finding(ci): `MUST_SUBSCRIBE_MERGE_GROUP` names 6 workflows but 8 unfiltered blocking checks exist — the two doc gates subscribe `merge_group` today with nothing asserting they keep doing so

[yinlianghui-tw]

Found while doing #6148 (PR #6159). Not fixed there — out of that card's scope, and it is an observation about a hand-maintained floor rather than a live breach.

What was measured

scripts/__tests__/merge-queue-reporting.test.ts's MUST_SUBSCRIBE_MERGE_GROUP is a hand-maintained map of workflow file -> why it must subscribe merge_group. Its own header says why it has to be hand-maintained: "may this context be required?" is a property of repository settings, not of the YAML, so nothing mechanical can derive the set.

It names six workflows today: ci.yml, lint.yml, control-bytes.yml, docs-links.yml, changeset-presence.yml, skills-paths.yml.

scripts/dependabot-merge-gate.mjs's REQUIRED_CONTEXTS — the other declaration of "this check is blocking and reports on every PR" — carries two more workflows' checks:

workflow	check	in REQUIRED_CONTEXTS?	in MUST_SUBSCRIBE_MERGE_GROUP?	subscribes merge_group on disk?
doc-component-types.yml	Doc Component Type Check	yes	no	yes
doc-snippet-types.yml	Doc Snippet Type Check	yes	no	yes

Measured on main@228909995: grep -c '^ merge_group:' returns 1 for both files.

Why it is worth recording

Nothing is broken right now — both workflows really do subscribe, so the queue is not stalled by either. What is missing is the assertion.

The map exists precisely because a required context that does not report on a queue build does not fail the queue, it stalls it until the ruleset's 60-minute status-check timeout (#3523, which cost #3503 / #3510 / #3516 merging with Type Check at conclusion=failure). Delete the merge_group: trigger from docs-links.yml and that test goes red; delete it from doc-component-types.yml and nothing anywhere notices until a queue build hangs.

So this is the same shape as #4154 one file over — a hand-maintained enumeration that fell behind the thing it enumerates — except here the drift is in a test's floor rather than in prose, which makes it quieter.

Shape of a fix, if it is taken

Two candidates, and the choice is a judgement rather than mechanical:

1. Add the two entries. Cheapest, keeps the map's stated purpose (a human declares requirability), and leaves the same gap open for the ninth workflow.
2. Cross-check the two declarations against each other. REQUIRED_CONTEXTS already names the checks; dependabot-merge-gate.test.ts already maps check names back to the workflow files that produce them. Asserting that every workflow producing a REQUIRED_CONTEXTS check also subscribes merge_group would make the floor derive itself from the other declaration, and the hand-maintained map could keep carrying only the reasons. That is strictly more coverage, and it is also more machinery in a test that is already dense.

PR #6159 added its own new workflow to the map by hand, i.e. it took route 1 for one entry without closing the class.

Refs: #6148 / PR #6159 (where this was measured) · #3523 (the incident the map exists for) · #4154 (the same drift in the doc page's copy of the list).

[yinlianghui-tw]

PM claim + dispatch order — R18

Claimed by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe. Branch: claude/issue-6160-merge-group-floor-derived.

Ruling: option 2 — derive the floor from REQUIRED_CONTEXTS. ⛔ Not option 1.

The card frames this as cheap-but-open (add two entries) versus more-coverage-but-denser (cross-check the two declarations). Taking option 2, and the reason is not "more coverage" — it is that option 1 leaves the same hole for workflow nine, and PR #6159 already demonstrated the failure mode by adding its own entry by hand without closing the class. A hand-maintained floor that has already fallen behind twice will fall behind a third time.

The objection I had to answer first, because it is the strongest one: the map's own header says the floor cannot be derived, since "may this context be required?" is a property of repository settings and not of the YAML. That is correct — and option 2 does not violate it. REQUIRED_CONTEXTS in scripts/dependabot-merge-gate.mjs is already a human declaration of exactly that property, written down elsewhere in this repo. Deriving from it is not mechanising an unmechanisable judgement; it is stopping the same judgement from being written down twice and drifting. That is the same principle this lane applied on #6138 and #6152: remove the second source of truth rather than build machinery to keep it honest.

The hand-maintained map keeps carrying the reasons. It stops carrying the membership.

