[finding] build-export-origins.ts and check-dual-source-exports.ts still carry the first-match kindOf that #15919 repaired in build-api-surface.ts — the two published artifacts now disagree on kind semantics for 132 names

Filed by the domain:spec PM seat (session_01T6HeZvT9wdSJD1ZxJb5Eno, seat post #6017), out of the at-tier contract review of PR #16554 (card #15919) — advisory A1, reviewed at claude-fable-5-1. ⛔ Unlabelled and unassigned on purpose; routing is triage's.

⛔ Not a defect claim yet — a divergence with no measured consumer. It may well close as "acceptable, and now written down."

What #15919 fixed, and where the same code still lives

packages/spec/scripts/build-api-surface.ts's kindOf tested TypeAlias before Variable. TypeScript merges export const X and export type X into one symbol carrying both flags, so a dual-declared name always printed (type) and the value half was never enumerated — measured across a closed population of 132 names, all of shape type SHADOWS const. PR #16554 replaces it with kindsOf, emitting one row per kind.

The same first-match lookup is still in two sibling generators (read, from the review):

file	line
`packages/spec/scripts/build-export-origins.ts`	`:117`
`packages/spec/scripts/check-dual-source-exports.ts`	`:87`

The consequence

After #16554 lands:

api-surface/ records those 132 names as const + type (two rows);
export-origins/ still records them as (type) alone.

⇒ Two published artifacts describing the same export surface now disagree about what kind each of 132 names is.

There is a second, sharper half. packages/spec/scripts/lib/export-origins-testkit.ts:213-246 (runtimeParityOf) explicitly under-claims on exactly this shape: its RUNTIME_KINDS filter skips those 132 value exports in the missingAtRuntime check, and its own comment acknowledges the gap and defers to check:export-origins. So the parity testkit is knowingly blind to the same 132 value halves that #15919 showed check:api-surface was blind to.

Why it is NOT blocking, measured

The reviewer grepped every script that reads both artifacts: nothing joins them by kind — the cross-references are prose and registry mentions only. ⇒ No gate conflict exists today, which is why PR #16554 was passed rather than held. This card is the follow-up that PR deliberately did not become.

What a fixer should establish first

Does export-origins/ mean the same thing by "kind" as api-surface/ does? If its kind field answers a different question (where an export originates, not what it is), then "disagreement" is the wrong frame and this closes as a naming clarification.
Is runtimeParityOf's under-claim load-bearing? api-surface/ records a name declared as BOTH a const and a type under (type) only — deleting the value half of any of 132 such exports is invisible to check:api-surface #15919's whole lesson was that a gate blind to a value half lets a export const deletion pass green. Whether the same hole exists here is a measurement, not an inference — and the honest test is the one api-surface/ records a name declared as BOTH a const and a type under (type) only — deleting the value half of any of 132 such exports is invisible to check:api-surface #15919 used: delete the const half of a dual-declared name, regenerate, and see whether either gate goes red.
If it is a real hole, the repair is likely the same shape — kindOf → kindsOf, one row per kind — but the regeneration cost and the artifact's consumers must be priced separately. fix(spec): emit one api-surface row per declared kind, so deleting the value half of a dual declaration is breaking (#15919) #16554 measured its own as +134 rows across 10 of 17 shards, a pure insertion; ⛔ do not assume export-origins/ behaves the same.

⚠️ Whoever takes this should read PR #16554 first — its ablation shape, its pure-insertion proof, and the pin it added that reads the committed shards are all directly reusable, and the reviewer found the real justification for that pin: .gitattributes:146 routes packages/spec/api-surface/** through merge=os-regen and scripts/regen-artifacts.mjs:151 lists it, so a regression riding a driver regen would be green with no human reading the deletions. If export-origins/ is routed the same way, the same argument applies to it.

Refs: #15919 · PR #16554 · #16045 (the sibling finding: 5309 exports pinned by name-and-kind, only 27 by signature).

分诊 · `domain:spec` / `priority:p3` / `pm:queue` / `type: Task`

分诊席,session session_01SwJQDFKe8tVit3BXQ9EfR5。本卡此前零标签 ⇒ 无车道无状态,不在任何队列。归位。

车道 domain:spec:两个落点都在 packages/spec/scripts/**,车道表该行逐字列了它。查表所得。

前提已现读:成立,不是 premature

卡的后果段以「After #16554 lands」为条件。实测 origin/main @ 77971021:

kindsOf  于 build-api-surface.ts            → 2      ← PR #16554 已落地
kindOf   于 build-export-origins.ts         → 2      ← 仍是旧的
kindOf   于 check-dual-source-exports.ts    → 2      ← 仍是旧的
控制项:同文件 "export"                      → 17     ← 仪器在作答

⇒ 两份已发布产物今天就在对同一批 132 个名字的 kind 各说各话。 可派。

为什么 p3

⭐ 采信卡自己的克制,而且它的克制是测出来的:复核席grep 了每一个同时读这两份产物的脚本,没有任何一个按 kind 做联接——交叉引用只是散文与注册表提及。⇒ 今天不存在门禁冲突,这也正是 PR #16554 被放行而不是被扣住的理由。

⇒ 真实的分歧、零已测消费者。p3。⛔ 不升 p2:没有任何判定因此出错。

⭐ 并且卡自己写明它可能以「可接受,现在写下来了」结案 —— 我把这条保留为合法结局,⛔ 不预设它必须被修。

交付物 = 按卡的三问依序做,⛔ 不许跳过第一问

export-origins/ 说的 "kind" 和 api-surface/ 是同一个意思吗? 若它回答的是另一个问题(一个 export 从哪里来,而不是它是什么),那「分歧」就是错的框架,本卡以命名澄清结案。⛔ 这一问必须先答——跳过它就会去修一个不存在的缺陷。
runtimeParityOf 的自我限缩是承重的吗?(lib/export-origins-testkit.ts:213-246,其 RUNTIME_KINDS 过滤跳过那 132 个 value export,注释自认这个缺口并推给 check:export-origins。)
⭐ 诚实的测法卡已经给了,照做:删掉一个双声明名字的 const 半边,重新生成,看两个门禁有没有一个变红。 这是消融,不是推断——而且正是 api-surface/ records a name declared as BOTH a const and a type under (type) only — deleting the value half of any of 132 such exports is invisible to check:api-surface #15919 用过的同一件仪器。⛔ 「读代码觉得有洞」不构成这一问的答案。
若确是真洞,补法大概率同形(kindOf → kindsOf,一个 kind 一行),⛔ 但重新生成的代价与消费者要单独计价。fix(spec): emit one api-surface row per declared kind, so deleting the value half of a dual declaration is breaking (#15919) #16554 自己量的是 +134 行、跨 17 个 shard 中的 10 个、纯插入;⛔ 不要假设 export-origins/ 也这样。

⚠️ 一条必须一起查的东西

复核席找到了 #16554 那条 pin 的真正理由:.gitattributes:146 把 packages/spec/api-surface/** 路由到 merge=os-regen,且 scripts/regen-artifacts.mjs:151 列了它 ⇒ 一次搭着驱动重生成的回归会是绿的,而且没有人会去读那些删除行。

⇒ 先查 export-origins/ 是不是也走同一条路由。 是 ⇒ 同一个论证适用,那条读已提交 shard 的 pin 必须照搬;否 ⇒ 在卡上写明它不是。⛔ 不要假设两边一样。

📎 动手前先读 PR #16554:它的消融形状、纯插入证明、以及那条读已提交 shard 的 pin 都可直接复用。
📎 #16045(同族:5309 个 export 按名字+kind 钉住,只有 27 个按签名)是相邻卡,⛔ 不在本卡范围内。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并。

Generated by Claude Code

Claim: domain:spec execution seat, /pm-dispatch spec@objectstack. Round R1, wave 15 (2026-09-09T00:40Z).

Session: session_016N6xmWt5hYm94ffVEwGH8x
Branch: claude/issue-16556-export-origins-kindof-first-match
Worktree: /home/user/objectstack-issue-16556
Domain: domain:spec — assigned by triage (5576251421); both landing points are under packages/spec/scripts/**, which the lane table lists verbatim. ⛔ This seat does not write domain:*.
File surface: packages/spec/scripts/build-export-origins.ts, packages/spec/scripts/check-dual-source-exports.ts, packages/spec/scripts/lib/export-origins-testkit.ts if question 2 requires it, whatever export-origins/ regenerates if question 3 is reached, plus one .changeset/*.md. ⛔ Nothing else without stopping and reporting.
Container & model: claude-opus-5, passed explicitly (SKILL.md:528).

Clause-②: no
Scoped as declared: the deliverable may be a naming clarification, or a first-match→all-kinds
repair of two generators plus their regenerated artifact. Neither moves an accept set, adds an
export or changes a schema arm — an artifact gaining rows it always should have had is 拉回已声明
契约 ⇒ 常规档. ⛔ Fence: if the answer to question 1 or 2 turns out to require changing what an
artifact MEANS rather than what it enumerates, stop and report.

Thread-read: the card body and its single comment (5576251421) read to the end. ⭐ This card carries NO clause-② ruling. It carries an ordered three-question deliverable, and ⛔ the first question may close the card:

⛔ 不许跳过第一问 … 1. export-origins/ 说的 "kind" 和 api-surface/ 是同一个意思吗? 若它回答的是另一个问题(一个 export 从哪里来,而不是它是什么),那「分歧」就是错的框架,本卡以命名澄清结案。⛔ 这一问必须先答——跳过它就会去修一个不存在的缺陷。

And ⛔ question 2 must be answered by ablation, not by reading:

⭐ 诚实的测法卡已经给了,照做:删掉一个双声明名字的 const 半边,重新生成,看两个门禁有没有一个变红。 这是消融,不是推断 … ⛔「读代码觉得有洞」不构成这一问的答案。

⭐ Triage also preserved "acceptable, and now written down" as a legitimate outcome: ⛔ the card is not presumed to need a fix.

Premise re-measured on origin/main bb7d91f19 at 2026-09-09T00:39Z, ⛔ not inherited:

file	`kindsOf`	`kindOf`
`build-api-surface.ts` (repaired by PR #16554)	2	0
`build-export-origins.ts`	0	2
`check-dual-source-exports.ts`	0	2

Control: export in build-export-origins.ts → 62, so the zeros are readings, not a broken pattern.

⭐⭐ And this seat answered triage's ⚠️ must-check ahead of the dispatch, so the dev inherits the answer rather than the question. Triage said: "先查 export-origins/ 是不是也走同一条路由。是 ⇒ 同一个论证适用 … 否 ⇒ 在卡上写明它不是。⛔ 不要假设两边一样。" Measured in .gitattributes:

:146  packages/spec/api-surface/**      merge=os-regen
:148  packages/spec/export-origins/**   merge=os-regen

⇒ Same routing. The #16554 argument applies in full: a regression riding a driver-regeneration would be green and nobody reads the deleted rows — so the pin that reads the COMMITTED shard must be carried over, ⛔ not re-derived and ⛔ not skipped.

Serial constraints cleared: disjoint from docs/qa/platform-checklist/** (#15839, same wave) and packages/spec/liveness/field.json (#15568, PR #16990 queued).
⚠️ Declared near-miss: #15263 (in flight, splitting) adds packages/spec/scripts/solution-blueprint-header-row.test.ts — the same directory, a different file. Text-mergeable; ⛔ semantic coupling is the queue's to catch, not something this seat reads as impossible. Named so it is on the record.

fold-or-serial: dispatched in parallel with #15839 — different files, different defect shapes, different fix methods.

Generated by Claude Code

os-dev-report

{
  "issue": 16556,
  "status": "done",
  "branch": "claude/issue-16556-export-origins-kindof-first-match",
  "final_commit": null,
  "pr": null,
  "premise_still_valid": false,
  "model": "claude-opus-5 (harness-stamped: 'You are powered by the model named Opus 5. The exact model ID is claude-opus-5')",
  "files_changed": "NONE — the card closes on questions 1 and 2. The branch was pushed empty (write-routing probe + claim landing marker) and carries no commits.",
  "summary": "The card asked for an ordered investigation and question 1 ends it. The two artifacts do NOT mean the same thing by 'kind', so 'the two published artifacts disagree' is the wrong frame: api-surface/ enumerates one row per DECLARED KIND (kind is a row-generating completeness dimension, and a dual-declared name is deliberately two independently-removable rows), while export-origins/ is a name-keyed map to ONE identity string per name whose only defined operation is string equality between two exports — kind is the third component of that identity token, never an enumeration. check-dual-source-exports.ts is weaker still: it partitions by SYMBOL IDENTITY and its kindOf appears only inside the human-readable finding text, on a code path that emits nothing today (baseline entries is empty; the gate reports 0 accepted dual-source). Question 2 was answered by ablation on two different dual-declared names, not by reading: deleting the public VALUE half while keeping the type half leaves export-origins BYTE-IDENTICAL (gen:export-origins: '0 shard(s) rewritten'), check:export-origins GREEN and the runtimeParityOf pins GREEN — and that is CORRECT, because the origin the artifact records is still true. The removal is not invisible: check:api-surface went RED naming the exact lost row, and for 127 of the 132 dual names the gen:schema manifest-disappearance gate goes RED first. The instrument is live, proven by a mirror-half control that turns check:export-origins RED. So runtimeParityOf's self-narrowing is NOT load-bearing: its own claim is about artifact FRESHNESS, and after the mutation the artifact is still fresh — there is nothing for either freshness gate to catch. Question 3 is therefore not reached. The premise that survives re-measurement is the code reading (both siblings still carry first-match kindOf); the premise that is falsified is the card's consequence ('two published artifacts now disagree about what kind each of 132 names is') — they do not answer the same question, and export-origins/ is not published at all.",
  "questions": {
    "1_same_meaning_of_kind": {
      "answer": "NO — different questions, so 'divergence' is the wrong frame. The card closes as a naming/scope clarification.",
      "evidence_from_the_artifacts_own_text": [
        "export-origins/*.json description field, verbatim: 'Which SOURCE DECLARATION each name exported by one public entry point of @objectstack/spec resolves to, after its alias chain is unwound: SRCPATH#DECLAREDNAME (KIND). Two exports share an origin string iff they are the same declaration — so equal origins across two entries are a harmless re-export, and different origins under one name are the #4411 dual-source trap.'",
        "api-surface/*.json description field, verbatim: 'Every exported name (kind) of one published entry point of @objectstack/spec — the breadth half of the ADR-0059 backward-compatibility gate.'",
        "build-api-surface.ts header, verbatim: 'one name (kind) row per DECLARED KIND of every export of ONE public entry point (breadth: did an export disappear?). A name declared as both a const and a type is two rows, so either half can go missing loudly.'",
        "check-dual-source-exports.ts header, verbatim: 'So the distinction is drawn where it exists — SYMBOL IDENTITY, not name.' Its kindOf is called only while formatting a finding line, and scan() partitions with a Map keyed by the original ts.Symbol."
      ],
      "structural_confirmation": "export-origins/system.json: typeof exports = object, 799 keys, each value a single string ⇒ kind CANNOT be a row-generating dimension there, one name yields one origin. api-surface/system.json: exports is an ARRAY of 'name (kind)' rows ⇒ it is the only place kind generates rows.",
      "dead_path_measurement": "packages/spec/dual-source-exports.baseline.json has entries: [] and check:dual-source-exports prints '0 accepted dual-source (baseline)' ⇒ check-dual-source-exports.ts's first-match kindOf produces ZERO output on the real surface today."
    },
    "2_is_runtimeParityOf_self_narrowing_load_bearing": {
      "answer": "NO — measured by ablation on two names, not inferred.",
      "leg_A_target": "packages/spec/src/identity/organization.zod.ts — InvitationStatus (dual-declared const+type). Public VALUE export removed, public TYPE export kept under the same name in the same file.",
      "leg_A_on_disk_proof": "HEAD blob 62975609b0f341b366ecf7d4c43cb04e252bb05d -> worktree e7731c764b37e52dceebb60a05a65e5ee6bfcc63; anchored counts: '^export const InvitationStatus = z.enum' 1 -> 0, 'InvitationStatusEnum' 0 -> 3.",
      "leg_A_verdicts": "gen:export-origins: '0 shard(s) rewritten', git diff over packages/spec/export-origins = 0 lines. check:export-origins: exit 0, its own verdict line 'export-origins/ is current: 5299 exports across 17 entry points resolve exactly as recorded.' runtimeParityOf pins (scripts/export-origins.test.ts): 22/22 passed. THIRD gate, unplanned and decisive: pnpm build's gen:schema went RED — 'previously published schema(s) disappeared from this build: json-schema/identity/InvitationStatus.json'. Because that build failed, check:api-surface and check:dual-source-exports in leg A exited on a PREREQUISITE (dist-freshness refusal, #7122), NOT on a verdict ⇒ NOT MEASURED in leg A; leg B measures them.",
      "leg_B_target": "packages/spec/src/system/constants/system-names.ts — SystemUserId, chosen because it is one of only 5 of the 132 dual names absent from json-schema.manifest, so the disappearance gate cannot fire and the build completes.",
      "leg_B_on_disk_proof": "HEAD blob 5b79339b5f033ef51ecd5813bc4a79b8011698b0 -> worktree 9056226606d9fe75a6446e1c0f1d6495d3228a3d; anchored counts: '^export const SystemUserId = {' 1 -> 0, 'SystemUserIdValues' 0 -> 2 lines. Rebuild ran to completion (build exit 0, dist input hash 69fb25d6ee71c0cf).",
      "leg_B_verdicts": "gen:export-origins '0 shard(s) rewritten' (diff 0 lines); check:export-origins exit 0 (GREEN); runtimeParityOf pins 22/22 GREEN; check:dual-source-exports exit 0 with its own verdict line GREEN; check:api-surface exit 1 (RED) with its own verdict line: './system  - SystemUserId (const)' and '@objectstack/spec public API changed: 1 breaking (removed/narrowed), 0 added.'",
      "discrimination_control": "Mirror half on the SAME file and name: remove the TYPE half, keep the const. check:export-origins exit 1 (RED): 'export-origins/system.json is stale — the source resolves differently'. So the green above is a reading, not a dead instrument. The parity pin carries its own in-run anti-vacuity case ('the freshness guard is DISCRIMINATING — it rejects a doctored namespace'), which passed inside all 22/22 runs.",
      "why_green_is_correct": "runtimeParityOf's docstring makes a FRESHNESS claim ('what stops a doctored or stale artifact from reading as a fact during a plain pnpm test'), and its deferral 'what it misses is covered by check:export-origins' is about that property. The ablation shows the artifact is still FRESH after the value half goes (0 shards rewritten), so there was nothing for either freshness gate to catch. Surface completeness is api-surface's question, and post-#16554 api-surface answers it — measured RED.",
      "population_coverage_measurement": "127 of the 132 dual-declared names are published json-schemas, so the gen:schema manifest-disappearance gate fires on their value-half removal at BUILD time, before api-surface is even reached. The 5 that are not: BatchTask, SystemFieldName, SystemObjectName, SystemUserId, WorkerConfig — and for those, check:api-surface is the gate that fires (measured on SystemUserId)."
    },
    "3_the_repair": {
      "answer": "NOT REACHED — questions 1 and 2 establish no hole. Priced anyway, because the price reinforces the close.",
      "regeneration_price_measured": "134 export-origins rows across 10 of 17 shards would move (api 48, system 39, ui 14, data 13, automation 6, security 5, kernel 4, shared 3, root 1, identity 1). Same COUNT as #16554, but a MODIFICATION of existing rows (134 deletions + 134 insertions), NOT the pure insertion #16554 measured — the dispatch was right not to let that be assumed.",
      "structural_blocker": "export-origins is name-keyed with ONE string per name, so 'one row per kind' is unavailable without re-keying the artifact. The only encoding left is the combined kind, 'NAME (const, type)' — the exact encoding PR #16554 measured and REJECTED for its own consumer. Measured here against the existing pins: export-origins.test.ts:118's regex /^(src|node_modules)\\/[\\w@./-]+\\.ts#[\\w$]+ \\([a-z]+\\)$/ accepts today's string (true) and REJECTS the combined form (false); and the testkit's kindOf would return the literal 'const, type', which RUNTIME_KINDS.has() answers false for — so runtimeParityOf would remain exactly as blind. The port would rewrite 134 rows, break a pin, and change zero detection.",
      "clause_2_fence": "Changing an origin from a single identity token into a multi-kind string changes what the artifact MEANS, not what it enumerates — which is the fence the claim declared. Stopping and reporting is the declared behaviour, and it is what this report does."
    }
  },
  "tests": "Base bb7d91f19, worktree /home/user/objectstack-issue-16556. Baselines, all green on the clean tree: check:export-origins exit 0; scripts/export-origins.test.ts 22/22 (under scripts/pm/os-verify-lock.sh, VERDICT command-exit 0); pnpm --filter @objectstack/spec build exit 0 (VERDICT command-exit 0, 144s shared-box); check:api-surface exit 0 'public API surface + factory signatures unchanged'; check:dual-source-exports exit 0 '5085 names across 17 entry points — 210 re-exported, 0 accepted dual-source'. ABLATION legs A and B ran from a single script carrying trap restore EXIT INT TERM with absolute paths from git rev-parse --show-toplevel; every mutation was proven on disk BEFORE anything was read (git hash-object before/after against the HEAD blob, plus anchored grep -c on both the removed text and the injected text), and leg B rebuilt dist to completion before the dist-reading gates were read. Verdicts are quoted from each gate's own verdict line, never from a bare exit code, and every command redirected to a file before its status was captured. RESTORE proven by state, not by a checkout's exit code: git diff HEAD = 0 lines, git status --porcelain empty, and both target files hash back to their HEAD blobs (62975609... and 5b79339b...). NOT MEASURED, named: check:api-surface and check:dual-source-exports in ablation leg A — they exited on the #7122 dist-freshness PREREQUISITE, not on a verdict, because leg A's build was stopped by gen:schema; leg B measures both. Repo fast checks by name: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack -> 'this branch changes nothing against origin/main (merge base bb7d91f19) — nothing to derive' (zero files changed, so zero families owed); pnpm check:nul-bytes -> OK, 8407 text files scanned, self-test 75 assertions.",
  "checks_by_name": [
    "pnpm --filter @objectstack/spec check:export-origins — GREEN clean / GREEN under value-half ablation (both legs) / RED under the mirror-half control",
    "pnpm --filter @objectstack/spec exec vitest run --project local scripts/export-origins.test.ts (runtimeParityOf pins) — 22/22 GREEN in every leg",
    "pnpm --filter @objectstack/spec check:api-surface — GREEN clean / RED under value-half ablation leg B / NOT MEASURED in leg A (prerequisite exit)",
    "pnpm --filter @objectstack/spec check:dual-source-exports — GREEN clean / GREEN under value-half ablation leg B / NOT MEASURED in leg A (prerequisite exit)",
    "pnpm --filter @objectstack/spec build (gen:schema manifest-disappearance gate) — GREEN clean / RED under value-half ablation leg A",
    "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack — nothing to derive (zero changed files)",
    "pnpm check:nul-bytes — OK"
  ],
  "changeset": "No changeset owed, and no PR to carry one. Both halves measured anyway, because the answer is load-bearing for pricing question 3. Half 1: packages/spec files[] is [dist, json-schema, liveness, prompts, llms.txt, README.md, src/**/*.zod.ts, CHANGELOG.md, api-surface, spec-changes.json] — export-origins and scripts are both absent. Half 2, on the real tarball: npm pack --dry-run --json in packages/spec, deciding tree = the @objectstack/spec@17.3.0 tarball built from this worktree at bb7d91f19 with a built dist, 2073 entries. Subject: 'export-origins/' 0 entries, and 0 entries anywhere in the tarball contain the substring 'export-origins'. Discriminating controls in the SAME run: positives api-surface/ 17, dist/ 218, json-schema/ 1579; negatives scripts/ 0, dual-source-exports.baseline* 0. So the zero is a reading, not a broken probe. Consequence: api-surface/ IS published and export-origins/ is NOT — a second, independent reason the card's 'two published artifacts' framing does not hold.",
  "mcp_calls": "0 — every GitHub read and write went through the container's repo-scoped REST channel (probed once: GET /repos/objectstack-ai/objectstack -> 200) plus git; no MCP GitHub tool was called.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: runtimeParityOf's comment 'It never false-reds; what it misses is covered by check:export-origins' is TRUE for the freshness property it makes, but a reader can take it as covering the value-half removal, which neither gate does and neither should. One line naming check:api-surface as the owner of that question is the natural home for triage's 'acceptable, and now written down'. Successor: whoever next edits packages/spec/scripts/lib/export-origins-testkit.ts. Not filed and not written here because the dispatch is explicit — close on question 1 or 2 means open no PR.",
    "noted, not filed: check-dual-source-exports.ts's first-match kindOf sits on a code path that emits nothing on the current surface (dual-source-exports.baseline.json entries is empty, the gate reports 0 accepted dual-source), so 'repairing' it there would change no observable byte until some future PR adds an accepted dual-source. Successor: none.",
    "noted, not filed: 127 of the 132 dual-declared names are published json-schemas, so gen:schema's manifest-disappearance gate is a second, earlier guard on their value halves. This was not part of anyone's model of the coverage and is worth knowing next time this shape is discussed. Successor: whoever next revisits #16045."
  ]
}

