文書規律エンジン (C) — B0 設計 design-of-record

v1.0.0 · status: active · folio 規律を一般化した汎用文書一式生成エンジンの設計記録 (epic folio-0dv / B0=folio-9ay 合意 + B1=folio-bwc 実証)

§1. 目的とロードマップ上の位置づけ

folio は当初「自分自身を規律する META FRAMEWORK」として作られたが、 そこで磨いた文書規律 (dual-audience / EARS / RTM / declarative / 1 名 1 語 / HOW を外側へ / 3-domain 分離 / inter-doc 照会) は folio 固有ではなく あらゆる文書一式に効く一般原理である。 文書規律エンジン (C) はこの規律を抽出し、 任意プロジェクト向けに「完璧な文書一式」を生成する道具にする試みである。

進め方は 抽出主導 (rule-of-three): 全列挙で設計するのではなく、 folio を強い事前知識として ~3 例の実物を作り、 共通項を core として後から抽出する。 SRS-pack (epic folio-c5g) が一例目、 本 B1 の ADR-pack が二例目 (instance#2)。 止め時は「新しい doc-type が core を一切変えずに純粋な pack として挿さった」とき。 抽出は可逆 (誤って core に置いた物は pack へ降格できる)。 endgame は folio 自身をこのエンジンで dogfood すること。

フェーズbd内容状態
B0folio-9ay設計 grill (6 論点合意)完了
B1folio-bwcinstance#2 = clinic ADR 生成 + 本 design-of-record本 doc
B2folio-5uacore 抽出 (非破壊・共有 lib/ へ)完了
B3folio-ar1instance#3 = research pack (rule-of-three 止め時 MET)完了
B4folio-igvinstance#4 = principle / constitution pack (本 §9)完了
B5folio-983照会 graph 終端完備 + HOW-outside enforcement 機構 (本 §10・ADR-0043 昇格)完了
B6folio-qf1folio self dogfood (endgame・spec-pack 自己 self-host)完了
c5rfolio-c5rpost-B6 完全 doc-suite 被覆 + suite demo grill (本 §11)進行中

§2. 論点1 — エンジンの 3 層構造

engine は次の 3 層 + 別軸の constitution に分かれる。 「機構 (どう生成・検証するか)」と「規律 (何が良い文書か)」と「中身 (各 doc-type 固有の部品)」を分離するのが要点で、 これが core / pack 境界を引く基準になる。

役割具体 (folio の現状から)
plumbing core (機構)doc-type 非依存の生成・検証の足回り現 §12 の 4 機構: ①機械 SSoT から生成 ②決定的 assembler + opus prose ③自己完結 (single-file inline) ④2-gate (floor 機械 ∧ ceiling LLM)
普遍規律層 (著作規律)どの文書にも効く「良い文書」の規律dual-audience / declarative / 1 名 1 語 (canonical name) / HOW を外側へ / domain 分離 / inter-doc 照会
doc-type pack (中身)その文書型固有の schema + 部品 + gate 詳細SRS: EARS・RTM・37 部品 / ADR: context・options・decision・consequences・supersession
(別軸) constitution採用時のみ効く不変原則 (§5)optional-but-special

core⟷pack の境界判定 = 「その機構を新 doc-type に持ち込んだとき改変が要るか」。 改変ゼロで再利用できれば core、 doc-type 固有なら pack。 B1 の実物がこの判定を初めて検証した (§7)。

§3. 論点2 — 照会 (inter-doc cross-ref) = 抽象ロール graph

文書間・文書内の「主張 → 根拠 → … → 終端」のつながり (照会) を、 doc-type 固有語ではなく 抽象ロールで定義する。 core が次の抽象役割と普遍 edge「主張 → 根拠 → 探索 → … → 終端」を定義し、 各 pack が具体語をこの役割へ写像する。

抽象ロール意味SRS-pack の写像ADR-pack の写像
claim主張・約束されるもの要件 (FR/NFR)decision (採用した判断)
rationaleなぜそれが要るか上位ニーズ (N-x)context (背景・力学)
exploration検討した選択肢(SRS では薄い)options (選択肢 + 利点/欠点)
verification満たせたと確かめる基準受入基準 (AC)(検証手法バッジ)
principle遡らない終端原則(constitution あれば)principle (照会終端)
implementationHOW 側 (外部化)tests / コード (照会リンク)実装方式 (decision が指す)

照会終端の規約 = principle があれば principle、 無ければ top-rationale で止める。 既存の folio JSON-LD graph (relations / xref) を描画・格納の基盤に再利用し、 1 名 1 語 (P-5) を保つことで文書横断クエリが可能になる。

★B1 で実証した最難関 edge = cross-doc 照会: ADR の decision (claim) が別文書である SRS の要件 FR2 (予約受付) / FR3 (競合拒否) を正当化する edge を機械 SSoT に持たせ、 参照先 SRS に当該要件 ID が実在することを fail-closed で検証した (§7)。

§4. 論点3 — HOW を外側へ (enforcement は 3-tier)

design-intent (WHAT/WHY) と実装・検証 (HOW) を content として分離し、 HOW へは照会リンクで繋ぐ (本文に HOW を埋めない)。 これを守らせる enforcement は core 同梱の 3-tier:

照会 graph が tier 1 の注入物になる。 これは folio の ADR-0007 (context injection) / ADR-0028 (2-gate enforcement) を一般化したものである。

§5. 論点4 — constitution = optional-but-special

constitution (不変の最上位原則) は 必須ではない。 採用したプロジェクトに対してのみ、 core が (a) 不変性、 (b) 改訂 gate (P-10 一般化: 改訂は ADR 経由で照会記録を残す)、 (c) 照会終端としての役割、 を保証する。 採用しないプロジェクトでは照会は top-rationale で終端する (§3)。 「必須でないが、 採用時だけ特別扱い」という非対称が要点。

§6. 論点5 — versioning = 単一版ライン (additive)

engine は 単一の版ラインで進める (folio の plugin.json 1 版)。 SRS-gen は 1.1.0、 core 抽出 + ADR-pack は後続 MINOR、 と 追記式に積む。 pack は「電池同梱」で folio と版が連動する。 MAJOR (2.0) は contract schema を破壊するときだけ。

★設計制約 (B1 から守る): core 抽出は 既存 SRS contract schema を不変に保つ (抽象ロールへの写像は pack 側に置く) ことで、 非破壊の MINOR に収める。 B1 の ADR-pack はこの制約を守って作った (SRS contract に一切触れず、 ADR から SRS を照会する片方向で実装)。

§7. 論点6 + B1 実証 — instance#2 (ADR-pack) が炙り出した core / pack 境界

B1 (folio-bwc) は clinic SRS の FR2/FR3 (二重予約防止) を正当化する clinic ADR を機械 SSoT から生成し、 同一ドメインで SRS + ADR の文書ペアを成立させた。 実物 (.claude-plugin/design-system/generator/) で得た core / pack の切り分けは次の通り。

要素SRS との関係判定
inject-prose.sh (prose 注入)無改変で共用 (data-slot-id ベースで doc-type 非依存)core 候補 (強)
esc / mark_terms / band / cover / glossary / footer の語彙idiom を共用 (関数を流用)core 候補
2-gate (floor 機械 ∧ ceiling LLM) の型同型 (verify-adr が verify-fab と同じ規律)core 候補
fabrication-free 規律 (行数=contract導出 / escape / 集合一致 / fail-closed)同型だが対象 schema が違うcore 規律 + pack 適用
contract schema (context/options/decision/...)SRS と全く別pack 固有
section emitter (options card / decision panel / cross-doc justify)SRS と別構造pack 固有
cross-doc 照会の解決 (justifies → 別 contract の req 実在)SRS には無い新軸core 機構 (照会) の pack 適用

一次証拠: prose injector が 1 byte も変えずに ADR で動いたこと、 2-gate と fabrication-free の規律がそのまま移ったことが「SRS-pack ∩ ADR-pack = core」を具体的に示す。 一方 assembler 本体は doc-type 固有の section 構造ゆえ fork が要った (= pack)。 core 抽出 (後続別 bd) は inject-prose.sh + 2-gate 型 + fabrication-free 規律 + 照会機構を core へ引き上げ、 assemble の共通 idiom (esc/mark_terms/band/cover/glossary/footer) を共有ライブラリ化する方向になる。

非目標 (rule-of-three の経済性): フル ADR generator 化・複数 ADR・独立版は作らない。 B1 は最小の extraction-probe に留める。

§8. 次の一手

§9. B4 — principle / constitution pack の設計合意

B4 (folio-igv) は §3 の照会終端ロール principle を実 doc-type 化する pack を新設する。 instance#4 として folio 自身の 14 不変原則を題材に取り、 principle 固有の 3 性質 (不変・終端・改訂は ADR 経由) を engine 機構で扱えることを実証する。 設計 grill (2026-06-20) で次の 6 点を合意した。

論点決定要点
① 題材folio 14 原則を read-only fidelity targetfrozen constitution.html は置換せず別アーティファクトとして生成 (P-10 安全)。 B6 self-dogfood の「源 contract」前払い。 過渡的に手書き frozen + 生成の二重表現を許容する。
② schema 粒度中核 + 改訂来歴を構造照会{id, 見出し, 宣言文, tier} + amended_by (ADR / date / approved_by)。 versioning / amendment 手続きは opus prose (短い policy 宣言のみ構造化)。
③ constitution = optional-but-specialbaseline-diff CI gateprinciples の golden と diff し、 宣言文 / tier / 増減の変化には必ず ADR 照会 + 版 bump を強制 → silent change を機械的に不可能化。 doc_type:constitution フラグ時のみ起動 (非対称)。 B0 決定③ (guarantee = CI) ④ (P-10 一般化) の機構化。
④ 照会終端機構principle node の局所整合principle の前方照会を FAIL (終端不変条件) + inbound 参照を verify_cross_doc_refs 再利用で fail-closed + amended_by は別軸の来歴 edge。 graph 全体の終端完備は B5 へ。
⑤ scopeprinciple pack のみ build + 写像仮説を記録投機 build をせず (rule-of-three 経済性)、 folio doc-type → pack 写像の仮説だけ本 doc に残す (§9.1)。
⑥ sequencingprinciple pack 先 → bcx 汎用 lint 後principle の異質さ (前方照会なし / baseline-diff / amendment edge) が SRS・ADR・research の 3 例の前提を破る = 汎用 lint を well-informed に一般化する最良の 4 例目 (lint 自身の rule-of-three)。

§9.1 folio doc-type → pack 写像仮説 (論点⑤・build せず記録)

B6 (folio self-dogfood) は folio の全 doc-type を生成可能にする必要がある。 どの doc-type が既存 pack を再利用し、 どれが新 pack を要するかの仮説を残す。 実証は各 doc-type を dogfood する段で行い、 既存 pack に挿さらなければ rule-of-three が新 pack の必要を炙り出す。

folio doc-type写像仮説根拠
constitutionprinciple pack (B4)不変原則 = principle ロール (終端)
rulesSRS 族 (or 汎用 spec pack)EARS で REQ-* を持つ = claim 群
self-specSRS 族 (or 汎用 spec pack)architecture の WHAT = claim 群
relations / verificationSRS 族 (or 汎用 spec pack)規約・framework の spec = WHAT
ADR clusterADR pack (済)B1 で実証
researchresearch pack (済)B3 で実証

★rule-of-three 追試: principle pack が core を一切変えずに純粋な pack として挿さるかが instance#4 の止め時判定である。 挿されば core 抽出の完了を 4 例目が裏づけ、 core 変更を要すれば抽出が不完全のサイン (可逆ゆえ core → pack へ降格できる)。 本節は探索領域 (research/) の design-of-record (路線「い」) であり、 実証が十分に積まれた段階で正式 ADR (P-10 承認) へ昇格させる。

§10. B5 — 照会 graph 終端完備 + HOW-outside enforcement の設計合意

B5 (folio-983) は §3 の照会 graph と §4 の HOW-outside enforcement を実機構化する。 設計 grill (2026-06-21) では reader 要約でなく 実 corpus (生成 5 contract) と現行 verify / hook 機構を read-only で精査する grounding sweep を 3 本 (論点④/⑤/⑥) 走らせ、 検証済み事実に基づいて 7 論点を詰めた。 sweep は地図に無かった重大事実 — 終端の 2 系統分裂 (clinic ADR の inline principle が constitution に不在)・inbound.from の完全無検査 (phantom 照会が GREEN 通過)・HOW-leak の hard gate 強制ゼロ (唯一の機構は advisory lens)・userConfig の runtime 未読 (base_url のみ実読) — を炙り出し、 論点⑥ の推奨を案A から案C へ反転させた。

B5 論点決定要点
① graph 空間 (cross-repo 境界)repo ローカル完備 + folio principle 照会だけ registry 参照各 repo 内で graph が閉じる。 consumer → folio principle の照会のみ plugin 同梱 registry への dangling 検証 (既存 vocabulary 配布レイヤーの拡張)。 cross-repo 統合は B5 射程外。 B6 (folio が consumer 兼 engine) を最も楽にする。
② 格納スキーマcontract YAML を graph 検証 SSoTHTML data-* は描画用 projection。 照会の真の SSoT は既に contract YAML (verify_cross_doc_refs が YAML を source に HTML と SET 一致)。 別表現への転写は drift 源ゆえ避ける。 scope = 生成 doc、 folio 自身の HTML graph 化は B6。
③ ロール写像宣言pack ごと rolemap (node-type → role 表)rolemap = node intrinsic role の SSoT。 scope 内 edge role は floor で edge.role == rolemap[node.type] を pin (co-author + enforce)。 既存 corpus から draft → 明示宣言 → pin が二重担保。 SRS の exploration 不在 (B0 開問F) は scan で実証解決。 rolemap = pack / リーダー = core。 role の多重定義は path-scoped で受容 (改名は follow-up)。
④ 終端完備の検証 (主題)独立 graph script (reachability 一括)contract/ glob → edge union → principle 終端への到達可能性を 1 計算で {終端完備 / 孤立 = warn / 逆方向 = 局所} に展開。 終端は domain-local principle (ADR inline 含む) を許容 (論点① repo-local と整合・inline を graph node に昇格)。 孤立は方向ゼロでなく到達可能性で定義。 amended_by は来歴 meta-edge として除外。 既存 core 関数は不変、 traversal は独立 script。
⑤ HOW-outside content gate二段 floor + ceilingfloor-1 照会リンク存在 + floor-2 P-11 4-enum の保守的検出 (明示 primitive の有無 = 意味判定の射程外ゆえ ADR-0028 の精度懸念に当たらない。 B5 実装は soft-warn 着地・hard-block 昇格は staged rollout = ADR-0043 §2.2)。 ceiling = 概念 HOW (P-3 portability) を既存 spec-review-ssot lens 強化で advisory (新 agent 不要)。 scope = spec_path・floor は CI で担保。 staged rollout (soft-warn 実測 → 新 ADR で CI hard gate)。
⑥ tier1/2 配布plugin 固定 (新 config 変数 0)tier1 照会 digest は folio prime 追記で常時 baked + progressive disclosure、 tier2 content gate は hook 1 本追加で全 consumer 自動適用。 consumer 独自 doc-type は実需要ゼロゆえ YAGNI follow-up。 userConfig は runtime 未読 (base_url のみ実読) のため案A の「userConfig 拡張」は新機構実装を要し不採用 (地図から flip)。
⑦ CI gate の floor ∧ ceiling決定的 → floor / 意味的 → ceiling を両方にgraph floor = 到達性 / dangling / 孤立 (例外的に exhaustive)・graph ceiling = 照会 note / role 真正性 (既存 fidelity-* lens)。 HOW floor = link + 4-enum・HOW ceiling = concept HOW (spec-review-ssot lens)。 guarantee は tier3 CI のみ、 ceiling は CEILING=PENDING の advisory (ADR-0028 一般化)。

§10.1 B5 が確立した横断原則

grill は 3 つの横断原則 — 境界原則 (contract/ 内 = 厳密検証 / 外 〔folio-self の inbound.fromamended_by.adr〕 = external-ref として warn・解決は B6)、 決定的 → floor (CI hard = guarantee) / 意味的 → ceiling (advisory) (graph 構造は有限ゆえ floor が例外的に exhaustive)、 core は additive 拡張のみ (既存 core 関数は byte-identity 非回帰・graph traversal は独立 script) — を確立した。 これらの確定形は ADR-0043 §2.4 が正本 (路線「い」= 実証後 ADR 昇格が完了)。 本 §10 は確定原則を二重保持せず、 grounding sweep が配布推奨を案A → 案C へ反転させた discovery の経緯記録に focus する。

§10.2 follow-up と B6 前払い

grill で炙り出した B5 scope 外の改善候補 (実装時に bd 起票判断): 抽象 role の改名 (P-5 hygiene・role の 3 重定義)、 ADR-less 孤立 SRS の warn → block 昇格 policy、 inbound.from / amended_by.adr の実在・reverse 検証 (B6 で folio spec graph 接続時)、 generated contract の HOW-leak lens (generator ceiling 側)、 ceiling lens の CI 非ゲート advisory 化、 userConfig 4 キーの runtime 未読 gap、 review_model の機械 override 欠落。 B6 前払い: 照会 graph helper は doc-type 非依存で core に置き folio 自身の横断 graph へ転用できるよう設計し、 folio-self-spec の HOW 参照 (§9 Bindings 等) の <code> 言及 → <a href> 昇格は B6 self-dogfood の deliverable とする。 本節も探索領域 (research/) の design-of-record (路線「い」) であり、 B5 の確定設計は ADR-0043 (P-10 user 承認・2026-06-22 accepted) へ昇格済。

§11. c5r — suite demo grill: engine = 生成器 + 機械検出 / 判断は人間

engine 本線 (B4 → B5 → B6) と並行し、 post-B6 の sub-epic c5r (完全 doc-suite 被覆) は『任意プロジェクトの完璧な文書一式』(北極星 folio-7wn) に必要な doc-type 集合を埋める。 その設計 grill (folio-yzv・2026-06-24) は clinic を母体に doc-type 集合の歩き方constitution の要否を詰め、 engine の根本姿勢に関わる哲学転換に至った。 同サイクルで instance#6 = test-cases pack (folio-uvt・main e69449e) が core 無改変で挿さり、 rule-of-three の止め時を 6 例目でも再確認している。

c5r grill 論点決定要点
① 母体ドメインclinic 一本EC (SRS-pack) とは別ドメインを母体に suite を組み、 generator の汎用性を別 consumer で実証する。
② 段階4 walk の順序二段 (索引型先行 → 記述型後追い)索引型 (SRS / ADR / research / glossary / test-cases) を先に歩き、 記述型 (architecture / vision) を後で追う。 要件索引型を脱した descriptive pack が engine フロンティア。
③ vision の扱い含む (段階3 architecture の後)記述型 2 例目として vision pack を suite に入れる (folio-c5r.4)。
④ constitution一律機械的に生成 + SRS との重複検出 → warning + folio 適用可否は人間constitution を生成するか否かを engine に判断させない (一律生成 = 冪等)。 生成物が SRS goals 等と重複していないかを検出し、 重複が多ければ人間に warning を出す。 重複の多寡から folio 適用可否を人間が最終判断する。 検出が clean でも「必要の証明」ではない。
⑤ 段階4 合格条件三層 (機械 floor / ceiling / 人間最終判断)floor = graph 双方向 + 重複検出、 ceiling = persona (gate I) + fidelity (gate J) + completeness (gate K)、 その上に人間の最終判断を必ず置く。

§11.1 哲学転換 — 「判断する engine」を作らない

論点④ で『engine が constitution の要否を判断する』案を退け、 constitution は一律機械的に生成することにした。 要否で生成可否を分岐させると同じ入力に別の出力を返し 冪等性を壊すうえ、 判断ロジックを正しく作り込むのも原理的に難しいからである。 その上で engine = 確実な生成器 + 機械的検出 (floor・冪等) / 要否の最終判断は engine に作り込まず人間に委ねる (ceiling・事後) という分担に合意した。 engine は生成した constitution が SRS と重複していないかを検出し、 重複が多ければ warning を出す (= 判断材料の可視化・黙って判断しない)。 ★重要な含意: 検出が clean でも「必要の証明」ではなく、 最終判断は人間である。 重複が多ければ『このプロジェクトは constitution 級の統治構造を持たない』と人間が読み取り、 folio をそのプロジェクトに適用しない判断をすればよい。 これは folio の 「floor 緑 ≠ 完成」 (機械 floor は『検査できた範囲が緑』) という教訓を doc-type の要否判断そのものへ適用したものであり、 judgment を engine の機能として作り込まない。

§11.2 constitution 必然性 = 統治構造の scale 依存

constitution が必然か人工的かは 統治構造 (governance) の有無 = project の scale で決まる。 folio 自身は複数 consumer を統べる META FRAMEWORK ゆえ constitution が必然である (既存の不変原則 14 条)。 一方 clinic は単一システムで、 constitution を立てると SRS goals と重複し人工的になる。 この対比を実証するデモ (clinic constitution を一律生成 → SRS との重複が検出される → 人間が不要〔= folio 不適〕と判断) は follow-up folio-c5r.2、 その基盤となる cross-doc 重複検出 lint は folio-c5r.1 で実装する。 constitution を統治構造の scale 軸で位置づける research note 化は folio-dxq が担う。 folio の constitution は read-only な写像 (翻訳) であり、 一律生成デモは clinic 側で行う。

§12. wq4 — fab-free floor の CORE substrate 硬化と「静的検査 / render-gate」責務境界

横展開 epic folio-bur (可視 echo pin = 「属性 pin ≠ 可視 pin / membership ≠ occupancy」を 7 pack へ pure-additive 硬化) の最終 ceiling が、 pack 層では塞げない CORE substrate (検査基盤) の fail-open を 3 件確定した。 pack-additive 制約 (core 無改変) を破る必要があるため別 epic folio-wq4 へ繰延し、 grill (2026-06-29・grounding-sweep wf_258cf2cd で地図補正) を経て対処した。 この epic は engine の検査基盤に初めて core 変更を入れる節目であり、 同時に 静的検査の責務境界を明文化する。

責務境界 (load-bearing): fab-free floor は 生成時点で DOM 文字列に存在する静的な捏造を検出する層である。 一方 render-time DOM 差替え (検証通過後に <script>innerHTML 等で genuine な決定・承認・章を丸ごと別物にすり替える) は静的検査では原理的に触れない別ジャンルで、 render-gate (gate F) の責務である。 両者を 1 epic に混ぜると、 (a) make_body で <script> も strip しようとして glossary の JSON-LD 用語抽出 (verify-glossary.sh) を壊す、 (b) 「make_body を直したから捏造検査は完成」と誤認し render-time 差替えが手つかずで残る、 の二方向の事故を招く。 ゆえに wq4 = 静的 substrate (make_body + occupancy)、 <script> render-time = 別 epic folio-4gz と切り分けた。

wq4 grill 論点決定要点
① epic scopeblocker 1 (make_body) + 3 (occupancy)。 blocker 2 (<script>) は別 render-gate epic へ carve静的検査層に閉じる 1・3 を束ね、 render-time の 2 を分離 (上記責務境界)。
② make_body 機構行範囲「削除」→ 最終形 = fail-closed scanner (genuine 不変条件の機械強制)sed '/<style>/,/<\/style>/d'<style> 同居行の実 DOM 捏造を巻き込み消去する支配的 fail-open だった (round-7 pin も再 open・単行 / 未閉じ <style> は EOF まで削除)。 当初 grill 決定は「中身のみ空化 (perl -0777)」だったが、 独立 ceiling が round 1 (単純 perl の comment / case / 未閉じ parser-differential)・round 2 (perl 手書き state machine の 属性値内 <style> / 不正 close 文法) と make_body parser-fidelity の whack-a-mole を 2 連続で実証した。 「regex / 手書きで rendering を忠実モデルする」arms race と判定し、 bounded-land 規律 (同テーマの新兄弟ベクタ反復 → STOP・user escalate) に従い user 判断で fail-closed 設計に転換した: rendering を完全モデルせず、 genuine 不変条件 (全 <esc() 済・<style>/<script>/comment は clean な既知形のみ) を単一パス scanner で機械強制し、 破る入力を 拒否 する (空 $BODY → 全 floor 欠落 FAIL + 診断・exit 3)。 完全性は構成的に担保 (genuine が narrow に shaped されている) ため rendering モデルの完全性証明に依らず arms race を停止できる。 commit 1489062 (空化+occupancy) → f508a1a (state machine) → ad28815 (fail-closed)。
③ occupancy global pinrole / en を global 占有 pin (複合式は繰延)従来は sign / grow 行 scope 内でしか数えず、 scope 外へ注入した偽 <span class="role"> (偽承認者) が素通った。 正当な置き場は approval span.role == |approval| (全 pack 共通) + SRS 固有 home (actor div.role / EARS legend en 4) のみと verified ゆえ、 global token 占有数を契約由来値に bind する。 EXEMPT 修飾 / badge の複合式 occupancy は false-FAIL リスク (dty の partial-enumeration 沼) ゆえ別 follow-up へ。
④ 回帰 gate (byte-identity の代替)assemble 無改変 proof + golden 全本 verify 再実行 + 敵対 + sandboxrule-of-three の「core git diff 空」proof は make_body (lib/) を変える wq4 では void。 だが make_body は assemble を触らないため再生成 HTML は依然 byte-identical (assemble 側の無料 proof)。 verify 側退行は golden 全本再 verify + 敵対 suite + sandbox で捕捉する。

メタ教訓 (ceiling-recursive-admin-self-certify の延長): folio-bur の ceiling-recursion は最終的に検査の substrate (core make_body) 層に到達した。 これは pack-additive 硬化の hard ceiling である ── 自己 mutation 検証 (pack に行を足す) は独立行注入ゆえ substrate trick を構造的に見落とす。 「floor 緑 = 検査基盤が健全な範囲で緑」であり、 基盤自体の欠陥は floor に映らない。 ゆえに substrate 修正は in-scope (pack) の land とは別 epic に切り出し、 独自の grill + 独立 ceiling + 回帰 gate を課す (bounded-land を scope 境界で適用する) のが正しい止め方である。

fail-closed land 時の final ceiling (round 3・wf_852e0730) が確定した 2 つの render-gate residual: fail-closed 転換は「<style> 空化経由の ADD 隠蔽」を構成的に封じたが、 final ceiling が設計の 受理域 (genuine と認めて処理する集合) の完全性に 2 つの seam を実証した ── (a) CSS content 捏造: <style> 中身空化が依拠する不変条件「style 中身=非描画」を CSS content: (::after/::before) が破り、 class を 1 個も足さず既存 .role/.en の pseudo-element に相乗りして捏造描画する (folio-2b8)。 (b) container OMISSION: well-formed な comment/script を拒否せず verbatim 受理するため、 必須要素を非描画コンテナで包むと $BODY に元バイトが残り floor 全 PASS のままブラウザが描画しない (folio-459)。 ★両者とも static floor では塞げない: 全 11 pack 実測で genuine が content: を 8〜12 回 (badge/legend)・<script> を mermaid (arch/rel/ver/spec) + JSON-LD (glossary 34) で正当使用するため、 ceiling 提案の「content: 拒否 / script 拒否」は genuine を壊滅 false-FAIL する。 genuine と捏造の区別には rendering が必須ゆえ、 これらは folio-4gz (script render-time DOM-swap) と同じ render-dependent fabrication residual class の新メンバーとして render-gate epic へ carve した (両 seam とも旧 sed make_body にも存在した pre-existing・wq4 regression でない)。 メタ教訓: fail-closed は「受理域を genuine だけに絞る」設計だが、 受理域の境界自体に render-dependent な穴が残りうる。 そして ceiling の提案 fix も over-claim しうる ── 本 ceiling は SRS のみで「static 構成的封鎖可」と一般化したが、 admin の全 pack grounding がそれを反証した (ceiling-recursion の双方向性: admin は自分の gate 修正を self-cert しないが、 ceiling の提案も実測で裏取りする)。