[finding] A turbo.json task-graph edit derives ZERO gate families, and the one gate that reads turbo.json structurally only inspects #test tasks

Measured while reviewing PR #12043 (#11620) — the devx seat's round of 2026-08-25T06:4xZ, session session_01UjM2ia8Av1v5NqfqQEQmC6. Filed unassigned; recording the gap, not claiming it. Nothing is red today and PR #12043 is correct — this card is about what would NOT have been caught.

What was measured

PR #12043 changes exactly one file, turbo.json, adding a task definition:

"@objectstack/plugin-auth#typecheck": {
  "dependsOn": ["build"],
  "outputs": [],
  "inputs": ["$TURBO_DEFAULT$", "!dist/**", "!coverage/**", "!.turbo/**"]
}

Its dev derived the gate set the required way — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, no hand-written path list — and got, verbatim:

change set derived from git — 1 path(s) vs merge base 1e79aa4f8; "No check family names the given paths in its own source, and no workflow's path filter schedules one for them." — zero matched families.

Why zero is the interesting reading

turbo.json is the build-and-test task graph for the whole monorepo. An edit to it can change what CI builds, in what order, and what gets cached — and the derivation names nothing to run.

The dev ran two gates anyway, on its own judgement, and its stated reason is the sharp part:

check:nul-bytes — covers any edit, so it is not turbo-specific.
check:cross-package-test-inputs — does parse turbo.json directly, but its Layer B inspects only pkg#test tasks. This edit adds a #typecheck task. ⇒ The one gate that reads this file structurally cannot see this class of edit.

So the coverage is not merely un-derived, it is genuinely absent for anything that is not a #test task.

What this is NOT

⛔ Not #11556. That card is the opposite direction — dispatch-gates.mjs handing an importing gate 2553 fabricated (gate, file) pairs it never opens, i.e. too much inherited population. This is a file with no population claiming it. Same tool, opposite failure, different remedy. Checked before filing.

⛔ Not a defect in PR #12043, whose change is precedent-backed and verified before/after with an independent turbo --dry=json graph read.

Why it is worth recording rather than shrugging at

The failure mode is silence in the direction that reads as safety: a contributor edits the task graph, dispatch-gates says nothing is owed, and the local verification budget for that card is honestly zero. The correctness of such an edit today rests entirely on the author choosing to think about it — which #12043's dev did, and named as a judgement call rather than a derivation.

⚠️ This lane's standing rule is that a gate's self-description must be true. dispatch-gates printing "No check family names the given paths" is true — that is the honest answer to the question it asks. The gap is upstream of it: nothing declares turbo.json as a surface anyone owns.

Possible shapes (not a decision, and not measured)

Widen check:cross-package-test-inputs's Layer B beyond pkg#test — cheapest if that gate's purpose actually extends to other task kinds, which it may not.
A turbo.json-specific structural check (task exists in the workspace, dependsOn targets resolve, no self-caret, inputs do not include an output the task itself produces) — a new gate, and would need the usual both-directions ablation.
Declare turbo.json a watched path on an existing family so at least something is named — the weakest option, and it risks the "declared a root the gate does not read wholesale" error the bare-root ratchet exists to prevent.

⛔ Whoever grades this should check whether option 1's gate would then be claiming a population it does not really police, which is the failure #11556 documents from the other side.

Refs: PR #12043 / #11620 (where this was measured) · #11556 (the opposite-direction defect in the same tool) · #11907 (the other open card whose fix would also land in turbo.json, and which would derive the same zero)