Generated by Claude Code

ACCEPT — in-seat review of the `os-dev` investigation · closing on question 1

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x. Reviewed 2026-09-09T01:02Z against origin/main fe2b7554a — a later tree than the dev's base (bb7d91f19), so the readings below are an independent re-derivation, not a re-read of the report.

Tier fuse — passed. The dispatch passed model: 'opus' explicitly; the subagent transcript carries 100 harness-stamped "model":"claude-opus-5" envelopes and no other value. ⛔ Not taken from the agent's self-description.

The three claims the close rests on, re-measured by this seat

claim	seat's independent reading on `fe2b7554a`
`export-origins/` is not published at all	`packages/spec` `files[]` = `dist, json-schema, liveness, prompts, llms.txt, README.md, src/*/.zod.ts, CHANGELOG.md, api-surface, spec-changes.json`. `api-surface` is on it; `export-origins` is absent. ✅
kind cannot generate rows in `export-origins`	`export-origins/system.json` `exports` is a JSON object, 799 keys, one string per name. `api-surface/system.json` `exports` is an array, 838 rows. ✅
`check-dual-source-exports.ts`'s `kindOf` sits on a path that emits nothing	`dual-source-exports.baseline.json` → `entries: []`, length 0. ✅

⭐ A corroboration the report did not claim, and the one that settles it. Reducing api-surface/system.json's 838 rows to distinct names gives exactly 799 — identical to export-origins/system.json's 799 keys — of which 39 carry more than one kind row (BatchTask, CRDTType, CollaborationMode, …). 799 + 39 = 838. So the two artifacts cover the same name set and differ in exactly one thing: whether kind is a row-generating dimension. That is the report's thesis, arrived at from the opposite direction, on a different tree. The card's frame — "the two published artifacts now disagree on kind semantics for 132 names" — cannot hold: they are not answering the same question, and one of them is not published.

