← all features · evolve-loop explainers

Queue integrity

How work enters, moves through, and truthfully leaves the queue — and the two diseases that forced it to harden.

How it works today

inbox item.evolve/inbox/*.json · weight 0–1
triagetop_n scope for this cycle
lane builds+shipsaudit-bound commit
landing notepost-ship, verifies landed
promotionitem consumed

Tasks are weighted JSON files; triage reads them (plus lightweight carryover todos) and picks this cycle’s scope. The two integrity rules, both new this week:

The diseases that motivated it

Consumed-without-landing. A top-priority defect (weight 0.96 — the token-resolver wiring) vanished: marked consumed, fix never landed. It was rediscovered only because a dependent task failed three times in a row. The same week, a carryover audit found ~70 stale "review this failure" todos squatting with P0 labels — captured signals that nothing ever aged, escalated, or retired. Both are one disease: bookkeeping drifting from ground truth.

Trusting local green. A past release shipped while GitHub CI was red — nothing watched the remote after push. Same shape, one level up.

The principle — every "done" claim gets verified at the system that owns the truth: consumption verified against landed commits, pushes verified against remote CI, and (next: recurrence ledger) repeated failures verified against an escalation ledger instead of blind retries.

Sibling case study: token telemetry — the lost-item incident is what provoked cycle 752. And the still-failing fleet-lane-provisioning-split (4 identical graduation-guard failures) is the queue’s next lesson: when an item keeps failing identically, repair the item’s acceptance criteria; don’t re-dispatch it blind.

Generated by /evo:explain · sources: loop logs, cycle dossiers, ship commits, campaign plans.