style: 🎨 remove em dashes across the documentation

Author: slugb0t

docs/dev/api-reference.md

@@ -12,7 +12,7 @@ head:
 
 The central API exposes its functionality over HTTP from `ui/server/api`. This page is a reference to those endpoints.
 
-> [!WARNING] > **Internal and evolving.** These endpoints currently power Codefair's own web UI and are authenticated with the browser **session cookie**, not API tokens. They are documented here as the foundation of the planned **public REST API** — paths, payloads, and the auth model may change before a stable, token-authenticated, versioned API is released. Treat this as a contributor reference, not a public contract.
+> [!WARNING] > **Internal and evolving.** These endpoints currently power Codefair's own web UI and are authenticated with the browser **session cookie**, not API tokens. They are documented here as the foundation of the planned **public REST API**, so paths, payloads, and the auth model may change before a stable, token-authenticated, versioned API is released. Treat this as a contributor reference, not a public contract.
 
 ## :gear: Conventions
 
@@ -54,7 +54,7 @@ Each FAIR check exposes a consistent trio: `GET` current state, `POST` to create
 
 > [!NOTE]
 > A second, older pair of routes exists at `/dashboard/[owner]` and
-> `/dashboard/[owner]/[repo]`. No page calls them — the UI uses
+> `/dashboard/[owner]/[repo]`. No page calls them; the UI uses
 > `/[owner]/dashboard` and `/[owner]/[repo]/dashboard` above. Treat them as
 > deprecated and don't build on them.
 
@@ -118,7 +118,7 @@ the browser rather than by `fetch`.
 | :----- | :--------------------------------- | :------ | :------------------------------------------------------------------------------------ |
 | GET    | `/up`                              | Public  | Health check for the deployment proxy.                                                |
 | GET    | `/login/github`                    | Public  | Starts GitHub OAuth. Accepts `?redirect=` to return the user where they started.      |
-| GET    | `/login/github/callback`           | Public  | OAuth callback — validates state, creates the session, redirects to the dashboard.    |
+| GET    | `/login/github/callback`           | Public  | OAuth callback: validates state, creates the session, redirects to the dashboard.     |
 | GET    | `/doi/[owner]/[repo]`              | Public  | Redirects to the repository's published DOI. **This is the DOI badge's link target.** |
 | GET    | `/add/license/[identifier]`        | Session | Redirect shim to the license editor. Kept for links in older dashboard issues.        |
 | GET    | `/add/code-metadata/[identifier]`  | Session | Redirect shim to the metadata editor.                                                 |

docs/dev/architecture.md

@@ -30,11 +30,11 @@ flowchart LR
     GL["GitLab (planned)"]
   end
 
-  subgraph CentralAPI["Central API — ui/ (Nuxt + Nitro)"]
+  subgraph CentralAPI["Central API: ui/ (Nuxt + Nitro)"]
     WH["/api/webhooks/github"]
-    SVC["services/ — webhooks, compliance,<br/>dashboard, archival"]
+    SVC["services/: webhooks, compliance,<br/>dashboard, archival"]
     REST["/api/** REST endpoints"]
-    WEB["Web UI — pages/, components/"]
+    WEB["Web UI: pages/, components/"]
   end
 
   VAL["Validator microservice<br/>(Flask, port 5000)"]
@@ -59,8 +59,8 @@ flowchart LR
 | :-------------- | :----------- | :------------------------------------ | :---------------------------------------------------------------------------- |
 | **Central API** | `ui/`        | Nuxt 4, Nitro, Octokit, Prisma, Lucia | Web UI **and** backend: webhooks, compliance, dashboard, PRs, archival, auth. |
 | **Validator**   | `validator/` | Python 3, Flask, Flask-RESTX          | Validates CWL, `CITATION.cff`, and `codemeta.json` over HTTP.                 |
-| **Database**    | —            | PostgreSQL                            | Stores installations, per-check state, users, and Zenodo depositions.         |
-| **Zenodo**      | —            | external                              | Archival of releases and DOI minting.                                         |
+| **Database**    | n/a          | PostgreSQL                            | Stores installations, per-check state, users, and Zenodo depositions.         |
+| **Zenodo**      | n/a          | external                              | Archival of releases and DOI minting.                                         |
 
 ## :gear: Inside the central API (`ui/server`)
 
