§1 — Why this exists

The gating reflex being hardened here was developed in imas-ambix, where a plan declares an evidence-gate table of measure against required evidence before the work starts, downstream work stays visibly closed when a gate fails, and negative results stay on the page. Today that reflex is prose: nothing but discipline enforces it, and nothing else can read it.

Making it first-class state repairs a measured defect at the same time. Reckon derives a plan's blocked state — blocking comes from unresolved dependencies and effective_status projects it over the persisted workflow status — but the projection is one-way. It can add blocked and never remove a stale one:

effective_status('blocked', [])        -> 'blocked'   # never clears
effective_status('active',  [{...}])   -> 'blocked'   # correctly derived
effective_status('active',  [])        -> 'active'

A plan authored plan-status="blocked" therefore reads blocked forever after every blocker clears. roadmap already detects this as orphaned-blocked-status — the system knows the state has rotted and files a report instead of resolving it.

The same defect class exists in sprint items, where it contradicts an explicit written contract. references/sprint-orchestration.md §8 states that item lifecycle status and implementation fraction are derived from plan HTML and must never be persisted in the sprint — yet index.json carries a persisted per-item status, and it is already stale: distributed-sprint-state reads pending while its plan is shipped. roadmap derives the correct rollup, so only consumers of the raw index are misled — which includes any agent reading project state directly.

Reviewing the surface for this defect class found four further instances, so this plan's scope is one idea applied six times: state that can be computed must not also be stored. Persisted blocked status, persisted sprint-item status, hand-set sprint activation guarded by a single-session invariant, plan runnability as an authoring default with no decay alarm, and staleness that is detected but never reaches the agent doing the work. The gate mechanism leads because a gate is a declared blocker, so it reuses the derivation the others are being moved onto.

§2 — Deliverables

The gate element. A <section data-reckon="gates"> whose <div class="r-gate"> children carry a stable id, the section they anchor to, the sections they gate, status, the measure, the required evidence, the verdict and an evidence link. Parser, schema, renderer and round-trip parity follow the pattern already established for decisions and followups — including the derived-status discipline that a gate's passed state is computed from its verdict rather than stored twice.

Write ops. edit_plan gains gate to declare one and pass/fail to record a verdict with evidence. A pass with gates.require_evidence in force and no recorded measure is rejected, not warned — a gate that can pass without evidence is not a gate.

Derivation wiring. An unpassed gate becomes a row in blocking, flowing through the existing effective_status path. A failed gate therefore renders downstream sections and plans blocked automatically, and passing it unblocks them automatically, with no status edit anywhere.

Blocked becomes derived-only. Remove blocked from the persistable status set and reject it on write, matching reckon's established reject-write-warn-doctor posture. Fix effective_status so a legacy persisted blocked resolves to its underlying open state before the projection is applied, which turns the one-way defect into a two-way derivation. Persisted sprint-item status goes the same way — derived from plan HTML on read, rejected on write.

Server rendering. The server renders gates on the plan page and surfaces a gate column in sprint view, so a closed gate is visible without reading prose. This touches only server and SPA files and conflicts with nothing.

Swap the skill's gate enforcement — do not re-author the rule. The gate-fence rule itself is owned by uniform-worker-dispatch, which authors it in reckon-ship/SKILL.md with enforcement by reading the plan's prose evidence-gate table. This plan changes only the mechanism: enforcement moves to computed gate state, and gates.enforce from flight config selects strict refusal or a warning. Two consequences bind. The rule's wording is not this plan's to rewrite. And because SKILL.md is a shared file, this slice is a separate node that must not be dispatched until the owning plan's changes are integrated — everything else here touches only reckon/ and the SPA and may run concurrently. Split the node at that file boundary rather than serialising the whole plan; the file-conflict edge belongs in the execution graph, which the sprint contract already requires for shared files.

The portfolio sweep. Once the pattern exists, sweep every mounted project: migrate each persisted plan-status="blocked" to a recorded blocker or gate, drop persisted sprint-item status, and repair the error-level wiring findings the portfolio scan reported — 82 findings of which 17 are error-level, 69 of them in imas-efit alone, including two dependency cycles and three inactive-hard-dependency errors. Twelve live plans still persist blocked and forty-six sprint items still persist a status. This is a review-and-cleanup job, not an implementation one: each repair is a plan-state edit through the owning skill, re-scanned after. A finding that needs a material decision is reported, not guessed. Cross-repository edits stay in their owning checkout.

