tools/reformat

12 files changed, 75 insertions, 96 deletions

diff --git a/docs/api/authentication.md b/docs/api/authentication.md
index 7b5ebd7..2e9b58f 100644
--- a/docs/api/authentication.md
+++ b/docs/api/authentication.md
@@ -15,10 +15,10 @@ Authentication associates each authenticated request with a user.
 
 To create users, see [initial setup](./initial-setup.md) and [invitations](./invitations.md).
 
-
 ## Names
 
 <!-- This prose is duplicated in channels-messages.md. If you change it here, consider changing it there, too. -->
+
 The service handles user names using two separate forms.
 
 The first form is as given in the request used to create the user. This form of the use name is used throughout the API, and the service will preserve the name as entered (other than applying normalization), so that users' preferences around capitalization and accent marks are preserved.
@@ -27,8 +27,8 @@ The second form is a "canonical" form, used internally by the service to control
 
 The canonical form is not available to API clients, but its use has practical consequences:
 
-* Names that differ only by case or only by code point sequence are treated as the same name. If the name is in use, changing the capitalization or changing the sequence of combining marks will not allow the creation of a second "identical" user.
-* The login API accepts any name that canonicalizes to the form stored in the database, making user names effectively case-insensitive and composition-insensitive.
+- Names that differ only by case or only by code point sequence are treated as the same name. If the name is in use, changing the capitalization or changing the sequence of combining marks will not allow the creation of a second "identical" user.
+- The login API accepts any name that canonicalizes to the form stored in the database, making user names effectively case-insensitive and composition-insensitive.
 
 ## Identity tokens
 
@@ -40,13 +40,11 @@ Tokens are issued by logging into the service, using the `/api/auth/login` endpo
 To authenticate a request, include
 `cookie: identity=TOKEN SECRET` header in the request. For browser-based clients, this may happen automatically.
 
-
 ## Authentication failures
 
 Unless the endpoint's documentation says otherwise, all endpoints require authentication. Making a request to any endpoint that requires authentication, either without a token, or with a token that is not valid or that has expired, causes the service to return a
 `401 Unauthorized` response, instead of the responses documented for the endpoint the request was intended for. The API will not take action on requests that fail authentication in this way.
 
-
 ## `POST /api/auth/login`
 
 Authenticates the user using their name and password. The user must exist before calling this endpoint.
@@ -65,7 +63,7 @@ Authenticates the user using their name and password. The user must exist before
 The request must have the following fields:
 
 | Field      | Type   | Description                          |
-|:-----------|:-------|:-------------------------------------|
+| :--------- | :----- | :----------------------------------- |
 | `name`     | string | The login's name.                    |
 | `password` | string | The login's password, in plain text. |
 
@@ -86,7 +84,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field  | Type   | Description                    |
-|:-------|:-------|:-------------------------------|
+| :----- | :----- | :----------------------------- |
 | `id`   | string | The authenticated user's ID.   |
 | `name` | string | The authenticated user's name. |
 
@@ -100,7 +98,6 @@ The cookie will expire if it is not used regularly.
 This endpoint will respond with a status of
 `401 Unauthorized` if the login name and password do not correspond to an existing user.
 
-
 ## `POST /api/auth/logout`
 
 Invalidates the identity token used to make the request, logging the caller out.
@@ -120,7 +117,6 @@ This endpoint will respond with a status of `204 No Content` when successful.
 The response will include a `Set-Cookie` header that clears the
 `identity` cookie. Regardless of whether the client clears the cookie, the service also invalidates the token.
 
-
 ## `POST /api/password`
 
 Changes the current user's password, and invalidates all outstanding identity tokens.
@@ -137,7 +133,7 @@ Changes the current user's password, and invalidates all outstanding identity to
 The request must have the following fields:
 
 | Field      | Type   | Description                                    |
-|:-----------|:-------|:-----------------------------------------------|
+| :--------- | :----- | :--------------------------------------------- |
 | `password` | string | The login's _current_ password, in plain text. |
 | `to`       | string | The login's _new_ password, in plain text.     |
 
@@ -156,7 +152,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field  | Type   | Description                    |
-|:-------|:-------|:-------------------------------|
+| :----- | :----- | :----------------------------- |
 | `id`   | string | The authenticated user's ID.   |
 | `name` | string | The authenticated user's name. |
 
