You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] check-type-source-resolution's (via …) provenance annotation is FALSE for an include entry naming a bare directory — and that annotation is the doc-block's OWN test for which remedy limb an author is on #18373
Filed by the domain:spec execution seat (#6017), session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T05:2xZ, from an os-dev round's out_of_scope_findings. ⛔ Not claimed, ⛔ not dispatched. Grading is triage's. ⛔ This seat did not run a dedupe search (per 「立卡者不查重,只附查重词」).
Measured by the #17396 round (report 5692289800) while it was blocked by this exact gate on PR #18198, with a two-leg control, one variable, restored between legs.
The defect
scripts/check-type-source-resolution.mjs — programFiles() at :1224 maps every include entry through globToRegExp (:1164, applied at :1254). An entry naming a bare directory is therefore matched literally instead of as TS's dir/**/*, and that program's file set reads as empty.
⇒ tsc compiles src/engine.ts under both spellings — measured, 18 × TS6059 under tsc -p tsconfig.json with the shipped bare-src spelling — so the annotation is wrong, not the compiler.
Why it is class (a) rather than cosmetic
The (via …) annotation is the doc-block's own test for telling the re-baseline limb from the plain refusal — 「if you cannot point at the program, you do not have this case」. A false annotation therefore steers an author onto the limb the doc-block forbids, in a gate whose other two routes are both marked maintainer-only. That is the shape where being wrong costs a ratchet.
Second symptom, same subject
The doc-block says the annotation appears 「in --list and in the failure text」. --list emits zero of them. Controlled: 0 occurrences of (via in --list output against 3 in the failure output — same token, same script, same run.
Carrier
The maintainer who rules on PR #18198's check:type-source-resolution red opens this exact file. ⇒ worth grading before that sitting, not after.
Dedupe words
check-type-source-resolution · programFiles · include bare directory · via provenance annotation · TS6059
os-decision-facets
⚠️Added by the domain:spec execution seat, NOT by this card’s filing seat. H62 measured this body as carrying no marker in either spelling, and the remedy it names is the FILING seat’s — but that seat (os-warren) is out of budget, so the duty cannot be discharged where it belongs and the card would sit unrulable. This seat dispatched the card, read the round’s report and routed it here, so it supplies the block from its own measurements. ⛔ Purely additive — nothing already on this face was removed, reworded or re-ordered. ⛔ This seat states the facets and does NOT grade them.
① 项目长远合理性 — the (via …) provenance annotation is the doc-block’s OWN test for which remedy limb an author is on, and it is FALSE for an include entry naming a bare directory. So the instrument that tells an author what to do is wrong about the case it is describing. The fix is proven and ablation-proven on PR fix(scripts): a bare-directory include is tsc's implicit glob, and --list annotates provenance too #18708; the cost is entirely downstream of the fix WORKING.
② 实际业务拉动 — measured: the repaired gate sees files it previously could not, and the required Lint & Repo Gates job goes 0 → 14 failure rows (first at packages/services/service-settings, whose tsc program imports 5 workspace packages whose declarations resolve to dist/ with no paths rule at source). ⚠️ Those 14 rows are pre-existing conditions the old reading could not see — not regressions the fix introduced.
③ 防 AI 犯错 — decisive and self-referential: the gate’s message hands the author a remedy, and the annotation deciding WHICH remedy applies is the false one. An agent following it lands on the wrong limb with the gate green. ⚠️ The mirror hazard is real too: narrowing the fix so the 14 rows stay invisible would restore exactly the half-blind instrument this card exists to repair. ⛔ Do not buy green that way.
④ 创业阶段不扩散 — the remedy the gate itself prints is paths rules per package or a ledger entry, and its own text says 「that ledger and ⛔ never widen a rootDir to make room — both are maintainer-only」. So the 14 rows cannot be cleared by any seat or dev; only the maintainer can authorise either route. That is why this card is here rather than in a patch round.
⭐ The reading that makes this a NEW shape, and the reason it needs a ruling rather than a re-baseline: the judged program count is UNCHANGED at 135 while the failing file set grows 0 → 14. The registry doc-block’s re-baseline test names the program set, so a file-set widening at constant program count is a fourth shape it has never recorded — an existing re-baseline procedure does not cover it.
Prior rulings read:#15931 (the gate-coverage family this belongs to) · ADR-0049 (enforce-or-remove, the sibling discipline for a declared-but-unenforced surface) · the gate’s own header, which reserves both remedies to the maintainer. ⛔ No prior ruling decides a file-set widening at constant program count; that is what this card asks.
The question, in one line: with the fix proven and a required gate now reporting 14 pre-existing rows it could never see, does the repair land together with paths rules for those packages, land with a ledger entry covering them, land alone and turn the gate red until the rows are cleared, or wait — and is the re-baseline procedure extended to name the FILE set as well as the program set?
Filed by the
domain:specexecution seat (#6017),session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T05:2xZ, from anos-devround'sout_of_scope_findings. ⛔ Not claimed, ⛔ not dispatched. Grading is triage's. ⛔ This seat did not run a dedupe search (per 「立卡者不查重,只附查重词」).Measured by the #17396 round (report
5692289800) while it was blocked by this exact gate on PR #18198, with a two-leg control, one variable, restored between legs.The defect
scripts/check-type-source-resolution.mjs—programFiles()at:1224maps everyincludeentry throughglobToRegExp(:1164, applied at:1254). An entry naming a bare directory is therefore matched literally instead of as TS'sdir/**/*, and that program's file set reads as empty.The repro, two legs, one variable
packages/services/service-automation/tsconfig.jsonships"include": ["src"]:includespelling["src"](shipped)@objectstack/types **(via tsconfig.test.json)**["src/**/*"](only change)(via …)⇒ tsc compiles
src/engine.tsunder both spellings — measured, 18 × TS6059 undertsc -p tsconfig.jsonwith the shipped bare-srcspelling — so the annotation is wrong, not the compiler.Why it is class (a) rather than cosmetic
The
(via …)annotation is the doc-block's own test for telling the re-baseline limb from the plain refusal — 「if you cannot point at the program, you do not have this case」. A false annotation therefore steers an author onto the limb the doc-block forbids, in a gate whose other two routes are both marked maintainer-only. That is the shape where being wrong costs a ratchet.Second symptom, same subject
The doc-block says the annotation appears 「in
--listand in the failure text」.--listemits zero of them. Controlled: 0 occurrences of(viain--listoutput against 3 in the failure output — same token, same script, same run.Carrier
The maintainer who rules on PR #18198's
check:type-source-resolutionred opens this exact file. ⇒ worth grading before that sitting, not after.Dedupe words
check-type-source-resolution·programFiles·includebare directory ·viaprovenance annotation · TS6059os-decision-facets
domain:specexecution seat, NOT by this card’s filing seat. H62 measured this body as carrying no marker in either spelling, and the remedy it names is the FILING seat’s — but that seat (os-warren) is out of budget, so the duty cannot be discharged where it belongs and the card would sit unrulable. This seat dispatched the card, read the round’s report and routed it here, so it supplies the block from its own measurements. ⛔ Purely additive — nothing already on this face was removed, reworded or re-ordered. ⛔ This seat states the facets and does NOT grade them.(via …)provenance annotation is the doc-block’s OWN test for which remedy limb an author is on, and it is FALSE for anincludeentry naming a bare directory. So the instrument that tells an author what to do is wrong about the case it is describing. The fix is proven and ablation-proven on PR fix(scripts): a bare-directoryincludeis tsc's implicit glob, and--listannotates provenance too #18708; the cost is entirely downstream of the fix WORKING.Lint & Repo Gatesjob goes 0 → 14 failure rows (first atpackages/services/service-settings, whose tsc program imports 5 workspace packages whose declarations resolve todist/with nopathsrule at source).pathsrules per package or a ledger entry, and its own text says 「that ledger and ⛔ never widen arootDirto make room — both are maintainer-only」. So the 14 rows cannot be cleared by any seat or dev; only the maintainer can authorise either route. That is why this card is here rather than in a patch round.⭐ The reading that makes this a NEW shape, and the reason it needs a ruling rather than a re-baseline: the judged program count is UNCHANGED at 135 while the failing file set grows 0 → 14. The registry doc-block’s re-baseline test names the program set, so a file-set widening at constant program count is a fourth shape it has never recorded — an existing re-baseline procedure does not cover it.
Prior rulings read: #15931 (the gate-coverage family this belongs to) · ADR-0049 (enforce-or-remove, the sibling discipline for a declared-but-unenforced surface) · the gate’s own header, which reserves both remedies to the maintainer. ⛔ No prior ruling decides a file-set widening at constant program count; that is what this card asks.
The question, in one line: with the fix proven and a required gate now reporting 14 pre-existing rows it could never see, does the repair land together with
pathsrules for those packages, land with a ledger entry covering them, land alone and turn the gate red until the rows are cleared, or wait — and is the re-baseline procedure extended to name the FILE set as well as the program set?Generated by Claude Code