Archive, part 1: an admin archives or wakes one repository from Settings and the API, and its page says "archived on <date>" with a Wake button #1940

The feature is right and safe. One admin gate (requireRepoAdmin in the action, plus canAdmin in front of the API and the terminal key), the Settings and Wake forms go through adminForm (same-origin, tested with a foreign Origin), the date is escaped, and the migration is one nullable column. I booted the merged tree: Archive answers 303, the page shows "Archived on <date>" with Wake for the admin only, a guest sees the line and no form, and Settings renders in about 24 ms. The archive and terminal-archive suites pass. (The sandbox blocked me from reaching the preview host and the looks, so I checked by booting the app locally.)

Fix first: the check this pull says it fixes is red once it is merged. Main has since cut 0.7.124 with "migrations": 93 and no ids. Merged with main (git merge-tree main 56450d87 is clean), test/schema-additive.test.ts › the release record is newest first and never ahead of the schema fails: Expected: <= 91, Received: 93 on the 0.7.124 entry. Main fails the same way. This pull has taken on that test, though, and it is the pull that meets it. Merge main and give 0.7.124 the same ids you gave 0.7.123 (20261015090000-feed-chips, 20261015230000-a-domain-drill). Leave 20261015090000-a-repository-put-away out because it has not shipped. Then run bun test test/schema-additive.test.ts on the merged head.

Smaller, same round: PATCH {"archived":"yes"} answers 200 and silently does nothing. Every other field here refuses a bad value with a 422 (bad_decisions_by), so refuse a non-boolean archived the same way and add a test for it.

This does what #1838 asks, and nothing beyond it. A nullable archived_at column is added in a named migration, and the repository JSON carries archivedAt because repoJson spreads the row. PATCH {archived} is admin-only: a reader who is not an admin gets a 403 before validation, a value that is not a boolean gets a 422 bad_archived, and updateRepoSettings still enforces requireRepoAdmin underneath. The Settings → Archive POST goes through adminForm, so it gets the same-origin check and the admin gate, and a test covers the cross-origin refusal. The to field only switches between two fixed paths, so it cannot redirect elsewhere. The date is escaped through html. Archiving twice keeps the first stamp. The terminal's a key on About is offered only to an admin and gated again on the press. It writes through the same action, which appends repo.settings_updated to the bus, so web viewers see the change live. A guest sees the line but cannot flip it, and a test proves that. MCP is left out on purpose, as the issue says. Both test files are in GATE, the README documents the page, the API and the terminal, and there are no new dependencies.

I could not reach the preview or its screenshots from my sandbox, so this verdict rests on the code and the green check.

Nits only, none blocking:

• src/tui/screens/about.ts: the body of the get keys() getter is not indented.
• src/web/pages/repo.ts: archivedLine is missing its trailing semicolon.
• In the terminal only kind === "user" may archive, while the API lets an admin agent do it. Pick one rule when part 2 makes archiving actually hide things.

Most of this works. Only an admin can archive: updateRepoSettings calls requireRepoAdmin and the API checks canAdmin. The form is protected by adminForm, which does the same-origin check, and the PATCH accepts only true or false. A second archive keeps the first date, and dates are escaped through html. At head c4333dbd, test/archive.test.ts and test/tui-archive.test.ts pass (7 tests).

I could not check the preview or the screenshots: my sandbox can't reach the preview host or read /data/looks. So nothing here is confirmed by eye.

Fix first: the terminal and the API disagree on who may archive. The terminal only offers and accepts a when the account is a person (f.user.kind === "user"). PATCH and the Settings form let any admin archive, agents included. The terminal has to gate exactly as the page does, and this is decided in two places. Decide it once, in src/actions/repos.ts. Archiving is the owner's call, like crewOutsiders, decisionsBy and plansNeedNod, so add settings.archived !== undefined to the agent refusal near line 250. Then drop the kind === "user" check in about.ts, so may() is just canAdmin. Add a test where an admin agent's PATCH {"archived":true} is refused and nothing changes.

Smaller, fix in the same push:

• about.ts: held is a dead alias; use let repo = localRepo(src). The body of the get keys() array is not indented.
• repo.ts archivedLine: the template is missing its closing ;.
• Settings: the Archive card uses icon("alert"), the same icon as the danger zone. Archiving is calm and reversible, and the direction says no red noise, so give it a neutral icon.

Covers everything #1838 asks for. The migration adds one nullable column, and archivedAt appears in the repository JSON. All three doors go through updateRepoSettings: the PATCH, the same-origin-checked Settings form (via adminForm) and the terminal's a key. It refuses agents in the same place as the other decisions only a person makes, and appends repo.settings_updated, so a change made in the terminal reaches web viewers. The API refuses a non-admin with 403 and anything that isn't a real boolean with 422. The redirect target to is limited to repo or settings, so it can't be used as an open redirect. Dates are escaped through html. Archiving twice keeps the first date. In the terminal, may() is checked again when the key is pressed, not only when the key is offered. The tests cover the round-trip, the 403, the cross-origin refusal, the page line, a guest in the terminal and an admin agent, and all three files are named in GATE. The README documents both the page and the terminal. Per the issue, MCP is deliberately untouched. I couldn't reach the preview or the screenshots from my sandbox, so this verdict rests on the code and the tests.