folio-rgtc grill (2026-07-13) の論点6 は SSoT の向き = A-where-possible を裁定した: 反転可能な doc-type では contract YAML を「正本」とし、 HTML は生成物とする (ADR-0050)。 この「正本 = YAML」という言い方は、 constitution の三原則と見かけの緊張を生む: P-7 は「WHAT (設計意図) は design-intent 空間の design intent 領域 (spec cluster) が持つ」と定め、 P-2 は「design-intent 文書は HTML で記述する」と定め、 P-11 は「HOW (platform 固有 primitives) を本文に直接記述せず implementation harness へ隔離する」と定める (folio ではその harness = ADR-0003 の .claude-plugin/)。 素朴に読むと「正本が YAML になった = WHAT が YAML に移った = P-7 と P-2 に違反し、 しかもその YAML は P-11 の隔離先 harness (.claude-plugin/design-system/generator/contract/) に住んでいる」という誤読が成立してしまう。
この誤読は仮定の話ではなく、 放置すると監査が恒常的に誤検出する実害を持つ。 folio の検証体制は独立コンテキストの reviewer (ceiling / spec-review-ssot 等) を多数束ねる方式であり、 各 reviewer は constitution と spec を一次資料として判定する。 「正本」の語が層を区別せずに流通すると、 P-7 違反 (WHAT の越境) という false positive が review のたびに再生産され、 その都度の反駁コストが恒常化する (grill 監査 F1 が pin した放置コスト)。 必要なのは constitution の改訂ではなく、 「正本」と「canonical WHAT」の層を分離する解釈の明文化である。
次の層解釈を canonical とする: 生成 HTML = canonical WHAT (提示層) — 何が真かの canonical な表明であり、 spec graph の住人 (JSON-LD relation の端点) であり、 P-7 が「WHAT の家」と定める場所に住み続け、 P-2 の HTML 要件を満たし続ける。 contract YAML = 正本 (edit-SSoT) — その表明を produce するための編集起点 (生成 input) であり、 生成工程 (HOW) の一部として P-11 の隔離先 harness (.claude-plugin/design-system/generator/contract/) に居住する。 両者は同じ内容の二つの顔ではなく、 役割の異なる二つの層である: 読む者・照会する者・graph が見るのは提示層 (HTML) であり、 書く者が触るのは edit-SSoT (YAML) である。 P-7 / P-2 は提示層に、 P-11 は edit-SSoT に、 それぞれ矛盾なく適用される。
この層分離は folio が既に持つ原理の再適用である。 ADR-0026 (P-13) は検証を「spec 適合性 (framework 提供・普遍) / 実装適合性 (各 stack 慣習・folio 非 mandate)」に二分し、 「何が真か」の層と「どう作る・確かめるか」の層を分離した。 本 ADR は同じ二分を WHAT の SSoT に適用する: canonical WHAT (何が真かの表明 = 提示層 HTML) と、 それを produce する工程資材 (edit-SSoT = contract YAML) は別の層であり、 後者が前者の家 (P-7) を侵さない。 ADR-0047 の HOW-outside gate が contract YAML の .claude-plugin/ 居住を現に守っていることは、 この解釈が現行秩序と一致している傍証である。
以後の文書・監査・review は次の語彙で層を区別する (grill 監査 F1 の pin): 「正本 (edit-SSoT)」= contract YAML / 「canonical WHAT (提示層)」= 生成 HTML。 folio-rgtc 論点6 の裁定文にある「contract YAML = 正本」は edit-SSoT の意味であり、 P-7 の「WHAT は design intent 領域の HTML が持つ」を否定しない。 既存 canonical 語「canonical SSoT」(= dual-audience 文書の機械層・精密 normative の確立名) はこの pin と両立する — 機械層は canonical WHAT (提示層) の内部にあり続け、 その編集の源が正本 (edit-SSoT) = contract YAML である。 「SSoT」の語は以後、 修飾付き full 形 (canonical SSoT = 提示層の精密 normative / edit-SSoT = 編集の源) で層を明示して用いる (glossary SSoT = vocabulary.yaml の dual-audience 定義への反映は follow-up)。 監査が SSoT-first 転換後の corpus で P-7 違反を判定する際は、 「WHAT の越境」(内容が domain を跨いで重複・矛盾する) と「edit-SSoT の harness 居住」(本 ADR が正当と定める配置) を混同してはならない。
「正本なのだから design-intent/ に置くべき」という物理移動案は不採用とする。 contract YAML を design-intent 空間に移すと (1) P-2 (design-intent 文書は HTML) と衝突する — P-2 の YAML 例外は「外部 platform 規約に従う file (VCS host README / AI-agent instruction / YAML config)」に限られ、 folio 内部 generator の生成 input を WHAT 空間の文書として置く行為は例外に該当しない。 そもそも contract YAML は spec 文書ではなく生成 input であり、 HTML 化する意味がない。 (2) P-11 の HOW 隔離を破る — 生成工程の資材が WHAT 空間に混入する。 (3) 得られるものは「正本という語の素朴な読みとの一致」だけで、 §2.1 の層解釈がその必要自体を消す。 配置は現状 (.claude-plugin/design-system/generator/contract/) を維持する。
| 案 | 採用可否 |
|---|---|
| 層解釈の明文化 (採用) | constitution 無改訂で P-7 / P-2 / P-11 の緊張を解消。 P-13 と同型の既存原理の再適用で、 新規概念の発明ではない |
| contract YAML を design-intent/ へ物理移動 | 不採用 — P-2 と衝突し (YAML 例外は外部 platform 規約準拠 file 限定で該当せず)、 P-11 の HOW 隔離を破る。 層解釈が「移す必要」自体を消す (§2.4) |
| P-7 を改訂して YAML-WHAT を許す | 不採用 — constitution Amendment (P-10) は不変資産への重量級介入であり、 解釈で足りる問題に対して過大。 P-7 の本来の射程 (domain 間の内容排他) は毀損せず保てる |
| 何もしない (裁定文の文脈で読めば分かる) | 不採用 — 独立コンテキストの reviewer は grill の文脈を持たない。 監査の P-7 誤検出が review のたびに再生産される (F1 pin の放置コスト) |