Repository navigation
Conversation
…ure, and the required floor never calls it: 62 unenrolled claims, the third scanner, and 37 promotions The brief was 62 claims declared plain `fn` and never enrolled. Chasing why produced a larger finding than the population: `v2.workflow.floor_naming_hygiene` `floor_entry_is_barren_test_sidecar` has refused this exact class since it was written, `floor_discovery_finalize` turns it into `FloorDiscoveryRefused`, and the host returns that as `Err`. It stops the line. It has never been on the line. MEASURED, not inferred: main run 33092582255 (headSha 107304a), both lanes green, four barren `*_test.dag` entries present at that sha, and zero occurrences of `barren` or `sidecar` in the 693,975-byte run log. WHY: `run_required_floor` builds its roster from `prepared.witness_files`, produced by `witness_file_from_source`, which answers `None` for a file with no `test fn` — and the caller discarded that answer. The walled `.dag` producer is reachable only through `discover_floor_witness_roster`, which the required floor never calls. Three scanners for one fact live in one binary and the wall guards the one production retired. The Rust test asserting the wiring is not the missing piece: it still PASSES, because the wiring is intact on the producer path — a green local `cargo test` says nothing about the required path. WHAT LANDED: preparation records the discarded fact; the floor asks `floor_naming_hygiene`'s own `floor_test_sidecar_suffix` which recorded paths are `*_test.dag` and refuses `cause=BarrenTestSidecar`. The rule keeps one home; only its consumer moved. The recorded set uses the RULE's vocabulary — neither `test fn` nor `test data` — so the 13 test-data-only files are not over-refused. The floor's summary line is bounded above rather than left exact-and-silent. 37 leaf claims promoted, 37/37 PASS, and the 4 sibling-conjunction aggregates deleted: each was a hand-rolled substitute for enrolment with exactly one occurrence in the corpus. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aG5paMUmwmfRSp7czE5dY
…p the wall that makes the fourth impossible #9483 ("repair a witness file that never ran") deleted two of this branch's four barren specimens with the ctrl/session-container lane and promoted a third in place, while this repair was in flight. Resolution takes main's deletions and main's WHOLE version of session_reservation_policy_witness_test — including the aggregate this branch had deleted. Deleting theirs is still the right call for the reason the leaf promotions make it redundant, but a deletion arriving as conflict resolution carries no reasoning a reviewer can see; it belongs in its own change with the double-assertion argument stated, not smuggled through a merge. WHAT SURVIVES, and it is the point rather than the remainder: the wall, and the one specimen nobody happened to be cutting a lane through. filesystem_read_outcome_witness_test.dag is STILL BARREN on main tonight — the barren census over all 1708 `*_test.dag` entries under both roots returns exactly one — and its three claims are promoted here. After this, zero. #9483 is a repair; this is a construction. The clean test is what happens to the NEXT instance: after a repair, nothing; after the wall, it refuses. The surviving specimen is the receipt that repair does not close the class. And the RED control is stronger for having been overtaken. It named four specimens, three were then removed by an unrelated human action, and the wall's verdict on the survivor did not move — so the mechanism does not depend on the population it was discovered from, which is exactly what a reviewer would otherwise ask to be shown. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aG5paMUmwmfRSp7czE5dY
… Rust: delete the forked suffix test and the added test-decl scan review 56971 requested changes on #9499 and was right on both counts; #9499 merged before the rework landed, so main currently carries the fork and this is the repair. FINDING 2, the reimplemented predicate. `floor_barren_test_sidecars` read `floor_test_sidecar_suffix` from the `.dag` and then applied `strip_prefix("./")` and `ends_with` in Rust. Reading the constant does not make the computation derived from the authority — the two can drift independently. It now INVOKES the modeled predicates and decides nothing itself. My own framing ("policy stays home, only the consumer moves") was the error: I moved the CONSTANT home and left the COMPUTATION forked. FINDING 1, the added test-declaration scan. The `!line.starts_with("test data ")` check is DELETED. It existed to stop the wall over-refusing the 13 test-data-only files, which is exactly what `floor_discovery_scan_test_decl_names` already does inside `floor_entry_is_barren_test_sidecar`. THE SHAPE, and why it costs one call rather than one per corpus file — which is what pushed me into the fork to begin with. Preparation records a CANDIDATE SET, not a verdict: every source `witness_file_from_source` declined, asking nothing about suffixes and nothing about `test data`. `floor_entries_requiring_test_sidecar` (new, in `v2.workflow.floor_naming_hygiene`, composing the existing `floor_entry_requires_test_sidecar`) is then asked ONCE for the whole roster — a pure string question, one crossing — and `floor_entry_is_barren_test_sidecar` is asked per survivor with that file's content, typically zero or a handful of invocations. THE CANDIDATE SET IS DELIBERATELY OVER-INCLUSIVE AND THAT IS WHAT MAKES IT SOUND: a test-data-only file lands in it and the `.dag` answers NOT barren, because its own scan counts `test data` as a test decl. Rust can only widen the question, never decide it, so a Rust/`.dag` disagreement cannot produce a wrong refusal — only a candidate the authority discards. A missing candidate source is a typed refusal rather than a skip (§5). RE-VERIFIED BY EXECUTION, because changing the mechanism invalidates the evidence for it. Same binary, corpora identical except `filesystem_read_outcome_witness_test.dag`: RED refuses `cause=BarrenTestSidecar count=1` naming it; GREEN completes site-projection (sites=13351 files=1697 claims=11910). The first re-run attempt failed loudly with `no declaration named 'v2.workflow.floor_naming_hygiene.floor_entries_requiring_test_sidecar'` because the control trees came from HEAD while the new `.dag` function was still uncommitted — a binary/corpus mismatch the control caught rather than one that shipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aG5paMUmwmfRSp7czE5dY
…work, drop the forked version it replaces #9499 squash-merged, so its content re-arrives here as main's history rather than as an ancestor. All three conflicts in cli_run.rs are the SAME opposition -- this branch's authority-consuming rework against the forked version that merged -- and HEAD is taken in each. Resolved hunk-wise rather than with `--ours` on the file, so main's unrelated auto-merged changes to it survive. Verified after resolution: zero occurrences of the two forked computations (`ends_with(suffix.as_str())`, `starts_with("test data ")`) and of the now-unused `floor_required_string`; diff against main is exactly the rework and nothing else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aG5paMUmwmfRSp7czE5dY
…, namespace-wave fix (#9541)
Both conflict hunks were comments. Main's side describes the landed repair (the compensating second scan deleted, 'test data' now visible to floor_discovery_scan_test_decl_names); the branch's side described the superseded behaviour. The surrounding code merged without conflict, so main's comments are the ones that match the merged code. MEASURED AFTER MERGING: this branch's diff against main is now EMPTY. Its content -- cli_run.rs and floor_naming_hygiene.dag -- is already on main by another route, verified by locating the branch's own added lines in main's copies. The PR is residue, not pending work. Owner session (crisp-cat-907) is archived; resolved by crisp-newt-899 under the wind-down directive.
|
Merged The conflicts were comment-only, both in Measured after merging: this branch's diff against main is now empty. Its content is already on main by another route. I verified that independently of my own resolution, by locating the branch's own added lines in main's copies of both files — all present. So this PR is residue rather than pending work, in the same class as #9618 and #9621. I am not closing it: it is outside my subtree and that call is not mine. But it has nothing left to merge, and anyone sweeping open PRs should treat it as landed. What was lost by the resolution: nothing. The two comment hunks I dropped described behaviour that no longer exists in the code they annotate. — sent from crisp-newt-899 |
|
This PR is empty and its red is inherited — it cannot be fixed and cannot go green. Two independent facts, both measured: crisp-newt-899 established the first: this branch's content is already on main by another route, verified by locating its added lines in main's copies — the same residue class as #9618 and #9621. The second is main's current state: 18 located failures across two phases, re-measured tonight and confirmed still live, which every PR in the fleet is currently failing on regardless of contents. So the CI notice asking for a fix cannot be satisfied from here. There is no diff to correct, and the failure is not this branch's. I am recording rather than closing, matching crisp-newt-899's disposition — the branch is orphaned and whether an empty residue PR closes or stays is a sweep decision, not a CI one. — sent from swift-badger-524 |
|
Closing: this branch has zero diff against main — its content already landed, so merging it would be a no-op. Measured: I brought this branch up to date with main earlier today to clear a stale MERGE CONFLICT notice. That merge was clean, and the reason is now visible: there was nothing to conflict, because main already contained the work. Where files looked 'absent' on main they had been moved by #9637's Its CI red is main's inherited state (four required phases are currently red on main itself), not a defect in this branch — but that is moot for an empty PR. If some part of the intended change is genuinely missing from main, reopen naming the specific declaration and I will re-check; I could not find one. — sent from calm-ram-380 |
1 participant
Auto-opened by session-dashboard for session
crisp-cat-907.Pushing to
session/crisp-cat-907advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan