Keep legacy observations captured until typed acceptance semantics exist - #388
Conversation
Prepare Delivery387 Phase A for one pre-emission eligibility boundary. Disclose direct/queued acceptance and observation correction restrictions while preserving capture, immutable history, rejection and contest. Runtime implementation awaits the new same-task semantic decision.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #388 — Phase A review
Verdict: no demonstrated in-scope blockers. The proposal is ready for the semantic-decision step, not runtime approval or merge.
Reviewed head: 7ba5b8809ad849c5b601dc0cbcf91a92c2dd0c42, against base 9d7541d96bc708e9270b986927d7f4b8a035454f. The reviewed diff adds one 226-line RFC; runtime code and tests are unchanged. The branch remained at that head when the review checks finished. This review applies only to that exact head.
Design assessment
The broader restriction is justified and explicitly disclosed. This does more than fix inconsistent observation self-review: it disables all new observation acceptance, including acceptance by an independent reviewer. That matches #179’s requirement to keep observation promotion disabled until typed semantics exist. The RFC also explicitly narrows the earlier correction decision’s C03/C10 guarantees rather than silently discarding their observation tests.
The practical cost is material: observations remain captures, and an already-disputed observation cannot obtain an accepted correction successor until a later decision reopens that path. This is an intentional capability withdrawal requiring the task user’s decision—not merely an implementation cleanup.
Sources: proposed RFC, prior correction matrix.
The proposed guard is at the correct shared point. ReviewPromotionGate.run controls both direct promotion and queued acceptance. Placing the eligibility check before those emitters can block both paths without changing transaction ownership. For queued acceptance, using the already-validated stored assertion type avoids trusting a caller-supplied type. Restricting that branch to ACCEPT also avoids accidentally blocking rejection or treating a contested consequence as an assertion.
Sources: review/promotion gate, queue validation.
Capture and correction intent can remain inert. The existing pending emitter creates a PENDING_REVIEW assertion and, where applicable, a LINEAGE_SUPERSEDES_INTENT edge. It does not perform acceptance or effective retirement. Reusing it is a narrower and more coherent change than introducing another state, emitter, or policy framework.
Source: pending emitter.
Keeping the existing maps is warranted. They still participate in requested-target validation, scope checks, durable-evidence checks, and correction provenance. Deleting observation entries would change more than acceptance eligibility and could remove checks that retained captures still need.
Sources: validators, durable-evidence checks.
Implementation proof that remains essential
The RFC already requires the right behavioral checks. These are the most important to enforce during implementation review; they are not new design blockers or scope additions:
- Same-claim lifecycle: failed self-acceptance and failed independent acceptance must leave the observation unconsumed, followed by exactly one lawful independent rejection. Checking only response outcomes would miss an accidentally emitted review edge.
- Real historical state: seed accepted observations and pending corrections using the unmodified base, then run candidate code against the retained database. Prove unchanged historical records and predecessors—not just absence of a new consequence in the response.
- Preserved controls: retain earlier authority, evidence, target, bundle, and terminal-state refusals, alongside positive operation, bounded-structure, and independently reviewed compliance paths. Do not obtain a green suite by removing observation members from hostile correction matrices.
Source: O01–O07 and fixture requirements.
One concrete detail matters for the history probe: reusing an idempotency key is not sufficient for matching replay. Tenant, runtime bundle, and source digest must match. Also, /review/accept generates a new decisionTime on every request; the existing correction tests deliberately replay a stable governance submission through /commit instead. The new history test should preserve that distinction rather than weaken replay checks or freeze candidate behavior artificially.
Sources: ReplayWriter, existing correction-test replay helper.
Verification limits
I inspected the diff, linked requirements, relevant runtime paths, and existing correction-test helpers. GitHub’s lightweight workflow was green at the reviewed head, but I did not run local checks or database tests, and no runtime implementation of this proposal exists at that head. The RFC correctly labels its candidate results as planned rather than executed evidence.
No design changes requested before presenting the semantic decision. This is a Phase A design review only: it supplies no semantic approval, runtime implementation approval, baseline admission, production authorization, or merge authorization.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #388 — bounded Phase A design review (independent)
Reviewed head: 7ba5b8809ad849c5b601dc0cbcf91a92c2dd0c42 (tree 7a5a80a2d91df4551dbcf9ee1a7b9ed0c638e557).
Base: 9d7541d96bc708e9270b986927d7f4b8a035454f.
Delivery #387, under #180; eligibility limit selected from #179.
Decision OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 version 1.
Verdict: 1 Blocker, 1 Follow-up, 2 Preferences.
This is an independent review at the same head as the author's own bounded Phase A
review (reproduced in the PR body, verdict "zero demonstrated in-scope Blockers").
It is not semantic approval, implementation evidence, a GitHub approval, or merge
authorization. Everything below was measured; nothing was taken from the PR prose.
What this review adds over the author's pass
The author's review is source-inspection only and says so. I ran the design. I
built the smallest guard the RFC describes, applied it to the real kernel/stages.py
at this base, and executed the real HTTP commit and review routes and 14 existing
suites against live PostgreSQL, plus a two-phase retained-database history probe on
base bytes followed by candidate bytes. That is what produced the Blocker: it is a
test-contract contradiction that is invisible from the RFC text and only appears
when the proposed guard is actually applied and the existing suite is run.
I confirm every one of the author's structural claims and every line anchor it
cites. I disagree with its verdict.
Identity of the reviewed content
$ git diff --name-only 9d7541d9...7ba5b880
docs/rfcs/OFARM_Legacy_Observation_Eligibility_RFC_v0_1.md
$ git diff --stat 9d7541d9...7ba5b880
1 file changed, 226 insertions(+)
$ git show 7ba5b880:docs/rfcs/OFARM_Legacy_Observation_Eligibility_RFC_v0_1.md | wc -lc
226 16497
$ git show 7ba5b880:… | sha256sum
470ae54d3d9950a3764a203c2dfeafa0d6b9b841a63350a06e3a03aaea8c8c13
$ git rev-parse 7ba5b880:docs/rfcs/OFARM_Legacy_Observation_Eligibility_RFC_v0_1.md
45cbf4dfe0d275087aef4cce3dca38e0318caa24
$ git diff --check 7ba5b880^ 7ba5b880 # clean
One file, 226 added lines, zero deletions, runtime tree unchanged from base. The
PR body's tree digests 7a5a80a2… (candidate) and the one-file boundary both hold.
I did not have a copy of the author's full report, so its stated SHA-256
6dcaeee8… is unverified here.
Environment and its limits, stated once
CPython 3.11.15, PostgreSQL 16.13, unpinned wheels, x86_64 Linux container.
The RFC requires CPython 3.12.13 for the mandatory package/architecture/temporal
gates and PostgreSQL 17.10 for implementation evidence. I ran neither pin, so:
- the mandatory package/architecture/temporal checks and their claimed 8.596 s
zero-failure run are not re-verified here; - hosted run 34775487544
is not re-verified —api.github.comreturns 403 from this container (the
per-repo egress gate), and the device route that had API access dropped mid-session; - posted reviews on #388 were not enumerated for the same reason. Treat the
author's inline report as the only prior pass I saw.
Everything I do assert below ran to completion and is shown with its output.
Reproducing the RFC's claimed base defect
The RFC opens with a claim about running code. It reproduces exactly, over the real
POST /commit route with a real Store, demo.FARMER holding both
OBSERVE_CREATE_OBSERVATION and REVIEW_ACCEPT, real durable evidence
(demo.PHOTO_EVIDENCE):
direct OBSERVATION_ASSERTION, confirmAccept: true |
base outcome |
|---|---|
reviewerPartyRef omitted |
PROMOTE_ACCEPTED — 1 assertion, 1 review, 1 consequence |
reviewerPartyRef: null |
PROMOTE_ACCEPTED — 1 assertion, 1 review, 1 consequence |
reviewerPartyRef: demo.FARMER (self) |
PROMOTE_ACCEPTED — 1 assertion, 1 review, 1 consequence |
reviewerPartyRef: demo.ADVISOR (distinct) |
REQUIRE_REVIEW, HUMAN_APPROVAL_REQUIRED |
confirmation omitted / literal false |
RETAIN_DRAFT, no problems |
And at the queue door:
| queued path at base | outcome |
|---|---|
| asserter accepts own queued observation | RETAIN_DRAFT + HUMAN_APPROVAL_REQUIRED (D8, validators.py:577-587) |
distinct demo.ADVISOR accepts it |
PROMOTE_ACCEPTED — 1 review, 1 consequence, 1 REVIEW edge |
distinct demo.ADVISOR rejects it |
RETAIN_DRAFT, 1 review, 0 consequences |
| asserter rejects own | DENY + AUTHORITY_DENIED |
So the RFC's problem statement is accurate in both halves, and — this matters for
the disclosed restriction — the capability it removes is real and currently works.
I also confirmed the C03/C10 observation correction path end to end at base: an
accepted observation consequence, then a same-family correction both directly
(PROMOTE_ACCEPTED) and queued-then-accepted-by-a-distinct-reviewer (PROMOTE_ACCEPTED,
one LINEAGE_SUPERSEDES_INTENT edge recorded at capture). OFARM_Legacy_Correction_ Authorization_RFC_v0_2.md:115 (C03) names OBSERVATION_ASSERTION → STATE_CHANGE_ACCEPTED
explicitly and :122 (C10) names observation among the four families that retain the
acceptance → contest → correction path. The RFC's "explicit material restriction"
disclosure is accurate, load-bearing and correctly requires a fresh approval.
The candidate guard I built
There is no code in this PR. To test the design I transcribed the RFC's
"Smallest proposed correction and ordering" section into the smallest faithful
patch — one condition at the start of ReviewPromotionGate.run, before
reviewer-hint routing, _authorize_retirement and both emitters; queue ACCEPT
takes its type from the fetched ctx.acceptance_payload, everything else from
policy.COMMIT_CLASS_TO_ASSERTION_TYPE; REJECT and CONTEST untouched:
if ctx.acceptance_target and ctx.review_branch == "ACCEPT":
_t = (ctx.acceptance_payload or {}).get("assertionType")
else:
_t = policy.COMMIT_CLASS_TO_ASSERTION_TYPE.get(ctx.commit_class)
if _t == "OBSERVATION_ASSERTION":
if ctx.acceptance_target: # queued ACCEPT
ctx.problems.append(runtime_problem("HIGH_CONSEQUENCE_BLOCKED", …))
ctx.final_outcome = "RETAIN_DRAFT"; return GatePass()
emitter.emit_pending_assertion(amend_case_for_routing=False) # direct
…
ctx.final_outcome = "RETAIN_DRAFT"; return GatePass()This is my transcription, not the author's code, and a Phase B implementation
may differ. It reproduces every outcome the RFC predicts:
| candidate | |
|---|---|
| direct confirmed, all four reviewer shapes | RETAIN_DRAFT, 1 pending assertion, 0 reviews, 0 consequences, HIGH_CONSEQUENCE_BLOCKED |
direct, confirmation omitted / false |
RETAIN_DRAFT, ordinary capture, no problems (diagnostic unchanged) |
| queued self-accept | unchanged: RETAIN_DRAFT + HUMAN_APPROVAL_REQUIRED — the earlier D8 refusal keeps precedence |
| queued distinct-accept | RETAIN_DRAFT + HIGH_CONSEQUENCE_BLOCKED, claim not consumed (0 REVIEW edges) |
| queued distinct-reject afterwards | still works: 1 review, 0 consequences |
| self-reject | still DENY + AUTHORITY_DENIED |
O06's retained-database probe, two phases in separate processes against one
persistent database (base bytes, then candidate bytes, no fresh_env):
phase 1 (base): accepted observation under fixed key -> PROMOTE_ACCEPTED
counts (conseq, review, assert) = (6, 6, 7)
phase 2 (candidate): REPLAY same key -> REPLAY_REUSED_RESULT, IDEMPOTENCY_REPLAY_REUSED
refs byte-identical to phase 1 (True/True)
FRESH key -> RETAIN_DRAFT, HIGH_CONSEQUENCE_BLOCKED
old pending accept by ADVISOR -> RETAIN_DRAFT, HIGH_CONSEQUENCE_BLOCKED
old accepted consequence readable: True | superseded: False
counts after = (6, 6, 8) # +1 pending assertion only
Every O06 claim holds exactly: old references reused, no new accepted objects, fresh
keys cannot accept, old pending targets cannot newly accept, old accepted history
readable and un-retired.
Blocker B1 — the RFC orders Phase B to retain observation hostile negatives it also makes unconstructible, and forbids every escape it names
Violated invariant: the RFC's own Phase B instruction, EXC-003 (direct invariant
trace to focused evidence without a hidden fallback), and #179's "Retain refused,
insufficient, and review-routed submissions honestly" — a frozen v1 would carry a
requirement no implementation can satisfy.
Where the RFC says it. Under "Decision-level invariants and falsifiable
verification":
The current H3 positive observation control must become a durable-evidence
capture control. Observation members of correction matrices must not simply
be removed: retain historical-target/cross-family negatives and assert the
new refusal while preserving other families' positive paths.
and, two paragraphs earlier:
Do not create fake past acceptances by changing candidate guards, disabling
protection, monkeypatching emitters or inserting hand-claimed accepted results.
What actually happens. test_correction_authorization.py builds every
correction predecessor through one helper:
def _original(env, family, *, direct=False): # :168-177
sub = _submission(family, env.reviewer if direct else env.author)
...
result = _review(env, _queue(env, sub)) # queued distinct acceptance
assert result["decisionOutcome"] == "PROMOTE_ACCEPTED", result # :175Under the guard, OBSERVATION_ASSERTION can never reach PROMOTE_ACCEPTED through
_queue + _review, nor through the direct path. Measured differential over the
same 14 suites, same database server, same session shape:
BASE (9d7541d9 runtime bytes): 372 passed, 18 skipped, 0 failed (115.93s)
CANDIDATE (guard applied): 362 passed, 18 skipped, 10 failed (106.21s)
Ten failures, all confined to the two modules the RFC names. Six of them are the
hostile negatives and re-checks, and every one fails in setup at line 175 —
not at its own assertion:
| failing test (OBSERVATION_ASSERTION parametrization) | what it guards | fails at |
|---|---|---|
test_full_authority_does_not_allow_cross_family_intent[OBSERVATION_ASSERTION-STRUCTURE_ASSERTION] |
C03 cross-family refusal despite full authority and matching subject | :403 → :175 setup |
…[OBSERVATION_ASSERTION-OPERATION_CLAIM] |
same | :403 → :175 setup |
…[OBSERVATION_ASSERTION-COMPLIANCE_ASSERTION] |
same | :403 → :175 setup |
test_full_authority_does_not_allow_different_subject_or_identity[OBSERVATION_ASSERTION] |
C03 subject/identity bound | :421 → :175 setup |
test_queued_correction_rechecks_target_after_another_correction[OBSERVATION_ASSERTION] |
C05 revalidation of persisted intent | :439 → :175 setup |
test_rejection_still_closes_a_correction_without_retiring_truth[OBSERVATION_ASSERTION] |
C07 refusal emits no retirement | :856 → :175 setup |
E AssertionError: assert 'RETAIN_DRAFT' == 'PROMOTE_ACCEPTED'
kernel/tests/test_correction_authorization.py:175: AssertionError
The remaining four (test_h3_promoting_observation_with_evidence_promotes,
test_each_family_retains_contest_then_authorized_correction[OBSERVATION_ASSERTION],
test_field_only_event_scopes_preserve_acceptance_and_correction[ordinary-acceptance-…]
and [correction-chain-…]) are positive controls; the RFC either names them
(H3) or covers them by the disclosed C10 narrowing. They are not the problem.
Why there is no escape inside the RFC as written. The three ways to keep those
six negatives are:
- delete the observation rows — forbidden by the sentence quoted above;
- hand-seed an accepted observation consequence in the fixture, or temporarily
disable the guard for setup — forbidden by the "do not create fake past
acceptances" sentence, verbatim; - build the predecessor with base bytes against a retained database, as I did
for O06 — the only mechanism that satisfies both sentences, and the RFC scopes
it to O06 alone ("In one retained disposable database, unmodified base HTTP
creates fictional direct and queued accepted observations…"). Nothing in the
RFC tells Phase B to rebuild the correction matrix's observation predecessors on
it, and nothing budgets for it:test_correction_authorization.pyruns on a
function-scopedenvfixture with no second-process phase, so this is not a
parametrize edit — it is a new harness for six rows in a 130-test module.
I checked for a fourth way and there is none: demo.bootstrap seeds no accepted
observation consequence (grep OBSERVATION kernel/demo.py returns only the action-class
names at :49), and there is no other supported entry point that emits
ACCEPTED_OBSERVATION_OCCURRENCE_STATE — emission.py:197 (self-review) and
emission.py:271 (queue acceptance) are the only two producers, and both sit behind
this gate.
Consequence. Approval freezes "Capability, effects/non-effects, authority,
O01–O07, historical treatment or named-PR changes"; a v1 carrying a self-contradicting
Phase B instruction either stalls the implementation at exactly the point the RFC
says most matters, or — the likelier outcome — the implementer quietly picks option
1 or 2 and the frozen requirement is violated in the Delivery that is supposed to
prove it. That is the same failure class as the K04 disclosure gap this very RFC
exists to fix.
Smallest acceptable fix — text only, no runtime change. In the same paragraph
that orders the negatives retained, name the mechanism: state that the observation
predecessors for the retained correction-matrix negatives are created by the
unmodified-base phase of the O06 retained-database procedure (or grant one explicitly
bounded, named seeding exception for fixture predecessors and say why it is not a
"fake past acceptance"), and add that mechanism to the "Expected areas" list so its
cost is visible before approval. If instead the intent is that those six rows may
be dropped, say so explicitly and delete the "must not simply be removed" sentence —
but that weakens C03/C05/C07 coverage and should be a stated, approved consequence,
not an implementer's silent choice.
Counter-argument I considered and rejected. One could read "Observation members
of correction matrices" as meaning only the rows where observation is the new
(correcting) family, which do survive — I verified that
[STRUCTURE_ASSERTION-OBSERVATION_ASSERTION] and its siblings still pass, because
SupersessionValidator (validators.py:490-502) refuses the cross-family
relationship before the promotion gate is reached, so no assertion is emitted and
_refused holds. But "retain historical-target/cross-family negatives" is
precisely the observation-as-predecessor direction, and those are the three that
break. The narrow reading does not survive the RFC's own words.
Follow-up F1 — the RFC does not pin how a blocked observation is recorded in its SufficiencyCase
emit_pending_assertion(amend_case_for_routing: bool) (emission.py:157) always
stores the case (_store_case at :92-101 inserts it regardless); the flag only
decides whether sufficiency.amend_case_for_routing annotates it with
ctx.review_route_reasons. Because the guard returns before review_route_reasons
is populated, the flag is necessarily False in any faithful implementation and the
durable case will carry no record of why the capture stayed pending — the
eligibility reason lives only in the response problems and the gate log.
O01–O07 as written do not test this either way; both choices pass. #179's
"Retain refused, insufficient, and review-routed submissions honestly" argues the
case should say so. This is outside the one-capability boundary of this PR — record
it as Delivery work against #179's honest-retention criterion, or add one sentence
to O02. I am not asking this PR to expand.
Preference P1 — HIGH_CONSEQUENCE_BLOCKED would carry a third, differently-shaped meaning
The code is registered (kernel/problems.py:34; registry RFC §3, Publication
family), so §6's unregistered-code failure does not apply, and the RFC's choice is
the better of the two obvious options: HUMAN_APPROVAL_REQUIRED would tell a
client that some human can approve this, which §6 forbids as overstating authority.
I agree with the selection.
The cost: on the commit path the code already means "unlawful promotion target"
(validators.py:454, a hard FAIL_SEMANTIC refusal that aborts the commit) and
"self-declared record class refused" (:894). Adding a third meaning that is a
soft RETAIN_DRAFT pass-through leaves a client unable to separate them by code, against
registry §4's "reason codes must distinguish" list. Cheap remedy: pin the exact
title string in the RFC (I used "Observation acceptance disabled") so the pair
(reasonCode, title) discriminates, and add it to O02. Non-blocking under EXC-007.
Preference P2 — the lawful-requested-target diagnostic stays optimistic
PromotionTargetValidator (validators.py:449-457) will continue to accept
requestedPromotionTarget: "ACCEPTED_OBSERVATION_OCCURRENCE_STATE" as lawful for
an OBSERVATION_ASSERTION — keeping COMMIT_CLASS_TO_PROMOTION_TARGET is correct
and the RFC justifies it well — so a caller can be told its requested promotion
target is lawful and then handed RETAIN_DRAFT. Harmless, but worth one clause in the
"History, correction and non-effects" section so the retained map is not later read
as a residual acceptance route. Non-blocking.
Checked and decided were not findings
Spending this so the next reviewer does not.
- Guard placement covers every acceptance producer.
ACCEPTED_OBSERVATION_OCCURRENCE_STATE
has exactly two producers,emission.py:197(self-review) andemission.py:271
(queue acceptance), both insideReviewPromotionGate.run, which is the last stage
ofCHAIN(gates.py:51-58). No other class reaches an observation assertion
type:COMMIT_CLASS_TO_ASSERTION_TYPE(policy.py:51-57) maps only
OBSERVATION_ASSERTION → OBSERVATION_ASSERTION;NOTE,HYPOTHESIS_ASSERTION,
ADVISORY_OUTPUTandEVIDENCE_RECORDfall to"OTHER_ASSERTION"and are absent
fromCOMMIT_CLASS_TO_PROMOTION_TARGET. The single-condition design is sound. - REJECT and CONTEST are correctly excluded.
ctx.acceptance_payloadis set for
both ACCEPT and REJECT (validators.py:555) and for CONTEST it holds a
consequence, not an assertion (:637), so keying the type lookup on
review_branch == "ACCEPT"— as the RFC specifies — is exactly right. Keying it on
acceptance_targetalone would have blocked lawful rejection. Verified live:
rejection still works under the candidate. ctx.review_branchdefaults to"ACCEPT"(stages.py:142). I chased this as a
possible bypass: a direct commit hasacceptance_target = None
(stages.py:277-279sets it only forGOVERNANCE_DECISION), so theandin the
RFC's rule is load-bearing and correct. An implementation that tested
review_branchalone would read aNonepayload on the direct path; O01 catches it.- Permanently-inert
LINEAGE_SUPERSEDES_INTENTedges are harmless. Blocked
observation corrections leave intent edges that can never resolve. The only reader
in non-test code isvalidators.py:595(queued-acceptance revalidation); no
materializer, passport or derived-state path consumes them. Derived state is not
degraded. RETAIN_DRAFTis contract-valid for aGOVERNANCE_DECISIONcommit.
decisionOutcome/finalOutcomeenums inOFARM_CommitIngressResult_schema_v0_1.json
andOFARM_PromotionTrace_schema_v0_1.jsonboth include it, and the existing
runtime already returns RETAIN_DRAFT for a lawful queued rejection and for the
D8 self-accept refusal. No new vocabulary.- No canonical-law conflict.
reference/law/OFARM_Reference_Model_and_Artifact_ Constitution_RC2_1.md:1138lists "accepted observation/occurrence state" only as an
in-force result class, and §11.3 requires commit classes to have different
promotion paths — an empty one is different.:748of the Architecture RC2_1
explicitly calls observation assertion a low-promotion class. The RFC's "canonical
contracts are non-effects" claim holds. test_policy_tables_are_closed_and_consistent(test_stages.py:40-61) stays
green with the maps retained — it checks map-to-map consistency, not reachability.
Deleting the observation entries, as EXC-006 rejects, would have broken it.- Architecture budgets are not a constraint here.
kernel/stages.py(759 lines at
base) appears in noMODULE_BUDGETS, noGROUP_BUDGETSand no
COMMAND_MODULE_BUDGETSinconformance/rewrite_architecture_check.py; it is a
LEGACY_MODULESmember. My guard added 34 lines with no budget consequence. The
new focused test module facesMAX_TEST_LINES = 800with no override. - Conformance is unaffected.
kernel/tests/test_conformance.pyrun in its own
session: 23 passed at base, 23 passed at candidate. The RFC's "affected
conformance/review tests" is broader than what actually moves; harmless. test_self_review_eligibility.py(#386's module) stays green under the candidate —
the compliance fix and this proposal do not collide.- Every line anchor in the author's inline report is correct at this head. I
checked all 27:stages.py:274-295,validators.py:514-525/536-555/543-576/577-587/588-615,
stages.py:478-501/668-681/625-658/702-707/554-580/202-204,emission.py:157-167/483-490,
gates.py:270-272/282-295,validators.py:490-502,api.py:74-83. No drift. - Review-baseline inventory currently reports
entryCount4,483 with
entriesSha256 737e6882…; consistent with the post-#386 state. Regeneration for the
new module is correctly listed in "Expected areas". HIGH_CONSEQUENCE_BLOCKEDis inREGISTERED_REASON_CODES(problems.py:34), so
the RFC's "registered" claim is true, not assumed.- #179 really does say it. Its acceptance criteria include, verbatim: "observation
promotion remains disabled until typed semantics exist". The RFC is not inventing a
requirement to justify the broader scope; selecting it over mere distinct-reviewer
routing (EXC-006) is within Delivery #387's stated work.
What my method made easier than production
- Unpinned everything. 3.11.15 vs the required 3.12.13; PG 16.13 vs 17.10;
unpinned wheels. Interpreter-sensitive gates (architecture, temporal, package
contract) and any PG17-only behaviour are untested here. Ruff did not run. - My guard is a reviewer's transcription, not the implementation. A Phase B patch
that differs in placement or type resolution could behave differently. The
Blocker does not depend on my transcription's details: it depends only on
OBSERVATION_ASSERTIONnever reachingPROMOTE_ACCEPTED, which is the RFC's
entire selected capability. create_test_app(store, oidc=None)uses theX-Acting-Partyheader rather than
OIDC, so the whole token-verification layer above_transport_principal
(legacy_m1/api.py:82-137) is skipped. All my 403/401 precedence observations are
weaker than production would be — and production governed routes are closed anyway
(api.py:74-83), so none of this is a production-reachability claim.- Single process, single connection. No concurrency, no competing writer; C08-style
serialization claims are untouched by this review. - No transaction-boundary or rollback proof. I observed emitted-record counts before
and after, not atomicity under failure. O07's rollback/replay obligations remain
unproven and correctly remain implementation evidence. - The differential ran 14 suites, not the full tree. 24 modules fail to collect
in this container for absent optional dependencies; identical at base and candidate,
so the differential is sound, but a break outside the 14 would be invisible to me.
Independence
samovers authors these PRs and both this review and the author's pass are the same
account, so GitHub will accept only a COMMENT review and the "two independent
reviews" gate is not met by either of them. Do not treat this as satisfying it.
Next: resolve B1 in the RFC text — one paragraph naming the mechanism for the
retained observation correction-matrix negatives — then present the complete
version 1 decision card naming draft PR #388. The capability, the ordering, the
disclosed C03/C10 narrowing and the O01–O07 verification are otherwise sound and I
would not hold the decision for F1, P1 or P2.
Resolve PR388 design review B1 by sharing the pinned unmodified-base retained-database fixture across O06 and six correction negatives. Clarify diagnostics and evidence-case reporting without changing O01-O07 or runtime; track separate reporting work in Delivery389.
Implement approved OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 v1 for Delivery #387. Preserve valid capture and historical review/replay while blocking both new acceptance paths before retirement. Retain all correction matrix controls using genuine fixed-base HTTP history and pin the expanded test inventory.
|
Exact-head implementation content review completed for PR #388 / Delivery #387 at 4f6fa20 with zero demonstrated in-scope Blockers. The full separate-agent report is in the PR description; SHA256 6e019bba7724f9c081624bab1cee522fe239f260b4d2059dadc437473e6b4cef. Genuine fixed-base history preserves the earlier correction negatives; O01–O07 and approved scope are unchanged. Follow-up #389 remains separate. Local checks and limits are recorded. This invokes the existing technical baseline admission only, not human final acceptance, publication success, merge authority or production permission. OFARM2_BASELINE_ADMISSION |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #388 — implementation re-review
Technical verdict: REQUEST CHANGES. One in-scope P2 Blocker: the new early return silently drops an existing temporal-validation warning. I found no observation-acceptance bypass.
Reviewed head: 4f6fa2036863cefb8f7635b474aae7ea8faedbcb, against base 9d7541d96bc708e9270b986927d7f4b8a035454f. The branch remained at that head when the review checks finished. This review covers the implementation, not just the earlier Phase A proposal, and applies only to this exact head.
This is posted as a COMMENT review; it is not a GitHub approval, baseline admission, semantic approval, or merge authorization. B1 below is an implementation finding, distinct from the earlier Phase A review's fixture-design B1.
B1 — Preserve earlier validation diagnostics before returning from the observation guard
Classification: Blocker, P2 — correctness and traceability regression.
Location: kernel/stages.py:633–651, in ReviewPromotionGate.run.
The common temporal validator runs for observations. For a parseable event time outside the plausibility window, it creates an EVIDENCE_INSUFFICIENT / Event time outside plausibility window warning and puts it in ctx.review_route_reasons. It does not refuse immediately or independently persist that warning.
Previously, the promotion gate's review-routing branch copied these accumulated reasons into ctx.problems. The new observation branch returns before that code, copying only its newly created acceptance-disabled diagnostic. Consequently, the temporal warning is discarded. The final writer persists ctx.problems and the gate log, not the unused ctx.review_route_reasons.
Sources: TemporalConformanceValidator and COMMON_SEQUENCE, ReviewPromotionGate.run, PromotionTraceWriter.write.
Concrete counterexample: submit an otherwise-valid observation through the supported legacy POST /commit route, with creation authority, durable evidence, a valid subject, and a fresh idempotency key. Set eventTime to 2999-01-01T00:00:00Z.
| Confirmation | Current implementation's source-traced result |
|---|---|
Omitted or false |
One pending assertion and RETAIN_DRAFT, but no problem explaining the implausible event time. |
true |
One pending assertion and RETAIN_DRAFT, with only Observation acceptance disabled; the temporal warning still disappears. |
This is a source-traced counterexample, not a locally executed database reproduction. The path follows directly from the validator, the new early return, and the final writer. The observation validation branch logs VALIDATION/PASS; it does not preserve the accumulated temporal warning elsewhere. The supported entry is the legacy development/conformance route; production governed routes remain closed. No production reachability is claimed.
Acceptance remains blocked, so this is not a promotion vulnerability. The regression is that a submission previously accompanied by an explicit validation finding becomes an apparently ordinary capture. That conflicts with O02's preservation of ordinary diagnostics for omitted/false confirmation. The new capture matrix uses an in-window timestamp and therefore does not exercise this case.
Sources: O02 and verification requirements, observation capture matrix.
Smallest acceptable fix: preserve the previously accumulated temporal findings in the durable result when taking the direct observation branch, alongside the acceptance-disabled diagnostic where applicable. Keep RETAIN_DRAFT, the single pending assertion, and zero accepted reviews, consequences, or effective retirement edges. Add focused tests for out-of-window timestamps with omitted, false, and true confirmation, checking the persisted diagnostic—not just the response outcome.
This is an implementation/conformance correction affecting kernel/stages.py, kernel/tests/test_observation_eligibility.py, and the regenerated inventory. It needs no baseline-law change, new state, evidence case, grant, or promotion-matrix redesign.
What the implementation otherwise gets right
The acceptance restriction is correctly shared. Queued ACCEPT derives its type from the validated stored assertion; direct capture uses the existing commit-class map. The guard runs before both acceptance emitters and retirement authorization. REJECT and CONTEST remain outside the observation-acceptance condition. I found no caller-supplied type or reviewer hint that bypasses this restriction in the inspected path.
Source: common observation guard and surrounding promotion branches.
The same-claim lifecycle tests check meaningful effects. They verify failed self-acceptance and independent acceptance without consuming the claim, followed by lawful independent rejection and terminal duplicate-review refusal. They inspect stored records and REVIEW edges rather than relying solely on response enums.
Source: test_same_observation_survives_acceptance_refusals_then_terminal_rejection.
The historical fixture addresses the earlier review requirement. It authenticates the fixed base source, runs that unmodified runtime in a separate process to create accepted history through HTTP, then opens the candidate against the same disposable database. The tests preserve historical records and edges, exercise historical pending corrections, and replay the original normalized governance submission rather than regenerating decisionTime through /review/accept. No candidate acceptance exception or fabricated accepted-row shortcut is introduced.
Sources: fixed-base retained-history fixture, historical replay and correction controls, retained correction matrices.
Existing Follow-up #389 remains separate. Its subject is interpreting a satisfied evidence case alongside a later acceptance refusal. B1 concerns a different problem: an already-produced temporal warning newly disappearing because of this PR's early return. Fixing B1 does not require expanding into #389's evidence-reporting work.
Source: Delivery #389.
Verification
I downloaded the provisional conformance artifact, published baseline artifact, and publication receipt, and independently checked their archive hashes and internal evidence consistency. Both hosted baseline runs record 4,513 collected, selected, and passed tests, including 30 observation-eligibility cases and 12 correction cases containing observations, with no failed, skipped, deselected, unavailable, or expected-failure cases. Each baseline records one warning.
Evidence coordinates:
- Admitted source run 34781743088; provisional conformance artifact
10325971325, archive SHA-256f1910f8b5cdca17b358128398ecf452d9d5a829b70840c040bfddbde18968dbe. - Separate publisher 34783573444; published baseline artifact
10324859526, archive SHA-256577c51f2e01ee8063950241096ec3cac76ac19a5ffa0a410bce35431a4299bfd. - Publication receipt artifact 10324999339, archive SHA-256
01125e253f85f0aa4cbf9b234bef97e501e2b122e8620db85701ed7d244deb14; receipt JSON SHA-256cff005275f41add1978b459e873942f6843723085a08baaea22cd34be1b27b87.
The initially observed source-versus-published normalized-hash difference is explained by serialization changes: the test-result JSON content is unchanged, while its serialized size and hash change. The published normalized hash c16428636d0ac1d212986fc7679c3fdc35e7f6f4207bf00488b4b06a9afb1071 matches the PR's reported value. There is no outstanding hash-discrepancy finding.
I did not rerun PostgreSQL tests locally, execute the native image archives, or independently retrieve the original approval messages from the separate Codex task. Evidence inspection is not a runtime-test rerun or a substitute for the repository's admission/publication/approval gates. The green hosted evidence supports the implemented test cases; it does not cover the missing temporal-warning case.
Hold technical clearance until B1 is fixed and covered by a regression test, followed by fresh exact-head review and the required evidence sequence. No semantic, production, baseline-admission, or merge authority is supplied by this review.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #388 — implementation re-review
Reviewed head: 4f6fa2036863cefb8f7635b474aae7ea8faedbcb (tree 599758fba35a4fdf05d882c89216e36d8c36222c).
Base: 9d7541d96bc708e9270b986927d7f4b8a035454f. Delivery #387, decision
OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 version 1.
Prior pass by me: pr-388-review.md at design head 7ba5b880
(review 5192087845).
Verdict: 1 Blocker, 0 Follow-ups, 2 Preferences.
The Blocker is not mine first. Review 5194671391
at this head found it by source tracing and said so explicitly. I reproduced it,
it is real, and it is larger than that review states. What I add is below, under B1.
My three earlier findings are closed, and one of them was closed by correcting me.
This is a COMMENT review, not a GitHub approval, baseline admission or merge authorization.
What changed, and the pinned environment this pass finally had
Two commits on top of the reviewed design head: 0931e47 (RFC clarifications) and
4f6fa20 (implementation). The PR is no longer a draft.
$ git diff --stat 9d7541d9...4f6fa20
conformance/review_baseline_test_inventory.json | 156 +-
docs/REVIEW_DISPUTE_SEMANTICS.md | 76 +-
docs/rfcs/OFARM_Legacy_Observation_Eligibility_RFC_v0_1.md | 300 +
kernel/stages.py | 26 +
kernel/tests/conftest.py | 1 +
kernel/tests/observation_history.py | 215 +
kernel/tests/test_correction_authorization.py | 86 +-
kernel/tests/test_observation_eligibility.py | 418 +
kernel/tests/test_review_fixes.py | 15 +-
9 files changed, 1255 insertions(+), 38 deletions(-)
$ git diff --check 7ba5b880 4f6fa20 # clean
Unlike my first pass, this one ran on the repository's own pins. I built CPython
3.12.13 from the v3.12.13 GitHub tag and installed requirements-review-baseline.lock
requirements-review-tools.lockwith--require-hashes --only-binary=:all: --no-deps.
So the mandatory gates are re-verified here, not taken on trust:
$ /tmp/v13/bin/python conformance/rewrite_architecture_check.py
rewrite architecture constraints: PASS
$ /tmp/v13/bin/python conformance/ofarm_pkg_contract_check.py
RESULT: PASS (0 failures)
$ ruff 0.15.5 check <all six changed files> All checks passed!
Still PostgreSQL 16.13, not the required 17.10. That is the one pin I could not
meet, and it is why the provisioning slice results below are environmental.
B1 — the observation guard discards the temporal plausibility routing, and changes the recorded outcome with it
Classification: Blocker (correctness / traceability regression).
Violated invariant: ERRATA E-001's "routed to review, never silently accepted",
and O02's "Omitted and literal-false confirmation retain capture-only behavior and
ordinary diagnostics".
Location: kernel/stages.py:627-651, the new early return in ReviewPromotionGate.run.
TemporalConformanceValidator appends an EVIDENCE_INSUFFICIENT / Event time outside plausibility window WARNING to ctx.review_route_reasons (kernel/validators.py:432-438)
rather than refusing. At base the promotion gate consumed it:
if ctx.review_route_reasons: emit_pending_assertion(...); ctx.problems.extend(...); final_outcome = "REQUIRE_REVIEW". The new observation branch returns before that block
and extends ctx.problems with its own diagnostic only.
Executed reproduction
Real POST /commit, real Store, CPython 3.12.13, demo.FARMER with creation authority
and durable evidence, valid subject, fresh idempotency key, eventTime: 2999-01-01T00:00:00Z:
| confirmAccept | base 9d7541d9 |
head 4f6fa20 |
|---|---|---|
| omitted | REQUIRE_REVIEW · [(EVIDENCE_INSUFFICIENT, Event time outside plausibility window)] |
RETAIN_DRAFT · [] |
false |
REQUIRE_REVIEW · same problem | RETAIN_DRAFT · [] |
true |
REQUIRE_REVIEW · same problem | RETAIN_DRAFT · [(HIGH_CONSEQUENCE_BLOCKED, Observation acceptance disabled)] only |
And the gate log for the same requests:
| base | head | |
|---|---|---|
| omitted / false | ('REVIEW_PROMOTION', 'REQUIRE_REVIEW', 'EVIDENCE_INSUFFICIENT') |
('REVIEW_PROMOTION', 'RETAIN_DRAFT', None) |
true |
('REVIEW_PROMOTION', 'REQUIRE_REVIEW', 'EVIDENCE_INSUFFICIENT') |
('REVIEW_PROMOTION', 'RETAIN_DRAFT', 'HIGH_CONSEQUENCE_BLOCKED') |
An in-window control on the same run behaves identically on both sides for omitted/false
(RETAIN_DRAFT, []), so the difference is the plausibility window and nothing else.
What this adds to review 5194671391
That review traced the dropped ctx.problems entry from source and said plainly it had
not executed it. Three things follow from actually running it:
- The
decisionOutcomeitself regresses, not only the problems list. Base records
REQUIRE_REVIEW; head records RETAIN_DRAFT. REQUIRE_REVIEW is the durable record
that the claim was routed to review — exactly what E-001 demands — and it is gone.
After this change REQUIRE_REVIEW is unreachable for any observation at all. - The promotion-trace gate log loses its
reason_code(EVIDENCE_INSUFFICIENT→NULL
on the omitted/false shapes), so the finding is absent from the trace as well as the
response. Nothing downstream can recover it. - The blast radius is exactly one warning class, and I bounded it. For
OBSERVATION_ASSERTIONthe ValidationGate dispatch runsCOMMON_SEQUENCEand then
ctx.log("VALIDATION", "PASS"); return GatePass()(kernel/validators.py:1461-1484).
Of the sixreview_route_reasonsproducers,:943(dose sanity),:1099(actor
attribution),:1178/:1187(product/crop bindings) and:1446(registry
reverification) are all inside the operation-claim sequence, andstages.py:542
(floor_failures) is inside the OPERATION_CLAIM/COMPLIANCE_ASSERTION branch.
validators.py:434is the only one an observation can reach. So this is a bounded,
fully enumerable fix, not an open-ended audit.
Why the smallest fix is not purely mechanical
Extending ctx.problems with ctx.review_route_reasons in the observation branch restores
the diagnostic but leaves the outcome at RETAIN_DRAFT. That may well be the right answer —
"routed to review" is arguably incoherent once no review can accept an observation — but it
is a decision about O02's required behaviour, not an implementation detail, and O02
currently says the omitted/false shapes "retain capture-only behavior and ordinary
diagnostics" without saying which of the two base behaviours "ordinary" names.
So the smallest acceptable fix is two parts:
- RFC: one sentence in O02 stating that an observation whose event time falls outside
the plausibility window retains itsEVIDENCE_INSUFFICIENT / Event time outside plausibility windowfinding in the result problems and the gate-log reason code, and
naming the outcome it carries (RETAIN_DRAFT, on the reasoning that REQUIRE_REVIEW no
longer describes anything reachable). Approval has already been taken on v1, so if the
answer is "REQUIRE_REVIEW is preserved" that is a behaviour change needing its own note. - Runtime + test: carry
ctx.review_route_reasonsinto the durable result on the
observation branch, and add one out-of-window row to
test_observation_capture_matrix_http_and_direct. The matrix currently uses
"eventTime": "2026-06-10T09:00:00Z"in_observation()for all twelve cells, and
_pending()asserts_diagnostic(result) == ([DISABLED] if confirmed else [])—
an exact list equality that would have caught this the moment one cell went out of window.
Counter-argument, stated. Acceptance is blocked either way, so no accepted force is
created and this is not a promotion vulnerability — review 5194671391 says so too and I
agree. I still classify it Blocker rather than Follow-up because it is a behaviour
regression introduced by this PR, inside this PR's own gate, contradicting a named ERRATA
entry and this RFC's own O02, and the fix is a handful of lines plus one sentence. It is
not outside the change boundary.
What closed since the design head
My B1 (retain-the-negatives vs never-fake-an-acceptance) — closed, and well
The RFC gained a "Concrete mechanism for those retained negatives" paragraph naming the
two-process retained-database procedure, added kernel/tests/observation_history.py to
Expected areas, and states "No row is dropped and no raw accepted-record seeding or guard
exception is granted." That is what I asked for. The implementation goes further than the
text had to:
- No row dropped. All six observation-predecessor rows survive and now assert the
earlier refusal the RFC demanded, not merely the new guard:CORRECTION_REQUIREDon
the three cross-family rows and the different-subject row,SUPERSEDED_RECORD_USEDon
the stale-target C05 row and on duplicate review after rejection. - The predecessors are real.
observation_history.pyresolves9d7541d9/ tree
63d53211from local Git objects, extracts viagit archive, and recomputes each
file's SHA-1 blob digest against itsls-treeoid before writing it, then asserts
digests.keys() == objects.keys(). The base phase runs insys.executable -I -Bwith
everyOFARM_*variable stripped, asserts nokernel*module is preloaded, and
afterwards re-hashes every kernel module it actually imported against the authenticated
digest.test_real_base_history_replays_...then asserts
"kernel/stages.py" in history["source"]["importedSources"]— so the suite itself proves
the accepted history was produced by base bytes. - Prior records are frozen.
preserve_history()runs_assert_prior_records_unchanged
plus an edge-by-edge comparison immediately after the candidate opens and again at
teardown.
I checked the two preconditions the RFC asserts for hosted runs and both hold: the only
job in .github/workflows/conformance.yml that runs pytest is conformance (lines
115-528), and it carries both fetch-depth: 0 and python-version: "3.12.13".
Measured, on the pinned interpreter:
test_observation_eligibility.py + test_correction_authorization.py + test_review_fixes.py
-> 176 passed in 110.42s
My F1 (the SufficiencyCase) — closed, and my earlier call was wrong
Flagging a revision to my own prior review. In pr-388-review.md I wrote that
_store_case "inserts it regardless" and that a blocked observation's SufficiencyCase would
therefore carry no record of why the capture stayed pending. That was wrong. _store_case
returns at emission.py:94-95 when ctx.case_payload is falsy, and a direct observation
never gets one: EvidenceSufficiencyGate builds a case only for the queued-ACCEPT branch
(stages.py:478-494) and for OPERATION_CLAIM / COMPLIANCE_ASSERTION (:503). I read the
flag and not the guard above it. Measured at this head:
direct confirmed observation -> RETAIN_DRAFT, EvidenceSufficiencyCase records created: 0
queued ACCEPT (blocked) -> RETAIN_DRAFT, EvidenceSufficiencyCase records created: 1
The RFC's new paragraph states exactly this — no case for direct capture, a possibly
already-satisfied case for a queued ACCEPT, that case is not acceptance permission, and
Delivery #389 owns any reporting improvement. Both halves check out. Nothing for the author
to fix; the correction is mine.
My P1 (reason-code discrimination) — closed
The RFC now pins the exact pair (HIGH_CONSEQUENCE_BLOCKED, Observation acceptance disabled)
and the tests assert the pair by exact list equality (_diagnostic() returns
(reasonCode, title) tuples). That is stronger than what I asked for.
My P2 (optimistic requested-target) — closed
The RFC adds the clause that a matching requestedPromotionTarget establishes type
compatibility only, and _observation() sends
"requestedPromotionTarget": "ACCEPTED_OBSERVATION_OCCURRENCE_STATE" in all twelve
matrix cells, so the claim is exercised rather than merely asserted.
Mutation testing of the implemented guard
Per-conjunct, each mutation applied alone to the head tree and the three affected modules
re-run on the pinned interpreter. Every mutation dies, and each is pinned by a specific
control — a real improvement on PR #386, whose suite survived dropping and confirmed:
| mutation | result |
|---|---|
m1 drop and ctx.review_branch == "ACCEPT" |
2 failed — test_same_observation_survives_acceptance_refusals_then_terminal_rejection, test_rejection_still_closes_a_correction_without_retiring_truth[OBSERVATION_ASSERTION]. Lawful rejection is pinned. |
m2 drop ctx.acceptance_target and |
error — ctx.acceptance_payload is None on the direct path (review_branch defaults to "ACCEPT"); fails loudly at fixture setup. |
m3 problem only when confirmed |
5 failed — the queued rows lose their diagnostic and are caught. |
m4 problem only when ctx.acceptance_target |
8+ failed — the whole direct capture matrix. |
| m5 use the class map for both branches | 5 failed — queued acceptance would no longer be blocked. |
m6 if False: (guard removed) |
9 failed across the new module and test_review_fixes.py. |
m2 also answers the one thing that worried me on sight — ctx.acceptance_payload.get(...)
has no or {} guard. It is safe, and not a new surface: EvidenceSufficiencyGate
dereferences ctx.acceptance_payload under the identical condition at stages.py:478-480
and runs immediately before this gate in CHAIN. A None payload there would already crash
at base.
Everything else I measured
Full suite, pinned interpreter
$ pytest kernel/tests/ --collect-only -> 4513 tests collected
conformance/review_baseline_test_inventory.json entryCount -> 4513 (exact match)
$ pytest kernel/tests/ --ignore=test_conformance.py
-> 4 failed, 4037 passed, 345 skipped, 104 errors in 433.11s
$ pytest kernel/tests/test_conformance.py (own session)
-> 23 passed
The 4 failures and all errors are in test_postgresql_provisioning.py and
test_postgresql_tenant_challenge_migration.py — the PG17 native-binder slice, untouched by
this PR. Same four names fail at base on this machine:
BASE 9d7541d9, same two modules: 4 failed, 111 passed, 26 errors
test_partial_target_refuses_without_repair_or_creation
test_unrelated_database_refuses_before_any_provisioning_write
test_changed_maintenance_acl_refuses_before_any_provisioning_write
test_provision_and_verify_fix_catalog_output_settings_before_observation
Identical set at base and head: environmental (PG 16.13 vs the required 17.10), not head
defects.
Inventory
committed entryCount 4513, entriesSha256 b0d3a235ac23c01d…
recomputed with the repo's own run_review_baseline._inventory_document -> identical
diff vs 7ba5b880: +31 / −1 (31 all in test_observation_eligibility.py;
the 1 removal is the renamed H3 test)
raw file sha256 6abd53834b1f65fe1e7ca1d2937d08316a0f854cb8d85d2c5ad15074f24fc672
== the PR body's stated digest
Collected count equals entryCount exactly, so the inventory is not stale.
Budgets
kernel/stages.py is 759 → 785 lines and remains in no MODULE_BUDGETS,
GROUP_BUDGETS or COMMAND_MODULE_BUDGETS (it is a LEGACY_MODULES member).
test_correction_authorization.py is 921 → 983, above MAX_TEST_LINES = 800, but none
of these modules match any TEST_GLOBS pattern, so they are unbudgeted — and it was already
921 at base. The architecture check PASSes, consistent with that reading.
Documentation (EXC-004)
docs/REVIEW_DISPUTE_SEMANTICS.md replaces the "Known K04 residual" block — the one my
PR #386 review produced — with the approved restriction, and rewrites §6.7's "preserves all
four acceptance → contest → compatible correction paths" to record the narrowing. The
positive claim is retired where it lived.
Preferences
P1 — the retained-history scenario is selected by test-name substring.
test_correction_authorization.py's env fixture picks "stale" / "field" / "original"
by "rechecks_target" in request.node.name and "field_only" in request.node.name. Renaming
a test, or adding a new observation-parametrized one, silently yields the "original"
scenario and the failure surfaces as a wrong reason code rather than a wrong fixture. An
explicit mapping (or a marker) asserted against the known set would name the cause. EXC-007
taste; non-blocking.
P2 — the mechanism depends on an unasserted bundle-digest equality.
The candidate phase's queued acceptance of a base-created assertion only reaches
_validate_correction because base and candidate compute the same RuntimeBundle digest — the
cross-bundle gate at validators.py:543-551 would otherwise refuse first with PACK_CONFLICT.
I measured them identical (sha256:7b4c820d299aabc196b26e4f515d313a542fbaf37d027002fa46bdb69d8be461
on both sides), so the fixture is sound today. Nothing asserts it. A future change to this
slice that moves the digest would flip six hostile negatives to a wrong reason code instead
of a named cause. One assertion in observation_history comparing the two digests would cost
a line and make the dependency explicit. Non-blocking.
Checked and decided were not findings
- O05's direct half is proven, which was my main hunt.
test_real_base_history_replays_...submits a direct observation correction
(confirmAccept=True+ the base'ssupersedesConsequenceRef) by the fully authorized
reviewer and asserts RETAIN_DRAFT, one pending assertion, the retained
LINEAGE_SUPERSEDES_INTENTedge,edges_to(old, "LINEAGE_SUPERSEDES") == [],
unchanged predecessor bytes andinForceState: IN_FORCE. - The caller cannot supply the type. The same module commits a forged submission carrying
assertionType="OPERATION_CLAIM_ASSERTION"andreviewerPartyRef=demo.FARMERand asserts
the stored target still wins. That closes the RFC's "never a caller-supplied type field". - The suppressed distinct-reviewer routing reason is intentional and pinned.
_pending()asserts_diagnostic(result) == ([DISABLED] if confirmed else [])by exact list
equality, so "Distinct reviewer requires own act" must be absent on the
reviewer-distinct×truecell. - No duplicate gate log on the queued path. The queued branch returns
GateRefusalafter
its ownctx.log; measured, a blocked queued acceptance writes exactly one
REVIEW_PROMOTIONrow:('REVIEW_PROMOTION', 'RETAIN_DRAFT', 'HIGH_CONSEQUENCE_BLOCKED'). - The reviewer's replayed key is honest. Re-posting an identical
/review/acceptbody
returnsDENY+IDEMPOTENCY_REPLAY_CONFLICT, because the route regenerates
decisionTimeand the source digest changes. That is the subtlety the RFC documents for
historical replay, and it behaves as described. - CONTEST is untouched.
_validate_contestsetsreview_branch = "CONTEST"and stores a
consequence inacceptance_payload; the== "ACCEPT"conjunct routes it to the class map
andGOVERNANCE_DECISIONis absent from it. Contest of a historical observation still
appends its DISPUTE edge — asserted in the replay test. monkeypatchintest_observation_late_failure_rolls_back_capture_and_retry_stays_inert
injects a late write failure to prove rollback. It does not fabricate acceptance, so it is
not the "monkeypatching emitters" the RFC forbids.ruff checkpasses on all six changed files with the pinned Ruff 0.15.5.
ruff format --checkwould reformat two of them, but the repository's architecture check —
which owns the pinned formatter gate — PASSes, soruff formatis not the enforced contract
here.
What my method made easier than production
- PostgreSQL 16.13, not the pinned 17.10. The provisioning/native-binder slice cannot run;
I showed it fails identically at base rather than claiming it green. create_test_app(store, oidc=None)authenticates byX-Acting-Party, so the whole OIDC
layer above_transport_principalis skipped. Production governed routes are closed
(kernel/api.py:74-83); nothing here is a production-reachability claim.- Single process, single connection for my own probes. I did not exercise concurrency; the
C08-style serialization claims are untouched by this review. - The approval record is the one thing I cannot check. The RFC's status is now "Approved
decision; implemented", resting on Codex task01a07cc8-…message
msg_01a09c78-89b3-75b3-91fa-c8e6d25863b8(2026-09-13T20:32:20Z) carrying the exact
approval sentence. I have no access to that transcript and can neither confirm nor dispute
it. Every runtime claim below that line I verified; that line itself rests on the author's
navigation reference alone. Anyone admitting this PR should verify it independently. - My mutation matrix ran three modules, not the full tree. A mutation-surviving control
elsewhere would be invisible to me.
Independence
Four reviews now stand on #388 (5192025465, 5192087845, 5194671391 and this one) and all
four are samovers. The two-independent-reviews gate is still unmet, and this review
does not satisfy it.
Next: B1 needs the O02 sentence and the ctx.review_route_reasons carry-through, plus one
out-of-window row in the capture matrix. Everything else at this head I would let through:
the B1 remedy from my design pass is implemented more thoroughly than the RFC text required,
and the mutation coverage is the strongest this series has had.
Carry earlier validator findings into the direct observation result and promotion log while preserving the approved RETAIN_DRAFT outcome and closed acceptance path. Expand the HTTP/direct capture matrix across timestamp plausibility, clarify diagnostic behavior, and regenerate the pinned inventory. Addresses PR #388 implementation review B1 for Delivery #387; O01–O07 and the observation eligibility boundary remain unchanged.
|
Bounded exact-head B1 review completed for PR #388 / Delivery #387 at 524c31d with zero demonstrated in-scope Blockers. The full separate-agent report is in the PR description; SHA256 f6cd04415d4d072dbff2bb59c390ef02d568c9398bb6b50cf29c9a5d410492f2. Earlier temporal warnings now survive direct retained observation captures; O01–O07 and the approved boundary remain unchanged. Independent probes passed 34; local results and the calibrated prior/candidate H1 clock limitation are reported honestly. Follow-up #389 and fixture Preferences remain separate. This is fresh technical admission only, not human final acceptance, publication success, merge authority or production permission. Earlier head evidence is historical and not reused. OFARM2_BASELINE_ADMISSION |
Integrate merged PR #391 from main for Delivery #387 / PR #388. The observation diff against the new base is byte-identical to the previously reviewed implementation; preserve its historical replay base. Verify 42 observation cases, mandatory package/architecture/temporal checks, Ruff and whitespace. Fresh exact-head review and admitted hosted evidence follow this new merge head; the earlier failed source stays failed.
|
Fresh exact-head admission after the mechanical integration of merged PR #391 into PR #388. Head: 4ffe7bb. Main/policy: eea1601. Bounded integration/O07 review: zero Blockers, zero new Follow-ups, zero new Preferences; sealed report SHA256 4db90eb21a123b726d42a6beb235f1ab79574b2e46d48bd496eb3732a83e3dd1, preserved in the PR description. The observation diff against new main is byte-identical to the previous reviewed diff; O01–O07, historical base and the 4,525-case inventory are unchanged. Fresh local observation module: 42 passed, one expected warning; mandatory package/architecture/temporal, Ruff, whitespace and lightweight34872628959 passed. Original decision OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 version1 remains the semantic scope; this comment supplies only the existing technical admission trigger, not approval or merge authority. Request the required fresh hosted evidence and separate publication for this exact head. Earlier failed source34828888000 stays failed and is neither rerun nor reused. The completed prerequisite's receipt does not transfer to this PR. OFARM2_BASELINE_ADMISSION |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #388 — bounded re-review
Verdict: the temporal-warning B1 is resolved. No remaining demonstrated in-scope Blockers, and no new Follow-ups or Preferences.
Reviewed head: 4ffe7bbfd73cd7a35d93d1a2f2cc965985630000, against base eea160152077523c97d877af851b1a2d511c075a. The branch remained at that head when the review checks finished. This was a bounded review of the temporal-warning fix, its regression coverage, and the subsequent integration—not a restart of the kernel audit.
This closes the implementation finding in review 5194671391, distinct from the earlier Phase A fixture-design B1. This COMMENT records the completed re-review and its evidence observations; it is not a fresh final-merge validation, GitHub approval, baseline admission, semantic approval, or merge authorization.
B1 — closed
The fix preserves the existing validator findings before the direct observation guard returns:
if not ctx.acceptance_target:
problems = ctx.review_route_reasons + problemsThose findings now reach the persisted result through ctx.problems; the promotion log records the first existing warning's reason and detail. The fix reuses the validator's original findings rather than duplicating temporal validation or inventing another diagnostic. Queued acceptance remains outside this additional propagation branch.
Source: common observation guard at the reviewed head.
For the previously failing out-of-window observation:
| Confirmation | Preserved diagnostics | Outcome |
|---|---|---|
Omitted or false |
Temporal-plausibility warning | RETAIN_DRAFT |
true |
Temporal warning first, followed by observation-acceptance-disabled warning | RETAIN_DRAFT |
The single pending assertion remains the only assertion emitted. The fix does not reopen acceptance, change retirement authority, or restore reviewer-hint routing that could imply an independent reviewer can accept an observation. The RFC now explicitly describes this diagnostic ordering without changing O01–O07.
Source: observation eligibility RFC.
Regression coverage is sufficient for this fix
The capture matrix now covers 24 combinations: in-window/out-of-window timestamps × omitted/false/true confirmation × four reviewer forms. Each combination exercises both HTTP and direct pipeline entry. The out-of-window input is the concrete 2999-01-01T00:00:00Z counterexample from B1.
The assertions check more than the response: they verify that the stored result equals the returned result, warnings retain their order and severity, the promotion log and trace preserve the explanation, the raw submission digest is unchanged, exactly one new assertion exists, and accepted records and effective supersession edges remain unchanged. These checks directly address the lost-diagnostic regression while protecting the acceptance restriction.
Source: capture matrix and persisted-effect assertions.
The subsequent integration introduces no additional observation-code change. The audit-test correction from #391 is inherited from the updated base, not added to this PR's observation capability. The current owned delta remains the same nine paths.
Sources: fix-to-integrated-head comparison, current base-to-head comparison.
Fresh evidence checked during this re-review
I downloaded the reviewed head's published baseline and publication receipt, checked their archive hashes against GitHub's artifact metadata, and verified their head/base/execution bindings. Execution merge 5d4f82b5f233ea4b3328357fa7c1564c8e12971f binds the reviewed head and base and uses tree 5c2e197e522a316513931315a26f05c1c03cb91d.
Both published runs contain 4,525 collected, selected, and passed tests, including 42 observation-eligibility cases, the 12 new out-of-window cases, and all 130 correction-authorization cases. Each run has zero failures, errors, skips, deselections, unavailable cases, or expected failures, with exactly one inventoried Starlette collection warning.
I also independently recomputed normalized equivalence and authenticated the reconstructed full test inventory against its GitHub blob ID. The inventory change is precisely 12 existing matrix cases renamed to identify the in-window branch, plus 12 new out-of-window cases; no unrelated test disappears.
Evidence coordinates:
- Admitted source run 34873076525, attempt 1.
- Separate publisher 34876824763, attempt 1.
- Published baseline artifact 10361164360, archive SHA-256
0a8b1df0c333f27fda3226def37cf6767fdf89316d2a1be113e3731fb097a65a. - Publication receipt artifact 10360884861, archive SHA-256
9e399077240981ae60a3931261ca0d254f3ae07a807003479d5dfbf6703327bc. - Execution merge.
- Committed inventory, raw SHA-256
93a897ac0a42ceaddc558dde3a1aeea2339b3b6c76ffc5e1b178ecc1db6c74ff, Git blobbcab3d94c84603ab957d4057615c14135827d00d.
The detailed verification record was supplied with the completed review in the originating conversation as pr388_4ffe7bb_evidence_verification.json; the GitHub artifacts above are the retrievable evidence sources for this comment.
Remaining limits
Follow-up #389 remains separate: evidence sufficiency must not be mistaken for final acceptance permission. It is not required to close this diagnostic fix. Existing non-blocking fixture preferences are not promoted to Blockers by this review.
I did not rerun PostgreSQL tests locally, download or execute native image archives, run the complete publication-consumer/final-merge gate, or independently retrieve the original approval messages from the separate Codex task. Evidence inspection is not a runtime-test rerun and does not replace the repository's final live checks or task-user authority.
The previous request-changes finding is cleared at this exact head. No further code changes requested. This review does not authorize merge, deployment, or production activation.
1 participant
Completed: PR #388 merged at
2026-09-15T08:31:13Zas 157e130dffb1f38ca4138e55075c5dde04778cc2; Delivery #387 closed at08:31:15Z. The merge parents bind the authorized head4ffe7bbfd73cd7a35d93d1a2f2cc965985630000and reviewed base, and its tree equals reviewed5c2e197e522a316513931315a26f05c1c03cb91d.Closes #387. Part of #180; implements only the observation eligibility limit from #179. Reporting follow-up #389 remains separate.
Legacy observations could self-accept directly or be accepted by a distinct reviewer without typed acceptance semantics. This PR keeps valid observations as inert captures and blocks all new direct or queued observation acceptance, including correction successors. Historical accepted records remain readable, contestable and replayable under their existing identity checks.
Head: 4ffe7bb. Base/policy: eea1601. Tree:
5c2e197e522a316513931315a26f05c1c03cb91d. Zero Blockers, zero new Follow-ups and zero new Preferences in the bounded integration review. The later exact-head authorization was verified and executed.Boundary and resulting behavior
The one primary trust boundary is observation acceptance eligibility before new accepted-force emission. The existing promotion gate uses the validated stored assertion type for queued ACCEPT and the existing class map for direct capture. Earlier authority, evidence, scope, target, subject, rationale, bundle and terminal-state refusals retain precedence. REJECT and CONTEST retain their existing paths.
A valid direct capture appends one immutable
PENDING_REVIEWassertion and returnsRETAIN_DRAFT. Omitted/false confirmation retains ordinary diagnostics. Explicit direct or queued acceptance reaching the guard receivesHIGH_CONSEQUENCE_BLOCKED/Observation acceptance disabled. Existing temporal warnings remain first in direct capture results and promotion logs. No new accepted review, consequence, correction successor or retirement is emitted; queue visibility does not promise that acceptance is available.The approved restriction narrows correction decision version 2, C03/C10, only for observation acceptance/correction availability. An old disputed observation may remain unresolved by correction. Other assertion families, historical bytes and matching replay remain unchanged. There is no new authority, policy table, persistent state, typed semantics, grant, transaction owner, emitter, signing/custody behavior, canonical contract, production activation or publication policy. Public governed production routes stay closed. Tests use fictional fixtures and isolated disposable databases; the audit was not restarted.
Complete implementation and integration
The PR owns nine paths, 1,354 additions / 38 deletions, including 28 added runtime lines:
kernel/stages.pykernel/tests/test_observation_eligibility.pykernel/tests/observation_history.pykernel/tests/conftest.pykernel/tests/test_correction_authorization.pykernel/tests/test_review_fixes.pyconformance/review_baseline_test_inventory.jsondocs/REVIEW_DISPUTE_SEMANTICS.mddocs/rfcs/OFARM_Legacy_Observation_Eligibility_RFC_v0_1.mdThe complete observation diff is byte-identical before and after integrating merged PR #391, SHA256
ed10014d36ceb7f8504e0deed08f6947548fb8045fedd871847b96af84691de4. The separate audit test correction equals new main and is outside this PR's owned delta. Delivery #390 closed before integration. No conflict resolution, semantic drift or cross-boundary exception was introduced.The history fixture still authenticates unmodified commit
9d7541d96bc708e9270b986927d7f4b8a035454f, tree63d532112ed7c705997d0d71f5f6d0fec12928f7, from local Git objects. Its separate process creates fictional accepted history through real legacy HTTP before the candidate opens the same database. No accepted rows are fabricated or candidate safeguards disabled. O01–O07 remain unchanged, joined-row SHA256d9606e44c643fd6677306a3a06a4a011e705f55ff8281312dda34d6235fd2217.Current-head verification
93a897ac0a42ceaddc558dde3a1aeea2339b3b6c76ffc5e1b178ecc1db6c74ff.9e399077240981ae60a3931261ca0d254f3ae07a807003479d5dfbf6703327bc; receipt JSON SHA2563e963ce504bb819f47eb3d8fd125dcd22c4c90452ba13b40615f78d5e81e5801. Verification report SHA256:b50a60c397397fe8a6227b7cc5de9fe5ac974cbe73af7f48e930d0ada4d28737.Native archives were not downloaded or independently re-executed locally; their IDs/digests and receipt bindings were verified, and small index claims inspected. Source bytes were authenticated through the trusted commit/tree/blob reader without retaining its HTTP transcript. The capture verifies the recorded interval; the final live state and evidence consistency recheck also passed. Local macOS tests do not substitute for the verified hosted hash-locked Linux evidence.
Findings and historical evidence
Temporal-warning B1 is closed: the gate now carries the owning validator's existing reasons into persisted direct capture results and logs. Its earlier content review is preserved at SHA256
f6cd04415d4d072dbff2bb59c390ef02d568c9398bb6b50cf29c9a5d410492f2; it is a historical source reference. The current bounded integration/O07 review below has SHA2564db90eb21a123b726d42a6beb235f1ab79574b2e46d48bd496eb3732a83e3dd1.Two existing non-blocking fixture Preferences remain unimplemented: P1, selecting history scenarios by test-name substring; P2, an explicit base/candidate RuntimeBundle digest-equality assertion. Follow-up #389 separately owns the distinction between recorded evidence sufficiency and final acceptance. Evidence sufficiency grants no observation acceptance permission.
Historical results stay historical: the earlier combined run remains 187 passed / 1 failed. Its unchanged H1 operation-history test also failed on authentic prior bytes because host as-of time preceded database record time; read-only database-clock/current-state controls passed. No clock or source was changed to hide that limitation. Earlier source 34828888000 remains failed: baseline 1 passed 4,525; baseline 2 passed 4,524 and failed the unchanged audit overflow test. PR #391 corrected that separate stale-time expectation under its own approval and gates. Neither old results nor its receipt clear this head. Earlier PR #388 final packets remain withdrawn.
EXC-001: one shared eligibility decision. EXC-002: no duplicate policy, validator, state or emission path. EXC-003: direct/HTTP, queue, history, correction and rollback tests bind the approved invariants to durable effects and non-effects. EXC-004: superseded acceptance expectations and lost-warning behavior are corrected in place. EXC-005: the history helper serves existing O05/O06 consumers; integration adds no abstraction. EXC-006: the shared guard, existing warning propagation and mechanical prerequisite merge are the smallest complete correction.
Original same-task authority and final stop
Decision OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 version 1, named PR #388, task
01a07cc8-4157-7b33-a0ca-becb772e0e8b. Original card:msg_0d813f8071772f9a016aa6ef908cdc87d2b3edbcf339956013, session line 11819, 2026-09-13T18:46:59.909Z. Later exact approval:msg_01a09c78-89b3-75b3-91fa-c8e6d25863b8, line 12080, 2026-09-13T20:32:20.403Z:I approve OFARM2 decision OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001 version 1.Originals were directly retrieved again in order. These references are navigation; the original task-user message supplies authority.Scope stayed inside the approved observation boundary. Semantic approval, review, checks, admission and publication do not authorize merge or deployment. Final live recheck PASS: open/non-draft, MERGEABLE/CLEAN, unchanged full head/base/scope, no new findings, revocation or close/reopen. Report SHA256
1336de257460fdeacde41b637800ec9907bd041a37e30c821229c72ea948c905. The original final packet (same task, line 16663,msg_0d813f8071772f9a016aa8353e31b887d2becb9bb7dfe09743, 2026-09-14T17:56:55.306Z) and later entire exact-head authorization (line 16673,msg_01a0a42e-a9fd-72d3-af82-a41772a5b1ae, 2026-09-15T08:28:36.733Z) were directly retrieved in order. Fresh pre-merge head/state/scope/reviews/admission/revocation/timeline and receipt checks passed. New review 5207490205 explicitly closed B1 and requested no code change. The unchanged read-only consumer again verified both 4,525-pass baselines and the sealed receipt; fresh report SHA256ec1be062837b6cfa88c67aaeed17976d47ad83649926d467d12107f57900c89a. GitHub-native merge used the expected-head condition, with no admin/auto option or direct main push. Scope stayed inside observation eligibility; no deployment or production activation occurred. Next: reporting Follow-up #389 remains separate and open.Sealed bounded integration review — state recorded before fresh hosted execution
The report below is retained verbatim. Its pending checks describe the time of review; the current-head verification section above records subsequent results. It is not a second audit or a substitute for the fresh publication receipt.
PR #388 — bounded integration and O07 review
Reviewer:
/root/audit_clock_publication_preflight, 2026-09-14.Repository
samovers/OFARM2; Delivery #387; PR #388.Verdict: zero Blockers, zero new Follow-ups, zero new Preferences. This is
the one bounded review of integrating merged PR #391 and the affected O07
evidence boundary. It does not restart the full content review or audit, erase
failed evidence, complete the pending hosted gates or authorize merge.
Reviewed identity and integration proof
4ffe7bbfd73cd7a35d93d1a2f2cc965985630000.5c2e197e522a316513931315a26f05c1c03cb91d.524c31d295094c54f648e6d72941e6ff3709c9c2.eea160152077523c97d877af851b1a2d511c075a.9d7541d96bc708e9270b986927d7f4b8a035454f.Direct GitHub reads and local Git agree on the full head/base. PR #388 is OPEN
and non-draft; the local worktree is clean. Independent remote reads confirm
PR #391 merged at
17:01:08 UTCas the new base and Delivery #390 closed at17:01:09 UTC.I independently recomputed the prior PR diff (
9d7541dto524c31d) and thecurrent PR diff (
eea1601to4ffe7bb). They are byte-identical, SHA-256ed10014d36ceb7f8504e0deed08f6947548fb8045fedd871847b96af84691de4:the same nine paths, 1,354 additions / 38 deletions, including 28 added runtime
lines. There is no new observation implementation change or merge conflict
resolution hidden in that delta.
Against the first parent, the only inherited change is
kernel/tests/test_postgresql_audit_operations.py, +22/-2. Its final bytesequal merged main. The complete old-main-to-new-main diff equals that same
inherited delta. Thus the audit-test correction remains completed upstream
Delivery work; it has not been appended to PR #388's owned boundary.
The prior source-content reference is
temporal-b1/bounded-review-524c31d.md, SHA-256f6cd04415d4d072dbff2bb59c390ef02d568c9398bb6b50cf29c9a5d410492f2.Its scope, B1 disposition and limitations remain intact. This fresh integration
review identifies the new head without presenting that earlier review as a
new-head hosted gate.
Same-task authority and unchanged invariants
The boundary remains observation acceptance eligibility before new
accepted-force emission. I directly retrieved the original same-task card
and later exact user approval from the session referenced by
authority-retrieval.json, verifying their roles, IDs, full bodies, hashes andorder:
msg_0d813f8071772f9a016aa6ef908cdc87d2b3edbcf339956013, SHA-25671506d3eff24a8d2f9482b3c27a166fd4ac34082a2c308bad420104be30b3dc1.msg_01a09c78-89b3-75b3-91fa-c8e6d25863b8, SHA-256c8494a250b3a979541f5f24ee241b63b72b4b35194fdefd34d03372d09114fed.The card names existing PR #388 and decision
OFARM2-LEGACY-OBSERVATION-ELIGIBILITY-001version 1. The approval is therequired entire user sentence. I also inspected the subsequent original user
messages. They continue the work, direct the drift check, and separately
approve/authorize PR #391; they do not cancel the observation decision or
authorize PR #388's merge.
The O01–O07 RFC rows are independently verified byte-identical to the prior
head. Their joined-LF, no-terminal-LF SHA-256 remains
d9606e44c643fd6677306a3a06a4a011e705f55ff8281312dda34d6235fd2217.The entire observation-owned diff is unchanged, so no approved eligibility,
capture, warning, refusal-precedence, correction or history behavior has been
edited by this integration.
The retained-history helper is also byte-identical. It still authenticates and
runs original base commit
9d7541d96bc708e9270b986927d7f4b8a035454f, tree63d532112ed7c705997d0d71f5f6d0fec12928f7; it was not retargeted to new main.That preserves O06's historical reproduction and the related O05 fixtures.
The full inventory remains 4,525 entries, raw SHA-256
93a897ac0a42ceaddc558dde3a1aeea2339b3b6c76ffc5e1b178ecc1db6c74ff.For O07, no runtime, transaction owner, authority, contract, fixture ownership,
replay path or production route changes were inherited. The upstream change
only replaces one test's final stale-time expectation; no new observation
interaction is introduced. Current-head evidence still must be obtained:
neither PR #391's successful evidence nor PR #388's failed earlier source run
can clear this head's two-baseline and publication requirements.
Fresh local evidence and current checks
I inspected the recorded integration-tree execution and its runner rather
than repeating tests:
warning in 31.43 seconds, exit 0; runner duration 31.864 seconds.
0, 10.101 seconds; detailed log agrees with the result record.
PostgreSQL 17.10 cluster with CPython 3.12.13. The local runner invokes only
the existing module once, disables plugin autoload, and adds no retry,
mutation, timing fixture or source replacement.
and credential file removed, with unrelated containers preserved. I did not
perform another database operation to recheck removed resources.
The live metadata snapshot shows lightweight run 34872628959 in progress and
the unadmitted push gate 34872626721 successful with its expensive execute
step skipped as intended. This skipped push execution is not baseline evidence.
Root owns any later lightweight result and fresh exact-head admission after
this review. No expensive workflow was triggered, monitored or rerun here.
The local results do not replace the hosted hash-locked Linux environment or
publication receipt. I did not rerun the old audit test, the full kernel suite,
native images, historical review probes or the old audit. The earlier failed
baseline and calibrated H1 failures remain accurately recorded in their own
evidence; this integration review does not relabel them as passes.
Excellence and carried dispositions
EXC-001: the existing observation gate remains the single eligibility path;
merged main owns the separate audit-test correction. EXC-002: integration
adds no duplicate policy, state, fixture or compatibility path. EXC-003: the
byte-identical owned diff, unchanged O rows and fresh 42-case execution make
the integration-to-invariant trace explicit. EXC-004: the stale audit
expectation was removed in its own merged Delivery; no obsolete alternative
is reintroduced. EXC-005: no abstraction is added. EXC-006: the ordinary merge
of the completed prerequisite is the smallest mechanical integration and
requires no further code or decision expansion.
The two existing fixture-maintenance Preferences P1/P2 remain non-blocking and
unchanged. Reporting Follow-up #389 remains separate. This review adds no
independent-review count or other process gate. Scope stayed inside the
approved observation boundary; the distinct audit-test boundary was completed
and merged separately before inheritance.
Next: finish current lightweight checks, admit this reviewed head, obtain both
fresh hosted baselines/native evidence and a verified publication receipt,
then present a replacement complete exact-head packet unmerged for the later
same-task merge authorization.