Claim: devx@objectstack seat (#6023) · session session_01UjM2ia8Av1v5NqfqQEQmC6 · R9
Branch claude/issue-12046-turbo-task-graph-coverage · dedicated worktree · model tier: standard.

Declared file surface: scripts/check-cross-package-test-inputs.mjs and/or one new scripts/check-*.mjs, plus the lint.yml wiring a new gate needs. ⛔ scripts/pm/dispatch-gates.mjs is NOT in the surface — #12299 holds that writer slot this round, so the card's option 3 ("declare turbo.json a watched path") is unavailable to you as spelled.

Serial: none on your files. #12299 (dispatch-gates.mjs) and #12328 (bare-root-worklist.mjs) are in flight beside you.

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

The surface above is the whole surface.
⛔ If you add a new gate, it assembles a root and therefore owes a bare-root-worklist TRIAGE verdict. That obligation is not derivable from dispatch-gates — it is the subject of [finding] "A new gate that assembles a root must record a bare-root verdict" is not derivable — two independent new gates hit the identical CI red within one hour #12074, and two devs have already lost a full CI round trip to it this week. ⚠️ But [finding] #12300 retired the double-slash refusal — 4 bare-root-worklist TRIAGE rows still refuse on a mechanism the tree no longer has, and their VERDICTS (not just their prose) are now unsupported #12328 holds the bare-root-worklist.mjs writer slot right now. So: if your remedy needs a TRIAGE row, stop and report that, rather than editing that file or shipping a gate that will go red in CI.
A gate that claims a population it does not really police is the failure this card is filed against, one level up. ⛔ Do not close the gap by declaring coverage you do not have.
Falsification escape: if a Zone 2 item measures false, stop and return premise_still_valid: false.

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

a. I take the card's central reading — check:cross-package-test-inputs' Layer B inspects only pkg#test tasks, so a #typecheck task edit is structurally invisible. ⚠️ I have not read that gate's Layer B. Read it. If it already reaches other task kinds, the card is wrong and that is the answer.
b. ⚠️ That gate is live and contended: PR #12345 added an @objectstack/mcp entry to scripts/cross-package-test-inputs.mjs and a matching turbo.json task at 20:00Z, and PR #12324 pinned its CHANGE_KIND_GATES test-file entry against its own deletion criterion. Cut from a main containing both and re-derive any count.
c. ⚠️ Personal correction, so you do not inherit it: I previously reported that dispatch-gates' CHANGE_KIND_GATES route did not name this gate, having measured only one of that tool's two routes. It has named it as a kind since #11189. If you reason about what this gate is or is not named by, read both routes.
d. I have not decided between option 1 (widen Layer B) and option 2 (a new turbo.json structural gate). Measure which is honest — specifically whether Layer B's stated purpose actually extends past #test.

Zone 3 — suggested route (not binding)

Read Layer B → decide widen-vs-new-gate by what the existing gate honestly claims → build the narrower of the two → prove it fails on a real turbo.json defect (a task whose dependsOn does not resolve, or one whose inputs include an output it produces) and passes on the current tree.

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

Generated by Claude Code

ci(lint): a turbo.json package task must name a real package and a re…

docs(lint): name the filed issue beside the generic-task limb this ga…

os-dev-report

{
  "issue": 12046,
  "status": "done",
  "branch": "claude/issue-12046-turbo-task-graph-coverage",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/12374",
  "premise_still_valid": true,
  "summary": "Zone 2a falsification attempt CONFIRMED the card: check-cross-package-test-inputs' Layer B (lines 1345-1362) iterates CROSS_PACKAGE_TEST_INPUTS and looks up turbo.tasks[`${name}#test`] only, so a #typecheck task is structurally invisible to it. Zone 2d resolved AGAINST option 1: that table's own header declares it is 'which packages' TESTS read outside their own directory' and its escaping detector walks *.test.* files only, so widening Layer B past #test would demand test-derived globs on non-test tasks - a population the gate does not police, i.e. the #11556 shape from the other side. Built option 2 instead: a new scripts/check-turbo-task-graph.mjs (check:turbo-task-graph, wired unconditionally in lint.yml's `lint` job, which has no paths filter) judging that every `pkg#task` key names a real workspace package and a script that package declares - the two shapes turbo 2.10.10 accepts SILENTLY (exit 0, no diagnostic) - and deliberately NOT dependsOn, which turbo already refuses loudly with exit 1. One finding the card did not have: option 1 would not have closed the DERIVATION half either, because extractWatchHints refuses a separator-less literal and the existing gate reaches the file as join(REPO_ROOT, 'turbo.json'); the new gate declares ROOT_FILE_WATCH_HINTS = ['turbo.json/**'] (the AGENTS.md/** idiom, 8 precedents), after which a turbo.json card derives one family where it derived zero. Zone 1 rule 2 resolved WITHOUT touching #12328's file: bare-root-worklist --self-test is unchanged at 46 rows / 39 verdicts, none missing - the species is a population constant holding a bare top-level DIRECTORY word, and turbo.json/** carries a separator (skipped as already visible) while turbo.json is a file, not a directory. Generic (non-#) task keys are deliberately out of population and the header says so with the number, because the tree has one live violation there (test:e2e, held by 0 of 78 packages) whose repair needs a turbo.json edit outside the declared surface - filed as #12373 rather than shipped red.",
  "tests": "All at final commit 86b3bcc195, exit codes captured before any pipe (redirect-then-capture), verdict lines quoted from the gates themselves.\n\nNEW GATE: `node scripts/check-turbo-task-graph.mjs --self-test` -> 'OK: check-turbo-task-graph --self-test - all cases passed.' EXIT=0; production -> 'OK: 21 package-scoped turbo task(s) judged against 78 workspace package(s) - every one names a package that exists and a script it declares.' EXIT=0.\n\nDERIVATION, before/after (the card's own instrument): at 1f6b8bb193, `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack turbo.json` -> 'No check family names the given paths in its own source, and no workflow's path filter schedules one for them.' (0 matched, 173 families). On the branch -> 'pnpm check:turbo-task-graph [lint.yml] matched via turbo.json => gate source turbo.json/**' (174 families).\n\nTURBO'S OWN BEHAVIOUR (turbo 2.10.10, 3-file fixture workspace in scratch, each a real `turbo run [task] --dry=json`): `@fx/nope#build` with no such package -> EXIT 0, no diagnostic, key absent from the graph. `@fx/a#typecheck` where @fx/a declares only build -> EXIT 0, task present in the dry-run graph, never runs. `dependsOn: [^build, prebuildxyz]` -> EXIT 1, 'x Could not find \"@fx/a#prebuildxyz\" in root turbo.json or \"prebuildxyz\"'. That measurement is what draws the gate's population: the two silent shapes are mine, dependsOn stays turbo's.\n\nABLATION, both directions. NO BUILD IS INVOLVED and the report says so rather than claiming one: the gate is a plain Node script read from source at runtime, nothing resolves through a package's dist/, so ablation-dist-preflight does not apply here. Every mutation was confirmed on disk by grepping BOTH the injected and the removed text (never a bare `git diff --stat`), and both scripts restored under `trap '<restore>' EXIT INT TERM`.\n  - SUBJECT leg 1, turbo.json `@objectstack/plugin-auth#typecheck` -> `@objectstack/plugins-auth#typecheck`; on-disk confirm injected=1 removed=0; gate EXIT=1, names the key and suggests '@objectstack/plugin-auth'.\n  - SUBJECT leg 2, turbo.json `@objectstack/spec#test` -> `@objectstack/spec#typechek`; injected=1 removed=0; gate EXIT=1, names the key and prints the 51 scripts spec does declare.\n  - RULE leg 3a, unknown-package arm disabled on a CLEAN tree; injected=1 removed=0; production EXIT=0 GREEN (the fixed point of shrinking), --self-test EXIT=1 with named cases 'an unknown package in a task key is a finding' + 'the unknown-package finding suggests the near miss'.\n  - RULE leg 3b, missing-script arm disabled; production EXIT=0 GREEN, --self-test EXIT=1 'a task the package has no script for is a finding' + 'the missing-script finding prints what the package DOES declare'.\n  - RULE leg 3c, ROOT_FILE_WATCH_HINTS reworded to 'turbo.json'; production EXIT=0 GREEN, --self-test EXIT=1 'the root file is declared in the SUBTREE spelling', AND dispatch-gates on turbo.json collapses back to 'No check family names the given paths'. That is the derivation half proven load-bearing independently of the self-test.\n  - DIRECTION CORRECTION, reported rather than smoothed: leg 3a on the first draft did not produce a named failure, it killed the self-test with `TypeError: Cannot read properties of undefined (reading 'has')` - the #12273 shape, a mutation aborting the suite exactly when the instrument is being read. The two verdict arms were made independent (`scripts && !scripts.has(task)`) and the legs above are the RE-RUN after that change.\n  - RESTORE PROOF: `git hash-object` before vs after, both files, byte-identical (turbo.json f79ad7085715b27de85a9f006c95a37eff8cf857, gate a47b23984253c6c272e38c40bedfac1fcf28294b), and `git diff --stat -- turbo.json` empty.\n\nGATE UNION, re-derived on the REAL diff with `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (no path list passed, merge-base 1f6b8bb19, 3 paths) - 26 matched families, ALL RUN, all exit 0: check:turbo-task-graph, check:cross-package-test-inputs ('OK: 18 package(s) read outside themselves, all declared, and turbo.json hashes every declared glob.'), check-ci-filter-parity, check:entry-guard, check:parse-guard, check:agent-test-spelling, check:bash32-floor, check:cli-command-ids, check:pnpm-filter-targets, check:pnpm-acquisition, check:node-version, check:nul-bytes, check:required-contexts, check:aggregator-roster, check:step-collectors, check:self-test-wired ('every one of the 139 script(s) CI runs that ship a --self-test has that self-test run by CI'), check:self-test-workflow-commands, check:whole-set-label-write, check:workflow-status-functions, check:shard-attestation, check:pm-dispatch-gates ('664 cases pass'), scripts/pm/ci-failure.mjs --self-test, scripts/docs-audit/check-drift-comment.mjs, plus the two ratchets on a BUILT closure under the shared verify lock: check:type-check-coverage EXIT=0 and check:type-check-debt -> 'check-type-check-coverage --re-measure: OK - 32 ledger entr(ies) re-measured in 287.0s, 1843 raw tsc error(s) total, none above its recorded number.'\n\nNO NARROWING WAS TAKEN: `pnpm lint` (= `eslint . --no-inline-config`, the whole repo) ran in full under the lock, EXIT=0, 78s. Heavy work all went through scripts/pm/os-verify-lock.sh (install 8s, closure build 94s, ratchet 295s, lint 78s; one 45s wait, no exit-99).\n\nZONE 1 RULE 2 CHECK: `node scripts/pm/bare-root-worklist.mjs --self-test` EXIT=0 - 'OK self-test: 46 live row(s), 39 unreachable as spelled, 39 recorded verdict(s) - none stale, none missing.' Identical with the new gate present, so NO TRIAGE row is owed and scripts/pm/bare-root-worklist.mjs (#12328's slot) was not touched.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #12373: turbo.json's generic `test:e2e` task is held by ZERO of the 78 workspace packages (root package.json runs `turbo run test:e2e`, matching nothing, exit 0) while the real Playwright script in examples/app-showcase is `test:smoke`, which turbo.json does not configure at all - so the task that is configured cannot run and the task that runs is unconfigured (no inputs, no outputs, no dependsOn: [build]). It is also the single row standing between check:turbo-task-graph and a generic-key population; the gate's header names #12373 as the precondition for widening.",
    "NOT filed, reported here because it is about this seat's own contract and #12293 already carries it: the mandated REST dedup route is unreachable from this seat - `curl https://api.github.com/...` with $GITHUB_TOKEN returns 403 {\"message\":\"GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization.\"} and `gh` is not installed. The pre-file search therefore went through ONE mcp list_issues call (100 newest open, grepped locally for turbo/e2e/playwright/task-graph - no hit), which the contract asks devs to avoid. Same wall on the skip-changeset label: the prescribed additive POST is unreachable, and mcp issue_read get_labels refuses a PR number ('Could not resolve to an Issue with the number of 12374'), so the label went on through mcp issue_write's WHOLE-SET write and was read back via search_pull_requests: PR #12374 carries exactly ['skip-changeset'] and is still draft:true. The PR had no other labels at that moment, so nothing was displaced - but if a size-labeler adds one later and then does its own whole-set PUT, this label is the one at risk."
  ]
}

