Skip to content

Release 0.3.0: Evidence to Action with verified work scopes and bounded handoff - #59

Open
abogun-product wants to merge 23 commits into
drevendev:masterfrom
abogun-product:release/0.3.0
Open

abogun-product wants to merge 23 commits into
drevendev:masterfrom
abogun-product:release/0.3.0

Conversation

@abogun-product

@abogun-product abogun-product commented Oct 2, 2026 •

Copy link
Copy Markdown

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.

drevendev and others added 19 commits September 25, 2026 20:51
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 andy-zen-dev left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 andy-zen-dev left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants