ADR-0003 は folio CLI の subcommand として init / validate / inventory / prime / fix を WHAT 列挙し、 「引数仕様等の HOW は .claude-plugin/ 実装時に確定」 と明記した。 ADR-0022 + X4-C (ADR-0023) で canonical layout が確定・実体化した今、 folio init = その canonical layout を consumer (Layer 1) project に scaffold する CLIとして scope を確定する (X4-A)。
init は folio core mission「architecture/ 構造を作成し維持する」 の「作成」 半分を担う (validate/fix が「維持」)。 user 承認は本 session の AskUq (標準 seed + ADR-0024 起票) で取得済。
folio init [<dir>] (省略時 cwd) に以下を生成する (rules §2 consumer layout):
<consumer>/
├── folio.config.yaml # 生成 (§2.5 defaults)
├── architecture/
│ ├── spec/
│ │ ├── README.html # cluster entry point (P-6 MUST)
│ │ ├── constitution.html # project 固有 starter (folio core 継承宣言 + 固有 placeholder)
│ │ └── overview.html # project overview template
│ ├── decisions/
│ │ └── README.html # cluster entry point (P-6 MUST)
│ └── research/
│ └── README.html # cluster entry point (P-6 MUST)
└── verification/ # HOW-test dir (.gitkeep)
assets/ は consumer layout (rules §2) に含まれないため init は生成しない (mermaid 等を使う consumer が任意で追加)。 CLAUDE.md / README.md 等の platform binding file も生成しない (consumer の platform 規約に委ねる、 標準 seed の範囲外、 §4 リッチ案 不採用)。
seed する architecture/spec/constitution.html は通常の conforming JSON-LD (@context object + @id + @type) を持つ project 固有 spec として生成する。 これは folio 自身の frozen constitution (FolioConstitution schema、 string @context、 scan 除外 = ADR-0023) とは別物: consumer の constitution は Layer 1 の通常 spec で、 inventory/validate の scan 対象に入り得る。 starter は「folio Layer 0 core を継承し、 project 固有原則をここに追記する」 旨の宣言 + placeholder を含む。
init は idempotent: 既存 file は上書きしない (preserve)、 欠損している file / dir のみ生成する。 既存 project への再 init や部分的に欠けた layout の補完に安全。 上書きが必要な場合は user が明示削除してから再 init する。
生成された skeleton は folio validate が clean (exit 0) である MUST。 すなわち seed file 群は (a) 各 cluster が README.html entry point を持ち orphan を出さない (P-6)、 (b) 全 JSON-LD relation @id が resolve する (link-integrity)、 (c) JSON-LD structural (@context object + @id + @type) を満たす。 folio init && folio validate が pass することが init の品質ゲート (REQ-VER-014)。
rules §2 schema の default を生成する:
folio_version: "^0.5" # 現 folio major (0.5.x) の semver range
spec_path: "architecture/spec/" # canonical default (userConfig で override 可)
caller_marker_env: "FOLIO_ARCHITECT_CONTEXT"
caller_marker_value: "folio-architect"
review_model: "opus" # optional
init の conformance は verification §3.6 REQ-VER-014 + scenarios/init-scaffold.yaml (cli-golden) で検証する: init を temp root に実行 → (a) exit 0、 (b) 生成 tree の file 集合 + folio.config.yaml 内容を golden 比較、 (c) folio validate --root <tmp>/architecture が clean。 init は tree (複数 file) を生成するため、 既存 cli-golden harness (単一 output_file/stdout) の拡張が要る可能性があり、 その HOW は SPAWN (feature-dev) が実装時に確定 (harness 拡張 or init の stdout manifest + 後続 validate の組合せ)。
folio init 一発で canonical layout + folio.config.yaml を得るconstitution.html は通常 spec schema (scan 対象) で、 folio 自身の scan 除外 constitution とは別扱い (§2.2)| 案 | 採用可否 |
|---|---|
| 標準 seed (採用): 最小 + starter constitution + overview template | すぐ spec を書き始められ、 rules §2 consumer layout に最も忠実 (AskUq) |
| 最小 seed: dirs + config + cluster README のみ | 不採用 — validate-clean な空箱は得られるが、 constitution/overview を user が一から書く負担。 標準が初動を楽にする (AskUq) |
| リッチ seed: + CLAUDE.md / README.md / sample ADR | 不採用 — platform binding まで生成すると init の責務が広がり上書きリスク増。 platform 規約は consumer の自由 (AskUq) |
| REQ-INIT-* family を新設 | 不採用 — CLI subcommand の検証 REQ は REQ-VER-010(inventory)/012(prime)/013(validate) の系列。 init も REQ-VER-014 として §3.6 に追加し convention 統一 |
| 非 idempotent (常に上書き) | 不採用 — 既存 project の破壊リスク。 idempotent preserve が安全 (§2.3) |
bin/folio dispatch に init) case + folio_cmd_init、 seed template (starter constitution / overview / cluster README / folio.config.yaml)、 scenarios/init-scaffold.yaml + golden、 生成 skeleton の validate-clean + sandbox GREEN を acceptance とする。