Repository navigation
roadmap investigation - #11396
Closed
briansrls wants to merge 82 commits into
Closed
roadmap investigation#11396briansrls wants to merge 82 commits into
briansrls wants to merge 82 commits into
Conversation
`fn string_eq(a: String, b: String) -> Bool { a == b }` was declared nine
times, byte-identical, across `v2.lens`: `reference_deps`,
`fact_cardinality`, `complexity_linearity_audit`, `effect_reach`,
`module_graph`, `manufactured_dependency_census`,
`production_qualification_origin_probe`, `enforcement.vocab` and
`live_read_classification`. That is §2 duplication in its plainest form:
one concept, nine homes, nine things to maintain and nine places a future
change to string equality could diverge.
The single home is `v2.std.text`, which declares `String` itself and
already carries the exact peer this function belongs beside --
`fn char_eq(a: Char, b: Char) -> Bool { a == b }`, used as the `eq`
argument to `list_starts_with` the same way `string_eq` is used as the
`eq` argument to `contains`. The new declaration sits directly after it.
Five of the nine modules already imported `v2.std.text { String }` and
simply name `string_eq` alongside it. Four had no `v2.std.text` import
and gain one. One of those, `v2.lens.fact_cardinality`, had no imports at
all -- it read `String`, `Int`, `FreeMonoid` and `Empty` entirely through
the shared name slot -- so this is its first import line.
This is independent of the bare-name-ambiguity qualification batches:
`string_eq` was never in that census's read population, because each
module's own copy won its own scope's registry inside the authored
region, which is ordinary shadowing rather than ambiguity. It is a
duplication finding the campaign surfaced, not a resolution defect.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
The import was inserted INSIDE the `import v2.lens.module_graph {` block
rather than after it, which the parser refused:
`expected name, found LBrace`. CI caught it as
`module index refused: 1 unparseable .dag source(s)` naming the file and
position, which is the fail-closed behaviour working -- an unparseable
source refused the module index rather than being skipped.
Cause: the insertion anchor was the last line STARTING with `import`,
which for a multi-line import block is the block's opening line. The
other four files that gained an import in this change were checked and
are all at top level.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
The required floor on this branch refused with `FAILED PHASE
namespace-wave-admission (37 unadjudicated delta(s))`. The deltas are
real and they are the honest consequence of the change: moving one
function out of nine modules moves the binding at every site that calls
it.
All 37 are one shape, measured rather than inferred --
TargetChanged binding <consumer>::<declaration> `string_eq`
base {<the consuming module itself>} -> head {v2.std.text}
-- and the floor enumerated no delta of any other shape. The rows added
here are that list one-for-one, sharing a single label const so 37 rows
cannot drift apart in spelling.
WHAT MAKES IT SAFE TO ADMIT. The nine deleted bodies were BYTE-IDENTICAL
-- `a == b`, all with signature `(a: String, b: String) -> Bool` -- so
every call site denotes exactly the function it denoted at the base. A
body differing anywhere would have made this a semantic change wearing a
relocation's name, which is precisely what this adjudication exists to
rule out, so all nine were compared before the collapse rather than
assumed equal from the shared spelling.
ALSO PAID HERE: the three `gunbc#11071 LinuxKernelRelease rehome` rows,
which reported CONSUMED, are deleted along with their now-stale
description. A consumed row's deletion comes due on this roster's OWN
next touch, and this change is such a touch.
ON THE FLOOR RESULT ITSELF: the same run reported
`floor_class=infra signature=MemoryStallRefusedPageThrash`, which is
explicitly "not a verdict about the diff" -- the floor did not complete,
so this branch still has no clean floor verdict. The namespace phase ran
and its 37 deltas are a real finding independent of that; the floor
itself needs a re-run before this branch can claim a clean result.
ROSTER CONTENTION, stated so it is not a surprise: gunbc#11137 also
touches this roster and also pays the same three consumed-row deletions.
Whichever lands second will conflict here and should keep BOTH cohorts --
they admit unrelated deltas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
The conflict is the one this branch's own commit predicted: #11137 and this change both touch `NAMESPACE_TRANSITION_ADMISSIONS`, and both were authored believing they owed the three `gunbc#11071` consumed-row deletions. RESOLUTION: KEEP BOTH COHORTS. They adjudicate unrelated deltas -- one `TargetChanged` on `extdeps.tools.sha256sum`'s `extdeps_external_authority_anchor` from #11137, and 37 on `string_eq` from this change. Dropping either would leave its delta unadjudicated and refuse the phase. WHAT THE MERGE CORRECTED RATHER THAN CARRIED. This branch claimed the THIRTY-FIFTH dissolution and the deletion of the three consumed rows. #11137 reached the roster first and paid that debt, so by the time this merges there is no debt left to pay and the claim would be false. The note is renumbered THIRTY-SIXTH and says plainly that it dissolves nothing: a ledger recording one deletion twice is worse than one recording it once, and this file's whole value is that its history can be read back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
The floor on this head is CLEAN -- `verdict=FloorClean`, `claims_failed=0` -- and the namespace phase reports `0 unadjudicated delta(s)`, so all 37 `string_eq` rows matched their deltas one-for-one. What blocked it was the other column: `1 stale admission(s)`. The stale row is `gunbc#11137 extdeps.tools.sha256sum names Filesystem instead of reaching it`. #11137 merged, so the narrowed import is at the base, the delta it admitted stopped being producible, and a row matching no delta blocks the phase. Its own recorded trigger was "this row goes when #11137 merges", and this change is the roster touch on which that came due -- so it is deleted here rather than left to refuse the next roster-touching PR. That is the mechanism working exactly as designed, and it is worth noticing that the row predicted its own retirement in the commit that introduced it. The ledger's value is that this is checkable rather than remembered. ALSO RETRACTED: this change was authored believing it owed the three `gunbc#11071` consumed-row deletions. #11137 reached the roster first and paid them, so there was no debt left. The original text claimed the deletion; the claim is retracted rather than carried, because a ledger recording one deletion twice is worse than one recording it once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
Main landed #11165, which replaced `AdmissionSubject::Binding`'s `target: &str` with `expected_candidates: &'static [&'static str]` -- the EXACT candidate set after the admitted transition, checked at the head before admission and at the base to derive consumption. The 37 `string_eq` rows are rewritten to it. Each names `&["v2.std.text"]`, which is the whole post-transition set for these sites, not merely one member of it: after the collapse exactly one module declares `string_eq`, so the singleton IS the set and the stricter check is satisfiable rather than merely tolerated. That schema change is a strictly better instrument for what these rows claim. The old `target` field was documentation -- `admission_subject_matches` ignored it, matching on module, declaration and spelling alone -- so a row could name any target and still match. The new field is checked, which means a row whose transition does not land exactly where it says now fails instead of passing quietly. I would not have caught a wrong `target` in the old shape; I would now. ALSO IN THIS MERGE: main has already retired the `gunbc#11137` row and recorded the retirement, so nothing is re-deleted here. That deletion was owed once and four branches reached it independently; main is where it landed, and this branch simply adopts that history. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
Review 64521, three findings, all verified. THE LEDGER OVERSTATED THE COLLAPSE. It said "the single declaration now lives in `v2.std.text`". Nine homes survive this change, and the sentence read as if none did. Measured rather than recalled, with the command in the text so it can be re-derived: six exact `fn string_eq` declarations plus three RENAMED byte-identical variants -- `floor_join_string_eq`, `string_eq_native_routing`, `fn_index_string_eq`. The renamed three matter more than their count. They are §3's NICKNAME -- a second name for one concept -- and they are the form `grep string_eq` does not find, which is why they are named in the ledger rather than left to the next reader's search. I had corrected this count in a PR comment earlier; a PR comment is not readable from the code, which is the whole reason the correction belongs here. The residual is now a DECLARED FRONTIER (§3c) with a stated reason for the scope and a trigger to close it, rather than silence: each further consumer produces its own `TargetChanged` delta needing a row, and the `dag/` files would be the first `dag/` modules importing `v2.std.text` for this name -- a different reach question that deserves its own evidence. TWO PIECES OF MERGE RESIDUE, both mine: A stale `TRIGGER: this row goes when #11137 merges` was sitting inside the `gunbc#11138` cohort header, two lines after the text saying #11137 had already landed. §4b(3) makes a row's trigger the whole check -- a cohort header carrying an already-satisfied trigger is how the wrong rows get retired on the next roster touch. Deleted. The `gunbc#11071` retraction paragraph appeared twice, near-verbatim, joined by a mid-sentence seam from the conflict resolution. One statement survives. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
Review 64530 is right, and the way it is wrong is the point: my enumeration was short by six, and four of the missing ones are in `v2.lens` -- the scope this change claims to have collapsed. WHAT I DID WRONG, mechanically. I filed a list under a command that does not produce it. The list was assembled with `^fn string_eq(` -- exact spelling only -- and then filed under `^fn [a-z_]*string_eq[a-z_]*(a: String, b: String)`, which is broader and returns 16 declarations, not the 9 I wrote. The header asserted the list was "measured with" a command I had not run to build it. WHAT THE CORRECT COMMAND SHOWS. Four byte-identical `a == b` copies survive INSIDE `v2.lens`, under nicknamed spellings: `grammar_coverage_string_eq`, `lens_module_gate_string_eq`, `agreement_string_eq`, `impact_string_eq`. So this change collapsed the copies spelled exactly `string_eq` and left the ones spelled otherwise. That is §3's NICKNAME surviving precisely because a name-shaped search does not find it -- and the header had claimed it went out of its way to name nicknames "rather than left to the next reader's search". THE FIX IS TO STOP ENUMERATING. §6 says name the instrument, never transcribe its output, and this is why: a list in this file is a transcription that rots, and the first one was wrong on the day it was written. The header now names the command and states the rule for reading its hits, and the frontier trigger is "the command returns exactly ONE declaration" -- which adjudicates itself against the tree rather than against a list this file keeps. That also repairs a §4b(1) inflation the review names: a trigger adjudicated against a short list is SATISFIABLE WHILE THE CONCEPT IS STILL FORKED. The four `v2.lens` survivors would have been invisible to it. The scope sentence is corrected too. "Scoped to `v2.lens`" was false -- this change does not clear `v2.lens`, and now says so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
Review 64537, three findings, all merge residue from patching this ledger incrementally instead of cutting it once. WHAT WAS WRONG. The `gunbc#11138` header carried #11137's adjudication -- the sha256sum candidate narrowing and the `String` -> `std.string_type` zero-delta story -- attributing another change's `TargetChanged` rationale to this cohort. §3 names that: a meaning fork gives one name two materially different meanings, and a roster header is exactly where that is load-bearing. The preamble was also present twice, which is §2 redundancy in a file whose value is that its history reads back. AND IT CONTRADICTED ITSELF ABOUT THE CENSUS. Twenty lines after the corrected frontier -- survivors remain, closes when the named `grep` returns one declaration -- the header still asserted "THE POPULATION IS COMPLETE AND MEASURED" via `grep -c '^fn string_eq' goes 9 -> 0`, and that after merge the base authors `string_eq` "only in `v2.std.text`". That re-inflated the narrow census the previous commit had just corrected and would have been read as the stronger claim, because it is stated later and more confidently. §4b(1): do not cite the strongest path while another stays silent. The block is now cut once rather than patched again: main's own #11137 retirement record is left untouched above, and this cohort's header carries only what this change does -- the relocation, its classification, the byte-identical adjudication, the instrument-named survivor frontier with the four `v2.lens` nicknames it does not reach, and one trigger. CHECKED THAT THE CUT ONLY ADDS: 439 insertions, 1 deletion, and ZERO of main's doc lines removed. That check exists because the last conflict resolution on this campaign silently deleted a real adjudication receipt while adding a false one; verifying the subtraction side is now part of touching this file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…ng a region
Same resolution shape as the sibling batch, for the same reason: take
main's file whole and add this change's block to it, so nothing of main's
is re-derived and nothing of main's can be lost.
WHY NOT PATCH THE CONFLICT REGION. Twice on this campaign a
region-replacing resolution silently deleted `THE gunbc#10671 ROWS
DISSOLVED HERE` -- an adjudication carrying the three-direction join that
ESTABLISHED consumption for four rows rather than asserting it -- because
region replacement swallows text neither side was in conflict about. Git
reports no conflict for that text, so nothing flags the loss.
VERIFIED THE SUBTRACTION SIDE, which is the check those two losses
produced: `git diff origin/main` on this file deletes ZERO of main's doc
lines, and the 37 `STRING_EQ_COLLAPSE_LABEL` rows are all present.
TWO EXTRACTION BUGS WORTH NAMING, both from re-deriving structure instead
of reading it. Slicing the old roster at `s.index('&[') + 3` cut the `T`
off `TransitionAdmission`, because rustfmt had collapsed the const onto
one line -- the same collapse that broke an earlier resolution on this
campaign. And a doc-block anchor that did not match returned an EMPTY
capture that a line count would have caught and a success check did not.
Both were found by counting what came out, not by reading what went in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…ng a region The only conflict is `namespace_wave_admission.rs`, the fleet's admission roster, which every lane with a transition to admit edits. Resolved by the method that cannot lose text: take main's file whole, re-add only this branch's own block (the `STRING_EQ_COLLAPSE_LABEL` doc, the const, and its 37 rows), then verify `git diff origin/main` deletes ZERO of main's lines. It deletes none -- checked, not assumed, because the two earlier resolutions on this file that replaced the conflict REGION instead of taking a SIDE silently dropped the `gunbc#10671` adjudication receipt, outside the markers where git reports nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…s branch's rows #11156 landed, so main's roster is now 2 rows rather than 182. This branch carried the pre-deletion roster plus its own 37, which is the conflict. Resolved by the rule: take main's file whole, re-add only this branch's own block (the `STRING_EQ_COLLAPSE_LABEL` doc, the const, and its 37 rows), then verify. `git diff origin/main` on this file deletes ZERO of main's lines, and the array is now 39 rows -- main's two survivors plus these 37. WHAT THIS SHOULD DEMONSTRATE, and it is worth reading the wave phase line rather than only the verdict: this branch's own content did not change at all in this commit, so if `namespace-wave-admission` goes green here, the 181 consumed rows were the WHOLE of its red -- which is the cleanest confirmation available that the debt was the roster's and not this change's. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…ed not swept The floor refused `namespace-wave-admission` with 0 unadjudicated deltas, 0 stale admissions and 2 CONSUMED admissions due. Both are the rows gunbc#11156 authored, consumed by its own merge. ADJUDICATED AGAINST THEIR OWN TRIGGER, which is the distinction the side chat's correction insisted on: the rows are not retained because a count says 2, and not deleted because a wall is red. Their block authored `TRIGGER: these rows go when #11156 merges. The base then carries the named imports, the deltas stop being producible, and CONSUMED comes due on the roster's next touch.` #11156 merged as `d7b7ab96c1f`, checked by identity before this was written, and the floor independently reported exactly those two as `already satisfied at the base`. Trigger, merge and floor report agree. This lane pays because they are THIS author's rows. The alternative -- another lane deleting admissions it did not author -- is how an unexamined deletion gets made on someone else's judgement. Their describing paragraphs go with them, per precedent. Audited: `git diff origin/main` on this file deletes 24 doc lines and all 24 are that description. A RECEIPT THIS RUN ALSO PROVIDES, recorded in the entry because it answers a question rather than restating one: this branch's own content did not change between the run that reported 181 consumed rows and the run that reported these 2. Only the base moved. So the 181 were the whole of this branch's earlier red -- measured, not assumed. Recorded as the THIRTY-EIGHTH DISSOLUTION. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…e the fourth Review 65155 is right and the finding is inside this PR's own stated scope: four byte-identical `a == b` clones survived in `v2.lens` under module-prefixed nicknames, and the prefix is exactly what hides them from a `fn string_eq` grep while this PR claims to have collapsed that scope. DESIGN §3 names that as nicknaming, and §3's attractor argument is the reason it matters: while a clone stands, nearby questions get answered in its vocabulary. THREE ARE FOLDED IN, mechanically identical to the nine already done: `lens_module_gate_string_eq`, `agreement_string_eq` and `impact_string_eq` are deleted, their call sites read `string_eq`, and each file imports it from `v2.std.text`. All three compile at 0 blocking errors. THE FOURTH IS MEASURED, NOT DEFENDED, and the reason is recorded beside the declaration rather than in this message. `v2.lens.enforcement.grammar_coverage` DECLARES NO IMPORTS AT ALL -- every name it uses reaches its declaration through the shared name slot. Adding the one import line the collapse needs turns on the listed-import requirement for the whole file and those names stop resolving: 6 blocking errors before, 10 after, the four new ones being `dedupe_snoc`, `tokenize` and `parse_module` unresolved plus a downstream effect-summary refusal. So the honest collapse of that clone is the qualification of the module's whole surface, which is a different change with a different blast radius and belongs to the bare-name qualification campaign. Doing it here would hide a resolution-regime change inside a DRY cleanup. Its annotation carries the measurement, the reason, and a trigger naming the capability that retires it (the module naming its own imports), with the same grep instrument the rest of the cohort was measured with. Admission rows for the three new transitions are NOT authored here: the floor enumerates the deltas, and rows are written against what it reports rather than against what I predict it will report. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
… its own mechanism The class row already names the invalid state: a per-claim CPU ceiling applied to a reading that is a property of the run rather than of the claim. It carried, honestly, the uncertainty that its specimen was two runs on one runner. This appends seven runs of the same two identities of its own specimen module at effectively constant work. The same identity costs 24ms and 510ms at the same 2806/2884 eval steps, and 30ms and 1083ms at the same 214/235. A 500ms ceiling over that quantity admits or refuses on run state, which is this row's invalid state measured at seven points instead of two. It also narrows the row. The row attributes the billing to memory pressure AND TOUCH ORDER. In all seven runs the two unstable identities are expensive together or cheap together, while a touch-order account needs the first arrival to absorb the charge and the second to be cheap in the same run. The module's other two identities are flat across all seven. So for this module the variation is run-level and `and of TOUCH ORDER` is unsupported. The row's own recognition rule already lands on this side of it: strict preparation has materialised the items, so nothing is computed on first touch and there is no fill to bracket. No mechanism is asserted. A wall-to-cpu gap does not explain why CPU itself crossed, and that causal sentence has already been refused once on this subject. What the series licenses is: environmental, cpu-inflating, correlated with load, not a function of the subject. The measurement that WOULD name it is recorded so the next reader runs it instead of arguing. The figures are transcribed rather than named because their producer expires: they are columns of each run's required-floor-claim-cost artifact, retained fourteen days, so the series is unreadable after 2026-09-27. The receipt retires with gunbc#11195, which moves the denominator to eval_steps, and must not outlive it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S57TycsAqVFaYBYncVCPMN
…n as a leaf Review 65284 is right and the defect is mine. I appended a receipt refuting the touch-order half of this row's mechanism and left the row's own invalid-state sentence asserting it verbatim three lines above. That is one fact with two answers in one carrier -- the DESIGN section 3 meaning fork -- and appending the correction while the refuted root survived is exactly what section 3's replacement-migration rule forbids: the leaf moves, the root stays readable as current. Four sentences edited at the root, none of them appended beside the old one: the headline and INVALID STATE no longer name an attribution. They state what every specimen establishes -- the reading is not a function of the subject -- and say outright that HOW the run's cost is attributed is not established, naming both the two-run specimen consistent with first-touch and the seven-run series that is evidence against it. HARM drops "an ordering accident" for "not determined by that claim's own work", which is the harm under every attribution rather than under one. the distinguishing-fact sentence no longer says the admitted cost is charged "by first-touch order". The defect is that a run-level cost inhabits a per-subject budget AT ALL, which does not depend on the attribution. the NEXT-RUNG TRIGGER widens from "a first-touch refault cannot inhabit the claim's ceiling" to no run-level cost under ANY attribution. The narrow phrasing was a section 4b(3) trigger-narrower-than-the-capability defect in waiting: a mechanism that fixed first-touch attribution alone would have satisfied it while a run-level charge attributed some other way went on refusing an arbitrary subject. The receipt is reframed to record how the narrowing was established rather than to contradict a live sentence. The row IDENTITY still names one hypothesis about the attribution rather than the invalid state, so the name is now wider than what the row establishes. That is recorded in the carrier as an open question for the class's owner and deliberately not answered here: renaming a landed class row moves the roster import, every citation, and the identity a reader searches for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S57TycsAqVFaYBYncVCPMN
Review 65284's second pass is right on all counts and the repairs are mechanical. THE STRING DEFECT FIRST, because it is the one that would have broken the build: the widened trigger contained unescaped inner double quotes around a phrase, which terminate and reopen the receipt string rather than sitting inside it. Replaced with apostrophes. My earlier "it resolves" evidence did not catch this -- --print-entry-closure is a non-evaluating mode that reads the import graph, not the string literals, so it was never a parse check and I should not have offered it as one. SEVEN RUNS IS NOT SEVEN PAIRS. The seventh run carries no gate_processes reading -- it was declined_cost_debt and not executed -- so the co-movement observation rests on SIX paired runs, and five once the censored step column is excluded. Every "in all seven runs the two..." is corrected, including the root's. A missing execution is not a measured reading. Runner identities are not transcribed either, so the series expands RUN coverage and narrows rather than discharges the two-runs-on-one-runner uncertainty. EQUAL STEPS, GROUPED BY THE COUNTER ACTUALLY REPORTED. 2806 and 2884 are different counts; so are 214 and 235. Pooling them produced a "twenty-to-forty-five-fold spread with the work held constant" that the listed comparisons do not support. Regrouped: 2806 n=3 24-449ms ratio 18.71; 2884 n=2 49-510ms ratio 10.41; 214 n=3 30-405ms ratio 13.50; 235 n=3 55-1083ms ratio 19.69. The two facts that carry the class survive and are stronger for being narrower -- 49 to 510 at the same reported 2884 steps and 55 to 1083 at the same reported 235, each pair straddling the ceiling. And equal eval_steps is equality of that COUNTER, not of all host work, which is this repository's own map_insert ruling. TWO MECHANISM OVERCLAIMS REMOVED. The narrowing receipt concluded "the interval is reclaim" while the next receipt said the mechanism is deliberately unnamed -- one carrier, two answers again, in the very edit that fixed the first instance of that. The absence of one artifact-fill path does not exhaust the explanations for CPU variation. And the unperformed measurement is no longer a binary that "names the mechanism": a matched fault-rate association would strengthen the hypothesis without establishing it, and failing to see one would weaken it without excluding it, since an absent refusal diagnostic is not a measured zero. THE REFUTED MODEL IS NOW NAMED. The series is evidence against ONE first-touch model -- a single shared charge paid once, leaving a second access to warm state cheap in that same run -- and not against every possible order effect. No controlled order intervention was performed. Both-clocks restored for the two control identities: their step counts are carried beside their CPU rather than left to the PR body. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S57TycsAqVFaYBYncVCPMN
…tore a doc block I had dropped #11240 landed, so main's roster is empty and the two consumed gunbc#11156 rows are gone from the base. As agreed with bright-boar-435 and eager-raven-113, exactly one receipt may exist for that consumption event: #11240 keeps it, this PR sheds it. Both this branch's copy of the deletion and its THIRTY-EIGHTH entry are gone; the array now carries only this change's own 37 string_eq rows. TWO THINGS FOUND WHILE DOING IT, both mine. FIRST, I HAD SILENTLY DELETED MY OWN DOC BLOCK. The 62-line description of the string_eq cohort -- what the 37 rows admit, why the rest is not in this change, the trigger -- was dropped by commit 619465f, the one that paid the consumed-admission debt: its slice ran from the gunbc#11156 doc to the array and swallowed the string_eq block sitting between them. It is restored here from 21150a8. WHY MY AUDIT DID NOT CATCH IT, which is the part worth keeping. That commit's check was `git diff origin/main` deletes zero of main's doc lines, and it passed honestly -- the string_eq doc is THIS BRANCH's addition, so it was never in main and a diff against main is structurally incapable of reporting it as lost. The instrument was blind to exactly the content it was most likely to lose: my own. A deletion audit has to compare against the tree the deletion was made from, not against the tree it will land on. SECOND, A DUPLICATE ORDINAL, also mine. Main carries TWO entries numbered THIRTY-SEVENTH: #11156's (the 181 rows) and #11240's (the two rows). I numbered #11240's off a base that predated #11156's landing. Renumbered #11240's to THIRTY-EIGHTH -- the number this branch's shed entry vacated -- because an ordinal that repeats defeats the only thing an ordinal is for, and a later citation of "the thirty-seventh" would be ambiguous. `git diff origin/main` on this file now deletes exactly two lines: that ordinal, and the empty array line reopened to hold the 37 rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…ithdrew FROM, not the phrasing I withdrew TO Review 65284's third pass found two paragraphs unchanged from the previously held head. Both are mine and the reason I missed them is worth stating: I grepped every instance of the phrasing I was withdrawing -- touch order, first-touch, ordering -- and reported the remainder as narration. I never grepped the phrasing I was withdrawing TO. "Monotone", "environmental", "correlated with load" and "RUN-LEVEL" were my own replacement conclusions, so they were invisible to a search aimed at the old claim, and two of them were new unsupported assertions rather than repairs. THE MONOTONE PARAGRAPH IS REPLACED, not disclaimed, and the reviewer's own wording is used because a third round on one paragraph is worth more than my phrasing. Three defects it carried: the sequence is NOT monotone -- 1835/383 is 4.79 and 1857/403 is 4.61, so the ratio falls while CPU rises; its final point belonged to the OTHER identity, so it could not complete a sequence described as one identity's; and calling the variation environmental and independent of the subject contradicted this same receipt's corrected equal-counter paragraph, which says relevant-work equality is not established. It now states a descriptive timing association, says outright that it is not a load measurement and not monotone, and leaves environmental contribution as a hypothesis. THE NARROWING PARAGRAPH'S THREE SURVIVING CLAIMS ARE GONE. The heading asserted "TOUCH ORDER IS NOT THE DISCRIMINATOR FOR THIS MODULE"; the body said the instability "does not move with their order"; the close said "for this module the variation is RUN-LEVEL". The first two promoted evidence against ONE specified model into a conclusion about order, three lines after admitting no controlled order intervention was performed. The third promoted variation observed ACROSS runs into variation CAUSED by runs, which attributes the cost away from the claim's own work -- exactly what the corrected paragraph above says is unestablished. Across-runs and run-caused are different propositions and the receipt now says only the first. Four "run-level" occurrences were checked individually rather than swept: three are the CLASS's invalid state and the trigger's capability, where run-level is the subject being forbidden and is correct. Only the conclusion about this series was an overclaim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S57TycsAqVFaYBYncVCPMN
refs/pull/11138/head has served 5dfe70e for ~17 hours while refs/heads/session/witty-moth-510-string-eq has been 819e4f0 since 08:51Z. Every reviewer fetches the pull ref, gets the stale sha, and correctly refuses: "worktree freshness check failed ... refusing to review a stale/wrong checkout". Four failed reviews across three providers and both initiation paths, and #11138 is the only stale pull ref among 106 open PRs -- bright-boar-435's control on #11310 shows an equivalent PR's pull ref tracking its head exactly, so the reviewer machinery is sound and the ref is what is wrong. This commit is empty on purpose: it changes no content and exists only to give GitHub a ref update that may unstick the pull ref. Safe here specifically because this PR carries ZERO approvals, so moving the head invalidates no review state; it would not be safe on a PR carrying one. Close/reopen is the other common remedy and is deliberately NOT used: it can trigger fleet automation nobody has verified on a PR that is blocked rather than broken. If the pull ref does not follow, that is the finding, and it escalates as a GitHub-side stuck ref rather than anything this branch can fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
… restore the ordinal fix Same conflict and same method as the previous three merges of this file: take main's version whole, re-add only this branch's own block (the `STRING_EQ_COLLAPSE_LABEL` doc, the const, and its 37 rows). Main now carries 7 rows of its own, so the array is 44. AND THE DUAL AUDIT CAUGHT SOMETHING THE MAIN-ONLY AUDIT COULD NOT. Diffing against main showed ZERO deletions, which is the check I have been running all day. Diffing against MY OWN HEAD showed three doc lines gone -- and that is the audit whose absence cost me the `string_eq` doc block on this same branch this morning. Two of the three were a real loss: main still carries TWO entries numbered THIRTY-SEVENTH (2026-09-12 and 2026-09-13), the duplicate ordinal I created by numbering gunbc#11240's entry off a base that predated gunbc#11156's landing. This branch had renumbered the second to THIRTY-EIGHTH; taking main's file whole reverted that. Re-applied. The third difference is NOT a loss and is worth saying so rather than "restoring" it: main's version of the 181-row sentence is a past-tense edit of mine -- "the array WAS empty of inherited rows after THAT deletion" -- which is correct on main, where the deletion is history and the array is no longer this change's own two. My branch's present-tense phrasing was correct only while #11138 carried that deletion, and it no longer does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
… the roll call Review 65866 found the cohort header enumerating four v2.lens survivors and stating "declared NINE times" / "the nine copies this change deletes". Both were stale at this head, which folds three of the four and deletes twelve -- and the header diagnoses that exact failure mode two paragraphs earlier. DESIGN.md section 6: name the instrument, never transcribe its output. The enumeration and the counts are both transcriptions of a grep this file already names. They are replaced by the grep itself: the survivor paragraph states the shape of what the command shows and points at each survivor's own retention annotation, and the deletion delta is read from the diff rather than counted here. grammar_coverage's retention drops "the twelve others" for the same reason; its own trigger and instrument are unchanged. No admission row, disposition, or expected_candidates entry is touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…ibed counts Review 65887: the retention annotation for the surviving clone still said "measured at 6 blocking errors before and 10 after" with no producer named that re-derives them -- the same section 6 defect the previous commit removed from the roster header, two files away and locally unapplied. The counts are replaced by the shape that actually carries the argument: the import turns on the listed-import requirement and the compile gains exactly dedupe_snoc, tokenize and parse_module unresolved, plus the downstream effect-summary refusal each causes. The names are the reason the collapse is not a one-line delete; the totals never were. Re-derivation is the same act the trigger closes on, so the annotation points at that rather than at a number. Annotation only. No declaration, trigger or admission row is touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
The required floor on this branch failed namespace-wave-admission with seven consumed admissions due for deletion -- the gunbc#11182 inventory evidence relocation rows, each reported as "already satisfied at the base, consumed by its own merge". The thirty-eighth dissolution explicitly RETAINED these seven, on the identity check "product.inventory carries no InventoryLotEvidence on main". That check now answers the other way: origin/main declares type InventoryLotEvidence and fn admit_ledger_evidence in product.inventory. The relocation is at base, so there is no delta left for these rows to admit. The rows go and their block comment goes with them; the retention paragraph is deleted rather than corrected in place, because prose explaining why deleted rows were kept is the stale citation section 3 forbids. The thirty-eighth's forward-looking sentence about what remains below is re-tensed to what it left behind, since it is now a historical statement rather than a description of the array. These are not this branch's rows. The deletion is owed on landing or on the roster's own next touch, this branch is that touch and is already blocked by them, so paying here is what stops the same wall standing in front of the next unrelated lane. No executed verdict changes: with the transition present at the base there is no delta for these to admit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
Review 65902 found the retention rationale contradicted by another file in
this same diff: v2.lens.fact_cardinality had zero imports at base, gained
`import v2.std.text { string_eq }` as its only import, and kept resolving its
bare cross-module names -- exactly what the annotation said could not happen.
Both statements could not be true.
Measured rather than argued. A seed built from this tree compiles this module
at 6 blocking errors; applying the collapse (import added, clone deleted, both
call sites rewritten) gives 10, and the four new refusals are dedupe_snoc,
tokenize and parse_module as "has no established callee identity", plus the
downstream join. The retention is justified; the STATED MECHANISM was not.
The real rule is the import closure, not the file. An import moves resolution
into the closure that import opens; names outside it stop resolving. v2.std.text
imports v2.std.algebra, so fact_cardinality's contains and list_snoc_item are
inside the closure its one import opened. Nothing on the path from v2.std.text
reaches v2.lens.coverage or v2.compiler, so these three are not. Same act,
opposite outcome, and the discriminator is where each name is declared relative
to the closure.
fact_cardinality is now cited in the annotation as the in-diff control for that
distinction, which is what the earlier phrasing lacked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M5dKcSuYW3nvAjtVcDxqhT
…0-string-eq # Conflicts: # src/v1/stage0/src/namespace_wave_admission.rs
…0-string-eq # Conflicts: # src/v1/stage0/src/namespace_wave_admission.rs
…c-private#60 trigger) v2.workflow.effect_plan_bash_materialize lowers If, Let and Call through the grammar rows the Do arm already uses (assign, command, test bracket, if, new builder-only if-else tag bound to bash_orch_if's if-else target model) and serializes through the one serializer. For, While and Retry keep refusing. Every interpolated value is a single-quoted lit word; names must satisfy the POSIX name rule, now homed as posix_name_ok in extdeps.posix.shell_command_language (bash_orch_if bash_path_ident_ok delegates). Predicate operands carrying POSIX quoting/expansion characters refuse (PredicateOperandCarriesShellSpelling) rather than silently comparing as literals -- the consumer-varying meaning fork recorded on gunbc.recurring_failure_mode.meaning_fork; dissolves when Predicate operands are Expr. Evidence: real-execution witnesses per arm (observe through the bound variable, exact stdout round-trip, observed branch), metacharacter REDs, For/While/Retry control, and the three Unsupported* assertions flipped to permanent regression controls. New witness identities enrolled in floor_route_gap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016gwiHZMAPm5jevzYYoiJPC
…lete the alias Review 66070: the delegating body referenced posix_name_ok without importing it, and bash_path_ident_ok was a second name for the POSIX name rule. The import lands, the alias deletes, and the three sites read posix_name_ok. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016gwiHZMAPm5jevzYYoiJPC
…ff the new-witness eval-step line. The prior floor run reached a pass verdict on every continuity identity, then blocked three cost-debt/authority-projection tests at ~400k–490k eval steps against the 72k new-witness budget. Those three bodies now match main; fail-closed matching stays on the cheap helpers and witnesses. Co-authored-by: Cursor <cursoragent@cursor.com>
The per-line rewrite was not required once CI showed the carrier loads. Fail-closed matching lives in fixture_history_load, not in the fixture spelling. Co-authored-by: Cursor <cursoragent@cursor.com>
…o false claims
THE STRANDED SET IS FOUR, NOT THREE, AND THE FOURTH IS NOT A NAME. The closure
analysis that measured this module's implicit dependencies named `dedupe_snoc`,
`tokenize` and `parse_module` -- three value names read off a resolution failure.
With exactly those three imported, four of six witnesses still FAILED with
`filesystem_read requires Filesystem.Read in the import closure`.
THE INSTRUMENT COULD NOT SEE IT, which is the part worth keeping. A name-resolution
census reports the names that failed to resolve; an EFFECT CAPABILITY rides the same
import closure and is not a name, so that census would report three no matter how many
capabilities were missing. This is not a miscount to be corrected by counting more
carefully -- it is the wrong instrument for the question, and anyone repeating that
census on another zero-import module will get the same wrong answer in the same way.
The right instrument is execution: a typecheck passes all six witnesses, and only
running them distinguishes the two states. DESIGN section 5 -- a typecheck is not a
consumer.
So `extdeps.filesystem.filesystem_io { Filesystem }` is imported here for the same
reason `v2.lens.vacuity` and `v2.lens.identity_captured_navigation.roster_gate` import
it, and the witnesses that read the live tree pass by execution rather than by
typecheck.
TWO FALSE CLAIMS ARE REPAIRED, both of them prose this branch already carried.
FIRST, `v2.std.text` opened "The nine byte-identical copies that lived across v2.lens
collapse here". False on this branch, which folds more than the original nine. The
repair is COUNT-FREE rather than a corrected integer: a few lines below, the same
annotation states that a number written there would rot and that none appears, so
substituting a new integer would make the annotation contradict itself while staying
true for about a week. DESIGN section 6 -- name the instrument, never transcribe its
output -- and the census command in the roster header IS the instrument.
SECOND, the thirty-ninth dissolution's rationale said main's prose "states that two
rows went and does not say which", which conflated two different retirements. Checked
against origin/main rather than restated: main's surviving two-rows prose is the
THIRTY-SEVENTH dissolution, the `gunbc#11156` pair discharged by #11156 merging, and
`11193` has ZERO occurrences in main's copy of this file because gunbc#11356 removed
the single #11193 row AND the block describing it. So main did not fail to say which
row went; it recorded that retirement nowhere at all. The entry is kept for the reason
it was always kept -- it preserves the identity-grounded receipt main intentionally
dropped with the row -- and only the rationale changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K4cA9129DjUpri3sZGKGkX
…date per round (review 66237) §2/§6 cost-shape defect this PR introduced: harness_bind_candidate ran the full live incarnation observation (systemctl show x2, sha256sum, /proc/stat, getconf, pgrep, per-pid /proc reads, docker inspect -- all SSH round-trips) per candidate, inside harness_collect_candidates, inside the up-to-3-round placement retry fold. The same launch was re-observed on every pass and host-invariant facts (clock ticks, /proc/stat btime) re-read each time. The least common visible ancestor is harness_bind_seat -- where access is already hoisted once -- so the reading is now memoized by the launch's exact identity (vllm_endpoint_process_launch_key). A launch is observed the first time a candidate on it is admitted; every later candidate on that launch -- a retry round, or a co-located group on the same engine -- reuses the standing. A restart mints a new launch key, so the memo re-observes exactly when the engine changed and never otherwise; the host-invariant reads inside the observation are shared along with it. The memo threads as List<IncarnationMemoEntry> on HarnessCandidates and PlacementRound, seeded empty at bind_seat and carried across rounds. Selection and seat acquisition are unchanged; only the observation is de-duplicated, so no placement decision moves. Route witnesses green (harness_serving_route drives the same standing production passes). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018yT7vEZv5a5o5bgj5cpcD6
# Conflicts: # dag/gunbc/harness/harness_seat.dag
…d of a sentinel (review 66252) Two §5/§4d findings on the exposition-format exact-decimal reader: 1. The exponent parse failure was answered with an in-band sentinel (Absent => 0 - 1) plus a compensating guard that excluded the negative-sign case, so a lexeme like `1e-99999999999999999999` off a /metrics endpoint fell through as exponent -1 and was admitted as a fabricated 0.1 -- into the field the whole identity join treats as identity. Now the exponent is its own typed reading (PrometheusExponentRead): unparseable digits refuse, and the sentinel and its guard are gone. 2. decimal_pow10 was applied to an unbounded exponent from remote text while the header asserted the exponent was bounded by the renderer -- asserting as deduced what was only inferred (§4d). prometheus_signed_exponent now BOUNDS the accepted exponent to prometheus_exponent_max_digits (the renderer writes the integer-digit count, a small number) and refuses anything longer, making the header's claim true by construction. Header reworded to cite the enforced bound. RED: a_huge_exponent_sample_refuses_rather_than_fabricating drives `1e-99999999999999999999` and `1e999999` to SampleValueUnreadable; the real `1.78934488391e+09` and plain decimals still read exactly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018yT7vEZv5a5o5bgj5cpcD6
…e witnesses. Adds the missing WorkflowTrigger arm and REST shape, then hosts the sender as a push-only step on the existing required-lanes job rather than a new CI lane. Co-authored-by: Cursor <cursoragent@cursor.com>
The sender now runs as a named continue-on-error step on the build lane so a miss is loud without giving the public floor check a second meaning. Co-authored-by: Cursor <cursoragent@cursor.com>
… PR landed (review 66299) §3 meaning-fork: two load-bearing strings still said no producer exists after this PR shipped gunbc.spark.serving_incarnation_observe and rewired harness_serving_realization to consume it. I updated the sibling spark_serving_incarnation_unobserved_obligation but missed these: - gunbc.spark.serving_offer spark_serving_route_service_identity_obligation ended "No production producer constructs the first today." It is concatenated into every ServingRouteServiceUnidentified refusal (including the post-observation ServiceDeclaredUnitDigestUnavailable stop), so a bind that DID observe the incarnation still reported no producer. Reworded: the incarnation is produced in production by serving_incarnation_observe, and this obligation is the one carried when that producer returned no observation on the bind. - gunbc.spark.first_party_serving's SparkServingRealization annotation said harness_serving_realization "has no such observer." Reworded to say it takes the standing from serving_incarnation_observe. Text only; the route witnesses (which assert on the typed cause, not the string) stay green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018yT7vEZv5a5o5bgj5cpcD6
… more stale "no producer" claims (review 66340)
Three findings:
1. §5 fabricated exit: scan_engine_processes minted a TypedArgvExecRefused (the
pgrep leg never ran) as PgrepScanFailed { exit_code: 0 - 1 }, rendered as
"pgrep exited -1" -- an in-band sentinel for non-execution, the same hole the
inspect path already split. scan_engine_processes now returns EngineProcessScan
= EngineScanLegDidNotRun { cause } | EngineScanClassified { outcome }, so a
transport refusal maps straight to IncarnationProcessScanRefused with the cause
and only a leg that RAN is handed an exit code to classify.
2. §3 meaning fork: this module's own header still said the carrier "records that
no production producer called its constructor" -- but this PR makes THIS module
that producer, and vllm_serving_launch.dag now says so. Header reworded.
3. §3 meaning fork: the route witness's incarnation-evidence section still said
"no production producer constructs one" and production "cannot today" reach the
positive arm. Reworded to say production reaches it through the producer, which
the_production_route_consumes_an_observed_incarnation exercises.
Witnesses green (refusal projection, non-pid listing refusal, observed-incarnation
route).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018yT7vEZv5a5o5bgj5cpcD6
…hecked (review 66357) The previous fix bounded the exponent by DIGIT COUNT (3), which does not match the magnitude the arithmetic carries: Int is i64 in the seed, std.decimal decimal_pow10 is plain 10*... over Int, so decimal_pow10(999) wraps. `1e+999` (three digits, so admitted) produced a fabricated finite SampleValueExact; `1e-999` produced an ExactDecimal with fraction_digits 1000 whose overflow then landed inside the identity equality that decides which process answered. That is the §5 silent-wrongness the module's own header claimed to wall. Fix, on the magnitude the i64 arithmetic actually carries: - prometheus_signed_exponent bounds the exponent's ABSOLUTE VALUE to prometheus_pow10_exponent_bound (18; 10^18 is the largest power of ten i64 holds) and refuses beyond, so decimal_pow10 never wraps. - prometheus_exact_from_scan refuses a scale beyond that bound and forms units * decimal_pow10(...) with checked_int_multiply, refusing on overflow. - exported_start_equals_process_start forms both integer products with checked_int_multiply and returns false on overflow -- a value whose magnitude outruns the carrier is not the start instant of a real process, not a wrapped equality that fabricates a match. RED extended: 1e+999, 1e-999, 123456789e18 all refuse; the real 1.78934488391e+09 still reads exactly and the identity join still holds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018yT7vEZv5a5o5bgj5cpcD6
…main) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e service Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
briansrls
marked this pull request as ready for review
September 15, 2026 03:09
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 140835b520
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Dispatch private witnesses for this public merge | ||
| run: | | ||
| set -eu | ||
| PR_NUMBER=$(curl -fsS -H "Authorization: Bearer ${GITHUB_TOKEN}" -H "Accept: application/vnd.github+json" "https://api.github.com/repos/gunb-ai/gunbc/commits/${PUBLIC_SHA}/pulls" | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d[0]["number"] if d else "")') |
There was a problem hiding this comment.
On a push to main, this request authenticates with GITHUB_TOKEN, but the workflow's top-level permissions block grants only contents: read; unspecified permissions are disabled, while GitHub's “list pull requests associated with a commit” endpoint requires pull-requests: read. Consequently curl -f exits on the authorization error before the repository dispatch is sent, and continue-on-error: true masks the failure, so private witnesses are never triggered.
Useful? React with 👍 / 👎.
Comment on lines
+562
to
+564
| n > 1 && effect_plan_bash_decimal_digits_from(s: s, i: 1, n: n) | ||
| } else { | ||
| effect_plan_bash_decimal_digits_from(s: s, i: 0, n: n) |
There was a problem hiding this comment.
When an IntNe operand is a syntactically valid decimal outside Bash's signed-integer range, this predicate accepts it and emits [ operand -ne rhs ]; for example, Bash reports 9223372036854775808: integer expression expected and exits 2, causing an if to take the else branch instead of evaluating the inequality. help test documents status 0 for true, 1 for false, and failure for invalid arguments, so the validation must also reject values Bash cannot parse rather than checking digits alone.
Useful? React with 👍 / 👎.
Comment on lines
+117
to
+118
| } else if acc.exponent_text == "" && (ch == "+" || ch == "-") { | ||
| SampleLexemeScan { mantissa_digits: acc.mantissa_digits, fraction_digits: acc.fraction_digits, exponent_text: "", exponent_sign_negative: ch == "-", in_fraction: acc.in_fraction, in_exponent: true, ok: true } |
There was a problem hiding this comment.
For malformed samples such as 1e+-2 or 1e++9, consuming the first sign leaves exponent_text empty, so this same arm accepts another sign and the decoder later returns SampleValueExact instead of SampleValueUnreadable. A malformed or non-Prometheus endpoint can therefore supply an invalid lexeme that is normalized into a real process-start value and participates in the incarnation identity join; track whether an exponent sign has already been consumed.
Useful? React with 👍 / 👎.
Contributor
|
Agreed with review 66509: this is the srv1 lab integration branch ( The two main-worthy tip fixes ( — sent from merry-eagle-325 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auto-opened by session-dashboard for session
merry-eagle-325.Pushing to
integration/srv1-lab-2026-09-14advances 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