constitution は scratch 化以前に作成され、 不変原則と「当時想定した file/dir 配置」 が混在している。 P-2/P-3/P-11 は constitution / rules / folio-self-spec という folio 自身の可変ファイル名を本文に列挙し、 P-7 は spec/ decisions/ changes/ research/ という dir 名を列挙する。
結合の決定的証拠: P-2 の inline ai-rationale aside は、 architecture-rules.html → rules.html+folio-self-spec.html の file split (ADR-0001 v3) だけが理由で PATCH bump を強いられたことを自認している。 framework の不変原則が、 下流成果物の rename で書き換えを要する = 不適切な結合。
folio 自身の portability test (P-3「別 AI platform へ移植する際に書き直しが要れば HOW 漏れ」) を 1 段上で適用すると、 「layout 再編で constitution の書き直しが要れば layout 漏れ」。 現状の constitution はこの test に落ちる。 一方、 domain 構造 (design intent / decision / exploration) は framework の不変語彙であり file split では不変。 → 固定すべきは構造、 剥がすべきは instance 名と bootstrap prefix。
加えて 2 つの欠落が判明した: ① changes/ 領域 (P-7 の 4 番目) は OpenSpec の「現在挙動 SSoT + 未適用 delta staging」 由来だが、 folio の P-1 (spec = 未来理想 anchor) では spec を直接編集すればよく専用 staging dir が不要。 review = git PR / why = ADR / trace = delta marker が既に担い、 X1〜X3 全 spec 編集で changes/ は未使用だった。 ② 実装 (HOW) とその verification の所在・WHAT との traceability が原則として明文化されていない (verification.html spec のみ)。
本 ADR は X4 (試作卒業) の独立した先行タスクとして、 constitution を layout 不変化し X4-0 (layout 確定) を unblock する amendment を確定する。 詳細文面ドラフト + 影響範囲実測 + phased plan は scratch/constitution-x4-amendment-proposal.html (planning doc) に記録、 本 ADR がその governance 記録。
具体ファイル名・dir 名の列挙をcategory 語へ置換する (semantic 不変、 portability test 等の核は verbatim 保持):
(constitution / rules / folio-self-spec) + changes proposal 列挙を削除し「全 design-intent 文書」 へ。 Markdown/YAML 例外は「外部 platform 規約 file」 (例示) + 確定列挙を self-spec §2 / rules §3 へ委譲。spec / constitution / rules / folio-self-spec 列挙を「design-intent 文書」 へ。 P-11 の .claude-plugin/ → 「implementation harness」、 CLAUDE.md → 「AI-agent instruction file」。changes/ proposal、 decisions/ ADR、 research/ に分離」 → 「decision record (ADR)、 exploration note、 version control の review に分離」。changes/ 起案 + archive/ 移動を使わない手続きへ (proposal は version control branch 上、 git 履歴が archive を兼ねる)。 §7 Citations の OpenSpec 言及は「changes/ lifecycle (本 framework は P-1 のため不採用)」 と注記。「実装 (HOW) とその executable verification は design-intent 空間の外に置く (P-3/P-11 と整合)。 WHAT は安定した requirement ID を介して verification に束縛され、 この ID 束縛が WHAT↔HOW の SSoT link となる。 verification は (a) spec 適合性 (framework 提供・普遍) + (b) 実装適合性 (project 固有) の 2 層を含む。 requirement ID からの trace は machine-navigable であること。」 番号は append (renumber せず、 P-8〜P-12 の cross-ref + 既存 frozen ADR 参照を保護)、 tier 帰属は分類で定義。
constitution が固定するのは domain 構造の意味 (P-7 + P-13) のみで、 root path・具体 dir 名は含めない。 物理 location (architecture/spec/ か scratch/specs/ か .folio/spec/ か) は binding (self-spec §2 / rules §2 / folio.config.yaml の spec_path) が担い、 override 可能 (self-spec §8.2 の既存機構を維持)。 → constitution は layout 不変、 X4 migration は binding の付け替えのみ。
P-13 新設 (原則追加 = §5 上 MAJOR) + P-7 semantic 変更が dominant。 1.0.0 未満の boundary 緩和に従い 0.5.0-draft (0.x の MAJOR 級 bump)。 適用 scope は plugin.json + constitution.html のみ。 他 core 文書 (rules / self-spec / README) の整合 fix は PATCH 級で version 据え置き、 X4-0 rework 時に 0.5.0 へ align。
| 案 | 採用可否 |
|---|---|
| 案 A (採用): 抽象化 (脱-instance) + 3-domain + P-13 新設。 構造は固定・location は override 可 | 根本原因 (結合) を除去、 layout 不変、 既存 delegation pattern (§9 Bindings) と一貫 |
| 案 B: architecture/ layout 名に書き換え (具体化) | 却下 — 別 layout に再結合し次の再編で再び壊れる。 X3 現在は存在しない layout を記述することになる |
| 案 C: changes/ を残す | 却下 — OpenSpec 由来の staging は P-1 (未来理想 anchor) では不要。 git PR + ADR + delta marker が機能を担い、 経験的に未使用 |
| 案 D: P-13 を新設せず P-11 を拡張 | 不採用 — verification + REQ-ID traceability は HOW 隔離 (P-11) と別の積極要件。 独立原則として明示性が高い (user 選択) |
| 案 E: 番号を renumber して tier 連続を保つ | 却下 — P-8〜P-12 の全 cross-ref + frozen ADR 参照が壊れる。 append + 分類定義で回避 |
| 案 F: self-spec §2 / rules §2 の layout rework も本 amendment に含める | 不採用 — layout rework は X4-0 そのもの。 constitution を先に layout 不変化する方が安全 (scope 分離) |