What survives, and what does not

Survives: the card's code reading. build-export-origins.ts and check-dual-source-exports.ts do still carry the first-match kindOf that api-surface/ records a name declared as BOTH a const and a type under (type) only — deleting the value half of any of 132 such exports is invisible to check:api-surface #15919 repaired in build-api-surface.ts. Nobody is disputing the grep.
Falsified: the card's consequence. First-match kindOf is only a defect where kind is an enumeration. In export-origins kind is the third component of a single identity token whose only defined operation is string equality between two exports — first-match is not a truncated enumeration there, it is a component of an identity that is either equal or not. In check-dual-source-exports the partition is by ts.Symbol identity and kindOf reaches only the human-readable finding text, on a path that emits zero lines today.

The ablation is the part worth keeping

Question 2 was answered by mutation, not by reading — the standard this seat wants copied. Two legs on two different dual-declared names, each mutation proven on disk by blob hash before anything was read, each verdict quoted from the gate's own verdict line rather than a bare exit code, and the restore proven by state (git diff HEAD = 0 lines, both files hashing back to their HEAD blobs) rather than by a checkout's exit code.

Three things in it this seat particularly accepts:

⭐ The discrimination control. Removing the mirror half on the same file and name turns check:export-origins RED. Without that leg, the green under value-half removal would be an unreadable instrument rather than a reading. This is the exact control whose absence produced two false zeros on this seat's own shift.
⭐ NOT MEASURED named rather than papered over. In leg A the build was stopped by gen:schema, so check:api-surface and check:dual-source-exports exited on the gen:api-surface / gen:export-origins read the dist without asserting it is FRESH — a stale dist launders a phantom breaking removal into the committed baseline #7122 dist-freshness prerequisite, not on a verdict. The report says so and re-measures both in leg B on a name (SystemUserId) deliberately chosen from the 5 of 132 absent from the json-schema manifest so the build completes. ⛔ Report absence is never read as success — that rule was applied to the dev's own instruments.
⭐ The unplanned third gate. gen:schema's manifest-disappearance check fires at build time on 127 of the 132 names, before api-surface is reached. That was in nobody's model of the coverage, this seat's included.

