question(tests): tNNN に一意性契約を置くか、意図的併存を文書化するか — 実測で192番号が重複

[j5ik2o]

重複・現行状態の確認

• gh issue list --state all --search "tNNN 重複 test number" / --search "テスト番号" を実行。ヒットした open Issue(mirror(labels): ラベル同期の残債 — Project 参照の PR 番号混入時の誤付与(理論上)と labelHttpStatuses の 1xx 扱い #2020 / refactor(tools): ownPhase の3コピー(orchestrate/jump/state)を amadeus-lib へ共通化する #833 / ci: マージ時再検証の一般化 — drift guard・ベースライン系ゲートをマージ直前に fail-closed で再検証する #1983 / Codex: invoke-swarm directive lacks executable batch and convergence context #2837 / enhancement(hooks): runtime-compile の transition 検出を固定3行窓からイベント耐性のある走査へ — WORKFLOW_COMPLETED 押し出しの無言不発ハザードを予防 #2539 / coverage-patch-allowlist の全エントリを reason と現行行内容で直読照合する(無音転位の棚卸し) #1622)はいずれも別主題で、テスト番号の一意性を扱うものは無い。
• origin/main の tests/ を実測し、後述のとおり重複は現行の常態であることを確認済み。

背景・対象範囲

intent 260810-grilling-frontier-resync の §12a レビューが FOLLOW-UP として「新規テスト t530 / t531 が既存テストファイルと同一 tNNN を共有している。改番または意図的併存の明記が要る」と指摘した。

これを受けて conductor が repo 全域を実測したところ、tNNN の重複はこの repo の常態であり、当該2件は例外ではないことが分かった。したがって「t530/t531 を改番する」という個別対応では問題設定を誤る。本 Issue はスコープを一段上げ、tNNN に一意性契約を置くのか、意図的併存を正式に文書化するのかの裁定を求める。

対象範囲は方針の裁定まで。実装(ガード追加・改番キャンペーン・文書化)は裁定後に別 Issue とする。

根拠・実測証拠

測定 ref: origin/main 相当の作業ツリー、tests/ 配下。

# 2ファイル以上で共有されている tNNN の数
find tests -name 't[0-9]*' -type f | sed 's|.*/||' | grep -oE "^t[0-9]+" | sort | uniq -c | awk '$1>1' | wc -l
  → 192

# 共有数の上位
  9 t427
  9 t258
  8 t416
  6 t415
  6 t367

# 本件の発端となった2番号
tests/integration/t530-nfr-budget-scope-skip.integration.test.ts
tests/unit/t530-grilling-marker-predicate.test.ts
tests/integration/t531-plugin-harness-literal-guard.integration.test.ts
tests/integration/t531-grilling-budget-sensor.integration.test.ts

一意性を強制する機構は存在しない。tests/ 配下に番号レジストリや重複検出ガードは無く(gen-coverage-registry.ts はカバレッジ台帳であって番号の一意性を見ない)、CI のブロッキング集合にも該当する検査は無い。

一方、短形引用の誤解決リスクは既にノルムで対処済みである。memory/team.md の cid:requirements-analysis:mechanism-cite-verify-at-draft 追補(E-FSPRAS13、2026-07-23 採用 3-0)は「テスト引用は tNNN 短形でなくフルパス(+可能ならシンボル)で書く — 同一テスト番号の複数ファイル共存は実在する生態(t211 = 5ファイル実測)で、短形引用は実在する別ファイルへ誤解決される」と明記している。つまり現行ノルムは重複の実在を前提に、引用側で防御する設計になっている。

なお cid:code-generation:swarm-test-number-reservation は「並列 swarm ディスパッチでは新規 tNNN をユニットごとに事前予約する」を定めるが、これは同時採番による同一 intent 内の衝突の予防であり、intent 横断の一意性を契約するものではない。本 intent でも t530 以降を予約して運用したが、他 intent が既に使っていた番号との衝突は防げていない(予約は自 intent 内の調整でしかないため)。

期待結果・完了条件

次のいずれかの方針が裁定され、記録されること。

• A: 意図的併存を正式に文書化する — tNNN は「テストの通し番号」ではなく「起票・作業単位の識別子」であり、複数ファイルが同じ番号を共有してよいと明記する。引用側の防御(フルパス引用)は既存ノルムのまま。追加のガードは作らない。
• B: 一意性を契約し、機械ガードを置く — 新規ファイルの tNNN が既存と衝突したら CI が落ちる drift guard を追加する。既存 192 番号の扱い(grandfather する / 改番キャンペーンを打つ)も併せて決める。
• C: 中間 — 新規追加分のみ一意性を要求し(shrink-only ratchet)、既存重複は据え置く。

完了条件: 方針が memory 層のノルムまたは docs に記録され、B/C を選ぶ場合は実装用の別 Issue が起票されていること。

影響・価値

現状は「重複が常態」と「重複は避けるべき」という2つの読みが同居しており、レビューのたびに同じ FOLLOW-UP が再生産される(本件がその実例)。方針を確定すれば、レビュアーは指摘するかしないかを機械的に判断でき、実装者は採番時に迷わなくなる。

B/C を選ぶ場合は 192 番号の扱いという実コストが発生するため、A(現状追認+文書化)が最小コストである可能性が高い。ただしそれを裁定として記録することに価値がある。

関連 Issue・PR・intent

• 発端: intent 260810-grilling-frontier-resync の §12a FOLLOW-UP(amadeus/spaces/default/intents/260810-grilling-frontier-resync/construction/budget-sensor/code-generation/code-generation-plan.md の Review — Iteration 1/2)
• 関連ノルム: cid:requirements-analysis:mechanism-cite-verify-at-draft(E-FSPRAS13 追補 — フルパス引用)、cid:code-generation:swarm-test-number-reservation
• 関連 PR: feat(grilling): grilling モード対応の question-budget センサーと契約テスト (Bolt 2) #2843(t530 / t531 を追加)

優先度（いつ対応するか）

P3

回答してほしい問い・選択肢

問い: tNNN に intent 横断の一意性契約を置くか、意図的併存を正式に文書化するか。

選択肢	内容	トレードオフ
A	意図的併存を文書化(現状追認)	コスト最小。引用側の防御は既存ノルムで足りる。ただし「番号が識別子として弱い」状態が続く
B	一意性を契約+CI ガード	採番が決定的になる。既存 192 番号の grandfather 設計か改番キャンペーンが必要
C	新規のみ一意(shrink-only)	既存を触らずに前進できる。ratchet の初期 census を最終 base で採る規律が要る(cid:code-generation:c5-ratchet-census-at-final-base)

事実確認の方法: 上記「根拠・実測証拠」のコマンドをそのまま再実行すれば、重複の規模(192 番号)と一意性ガードの不在を独立に確認できる。