fix(guard): resolve_base refused every STACKED merge-group entry — two of every three queue builds were RED by construction (#3186) - #3187
Merged
Conversation
…o of every three queue builds were RED by construction (#3186) GitHub builds queue entry N as a squash on top of entry N-1's squash, so at position >= 2 the head has ONE parent that is not the origin/main tip and, at fetch-depth 1, is not fetched. Every rule in resolve_base refused that shape (exit 2 -> guard-tree FAIL), so with max_entries_to_build=3 the second and third entries of every stacked build were RED on this resolver alone: runs 34704287677 (#3139) and 34704288441 (#3046), 2026-09-12, each after passing 82,085 workspace tests on gx10. Four PRs were dequeued today on it. Under GITHUB_EVENT_NAME=merge_group the resolver now deepens the shallow checkout by one commit (git fetch --deepen=1 origin, else fetch the parent by sha) and names that parent as the base — exactly this entry's own diff. A push-shape depth-1 head stays refused (never the tree against itself); ROADMAP_DIFF_NO_DEEPEN=1 is the mutation. Case table (check_roadmap_diff_additive.sh --self-test): rows 19-20 added — a self-contained repo c1 -> c2 -> c3 with origin/main := c1 fetched by name into a depth-1 clone (a shallow clone cannot update-ref to an object it lacks; the fixture fetches the tip the way the job does). Row 19 resolves to c2 under merge_group; row 20 is refused by name with deepening disabled. Mutation measured: with origin/main's resolver restored, row 19 goes RED. 20/20 rows; bashrs 0 errors on both files (guard: 0 -> 0, lib: 0 -> 0). Every consumer of the lib benefits: check_hardcoded_paths.sh (its ratchet also read "origin/main tip" as the base for stacked entries), check_no_fabricated_baselines.sh, check_dogfood_coverage.sh, check_row_pr_write_set.sh. Refs #3186, #3177, APR-RELEASE-001 §3.4/§5 P0·Pack (packing rule, operator 2026-09-12). Pmat-Ticket: PMAT-3186 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
noahgift
enabled auto-merge
September 12, 2026 16:37
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
noahgift
added a commit
that referenced
this pull request
Sep 12, 2026
…changed (SSH measurement, 146 GB reclaimed, forjar P0·Reap live on gx10+yoga via infra#549, packing rule, spec e874769), the stacked-merge-group resolver defect #3186 → #3187, 16 ledger records incl. fleet-pack samples [skip ci] Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Sep 12, 2026
This was referenced Sep 12, 2026
noahgift
added a commit
to guyernest/aprender
that referenced
this pull request
Sep 13, 2026
…runs at release time and never on a PR, so paiml#3187 merged two SEC010 into the same file that had just been cleared (paiml#3194) `dogfood.sh --phase pre-publish` on `ee76ee39c` (the commit carrying paiml#3188's own bashrs fix) returned NO-GO again: [FAIL] bashrs 2 SEC/DET/IDEM error(s) over 293 file(s): SEC010 Both in `scripts/check_roadmap_diff_additive.sh`, at the two `cd "$Q.clone"` sites that paiml#3187 added to the self-test case table four hours after paiml#3188 cleared the previous nine. Nothing caught them in between, because the bashrs gate lives in `scripts/dogfood.sh` and no CI job runs it — filed separately, it is the reason this class keeps landing on the train rather than on the PR that writes it. The fix: the harness cd'd into the fixture clone so the script under test would see it as cwd. That requirement belongs to the INNER shell, so it is handed the directory and cds itself. No `cd` of this script's own remains at either site. What was measured, not assumed: * validating `$Q` at its definition does NOT clear SEC010 (still 2) * validating immediately before each `cd` does NOT clear it (still 2) * `cd --`, `cd "$TD" && cd <literal>`, and a command-substitution alias do NOT clear it; the alias made it worse (2 -> 4) * `bashrs fix` CORRUPTS this file — it rewrote `trap 'rm -rf -- "${TD:?}"' EXIT` into `trap "rm -rf -- "${TD:?}"" EXIT` and swapped the quote characters inside five `assert_row` calls, turning valid code into broken code. Filed separately. * restore either `cd` and SEC010 returns at that line; with both moved inward the file is CLEAN and the full 293-file surface has ZERO DET/SEC/IDEM The guard's own case table is unchanged and still green: 24/24 rows, including row 19 (`stacked merge_group entry at depth-1 -> deepened`) and row 20 (`stacked entry with deepening disabled (mutation): refused by name`) — the two rows whose `cd` moved. `bash -n` clean. Pmat-Ticket: PMAT-1098 Co-authored-by: Noah Gift <claude@noahgift.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
noahgift
added a commit
to guyernest/aprender
that referenced
this pull request
Sep 13, 2026
…e 0.67.0 train three times on findings no PR check saw (paiml#3196) (paiml#3199) dogfood.sh's bashrs row is the only place the SEC/DET/IDEM filter ran, so a PR could add a finding freely and the train paid for it at the pre-publish gate: 17:33Z (paiml#3115, paiml#3127 -> fixed by paiml#3188), 20:58Z (paiml#3187 -> paiml#3194), 22:48Z (paiml#3068 -> paiml#3198). Three fixes round the merge queue while the tag waited. scripts/check_bashrs_gate.sh is that gate lifted out where the finding is cheap: same surface enumeration (git ls-files, N+1 receipt asserted), same positive control (a DET002 sentinel that must fire or the run is ENV/2), same code filter. Its --self-test carries a drift gate that greps dogfood.sh for the identical rule tuples, a classifier case table, a must-RED fixture repo built from the incident's exact construct (a --repo argument parsed into a variable and used in a subshell cd; cd "$1" alone is not flagged, measured), its must-GREEN twin carrying paiml#3198's validation, and a vacuity case (gitignored script -> exit 2, named). Measured on real trees: main @ 0b6f94c -> exit 1, names cuda_rust_fleet_check.sh:129 DET002 and :201 SEC010; paiml#3198's tree -> exit 0. 3 s over 294 files. Wired as a step of guard-cargo, which gate already requires. dogfood.sh is untouched in this change; consolidating its inline row onto this script is the follow-up named in paiml#3196. Pmat-Ticket: PMAT-1098 Co-authored-by: Noah Gift <claude@noahgift.com> Co-authored-by: Claude Fable 5.1 <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
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.
GitHub builds queue entry N as a squash on top of entry N-1's squash, so at
position >= 2 the head has ONE parent that is not the origin/main tip and, at
fetch-depth 1, is not fetched. Every rule in resolve_base refused that shape
(exit 2 -> guard-tree FAIL), so with max_entries_to_build=3 the second and
third entries of every stacked build were RED on this resolver alone:
runs 34704287677 (#3139) and 34704288441 (#3046), 2026-09-12, each after
passing 82,085 workspace tests on gx10. Four PRs were dequeued today on it.
Under GITHUB_EVENT_NAME=merge_group the resolver now deepens the shallow
checkout by one commit (git fetch --deepen=1 origin, else fetch the parent by
sha) and names that parent as the base — exactly this entry's own diff. A
push-shape depth-1 head stays refused (never the tree against itself);
ROADMAP_DIFF_NO_DEEPEN=1 is the mutation.
Case table (check_roadmap_diff_additive.sh --self-test): rows 19-20 added —
a self-contained repo c1 -> c2 -> c3 with origin/main := c1 fetched by name
into a depth-1 clone (a shallow clone cannot update-ref to an object it
lacks; the fixture fetches the tip the way the job does). Row 19 resolves to
c2 under merge_group; row 20 is refused by name with deepening disabled.
Mutation measured: with origin/main's resolver restored, row 19 goes RED.
20/20 rows; bashrs 0 errors on both files (guard: 0 -> 0, lib: 0 -> 0).
Every consumer of the lib benefits: check_hardcoded_paths.sh (its ratchet
also read "origin/main tip" as the base for stacked entries),
check_no_fabricated_baselines.sh, check_dogfood_coverage.sh,
check_row_pr_write_set.sh.
Refs #3186, #3177, APR-RELEASE-001 §3.4/§5 P0·Pack (packing rule, operator
2026-09-12).
Closes #3186.
🤖 Generated with Claude Code