第4章本文と規範文の書き方

本文は文書の知識層である。規定の趣旨・解説・図表を自然言語で書く。ただし、法的拘束力を持つ 規範文は知識層と峻別し、原文を改変せず保持する。本章はこの区別を中心に、見出し・図表・ルビの書き方を定める。

4.1 規範文と解説文を峻別する

仕様書の本文には、性格の異なる 2 種類の文が混在する。

両者を視覚的・構造的に区別する。規範文は §4.5 の byte 保持ルールに従い、解説文は通常の Markdown で書く。

よくある誤り: Word から変換すると、規範本文が引用ブロック（>）になっていることがある。仕様書本文は「引用」ではなく「規定」なので、引用記法を規範文に用いてはならない。

見出しレベルは歯抜けにせず連続させる（H1→H2→H3）。
章節番号は自動採番に頼らず、本文に明示する。番号体系は原本（元 PDF・告示）と平仄を合わせる。例: ## 1 管理項目 → ### 1.1 住民データ → #### 1.1.1 ...。
機能 ID 等の参照キーになる番号は、勝手に振り直さない。既存の正本番号があればそれを温存し、計算による補完は番号のない見出しにのみ適用する。

理由: 章節番号や機能 ID は他文書からの参照キー（spec_ref 等、第6章）になる。自動連番に委ねると改訂のたびに番号がずれ、参照が壊れる。番号は人間が正本に明示し、機械はそれを温存する。

構造化された規定（項目の型・コード値・条件）は表ではなく payload で書く（第5章）。表は人間の読みやすさのための補助とする。
表は GitHub 形式の Markdown 表（| ... |）で書く。pandas の to_markdown() ダンプ（Unnamed: 0・ NaN・空行/空列）をそのまま貼らない。
数千行に及ぶ巨大な表は本文に焼かず、CSV を添付してストリーミング表示に委ねる（第7章）。

図は手書きのバイナリ画像ではなく、テキスト記法から生成することを第一とする。生成元テキストが本文に残るため、差分・レビュー・再生成ができる。

住民記録のデータモデル（er.md）は、グループ構成表と主キー共有から推定した 23 エンティティの関係を Graphviz DOT で記述し、rankdir=LR でビルド時に SVG 化している。

法的拘束力を持つ規範文（告示別表の機能要件欄、法・省令の条文）は、装飾・語順変更・正規化を一切加えず、原文を byte 単位で保持する。

記法: ```text フェンスに原文をそのまま格納する（```yaml ではない）。**強調** 等の Markdown 装飾を混入させない。
理由: 告示は法的正本であり、テキスト正本からの projection が配布告示と byte 一致することを CI で検証する（第6章・第9章）。装飾の混入や語順の変更は不一致として検知される。
適用範囲: 規範文のみ。趣旨・要件の考え方・検証ルール等の技術補足は通常の Markdown／payload でよい。

日本人住民について、以下の項目を管理（※）すること。
※「管理」とは、データの設定・保持・修正ができることをいう。
（シート「項目詳細一覧」を参照）

行政文書特有の難読語・固有名詞には、必要に応じてルビを付す。ルビ記法は SSG が <ruby> へ描画する。過剰なルビは可読性を下げるため、初出や難読箇所に限る。