第9章 適合性と検証
テキストを正本とする以上、その正しさは機械で検証できなければならない。本章は、文書が本書フォーマットに 適合するための条件と、それを検証する手段を定める。
9.1 適合性の段階
適合性は表現力の三層（第1章 §1.3）に対応して段階的である。文書はその性格に応じて達成できる段階まで 適合する。
| 段階 | 条件 | 対象 |
|---|---|---|
| 1. 索引適合 | 先頭に frontmatter を持ち、必須 3 キー（type／title／source）と type enum・各パターンを満たす | 全文書 |
| 2. 正本適合 | payload フェンスが当該 type のメタスキーマ（JSON Schema）に適合する | payload を持つ文書 |
| 3. 規範保持 | 規範文が ```text フェンスで byte 保持されている | 規範文を持つ文書 |
| 4. 参照解決 | URN・authority／renders_to／spec_ref の参照先が解決可能 | リンクを持つ文書 |
| 5. projection 一致 | 生成した告示別表行が配布告示原本と byte 一致する | projection を持つ文書 |
段階 1 は全文書の最低条件。段階 2〜5 は型付き正本（gov- 系）で順に求められる。
9.2 検証の手段
| 段階 | 検証器 | 実行 |
|---|---|---|
| 1 索引適合 | 文書プロファイル検証器 | bun run validate --doc <ファイル...> |
| 2 正本適合 | payload 検証器（JSON Schema） | bun run validate <ファイル...> |
| 3〜5 | 規範保持・参照解決・round-trip ビルド検証 | 後続実装 |
索引適合・正本適合は CI ゲートとして用いる（不適合で exit 1）。新しい仕様書を起こしたら、まず
--doc で全ファイルが索引適合することを確認する。
9.3 二重適合の例（住民記録 基本データリスト）
住民記録の基本データリストは、frontmatter が索引適合（mrlgss-doc/0.1）し、かつ payload が正本適合
（chimata-okf/0.1 の schema.payload）する二重適合を機械保証している。コード一覧（37 コード）も
vocab.payload に適合する。テキスト正本が「検索できる索引」と「プログラムが食える正本」を同時に
満たす状態である。
9.4 ビルドによる目視確認も検証の一部
機械検証（スキーマ適合・型検査・テスト）が通っても、見た目が崩れていれば未完とみなす。静的サイト （SSG）を生成し、実ブラウザでレンダリング結果を目視確認することを検証工程に含める。
- 巨大表が表示不能になっていないか、図（SVG）が判読可能か、PUA グリフが豆腐化していないか、章節番号が 原本と平仄しているか、サイドバーの章遷移が機能するか、を確認する。
- 確認には静的サイトを起動して実ブラウザで開く（例: 生成物ディレクトリで簡易 HTTP サーバを立てる）。
9.5 適合チェックリスト（起草者向け）
新しいテキスト正本を起こすとき、次を確認する。
- UTF-8（BOM なし）・LF で保存した（第7章）。
- 先頭に frontmatter があり、
type／title／sourceを持つ（第3章）。 - 先頭ゼロのコード・版番号・予約語を引用した（第3章・第5章）。
- 1 概念 = 1 ファイル、パスが概念の所在を表す（第2章）。
- 章分割文書は
index.md＋連番章ファイル、H1 始まり、見出し連続（第2章・第4章）。 - 規範文と解説文を峻別し、規範文は
```textで byte 保持した（第4章）。 - 型付きデータは payload に書き、型記法・条件付き必須を正しく表した（第5章）。
- 識別子（機能 ID・項目 ID・URN・章節番号）を温存し、参照を壊していない（第6章・第8章）。
- 文字は行政事務標準文字に準拠し、PUA を生で埋め込んでいない（第7章）。
bun run validate --docで索引適合、payload があれば正本適合を確認した。- SSG を生成し実ブラウザで目視確認した（§9.4）。