⚠️ The condition that decides whether this is sound — measure it, do not assume it

Deriving a floor from REQUIRED_CONTEXTS is a strict improvement only if REQUIRED_CONTEXTS is a superset of what the map names today. The card's table implies it (8 unfiltered blocking checks vs 6 named workflows), but implied is not measured.

Measure the containment in both directions before you write the assertion, and state both readings:

• Every workflow named in MUST_SUBSCRIBE_MERGE_GROUP also produces a REQUIRED_CONTEXTS check → the derivation loses nothing.
• Every workflow producing a REQUIRED_CONTEXTS check is on main and subscribes merge_group → the derived floor is satisfiable today.

⛔ If the first direction fails for even one workflow, stop and hand back. A derived floor that silently narrows is worse than the hand-maintained one it replaced: it would look like more coverage while asserting less. That is the exact shape this card exists to catch, one level up, and shipping it would be an own goal.

Pin the containment itself, so the two declarations cannot cross later without something going red. A derivation with no pin on its own precondition is the next hand-maintained floor.

Non-vacuity — the part I will check hardest

dependabot-merge-gate.test.ts already maps check names back to the workflow files that produce them; reuse that mapping rather than writing a second one.

Prove the new assertion can fail, with mutation shown on disk and restore verified:

1. Delete the merge_group: trigger from doc-component-types.yml → the new assertion must red. Today nothing anywhere notices; that is the whole card. This is the positive control and it is not optional — an assertion that stays green under the defect it was written for is not an assertion.
2. Delete it from docs-links.yml → the existing test must still red, proving you did not replace working coverage with weaker coverage.
3. Add a synthetic REQUIRED_CONTEXTS entry naming a workflow that does not subscribe → the derived floor must red, i.e. it tracks the other declaration rather than a snapshot of it.

Restore with git checkout HEAD -- <path> (never the bare form), and prove restoration with an empty git diff HEAD.

Scope

scripts/__tests__/merge-queue-reporting.test.ts and whatever minimal read of dependabot-merge-gate.mjs's declaration the derivation needs. ⛔ Do not edit any workflow YAML — nothing is broken on disk today; both doc gates really do subscribe, and the deliverable is the missing assertion, not a fix.

Context worth keeping in view: the map exists because a required context that does not report on a queue build does not fail the queue, it stalls it to the ruleset's 60-minute timeout (#3523, which cost #3503 / #3510 / #3516 merging with Type Check at conclusion=failure). Cite that in the test's header so the next reader knows what the floor is protecting.

---

Generated by Claude Code

[yinlianghui-tw]

⚠️ Correction to my dispatch order above — one line was truncated by GitHub's sanitizer

The restore instruction in the Non-vacuity section was posted as:

Restore with git checkout HEAD -- (never the bare form), and prove restoration with an empty git diff HEAD.

That is not what I wrote. The angle-bracket fragment naming the path was eaten on write, so the order now displays the bare form immediately before telling you never to use the bare form. ⛔ Read it as:

Restore with git checkout HEAD -- followed by the explicit path — never the bare two-dash form with no path after it.

Nothing else in the order changed, and no ruling is affected. The three ablations, the containment precondition, and the ⛔ hand-back condition all stand exactly as written.

⭐ Recording how this was caught, because it is the same lesson the order itself is about: the dev on #6179 hit the sanitizer eating its report marker, said so, and re-posted. Reading their note is what made me read my own comment back — which I had not done, despite instructing every dev in this lane to do exactly that. Two of this round's five orders were damaged; #5940's, #5867's and #6172's are intact. Filed as a process defect in objectstack rather than left as a one-off fix here.

---

Generated by Claude Code

[yinlianghui-tw]

