Raise the surface cap to 217 and pin the scheduled audit workflow - #406
Merged
lamemustafa merged 2 commits intoSep 15, 2026
Merged
Conversation
`dependency-security-scheduled.yml` landed in #404 unpinned, because the surface held exactly 216 entries against a cap of 216 and `reseal.sh --pins-changed` refuses a 217th with `surface_file_count_invalid`. Raising a cap the count sits exactly on is the deliberate decision that constant exists to force, so it was left for review rather than taken as a side effect of adding a workflow. This is that decision. The constant's own rule is one file for one named reason, not headroom, so the reason is recorded beside it. It differs in kind from the three raises above it. Those bound files that decide what Bridge admits -- `agent_ledgers.rs`, `master_binding.rs`, the voucher-presence engine. This one binds a file that decides what Bridge is allowed to do to its own repository while nobody is watching: it is the only workflow that runs unattended on a schedule holding `issues: write`, and it was the only one of the five whose sibling is pinned while it was not. Left unpinned, an edit that widened its permissions or pointed its audit at a different lockfile would leave the surface digest unchanged and let existing evidence attest a workflow it never covered. That is not asserted. Widening the job's `contents: read` to `contents: write` now fails `reseal.sh --verify` and fails the gate with `surface_file_changed`; before this change the same edit passed both. The file was restored byte-identically afterwards and verify returns to exit 0. The comment's closing sentence reserved the 216th slot for `agent_catalog.rs`. That slot has since been taken by it, as intended, so the sentence is replaced rather than left reading as a pending claim. `RESERVED_SURFACE_FILES` is untouched at 15 and the invariant it guards still holds: `MAX_SURFACE_FILES - files.len()` is 0, well inside it, because the cap moved by exactly one alongside exactly one pin. Resealed through the documented inverted order for a changed pin list -- `reseal.sh --pins-changed` seals the new file list before rehashing, since `rehash-surface` validates `manifest_sha256` before it does anything and the ordinary order fails with `surface_checksum_mismatch`. Verified with every exit status read directly: tools workspace 11 binaries, 53 passed, 0 failed, including `surface_file_cap_refuses_one_entry_above_the_cap` and `real_tree_has_complete_migration_and_report_surface_coverage`, the two tests that assert on this constant. Compatibility gate passes. `reseal.sh --verify` exit 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
#405 resealed pinned files without changing the pin set, so both sides moved the two manifests and they conflicted. Pin lists compared by path: master's 216 is a strict subset of this branch's 217, the difference being this branch's own addition, and #405 changed hashes only. Resolved by taking this branch's list and running scripts/reseal.sh, which recomputes every hash from the merged tree rather than hand-merging one. Exactly one hash moved, and no path is missing versus either side. reseal.sh --verify exit 0, read directly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lamemustafa
deleted the
chore/raise-surface-cap-and-pin-scheduled-audit
branch
September 15, 2026 19:32
This was referenced Sep 15, 2026
lamemustafa
added a commit
that referenced
this pull request
Sep 15, 2026
I had written the surface being at 217 of 217 as a shortage blocking decomposition. Reading the constant's own documentation, it is not. RESERVED_SURFACE_FILES is capacity for one small cohesive surface change, and the cap's rationale says it makes further unreviewed additions an explicit compatibility-surface decision -- 'one file for one named reason, not headroom'. It has been raised four times, three by branches that could not see each other, which is the drift the friction prevents. So the pattern is a per-decomposition raise with its own named reason, pinning what it adds, as #406 did. The doc now says that, and says to budget for it: splitting a 6,000-line module four ways is four surface decisions. The silent-shrink hole is unaffected and still stands -- extraction leaves the moved code outside the evidence boundary with no raise, no pin, and nothing loud, which is the same failure the cap comment says it exists to make loud, arriving by a route the cap cannot see. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lamemustafa
added a commit
that referenced
this pull request
Sep 15, 2026
…he obvious way (#417) * Write down how to split a module here, and what breaks if you do it the obvious way Fourteen production files are over 2,000 lines and five over 3,500. General Rust guidance covers where to cut; it does not know the constraint that actually governs decomposition in this repository. **Splitting a pinned file silently removes the extracted code from the compatibility surface.** The parent's hash changes, reseal succeeds, --verify passes, CI is green, and the sealed set now covers less than it did. Nothing reports it, because `rehash-surface` hashes the paths the manifest lists and an extracted file is not one of them. It is not a check that fails; it is a check nobody asked. The companion hazard arrives without splitting anything. `agent_import.rs` is pinned and all six of its direct child modules are not -- 1,336 lines including the posting path, and the module deciding which side a cash/bank leg sits on for Payment versus Receipt versus Contra. The module that renders the qualified write shape is sealed; the module that decides it is not. Some of that may be deliberate, and the manifest cannot say which, because it records paths and not reasons. Both are recorded here with the rules that follow, plus the cut-by-subject measurement for bridge-tally-protocol, the test-extraction pattern and its visibility trap, and the regenerate-verify-stage order whose inversion has already cost a CI round. Blocked-on is filed as #416: the surface is at 217 of 217, so any decomposition of a pinned file needs a cap change first. Docs only. No pinned file moves; reseal --verify exits 0 unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Add the function-shape trigger, which finds targets size ranking cannot A parallel measurement on the Axal tree showed file length did not predict which files had a defect there; the longest-function-to-median ratio did. Run on this tree it finds sync/snapshot.rs::run -- 811 lines in one function, brace-matched -- in a file that ranks only eighth by size, and a 296-line function in a 443-line file nobody would look at. It does not replace the size trigger here, and the doc says where the two trees disagree: bridge's largest files are 11-21x with medians of 19-32 across 112-171 functions, so they are many cohesive small things in one place rather than one giant function. That is a module defect and the ratio is silent about it. Both triggers, naming different problems. Also records the impl-block counting trap, and to check for a deletion entry before planning a split. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Correct the cap guidance: the friction is the control I had written the surface being at 217 of 217 as a shortage blocking decomposition. Reading the constant's own documentation, it is not. RESERVED_SURFACE_FILES is capacity for one small cohesive surface change, and the cap's rationale says it makes further unreviewed additions an explicit compatibility-surface decision -- 'one file for one named reason, not headroom'. It has been raised four times, three by branches that could not see each other, which is the drift the friction prevents. So the pattern is a per-decomposition raise with its own named reason, pinning what it adds, as #406 did. The doc now says that, and says to budget for it: splitting a 6,000-line module four ways is four surface decisions. The silent-shrink hole is unaffected and still stands -- extraction leaves the moved code outside the evidence boundary with no raise, no pin, and nothing loud, which is the same failure the cap comment says it exists to make loud, arriving by a route the cap cannot see. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Correct six factual errors an independent fact-check found A conventions document that states a false fact is worse than no document, because people act on it. A reviewer asked to verify every claim found six wrong, and one of them was inverted. - `agent_import.rs` has **eight** non-test children, not six, and **one is pinned** -- `agent_desktop_journal.rs`, via the hard-coded REQUIRED_SURFACE_FILES list. I had named a file that does not exist (`agent_import_desktop_journal.rs`) and called it unpinned. Two genuinely unpinned siblings were missing entirely, so the real figure is 1,859 lines outside the seal, not 1,336. - The `#[path] mod tests;` pattern is used **20** times, not 95. `#[path]` in all forms is 101; 63 of those point at a `*_tests.rs` file. 95 was not any of the three readings. - `execute_with_transport` is in `tools/bridge-tally-live-read/src/lib.rs`, not `bridge-tally-transport`. My clustering script printed basenames, so every `lib.rs` in the tree collapsed into one row and the attribution was whichever crate I guessed. - Six production files exceed 3,500 lines, not five. - #395 moved 8,465 lines, not 14,400. - The function-shape figures were inferred from the next `fn` rather than brace-matched, which moved every median and ratio: snapshot.rs::run is 45x not 37x, and the protocol crate's longest is 375 lines at 29x, not 396 at 21x. The table is now brace-matched throughout and says so. Also: the seal is not entirely unguarded. `validate_required_directory_coverage` fails closed for two directories and four named files. I had written "nothing reports" without checking, which overstated a real finding -- the net exists and is narrow, and the document now says exactly how narrow. And the protocol-crate clustering is scoped to what a keyword method can support: it says which groups exist, not their sizes to the line. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: t <dev@example.invalid>
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.
Follow-up to #404, which landed
dependency-security-scheduled.ymlunpinned. That was not an oversight: the surface held exactly 216 entries againstMAX_SURFACE_FILES = 216, andreseal.sh --pins-changedrefuses a 217th withsurface_file_count_invalid. Raising a cap the count sits exactly on is the deliberate decision that constant exists to force, so it was left for review. This is that decision.The named reason
The constant's own rule is one file for one named reason — not headroom, so the reason sits beside it in the source.
It differs in kind from the three raises above it. Those bound files that decide what Bridge admits:
agent_ledgers.rs,master_binding.rs, the voucher-presence engine. This one binds a file that decides what Bridge is allowed to do to its own repository while nobody is watching. It is the only workflow that runs unattended on a schedule holdingissues: write, and it was the only one of the five whose sibling is pinned while it was not.Left unpinned, an edit that widened its permissions or pointed its audit at a different lockfile would leave the surface digest unchanged and let existing evidence attest a workflow it never covered.
Proven, not asserted
Widening the job's
contents: readtocontents: write:Before this change the same edit passed both. The file was restored byte-identically afterwards (sha256 compared) and verify returns to exit 0.
Worth recording how that nearly went wrong: my first attempt at this mutation targeted a pattern that did not match the file, so it changed nothing while my script printed success anyway — and the gate "passing" looked exactly like the pin not working. The second attempt asserts the replacement landed and compares hashes before trusting the result.
Housekeeping in the same comment
The closing sentence reserved the 216th slot for
agent_catalog.rs. That slot has since been taken by it, as intended, so the sentence is replaced rather than left reading as a pending claim.RESERVED_SURFACE_FILESis untouched at 15, and the invariant it guards atlib.rs:2480still holds —MAX_SURFACE_FILES - files.len()is 0 — because the cap moved by exactly one alongside exactly one pin.Reseal ordering
Resealed through the documented inverted order for a changed pin list:
reseal.sh --pins-changedseals the new file list before rehashing, becauserehash-surfacevalidatesmanifest_sha256before doing anything and the ordinary order fails withsurface_checksum_mismatch.Verification
Every exit status read directly, not through a pipe.
surface_file_cap_refuses_one_entry_above_the_capreal_tree_has_complete_migration_and_report_surface_coveragecompatibility_gate_passed:unknown_claims=11:evidenced_claims=0reseal.sh --verifyThe two named tests are the ones that assert on this constant, which is why they are called out rather than folded into the total.
🤖 Generated with Claude Code