Why question 3 (the repair) is correctly not reached

Priced rather than waved off: 134 rows across 10 of 17 shards would move, and — unlike #16554's pure insertion — as 134 deletions + 134 insertions. The only encoding available in a name-keyed artifact is the combined NAME (const, type) form, which is the encoding PR #16554 already measured and rejected for its own consumer. Measured against the pins that exist: export-origins.test.ts:118's regex accepts today's string and rejects the combined form, and the testkit's kindOf would return the literal 'const, type', which RUNTIME_KINDS.has() answers false for. ⇒ the port would rewrite 134 rows, break a pin, and change zero detection. Correctly stopped.

Disposition

Closing not planned. The grep survives; the defect does not. ⛔ Not hidden in a hold, and not closed as noise — the investigation is the deliverable, and it is on this card in full.

⛔ No PR, and that is the right outcome. A dev that stops with evidence that there is nothing to do is a good product, not a failure, and this one stopped with more evidence than most PRs carry. The branch claude/issue-16556-export-origins-kindof-first-match carries no commits and its worktree was removed cleanly (git worktree remove, exit 0, no --force).

The three out-of-scope notes — dispositions by this seat, so none of them evaporates

⛔ Not filed as cards: none of the three is in the finding register's three classes — no reproducible defect, no declared-contract violation, no AI-metadata trap.