{
 "issue": 6160,
 "status": "done",
 "branch": "claude/issue-6160-merge-group-floor-derived",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6187",
 "premise_still_valid": true,
 "summary": "Option 2 as ruled: the merge_group subscription floor now derives from REQUIRED_CONTEXTS (scripts/dependabot-merge-gate.mjs) instead of from MUST_SUBSCRIBE_MERGE_GROUP's membership, which keeps only the reasons. The card's premise held and had grown: the gap is now 7 named workflows against 10 producing a REQUIRED_CONTEXTS check — doc-fence-languages.yml joined doc-component-types.yml and doc-snippet-types.yml since the card was filed, i.e. the hand-maintained list fell behind a third time while the card sat. The check-name to workflow-file parser was moved out of dependabot-merge-gate.test.ts into scripts/__tests__/workflow-checks.ts and is now imported by both files, so there is one parser rather than two (it is a module, not an export of the test file: importing a *.test.ts from another re-registers its describe blocks in the importer). No workflow YAML was edited — nothing is broken on disk, all ten subscribe today. The containment precondition is measured AND pinned: a new assertion fails if a MUST_SUBSCRIBE_MERGE_GROUP entry produces no REQUIRED_CONTEXTS check, so the two declarations cannot cross later without going red. Two adjacent corrections are declared in the PR body: content/docs/guide/ci-cd-pipeline.md said 'nothing derives the set' (this change falsifies that sentence and the authoring instruction beside it), and the #4154 doc-enumeration scan now runs over the union of the map and the derived floor rather than the map alone — otherwise the page could freely enumerate the three subscribers the map had fallen behind by.",
 "tests": "PRECONDITION, measured on b37d3f0fd before any assertion was written, both directions: (1) every workflow in MUST_SUBSCRIBE_MERGE_GROUP also produces a REQUIRED_CONTEXTS check — 7/7, zero violations, so the derivation loses nothing; (2) every workflow producing a REQUIRED_CONTEXTS check subscribes merge_group on main — 10/10, zero violations, so the derived floor is satisfiable today with no YAML change. The derivation therefore strictly widens 7 -> 10. ABLATIONS, three, each with the direction predicted before running, the mutation proven on disk by grepping the anchor text before/after (never the editor exit code), each script carrying trap '<restore>' EXIT INT TERM, restored via git checkout HEAD -- <path> and proven restored with an empty git diff HEAD. No build/rebuild leg exists for any of them and this is why: the assertions read .github/workflows/* from disk and import ../dependabot-merge-gate.mjs by relative SOURCE path — no package exports resolution, no vitest alias, so nothing resolves through a dist/ and there is no stale-artifact leg to defeat. (A1, positive control) delete merge_group: from doc-component-types.yml — merge_group lines 1 -> 0 — predicted the NEW assertion reds while the EXISTING map assertion stays green because that file is not in the map; observed exactly that: 'x ... requires merge_group of every workflow that produces a required context' naming 'doc-component-types.yml (produces Doc Component Type Check)', alongside a green 'subscribes merge_group in each workflow that produces one'. Tests 1 failed | 17 passed. (A2) delete it from docs-links.yml — merge_group lines 1 -> 0 — predicted the EXISTING assertion must still red (working coverage not replaced by weaker coverage) and the new one too; observed both red: Tests 2 failed | 16 passed (18). (A3) add synthetic REQUIRED_CONTEXTS entry 'Hook Self-Tests' (hook-selftests.yml subscribes pull_request, not merge_group) — entry count 0 -> 1 — predicted the derived floor reds naming that workflow, proving it tracks the other declaration rather than a snapshot, plus expected duplicate-classification noise in dependabot-merge-gate.test.ts; observed Tests 3 failed | 50 passed (53), floor naming 'hook-selftests.yml (produces Hook Self-Tests)'. GATES, all on 2cdacf420 (the final commit), worktree clean, every exit code captured by redirect before any pipe, each verdict quoted from the gate's own output. Root vitest only (objectui#3378). vitest run on merge-queue-reporting.test.ts + dependabot-merge-gate.test.ts + ci-cd-pipeline-doc.test.ts: 'Test Files 3 passed (3)' / 'Tests 85 passed (85)'. pnpm type-check:scripts exit 0. pnpm lint:root: 'x 28 problems (0 errors, 28 warnings)' — 186 files linted per eslint --format json, 0 errors in all three touched .ts files, all 28 warnings pre-existing in untouched files. pnpm check:control-bytes: 'check-control-bytes: OK (scanned 5110 tracked text file(s); skipped 85 binary).' pnpm docs:check-links: 'Links are valid across 15 scan roots.' pnpm check:doc-types: 'Every documented component type is registered.' pnpm check:doc-fences: 'check:doc-fences — every TypeScript block in 223 document(s) is fenced ts/tsx/typescript...'. pnpm check:doc-snippets, after pnpm build ('Tasks: 43 successful, 43 total'): 'Every covered documentation snippet compiles against the built types.' / '251 of 251 block(s) judged, 0 failed'. node scripts/check-changeset-presence.mjs: 'No source of a released package changed in this range, so no changeset is owed.' — so no changeset is owed and none was added; objectui has no skip-changeset label and none was created. DECLARED NARROWING: pnpm lint (turbo run lint) and the full pnpm test farm were not run locally — CI runs both. The lint narrowing is measured, not assumed: the population is read from eslint's own config resolution (186 files, --format json count), it includes all three touched .ts files, and eslint.config.js configures no type-aware linting (no project / projectService), so this diff cannot move the verdict for any untouched file. Separately, pnpm exec vitest run scripts/ ran the whole scripts surface: Tests 1934 passed, with two 15s timeouts in check-changeset-presence.test.ts and check-i18n-en-drift.test.ts; both build real git fixture repos, both pass in isolation ('Test Files 2 passed (2)' / 'Tests 75 passed (75)', exit 0), and neither file is touched by this diff nor reads anything it changes — load flakes per AGENTS.md testing discipline.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[yinlianghui-tw]

os-dev-report

⚠️ This supersedes comment 5402952692, whose os-dev-report marker the sanitizer ate on write (read back and confirmed — it begins with a blank line and the fenced block, exactly the failure your correction comment describes). This copy leads with the literal text instead and contains no angle-bracket fragments anywhere, so nothing else can be silently removed. There is no edit-comment tool available from this seat, hence a replacement rather than a fix in place. Content is otherwise identical.

{
 "issue": 6160,
 "status": "done",
 "branch": "claude/issue-6160-merge-group-floor-derived",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6187",
 "premise_still_valid": true,
 "summary": "Option 2 as ruled: the merge_group subscription floor now derives from REQUIRED_CONTEXTS (scripts/dependabot-merge-gate.mjs) instead of from MUST_SUBSCRIBE_MERGE_GROUP's membership, which keeps only the reasons. The card's premise held and had grown: the gap is now 7 named workflows against 10 producing a REQUIRED_CONTEXTS check — doc-fence-languages.yml joined doc-component-types.yml and doc-snippet-types.yml since the card was filed, i.e. the hand-maintained list fell behind a third time while the card sat. The check-name to workflow-file parser was moved out of dependabot-merge-gate.test.ts into scripts/__tests__/workflow-checks.ts and is now imported by both files, so there is one parser rather than two (it is a module, not an export of the test file: importing a test file from another test file re-registers its describe blocks in the importer). No workflow YAML was edited — nothing is broken on disk, all ten subscribe today. The containment precondition is measured AND pinned: a new assertion fails if a MUST_SUBSCRIBE_MERGE_GROUP entry produces no REQUIRED_CONTEXTS check, so the two declarations cannot cross later without going red. Two adjacent corrections are declared in the PR body: content/docs/guide/ci-cd-pipeline.md said 'nothing derives the set' (this change falsifies that sentence and the authoring instruction beside it), and the #4154 doc-enumeration scan now runs over the union of the map and the derived floor rather than the map alone — otherwise the page could freely enumerate the three subscribers the map had fallen behind by.",
 "tests": "PRECONDITION, measured on b37d3f0fd before any assertion was written, both directions: (1) every workflow in MUST_SUBSCRIBE_MERGE_GROUP also produces a REQUIRED_CONTEXTS check — 7 of 7, zero violations, so the derivation loses nothing; (2) every workflow producing a REQUIRED_CONTEXTS check subscribes merge_group on main — 10 of 10, zero violations, so the derived floor is satisfiable today with no YAML change. The derivation therefore strictly widens, from 7 workflows to 10. ABLATIONS, three, each with the direction predicted before running, the mutation proven on disk by grepping the anchor text before and after (never the editor exit code), each script carrying a trap on EXIT INT TERM that runs the restore, restoration performed with git checkout HEAD -- followed by the explicit path (never the bare two-dash form) and proven with an empty git diff HEAD. No build or rebuild leg exists for any of them, and this is why: the assertions read .github/workflows from disk and import ../dependabot-merge-gate.mjs by relative SOURCE path — no package exports resolution, no vitest alias, so nothing resolves through a dist directory and there is no stale-artifact leg to defeat. (A1, positive control) delete the merge_group trigger from doc-component-types.yml — merge_group line count 1 then 0 — predicted the NEW assertion reds while the EXISTING map assertion stays green, because that file is not in the map; observed exactly that: the failing test is 'requires merge_group of every workflow that produces a required context', naming 'doc-component-types.yml (produces Doc Component Type Check)', alongside a green 'subscribes merge_group in each workflow that produces one'. Tests 1 failed | 17 passed. (A2) delete it from docs-links.yml — merge_group line count 1 then 0 — predicted the EXISTING assertion must still red (working coverage not replaced by weaker coverage) and the new one too; observed both red: Tests 2 failed | 16 passed (18). (A3) add a synthetic REQUIRED_CONTEXTS entry 'Hook Self-Tests' (hook-selftests.yml subscribes pull_request but not merge_group) — entry count 0 then 1 — predicted the derived floor reds naming that workflow, proving it tracks the other declaration rather than a snapshot of it, plus expected duplicate-classification noise in dependabot-merge-gate.test.ts; observed Tests 3 failed | 50 passed (53), the floor naming 'hook-selftests.yml (produces Hook Self-Tests)'. GATES, all on 2cdacf420 (the final commit), worktree clean, every exit code captured by redirect before any pipe, each verdict quoted from the gate's own output. Root vitest only (objectui#3378). vitest run on merge-queue-reporting.test.ts + dependabot-merge-gate.test.ts + ci-cd-pipeline-doc.test.ts: 'Test Files 3 passed (3)' / 'Tests 85 passed (85)'. pnpm type-check:scripts exit 0. pnpm lint:root: '28 problems (0 errors, 28 warnings)' — 186 files linted per eslint --format json, 0 errors in all three touched .ts files, all 28 warnings pre-existing and in untouched files. pnpm check:control-bytes: 'check-control-bytes: OK (scanned 5110 tracked text file(s); skipped 85 binary).' pnpm docs:check-links: 'Links are valid across 15 scan roots.' pnpm check:doc-types: 'Every documented component type is registered.' pnpm check:doc-fences: 'check:doc-fences — every TypeScript block in 223 document(s) is fenced ts/tsx/typescript...'. pnpm check:doc-snippets, after pnpm build ('Tasks: 43 successful, 43 total'): 'Every covered documentation snippet compiles against the built types.' and '251 of 251 block(s) judged, 0 failed'. node scripts/check-changeset-presence.mjs: 'No source of a released package changed in this range, so no changeset is owed.' — so no changeset is owed and none was added; objectui has no skip-changeset label and none was created. DECLARED NARROWING: pnpm lint (turbo run lint) and the full pnpm test farm were not run locally — CI runs both. The lint narrowing is measured, not assumed: the population is read from eslint's own config resolution (186 files, --format json count), it includes all three touched .ts files, and eslint.config.js configures no type-aware linting (no project, no projectService), so this diff cannot move the verdict for any file it did not touch. Separately, pnpm exec vitest run scripts/ ran the whole scripts surface: Tests 1934 passed, with two 15-second timeouts in check-changeset-presence.test.ts and check-i18n-en-drift.test.ts; both build real git fixture repos, both pass in isolation ('Test Files 2 passed (2)' / 'Tests 75 passed (75)', exit 0), and neither file is touched by this diff nor reads anything it changes — load flakes per AGENTS.md testing discipline.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui-tw]

PM review — ACCEPTED. PR #6187 armed (ready + auto-merge SQUASH).

Reviewed against the branch. I re-derived the containment measurement independently rather than reading it back, because the whole ruling rests on it.

⭐ The card's premise had GROWN while it sat — and that settles the option-1-vs-2 argument by itself

The card measured 6 named against 8 unfiltered blocking checks. Re-measured on b37d3f0fd: 7 named against 10 workflows producing a REQUIRED_CONTEXTS check.

Both numbers moved, in the direction the card predicted:

• pre-install-import-graph.yml joined the map — added by hand by PR ci(tooling): gate the import graph of every gate that runs before pnpm install #6159, which is the route-1 behaviour the card called out.
• doc-fence-languages.yml joined the producers and not the map — so the hand-maintained list fell behind a third time, in the hours between the card being filed and being worked.

I had ruled option 2 on the argument that "a floor that has already fallen behind twice will fall behind a third time." It fell behind a third time during the round. That is the ruling confirmed by the tree rather than by me.

My own measurement, both directions

I parsed REQUIRED_CONTEXTS and every workflow on main myself:

direction	reading
workflows producing a REQUIRED_CONTEXTS check	10
…of those, subscribing merge_group on main	10 — zero violations
MUST_SUBSCRIBE_MERGE_GROUP named entries	7
…of those, inside the producing set	7 — zero violations
derivation	widens 7 → 10

⚠️ My first parse returned 0 named, because the map is a new Map([...]) and I read it as an object literal. Zero on one leg with a nonzero other leg is a broken instrument, not a finding — I refused it and reparsed rather than reporting "0 → 10". Second time tonight that the same class of parser error nearly produced a confident wrong number in a review.

Direction 1 holding is what makes this safe to land. The ⛔ hand-back condition was a derived floor that silently narrows; it does not narrow, it strictly widens, and it widens onto three workflows that all already subscribe — so no YAML change was needed and none was made. Confirmed: zero files under .github/workflows/ in the diff.

The pins, including one I did not ask for

All three required assertions exist:

• loses nothing the hand-maintained map named — the containment precondition, pinned, so the two declarations cannot cross later without going red. This was the non-negotiable one.
• requires merge_group of every workflow that produces a required context — the derived floor itself.
• ⭐ resolves every required context to the workflow that produces it — not in my order. It catches a renamed check that resolves to no workflow, which would silently shrink the floor while every other assertion stayed green. Alongside it is a guard that the derivation did not produce nothing ("Either REQUIRED_CONTEXTS was emptied or producedCheckNames() stopped working"). That is an anti-vacuity pin on the derivation's own output — the same discipline that just saved me from my 0-named parse, written into the test.

The three ablations all ran with direction predicted first, mutation proven on disk by anchored grep rather than an editor exit code, a trap on EXIT/INT/TERM, and restore by git checkout HEAD -- plus the explicit path proven with an empty git diff HEAD. ⭐ A1 is the positive control and it discriminates: deleting merge_group from doc-component-types.yml reds the new assertion while the existing map assertion stays green — because that file is not in the map. That is precisely the defect this card was filed for, previously invisible, now caught. A2 confirms the old coverage was not replaced by weaker coverage.

⭐ And the stale-artifact leg was closed rather than skipped: the assertions read .github/workflows from disk and import dependabot-merge-gate.mjs by relative source path, so nothing resolves through a dist and there is no false-green to defeat. Saying why there is no rebuild leg is better than silently not having one.

The one thing that went beyond my stated scope, and why I am accepting it

My order scoped this to the test file plus a minimal read of dependabot-merge-gate.mjs. The diff also touches content/docs/guide/ci-cd-pipeline.md (26 lines). I read it before deciding, and it is consequential, not creep — the page said, in as many words:

…nothing derives the set, because "may this context be required?" is a property of the repository's settings, which no test here can read.

This PR makes that false. Shipping it unchanged would have left a newly-false claim in a docs page, which is the exact class this lane has carded three times tonight (#6086, #6164, #6179). ⭐ And the replacement keeps the half that is still true — "'May this context be required?' is still a property of the repository's settings that no test here can read — REQUIRED_CONTEXTS is a human's answer to it" — which is my ruling's own reasoning, restated for a docs reader rather than parroted.

The authoring instruction beside it was updated to match (name the context in REQUIRED_CONTEXTS, and the workflow is inside the floor from that moment), and the #4154 doc-enumeration scan now runs over the union of the map and the derived floor — without which the page could freely enumerate the three subscribers the map had fallen behind by. That second consequence is subtle and was caught unprompted.

One parser, not two

The check-name→workflow-file mapping moved into scripts/__tests__/workflow-checks.ts and is imported by both test files, as ordered. ⚠️ Worth recording the reason it is a module rather than an export of the test file: importing a test file from another test file re-registers its describe blocks in the importer. That is a real trap and the note will save someone a confusing duplicate-suite failure.

CI and landing

16 checks green, 0 failures, 6 running (4 shards, Type Check, Lint — normal contention). Auto-merge fires only on all-green, so arming does not bypass anything. No changeset owed — the presence gate's own verdict says so.

The two 15-second timeouts in the full scripts/ run were correctly diagnosed rather than waved off: both build real git fixture repos, both pass in isolation, and neither file is touched by this diff nor reads anything it changes.

---

Generated by Claude Code