RESET-2026 — triaging the four JARBUS v2 upgradesReview

Four JARBUS v2 upgrades are on the table and sixteen days of sabbatical remain — at most one gets built. Today's lesson is the triage: the criteria for picking, and why the evidence points at a scoped daily brief.

The four candidates, one breath each. Fail-loud contract: no automation may fail into a log file — failure fires a 🚨 Things task, and a placeholder artifact is never reported as a delivery. Declarative route registry: replace the 11 hardcoded intent handlers in route.py with a routes.yaml file, so adding a route is a data edit with a declared risk level and autonomy setting. Witness layer: STATUS.md, the ledgers, and project state become generated views over reporter.py's event stream (data/jarbus-events/*.jsonl), so the describing layer can never drift from reality again. Signal architecture: three channels — a deterministic daily brief (notify), a decisions-only push queue (question), and a weekly opportunity radar (review).

Triage on a bounded runway uses three questions. One: does it still pay off on Sep 15, when you're back at work and giving this system minutes a day instead of hours? Two: how much of it already exists — what fraction is a new build versus wiring up bricks already laid? Three: what does the audit's own sequencing law say? Its Phase 1 is signal BEFORE structure, with the stated reason that the brief is what keeps the operator engaged while everything else waits — losing sight of the system is the documented first domino of abandonment.

Scored that way, the field separates fast. Fail-loud is already half-shipped this month — the alert dedup ledger (commit d9b37fc, Jul 28's lesson) and plan-day's retry wrapper (a727e1b) were its first two bricks; finishing it is cleanup, not a fund-one pick. The routing registry is the biggest lift and the trap: it feels like 'real engineering' but only pays off in a future where v2 development continues. The full witness layer and the full three-channel architecture are each 2–3+ sessions. But ONE channel — the deterministic daily brief, generated from the event stream that reporter.py already writes — is a bounded build that doubles as witness-layer v0 and is precisely the re-onboarding surface your post-sabbatical self needs. That's the rec: fund the brief, scoped to one channel.

Worked example

Before picking, audit what's already landed toward each upgrade — the raw material changes the math:

git -C ~/Claude/PDB log --oneline --since='2026-07-24' | head -4
cat ~/Claude/PDB/data/alert-state.json
ls ~/Claude/PDB/data/jarbus-events/ | tail -3

• The recent commits show fail-loud's first bricks already shipped: d9b37fc (dedup + auto-resolve alert layer) and a727e1b (plan-day retry + watchdog wiring) — that upgrade is further along than the roadmap implies.
• alert-state.json is the live incident ledger from Jul 28's lesson — as of this morning it holds exactly one open incident (jobhunt-sweep, Jul 27). The fail-loud pattern demonstrably works.
• jarbus-events/*.jsonl is the event stream reporter.py has been writing all along. Both the witness layer AND the daily brief are 'generated views' over this same data — which is why one scoped brief buys you a piece of both upgrades at once.

Gotchas

• 'At most one' is the constraint that makes the exercise real — picking two with sixteen days left is picking zero.
• A scoped daily brief is NOT the full three-channel architecture. Cutting to one channel (no push queue, no radar) is exactly what makes it fundable before Aug 15 — resist scope creep back toward the full spec.
• The routing registry will keep whispering that it's the 'real' engineering work. It only compounds if JARBUS v2 development continues after the sabbatical — which is precisely the assumption you can't verify from here.
• Don't confuse fail-loud's momentum for a reason to pick it — momentum means it's finishing itself as cleanup. Fund the thing that WON'T happen without a deliberate decision.