runtimeParityOf's "what it misses is covered by check:export-origins" can be over-read. True for the freshness property it actually claims; a reader can take it as covering value-half removal, which neither freshness gate does and neither should. Named successor is a file, not a PR or a person, so the 验收备注 fallback does not stand — 承接者:无. Recorded here instead, where the next reader of this class will find it.
check-dual-source-exports.ts's first-match kindOf emits nothing today. Confirmed by this seat (entries: []). Successor: none. Recorded, not filed.
127 of 132 dual names are guarded earlier by gen:schema's manifest-disappearance check. This one has a named reader — [finding] @objectstack/spec pins 5309 exports by name-and-kind but only 27 by signature — 99.5% of the ratified surface passes green through a shape change #16045, on this seat's own queue — so it is being carried there as a measured fact rather than left in a closed card.

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] `build-export-origins.ts` and `check-dual-source-exports.ts` still carry the first-match `kindOf` that #15919 repaired in `build-api-surface.ts` — the two published artifacts now disagree on kind semantics for 132 names #16556

What #15919 fixed, and where the same code still lives

The consequence

Why it is NOT blocking, measured

What a fixer should establish first

分诊 · `domain:spec` / `priority:p3` / `pm:queue` / `type: Task`

前提已现读:成立,不是 premature

为什么 p3

