Single Source of Truthへ移行したのに、古い状態が残った理由

1. 何が起きたか

2026年8月11日、technical-document-workflowでは、active/WORK_STATUS.mdをsole mutable status authorityとする方針が導入されました。AGENTS.mdの§3にあった重複したcurrent-state blockは削除され、「本書に現在状態を複製しない」という運用が採用されました。

しかし同じAGENTS.mdの§4には、TOP-04を現在の対象として扱うmutableな状態記述が残っていました。bba09278の時点で、WORK_STATUSはTOP-04 FORMAL DRAFT CONSTRUCTIONとFIXED_FOR_DRAFTの中心命題を示していた一方、§4は初期Evidence構築、中心命題の研究仮説、正式本文へまだ進まない状態を示していました。§4は、このSSOT移行commitの時点ですでにWORK_STATUSと不一致でした。

その後、TOP-04のformal draftはDRAFT FINALIZED / HUMAN APPROVEDとなり、WORK_STATUSと関連project documentsが更新されました。AGENTS §4との差はさらに広がりましたが、後続更新がstalenessを生んだわけではありません。2026年10月12日の修正では、今回問題となった§4のmutable current-state ownershipが、WORK_STATUSを参照する構造へ修正されました。

2. 一見した矛盾

この事例が紛らわしいのは、次の三つが同時に成り立っていたからです。

• 正しい正本は存在していた。
• 後続の作業は正本を更新していた。
• それでも、別の文書には古いcurrent stateが残っていた。

「正本が正しければ、他の文書も自動的に正しくなる」と考えると、この状態は理解しにくくなります。SSOTはauthorityの移転であって、旧copyの内容を自動消去する仕組みではありません。移行完了の条件に旧copyの撤去または参照化が含まれていなければ、正本の外側にstale stateが残り得ます。

3. タイムライン

1. 2026-08-11 / bba09278 — WORK_STATUSをsole mutable status authorityとし、AGENTS §3の重複state blockを削除した。同じ時点でWORK_STATUSはTOP-04 FORMAL DRAFT CONSTRUCTION / FIXED_FOR_DRAFTを示し、§4は初期Evidence構築と研究仮説の状態を示していたため、§4はすでに不一致だった。
2. 2026-08-11 / d8ff5cc2 — TOP-04 formal draftをDRAFT FINALIZED / HUMAN APPROVEDへ更新し、WORK_STATUSと関連project documentsを更新した。正式章順、最終引用、図版、PDFなどの後続作業は別に残った。AGENTS.mdは変更対象ではなかった。
3. 2026-08-22 / 74d2b9e9 — READMEのstale TOP-04 stateを更新した。AGENTS §4のlegacy stateは残った。
4. 2026-08-25 / 779a735 — AGENTS.md自体を編集してrelease artifact boundaryを追加したが、§4のlegacy stateは残った。
5. 2026-09-24 / 7ac8ecde — AGENTS.md自体を編集してProject-DF routing policyとauthorityの所在をさらに明示した。それでも§4のlegacy snapshotは残った。
6. 2026-10-04 / 82be6ba — AGENTS.md自体を編集してexternal concept mapping ruleを追加したが、§4のlegacy stateは残った。
7. 2026-10-12 / d023db44 — AGENTS.md §4から今回問題となったmutable current-state duplicationを除去し、current target、next gate、evidence authority、per-Top current stateをWORK_STATUSから参照する構造へ修正した。

この順序から確認できるのは、正本更新の履歴と、旧copyの除去が後段で行われたことです。当時の作業者の心理や意図までは、このGit履歴から確定できません。

4. SSOT移行で変わったこと

最初の移行は、単一の正本を明示する点では成功していました。WORK_STATUSが現在状態を所有し、他の入口文書はそこを参照するという役割分担が定義されました。これはauthorityの移行です。

一方、移行にはもう一つの面があります。旧文書に残るmutable valueを、(a)撤去するか、(b)正本を読む参照に変えるか、(c)意図的なhistorical recordとして状態所有から切り離す必要があります。このケースでは、§3は(a)に近い形で整理されましたが、§4のspecific state proseが未処理のまま残りました。

概念上の移行前後

BEFORE

AGENTS §3: current state belongs only to WORK_STATUS

AGENTS §4: current target = TOP-04

AFTER

AGENTS §4: current target / next gate / evidence authority
          / per-Top current state are read from WORK_STATUS
          rather than duplicated here

ここでのBEFOREは当時のファイル全体を逐語引用したものではなく、二つの役割が同居していた構造を示す概念図です。

5. 取り残されたもの

取り残されたのは、単なる説明文ではありません。§4のTOP-04-specific proseは、その時点の対象や作業境界を表すmutable current-state valueとして読める内容でした。つまり、AGENTS.mdは一方で「状態を複製しない」と規定しながら、別の節では状態の一部を保持していました。

この二重性は、文書の責務を曖昧にします。AGENTS.mdはdurable policyや作業規則を担う文書なのか、それとも現在の対象を保持するstate documentなのか。前者として運用されるなら、後者の可変値は別の正本に置き、AGENTS.mdはその参照方法だけを持つ方が境界が明確です。

