Build Log · October 22-23, 2026
Foreman gets the authority to match its accountability, and owners can ask for an update
Oct 22 late evening, after the earlier retro. Zeb picked items 4 and 10 from the outstanding list. Foreman now has full bounded recovery authority on MedinaCHF. Owners in MedinaCHF and all four canvas apps get an "Ask for an update" button on requests held up on ForgeKit's side, with one visible outcome. An independent audit found four real bugs before deploy.
- owner-loop
- foreman
- medinachf
- empty-canvas
- apps deployed with "Ask for an update" (MedinaCHF, canvas-1..4), each on 14717e44
- 5
- should-fix bugs the independent audit found before deploy, all fixed with tests
- 4
- requests currently held in any app, so no owner has pressed the button yet
- 0
- test:os commands passing in one full run (forgekit-os/command/test-evidence.json, commit 14717e44); the 2 failures were stale tests, fixed and passing when re-run on their own (the full suite was not re-run after)
- 137/139
apps deployed with "Ask for an update" (MedinaCHF, canvas-1..4), each on 14717e44
should-fix bugs the independent audit found before deploy, all fixed with tests
requests currently held in any app, so no owner has pressed the button yet
test:os commands passing in one full run (forgekit-os/command/test-evidence.json, commit 14717e44); the 2 failures were stale tests, fixed and passing when re-run on their own (the full suite was not re-run after)
Timeline
Oct 22 21:30
Witness corrections
The published retro overstated canvas-2/3/4 checks; database grants checked live and the retro corrected
Oct 22 22:00
Item 10, then full authority
fresh_dispatch granted on MedinaCHF; then Zeb: "the foreman has ultimate accountability" — full recovery authority
Oct 22 22:30
Item 4
Council: build it only with a visible outcome. Columns in five production DBs, dispatcher steps, buttons in five apps
Oct 23 01:30
Audit, fix, deploy
Audit: no blockers, four should-fix; fixed in 14717e44; five deploys; a real dispatcher run healthy on the new code
What shipped
forgekit-os/scripts/foreman/authority.mjs: MedinaCHF leaves the per-recipe allowlist and joins RECOVERY_LIVE_APPS (full bounded recovery, as the canvas apps). Acceptance and human-judgement reasons still escalate on every app; attempt and rebuild limits unchanged. Tests updated in foreman/tests/recovery.test.mjs, recovery-finding-shape.test.mjs, already-live.test.mjs; docs/command/foreman-role.md
forgekit-os/scripts/provision-update-request-columns.mjs: update_requested_at, update_handled_at, update_outcome on admin_intents (MedinaCHF) and requests (canvas-1..4), with column grants to each dispatcher role, re-checked from a fresh connection. Rehearsed on throwaway branches, then applied to all five production databases
forgekit-os/scripts/lib/update-asks.mjs + dispatch-owner-loop-requests.mjs: a pending ask makes Foreman's sweep due now; after the sweep each ask gets one outcome — moving, or needs_zeb with Zeb emailed first (left pending if the email fails). Only asks made before the sweep started are judged; a stale ask (30 min, sweep not running) goes to Zeb; Foreman's own reconcile-only child never settles asks; each app's own held rule
experiments/canvas-1..4: lib/actions/update-ask.ts (one-hour cooldown enforced in the UPDATE), components/UpdateAskControl.tsx, request-stage.ts helpers (isHeldUp, updateAskOf, canAskForUpdate), panels wired
products/medinaCHF: askForAdminIntentUpdate (org-fenced via requireCoordinator), the control in AdminIntentPanel.tsx in MedinaCHF's own style, and the panel polls while an ask is being checked
forgekit-os/scripts/tests/update-asks.test.mjs (14 tests), registered in test:os