folio 文書型 被覆完全性 監査 (doc-type coverage audit)

v1.0.0 · status: active · 北極星 folio-7wn の完全 doc-suite 被覆 roadmap の SSoT (探索領域・後段で正式化)

§0. 要旨

本書は 2026-06-24 に実施した多エージェント監査 (doctype-completeness-audit / wf_8e16a043) の design-of-record である。問い = 「folio 文書規律エンジン (C) は『任意プロジェクト向けの完全な文書一式』を生成する能力の全体像で、本当に self-spec (architecture description) 『だけ』が欠けているのか」

★中心的発見: folio engine は完全 project doc-suite を構成する canonical 約 17 の文書型のうち 5 種しか生成できない (SRS / ADR / research / principle / spec=rules)。self-spec (architecture description) は最初かつ最も paradigm-breaking な穴だが唯一ではない。本書はその全 gap を優先度付きで SSoT 化し、埋める roadmap を定める。実装追跡は bd epic folio-c5r (post-B6 完全 doc-suite 被覆 roadmap)。

§1. canonical doc-type カタログ × folio 被覆

完全な project documentation suite を構成する canonical 文書型を業界標準 (ISO/IEC/IEEE 42010 / 29148 / 29119, arc42, C4, Diátaxis, ADR, RFC, IEEE 1016 等) に接地して体系化し、folio の現 pack 被覆と厳密照合した。structure_kind = requirement-indexed (離散正規単位を索引) / descriptive (prose+図+表 主体) / hybrid。被覆 = covered (生成可) / partial (machinery のみ) / gap (pack 無)。

doc-typestructurecode 依存必須folio 被覆pack / 備考
Glossary / 用語集req-indexedagnosticpartialmachinery は lib/ に在り (vocabulary.yaml / .term)・standalone pack 無。promotion が最安 keystone
Vision / Charterdescriptivecode-less可gap叙述目標型・research と一部重複するが別軸
Constitution / Principledescriptivecode-less可coveredprinciple-pack (instance#4・baseline-diff gate)
Consumer Rules / Standardshybridagnosticcoveredspec-pack (rules=instance#5・dual-audience round-trip)
Requirements / SRSreq-indexedagnosticcoveredsrs-pack (EC + clinic・EARS 5型 + RTM)
Architecture Descriptiondescriptiveagnosticgap (P1)★最重要・要件索引型を脱した初の descriptive doc-type。self-spec の型。専用 pack 要 (folio-5uu)
ADR / 設計判断記録req-indexedagnosticcoveredadr-pack (justifies→SRS 後方照会)
Research / 探索記録descriptiveagnosticcoveredresearch-pack (approaches→ADR 前方照会)
Interface / API Spechybridcode固有gapprose frame + indexed endpoint/error 表
Data / Domain Modelhybridagnosticgapentity catalog (indexed) + domain 図 (descriptive)
Test Cases / Specreq-indexedcode固有gap (P2)RTM native・SRS↔test ループ閉・machinery 再利用で安価
Verification / V&V Reportreq-indexedagnosticpartialRTM machinery は core に在るが standalone V&V doc pack 無 (folio-self の verification.html=検証 contract spec と別物)
Risk Registerreq-indexedcode-less可gapindexed-row log ≈ ADR 形状・安価
Roadmap / Release Plandescriptiveagnosticgap時系列 milestone
Operations Runbookhybridcode固有gapprocedural (順序付き step) = RTM も flat-prose も適合しない第3の structure sub-kind
Change Log / Release Notesreq-indexedagnosticgapversion-keyed entry log・安価
Index / README / doc mapdescriptiveagnosticpartialfolio build が graph から derive (readme-index/inventory machinery)・authoring pack でない

§2. gap_set — 穴の二分と優先度

gap を質で二分すると engine の真のフロンティアが見える:

優先度: P1 = architecture-description, glossary。P2 = test-cases, vision, interface, data-model。P3 = risk, changelog, operations, roadmap, standalone V&V。

§3. roadmap (post-B6・bd epic folio-c5r)

順序の核心 = architecture (最難) を最後に、安い keystone (glossary) を先に

  1. 段階1 (folio-8f0・本書): gap 全体像の SSoT 化。
  2. 段階2: glossary pack (folio-1uc・最安 keystone・suite walk の cross-doc 整合 SSoT) + test-cases pack (folio-uvt) + suite demo 設計 grill (folio-yzv・clinic 母体)。indexed-heavy 一式 (SRS+ADR+research+glossary+test-cases) で suite demo を architecture 前に先行実証できる。
  3. 段階3: architecture-description 汎用 pack (folio-5uu・最難・grill + grounding-sweep 必須)。folio-self-spec を instance#1 として B6 self-dogfood と同一成果物で回収。
  4. 段階4: clinic suite 統合 walk (folio-rqj・cross-doc graph 双方向 fail-closed + 非エンジニア persona walk + fidelity ceiling 横断)。単一文書 walk が検査しない suite 規模の一貫性を検査する。

suite demo (段階2/4) の構成 = glossary / vision / architecture / SRS / ADR / research / test-cases / README。constitution は scale 依存 (clinic 単一チームでは optional)。

§4. コード無しプロジェクトへの射程 (folio-dxq へ)

核心命題 (verified): folio の文書規律は設計上すでにコード非依存。core の照会 graph が使う抽象ロール集合 GRAPH_ROLE_ALLOWLISTclaim|rationale|exploration|principle|verification|implementation で「コード」概念を含まない。「実装=コード」は SRS-pack 固有の写像にすぎず、ADR-pack は implementation を「実装方式 (非コード)」へ既に写像済。

規律ごとの translate 度: dual-audience=high (混在読者=専門家 vs 市民/議員/監査人 はコード無しドメインで常態・価値増)、canonical-name=high、declarative=high (法令/標準/憲章は本来 declarative)、P-7 3-domain=high、RTM=high (政策目標→施策→根拠→評価指標)、EARS=medium-high (規範型で high・記述型で low)、HOW-outside=high (再定義要: 「実装」が施行/運用/建造になる)。

橋頭堡 = principle/constitution pack (要件索引型を脱した唯一の実証済 pack・公共政策の基本方針/ガバナンス憲章は principle 型・既に gate I 達成)。第二 = architecture-description pack。最大の不確実点 = 純記述型 doc-type (EARS が乗らない) の floor をどう厚くするか (ceiling 依存で機械保証強度が落ちる)。詳細は folio-dxq の research note に展開する。

§5. 参照