diff --git a/docs/api/basics.md b/docs/api/basics.md
index 271a269..ab39570 100644
--- a/docs/api/basics.md
+++ b/docs/api/basics.md
@@ -2,55 +2,49 @@
 
 The API is exposed as a collection of HTTP endpoints that accept JSON and return JSON on success, with exceptions as noted in the documentation for each endpoint.
 
-
 ## Path parameters
 
 Many API endpoints accept one or more parameters via the URL's path element. Each parameter in the documentation is described using a placeholder, consisting of a leading full colon followed by a label (for example, `:example`).
 
 Each endpoint's documentation describes the expected type and value of each parameter it accepts.
 
-
 ## Types
 
 Each endpoint documents the types of the fields in each request or response. The types consist of:
 
-* `integer`: a number, with no decimal part, representing a 64-bit unsigned integer.
-* `string`: any string.
-* `timestamp`: a string containing an [RFC 3339] timestamp.
-* `object`: a nested structure, which has its own schema.
-* `array of TYPE`: an array, whose elements follow the `TYPE` schema (ex. `array of object`).
+- `integer`: a number, with no decimal part, representing a 64-bit unsigned integer.
+- `string`: any string.
+- `timestamp`: a string containing an [RFC 3339] timestamp.
+- `object`: a nested structure, which has its own schema.
+- `array of TYPE`: an array, whose elements follow the `TYPE` schema (ex. `array of object`).
 
 [RFC 3339]: https://www.rfc-editor.org/rfc/rfc3339
 
-
 ## Request bodies
 
 Requests that require a JSON body must include a `content-type: application/json` header.
 
 For requests that take a JSON body, if the body does not match the required schema, the endpoint will return a `422 Unprocessable Entity` response, instead of the responses documented for that endpoint.
 
-
 ## Response bodies
 
 In general, API endpoints that return data do so as `application/json` documents, containing either a single object, or a list of objects. Each endpoint's documentation includes the response schema.
 
 A small number of endpoints return data in other formats. These exceptions are included in the relevant endpoints' documentation.
 
-
 ## Status codes
 
 This API uses HTTP status codes to report success or failure. Each endpoint documents the status codes it may return.
 
 In addition to the documented status codes for each endpoint, any endpoint may return the following status codes:
 