Sprint activation becomes derived. Today a sprint's active status is hand-set and guarded by an invariant that raises when a second sprint is activated, enforced under a lock. That is a single-session assumption: with detached worktrees, per-node exclusive write scopes and independent orchestrators, concurrent sprints are the intended mode of operation, and the invariant forbids expressing it — a plan with no dependencies cannot run alongside another sprint's last item purely because of a presentational pointer. Drop the uniqueness constraint and derive the default focus as the earliest sprint in order holding incomplete items. The consuming views already degrade gracefully through fallback chains, so they need a default rather than a maintained one. Two consequences follow: the pointer can never be stale, and starting a sprint ceases to be an operation at all.

Plan runnability becomes derived plus alarmed. A plan is excluded from runnable work by its authoring status, which does one genuinely valuable job — separating written-down from authorised-to-act-on, which becomes safety-relevant once an orchestrator can fan out unattended workers. But it is an authoring default with no decay alarm, and it has rotted: of the eleven authored-but-unauthorised plans across the portfolio, one has sat sixty-four days, and five report no age at all because they carry no recorded modification date — the alarm falls silent on exactly the documents most likely to have decayed. Split the concept. Derive the well-formedness half — a plan is dispatchable when it declares at least one gate and carries an open followup, which lifts the node-level task-definition contract to plan level and is checkable rather than asserted. Keep the authorisation half as a deliberate act, but report it: an authored-but-unauthorised plan surfaces with its age, so a months-old draft with locked decisions cannot sit silent.

Staleness becomes visible to the agent doing the work. Detection already exists — reckon audit flags plans active beyond thirty days with incomplete implementation, research beyond sixty days that never closed, and completed plans with no implementation fraction — and plan-modified is server-stamped on every write. The gap is that none of it reaches an agent reading the plan, so a worker can begin on a plan idle for three months with no signal that its assumptions may have expired. Surface derived age and the staleness verdict on the plan read payload, using the thresholds the audit already defines rather than inventing second ones. This is advisory, never blocking: a stale plan is a prompt to re-read its assumptions, not a refusal to work.

Migrate this sprint's own gates. The seven plans of sprints S7 to S9 author their gates in ambix's prose form because the element did not yet exist. Converting them to the new element is this plan's first dogfood and proves the migration path on real documents.

§4 — Constraints

Legacy documents carrying persisted blocked or item status must still read successfully with a compatibility diagnostic. Rejection applies to writes only; a read-side hard failure would strand every unmigrated project in the portfolio.

The sweep never rebalances a sprint, retires a plan, or resolves a decision to make a finding disappear. It migrates state representation and repairs mis-wired relationships. A finding whose repair requires a material judgement is reported for the owning project.

§5 — The sweep, sized and stalled on a dispatch gap

The sweep was scoped against a live scan rather than the plan's original figures, and the inventory below is what remains. It is recorded here so the next session inherits the survey instead of repeating it.

The obstacle is not the work. reckon crew dispatch --repo <other> resolves the node's plan inside the repository it is dispatched into and refuses with plan-unavailable, so a node serving a plan in one repository cannot edit another — which is every part of this sweep but the first row. The fallback of aiming write paths at a foreign checkout is worse than the gap, because it puts a worker outside the worktree that bounds its blast radius. The capability belongs to the orchestration plan and is recorded there; the sweep-complete gate stays closed until it lands.

Of the sixteen error-level findings in imas-efit, only the eight non-executable-hard-dependency edges are in this plan's remit. The remaining eight — two dependency cycles, three inactive dependencies on superseded or archived plans, and three sprint-order inversions — need material judgement or a sprint rebalance, both of which §4 forbids the sweep from doing. They are residue to report to their owning project, not work to guess at.

§6 — Migrating an authored table has no op

Both the worker migrating the routing plans and this session's own edit of this document hit the same wall: edit_plan can declare a gate and record its verdict, but nothing removes the prose table those gates replace. Text mode refuses to touch data-reckon regions and the gate ops only append, so the migration step that the plan calls its dogfood is the one step with no sanctioned path — every migration so far has gone through raw HTML editing inside a worktree, announced as a bypass.

This is the plan's own mechanism, so it belongs here rather than in a followup. The gate ops need a companion that retires the authored prose a gate section supersedes, so migrating a document is a state write like every other.

/reckon-ship derived-gate-state

/reckon-ship derived-gate-state

/reckon-ship derived-gate-state

/reckon-ship derived-gate-state

/reckon-ship derived-gate-state