Use "Nomulus" name in documentation

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135509458

docs/admin-tool.md

@@ -2,7 +2,7 @@
 
 Nomulus includes a command-line registry administration tool that is invoked
 using the `nomulus` command. It has the ability to view and change a large
-number of things in a running domain registry environment, including creating
+number of things in a running Nomulus environment, including creating
 registrars, updating premium and reserved lists, running an EPP command from a
 given XML file, and performing various backend tasks like re-running RDE if the
 most recent export failed. Its code lives inside the tools package

docs/app-engine-architecture.md

@@ -1,11 +1,13 @@
 # App Engine architecture
 
-This document contains information on the overall architecture of the Domain
-Registry project as it is implemented in App Engine.
+This document contains information on the overall architecture of Nomulus as
+pertains to App Engine.
+
+[TOC]
 
 ## Services
 
-The Domain Registry contains three
+Nomulus contains three
 [services](https://cloud.google.com/appengine/docs/python/an-overview-of-app-engine),
 which were previously called modules in earlier versions of App Engine. The
 services are: default (also called front-end), backend, and tools. Each service
@@ -88,10 +90,10 @@ tasks to push queues at regularly scheduled intervals, and the [MapReduce
 framework](https://cloud.google.com/appengine/docs/java/dataprocessing/) adds
 tasks for each phase of the MapReduce algorithm.
 
-The Domain Registry project uses a particular pattern of paired push/pull queues
-that is worth explaining in detail. Push queues are essential because App
-Engine's architecture does not support long-running background processes, and so
-push queues are thus the fundamental building block that allows asynchronous and
+Nomulus uses a particular pattern of paired push/pull queues that is worth
+explaining in detail. Push queues are essential because App Engine's
+architecture does not support long-running background processes, and so push
+queues are thus the fundamental building block that allows asynchronous and
 background execution of code that is not in response to incoming web requests.
 However, they also have limitations in that they do not allow batch processing
 or grouping. That's where the pull queue comes in. Regularly scheduled tasks in
@@ -99,12 +101,12 @@ the push queue will, upon execution, poll the corresponding pull queue for a
 specified number of tasks and execute them in a batch. This allows the code to
 execute in the background while taking advantage of batch processing.
 
-Particulars on the task queues in use by the Domain Registry project are
-specified in the `queue.xml` file. Note that many push queues have a direct
-one-to-one correspondence with entries in `cron.xml` because they need to be
-fanned-out on a per-TLD or other basis (see the Cron section below for more
-explanation). The exact queue that a given cron task will use is passed as the
-query string parameter "queue" in the url specification for the cron task.
+The task queues used by Nomulus are configured in the `queue.xml` file. Note
+that many push queues have a direct one-to-one correspondence with entries in
+`cron.xml` because they need to be fanned-out on a per-TLD or other basis (see
+the Cron section below for more explanation). The exact queue that a given cron
+task will use is passed as the query string parameter "queue" in the url
+specification for the cron task.
 
 Here are the task queues in use by the system. All are push queues unless
 explicitly marked as otherwise.
@@ -159,9 +161,9 @@ explicitly marked as otherwise.
 *   `load[0-9]` -- Queues used to load-test the system by `LoadTestAction`.
     These queues don't need to exist except when actively running load tests
     (which is not recommended on production environments). There are ten of
-    these queues to provide simple sharding, because the Domain Registry system
-    is capable of handling significantly more Queries Per Second than the
-    highest throttle limit available on task queues (which is 500 qps).
+    these queues to provide simple sharding, because Nomulus is capable of
+    handling significantly more Queries Per Second than the highest throttle
+    limit available on task queues (which is 500 qps).
 *   `lordn-claims` and `lordn-sunrise` -- Pull queues for handling LORDN
     exports. Tasks are enqueued synchronously during EPP commands depending on
     whether the domain name in question has a claims notice ID.
@@ -184,10 +186,10 @@ explicitly marked as otherwise.
 
 ## Environments
 
-The domain registry codebase comes pre-configured with support for a number of
-different environments, all of which are used in Google's registry system. Other
-registry operators may choose to user more or fewer environments, depending on
-their needs.
+Nomulus comes pre-configured with support for a number of different
+environments, all of which are used in Google's registry system. Other registry
+operators may choose to user more or fewer environments, depending on their
+needs.
 
 The different environments are specified in `RegistryEnvironment`. Most
 correspond to a separate App Engine app except for `UNITTEST` and `LOCAL`, which
@@ -202,8 +204,8 @@ The full list of environments supported out-of-the-box, in descending order from
 real to not, is:
 
 *   `PRODUCTION` -- The real production environment that is actually running
-    live TLDs. Since the Domain Registry is a shared registry platform, there
-    need only ever be one of these.
+    live TLDs. Since Nomulus is a shared registry platform, there need only ever
+    be one of these.
 *   `SANDBOX` -- A playground environment for external users to test commands in
     without the possibility of affecting production data. This is the
     environment new registrars go through
@@ -287,7 +289,7 @@ cron.xml is:
 
 ## Cloud Datastore
 
-The Domain Registry platform uses [Cloud
+Nomulus uses [Cloud
 Datastore](https://cloud.google.com/appengine/docs/java/datastore/) as its
 primary database. Cloud Datastore is a NoSQL document database that provides
 automatic horizontal scaling, high performance, and high availability. All
@@ -388,15 +390,14 @@ registry codebase:
 
 ## Cloud Storage buckets
 
-The Domain Registry platform uses [Cloud
-Storage](https://cloud.google.com/storage/) for bulk storage of large flat files
-that aren't suitable for Datastore. These files include backups, RDE exports,
-Datastore snapshots (for ingestion into BigQuery), and reports. Each bucket name
-must be unique across all of Google Cloud Storage, so we use the common
-recommended pattern of prefixing all buckets with the name of the App Engine app
-(which is itself globally unique). Most of the bucket names are configurable,
-but the defaults are as follows, with PROJECT standing in as a placeholder for
-the App Engine app name:
+Nomulus uses [Cloud Storage](https://cloud.google.com/storage/) for bulk storage
+of large flat files that aren't suitable for Datastore. These files include
+backups, RDE exports, Datastore snapshots (for ingestion into BigQuery), and
+reports. Each bucket name must be unique across all of Google Cloud Storage, so
+we use the common recommended pattern of prefixing all buckets with the name of
+the App Engine app (which is itself globally unique). Most of the bucket names
+are configurable, but the defaults are as follows, with PROJECT standing in as a
+placeholder for the App Engine app name:
 
 *   `PROJECT-billing` -- Monthly invoice files for each registrar.
 *   `PROJECT-commits` -- Daily exports of commit logs that are needed for

docs/code-structure.md

@@ -3,6 +3,8 @@
 This document contains information on the overall structure of the code, and how
 particularly important pieces of the system are implemented.
 
+[TOC]
+
 ## Dagger dependency injection
 
 ## Bazel build system

docs/configuration.md

@@ -30,15 +30,14 @@ different values for different environments. This is especially pronounced in
 the `UNITTEST` and `LOCAL` environments, which don't run on App Engine at all.
 As an example, some timeouts may be long in production and short in unit tests.
 
-See the "App Engine architecture" documentation for more details on environments
-as used in the domain registry.
+See the [App Engine architecture](./app-engine-architecture.md) documentation
+for more details on environments as used by Nomulus.
 
 ## App Engine configuration
 
 App Engine configuration isn't covered in depth in this document as it is
 thoroughly documented in the [App Engine configuration docs][app-engine-config].
-The main files of note that come pre-configured along with the domain registry
-are:
+The main files of note that come pre-configured in Nomulus are:
 
 *   `cron.xml` -- Configuration of cronjobs
 *   `web.xml` -- Configuration of URL paths on the webserver
@@ -72,8 +71,8 @@ provides the instance of `RegistryConfig`, and defaults to returning
 In order to create a configuration specific to your registry, we recommend
 copying the `ProductionRegistryConfigExample` class to a new class that will not
 be shared publicly, setting the `google.registry.config` system property in the
-`appengine-web.xml` files to the fully qualified class name of that new class
-so that `RegistryConfigLoader` will load it instead, and then editing said new
+`appengine-web.xml` files to the fully qualified class name of that new class so
+that `RegistryConfigLoader` will load it instead, and then editing said new
 class to add your specific configuration options. There is one
 `appengine-web.xml` file per service (so three per environment). The same
 configuration class must be used for each service, but different ones can be

docs/developing.md

@@ -8,11 +8,11 @@ including how to set up an IDE environment and run tests.
 `RegistryTestServer` is a lightweight test server for the registry that is
 suitable for running locally for development. It uses local versions of all
 Google Cloud Platform dependencies, when available. Correspondingly, its
-functionality is limited compared to a Domain Registry instance running on an
-actual App Engine instance. It is most helpful for doing web UI development such
-as on the registrar console: it allows you to update JS, CSS, images, and other
-front-end resources, and see the changes instantly simply by refreshing the
-relevant page in your browser.
+functionality is limited compared to a Nomulus instance running on an actual App
+Engine instance. It is most helpful for doing web UI development such as on the
+registrar console: it allows you to update JS, CSS, images, and other front-end
+resources, and see the changes instantly simply by refreshing the relevant page
+in your browser.
 
 To see the registry server's command-line parameters, run:
 

docs/flows.md

@@ -1,4 +1,4 @@
-# Domain Registry EPP Command API Documentation
+# Nomulus EPP Command API Documentation
 
 ## ContactUpdateFlow
 

docs/operational-procedures.md

@@ -11,13 +11,13 @@ production registry system.
 
 ### Premium list file format
 
-The default domain registry codebase comes with a
-`StaticPremiumListPricingEngine` that determines premium prices of domain labels
-(i.e. the part of the domain name without the TLD) by checking for their
-presence on a list of prices in Datastore. `nomulus` is used to load and
-update these lists from flat text files. The format of this list is simple: It
-is a newline-delimited CSV text file with each line containing the label and its
-price (including currency specifier in ISO-4217 format). As an example:
+Nomulus comes with a `StaticPremiumListPricingEngine` that determines premium
+prices of domain labels (i.e. the part of the domain name without the TLD) by
+checking for their presence on a list of prices in Datastore. `nomulus` is used
+to load and update these lists from flat text files. The format of this list is
+simple: It is a newline-delimited CSV text file with each line containing the
+label and its price (including currency specifier in ISO-4217 format). As an
+example:
 
 ```
 premium,USD 100

java/google/registry/config/ProductionRegistryConfigExample.java

@@ -187,7 +187,7 @@ public final class ProductionRegistryConfigExample implements RegistryConfig {
 
   @Override
   public String getDocumentationProjectTitle() {
-    return "Domain Registry";
+    return "Nomulus";
   }
 
   @Override

java/google/registry/config/TestRegistryConfig.java

@@ -134,7 +134,7 @@ public class TestRegistryConfig implements RegistryConfig {
 
   @Override
   public String getDocumentationProjectTitle() {
-    return "Domain Registry";
+    return "Nomulus";
   }
 
   @Override