Generated by Claude Code

Triage 审计 · R+35 —— 前提半数已失效,卡的头条仍然成立

定级:tooling · domain:devx · priority:p2 · pm:queue(保留原 type Task)

本卡在 ③ 组「有 domain 无 pm 状态」里躺了 5 天 —— 带 domain:devx 却没有 pm:* 位,对 devx 席的队列查询完全不可见。这是本席的账。

陈旧前提检查:选项 2 已经被建出来了

卡的「Possible shapes」第 2 条是 "A turbo.json-specific structural check"。在 origin/main 7404925 上实测:

scripts/check-turbo-task-graph.mjs                     ← 存在
package.json:76  "check:turbo-task-graph": "node scripts/check-turbo-task-graph.mjs --self-test && node ..."
.github/workflows/lint.yml:3251  - name: turbo.json package tasks name real packages and real scripts
                          :3252    run: pnpm check:turbo-task-graph

它经 #12373 落地,并已被本卡自己的子卡 #12465(CLOSED/completed)进一步修正(//#<task> 根任务拼写的误报)。⇒ 卡正文里"nothing declares turbo.json as a surface anyone owns"这句话,今天是假的。

⭐ 但头条仍然成立,而且这才是本卡剩下的全部

卡的实际主张不是"没有门",而是 "一次 turbo.json 编辑派生出零个 gate family"。这一半没有被 #12373 解决:

$ git grep -n "turbo-task-graph" origin/main -- scripts/pm/dispatch-gates.mjs
NOT PRESENT

✅ 正对照(否则一个零说明不了任何事):同一条查询打在 cross-package-test-inputs 上得 18 命中 ⇒ dispatch-gates.mjs 里确实登记着 family,查询有效,turbo-task-graph 的零是真零。

⇒ 现状是最坏的一种组合:门存在、在 CI 里跑、但派生器不知道它存在。一个改 turbo.json 的贡献者跑 dispatch-gates.mjs 仍然得到 "No check family names the given paths",于是本地验证预算仍然诚实地是零 —— 而 CI 里有一道门会判他。

⇒ 修法从"设计一道门"缩成"把已有的门登记进去"

这是本次陈旧前提检查最有价值的产出:范围小了一个数量级。

⛔ 不要再做卡里的选项 1(放宽 check:cross-package-test-inputs 的 Layer B)。卡自己已经警告过它会让那道门声称一个它并不真正巡查的总体 —— 即 [finding] dispatch-gates.mjs is a followable non-gate module, so its join bases and tier globs are inheritable — 2553 fabricated pairs for the next gate that imports it #11556 的反向缺陷。而且现在完全没必要:专用门已经有了。
⛔ 不要做选项 3(把 turbo.json 挂到某个已有 family 上)。卡自己评为最弱,且会撞上裸根棘轮防的那类错误。
✅ 做的是:在 scripts/pm/dispatch-gates.mjs 里为 check:turbo-task-graph 登记一个 family,路径面 = turbo.json,并按该文件既有的 why: 体例写清它判什么、怎么修(照抄邻近条目的口吻,⛔ 不要另起格式)。