@@ -70,19 +70,19 @@ The backend lives in `ui/server` and follows Nuxt/Nitro conventions:
 | :------------------- | :------------------------------------------------------------------------------------------------------------------------------- |
 | `server/api/`        | HTTP endpoints. File name encodes the method, e.g. `index.get.ts`, `index.post.ts`. See the [API reference](./api-reference.md). |
 | `server/routes/`     | Non-API server routes: GitHub OAuth login, `add/*` redirect shims, health check.                                                 |
-| `server/middleware/` | Runs on every request — session validation and CSRF checks (`auth.ts`).                                                          |
+| `server/middleware/` | Runs on every request: session validation and CSRF checks (`auth.ts`).                                                           |
 | `server/services/`   | The business logic, grouped by concern (see below).                                                                              |
 | `server/utils/`      | Shared helpers: `prisma.ts`, `auth/*`, `cuid.ts`, `logwatch.ts`.                                                                 |
 | `server/plugins/`    | Nitro startup plugins, e.g. `env-check.ts` which fails fast on missing env vars.                                                 |
 
 The `services/` folder is where most feature work happens:
 
-- **`services/webhooks/`** — one handler per GitHub event family: `installation.ts`, `push.ts`, `pull-request.ts`, `issues.ts`.
-- **`services/compliance/`** — the FAIR checks: `license.ts`, `metadata.ts`, `readme.ts`, `contributing.ts`, `cwl.ts`, orchestrated by `index.ts`.
-- **`services/providers/`** — the platform abstraction: `interface.ts` (the contract) and `github.ts` (the GitHub implementation).
-- **`services/github-app/`** — `client.ts` wires up the Octokit `App` and hands out installation-scoped clients.
-- **`services/dashboard/`** — `manager.ts` (reads/writes the dashboard issue) and `renderer.ts` (pure markdown builder).
-- **`services/archival/`** — `interface.ts` (the `ArchivalProvider` contract) and `zenodo.ts` (the Zenodo implementation).
+- **`services/webhooks/`**: one handler per GitHub event family: `installation.ts`, `push.ts`, `pull-request.ts`, `issues.ts`.
+- **`services/compliance/`**: the FAIR checks: `license.ts`, `metadata.ts`, `readme.ts`, `contributing.ts`, `cwl.ts`, orchestrated by `index.ts`.
+- **`services/providers/`**: the platform abstraction: `interface.ts` (the contract) and `github.ts` (the GitHub implementation).
+- **`services/github-app/`**: `client.ts` wires up the Octokit `App` and hands out installation-scoped clients.
+- **`services/dashboard/`**: `manager.ts` (reads/writes the dashboard issue) and `renderer.ts` (pure markdown builder).
+- **`services/archival/`**: `interface.ts` (the `ArchivalProvider` contract) and `zenodo.ts` (the Zenodo implementation).
 
 ## :inbox_tray: How a webhook is handled
 
@@ -116,16 +116,16 @@ sequenceDiagram
 
 Key handlers:
 
-- **`installation` / `installation_repositories`** — a repo was added or removed. On add, Codefair creates an `Installation` row, runs the first compliance check, and opens the dashboard issue. (To protect against bulk installs, only the first repositories get a full run; the rest are rate-limited.)
-- **`push`** — only the default branch is processed. Codefair re-runs the checks and updates the dashboard.
-- **`pull_request`** — tracks the Codefair-created PRs (license, README, …) so the dashboard can show their status.
-- **`issues`** — reopening the dashboard issue restores it; closing updates state.
+- **`installation` / `installation_repositories`**: a repo was added or removed. On add, Codefair creates an `Installation` row, runs the first compliance check, and opens the dashboard issue. (To protect against bulk installs, only the first repositories get a full run; the rest are rate-limited.)
+- **`push`**: only the default branch is processed. Codefair re-runs the checks and updates the dashboard.
+- **`pull_request`**: tracks the Codefair-created PRs (license, README, …) so the dashboard can show their status.
+- **`issues`**: reopening the dashboard issue restores it; closing updates state.
 
 ## :electric_plug: The provider abstraction (multi-platform support)
 
 The most important design decision is that **compliance services never touch
 Octokit directly**. Instead they receive a `RepositoryProvider`
