Repository navigation
floor memory attribution baseline, one reduction, refreshed sizing receipt - #12081
Merged
Merged
Conversation
…ak has a derivable phase The beat and the phase it was taken in were two separate stderr streams joined only by the order the lines happened to appear in. That is a positional citation (DESIGN 3): any line emitted between them by another thread invalidates the join silently, and the reader transcribing a receipt is the one who guesses. The 2026-09-19 receipt's own note admits it -- each beat "transcribed from its own [floor-cgroup] line and the N minutes in heartbeat printed BESIDE it". So the receipt that sizes the Work's memory minimum, the microVM guest shape and the fit stall cannot say which phase established the figure it sizes them with, and nothing derived from it can name a reduction. floor_seam already writes a process-global seam slot and the heartbeat already reads it for its human line; floor_seam_current is the same read for the stat line. FloorMemoryStatBeat carries a typed FloorSeam, and receipt_peak_seam DERIVES which seam established the peak from the beat the held-set fold already selects -- one derivation of "the peak", not a second one. Two arms are not seams and refuse rather than naming a phase: SeamNotYetEntered (sampled before the first seam) and SeamUnrecorded (transcribed from a line that carried no seam field). Every beat of the 2026-09-19 receipt is the latter, which makes that receipt's un-attributability structural rather than a caveat in prose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… position The seam repair left the same defect one field over. The stall clause is the heartbeat's quantity and was readable only from the heartbeat line printed BESIDE the beat, so gunbc.floor_demand FloorMemoryStatBeat.stall was transcribed by adjacency exactly the way the seam was. That field is not decorative. receipt_last_unstalled_beat derives gunbc.runner_microvm gunbc_runner_microvm_guest_cache_allowance from it -- the cache a guest is granted before it thrashes -- so a stall joined to the wrong beat mis-sizes a guest. Fixing the seam and leaving the stall would have been a half-repair of one class. The beat line now carries seam, stall_per_min and the counters together and is self-contained: no reader of it joins anything by position. Rendered `na` where the window could not be read and never a zero -- a zero stall is the healthiest reading this line can carry, so fabricating one manufactures progress, which is the inverse of the error the counters exist to catch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e different spellings
review 69697: floor_seam_current was a SECOND reader of FLOOR_SEAM beside the
heartbeat's own inline lock, and the two disagreed on the empty slot. That is the
DESIGN 3 fork, created by this branch's own addition, and on exactly the join the
branch exists to make derivable.
The remedy is NOT the one-line rewire, and the reason is load-bearing.
gunbc.observation_seed_render seed_heartbeat_subject branches on seam == "" to
decide whether a beat carries a PhaseSegment AT ALL -- the empty string IS that
model's representation of "no phase", pinned by
test.claim.observation_seed_heartbeat_witness_test. Passing it the beat line's
"none" would mint PhaseSegment { name: "none" }: a phase named after the absence
of one, which is the fabrication the SeamNotYetEntered arm exists to refuse.
So the READ is consolidated and the RENDERING is not. floor_seam_current returns
the slot's state and renders nothing: None is a poisoned lock, Some("") the unset
slot, Some(name) the seam. The heartbeat keeps "" for unset, because its mirror's
contract is stated in .dag and witnessed. The beat line spells the three states as
single space-free tokens -- none, unreadable, or the seam -- because that line is
parsed field-by-field into a typed FloorSeam.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…the compiler lane did not The required floor refused: floor_demand_witness_test.dag:170:14 missing required field 'seam'. The pattern edit that added the field to every beat required a six-space indent; the torn-beat fixture inside a test body has four, so it was missed. The closure of the edit was the ROW, not the string that matched. Worth recording WHERE this was caught. The compiler lane passed on the same head. It compiles its own closure; the floor's touched-entry-compile-subject seeded exactly the two modules this branch changed -- gunbc.floor_demand and test.claim.floor_demand_witness_test -- so the floor reached the construction site and the compiler lane never did. A green compiler lane is not evidence that a changed .dag module typechecks. And the job reported SUCCESS over that refusal (witnesses.yml:67), so the check colour said nothing either. The refusal is only readable in the run's own `required-ci: floor refused` and `phases_failed=1` lines. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…it fails are four facts review 69719: seam_is_attributable folded FloorSeam through a Bool, so receipt_peak_seam could only emit a DISJUNCTIVE cause -- "sampled before the first seam, OR transcribed from a line printed before the instrument carried one" -- for a case where the arm is known exactly. Collapsing a known discriminator and then apologising for it in the message is the absorbing fallback DESIGN 5 forbids, one layer up from the positional join the seam field removes. The module's own note says those two arms are materially different; the fold threw that away. PeakUnattributableCause is typed and the helper is deleted. The match is on the peak beat's seam DIRECTLY, so every FloorSeam arm is answered in one place and a new arm cannot silently fall into either bucket -- it fails to compile until this fold says which it is. Four facts, four remedies: PeakBeatSampledBeforeAnySeam (read a later beat), PeakBeatSeamUnrecorded (take a new run), ReceiptHasNoBeats (unmeasured), ReceiptTorn (carries the overflow). The first two carry the beat number, because a located diagnostic pointing at the wrong beat is worse than an unlocated one. The witnesses now assert the ARM and the beat rather than "it refused at all" -- the reviewer's second point, and correct: driving three receipts that fail three different ways through one cause-agnostic match greened whichever cause was produced, so the witness could not have caught the defect it was meant to cover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ts own peak's seam From this change's own CI run 35652545009 (srv3-01, 2026-09-21), 23 beats derived from their own [floor-cgroup] seam=/stall_per_min= lines by the instrument rather than joined to neighbouring lines by a reader. WHAT IT SHOWS, and it is not what a peak snapshot would have said. The peak is beat 18, in claim-evaluation-fold, at 26142809464 bytes held. But preparation alone reaches 23.01 GiB by beat 14 and never releases it -- anon climbs monotonically from 8.35 GiB with no drop -- and the fold adds only ~1.3 GiB on top of everything preparation is still holding. The peak SEAM and the demand's CAUSE are different answers: the maximum occurs in the fold, 95% of it was built before the fold began. Aiming a reduction at the peak's seam would chase the last 5%. Not a cache story, and the beats say so directly: file sits flat at 1.90 GiB through all fourteen preparation beats and is SQUEEZED to 0.26 GiB during the fold. That is reclaim giving cache back, the opposite of cache accumulation. STILL CENSORED, so it sizes nothing it should not. The peak beat carries a stall of 11 faults/min, beat 19 reads 77, beat 22 reads 3225, host swap-in rising. The receipt carries a typed RunSwapPolicy and receipt_peak_reading_standing consumes it: both receipts read PeakIsLowerBound, for two DIFFERENT reasons -- the 09-19 run never completed, the 09-21 run's peak beat was already stalling. A cell whose MemoryHigh sits under the workload cannot produce an uncensored reading by construction. SwapMaxDeclaredUnread rather than a figure: the envelope prints max/high/current/ peak and NOT memory.swap.max, so a receipt from a job log can cite the declaring row but cannot read the ceiling. Conflating those would consume a bet as a fact. THE 4b(4) FLIP, trigger satisfied: the expecting-red claim that the standing receipt could not attribute its peak now asserts that it CAN, citing what moved. It did not retire. The superseded 09-19 receipt is retained and keeps its own executed red, so SeamUnrecorded still has a discriminating control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… same word in prose The floor refused: floor_demand.dag heads-only parse, unmatched delimiter in a data value. Self-inflicted and worth naming precisely, because the mechanism is not specific to this file. The receipt was assembled by substituting the instrument's generated beat rows into a template at a BEATS placeholder. The surrounding note contains the sentence "the BEATS say so directly", so the substitution -- which replaces every occurrence, not the first -- injected the whole twenty-three-beat block into the middle of a comment as well as into the array. The comment swallowed the opening brace of the injected block and the array's own close brace then had no match. Repaired by restoring the displaced sentence. Both receipts verified intact afterwards: 4 beats on 2026-09-19, 23 on 2026-09-21, brace depth zero and never negative. WHERE IT WAS CAUGHT, AGAIN: the floor. clippy and compiler both passed on the same head for the second time in this branch, because the compiler lane does not compile what the diff touched and the floor does. A generated-content edit to a .dag file owes a structural check before it is pushed, not a CI cycle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tion is admitted required-ci parse FAIL, five lines: floor_demand_witness_test.dag:386-390 source annotation sits inside a declaration. Annotations are module-item grain only (DESIGN 4c: the initial .dag realization admits standalone leading // blocks attached to module-scope declarations); I put a five-line note inside a test function body. Moved above the declaration, unchanged in content. WHAT THIS COST AND WHY IT IS WORTH NAMING. The parse failure is the FIRST of the two phase failures; the floor's own ArmSetConsumerPlanningUnavailable refusal is its CONSEQUENCE -- --required-ci lends the parse phase's declaration index, None means the parse refused, and the floor then refuses to plan blind rather than planning without the dependents direction. Reading the floor's refusal as the defect would have sent me into the floor's planning row, which is working exactly as designed. A pre-push structural check now covers the three classes this branch has paid a CI cycle for each: delimiter balance with // stripped, depth-never-negative to localise an injection, and annotations inside a declaration. All three are decidable locally in milliseconds; each cost about forty minutes to learn from CI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…y token the instrument emits review 69767, two findings, both correct and both the same shape: a state that exists is given no faithful representation, so something else stands in for it. ONE -- A TORN RECEIPT REPORTED "NO BEATS". receipt_peak_reading_standing routed through receipt_peak_beat, which collapses HeldSetPeakUnrepresentable into Absent, so a receipt that plainly HAS beats was reported as having none, and ReceiptTorn was unreachable from that fold entirely. That is this module's own stated bar turned against it -- four causes, four remedies, and a cause naming the wrong thing is worse than an unlocated one. It now matches receipt_held_set_peak directly, as its sibling receipt_peak_seam already did. There was no claim over the torn case here, which is exactly why it passed; there is one now. TWO -- THE INSTRUMENT COULD EMIT TOKENS THE VOCABULARY COULD NOT RECEIVE. seam=unreadable (a poisoned slot) had no FloorSeam arm, and stall_per_min=na had no representation in EventsPerMinute at all. The na case is routine, not hypothetical: the heartbeat renders it whenever its /proc window does not read. A vocabulary that cannot receive its own producer's output does not prevent the state -- it forces the transcriber to map it onto some OTHER arm, and that mapping is a fabrication no reader of the receipt can see. My own tool was doing exactly that, folding unreadable into SeamUnrecorded. So FloorSeam gains SeamUnreadable and the beat's stall becomes BeatStall = StallRead | StallUnread. StallUnread IS NOT UNSTALLED: both predicates answer false, because "we could not tell" is not evidence of calm and the guest's cache allowance is derived from the last unstalled beat -- a beat nobody observed would otherwise size a guest. receipt_peak_reading_standing reports PeakBeatStallUnread rather than silently treating it as calm. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… than by a third review Two reviews in this session caught the same defect: a fold collapsing an arm that no claim could tell apart, green by construction. Fixing each instance individually was not going to find the third, so this audits every arm of both cause coproducts against the folds that produce them. FOUR ARMS WERE PRODUCED AND UNCLAIMED -- present in the witness module's import list and nowhere else, which greps as covered and establishes nothing: PeakBeatSeamUnreadable an unreadable seam slot on the peak beat PeakBeatStallUnread a peak beat whose stall window did not read SwapCouldAbsorbAnonymousPages a swap ceiling cited from a declaring row SwapPolicyIsRead a swap ceiling an instrument actually read The stall one is the one that mattered: without its arm driven, a peak beat whose window did not read would reach the swap test and could answer PeakIsDemand -- a figure permitted to SIZE a guest, resting on a beat nobody observed. The swap claim also drives the boundary the two arms share: a READ ceiling of zero is not censoring, so it answers PeakIsDemand, while a read ceiling of 4096 does not. Both arms censor and each reports its own cause, so a reader is told whether the ceiling behind the censoring was read or merely declared -- the distinction DESIGN 4d exists to keep. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…eturned clean My own witness caught this: neither_standing_receipt_reads_an_uncensored_demand FAILED on the floor. The diagnosis is a modeling defect I introduced, not a wrong assertion -- run_completed is ambiguous between "the measured workload ran to its end" and "the floor returned clean", and the two readings give DIFFERENT answers for the 2026-09-21 run. Its consumer, receipt_peak_reading_standing, asks exactly one question of the field: could the peak have been TRUNCATED? A run that stopped early never reached whatever it would have held later, so its maximum is a lower bound for that reason alone. A run whose workload completed and whose VERDICT was a refusal is a different fact: the memory it held is the memory it held, whatever any witness decided. Under the "floor was clean" reading, every refusing run is marked truncated and RunDidNotComplete masks every other censoring cause behind it -- which is what it did to the 2026-09-21 receipt, hiding that its peak beat was stalling. So the meaning is stated on the field, and the 2026-09-21 receipt reads true: the floor executed preparation and the whole claim-evaluation fold -- twenty-three beats, the anonymous set rising to its peak and falling again as the fold released scopes -- and the refusal came afterwards from an unrelated lane (test.claim.mtcollins1_census_image_local_wet, which this change does not touch). The 2026-09-19 receipt stays false: it refused IN strict-preparation and never reached the fold, so its peak really is truncated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…utside the diff review 69800, and it is right. Re-typing FloorMemoryStatBeat.stall from EventsPerMinute to BeatStall migrated the PRODUCERS and the two folds in floor_demand, and left four READERS passing a BeatStall to events_per_minute_count(r: EventsPerMinute): floor_demand_witness_test.dag:253,258,261 -- untouched hunks between my edits runner_microvm_witness_test.dag:814 -- a file this diff never opens The cross-module one is the one that matters. It asserts the beat behind gunbc_runner_microvm_guest_cache_allowance was unstalled, which is the very property this change says must not silently pass for an unread stall -- so the unmigrated assertion was quietly no longer enforcing the PR's own stated bar. It now calls beat_stall_is_zero, reusing the authority's predicate rather than re-deriving the arm at a second site. The three local ones assert specific rates, so they go through stall_rate_is, where StallUnread answers false rather than matching any n: "we could not tell" is not a reading and cannot equal one. WORTH RECORDING: the floor did NOT catch these. It reported 0 parse FAILs and no witness failures on the previous head while all four sites were live, and EventsPerMinute is a plain alias (Measure<Frequency, Sixty, Nat>), so these are ordinary argument-type mismatches. I am not claiming to know why the wall stayed quiet; I am recording that a green floor did not establish that a re-typed field's readers were migrated, so the reader enumeration has to be done by hand. Done by hand here for all four fields this branch re-typed or added -- stall, seam, swap_policy, run_completed -- and every reader now matches the arm or calls the owning predicate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…allowance move at the row that causes it
review 69817, and it catches the one consequence I acknowledged in a PR comment
and never fixed in the corpus -- which is precisely the failure mode, since a
comment on a PR is not reachable from the declaration that rots.
gunbc.runner_microvm's allowance note carried the 2026-09-19 receipt's beat-13
figure ("the stall clause at zero, 1895120896 bytes of file") beside a fold that
reads whatever the STANDING receipt says. Moving the standing to the 2026-09-21
receipt moved the derivation to beat 17 and HALVED the allowance, while the
sentence went on describing a beat nothing reads. DESIGN 6: a transcribed number
is unreachable from the thing that owns it, so it rots without anyone touching
either end. The note now names receipt_last_unstalled_beat and carries no figure;
the figure has one home, the standing receipt's rows.
And the receipt's own note states BOTH derived consequences rather than only the
demand: the demand falls 26725773568 -> 26142809464, and the guest cache allowance
halves 2 GiB -> 1 GiB. Nothing reds when it changes, because every claim over
these is derivation-relative -- including the production shape's expecting-red
probe, which still refuses -- and a figure that moves a fleet's sizing without
reddening anything is exactly the change that lands unnoticed.
The overshoot figures are my own computation, not the review's: 373005688 bytes
now against 2029711616 before, which is 356 MiB against 1.89 GiB. The review's
"~347 MiB / ~2.03 GiB" mixes decimal GB with binary MiB, and I copied it into the
note before checking. The bytes are what the fold compares, so the bytes are what
the note carries.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… the deletion condition stated review 69834: receipt_peak_seam and receipt_peak_reading_standing, with their four cause coproducts, are reached only by test.claim.floor_demand_witness_test. DESIGN 3c: name the consumer AND the route by which it reaches that consumer at EXECUTION, or classify the declaration honestly -- and only the dangling state is red. The note claimed the consumer was "a consumer asking what to reduce". That is a READER, not a route, and it carried no trigger, so it claimed consumption it did not have -- the middle state dressed as the first. Replaced with a typed DissolutionCondition beside the declaration, the same shape gunbc.runner_microvm_lifecycle_realize uses for its five frontiers. NAMED CONSUMER: the reduction lane's before/after receipt, which states which seam a landed reduction moved by evaluating receipt_peak_seam over the standing receipt on each side. TRIGGER: the change that lands the first measured reduction, reading these folds from a production declaration rather than from a claim. And the row states its own NEGATIVE condition, because a frontier that cannot fail is not one: if the reduction lane derives its attribution some other way, these folds and their vocabulary are unconsumed and are DELETED rather than kept. What is NOT a frontier, stated so the scope is not overclaimed either way: the seam FIELD is consumed now -- the receipts carry it and the peak fold reads it -- and the re-typed stall reaches production through receipt_last_unstalled_beat into gunbc_runner_microvm_guest_cache_allowance. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ption as the trigger Operator decision: land 12001 as the attributed baseline and keep PSI, oom_kill, process overlap, the wall/result join and cold-vs-repeat separation OUT of this PR -- but do not leave them silent. One declared frontier row, not a modeling pass. The gap is recorded PER FIELD because the fields are not in the same state and the difference matters to whoever closes it. PSI and oom_kill are PRINTED by floor_cgroup_envelope and not transcribed. The wall and result exist as their own row and are simply not joined to this one. Cold-vs-repeated is a distinction the receipts cannot express. Process overlap is different in kind: NOTHING OBSERVES IT, so its line is a measurement obligation before it is a transcription one. THE TRIGGER IS CONSUMPTION, NOT CARRIAGE, and that is the point of making it a frontier rather than a todo: a field added to the beat that no fold reads is the dangling declaration DESIGN 3c refuses, and this module already carries one declared frontier for precisely that reason (review 69834). So a field retires its line when it is carried AND read by receipt_peak_reading_standing or the fit fold -- and printing it in a job log explicitly does not count, since that is the state the row exists to record. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
review 69874, and it is the sharpest finding on this branch because it catches the branch contradicting itself. The change DELETES a transcribed beat figure from gunbc.runner_microvm's allowance note -- on the grounds that a transcribed number is unreachable from the thing that owns it and rots untouched -- and then MINTS transcribed figures in this receipt's note, in the same commit. That moved the rot rather than ending it. The next standing switch would have falsified these sentences exactly as it falsified the one deleted. So the quantities go back to their one home and the note names the producer: the demand to floor_memory_requirement over this receipt's rows, the allowance to gunbc_runner_microvm_guest_cache_allowance via receipt_last_unstalled_beat, the remainder comparison to the shape-fit fold and its expecting-red probe, and the censoring verdict to receipt_peak_reading_standing, which DERIVES the lower-bound reading rather than leaving a reader to compare stall figures by eye. WHAT THE NOTE STILL SAYS, because removing the figures is not the same as removing the finding: that switching the standing moves TWO quantities and only one is obvious; that the held set rises monotonically across preparation and never falls, so the peak SEAM and the demand's CAUSE are different answers; and that the file counter is flat then falls, which is reclaim rather than accumulation. Those are statements about the SHAPE of the rows -- a direction no single beat establishes and no lookup recovers -- not restatements of values the rows already carry (DESIGN 4c). The only long numbers left in the note are identifiers: the run, the job, the review. Those are citations, which is what 6 asks for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rting exact demand External review of 162e9d8, three findings, all the same class: a claim reaching past its evidence. The first two are defects in an instrument that was about to be used to certify a reduction, which is the worst possible moment to have them. 1. THE SEAM BINDING WAS STILL RACY. floor_cgroup_stat_beat read memory.stat, then memory.current, then the seam. The floor thread can call floor_seam in between, so a transition beat could carry memory sampled under seam A while confidently labelled seam B. Putting the values on ONE LINE removed the log-adjacency join; it did NOT bind the two observations in TIME, and those are different fixes. I claimed the line was self-contained, which was true of the LINE and not of the OBSERVATIONS. The seam is now read BEFORE and AFTER the procfs reads, and when they differ the instrument emits transition:A>B, which the receipt receives as SeamMovedDuringSample carrying BOTH endpoints. Bracketing rather than holding the seam lock across the reads: the lock is written by the floor thread on every phase change, and blocking it on two procfs reads would let the instrument perturb the workload it measures. It also makes the uncertainty explicit instead of resolving it silently. Its own discriminating witness asserts both endpoints survive, since a transition that forgot which two phases it sat between is no better than an unattributed beat. 2. A PERIODIC MAXIMUM IS NOT EXACT DEMAND. PeakIsDemand was reached when the workload completed, the SAMPLED peak showed no stall and swap could not spill. Those remove two CENSORING mechanisms; they do not make a sampled maximum the true maximum. memory.stat has no high-water counter, so a spike between two beats is invisible -- which this module's own cadence note has said from the start, while the fold promoted past it anyway. The ARM NAME was the assertion (DESIGN 4d: a later reader consumes PeakIsDemand as a fact). Renamed PeakIsUncensoredSampledMaximum: every arm of that type is now a lower bound and they differ only in WHY. Exact demand would need a persistent high-water observation of the same quantity; none exists, so none is claimed. 3. THE NARRATIVE SAID OVERLAP WAS RULED OUT. Falling anonymous memory after the peak is CONSISTENT with the fold releasing state but does not discriminate: these are per-cgroup totals and say nothing about which processes held what. The source correctly records overlap as UNOBSERVED with a missing INSTRUMENT, so the source stands and the narrative is corrected to match it. The cache arm is excluded by the rows; the overlap arm is simply not measured, and those are different states. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s own branch review 70180 flagged the "+25 -1" line counts as a soft spot and explicitly declined to count them, since the text labels its own standing. Checking them turned a stylistic remark into a real defect: they are now WRONG. The row claims +25 -1 on required_floor_runner.rs and UNCHANGED on cli_run.rs; the diff says +84 -3 and +7 -5. They rotted inside this branch, by my own later edits -- bracketing the seam read around the procfs sample, and routing the heartbeat through the shared reader -- without anyone touching this row. That is exactly the mechanism DESIGN 6 names, demonstrated on a figure I wrote while removing the same class of figure from two other files in the same branch. A hand-written count of a diff still being written has no producer to re-derive it, and this row already states that the item observation producer is absent. So the count goes, and the row says who reads the delta instead: whoever adjudicates the hand-item admission, from the diff, at the head they are adjudicating. The ORIGINAL receipt's +56/+3 stays, with a clause saying why it is different in kind: it describes a change that has LANDED, so it cannot move under itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…wice run_required_floor prepares TWO subjects -- the policy closure, then the gate closure -- and both call sites pass identical source roots, identical exclusions and the same gate_entry_index, differing ONLY in their closure seeds. Each prepare began with its own build_module_index(source_roots), which is not memoised: it walks every root and read_to_string's every .dag file. So the floor read and indexed the whole 6,494-module corpus TWICE on every run, for two questions that differ in their seeds and in nothing else. That is DESIGN 2's authored duplication, not a cache obligation, and 2 names the repair: when several demands share a least common ancestor, CARRY the first value. run_required_floor is that ancestor. It now reads once and lends. No key, no invalidation rule, no provider -- none of those was missing. The entry index one line above was ALREADY shared for exactly this reason, which is the tell that the corpus read should have been too. The read becomes a value a caller can own (SourceCorpusRead), with the reading wrappers kept for callers that have only one demand -- the lane resolution census still reads for itself. The only cost is at the two places the index was MOVED rather than read: those now clone Rc<SourceFile> pointers and their keys, never file contents, and for the closure arm only the KEPT subset (539 and 1,974 of 6,494 on the floor). STRUCTURAL CONSEQUENCE, STATED BEFORE THE MEASUREMENT: on the floor's production path there is now exactly ONE corpus read. That is checkable without a run and is independent of what the memory figure turns out to be. THE PREDICTION, ALSO BEFORE THE RUN: if this duplication is the dominant term of the retained preparation set, the floor's preparation drops toward 12-15 GiB AND quiet-koi-746's slot controller -- which already loads the corpus once -- DOES NOT MOVE. If the controller also drops, this account of the chain is wrong and the cause is somewhere shared that I have not read. The before/after is re-derived by the seam-bearing instrument from gunbc#12001, over both subjects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… one Follow-up to gunbc#12001, filed rather than pushed there because that PR is queued at an exact head the operator and the side chat each signed off, and a new push would dismiss both to fix two sentences. The two sentences explaining WHY PeakIsDemand was renamed said "it used to be called PeakIsUncensoredSampledMaximum" and characterised an arm by that same new name as the overclaim. Both should say PeakIsDemand. Self-contradictory as written, and worse than a missing comment because it reads as authoritative (DESIGN 4c: an annotation must not misdescribe what the declaration says). HOW I CAUSED IT, because the mechanism generalises: the rename was a blanket string replace of PeakIsDemand across the module. That correctly rewrote the type, the fold arms and the controls -- and also rewrote the PROSE THAT WAS TALKING ABOUT THE OLD NAME, which is the one place the old spelling had to survive. A rename is safe over code and unsafe over the sentences explaining the rename, and those live in the same file. It is the same class as the placeholder substitution earlier in this branch, where replacing a token also replaced the same word in prose: a mechanical edit over a file that contains both code and commentary about that code. The type, fold, controls and receipt semantics were all correct; this is prose only. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
briansrls
marked this pull request as ready for review
September 22, 2026 21:31
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: d52ede961e
ℹ️ 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".
| // repair: when several demands share a least common ancestor, CARRY the first value. This is | ||
| // that ancestor. The entry index one line above was already shared for exactly this reason -- | ||
| // the corpus read simply never was. | ||
| let floor_corpus = crate::cli_run::read_source_corpus_once(source_roots); |
There was a problem hiding this comment.
In every required-floor run, floor_corpus owns the complete ModuleSourceIndex and full inventory, and lending it to both prepares does not consume either collection. Because it is never explicitly dropped, it remains alive through claim execution, so the later take and consumption of prepared.full_inventory no longer release the outside-closure source contents as intended. This retains the whole corpus in the memory-constrained floor after preparation; drop floor_corpus immediately after prepare_repository_from_corpus finishes, alongside gate_entry_index.
Useful? React with 👍 / 👎.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 23, 2026
… seams placed before it Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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
loyal-ibex-544.Pushing to
session/loyal-ibex-544-d3advances 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