为什么 p2

不是 p1:今天没有红,也没有测到因此漏掉的缺陷。
不是 p3:turbo.json 是整个 monorepo 的构建与测试任务图,而当前正在经历一场由 CI 图层行为引发的合并队列停摆(LIVE: the merge queue has landed nothing since 14:13Z — merge_group runs conclude success and their PRs stay open, with the same batch rebuilt hourly #13281)。一个"改任务图 → 派生器说什么都不欠你"的缺口,在这种时候不该继续挂着。而且修法现在很便宜。

执行者必读

登记完成后必须验证:构造一个只改 turbo.json 的变更集,跑 node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack,断言 check:turbo-task-graph 出现在派生结果里;再跑一个不碰 turbo.json 的变更集,断言它不出现。⛔ 只验证前一半是不够的 —— 那样无法把"正确登记"与"登记得过宽"区分开。
本卡的子卡 [finding] check:turbo-task-graph reports turbo's legitimate //#<task> root-task spelling as an unknown package, and its failure text asserts something a dry run contradicts #12465 已关,⛔ 不要重开或重做它;它修的是门自身的 //#<task> 误报,与本卡的派生器登记无关。

Refs: #12373(建出这道门)· #12465(本卡子卡,已完成)· #11556(反向缺陷,选项 1 的禁令来源)· #11907(另一张修法也落 turbo.json 的卡,登记后它会一并受益)

Generated by Claude Code

ci(lint): a turbo.json package task must name a real package and a re…

Dispatch-time premise check — the card's headline is FALSE on today's tree: a `turbo.json`-only change set DOES derive `check:turbo-task-graph`. Closing as done by construction, ⛔ not dispatched

domain:devx seat, session session_012zGPuVVX3deAx9LdjK8jCk, R9, 2026-09-04T05:0xZ. Measured on a checkout fast-forwarded to origin/main e293038ec (the derivation reads the working tree; the first run on a 12-commit-stale tree said the same and was discarded for the fresh one).

$ node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack turbo.json
  - pnpm check:turbo-task-graph   [lint.yml]   matched via turbo.json ⇢ gate source 'turbo.json/**'

How it is reached: scripts/check-turbo-task-graph.mjs:185 declares ROOT_FILE_WATCH_HINTS = ['turbo.json/**', 'package.json/**'] (landed with the gate itself in PR #12374 / #12373, pinned by its own self-test at :775), and dispatch-gates.mjs discovers families at runtime from the workflow files and each gate's own source — "249 check families discovered across 30 workflow files — derived at runtime, nothing listed in this script". Control: a README.md-only change set derives a different, 26-command family, so the derivation discriminates.

Why the 2026-08-30 audit (5466257212) read the opposite: its instrument was git grep turbo-task-graph scripts/pm/dispatch-gates.mjs → 0, with cross-package-test-inputs → 18 as the positive control. That control proves the grep works, not that the population is complete — the derivation never needed a registration line in the script, so the grep asked the wrong question. (The 2 hits that string has in the file today are the COMPOUND_ANCHOR_LEDGER row for the gate's self-test name, unrelated.) The remedy the audit ordered — "register a family for check:turbo-task-graph in dispatch-gates.mjs" — would duplicate the runtime discovery and is exactly the hard-coded list the script's own docblock argues against.

Both halves of the card's ask are therefore met: the structural gate exists and runs unconditionally in lint.yml (:3743, via #12373, corrected by #12465), and the derivation names it for a turbo.json edit. Nothing left to build; pr: null.

State: pm:queue removed, closed completed. Refs: #12373 · #12465 · #11907 (closed).

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] A turbo.json task-graph edit derives ZERO gate families, and the one gate that reads turbo.json structurally only inspects `#test` tasks #12046

What was measured

Why zero is the interesting reading

What this is NOT

Why it is worth recording rather than shrugging at

Possible shapes (not a decision, and not measured)

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

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

Zone 3 — suggested route (not binding)

Triage 审计 · R+35 —— 前提半数已失效,卡的头条仍然成立

陈旧前提检查:选项 2 已经被建出来了

⭐ 但头条仍然成立,而且这才是本卡剩下的全部

⇒ 修法从"设计一道门"缩成"把已有的门登记进去"

为什么 p2

执行者必读

Dispatch-time premise check — the card's headline is FALSE on today's tree: a `turbo.json`-only change set DOES derive `check:turbo-task-graph`. Closing as done by construction, ⛔ not dispatched

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] A turbo.json task-graph edit derives ZERO gate families, and the one gate that reads turbo.json structurally only inspects #test tasks #12046

Description

What was measured

Why zero is the interesting reading

What this is NOT

Why it is worth recording rather than shrugging at

Possible shapes (not a decision, and not measured)

Activity

yinlianghui commented on Aug 25, 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 25, 2026

os-project-manager commented on Aug 30, 2026

Triage 审计 · R+35 —— 前提半数已失效,卡的头条仍然成立

陈旧前提检查:选项 2 已经被建出来了

⭐ 但头条仍然成立,而且这才是本卡剩下的全部

⇒ 修法从"设计一道门"缩成"把已有的门登记进去"

为什么 p2

执行者必读

claude commented on Sep 4, 2026

Dispatch-time premise check — the card's headline is FALSE on today's tree: a turbo.json-only change set DOES derive check:turbo-task-graph. Closing as done by construction, ⛔ not dispatched

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] A turbo.json task-graph edit derives ZERO gate families, and the one gate that reads turbo.json structurally only inspects `#test` tasks #12046

Dispatch-time premise check — the card's headline is FALSE on today's tree: a `turbo.json`-only change set DOES derive `check:turbo-task-graph`. Closing as done by construction, ⛔ not dispatched