-* `401 Unauthorized`, as described under [authentication](./authentication.md#authentication-failures).
-
-* `422 Unprocessable Entity`, as described under [request bodies](#request-bodies).
+- `401 Unauthorized`, as described under [authentication](./authentication.md#authentication-failures).
 
-* `503 Service Unavailable`, as described under [initial setup](./initial-setup.md#requests-before-setup-completed).
+- `422 Unprocessable Entity`, as described under [request bodies](#request-bodies).
 
-* `500 Internal Server Error`, if there was an unexpected problem handling the request. The server will record information about the error to its own standard output.
+- `503 Service Unavailable`, as described under [initial setup](./initial-setup.md#requests-before-setup-completed).
 
+- `500 Internal Server Error`, if there was an unexpected problem handling the request. The server will record information about the error to its own standard output.
 
 ## Errors
 
diff --git a/docs/api/boot.md b/docs/api/boot.md
index 2b9cf00..7e3dda3 100644
--- a/docs/api/boot.md
+++ b/docs/api/boot.md
@@ -20,9 +20,9 @@ sequenceDiagram
 
 Client initialization serves three purposes:
 
-* It confirms that the client's [identity token](./authentication.md) is valid, and tells the client what user that token is associated with.
-* It provides an initial snapshot of the state of the service.
-* It provides a resume point for the [event stream](./events.md), which allows clients to consume events starting from the moment the snapshot was created.
+- It confirms that the client's [identity token](./authentication.md) is valid, and tells the client what user that token is associated with.
+- It provides an initial snapshot of the state of the service.
+- It provides a resume point for the [event stream](./events.md), which allows clients to consume events starting from the moment the snapshot was created.
 
 ## `GET /api/boot`
 
@@ -71,7 +71,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field          | Type            | Description                                                                                                              |
-|:---------------|:----------------|:-------------------------------------------------------------------------------------------------------------------------|
+| :------------- | :-------------- | :----------------------------------------------------------------------------------------------------------------------- |
 | `user`         | object          | The details of the caller's identity.                                                                                    |
 | `resume_point` | integer         | A resume point for [events](./events.md), such that the event stream will begin immediately after the included snapshot. |
 | `heartbeat`    | integer         | The [heartbeat timeout](./events.md#heartbeat-events), in seconds, for events.                                           |
@@ -82,21 +82,21 @@ The response will include the following fields:
 The `user` object will include the following fields:
 
 | Field  | Type   | Description                              |
-|:-------|:-------|:-----------------------------------------|
+| :----- | :----- | :--------------------------------------- |
 | `name` | string | The name of the caller's login identity. |
 | `id`   | string | The ID of the caller's login identity.   |
 
 Each element of the `users` array describes a distinct user, and will include the following fields:
 
 | Field  | Type   | Description                                                                                                                          |
-|:-------|:-------|:-------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :----- | :----------------------------------------------------------------------------------------------------------------------------------- |
 | `name` | string | The name for the user.                                                                                                               |
 | `id`   | string | A unique identifier for the user. This can be used to associate the user with other events, or to make API calls targeting the user. |
 
 Each element of the `channels` array describes a distinct channel, and will include the following fields:
 
 | Field  | Type      | Description                                                                                                                                   |
-|:-------|:----------|:----------------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :-------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`   | timestamp | The moment the channel was created.                                                                                                           |
 | `name` | string    | The name for the channel.                                                                                                                     |
 | `id`   | string    | A unique identifier for the channel. This can be used to associate the channel with other events, or to make API calls targeting the channel. |
@@ -104,7 +104,7 @@ Each element of the `channels` array describes a distinct channel, and will incl
 Each element of the `messages` array describes a distinct message, and will include the following fields:
 
 | Field     | Type      | Description                                                                                                                                   |
-|:----------|:----------|:----------------------------------------------------------------------------------------------------------------------------------------------|
+| :-------- | :-------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`      | timestamp | The moment the message was sent.                                                                                                              |
 | `channel` | string    | The ID of the channel the message was sent to.                                                                                                |
 | `sender`  | string    | The ID of the user that sent the message.                                                                                                     |
diff --git a/docs/api/channels-messages.md b/docs/api/channels-messages.md
index 1eca1b4..e762600 100644
--- a/docs/api/channels-messages.md
+++ b/docs/api/channels-messages.md
@@ -29,6 +29,7 @@ Every channel has a unique name, chosen when the channel is created.
 ## Names
 
 <!-- This prose is duplicated in authentication.md. If you change it here, consider changing it there, too. -->
+
 The service handles channel names using two separate forms.
 
 The first form is as given in the request used to create the channel. This form of the channel name is used throughout the API, and the service will preserve the name as entered (other than applying normalization), so that users' preferences around capitalization and accent marks are preserved.
@@ -58,16 +59,16 @@ Creates a channel.
 The request must have the following fields:
 
 | Field  | Type   | Description         |
-|:-------|:-------|:--------------------|
+| :----- | :----- | :------------------ |
 | `name` | string | The channel's name. |
 
 The proposed `name` must be valid. The precise definition of valid is still up in the air, but, at minimum:
 
-* It must be non-empty.
-* It must not be "too long." (Currently, 64 characters is too long.)
-* It must begin with a printing character.
-* It must end with a printing character.
-* It must not contain runs of multiple whitespace characters.
+- It must be non-empty.
+- It must not be "too long." (Currently, 64 characters is too long.)
+- It must begin with a printing character.
+- It must end with a printing character.
+- It must not contain runs of multiple whitespace characters.
 
 ### Success
 
@@ -84,7 +85,7 @@ This endpoint will respond with a status of
 The response will have the following fields:
 
 | Field  | Type   | Description                                                                                                                             |
-|:-------|:-------|:----------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :----- | :-------------------------------------------------------------------------------------------------------------------------------------- |
 | `id`   | string | A unique identifier for the channel. This can be used to associate the channel with events, or to make API calls targeting the channel. |
 | `name` | string | The channel's name.                                                                                                                     |
 
@@ -107,7 +108,7 @@ Sends a message to a channel.
 This endpoint requires the following path parameter:
 
 | Parameter | Type   | Description   |
-|:----------|:-------|:--------------|
+| :-------- | :----- | :------------ |
 | `id`      | string | A channel ID. |
 
 ### Request
@@ -121,7 +122,7 @@ This endpoint requires the following path parameter:
 The request must have the following fields:
 
 | Field  | Type   | Description                            |
-|:-------|:-------|:---------------------------------------|
+| :----- | :----- | :------------------------------------- |
 | `body` | string | The message to deliver to the channel. |
 
 ### Success
@@ -142,7 +143,7 @@ This endpoint will respond with a status of
 The response will have the following fields:
 
 | Field     | Type      | Description                                                                                                                             |
-|:----------|:----------|:----------------------------------------------------------------------------------------------------------------------------------------|
+| :-------- | :-------- | :-------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`      | timestamp | The moment the message was sent.                                                                                                        |
 | `channel` | string    | The ID of the channel the message was sent to.                                                                                          |
 | `sender`  | string    | The ID of the user that sent the message.                                                                                               |
@@ -166,7 +167,7 @@ Deleting a channel prevents it from receiving any further messages. The channel
 This endpoint requires the following path parameter:
 
 | Parameter | Type   | Description   |
-|:----------|:-------|:--------------|
+| :-------- | :----- | :------------ |
 | `id`      | string | A channel ID. |
 
 ### Success
@@ -183,7 +184,7 @@ This endpoint will respond with a status of
 The response will have the following fields:
 
 | Field | Type   | Description       |
-|:------|:-------|:------------------|
+| :---- | :----- | :---------------- |
 | `id`  | string | The channel's ID. |
 
 When completed, the service will emit a [message deleted](events.md#message-deleted) event for each message in the channel, followed by a [channel deleted](events.md#channel-deleted) event with the channel's ID.
@@ -203,7 +204,7 @@ Deletes a message.
 This endpoint requires the following path parameter:
 
 | Parameter | Type   | Description   |
-|:----------|:-------|:--------------|
+| :-------- | :----- | :------------ |
 | `id`      | string | A message ID. |
 
 ### Success
@@ -220,7 +221,7 @@ This endpoint will respond with a status of
 The response will have the following fields:
 
 | Field | Type   | Description       |
-|:------|:-------|:------------------|
+| :---- | :----- | :---------------- |
 | `id`  | string | The message's ID. |
 
 When completed, the service will emit a [message deleted](events.md#message-deleted) event with the message's ID.
diff --git a/docs/api/events.md b/docs/api/events.md
index 7fc7d78..570dffa 100644
--- a/docs/api/events.md
+++ b/docs/api/events.md
@@ -31,13 +31,11 @@ sequenceDiagram
 The core of the service is to facilitate conversations between users. Conversational activity is delivered to clients using
 _events_. Each event notifies interested clients of activity sent to the service through its API.
 
-
 ## Asynchronous completion
 
 A number of endpoints return
 `202 Accepted` responses. The actions performed by those endpoints will be completed before events are delivered. To await the completion of an operation which returns this response, clients must monitor the event stream for the corresponding event.
 
-
 ## `GET /api/events`
 
 Subscribes to events.
@@ -87,13 +85,12 @@ The service may terminate the connection at any time. Clients should reconnect a
 Each event's `data` consists of a JSON object describing one event. Every event includes the following fields:
 
 | Field   | Type             | Description                                                                                                  |
-|:--------|:-----------------|:-------------------------------------------------------------------------------------------------------------|
+| :------ | :--------------- | :----------------------------------------------------------------------------------------------------------- |
 | `type`  | string           | The type of entity the event describes. Will be one of the types listed in the next section.                 |
 | `event` | string, optional | The specific kind of event. Will be one of the events listed with the associated `type` in the next section. |
 
 The remaining fields depend on the `type` and (if present) the `event` field.
 
-
 ## Heartbeat events
 
 ```json
@@ -108,7 +105,6 @@ Clients should treat any period of time without events, longer than the heartbea
 
 These events have the `type` field set to `"heartbeat"`. The `event` field is absent.
 
-
 ## User events
 
 The following events describe changes to users.
@@ -132,7 +128,7 @@ Sent whenever a new user is created.
 These events have the `event` field set to `"created"`. They include the following additional fields:
 
 | Field  | Type      | Description                                                                                                                                        |
-|:-------|:----------|:---------------------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`   | timestamp | The moment the user was created.                                                                                                                   |
 | `id`   | string    | A unique identifier for the newly-created user. This can be used to associate the user with other events, or to make API calls targeting the user. |
 | `name` | string    | The user's name.                                                                                                                                   |
@@ -160,7 +156,7 @@ Sent whenever a new channel is created.
 These events have the `event` field set to `"created"`. They include the following additional fields:
 
 | Field        | Type                | Description                                                                                                                                                 |
-|:-------------|:--------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| :----------- | :------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`         | timestamp           | The moment the channel was created.                                                                                                                         |
 | `id`         | string              | A unique identifier for the newly-created channel. This can be used to associate the channel with other events, or to make API calls targeting the channel. |
 | `name`       | string              | The channel's name.                                                                                                                                         |
@@ -190,7 +186,7 @@ Sent whenever a channel is deleted or expires.
 These events have the `event` field set to `"deleted"`. They include the following additional fields:
 
 | Field | Type      | Description                         |
-|:------|:----------|:------------------------------------|
+| :---- | :-------- | :---------------------------------- |
 | `at`  | timestamp | The moment the channel was deleted. |
 | `id`  | string    | The deleted channel's ID.           |
 
@@ -219,7 +215,7 @@ Sent whenever a message is sent by a client.
 These events have the `event` field set to `"sent"`. They include the following additional fields:
 
 | Field        | Type                | Description                                                                                                                                   |
-|:-------------|:--------------------|:----------------------------------------------------------------------------------------------------------------------------------------------|
+| :----------- | :------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------- |
 | `at`         | timestamp           | The moment the message was sent.                                                                                                              |
 | `channel`    | string              | The ID of the channel the message was sent to.                                                                                                |
 | `sender`     | string              | The ID of the user that sent the message.                                                                                                     |
@@ -251,6 +247,6 @@ Sent whenever a message is deleted or expires.
 These events have the `event` field set to `"deleted"`. They include the following additional fields:
 
 | Field | Type      | Description                         |
-|:------|:----------|:------------------------------------|
+| :---- | :-------- | :---------------------------------- |
 | `at`  | timestamp | The moment the message was deleted. |
 | `id`  | string    | The deleted message's ID.           |
diff --git a/docs/api/initial-setup.md b/docs/api/initial-setup.md
index 0179397..a3f6506 100644
--- a/docs/api/initial-setup.md
+++ b/docs/api/initial-setup.md
@@ -15,7 +15,6 @@ stateDiagram-v2
 
 New instances of this service require an initial setup step before they can fully enter service. This setup is performed online, via the API endpoints in this section.
 
-
 ## Requests before setup completed
 
 Before the service is set up, all API endpoints, other than those specifically documented as exceptions, will return a status of
@@ -23,12 +22,11 @@ Before the service is set up, all API endpoints, other than those specifically d
 
 Initial setup can be completed only once.
 
-
 ## `POST /api/setup`
 
 Initial setup performs the following tasks:
 
-* Create the first user for the service.
+- Create the first user for the service.
 
   This is the only user that does not require an [invitation](./invitations.md).
 
@@ -48,7 +46,7 @@ Initial setup performs the following tasks:
 The request must have the following fields:
 
 | Field      | Type   | Description                                  |
-|:-----------|:-------|:---------------------------------------------|
+| :--------- | :----- | :------------------------------------------- |
 | `name`     | string | The initial login's name.                    |
 | `password` | string | The initial login's password, in plain text. |
 
@@ -56,11 +54,11 @@ The request must have the following fields:
 
 The proposed `name` must be valid. The precise definition of valid is still up in the air, but, at minimum:
 
-* It must be non-empty.
-* It must not be "too long." (Currently, 64 characters is too long.)
-* It must begin with a printing character.
-* It must end with a printing character.
-* It must not contain runs of multiple whitespace characters.
+- It must be non-empty.
+- It must not be "too long." (Currently, 64 characters is too long.)
+- It must begin with a printing character.
+- It must end with a printing character.
+- It must not contain runs of multiple whitespace characters.
 
 ### Success
 
@@ -79,7 +77,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field  | Type   | Description                                                                                                                                        |
-|:-------|:-------|:---------------------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :----- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `id`   | string | A unique identifier for the newly-created user. This can be used to associate the user with other events, or to make API calls targeting the user. |
 | `name` | string | The user's name.                                                                                                                                   |
 
@@ -100,4 +98,3 @@ This endpoint will respond with a status of `400 Bad Request` if the proposed `n
 
 Once completed, this operation cannot be performed a second time. Subsequent requests to this endpoint will respond with a status of
 `409 Conflict`.
-
diff --git a/docs/api/invitations.md b/docs/api/invitations.md
index 0be2c2e..04e92c8 100644
--- a/docs/api/invitations.md
+++ b/docs/api/invitations.md
@@ -25,7 +25,6 @@ Other than the user created during [initial setup](./initial-setup.md), new user
 
 Any user can create invitations. Each invitation can be accepted at most once. An invitation which is not accepted within 24 hours expires.
 
-
 ## `POST /api/invite`
 
 Creates an invitation.
@@ -54,7 +53,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field       | Type   | Description                                                                   |
-|:------------|:-------|:------------------------------------------------------------------------------|
+| :---------- | :----- | :---------------------------------------------------------------------------- |
 | `id`        | string | A unique identifier for the invitation. This ID must be given to the invitee. |
 | `issuer`    | string | The user ID of the invitation's issuer.                                       |
 | `issued_at` | string | The timestamp from which the invitation will expire.                          |
@@ -62,7 +61,6 @@ The response will include the following fields:
 Clients and their operators are responsible for delivering the invitation to the invitee. Clients are strongly recommended to construct a URL for the invitation so that the invitee can take action on it easily. The included client supports URLs of the format
 `https://example.net/invite/:id` (with the `:id` placeholder substituted with the invitation's ID).
 
-
 ## `GET /api/invite/:id`
 
 Returns information about an outstanding invitation.
@@ -70,7 +68,7 @@ Returns information about an outstanding invitation.
 This endpoint requires the following path parameter:
 
 | Parameter | Type   | Description                                                                  |
-|:----------|:-------|:-----------------------------------------------------------------------------|
+| :-------- | :----- | :--------------------------------------------------------------------------- |
 | `id`      | string | An invitation ID, as returned from a previous request to `POST /api/invite`. |
 
 **This endpoint does not require an `identity` cookie.**
@@ -93,7 +91,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field       | Type   | Description                                          |
-|:------------|:-------|:-----------------------------------------------------|
+| :---------- | :----- | :--------------------------------------------------- |
 | `id`        | string | The ID of the invitation.                            |
 | `issuer`    | string | The name of the invitation's issuer.                 |
 | `issued_at` | string | The timestamp from which the invitation will expire. |
@@ -106,7 +104,6 @@ Clients should present the
 This endpoint will respond with a status of
 `404 Not Found` when the invitation ID either does not exist, or has already been accepted.
 
-
 ## `POST /api/invite/:id`
 
 Accepts an invitation and creates a new user.
@@ -114,7 +111,7 @@ Accepts an invitation and creates a new user.
 This endpoint requires the following path parameter:
 
 | Parameter | Type   | Description                                                                  |
-|:----------|:-------|:-----------------------------------------------------------------------------|
+| :-------- | :----- | :--------------------------------------------------------------------------- |
 | `id`      | string | An invitation ID, as returned from a previous request to `POST /api/invite`. |
 
 **This endpoint does not require an `identity` cookie.**
@@ -131,18 +128,19 @@ This endpoint requires the following path parameter:
 The request must have the following fields:
 
 | Field      | Type   | Description                             |
-|:-----------|:-------|:----------------------------------------|
+| :--------- | :----- | :-------------------------------------- |
 | `name`     | string | The new user's name.                    |
 | `password` | string | The new user's password, in plain text. |
 
 <!-- Reproduced in initial-setup.md. Edit in both places. -->
+
 The proposed `name` must be valid. The precise definition of valid is still up in the air, but, at minimum:
 
-* It must be non-empty.
-* It must not be "too long." (Currently, 64 characters is too long.)
-* It must begin with a printing character.
-* It must end with a printing character.
-* It must not contain runs of multiple whitespace characters.
+- It must be non-empty.
+- It must not be "too long." (Currently, 64 characters is too long.)
+- It must begin with a printing character.
+- It must end with a printing character.
+- It must not contain runs of multiple whitespace characters.
 
 ### Success
 
@@ -161,7 +159,7 @@ This endpoint will respond with a status of
 The response will include the following fields:
 
 | Field  | Type   | Description                                                                                                                                        |
-|:-------|:-------|:---------------------------------------------------------------------------------------------------------------------------------------------------|
+| :----- | :----- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `id`   | string | A unique identifier for the newly-created user. This can be used to associate the user with other events, or to make API calls targeting the user. |
 | `name` | string | The user's name.                                                                                                                                   |
 
diff --git a/docs/design.md b/docs/design.md
index 6cd0075..47df384 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -4,10 +4,10 @@
 
 As of this writing, the basic flow of most requests hits several subsystems:
 
-* Axum handles parsing and delivering requests to endpoint handlers.
-* Endpoint handlers interact with an "app" method (mostly defined in `**/app.rs`) to carry out logic.
-* App methods interact with the database through "repo" methods.
-* Repo methods access the database, and carry out minor tasks directly adjacent to data access (ID generation being the main example).
+- Axum handles parsing and delivering requests to endpoint handlers.
+- Endpoint handlers interact with an "app" method (mostly defined in `**/app.rs`) to carry out logic.
+- App methods interact with the database through "repo" methods.
+- Repo methods access the database, and carry out minor tasks directly adjacent to data access (ID generation being the main example).
 
 This approach helps enable testing (see [testing.md] and the implementation of most of the tests), and helps maintain some conceptual separation between what this service does and how each piece individually works.
 
diff --git a/docs/formatting.md b/docs/formatting.md
index 5339be0..90044eb 100644
--- a/docs/formatting.md
+++ b/docs/formatting.md
@@ -6,7 +6,6 @@ We use automated tools, rather than human effort, to maintain a consistent code
 - Rust is formatted using [rustfmt].
 
 [prettier]: https://prettier.io
-
 [rustfmt]: https://doc.rust-lang.org/cargo/commands/cargo-fmt.html
 
 ## Tools
diff --git a/docs/linting.md b/docs/linting.md
index 6620a74..47420bb 100644
--- a/docs/linting.md
+++ b/docs/linting.md
@@ -6,9 +6,7 @@ We use automated tools, rather than human effort, to spot possible bugs or dubio
 - Rust is linted using [cargo check] and [clippy].
 
 [eslint]: https://eslint.org/
-
 [cargo check]: https://doc.rust-lang.org/cargo/commands/cargo-check.html
-
 [clippy]: https://doc.rust-lang.org/cargo/commands/cargo-clippy.html
 
 ## Tools
diff --git a/docs/ops.md b/docs/ops.md
index 4274e22..4dfec49 100644
--- a/docs/ops.md
+++ b/docs/ops.md
@@ -6,6 +6,6 @@ The `pilcrow` server will automatically upgrade its database on startup. Before
 
 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.
+- 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 `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.
diff --git a/docs/testing.md b/docs/testing.md
index c6f3654..8e87568 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -4,11 +4,11 @@ Run `cargo test`.
 
 Most of the tests for this project use an integration-based testing approach:
 
-* Spin up a scratch copy of the application, using an in-memory database;
-* Perform operations against that database using the `app` abstraction to set up the scenario;
-* Interact with route endpoint functions directly to perform the test;
-* Inspect both the return values from the endpoint function to validate the results; and
-* Perform additional operations against the scratch database using the `app` absraction to validate behaviour.
+- Spin up a scratch copy of the application, using an in-memory database;
+- Perform operations against that database using the `app` abstraction to set up the scenario;
+- Interact with route endpoint functions directly to perform the test;
+- Inspect both the return values from the endpoint function to validate the results; and
+- Perform additional operations against the scratch database using the `app` absraction to validate behaviour.
 
 Tests can vary around this theme.