Merge branch 'main' into wip/touch-events

4 files changed, 8 insertions, 8 deletions

diff --git a/docs/api/book.toml b/docs/api/book.toml
index 476872c..493939b 100644
--- a/docs/api/book.toml
+++ b/docs/api/book.toml
@@ -1,5 +1,5 @@
 [book]
-title = "The hi API"
+title = "The Pilcrow API"
 authors = ["Owen Jacobson"]
 language = "en"
 multilingual = false
diff --git a/docs/design.md b/docs/design.md
index 1180b83..6cd0075 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -1,6 +1,6 @@
 # Internal design
 
-`hi`'s design is discovered and not planned. Do not take this as doctrine; continue to experiment on the structure as you find new needs.
+`pilcrow`'s design is discovered and not planned. Do not take this as doctrine; continue to experiment on the structure as you find new needs.
 
 As of this writing, the basic flow of most requests hits several subsystems:
 
@@ -15,7 +15,7 @@ This approach helps enable testing (see [testing.md] and the implementation of m
 
 Handling time in a service is always tricky.
 
-`hi` takes the approach that a request is considered to be serviced at one time, and that that time is determined when the request is received. The internals of `hi` - the "app" and data access types described below, as well as most other supporting tools - are written with an eye towards accepting the "current time" as an argument, rather than calling out to a clock for themselves.
+`pilcrow` takes the approach that a request is considered to be serviced at one time, and that that time is determined when the request is received. The internals of `pilcrow` - the "app" and data access types described below, as well as most other supporting tools - are written with an eye towards accepting the "current time" as an argument, rather than calling out to a clock for themselves.
 
 The "current time" for a request is determined in `src/clock.rs`, which runs on every request, and is available to the handler via the `RequestedAt` extractor defined in that module.
 
diff --git a/docs/internal-server-errors.md b/docs/internal-server-errors.md
index 16d61a2..7532e10 100644
--- a/docs/internal-server-errors.md
+++ b/docs/internal-server-errors.md
@@ -1,6 +1,6 @@
 # Internal Server Errors
 
-When `hi` encounters a problem that prevents a request from completing, it may report a `500 Internal Server Error` to clients, along with an error code. The actual error will be printed to standard error, with the error code. The following sections describe errors we've encountered, the likely operational consequences, and recommend approaches for addressing them.
+When the `pilcrow` server encounters a problem that prevents a request from completing, it may report a `500 Internal Server Error` to clients, along with an error code. The actual error will be printed to standard error, with the error code. The following sections describe errors we've encountered, the likely operational consequences, and recommend approaches for addressing them.
 
 ## database is locked
 
diff --git a/docs/ops.md b/docs/ops.md
index 02644c2..4274e22 100644
--- a/docs/ops.md
+++ b/docs/ops.md
@@ -1,11 +1,11 @@
-# Operating `hi`
+# Operating pilcrow
 
 ## Upgrades
 
-`hi` will automatically upgrade its database on startup. Before doing so, it will create a backup of your database (at `.hi.backup`, or controlled by `--backup-database-url`). If the migration process succeeds, this backup will be deleted automatically. If the migration process _fails_, however, `hi` will attempt to restore your existing database from the backup before exiting. If the restore process also fails, then both the backup database and the suspected-broken database will be left in place.
+The `pilcrow` server will automatically upgrade its database on startup. Before doing so, it will create a backup of your database (at `pilcrow.db.backup`, or controlled by `--backup-database-url`). If the migration process succeeds, this backup will be deleted automatically. If the migration process _fails_, however, `pilcrow` will attempt to restore your existing database from the backup before exiting. If the restore process also fails, then both the backup database and the suspected-broken database will be left in place.
 
-To avoid destroying backups that may still be needed, `hi` will not start if the backup database already exists. **There is no catch-all advice on how to proceed**, but you can try the following:
+To avoid destroying backups that may still be needed, `pilcrow` will not start if the backup database already exists. **There is no catch-all advice on how to proceed**, but you can try the following:
 
 * Start the server with **a copy** of the backup database, and determine if any data has been lost. If not, shut it down, replace your main database by copying the backup, and carry on.
 
-The `hi` database is an ordinary file. While the server is not running, it can be freely copied or renamed without invalidating the data in it.
+The `pilcrow` database is an ordinary file. While the server is not running, it can be freely copied or renamed without invalidating the data in it.