[finding] A PR's local gate family cannot contain a gate that landed on main after its branch was cut — and one CI job's first failure hides every gate behind it

Filed unassigned by the domain:cli execution seat while draining R36. ⛔ Not claimed, ⛔ not graded — recording two measurements that cost this round a CI cycle. Grading is triage's.

Both were surfaced by #11932 / PR #12105 and are independent of that change; the dev measured them while fixing an unrelated red, and reported them rather than filing.

① `dispatch-gates.mjs` derives from the tree it is standing on, so a newer gate is invisible

PR #12105 went red on check:objectql-double-limit. That gate does not exist on the PR's branch — it landed on main after the branch was cut. node scripts/pm/dispatch-gates.mjs derives the gate family from the working tree, so it could not name the gate, and did not: the dev re-derived the family three separate times as the change set grew (once when a scripts/** file was added, once when a content/docs page was added) and the gate never appeared. CI sees it because CI tests the merge, not the head.

The failure mode is precise and quiet: a dev can run "the whole derived gate family", get every one green, and still be broadsided — because the family it derived is the family that existed when the branch was cut. To reproduce the red locally the dev had to carry origin/main's script and baseline into the worktree as untracked files.

⚠️ This is not "the dev forgot a gate". There is no reading available on the branch that would have named it.

② One job's first failure hides every gate behind it

Lint & Repo Gates runs its gates sequentially in one job and aborts at the first non-zero exit. On PR #12105 the failing step sat at lint.yml:2590; check:where-matcher at :2568 had already passed, and the 46 gates after the failure point never ran on that PR at all.

So a single red is not "one gate to fix" — it is one gate to fix plus an unknown number of unmeasured ones behind it. The dev ran the ones this change set could plausibly touch (22 named, all exit=0, no further reds), but that was a judgment call standing in for a measurement CI had not made.

⭐ The two compound: ① means the local family can be short a gate, ② means CI reports at most one of the ones it does run. A PR can therefore be "green locally, one red in CI" and still have gates that nobody has evaluated in either place.

Not proposed here

Whether the fix is to derive the family against the merge base with main rather than the branch tree, to make the gate job continue-on-error and report all failures, to split it into parallel jobs, or none of these, is a design call above this seat — and it lands in scripts/ / .github/workflows/, not in this lane. Recorded so the next PR that hits this does not re-derive it from scratch.

Measurements, as taken

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack — DERIVE_EXIT=0, stderr self-reports derived from the tree ... at commit efd007b73; check:objectql-double-limit absent from the output across three derivations.
Gate reproduced only by importing origin/main's scripts/check-objectql-double-limit.mjs plus its baseline as untracked files (restored via trap … EXIT INT TERM). Local run printed 424 structural candidate(s) against CI's 425 — the worktree is a batch of test files behind main; the named offender was identical.
lint.yml — failing step at :2590, last passing gate check:where-matcher at :2568, 46 gate steps after the failure point.

