Security: the terminal deletes any match with no identity check, a power the page never exposes #40

src/tty.ts (~97–99): same as cs — any ssh session deletes any match; the web exposes no delete. Gate it to an admin (FORGE_APP_USER_ROLE) through one shared action, or remove it, and test that a guest terminal session cannot delete. Also src/server.test.ts (~175), the cross-site POST refusal test, times out one run in three; make it deterministic (no real timers, no network race) so the gate's test is trusted.

API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN) (api_error)

API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN) (api_error)

Read the park: it was an outage, not the work. The run ended without a pull because the provider's weekly limit reset or the API could not be reached — nothing was tried and found wanting, and no pull was opened on it.

So this issue stands exactly as written: it is not parked in the sense of "could not be finished as specified", and the next run should take it unchanged. Nothing here needs splitting or a new definition of done.

Re-read and rewritten on (1,239 tests green). Parked on Sep 20 by a DNS failure, not by the work — nothing was attempted, and the hole is still open, but it is wider than the body above says.

What is true today: takes from and calls or — there are two tables to destroy rows in now, not one — with no check of who is at the terminal beyond the ssh login the forge granted, while the page exposes no delete at all and the server has no route that would.

What done looks like now, replacing the checklist above where they differ:

• [ ] Both deletes are covered by the same rule, and alike: whatever identity the terminal decides on, obeys it in both tables and the note under the table says why a refusal was a refusal.
• [ ] The rule is stated where the app's other secrets are: an operator's value read from the environment at start-up, never in the repository, and a session that has not proved it gets a read-only terminal rather than a broken one.
• [ ] A terminal with no key configured is the honest case and the common one: say in the pull what it does — read-only, or a printed one-time token in the run log the way describes for a first sign-in — and make it one sentence on screen either way.
• [ ] drives both: a session without the proof presses on a standings row and on a runs row and both rows survive, with the note a person would read; a session with it deletes both.
• [ ] The README's terminal line says what a person needs before does anything.

Everything else in the body above still stands.

(A planner comment landed on this issue a minute ago with its backticked paths eaten by a shell. This is that comment, whole; ignore the mangled one.)

Re-read and rewritten on d2c980a (1,239 tests green). Parked on Sep 20 by a DNS failure, not by the work — nothing was attempted, and the hole is still open, but it is wider than the body above says.

What is true today: src/tty.ts:141-145 takes x from src/terminal/keys.ts and calls deleteMatch or deleteRun — there are two tables to destroy rows in now, not one — with no check of who is at the terminal beyond the ssh login the forge granted, while the page exposes no delete at all.

What done looks like now, replacing the checklist above where they differ:

• [ ] Both deletes obey one rule, match and run alike, and the note under the table says why a refusal was a refusal.
• [ ] The rule is stated where the app's other secrets are: an operator's value read from the environment at start-up, never in the repository, and a session that has not proved it gets a read-only terminal rather than a broken one.
• [ ] A terminal with no key configured is the common case: say in the pull what it does — read-only, or a one-time token printed to the run log the way AGENTS.md describes for a first sign-in — and make it one sentence on screen either way.
• [ ] src/tty.test.ts drives both: a session without the proof presses x on a standings row and on a runs row and both survive, with the note a person would read; a session with it deletes both.
• [ ] The README's terminal line says what a person needs before x does anything.

Everything else in the body above still stands.