v2.14.0
·
40 commits
to main
since this release
Immutable
release. Only release title and notes can be modified.
Changed
- The frontier is bounded by the owner's result.
advancing-tracked-worktreats an open, unblocked item as takeable only when it lies on the path from live state to the requested result; an item beyond that destination is reported as takeable and deferred rather than resolved on the way. When nothing takeable reaches the result, the run stops with the human batch instead of filling the wait with enabling work the request did not name. Where the request names only the tracker, the result is recovered from the records' own parent outcome or the product brief. The always-loaded kernel states the same measure beside its continuation rule. campaign-directionrecovers the premise from the owner's request and the owner's recorded decisions, not from a parent record the run or an audit wrote. The sentence that let security, money, recovery, and operational work produce no evidence of the result is gone; that work names the obstacle to the stated result it removes, like any other. Deferring an off-path direction is an outcome beside keep, simplify, replace, and retire, and replacing the architecture of off-path work is named as not a response. When deferral would carry the result past an unsettled risk or rollout consequence, that consequence is the one product question. With no takeable unit that reaches the result, admission stops; spare capacity admits nothing.- The kernel extends the 2.13.1 provenance rule: a record's claim that something must precede the owner's result is a proposal on the same footing, and a record the run itself wrote carries only the authority of the request it served. A unit that must create a new prerequisite of its own before it can finish is a named trigger for
campaign-directionand a stream anomaly inexecution-health.
Evidence
- Two owner-run installed Codex campaigns on 2.13.0 spent a day each on enabling machinery. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it did exactly that, closing twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner, and nothing in the package made it say so or ask whether to go on. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted.
campaign-directionwas opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; the second shows the tracker-only request shape the package could not measure. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are indocs/evidence.md.- The transcripts show the per-lane rules of
execution-healthbeing applied in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, seedocs/decisions.md. - One matched isolated Claude Code pair on a five-minute fixture showed exact 2.13.1 and this package behaving the same: closing the items on the payment path, continuing past a human-gated item rather than stopping at it, marking audit-derived infrastructure as proposed, and putting the backups-before-money question to the owner as a risk choice. That is a non-regression receipt; the drift lives in day-long installed runs, so the improvement stays
UNVERIFIEDuntil the owner's next long campaign. Seedocs/evidence.md.