-(`server/services/providers/interface.ts`) — a platform-agnostic contract with
+(`server/services/providers/interface.ts`), a platform-agnostic contract with
 methods like `getFileContent`, `listDirectory`, `commitFile`,
 `createPullRequest`, and `createIssue`.
 
@@ -144,8 +144,8 @@ flowchart TD
 `GitHubRepositoryProvider` (`providers/github.ts`) implements that contract
 today by translating each method into an Octokit request. A future
 `GitLabRepositoryProvider` will implement the **same** interface, and the
-compliance code will not need to change. This is what makes GitLab support — and
-the eventual public REST API — tractable. See
+compliance code will not need to change. This is what makes GitLab support (and
+the eventual public REST API) tractable. See
 [Platform Providers (GitLab)](./providers.md) for how to add one.
 
 Archival follows the same pattern: `ArchivalProvider`
@@ -155,7 +155,7 @@ for additional archival backends (e.g. Figshare) later.
 ## :floppy_disk: Data model
 
 State is stored in PostgreSQL through Prisma (`ui/prisma/schema.prisma`). The
-hub of the schema is the **`Installation`** model — one row per repository
+hub of the schema is the **`Installation`** model, one row per repository
 Codefair is installed on. Each compliance check has its own model linked 1:1 to
 `Installation` and cascades on delete:
 
@@ -176,15 +176,15 @@ erDiagram
 Other models include `User` and `Session` (authentication), `ZenodoToken` and
 `ZenodoDeposition` (archival), and `Analytics` (usage counters).
 
-## :lock: Authentication — two distinct identities
+## :lock: Authentication: two distinct identities
 
 Codefair uses GitHub in two different ways, and it helps to keep them separate:
 