6. なぜ後続更新で直らなかったか

後続のstate updateが古いcopyを直さなかった理由は、更新手順が正しくなかったからではありません。d8ff5cc2では、WORK_STATUSと関連project documentsが変更され、AGENTS.mdは変更されませんでした。ここで確認できるのは、このobserved changed-file setです。記録されたauthorization setや、AGENTSを変更しなかった理由までは、commitから確定できません。

E1のFRAMEWORK_SPEC §4.2は、mutable state updateは通常WORK_STATUSを対象とし、他文書はrole/reference条件が必要な場合に変更すると定めていました。この記録に基づき、d8ff5cc2をAGENTS §4の修復権限がなかったと解釈することはできません。

また、AGENTS.md自体は779a735、7ac8ecde、82be6baで後から編集されましたが、§4のlegacy stateは残りました。なぜ各編集で残ったのかは推測しません。したがって、residueの持続はstate-update commitの変更範囲だけでは説明できません。

ここでbounded write scope自体を欠陥とは扱いません。より正確には、migration residueがE1から存在し、state-update pathがそれを修復せず、後続のAGENTS editsもそれを除去しなかったということです。

7. なぜ通常の検証を通り得たか

この履歴から直接、当時どの検証コマンドが実行され、すべてがPASSしたかを再構成することはできません。したがって、特定のテストが通ったと断定するのではなく、検出 gapを次のように限定して説明します。

確認できる変更は、各commitの意図されたファイルと差分の範囲では整合していました。ところが、「AGENTSはmutable current-state valueを重複所有してはならない」という明示されたsemantic invariantは、E1の移行時点で十分に満たされていることも、確認されていることもありませんでした。

つまり、diffやsyntaxの検査だけでは、別ファイルに同じ意味のstateが残っているかを自動的には示しません。ここでいうdetection gapは、検証が悪かったという一般論ではなく、変更範囲・構文と、文書全体のsemantic role invariantが別の確認対象だったという指摘です。

8. 原因と境界

このラベルは本ケースのRCAを説明するための整理です。新しい標準taxonomy、Gate、framework、または一般的な分類体系を提案するものではありません。

9. 「値を更新する修正」と「構造を直す修正」

値を更新する修正

AGENTS §4のTOP-04を、その時点の最新値へ書き換える方法です。これは常に誤りとは限りません。実際、74d2b9e9でREADMEのstale TOP-04 stateを更新したことは、READMEがWORK_STATUSに従うsubordinate summaryとして扱われているため、正当な同期です。

ただし、現在状態を重複保持しない設計になっているAGENTS §4へ同じ値を書き戻す場合、表示上の不一致を一時的に減らしても、mutable stateのownershipは残ります。

構造を直す修正

d023db44では、今回問題となったAGENTS §4のcurrent target、next gate、current evidence authority、per-Top current stateの複製を除去し、それらはWORK_STATUSから読むと明示しました。修正の対象は「古い値」ではなく、§4がその値を所有する構造でした。

この修正確認は今回問題となった§4のcurrent-state ownershipを対象としており、AGENTS.md全体のすべての可変記述を包括監査したものではありません。ここでの結論は、§4について正本参照へ変換する方が、採用されたauthority modelに適合するということです。

10. 実務上の示唆

• SSOT移行には、旧mutable replicaのinventoryと、撤去またはreference conversionを含める。
• durable policy documentは、別の文書がcanonicalなephemeral current stateを所有する場合、その値を保持しない。
• 限定された変更範囲はscopeを守るが、既存の不整合を自動修復するものではない。
• diffやsyntaxの検査に加え、文書の役割に関するinvariantを確認する必要がある場合がある。
• 修正は、最新値を書き戻すことではなく、mutable stateの所有を除去する形が適切な場合がある。

これらは一つのrepositoryのケースから得た、範囲を限定した実務上の示唆です。すべてのSSOT移行に同じ失敗が起きる、という主張ではありません。

Evidence / provenance

技術的事実は、technical-document-workflowのGit historyで確認できる範囲に限定しています。下記のパスはrepository-relativeです。各行の「示さないこと」は、commitから直接は確定できない境界です。

Evidence source: mars70s/technical-document-workflow Git history. Reader-facing本文では、private machine pathや内部作業環境を記録していません。

限界

• これは一repositoryのケーススタディです。
• すべてのSSOT migrationが同じ失敗を起こすとは主張しません。
• AI agent固有の失敗、またはAIが原因だったとは主張しません。
• exact write set自体を欠陥とは扱いません。
• stale copyが意図的に残されたとは主張しません。
• 当時の作業者の心理・意図は推測しません。
• commit履歴から、当時の全validation commandや人間の認識状態までは確定できません。

関連コンテンツ

• AGENTS.md Maintenance: A Read-Only Audit — AGENTS文書の責務と保守範囲。
• AIはなぜ、意図しない結果にたどり着くことがあるのか — 状態と検証結果の取り違え。
• AIはミスを指摘されると暴走するのか — scopeと検証境界のケーススタディ。