Hard to bring down, not an Achilles heel: one place to manage, many places to fail; the forge's failure domains named and each one tested #2204

On the earlier failure: the check rejected #1202 because this branch's tests weren't registered in the gate's hand-kept list. Main has since dropped that list (#2037) and gates every test file, so that failure can't recur. Main had also moved 844 commits ahead and now holds its own versions of most of what this branch built: the failure-domain map in docs/DOMAINS.md and src/kernel/domains.ts (#1859), Settings → Resilience (#1853, #1975), and the drills (#2174, #2175).

So this branch first merges main and takes main's tree whole. That throws away the branch's earlier versions of the domain map, the Resilience page and screen, and the 23 empty sandbox files committed by mistake. The diff against main is now only the second commit:

• Snapshots on the forge's own volume: vitals() takes an optional snapshots: { dir?, mirrored }. If snapshots go to a directory on the same volume as the forge's data and no off-box mirror is set, it warns: "Snapshots are kept on the forge's own volume and mirrored nowhere…", with a link to Settings → Backups. This is the one shared failure point the forge can detect from inside (part 2 of the issue). Main only warned about a mirror once one was configured, so this case said nothing. The volume test is sharesVolume() in src/kernel/vitals.ts; for a path that doesn't exist yet it checks the nearest parent that does.
• Where the directory comes from: a snapshot store now reports its directory (Store.dir). A directory store sets it, the retry wrapper passes it through, and a bucket has none.
• One place builds vitals: the health answer, the board's forge strip and the asks each assembled vitals the same way in their own code. They now all call forgeVitals(app) in src/actions/health.ts. The degraded-history tick in src/main.ts keeps its own call but passes snapshotPlace(app). All four surfaces raise the new warning.
• Docs: docs/DOMAINS.md has a short "Shared by accident" section describing the check. The table's rows are unchanged.

I left out the edge's "the forge is restarting" page, the Resilience page served from the edge, and the rule that losing the runner never blocks a fix release. Those are #1194 and #1196. They already wait on #1148, so I didn't link them the other way, which would make a loop.

Tests: test/vitals-snapshots.test.ts covers the warning appearing, a mirror or a bucket clearing it, the parent-path fallback, telling two volumes apart, and dir passing through the retry wrapper. That file plus the vitals, health, domains, snapshot-store and gate-list suites pass, and the type check is clean except scripts/hollow.ts, which fails on main too. In a wider run of 42 board, asks, snapshot and resilience files, three tests (one in capacity, two in snapshot destination) fail the same way on main without this change: the sandbox blocks the loopback port they connect to.

To try it: on a forge whose Backups destination is a directory under FORGE_DATA and has no mirror set, the board's forge strip and /api/v1/health (as an admin) show the warning. Setting a mirror clears it.

🤖 Generated with Claude Code

Closes #1148

Vitals now warns when snapshots are written to a directory on the forge's own volume and no off-box mirror copies them, the one shared failure point the forge can detect today (part 2 of #1148). Every place that reads vitals now goes through one forgeVitals(app) in src/actions/health.ts, and the warning appears in all of them.

Review fixes in this round

• The 23 empty sandbox files are gone. They came in with commit 6958e869, made after my last run ended. They are now untracked, and their paths are added to .gitignore so a later run can't commit them again. The diff against main is 11 files: src, test, README, docs and .gitignore.
• The terminal shows the warning to an admin only. The dashboard was already reading it (forgeNeeds → readHealth → forgeVitals → needLine); now a test proves it. The new test in test/tui-screens.test.ts starts a forge whose snapshots go under its own data directory:

- the admin's dashboard shows the warning; - a non-admin's dashboard doesn't; - restarting the snapshot service with a mirror clears it.

With snapshotPlace deliberately broken, the test fails.

• README and DOMAINS.md: the README now lists everywhere the warning shows: the board's forge strip (linking Settings → Backups), the terminal dashboard, the asks, GET /api/v1/health and MCP health. It also says what clears it. docs/DOMAINS.md now states the st_dev limit: paths count as one volume only when they report the same device.

What changed overall

• vitals() takes an optional snapshots: { dir?, mirrored } and checks the volume with sharesVolume() in src/kernel/vitals.ts. For a path that doesn't exist yet, it checks the nearest parent that does.
• A snapshot store reports its directory (Store.dir). A directory store sets it, the retry wrapper passes it through, and a bucket has none.
• The health answer, the board's forge strip and the asks each built vitals the same way on their own; they now call forgeVitals. The degraded-history tick in src/main.ts passes snapshotPlace(app).

I left out the edge's "the forge is restarting" page, the Resilience page served from the edge, and the rule that losing the runner never blocks a fix release. Those are #1194 and #1196, which already wait on #1148.

Tests: test/vitals-snapshots.test.ts, the two terminal-health tests in test/tui-screens.test.ts, and the domains and gate-list suites pass. The type check is clean except for four errors in scripts/hollow.ts, which main has too. The "two volumes apart" test is skipped where /proc/self doesn't exist.

To try it: on a forge whose Backups destination is a directory under FORGE_DATA and has no mirror set, an admin sees the warning on the board, the terminal dashboard and /api/v1/health. Setting a mirror clears it.

🤖 Generated with Claude Code