Repository navigation
Release 0.3.0: Evidence to Action with verified work scopes and bounded handoff - #59
abogun-product wants to merge 23 commits into
Conversation
The Hungry Crab run of 2026-09-25 against pypa/build left its configuration (.crab.yml, all defaults) and its ledger (.crab/ledger.json: one meal, eighteen nutrients, two of them served as drevendev#36 and drevendev#37) in the working tree, from where a roadmap commit of the 0.1.9 release branch swept them in by accident. They were taken back out of that branch; this commit offers them on their own, byte for byte, because the configuration says the ledger is committed (ledger: repo) and without it the next run would propose the same eighteen nutrients again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…versions Direction becomes direction.bands.v2 and carries both accepted repairs in one rule move. Linkage is state-neutral (PV-REV-DIRECTION-CLOSED-TARGET-001): a change request linked to a declared target stays linked when the target closes, which repairs calibration finding 9, where closing A1 and B6 took the linked count from 2 of 6 to 0. The open-target count is still derived, for presentation only. Every active change request is LINKED, UNLINKED or UNRESOLVED (PV-DIRECTION-INCOMPLETE-001): a reference a complete register lacks is a broken reference and unlinked, with DIRECTION_TARGET_REFERENCE_MISSING; a reference nobody could resolve, or a title, body or milestone of the wrong type, is unresolved. Over L + U + R = N the completion set k in L..L+R is mapped through the unchanged predicates: one reachable band is DEGRADED / band / EXACT, several are UNKNOWN. Unreadable linkage evidence therefore no longer fails the whole project; LinkageEvidenceError is gone, and the record names what it could not read in linkage_unresolved. Horizon becomes horizon.bands.v2 (PV-HORIZON-PARTIAL-001). A partial target enumeration that returned a target proves the capability; its counts are observed-subset lower bounds, and only PH3, an open target already beyond the frame, forces a band: DEGRADED / EXTENDED / EXACT. PH0 to PH2 stay UNKNOWN, because Horizon declares no order to pick a representative by. Debt becomes debt.bands.v2 (PV-DEBT-PARTIAL-001). A partial register with a confirmed open item is DEGRADED / PRESENT / EXACT, one without is UNKNOWN, and, as issue drevendev#39 asked for Debt, a PARTIAL count is read as a lower bound only with its OBSERVED_SUBSET_COUNT proof. The target marker is a standalone token now (PV-AUDIT-TARGET-MARKER-SYNTAX-001): SubTarget: B1 and PreTarget:B1 link nothing. Counts that contradict each other (L + U + R != N, beyond > future > open) are InadmissibleEvidence, refused before classification and reported by the command line as an input error. The vector format learns two things the new families need: given.derive runs the derivation over stated inventories, so a case about how a change request becomes linked is executed where that happens, and expect.rejected states a refusal (HOR-PARTIAL-15). DIR-CLOSED-01..09, DIR-INCOMPLETE-01..16, HOR-PARTIAL-01..16 and DEBT-PARTIAL-01..16 are executable vectors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Integrity history was reconstructed from whatever the provider still showed, so a failure hidden behind a passing re-run on a parent-level surface, or dropped by retention, left the counts as if it had never happened. The accepted contract, PV-HIST-002 (PV-REV-HIST-002), makes history durable. The carrier is the union of every attempt observed per parent per revision. A build now reads its immediate predecessor, the bundle the comparison already resolved, and adds that union as ci.revision_history_carried before evaluating; Integrity merges it with the provider's current parents and emits the result as derived.revision_history in the snapshot, on every path, UNKNOWN ones included, so history also crosses a bundle whose verification evidence could not be read. A missing, unverifiable, foreign or later predecessor is a gap that says so (REVISION_HISTORY_GAP); nothing older is ever carried in its place. verify checks that the source a bundle names is the bundle its manifest follows, and a build refuses observations that already carry history from somewhere else. The state of a revision is a function of its union: an observed failure is FAILURE_OBSERVED on any surface and stays; favorable evidence proves PASS_ONLY_OBSERVED only when every attempt of every parent is observed, so a check-suite pass, or a run whose earlier attempts are not all known, is UNKNOWN_HISTORY (R52), which makes the Vital UNKNOWN, because T9 puts unknown history above every conservative branch. A current verdict is never carried. The first 0.2.0 bundle of a project replays the revision records of its 0.1.9 predecessor (lineage devostasis.ci-history.v1) instead of starting empty. On the stored corpus every active revision is attempt-complete, so no fleet project loses its band to R52; all 326 stored bundle directories still verify. The rule moves to integrity.bands.v1+ci-unit-004+hist-002; the band table and the 0.1.9 judgements are unchanged. HIST-01..07, -09..11, -13, -15, -16 and -19 are vectors, HIST-08, -12, -17, -18 and -20 store tests; HIST-14 has no accepted migration to execute. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ligation PV-REV-TEST-004 accepted the final T9 reconciliation (PV-TEST-004, generator PV-T9-GEN-003) with zero CONTRACT_GAP terminals: each of the nine gap identifiers PV-T9-GEN-002 exposed maps to one deterministic obligation, and higher-precedence fail-closed conditions stay higher. With the Direction, Horizon and Debt repairs of this release every obligation T9 consumes is implemented, so T9 can be adopted. The implementation side of it is a finite generator: the acquisition tokens (CF, POS_ABSENT, PARTIAL, UNAVAILABLE, FORBIDDEN, UNKNOWN, ERROR, STALE) crossed with the regions each family names, about 1,270 cells, each evaluated and held to the accepted table: Horizon PH0..PH3, Clutter's confirmed floors, Direction's completion set and per-reference resolution, Integrity's unresolved, partial and unconfigured-recent regions, Debt's PD0 and PD1, and unknown history above every conservative branch. The oracles restate the accepted table rather than calling the evaluators. The T9v2 cell-key serialization remains the research process's to deliver as vectors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The live run against a copy of the fleet store showed two costs the tests could not. The first 0.2.0 bundle of trade_simulation carried its 0.1.9 predecessor's whole revision series, about a megabyte, although every record in it had aged out of the 14-day window and would be dropped on arrival. And its snapshot grew from 12 KB to 393 KB, because 834 workflow_dispatch runs in two weeks attach to a handful of revisions and the carrier wrote each run as its own object. The carried observation now holds only in-window records, and a replayed 0.1.x record only the fields replay reads (revision, time and every parent's identity, kind and attempts). The carrier stores parents grouped by shape (kind, greatest attempt, observed attempts) with their ids, which is lossless: every parent keeps its identity and its own attempts, and a parent listed in two groups is corrupt history. On the same evidence the snapshot is 91 KB. Which of those runs should count as verification at all is the question issue drevendev#40 already asks the research side. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Version 0.2.0, the pins that name it, the example bundle regenerated under the four new rule versions (its change-request records now in the shape the adapter writes, one merged change linked to the closed release it delivered, so the example shows the state-neutral linkage: 6 of 10 linked where the open-target count says 5), and the changelog section. The roadmap moves B3 to done, the Direction, Horizon, Debt and T9 judgements to adopted, finding 9 to judged, and the count of named cases without a test from 63 to 62. It also says plainly that 0.2.0 ships before the condition it had set for 0.2 (Phase B closed, an outside consumer, no unadopted research): the owner asked for a large release (drevendev#47), and this is the part of it that rests on accepted contracts, so B7 and the Phase C contracts become the bar for 0.3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… on it Durable history is keyed by immutable revision identity, and the new union code read the revision of every record directly, so a hand-written record without one ended the evaluation with a KeyError. A record that names no revision can be neither counted nor carried: it is now REVISION_RECORD_INCONSISTENT, the same defect as a contribution that contradicts its own history, and the Vital is UNKNOWN. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
B3, durable revision history, is delivered by this release. v0.2 described the condition the roadmap had set for 0.2 (phases A and B closed, an outside consumer, no unadopted research); 0.2.0 ships before it at the owner's request, so the release target closes and the condition moves to a new target, v0.3, as the roadmap now says. Ids are never reused. The pull requests that advanced B3 stay linked after it closes: that is the state-neutral linkage of direction.bands.v2, and this repository is its first beneficiary. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
andy-zen-dev
left a comment
There was a problem hiding this comment.
Merge-blocking recheck defect on this exact head: planner emits recovery items with sources like recovery:change:<id>/checks, recovery:changes, recovery:issues, and recovery:inventory, but workscope.collect(..., selected=item) only refreshes direct sources beginning with change: or issue:. A recovery recheck can therefore return empty COMPLETE inventories without rereading the missing source; replanning then drops the recovery item and CLI reports INVALIDATED as if evidence recovered. This violates the documented work recheck contract (“reads only the selected source, correlated implementations and dependencies”) and the unknown-is-not-zero invariant. Please bind each recovery item to its underlying refresh target and make selected collection perform that bounded refresh. Add regressions where the source remains PARTIAL/UNAVAILABLE and the recovery item must persist, plus a case where a real COMPLETE refresh resolves it.
andy-zen-dev
left a comment
There was a problem hiding this comment.
Bounded inherited-history/release review at a41fac6, not whole-PR approval of the 100-file cumulative release.
Confirmed the actual _carried_records source at this head is blob e7c871965c2f783ae6991d6d2c6d20596e81daa7, including all three or [] conversions described in #83. Thus the concrete persisted-history defect remains in 0.3 even though the new current-inventory/attempt repairs are present. Invalid supplied arrays can be interpreted as empty evidence. The shared repair diff was reviewed on #57 and the affected reader was re-read here; do not apply the old pre-b849923 inventory patch stack over it.
Please propagate the narrow #83 array-type repair, with malformed v1/v2 cases and valid historical compatibility controls, to this candidate before release. Preserve revision-bound work evidence and the explicit gap for exact-head GitLab approval (#58); a queue suggestion does not grant merge authority.
The documented #57 → #53 → #59 dependency remains open, and #57 now has a fresh changes-requested verdict. Require exact-final-head checks and independent work-scope acceptance before a master release merge/tag. Fork CI in this PR's narrative is not a local test execution in this review; full local suite/replay is NOT_RUN. No merge, tag or issue closure was performed.
Repository evidence can now produce five deterministic bounded queues: review, finish_merge, implement_issue, research and analyze_code. The 0.3 work companion supplies revision-bound findings, GitHub/GitLab collection, immutable replayable scope history, bounded role slices and read-only live recheck. Missing capabilities remain explicit; proposed work grants no execution/merge/deploy authority.
Target: E1
Current/saved CI inventory now admits every row before proving branch departure, refuses duplicate revision identities, preserves an already-known commit instant, and retains carried failures through malformed generations. Attempt coverage checks exact observed identities without allocating by an untrusted maximum; UNKNOWN remains uncertain, foreign vocabulary is refused, and legitimate same-attempt transitions remain valid. Activity shares admission and exposes rejected inputs. Current revision metadata stays bound to the reconciled history.
These enforce existing accepted admission/history obligations. Rule ids, thresholds, windows, canonical contract identifiers and historical artifact bytes are preserved. No new external-check semantics or migration is introduced.
Validation: complete Python 3.12/3.13/3.14 CI passed on exact head
a41fac6353030f684b2e77b12079503b7b8a1e96: full unit/conformance suite, 148 CLI vectors, example verification and the replay/determinism checks declared by this release's workflow. The common repair was additionally exercised on the actual 0.2 source tree through real ObservationSet/evaluator/HistoryStore/bundle tests and CLI vectors. No independent acceptance is inferred from CI.Carries the pending earlier release ancestry and the corrected #57 history path. Preserve release-only master and the prepared #57 → #53 → #59 → #64 → #69 → #75 sequence, with independent review/checks on each final head. Sustained B7 adoption, remaining B1 cases, core GitLab/Instrument gates and exact-head GitLab approvals (#58) remain open. No tag or production activation is created here.