Repository navigation
os build / os compile cannot surface the ambiguous-stem refusal — it never constructs a FilesystemLoader, so #14921's third execution clause has no door to land on #16089
Description
Filed by the PM dispatch loop as option B of open question 1 on #14921, which this seat ruled A (accept the PR as shipped) with B split out here. ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.
Why this card exists
#14921's maintainer ruling (director seat, decision batch #43) specified three execution clauses. Two are implemented in PR #16086. The third — "os build surfaces it" — turned out to rest on a premise this tree does not satisfy, and the round measured that rather than inventing a way to satisfy it.
The measurement
Taken by the #14921 round and independently re-verified by this seat on origin/main, with two firing controls:
| reading | result |
|---|---|
NodeMetadataManager in packages/cli |
0 files |
CONTROL — the same symbol elsewhere in packages/ |
19 files ⇒ the symbol exists and the grep finds it |
CONTROL 2 — loadConfig in packages/cli |
27 files ⇒ the grep genuinely reaches that path |
Plus, from the round: os build is an alias of os compile; compile.ts reads a stack definition through loadConfig and performs no metadata-directory scan; no os compile flag names a metadata directory.
⇒ os build cannot surface the ambiguous-stem refusal, because it never constructs a FilesystemLoader.
What the refusal DOES reach today
Not nothing — this is a gap in build-time coverage, ⛔ not an unreachable feature:
- the dispatcher door, via
domains/mcp.ts(listObjectSummariesawaitsmeta.listObjects(), which islist('object'), with notryon the MCP request path); - any
MetadataPlugin-hosted server, whereNodeMetadataManagerregisters the loader.
⇒ An author learns about a colliding stem at first read, not at build.
The question this card carries
Should os compile / os build walk the metadata tree so an author sees a stem collision before deploying?
⛔ This is a feature with its own unruled contract questions, which is exactly why it was not folded into #16086:
- Which roots would
os buildwalk? It reads a stack definition today, not a metadata directory. - Does a missing metadata directory become an error? Today there is nothing to miss.
- Does the walk run on every
os compile, or behind a flag?
⭐ Folding this into a ruled engine fix would have smuggled an unruled decision in under a ruled one. ⇒ Filed separately, for triage to grade and route.
Dedupe, with its controls
Enumeration proven COMPLETE: 668 open issues fetched; the repo's own open_issues_count reads 668.
| probe | hits |
|---|---|
build-time metadata |
0 |
metadata-tree preflight |
0 |
os compile metadata directory |
0 |
ambiguous stem |
2 — only #14921 (the card) and #16086 (its PR) |
CONTROL os compile |
3 — fires |
CONTROL listNames |
6 — fires |
Refs
#14921 (the ruled card) · PR #16086 (where clauses 1 and 2 landed) · #14486 · #14341
Generated by Claude Code
Activity
os-zhuang commentedon Sep 6, 2026
分诊 ·
domain:cli/enhancement/priority:p3/needs-user-decision分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡 —— 本卡就是 decision-box，所以下面只有事实与四面框，没有裁决。
读数取自
origin/main@a4816a7，2026-09-06T02:16Z。卡的测量复现，并加了一条卡没有的控制
NodeMetadataManagerinpackages/clipackages/loadConfiginpackages/cliFilesystemLoaderinpackages/cli（我加的）packages/（我加的）我补这一条是因为卡的结论句是「it never constructs a FilesystemLoader」，而它测的是
NodeMetadataManager。两者不是同一个符号；只测后者，结论就是从代理量推来的。现在两个都直接测了，结论站得住。git grep -l … -- packages）。三者都指向「零是真零」，不影响结论，记录以免后人以为有人算错。车道：
domain:clios build是os compile的别名，compile.ts在packages/cli。任何「让 build 走一遍 metadata 树」的改动都落在packages/cli⇒domain:cli。⛔ 不归 engine：被扫的是 metadata 树，但改的代码在 CLI。为什么是
needs-user-decision而不是pm:queue卡自带三个未裁决的契约问题，且它们互相耦合、任何一个的答案都改变实现形状。这正是 decision-box 的定义。⛔ 本 session 是
claude-opus-5，CONTRACT_REVIEW_TIER硬闸要求 fable ⇒ 我不裁决，只装框。已移除
pm:queue：本仓约定needs-user-decision独立成状态（对照 #15854、#15617、#15542 均无pm:*）。四面框（给裁决者）
一、事实（已实测，非推断）
os build/os compile今天不构造FilesystemLoader，不构造NodeMetadataManager，不扫描任何 metadata 目录；其 flag 面上没有任何一项指向 metadata 目录。#14921 裁决的第三条执行句「os buildsurfaces it」因此没有门可落。这不是 PR #16086 做漏了，是前提在本树不成立。二、今天 refusal 到底能被谁看见
不是无人可见：dispatcher 门（
runtime/src/domains/mcp.ts的listObjectSummariesawaitmeta.listObjects()，MCP 请求路径上无try），以及任何MetadataPlugin托管的 server。⇒ 作者在首次读取时会撞到，不是在 build 时。所以这是 build 期覆盖的缺口，⛔ 不是「功能不可达」。三、要裁的三问（卡自列，我不代答）
os build该走哪些根？它今天读的是 stack definition，不是 metadata 目录。os compile都走，还是藏在 flag 后面？四、不裁的代价 vs 裁错的代价
不裁：现状维持，作者在首次读取撞到 stem 冲突而不是 build 时，缺口持续但有门。裁错（比如默认每次 compile 都强扫、且缺目录即报错）：给每一个不用 filesystem metadata 的工程平白加一道会红的闸——按机械边界测试，这是加宽
os compile的拒绝集，属 Feature，人工地板，所以不能由席位默认值糊过去。优先级：p3
有替代门（dispatcher / 托管 server 首读即拒），缺的是提前量不是能力；#14921 本身按 p3 落地，理由是碰撞实例数为零（PR #16086 实测：526 目录 / 7770 文件中 0 处 stem 碰撞，正控制夹具报 1）。零实例的人群里，把发现时机从首读提前到 build，价值同样低。⇒ p3。
Generated by Claude Code
os-zhuang commentedon Sep 7, 2026
Ruling recorded — option C, no build-time metadata walk; #14921's third execution clause is withdrawn (director seat, decision batch #61, 2026-09-07)
Maintainer reply, verbatim: 「同意」 (all five batch #61 recommendations adopted).
Ruling.
os build/os compiledo not gain a metadata-tree walk. The ambiguous-stem refusal is reachable today at first read (the dispatcher door viadomains/mcp.ts, and everyMetadataPlugin-hosted server); the census found zero collisions across 526 directories / 7770 files with a firing control; and the feature would carry three unruled contract questions (which roots, whether a missing directory is an error, always-on or flagged) plus a new failure mode for every project that does not use filesystem metadata. That is expansion for a zero-instance population. The third execution clause of the #14921 ruling ("os buildsurfaces it") rested on a premise this tree does not satisfy and is withdrawn; clauses 1 and 2 stand as landed in PR #16086.If a real project ever reports a stem collision discovered late, this card is the record to reopen; the three contract questions must be answered first.
Labels:
needs-user-decisionremoved; closed (not planned). Ledger on #12708 (batch #61).Generated by Claude Code