-1. **GitHub App identity** — how Codefair acts _as the bot_ (reading repos,
+1. **GitHub App identity**: how Codefair acts _as the bot_ (reading repos,
    committing files, opening PRs and issues). Configured in
    `services/github-app/client.ts` with `GH_APP_ID` and `GH_APP_PRIVATE_KEY`;
    Octokit mints short-lived, installation-scoped tokens automatically.
-2. **User identity** — how a human signs in to the web dashboard. This is GitHub
+2. **User identity**: how a human signs in to the web dashboard. This is GitHub
    **OAuth**, handled with [Lucia](https://lucia-auth.com/) sessions and
    [Arctic](https://arctic.js.org/) (`server/utils/auth.ts`,
    `server/middleware/auth.ts`). The user's OAuth token is used to confirm they
@@ -195,7 +195,7 @@ Codefair uses GitHub in two different ways, and it helps to keep them separate:
 
 The `validator/` service is intentionally small and stateless. It exposes a few
 HTTP endpoints (`/validate-cwl`, `/validate-citation`, `/validate-codemeta`,
-plus `/up` and `/echo`) and wraps established tools — `cwltool`, `cffconvert`,
+plus `/up` and `/echo`) and wraps established tools: `cwltool`, `cffconvert`,
 and JSON-Schema validation for CodeMeta. The central API calls it via the
 `VALIDATOR_URL` environment variable. Because it is decoupled over HTTP, it can
 be deployed and scaled independently. To add a new validation type, see
@@ -213,7 +213,7 @@ If you worked on Codefair before, here is what changed:
 | Two backends (`bot` + `ui`) with two `.env` files. | One app, one `ui/.env`.                                                 |
 | Two deployments to keep in step.                   | One deployment, one Prisma schema.                                      |
 
-Both backends use PostgreSQL through Prisma — that did not change in the
+Both backends use PostgreSQL through Prisma; that did not change in the
 migration. The schema now lives only in `ui/prisma/`.
 
 ### The `use_central_api` flag {#use-central-api-flag}
@@ -222,8 +222,8 @@ The cutover is per repository, not global. `Installation.use_central_api`
 (added in migration `20260320211650`) decides which backend handles a given
 repository:
 
-- **`true`** — the central API handles it. Every `bot/` handler early-returns.
-- **`false`** (the default) — the legacy Probot backend still handles it.
+- **`true`**: the central API handles it. Every `bot/` handler early-returns.
+- **`false`** (the default): the legacy Probot backend still handles it.
 
 This is why `bot/` is best described as **being retired** rather than gone: it
 still serves installations that have not been flipped over. Two consequences

docs/dev/compliance-check.md

@@ -10,7 +10,7 @@ head:
 
 # Adding a Compliance Check :sparkles:
 
-A **compliance check** is a single FAIR rule Codefair evaluates for a repository — for example "does a `LICENSE` file exist?" or "is the `codemeta.json` valid?". Each check produces a result that is stored in the database and rendered as a section of the repository's **FAIR Compliance Dashboard** issue.
+A **compliance check** is a single FAIR rule Codefair evaluates for a repository. For example, "does a `LICENSE` file exist?" or "is the `codemeta.json` valid?". Each check produces a result that is stored in the database and rendered as a section of the repository's **FAIR Compliance Dashboard** issue.
 
 Codefair is deliberately modular: checks are small functions that receive a platform-agnostic [`RepositoryProvider`](./providers.md) and are wired into a single orchestrator, `runComplianceChecks()`. This page walks through adding a brand-new check end-to-end by building an example that verifies an `expecto_patronum.md` file exists.
 
@@ -68,7 +68,7 @@ export async function checkForExpecto(
 ```
 
 > [!IMPORTANT]
-> Always go through the `provider` (`getFileContent`, `listDirectory`, `commitFile`, …) — **never** import Octokit directly in a compliance service. This is what lets the same check run unchanged on GitHub today and GitLab in the future. See [Platform Providers](./providers.md).
+> Always go through the `provider` (`getFileContent`, `listDirectory`, `commitFile`, …). **Never** import Octokit directly in a compliance service. This is what lets the same check run unchanged on GitHub today and GitLab in the future. See [Platform Providers](./providers.md).
 
 ## **Step 3**: Register the check in the orchestrator
 
@@ -94,7 +94,7 @@ export interface ComplianceSubjects {
   expecto: ExpectoResult;
 }
 
-// 3. Run it inside runComplianceChecks() — add a default stub and a Promise.all entry
+// 3. Run it inside runComplianceChecks(): add a default stub and a Promise.all entry
 const defaultExpecto: ExpectoResult = { content: '', path: '', status: false };
 
 const [readme, license, metadata, contributing, cofc, expecto] =
@@ -154,7 +154,7 @@ To write results back, follow the pattern in `server/services/compliance/license
 
 ## **Step 5**: Render it on the dashboard
 
-The dashboard issue body is built by `server/services/dashboard/renderer.ts` — a pure function that turns the compliance results into Markdown. Add a section renderer modelled on `renderReadme()`:
+The dashboard issue body is built by `server/services/dashboard/renderer.ts`, a pure function that turns the compliance results into Markdown. Add a section renderer modelled on `renderReadme()`:
 
 ```typescript
 function renderExpecto(
@@ -191,14 +191,14 @@ Then call it from `renderDashboard()` and add the data to the `DashboardSections
 body += renderExpecto(owner, repo, expecto);
 ```
 
-When `renderDashboard()` runs, the dashboard manager (`server/services/dashboard/manager.ts`) updates the single GitHub issue for the repository — no extra wiring needed.
+When `renderDashboard()` runs, the dashboard manager (`server/services/dashboard/manager.ts`) updates the single GitHub issue for the repository, with no extra wiring needed.
 
 ## **Step 6**: Test the feature
 
 Run the stack locally (see [Running Locally](./running-locally.md)):
 
 ```bash
-# In ui/ — runs the Nuxt server plus the Smee webhook proxy
+# In ui/: runs the Nuxt server plus the Smee webhook proxy
 yarn dev:webhook
 ```