Public: anyone can read this; the crew can change it.
The forge hunts its own faults: a sentinel reads what the forge already knows, names what is wrong with evidence, and proposes the mechanical fixes #1131
Two more of today's finds for the sentinel's first test set, both the same shape: a hand-installed emergency guard that outlived the fix it waited for and then refused the owner.
- An ingress route (
forge-looks-gate, priority 1000) that sent every look image under/trevato/(cs|cs-engine)/looks/to a busybox serving "This screenshot is not available." The forge has enforced look access itself since #727 and #738; the gate stayed, and the owner's pinned cs-engine card showed a question mark. Removed tonight (saved first). - The database triggers
steward_guard_repo,steward_guard_run,steward_guard_crewand the "paused for new accounts" one, from the emergency of 2026-10-05. The boot drop knew one of them; it drops the family now (trevato-apps/forge#21).
Still standing at the edge, for a person to decide: forge-signup-gate (blocks /signup entirely, although the owner asked for open, safe signup on the 5th), forge-outsider-gate (blocks POST /apps/new and crew or app settings for everyone outside a hand-kept list; the guard_new_accounts setting replaced it), forge-sw-retire (the service worker retire from #457), forge-old-host. The sentinel's rule for all of these: anything at the edge or in the database that is not in git is named on the board with its age, and a person nods or it goes.
Parked by the crew: the check stayed red through 2 automatic tries (pull #1197 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.
From the owner, 2026-10-12: "Hunting for these issues and being proactive about fixes is the kind of thing the forge should do well."
Today a person found, by hand, in one afternoon: a check runner whose cancelled runs kept their processes and held the only slot (#1106); a gate that had never been green in a cell because nested cells never answer (fixed upstream); a crew whose pushes could only ever succeed by leaving its sandbox (fixed upstream); a setting that painted the board red for a week (#1109); a hand-installed database guard from the 5th that still refused the forge's own admin from creating an app (fixed upstream). Every one of them left evidence the forge already had: the decision ledger, run logs, the check summaries, the vitals, the pod's own log,
sqlite_master. Nobody was reading it.Done looks like: the forge hunts its own faults, with a sentinel run on a schedule and on signal, that reads what the forge already knows and names what is wrong with evidence — and, when the fix is mechanical and reversible, proposes it as a pull.
sentinelagent is the natural owner; a run an hour, and one when the clock has been idle for an hour with work ready, or a check slot has been held by a finished run, or a setting is not its default for more than a day). It reads:GET /api/v1/healthand the vitals; the decision ledger (retry stopstreaks,guardparks, a direction at its cap); the last twenty run summaries and the check summaries; the pod's own log lines of level WARN and ERROR;sqlite_masterfor triggers the schema does not know; capacity settings away from their defaults.Files I expect:
src/crew/sentinel.ts(new),src/crew/autonomy.ts(the schedule and signals),src/kernel/vitals.ts,src/core/decisions.ts(read helpers),docs/CREW.md.