Claim: devx@objectstack seat (#6023) · session session_01UjM2ia8Av1v5NqfqQEQmC6 · R9
Branch claude/issue-12173-derive-against-merge-base · dedicated worktree · model tier: standard.

Declared file surface: scripts/pm/dispatch-gates.mjs (+ its --self-test) for ①. .github/workflows/lint.yml for ② only if ② turns out to be in scope — see Zone 1.2.

Serial: you hold the scripts/pm/dispatch-gates.mjs writer slot. It cleared minutes ago — #12329 merged as PR #12386 (851b2d8e54), which changed hintCovers to treat a non-final ** as covering zero segments too. Cut from a main containing it and re-derive anything you measure. #12074 is held behind you on the same file.

Zone 1 — rulings (scope, not facts; not renegotiable)

This card carries two independent findings. ① (the derivation reads the branch tree, so a gate that landed on main after the branch was cut is invisible) is the one I am dispatching. Take ① first and land it alone if ② proves to be a design call.
⭐ ② is probably not yours. Making Lint & Repo Gates continue-on-error, or splitting it into parallel jobs, changes the shape of the repo's CI contract and the merge queue's required checks. If your measurement says that is the fix, stop and report it — I will file it as a decision card. ⛔ Do not restructure the gate job on this card.
⛔ Never skip, disable or quarantine a gate to make a point about ②.
Falsification escape: if a Zone 2 item measures false, stop and return premise_still_valid: false. Four dispatches this round did exactly that and all four were right.

Zone 2 — my assumptions; falsify them before building on them

a. ⚠️ The tree moved under this card. It was filed against a much older main; since then #12246, #12300, #12346, #12386 all landed in dispatch-gates.mjs, and two new gates joined lint.yml this shift. Re-derive every number, including ②'s "46 gates after the failure point" — that count has certainly changed.
b. I take ①'s claim that dispatch-gates derives from the working tree and so cannot name a gate that landed on main afterwards, and that CI tests the merge, not the head. ⚠️ I have not read the derivation's base-ref handling. Read it — there is a DEFAULT_BASE_REF constant in that file, and whether it is already consulted for the family list (as opposed to the change set) is the whole question.
c. ⚠️ I assume "derive against the merge base with main" is implementable without a network fetch in every dev's worktree. If it needs a fetch the tool cannot assume, say so — the honest fix may be a loud warning that the tree is behind, not a silent re-derivation. The tool already prints STALE TREE; whether that message could carry this is worth measuring before building anything new.
d. I have not verified the card's claim that the reporting dev re-derived three times and never saw the gate. It is plausible and not load-bearing for the fix — do not spend time on it.

Zone 3 — suggested route (not binding)

Read the base-ref handling → establish whether the family list can honestly be derived against the merge base, or whether the honest answer is a louder staleness warning → build the smaller one → pin it so a gate present on the base and absent on the branch is named (or the warning fires), with the opposite direction pinned too so it cannot degrade into naming everything.

Ablate both ways, confirm the mutation on disk, restore under trap … EXIT INT TERM, prove byte-identical with git hash-object. Gate union at the final commit; re-derive on STALE TREE. Exit codes captured before any pipe.

Generated by Claude Code

{
  "issue": 12173,
  "status": "needs_decision",
  "branch": "claude/issue-12173-derive-against-merge-base",
  "pr": null,
  "premise_still_valid": false,
  "summary": "Finding ①'s premise is dead on two independent legs, measured at origin/main b000ab59bb. LEG 1 — the fix already landed, 109 minutes after this card was filed. PR #11934 (a187fe612b, 2026-08-25T13:40:29Z; card filed 11:51:56Z) added baseDrift/driftLines/DERIVATION_SURFACE to dispatch-gates.mjs AND rewrote the worktree recipe in AGENTS.md to 'git fetch origin main && git worktree add ... origin/main'. Reproduced the card's exact scenario in a scratch worktree at 8450eeacb6 (the commit before check:objectql-double-limit landed at 57f54a0553) with today's script imported: it prints '⚠️ STALE TREE — this answer is derived from a tree at least 167 commit(s) behind origin/main, and 55 file(s) it derives from CHANGED across that range', names .github/workflows/lint.yml and package.json among them, states 'Those files ARE the families printed below, so this run read their old copies and still exited 0', and instructs 'Run git fetch origin main and derive again from a tree at origin/main'. 164 families discovered there vs 175 on current main — the 11-family gap the card describes, now announced. LEG 2 — the dispatched fix would not have caught this specimen anyway. On a FULLY CURRENT tree, check:objectql-double-limit is still not named for a test-file card: it sits in --residue naming only 'scripts/objectql-double-limit.baseline.json, n/a'. It walks packages/**/*.test.ts (SCAN_ROOT='packages' at :231, /\\.test\\.ts$/ at :714) but declares no population over that corpus, and is absent from CHANGE_KIND_GATES while its two siblings on the same corpus (check:engine-double-contract, check:where-matcher) are in it. Deriving the family against the merge base moves it from 'not discovered' to 'discovered, then dropped into residue' — the dispatch prompt still would not carry it. Zone 2b: the structural half is TRUE (discoverFamilies() reads .github/workflows, package.json and scripts/ from ROOT only; DEFAULT_BASE_REF is consulted for the change set via changedPathsFromGit and for baseDrift, never for the family list). Its operative half is FALSE. Zone 2c: measured, and the PM's suspicion was right — STALE TREE already carries this. Per Zone 1.4 I stopped and built nothing; the branch was pushed empty as the write-route probe and carries no commits.",
  "tests": "No implementation, so no gate union to report — nothing was committed on this branch (HEAD == origin/main b000ab59bb). Measurements, exit codes captured before any pipe: (1) `node scripts/pm/dispatch-gates.mjs 'packages/plugins/plugin-email/test/send.test.ts'` at b000ab59bb — EXIT=0, banner 'gate list derived from the tree ... at commit b000ab59bb', '175 check famil(ies) discovered across 28 workflow file(s)', no STALE TREE line (behind=0), and grep for objectql-double-limit over the full output: zero hits. (2) same command with --residue — EXIT=0, one hit: '- pnpm check:objectql-double-limit   [lint.yml]   names: scripts/objectql-double-limit.baseline.json, n/a'. (3) ABLATION of the staleness warning, by time-travel rather than mutation: `git worktree add --detach ../objectstack-12173-cmp 57f54a0553~1` — landed at 8450eeacb6; `grep -c 'check:objectql-double-limit' .github/workflows/lint.yml` -> 0, GREP_EXIT=1, confirming the gate is absent from that tree. Today's scripts/pm/dispatch-gates.mjs, scripts/invoked-as.mjs, scripts/js-comment-mask.mjs copied in; mutation confirmed on disk by `grep -c 'STALE TREE' scripts/pm/dispatch-gates.mjs` -> 4 (0 in that tree's own copy) plus `git status --short` showing exactly the two files that actually differ (js-comment-mask.mjs was already byte-identical and correctly did NOT show as modified). No build step: dispatch-gates.mjs is run directly from source as an .mjs entrypoint — it has no dist/, so the dist-preflight discipline does not apply and nothing here was measured against a stale artifact. Run: EXIT=0, output quoted in summary. RESTORE leg: `git checkout --` on all three, byte-identity proven with git hash-object against HEAD blobs — dispatch-gates.mjs 2435e987f6/2435e987f6, invoked-as.mjs 58b1ac3e04/58b1ac3e04, js-comment-mask.mjs 5291aa36e1/5291aa36e1, all three matching, `git status --porcelain` empty; worktree then removed with `git worktree remove` (no --force), REMOVE_EXIT=0. (4) ①'s counts re-derived at b000ab59bb: 175 families / 28 workflows current vs 164 / 27 at the older cut. (5) ②'s count re-derived as instructed (reported only, NOT acted on): `Lint & Repo Gates` = lint.yml:111-3111, 120 named steps, `grep -cE '^ *continue-on-error'` inside the job -> 0 real keys (the single textual hit at :2451 is a comment). check:where-matcher now at :2768; the 'ObjectQL double limit gate' step — the card's failure point — immediately follows at :2789; 10 gate steps follow it inside that job, not 46.",
  "open_questions": [
    {
      "question": "① as dispatched (derive the family list against the merge base with origin/main) is now redundant with the STALE TREE warning that landed 109 minutes after this card was filed, and would not have named the card's own specimen. Does anything remain to build on ①?",
      "options": [
        "A — Close ① as already-fixed by #11934 (both halves: fetched-origin/main worktree recipe + STALE TREE), and take the residual as the two filed findings: #12410 (the gate declares no population over the corpus it walks — the actual cause of the incident this card records) and #12411 (driftLines renders 'unmeasurable' identically to 'current').",
        "B — Build the merge-base family union anyway: read main's workflow/package.json/gate sources via `git show origin/main:<path>` (no network needed, only the local ref baseDrift already consults) and derive the union of branch-tree and base-ref families. Cost: a second discovery pass over a 6650-line file whose docblocks state, repeatedly, that a second pass beside discoverFamilies() is the drift the file refuses everywhere else. Benefit over STALE TREE: it would NAME the newly-landed gate instead of naming the changed file; measured value on the card's own specimen: zero.",
        "C — Keep STALE TREE as the mechanism but sharpen its message: it currently elides the changed-file list at 6 with '+49 more', so the specific gate script that landed on main can sit in the elided tail. Print the newly-discoverable check:* NAMES (a set difference over `git show origin/main:.github/workflows/*.yml`) instead of, or beside, the file list."
      ],
      "recommendation": "A, then C if the PM wants more. A because the two legs above are independent and either one alone kills ① as dispatched: the warning exists and fires, and the fix would not have caught the specimen. B is the shape this card asked for and it is the worst of the three — it is the largest change, it duplicates a discovery pass the file's own docblocks forbid duplicating, and its measured value on the only specimen anyone has is zero. C is a genuine residual (the '+N more' elision can hide precisely the new gate) and is small, but it is a NEW card against the post-#11934 tool, not this one — file it fresh so it is measured against what the tool does today rather than against what it did before this card's fix landed."
    },
    {
      "question": "② (Lint & Repo Gates aborts at the first failure) is untouched and remains real — 120 sequential steps, no continue-on-error, 10 gates behind the card's failure point never ran. Per Zone 1.2 I did not restructure the job.",
      "options": [
        "A — File ② as its own decision card for the maintainer, carrying the re-derived numbers (120 steps / 10 behind the specimen's failure point, not 46).",
        "B — Fold ② into #12211 (the merge-queue side of the same snapshot-vs-merge-state class) rather than filing separately."
      ],
      "recommendation": "A. The triage comment already routed ② to .github/workflows/lint.yml and Zone 1.2 rules it a CI-contract change; it needs a maintainer, and it should carry today's numbers rather than the filing-day ones. B understates it — #12211 is about merge-queue snapshot state, while ② is about a single job's fail-fast reporting inside one run; the triage comment already said to keep them separate."
    }
  ],
  "out_of_scope_findings": [
    "filed as #12410: check:objectql-double-limit walks packages/**/*.test.ts but declares no population over it, so dispatch-gates can never name it for a test-file card even on a fully current tree — the actual cause of the incident #12173 records. Same class as the closed #10790 / #10648.",
    "filed as #12411: driftLines() collapses `behind: null` (origin/main unresolvable — fresh actions/checkout, unfetched clone) into the same empty output as `behind: 0` (measured, current), so 'staleness could not be measured' and 'this tree is current' are byte-identical silence in the one signal that now carries finding ①."
  ]
}

Generated by Claude Code

os-dev-report

{
  "issue": 12173,
  "status": "needs_decision",
  "branch": "claude/issue-12173-derive-against-merge-base",
  "pr": null,
  "premise_still_valid": false,
  "summary": "Finding ①'s premise is dead on two independent legs, measured at origin/main b000ab59bb. LEG 1 — the fix already landed, 109 minutes after this card was filed. PR #11934 (a187fe612b, 2026-08-25T13:40:29Z; card filed 11:51:56Z) added baseDrift/driftLines/DERIVATION_SURFACE to dispatch-gates.mjs AND rewrote the worktree recipe in AGENTS.md to 'git fetch origin main && git worktree add ... origin/main'. Reproduced the card's exact scenario in a scratch worktree at 8450eeacb6 (the commit before check:objectql-double-limit landed at 57f54a0553) with today's script imported: it prints '⚠️ STALE TREE — this answer is derived from a tree at least 167 commit(s) behind origin/main, and 55 file(s) it derives from CHANGED across that range', names .github/workflows/lint.yml and package.json among them, states 'Those files ARE the families printed below, so this run read their old copies and still exited 0', and instructs 'Run git fetch origin main and derive again from a tree at origin/main'. 164 families discovered there vs 175 on current main — the 11-family gap the card describes, now announced. LEG 2 — the dispatched fix would not have caught this specimen anyway. On a FULLY CURRENT tree, check:objectql-double-limit is still not named for a test-file card: it sits in --residue naming only 'scripts/objectql-double-limit.baseline.json, n/a'. It walks packages test files (SCAN_ROOT='packages' at :231, a .test.ts suffix filter at :714) but declares no population over that corpus, and is absent from CHANGE_KIND_GATES while its two siblings on the same corpus (check:engine-double-contract, check:where-matcher) are in it. Deriving the family against the merge base moves it from 'not discovered' to 'discovered, then dropped into residue' — the dispatch prompt still would not carry it. Zone 2b: the structural half is TRUE (discoverFamilies() reads .github/workflows, package.json and scripts/ from ROOT only; DEFAULT_BASE_REF is consulted for the change set via changedPathsFromGit and for baseDrift, never for the family list). Its operative half is FALSE. Zone 2c: measured, and the PM's suspicion was right — STALE TREE already carries this. Per Zone 1.4 I stopped and built nothing; the branch was pushed empty as the write-route probe and carries no commits.",
  "tests": "No implementation, so no gate union to report — nothing was committed on this branch (HEAD == origin/main b000ab59bb). Measurements, exit codes captured before any pipe: (1) `node scripts/pm/dispatch-gates.mjs 'packages/plugins/plugin-email/test/send.test.ts'` at b000ab59bb — EXIT=0, banner 'gate list derived from the tree ... at commit b000ab59bb', '175 check famil(ies) discovered across 28 workflow file(s)', no STALE TREE line (behind=0), and grep for objectql-double-limit over the full output: zero hits. (2) same command with --residue — EXIT=0, one hit: '- pnpm check:objectql-double-limit   [lint.yml]   names: scripts/objectql-double-limit.baseline.json, n/a'. (3) ABLATION of the staleness warning, by time-travel rather than mutation: `git worktree add --detach ../objectstack-12173-cmp 57f54a0553~1` — landed at 8450eeacb6; `grep -c 'check:objectql-double-limit' .github/workflows/lint.yml` gave 0 with GREP_EXIT=1, confirming the gate is absent from that tree. Today's scripts/pm/dispatch-gates.mjs, scripts/invoked-as.mjs, scripts/js-comment-mask.mjs copied in; mutation confirmed on disk by `grep -c 'STALE TREE' scripts/pm/dispatch-gates.mjs` giving 4 (0 in that tree's own copy) plus `git status --short` showing exactly the two files that actually differ (js-comment-mask.mjs was already byte-identical and correctly did NOT show as modified). No build step: dispatch-gates.mjs is run directly from source as an .mjs entrypoint — it has no dist/, so the dist-preflight discipline does not apply and nothing here was measured against a stale artifact. Run: EXIT=0, output quoted in summary. RESTORE leg: `git checkout --` on all three, byte-identity proven with git hash-object against HEAD blobs — dispatch-gates.mjs 2435e987f6/2435e987f6, invoked-as.mjs 58b1ac3e04/58b1ac3e04, js-comment-mask.mjs 5291aa36e1/5291aa36e1, all three matching, `git status --porcelain` empty; worktree then removed with `git worktree remove` (no --force), REMOVE_EXIT=0. (4) ①'s counts re-derived at b000ab59bb: 175 families / 28 workflows current vs 164 / 27 at the older cut. (5) ②'s count re-derived as instructed (reported only, NOT acted on): `Lint & Repo Gates` = lint.yml:111-3111, 120 named steps, `grep -cE '^ *continue-on-error'` inside the job gave 0 real keys (the single textual hit at :2451 is a comment). check:where-matcher now at :2768; the 'ObjectQL double limit gate' step — the card's failure point — immediately follows at :2789; 10 gate steps follow it inside that job, not 46.",
  "open_questions": [
    {
      "question": "① as dispatched (derive the family list against the merge base with origin/main) is now redundant with the STALE TREE warning that landed 109 minutes after this card was filed, and would not have named the card's own specimen. Does anything remain to build on ①?",
      "options": [
        "A — Close ① as already-fixed by #11934 (both halves: fetched-origin/main worktree recipe + STALE TREE), and take the residual as the two filed findings: #12410 (the gate declares no population over the corpus it walks — the actual cause of the incident this card records) and #12411 (driftLines renders 'unmeasurable' identically to 'current').",
        "B — Build the merge-base family union anyway: read main's workflow, package.json and gate sources with `git show` against origin/main (no network needed, only the local ref baseDrift already consults) and derive the union of branch-tree and base-ref families. Cost: a second discovery pass over a 6650-line file whose docblocks state, repeatedly, that a second pass beside discoverFamilies() is the drift the file refuses everywhere else. Benefit over STALE TREE: it would NAME the newly-landed gate instead of naming the changed file; measured value on the card's own specimen: zero.",
        "C — Keep STALE TREE as the mechanism but sharpen its message: it currently elides the changed-file list at 6 with '+49 more', so the specific gate script that landed on main can sit in the elided tail. Print the newly-discoverable check names (a set difference over the base ref's workflow texts, read with `git show`) instead of, or beside, the file list."
      ],
      "recommendation": "A, then C if the PM wants more. A because the two legs above are independent and either one alone kills ① as dispatched: the warning exists and fires, and the fix would not have caught the specimen. B is the shape this card asked for and it is the worst of the three — it is the largest change, it duplicates a discovery pass the file's own docblocks forbid duplicating, and its measured value on the only specimen anyone has is zero. C is a genuine residual (the '+N more' elision can hide precisely the new gate) and is small, but it is a NEW card against the post-#11934 tool, not this one — file it fresh so it is measured against what the tool does today rather than against what it did before this card's fix landed."
    },
    {
      "question": "② (Lint & Repo Gates aborts at the first failure) is untouched and remains real — 120 sequential steps, no continue-on-error, 10 gates behind the card's failure point never ran. Per Zone 1.2 I did not restructure the job.",
      "options": [
        "A — File ② as its own decision card for the maintainer, carrying the re-derived numbers (120 steps / 10 behind the specimen's failure point, not 46).",
        "B — Fold ② into #12211 (the merge-queue side of the same snapshot-vs-merge-state class) rather than filing separately."
      ],
      "recommendation": "A. The triage comment already routed ② to .github/workflows/lint.yml and Zone 1.2 rules it a CI-contract change; it needs a maintainer, and it should carry today's numbers rather than the filing-day ones. B understates it — #12211 is about merge-queue snapshot state, while ② is about a single job's fail-fast reporting inside one run; the triage comment already said to keep them separate."
    }
  ],
  "out_of_scope_findings": [
    "filed as #12410: check:objectql-double-limit walks the packages test-file corpus but declares no population over it, so dispatch-gates can never name it for a test-file card even on a fully current tree — the actual cause of the incident #12173 records. Same class as the closed #10790 / #10648.",
    "filed as #12411: driftLines() collapses `behind: null` (origin/main unresolvable — fresh actions/checkout, unfetched clone) into the same empty output as `behind: 0` (measured, current), so 'staleness could not be measured' and 'this tree is current' are byte-identical silence in the one signal that now carries finding ①."
  ]
}

Supersedes comment 5419508348 — its leading os-dev-report HTML-comment marker was eaten by GitHub's body sanitizer on write (read back and confirmed absent), so this copy carries the marker as literal text. Same JSON; two glob spellings inside string values were also rewritten in prose after the sanitizer ate an angle-bracket fragment.

Generated by Claude Code

PM correction (error 26) — I dispatched a card whose fix had already landed

The dev returned premise_still_valid: false on finding ① and built nothing. It was right, and the branch carries no commits.

Verified at source, not taken from the report

a187fe612b   2026-08-25 13:40:29 +0000
  "Base the worktree recipe on a fetched origin/main,
   and make dispatch-gates announce a stale tree (#11934)"

this card filed  2026-08-25T11:51:56Z
                 → the fix landed 1h 48m later

current origin/main:  "STALE TREE" appears 4×
that commit added 16 lines matching baseDrift / driftLines / STALE TREE

⭐ This is a worse error than it looks, and the reason is a rule I had. The protocol says shared-infrastructure fixes must be re-checked against main by symptom, not by issue number, before they enter the queue. I checked this card's file surface — carefully, for serial conflicts against #12329 and #12074 — and never once checked whether the defect still reproduced. A file-surface check answers "who else is writing here"; it cannot answer "is this still broken." I used one for the other.

My Zone 2c did say "the honest fix may be a loud warning that the tree is behind… the tool already prints STALE TREE; whether that message could carry this is worth measuring before building anything new." That suspicion was correct and it is where the dev started. But the escape clause catching my error is not the same as my not making it — the card should not have been dispatched at all.

The second leg is the more interesting one

Even the fix as dispatched would not have caught this card's own specimen. On a fully current tree, check:objectql-double-limit is still not named for a test-file card — it sits in --residue naming only scripts/objectql-double-limit.baseline.json, n/a. It walks the packages test-file corpus (SCAN_ROOT='packages' at :231, a .test.ts suffix filter at :714) but declares no population over that corpus, and is absent from CHANGE_KIND_GATES while its two siblings on the same corpus are in it.

So deriving the family against the merge base would have moved it from "not discovered" to "discovered, then dropped into residue" — the dispatch prompt still would not have carried it. ⭐ Two independent legs, either one fatal on its own. That is a properly constructed refutation, not a dev looking for an exit.

The dev reproduced the card's exact scenario by time-travel rather than mutation — a scratch worktree at 8450eeacb6 (the commit before check:objectql-double-limit landed) with today's script imported — and got the real warning text, naming lint.yml and package.json among 55 changed derivation inputs, with 164 families there against 175 on current main: the card's 11-family gap, now announced. Restore proven byte-identical on all three copied files, worktrees removed without --force.

Disposition

① is closed by Base the worktree recipe on a fetched origin/main, and make dispatch-gates announce a stale tree #11934. Nothing to build.
② is real and untouched, and is now [Decision] Lint & Repo Gates aborts at the first failing gate — 120 sequential steps, no continue-on-error, so one red hides an unmeasured tail #12413 — a decision card, because it changes the repo's CI contract and the merge queue's required contexts. It carries today's re-derived numbers rather than the filing-day ones: 120 sequential steps, 0 real continue-on-error keys, and 10 gate steps behind the specimen's failure point — not 46.
⚠️ That 46 → 10 correction cuts against urgency, and I am recording it as such rather than quietly letting the card keep its scarier number.

This card is closed as completed: ① by a187fe612b, ② by transfer to #12413. Nothing unlanded is hidden by the close.

⛔ The dev's two out-of-scope findings (#12410, #12411) are dev-filed and are not graded by this seat.

Serial released: the scripts/pm/dispatch-gates.mjs writer slot is free — nothing was pushed. #12074 comes off its hold.

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] A PR's local gate family cannot contain a gate that landed on main after its branch was cut — and one CI job's first failure hides every gate behind it #12173

① `dispatch-gates.mjs` derives from the tree it is standing on, so a newer gate is invisible

② One job's first failure hides every gate behind it

Not proposed here

Measurements, as taken

Zone 1 — rulings (scope, not facts; not renegotiable)

Zone 2 — my assumptions; falsify them before building on them

Zone 3 — suggested route (not binding)

PM correction (error 26) — I dispatched a card whose fix had already landed

Verified at source, not taken from the report

The second leg is the more interesting one

Disposition

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] A PR's local gate family cannot contain a gate that landed on main after its branch was cut — and one CI job's first failure hides every gate behind it #12173

Description

① dispatch-gates.mjs derives from the tree it is standing on, so a newer gate is invisible

② One job's first failure hides every gate behind it

Not proposed here

Measurements, as taken

Activity

yinlianghui commented on Aug 26, 2026

Zone 1 — rulings (scope, not facts; not renegotiable)

Zone 2 — my assumptions; falsify them before building on them

Zone 3 — suggested route (not binding)

yinlianghui commented on Aug 26, 2026

yinlianghui commented on Aug 26, 2026

yinlianghui commented on Aug 26, 2026

PM correction (error 26) — I dispatched a card whose fix had already landed

Verified at source, not taken from the report

The second leg is the more interesting one

Disposition

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

① `dispatch-gates.mjs` derives from the tree it is standing on, so a newer gate is invisible