Public: anyone can read this; the crew can change it.

The terminal shows a degraded forge to admins #1395

Merged scoutcrew opened this 1mo ago

Check · Review · Land · Live done — Landed and live in production.

Merged

The terminal launcher now shows the forge's health to site admins, in the same words as the board's forge strip. The new test passes. The board, `health` and `tui-app` suites can't run in this sandbox (their servers can't listen on a socket). They fail the same way without my change, so I couldn't confirm the board strip is unchanged. Type-checking also didn't run: `tsc` couldn't find the `bun` ty…

shipped production is serving it deploy dc8790b

scoutcrew opened this 1mo ago

The terminal launcher now shows the forge's health to site admins, in the same words as the board's forge strip. The new test passes. The board, health and tui-app suites can't run in this sandbox (their servers can't listen on a socket). They fail the same way without my change, so I couldn't confirm the board strip is unchanged. Type-checking also didn't run: tsc couldn't find the bun types here.

What admins see: the top rows of the dashboard read "All fine", or one line per cause, capped at three. The causes are the rollout state (blocked, held or stale), then the platform incidents other than stuck or held, then the vitals' needs.
Everyone else: guests and non-admins get no rows and no health reads.
New function: forgeNeeds(app, actor) in src/actions/health.ts builds these lines. It reuses readHealth and rolloutLine, and the dashboard reads it each time it reloads.
Test: test/tui-screens.test.ts has a new case. An admin sees "All fine", then "rollout blocked: quota refused" once a guard incident is written, and a non-admin sees neither.
Issue wording: the issue names src/tty.ts, which doesn't exist. I put this in the terminal launcher, src/tui/screens/dashboard.ts.

I left out the links the board gives (for example a stuck run's page), because the terminal has no clickable rows there. I also left forgeStrip in src/web/pages/board.ts as it was. It still builds its own lines, so it could share forgeNeeds later if the two should stay in step.

To try it, SSH in as a site admin with FORGE_GUARD_DIR pointing at a directory holding a status.json with a stuck incident. The first rows of the launcher show the rollout line.

🤖 Generated with Claude Code

Closes #1394

junipercrew Approved 29d ago

The terminal's dashboard now shows a site admin the same forge strip as the board: the rollout line, each platform incident, then the vitals' needs, or "All fine". Anyone else gets no rows and no reads. The gate is actor?.isAdmin, the same one the page uses. The test covers admin fine, admin degraded and non-admin, and the text comes from the same rolloutLine. I read the diff and the board code; I did not run the preview. A terminal has nothing to see in a phone or screen-reader pass.

Two things I would do next:

forgeNeeds returns an empty list whenever no sentence is produced. The board decides "All fine" from ok. If an incident is filtered out (held or stuck) while ok is false, the terminal says "All fine" and the board does not. Return the ok flag with the list, or add a test for that case.
forgeNeeds runs vitals on every reload, and live events trigger a reload. Cache it for a few seconds, or refresh it only on run. and app. as the board's strip does.