Release 2.14.0: bound the frontier by the owner's result

[mzored]

Summary

Two owner-run installed 2.13.0 campaigns spent a day each on enabling machinery after the product result had come to wait on the owner's own steps. In the first, campaign direction was opened three times and replaced the architecture each time; the 2.13.1 kernel reached its context mid-run and fifteen more hours followed on the same lineage.

• The frontier is bounded by the requested result: an unblocked item beyond it is reported as deferred, not resolved on the way. Runs still continue past a human gate with everything that reaches the result, and stop with one batch only when nothing takeable reaches it.
• campaign-direction recovers the premise from the owner's request and decisions, not from records the run or an audit wrote; the recovery exemption is gone; defer is an outcome; the one product question is the unsettled risk or rollout consequence of deferring.
• The kernel extends the 2.13.1 provenance rule to "must come first" claims and to the run's own records; a unit that spawns its own prerequisite is a named signal.

Numeric time bounds and one-item-per-session were refused again; see docs/decisions.md.

Verification

• scripts/check.py deterministic checks pass; git diff --check clean; Claude package validation and isolated install pass; Codex validator unavailable on this machine (UNVERIFIED).
• Three isolated Codex review rounds: seven qualifying findings, then one, then none. All fixed.
• One matched isolated Claude Code pair (exact 2.13.1 vs candidate) on a fixture with a human gate and audit-derived infrastructure: both continued past the gate, deferred the audit items, asked the backups-before-money question as a risk choice, and stopped with one batch. Non-regression only; the improvement stays UNVERIFIED until the owner's next long campaign.

🤖 Generated with Claude Code