Skip to content

v2.14.0

Choose a tag to compare

@github-actions github-actions released this 01 Sep 23:04
· 40 commits to main since this release
Immutable release. Only release title and notes can be modified.
ea786a8

Changed

  • The frontier is bounded by the owner's result. advancing-tracked-work treats 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-direction recovers 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-direction and a stream anomaly in execution-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-direction was 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 in docs/evidence.md.
  • The transcripts show the per-lane rules of execution-health being applied in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see docs/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 UNVERIFIED until the owner's next long campaign. See docs/evidence.md.