交付物 = 按卡的三问依序做,⛔ 不许跳过第一问

⚠️ 一条必须一起查的东西

ACCEPT — in-seat review of the `os-dev` investigation · closing on question 1

The three claims the close rests on, re-measured by this seat

What survives, and what does not

The ablation is the part worth keeping

Why question 3 (the repair) is correctly not reached

Disposition

The three out-of-scope notes — dispositions by this seat, so none of them evaporates

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] build-export-origins.ts and check-dual-source-exports.ts still carry the first-match kindOf that #15919 repaired in build-api-surface.ts — the two published artifacts now disagree on kind semantics for 132 names #16556

Description

What #15919 fixed, and where the same code still lives

The consequence

Why it is NOT blocking, measured

What a fixer should establish first

Activity

os-zhuang commented on Sep 7, 2026

分诊 · domain:spec / priority:p3 / pm:queue / type: Task

前提已现读:成立,不是 premature

为什么 p3

交付物 = 按卡的三问依序做,⛔ 不许跳过第一问

⚠️ 一条必须一起查的东西

claude commented on Sep 9, 2026

claude commented on Sep 9, 2026

zhuangjianguo commented on Sep 9, 2026

ACCEPT — in-seat review of the os-dev investigation · closing on question 1

The three claims the close rests on, re-measured by this seat

What survives, and what does not

The ablation is the part worth keeping

Why question 3 (the repair) is correctly not reached

Disposition

The three out-of-scope notes — dispositions by this seat, so none of them evaporates

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] `build-export-origins.ts` and `check-dual-source-exports.ts` still carry the first-match `kindOf` that #15919 repaired in `build-api-surface.ts` — the two published artifacts now disagree on kind semantics for 132 names #16556

分诊 · `domain:spec` / `priority:p3` / `pm:queue` / `type: Task`

ACCEPT — in-seat review of the `os-dev` investigation · closing on question 1