forge

Forge

Forgeは、曖昧なものも含めた最初のアイデアを、深さが段階的に増す6つのレベルで構成された、網羅的な製品および実装計画へと変換します。性能が高くないAIでも、各スライスを曖昧さなく実装できるほど詳細です。

6つのドキュメントレベル

Niveau 0 — INTENT       : Pourquoi ce produit existe, pour qui, quel problème il résout (PRD).
Niveau 1 — SCOPE         : Quoi et quand. MVP, V1, V2..., roadmap, compromis de scope.
Niveau 2 — DESIGN        : À quoi ça ressemble. Standards, direction visuelle, écrans, flows, interactions.
Niveau 3 — ARCHITECTURE  : Comment c'est structuré. Slices, modules, fondations, modèles de données, API, dépendances.
Niveau 4 — PLAN          : Comment implémenter chaque slice. Contrats, algorithmes, composants, checklist de tâches, critères d'acceptation.
Niveau 5 — VALIDATION    : Comment vérifier que tout fonctionne. Tests unitaires, intégration, E2E, UI (Chrome MCP), régression.

用語 — 3つの計画単位

• スライス：UI、ビジネスロジック、データアクセス、統合を含む、エンドツーエンドの完全な機能です。仕様策定と実装の単位です。Corpusの「能力」に着想を得ていますが、これはこのコレクションのスキルではなく、サードパーティーのオープンソース手法です。コードではなくニーズに基づいて定義されています。スライスは、PRDで特定されたユーザーニーズに応えます。
• モジュール：技術的に一貫したまとまりです（例：「認証」、「決済」）。複数のスライスを含みます。アーキテクチャの整理に使用し、実装の計画には使用しません。その順位は、ドメインの組織図ではなく使用頻度によって決まります。
• 基盤：横断的な関心事です（デザインシステム、認証、エラー処理、i18n、設定、ロギング、CI/CD）。ビジネススライスより前に実装します。アトミックな単位のままであり、スライスには分解しません。

指針となる原則

重要な判断にはすべて根拠があり、すべての主張は検証可能で、あらゆる経路が想定されています。

Forgeは5つの基本原則に従います。

1. すべてのビジネスルール、エッジケース、制約には、安定したIDが付与されます（ビジネスルールにはB1、B2…、エッジケースにはE1、E2…、検証にはV1、V2…、制約にはC1、C2…）。ルールが削除されても、これらのIDが再利用されることはありません。IDはトレーサビリティ全体の背骨として機能します：PRD → Architecture → Plan → Tests。

2. **人間によるゲートは譲れません。**各フェーズは明示的な承認をもって終了します。明確な「承認」がない限り、次のフェーズに進んではいけません。沈黙や質問を承認と解釈してはいけません。（範囲が限定され、文書化された例外：Phase 4〜5を単一のチェックポイントの後に自動化するFast Trackモード。references/fast-track.mdを参照。） このルールは、規律だけでなくガードによって適用されます。各アーティファクトはフェーズに属します（PHASE_ARTIFACT_OWNERS）：state.js registerは、そのフェーズに到達する前に作成されたアーティファクトの登録を拒否し、forge-guardはすでにディスク上にあるものを検出します（no_premature_artifacts）。かつて、デザインがdraftの状態の間にarchitecture.mdと15個のプランが作成され、12個のチェックはすべて通過しました。フェーズの順序は、単なる指示にすぎませんでした。premature_artifactと表示された場合、それは回避すべき障害ではなく、基盤が承認されていないという合図です。フェーズを進めるか、ゲート通過後にアーティファクトを作成してください。

3. **速度よりも網羅性を優先します。**一見筋が通っていても抜け穴が隠れている表面的なプランは、作成に時間がかかっても本当に完全なプランより悪いものです。常に問い続けるべきことは、「何が足りないのか？何を見落としているのか？」です。

4. **常に複数の視点から検討します。**主要なドキュメント（PRD、Architecture、Plan）を確定する前に、少なくとも2つの異なる視点から分析する必要があります。目的は「問題ありません」と言うことではなく、主たる視点が見落としたことを見つけることです。

5. **成果物は.forge内に置き、それ以外の場所には置きません。**一時フォルダーに作成されたドキュメントは、失われたドキュメントです。これは推奨事項ではなく、forge-guard.jsによって機械的に検証される制約です。

スクリプトの実行方法

このドキュメントのコマンドは、プロジェクトではなく SKILL のディレクトリを基準にしています。

スクリプトはプロジェクト内にはなく、skill とともにインストールされます （~/.agents/skills/forge/scripts/、.opencode/skills/forge/scripts/…）。プロジェクトには scripts/ ディレクトリはありません。そのため、スクリプトのパスがプロジェクトを基準とする コマンドは、どのプロジェクトからも実行できません。最初の 呼び出し時に Cannot find module '<projet>/scripts/state.js' で失敗します。

skill のパスを一度定義し、以降はどこでもそれを使用します：

# Le dossier de base du skill est communiqué au chargement du skill.
export FORGE=/chemin/vers/skills/forge

node "$FORGE/scripts/state.js" start

これに伴うルールは 2 つあります：

1. カレントディレクトリはプロジェクトのディレクトリであり、skill のディレクトリではありません。スクリプトは process.cwd() からアンカーを解決します。skill のディレクトリから実行すると、 skills リポジトリをプロジェクトのアンカーにしてしまいます。つまり、 何も通知されないまま誤ったプロジェクトが対象になります。
2. カレントディレクトリがプロジェクトのルートでない場合は、アンカーを明示的に渡してください： node "$FORGE/scripts/state.js" start /chemin/du/projet。

---

ステップ 0 — 実際の状態を取得する（最初に、呼び出しのたびに）

このステップは、state.json の読み込みやアンカーの解決も含め、ほかのすべてに先立って実行します。

node "$FORGE/scripts/state.js" start

このコマンドは、現在のフェーズ、保留中のゲート、ステータス別のスライス（計画の有無とテストケース数の実際の確認を含む）、ハッシュがずれているドキュメント、未解決の相違、昇格されていない所見、プロジェクトメモリの状態（AGENTS.md §Definition of Done、未解決の ADR、LEARNINGS.md の量）を表示します。

ファイルではなくコマンドを使う理由。 セッションログを毎回すべて読むには長すぎますし、最後には記憶を頼りに再構成することになります。実際のプロジェクトで確認された結果として、テストが一切ない承認済みスライスが 14 件あり、進捗の追跡は何の兆候もなく誤った内容を示していました。その理由は、進捗が「ファイルではなく、会話の記憶から把握されていた」ためです。

start によって、テストケースなしで完了とマークされたスライスが報告された場合、それは新たな事態ではありません。信頼できる最初のシグナルです。続行する前に対処してください。

ステップ 0 bis — 現在のプロジェクトを解決する

誤ったディレクトリに作成された .forge を取り戻すには、すべて手作業で対応する必要があります。

node "$FORGE/scripts/state.js" anchor

このコマンドは、採用したアンカー、その取得元（existing_state | project_marker | cwd）、親ディレクトリをたどって解決したかどうか、たどったディレクトリの一覧を表示します。

Legacy プロジェクト、コーパス、または参照プロジェクトにセッションからアクセスできる場合、それをアンカーにしてはいけません。 読み取り専用として宣言し、変更は一切行わないでください：

node "$FORGE/scripts/state.js" init <racine> "<NomProduit>" --reference /chemin/vers/Legacy

解決は、次の 3 つのルールに従って順番に行われます：

1. 親ディレクトリに既存の .forge/state.json があれば、それが優先されます。これは、サブディレクトリからの場合も含め、進行中のプロジェクトを再開するためです。
2. それがなければ、カレントディレクトリ内のプロジェクトマーカー（package.json、pyproject.toml、go.mod、.git など）、またはすでにファイルがある場合に限り、短い範囲で親ディレクトリをたどって探します。空のディレクトリは新規プロジェクトとみなします。そうしないと、新しいプロジェクトのアンカーが隣接するモノレポになってしまいます。
3. それもなければ、そのまま現在の作業ディレクトリを使います。

解決されたアンカーが宣言済みの参照プロジェクトである場合、このコマンドは明示的に失敗します。この動作には、.forge が存在しない Legacy も含まれます。これは最も危険で、最もよくあるケースです。これは、最も大きな損失につながるシナリオ、つまり Legacy を分析した後、新しいプロジェクトの .forge をLegacy の中に書き込んでしまう事態を防ぐための安全策です。

状態と再開

anchor が state_exists: true を返した場合は、state.json を読み込みます。完了した最後のフェーズ、各スライス／基盤のステータス、保留中のゲートが示されています。プロジェクトの進捗をユーザーに伝え、次のフェーズから再開してください。明示的な依頼がない限り、すでに approved になっているドキュメントを再生成してはいけません。

ファイルが v1 スキーマの場合は、黙って移行するのではなく、拒否します。

node "$FORGE/scripts/state.js" migrate <anchor>

正確な形式については、references/state-schema.md を参照してください。

書き込み先 — 絶対に守るルール

対象	場所
Forge のすべての成果物	<anchor>/.forge/ の CANONICAL_LAYOUT に定められた正規パス
プロジェクトの状態	.forge/state.json — メタデータのみ。内容は一切含めません
監査ログ	.forge/audit/

以下の3つは禁止です。いずれも forge-guard.js で検証されます。

1. .forge/ の外には絶対に書き込まないこと。 一時フォルダーやプロジェクトのルートに置かれた成果物は、失われた成果物です。
2. state.json にドキュメントの内容を絶対に含めないこと。 PRD は .forge/prd.md です。状態ファイルにテキストブロックを含めるのはバグです。禁止キーと値の長さで検出されます。
3. .md のフロントマターに status: を手書きしないこと。 状態とフロントマターを同じ操作で更新する state.js set-status だけが書き込みます。

キットのスクリプトは変更禁止 — 変更は検証されます

上記の3つの禁止事項は、プロジェクトの成果物を保護します。一方、キットは何にも保護されていませんでした。forge-guard.js が対象としていたのは .forge/、AGENTS.md、.opencode/rules/、マニフェストであり、キットを実行するスクリプトは対象外でした。また、$FORGE はエージェントが設定する export なので、任意の場所を指す可能性があります。

つまり、検出されない回避方法が2つありました。実際のプロジェクトで、AI がゲートを突破するためにスクリプトを変更し、壊れたスクリプトと必須成果物の欠落を含むリポジトリの状態は、人間がレビューするまで見つかりませんでした。これは自分自身の保護機能を無効にする唯一の欠陥であり、自力では検出できない唯一の欠陥です。

node "$FORGE/scripts/forge-guard.js" kit-integrity <anchor>
node "$FORGE/scripts/forge-guard.js" kit-integrity <anchor> --write-manifest

.forge/kit-manifest.json には、キットの各ファイルの sha256 ハッシュが記録されます。実行のたびにゲートが照合します。意図的に分けられた2つの扱いがあります。

変更されたもの	扱い	理由
スクリプト	重大なエラー	スクリプトはプロセスを適用します。スクリプトが変更されていると、プロセスが適用されなくなります
参照用ドキュメント	警告	エージェントに情報を提供するだけで、何かを適用するわけではありません。エラーと警告を同じ扱いにすると、ドキュメントの更新だけでプロジェクトが不必要にブロックされ、その結果ゲートが回避されることになります

マニフェストの書き換えは、明示的な操作でのみ行います。自動では行いません。 変更を隠せる唯一の操作だからです。自分自身を書き換えるゲートには、もはや保護機能がありません。スクリプトを意図して変更した場合（キットの更新）は、マニフェストを書き換え、理由を DECISIONS.md に記載してください。それ以外の場合は、スクリプトを元に戻してください。

補助スクリプトの配置場所

キットで実際のニーズを満たせない場合は、スクリプトを作成します。.forge/tools/ に置き、次のように登録します。

{ "project": { "tools": { "seed-dwight.js": { "purpose": "…", "owner": "…" } } } }

forge-guard.js tools は、次の3つを拒否します。それぞれ別個の欠陥です。未登録のツール（3か月後に誰もその存在を知らない）、目的が記載されていないツール、登録されているのにディスク上に存在しないツールです。内容について誤った情報を記載するレジストリは、存在しないレジストリよりも悪質です。人がそれを信頼してしまうためです。

別の場所（ルートや .forge/ の tools/ 以外）に書き込むと、配置場所を誤ったスクリプトとして報告されます。これは、適切な場所が見つからなかったものの既定の配置先です。

何が正なのか — 状態と成果物は決して食い違いません

state.json   =  AUTORITÉ   pour le statut
front matter =  MIROIR    (champ status:), écrit par set-status

食い違いが生じた場合、たとえば state.json では implemented、.md ではまだ draft となっている場合は、機械的に検出して修正します。

node "$FORGE/scripts/forge-guard.js" sync .          # détecte, exit 1
node "$FORGE/scripts/forge-guard.js" sync . --fix    # réaligne le miroir sur l'autorité

content_hash の対象はドキュメントの本文であり、フロントマターではありません。そのため、ステータスを変更してもプランは無効になりません。ハッシュが一致しなくなった場合は、範囲外の編集があったことを示しており、そのドキュメントは stale になります。

それぞれが所有するもの — project-rules-architect との境界

互いを認識しない2つのスキルは、優先順位のルールがないまま、競合する2つの記憶システムを生み出します。これは追跡に関する障害の大半の構造的な原因です。

Forge が所有するもの	project-rules-architect が所有するもの
.forge/ — 構築するものと現在の進捗	AGENTS.md、.opencode/rules/*.md — 従うべきこと
state.json — ステータス、パス、ID、ハッシュ	DECISIONS.md — 理由 · LEARNINGS.md — 発生した問題 · SESSION_LOG.md — 起きたこと

ルール：ビジネス上または技術上の事実は、project-rules-architect が所有するファイルに記述します。state.json にはそのポインターだけを含めます。文章が含まれる state.json は状態ファイルではなく、文書を装ったものです。そのため、forge-guard.js state によって拒否されます。

所見は適切な場所に振り分けるものであり、積み上げるものではありません。

node "$FORGE/scripts/state.js" finding <anchor> --domain=testing.md --severity=majeur "<fait>" "<correction>"

ドメインの指定は必須です。 ドメインのない所見には昇格先がないため、何も変わりません。所見はさらに1つログを増やすだけとなり、本来反映すべきルールと競合します。これは、昇格がゼロになる原因として測定されています。

契約の全文は references/skill-boundaries.md を参照してください。

2つのモード

	Guided（デフォルト）	Fast Track
ゲート	フェーズごとに1つ	Phase 5 の終了時に1つ、さらに Phase 7 ではマイルストーンごとに1つ
Phases 4-5	スライスごとに手動で実施	自動化し、サブエージェントが検証
Phase 7	手動	スライスごとに実行可能なゲート
バリデーター	セッション内で姿勢を切り替え	quality-analyst + red-team + plan-validator を並列実行
有効化条件	常に有効化可能	PRD + 規約 + デザイン + 画面 + ベンチマークが承認済み
切り替え方法	—	「通常モードに戻る」をいつでも実行可能

自律性のレベルは有効化のたびに選択します：milestone（デフォルト）または full。詳細と理由については、references/fast-track.md § 2つの自律性レベルを参照してください。

Fast Track は検証をなくすのではなく、繰り返しをなくします。

フェーズ

順番どおりに実行してください。各フェーズは明示的な人間による検証ゲートで終了します。明確な「approved」がないまま次のフェーズに進んではいけません。 これはこのスキルで最も重要なルールです。

必要な成果物が作成されていないフェーズは承認できません。 complete-phase と set-phase … approved は、成果物が不足しているフェーズを拒否します。また、forge-guard はゲートの前に current_phase_has_deliverables を通じてその問題を報告します。拒否時には、不足している成果物と、それを登録するコマンドが示されます。

この契約は形式的なものではありません。チェックでは宣言された成果物を検証します。宣言がゼロなら検証もゼロとなり、すべてが問題なしとして通過します。実際の規模で行ったテストでは、deliverables: {} のまま conventions.md も存在しない Phase 0 が承認され、その後、何のチェックにも止められずに、成果物のない状態を基盤としてすべての工程が連続して進んだことが確認されています。

ゲートでの質問の仕方。 仕様書の場合は、「ユースケースや、すでに気付いている制約で、抜けているものはありますか？」 と尋ねます。分解の場合は、「このスライス分割でよいでしょうか。それとも、まとめたり分割したりする必要がありますか？」 と尋ねます。プランの場合は、「実装の順序は妥当でしょうか。それとも、足りない依存関係がありますか？」 と尋ねます。明示的に承認する言葉があるまで、先に進まないでください。

各ゲートの前に、ガードを実行してください。結果は決定的で即時に得られ、トークンを消費しません。

node "$FORGE/scripts/forge-guard.js" all <anchor>        # chemins, état, contrat de phase, synchronisation, placeholders, versions
node "$FORGE/scripts/consistency-check.js" all <anchor>   # écarts ENTRE artefacts

ここでの fail は提案ではありません。ドキュメントを提示する前に修正してください。

コマンドが2つある理由。 forge-guard は一度に1つのドキュメントを読み込みます。ドキュメントが存在するか、正しいパスにあるか、ステータスに矛盾がないかを確認します。プランが、実装対象のアーキテクチャと矛盾していることまでは把握できません。consistency-check はそれだけを行う唯一のツールです。なぜなら、プロジェクトで最もコストのかかるパターンは、不完全な仕様ではなく、後続の成果物によって、すでに承認された先行成果物の欠陥が明らかになることだからです。実際のプロジェクトでは13回確認され、その横にはこう記されていました。「ゲートのチェックでは検出できない。」

成果物が依存する要件を宣言してください。 承認済みの成果物は、PRD の要件によって正当化されます。その依存関係は明記する必要があります。

node "$FORGE/scripts/state.js" register <anchor> deliverable conventions .forge/conventions.md --requires=B11,C1,C2

consistency-check premises は、これらの ID を PRD の実際の状態と照合し、承認済みの成果物が依然として依存している削除済みの要件を報告します。この宣言がないと、PRD がすでに放棄した前提に基づいてドキュメントが承認済みのままになります。実地テストでは、PRD が2つ目のクライアントがいないためマルチテナントを対象外にしていた一方で、conventions.md は「厳格なマルチテナント要件への対応」を根拠に PostgreSQL を正当化していました。これを検出できるチェックはありませんでした。

削除した要件も ID は維持します。## 9. 対象外 の項目の先頭に記載します。例：- **C102** — 厳格なマルチテナント — 理由：…。ID を取り除いて要件を削除すると、追跡できなくなり、矛盾を再び検出できなくなります。そのため、このチェックでは ID のない削除を拒否します。追跡できない削除は、宣言されていない削除だからです。

1つの ID が指す要件は1つだけです。 対象外の要件で C1 が「厳格なマルチテナント」を指し、制約で「サーバーは1台」を指す場合、C1 への参照はすべて曖昧になります。このチェックでさえ、誤った成果物を指摘してしまいます。このチェックは ID の重複を拒否します。

重複を避ける方法と、絶対にしてはいけないこと。

「削除した要件を別の範囲（B1xx、C1xx）に振り直す」という反射的な対応は、追跡可能性を損なうため避けてください。直前のルールにあるとおり、削除した要件は元の ID を維持します。これは、承認済みの成果物との関連付けを保つためです。B18 を B118 に改名すると、その関連付けが失われます。チェックは正しい成果物ではなく、誰も記述していない ID を指摘することになります。

正しい対処は上流にあり、ルールは1つです。

削除する要件には、すでに使われている最も大きな番号の次から番号を割り当て、空いた番号は二度と再割り当てしないでください。

つまり、B18、B19、B20、B21 を削除した場合、次の有効な要件は B22 です。削除した番号は元の ID のまま § 9 に残し、18〜21 の範囲は使用済みとして扱います。これこそが重複チェックで検証される内容であり、交渉の余地はありません。

このルールにはコストがあります。番号がより速く増えていくことです。それでも、これは正しいトレードオフです。番号の欠番は目に見えますが、ID の重複は誤った診断が出るまで気付きません。

conventions.md は最もよくあるケースです。これは更新され続けるドキュメントであり、PRD の改訂によって更新が必要になります。再改訂し、ステータスを stale にしてから approved に戻し、consistency-check premises を再実行してください。

フェーズごとの役割

この表は規範です。 フェーズの成果物を作成する際に、どのエージェントファイルを読むべきかを示します。この表がなければファイル名を推測することになり、推測すると存在しないファイルを参照してしまいます。そのファイルが存在しなくても、エラーになることはありません。

テストプロジェクトで2回連続して確認されました。Phase 4ではagents/solution-architect.md（ファイル名はsystems-architect.md）を、Phase 5ではagents/plan-writer.md（存在しません）を指定していました。どちらの場合も、呼び出しは成功したように見えました。サブエージェントは、ファイルがないことを報告しつつ、SKILL.md § 5に基づいて成果物を作成しました。誤った指示を回避するエージェントがいても、目に見える不具合にはなりません。不具合が見えなくなるだけです。

フェーズ	成果物	読むエージェント	検証方法
1	.forge/prd.md	agents/product-analyst.md	forge-guard placeholders、client-liaison --check
2	.forge/roadmap.md	agents/scope-architect.md	consistency-check premises
3	.forge/design/	agents/ux-designer.md	design-check contrast、design-check tokens-used
4	.forge/architecture.md	agents/systems-architect.md	ddl-exec all、dependency-check
5	.forge/plans/	自分で作成します。SKILL.md § Phase 5とtemplates/implementation-plan.md.tmplに従ってください	coverage-check slice、forge-guard placeholders
6	.forge/test-plan.md	agents/quality-analyst.md	consistency-check plans

Phase 5には計画作成エージェントがいません。これは意図的です。 実装計画は、何もないところから作成するのが最も簡単です。まだ書いていないコードについて説明するドキュメントでも、形式上の検証はすべて簡単に通過してしまいます。そのため、作成を委任できる相手はいません。すでに書かれた計画をレビューするだけで、書き直しはしないagents/plan-validator.mdのみです。

premise-challenger.mdはPhase 1の2つのタイミングで追加で使用します。最初のアイデアについてインタビューの中間時点で、また最後にPRDについて使用します。このエージェントは何も書き直しません。問題点を指摘するので、修正するのはあなたです。

validate-repoは、ここで名前が挙がっていないエージェントファイルがディスク上に存在する場合も、ここで名前が挙がっているエージェントファイルがディスク上に存在しない場合も拒否します。したがって、この表自体が不整合になることはありません。

---

Phase 0 — ブートストラップ

目的：プロジェクトのコンテキストを確立し、製品について検討する前に規約の基盤を生成します。

1. anchorを解決します（state.js anchor）。これはすでに完了しているステップ0です。
2. anchorに既存のプロジェクトがある場合は、その設定ファイルを読みます。package.json、tsconfig.json、.opencode/、AGENTS.md、ルール、ADRを確認します。暗黙の規約（lint、フォーマット、フォルダー構成、スタック、テストフレームワーク）を抽出してください。
3. プロジェクトがまだ存在しない場合は、ユーザーに次の点を確認します。
   • 想定する技術スタック（言語、フレームワーク、データベースなど）
   • 技術面またはホスティング上の制約
   • 必須または使用禁止のツール
4. .forge/を作成します：node "$FORGE/scripts/state.js" init <anchor> "<Nom>" --reference <projet de référence si applicable>。
5. § 2つの呼び出しに従って、「コンテキストの基盤」モードでproject-rules-architectを呼び出します。期待される成果物は、anchorのルートに置くAGENTS.md、SESSION_LOG.md、DECISIONS.md、LEARNINGS.mdのみです。
6. templates/conventions.md.tmplから.forge/conventions.mdを生成します。まだ決まっていないセクション（例：state management、E2Eフレームワーク）にはÀ DÉCIDER EN PHASE 4と記します。
7. 成果物を登録します：state.js register <anchor> deliverable conventions .forge/conventions.md。
8. templates/contract.md.tmplから.forge/contract.mdを生成し、client-liaison --checkで確認します。指摘された点を修正し、署名を受けます。

   node "$FORGE/scripts/state.js" register <anchor> deliverable contract .forge/contract.md
   node "$FORGE/scripts/state.js" set-status <anchor> deliverable contract approved
   

9. 検出した内容をユーザーに要約し、確認を求めます。

コンテキストを確立する前に、製品について話し始めてはいけません。 技術的な選択によって製品の可能性が制約され、その逆も同様です。

署名後に割り込まれるのは、2つの場合だけです

これは契約上の約束であり、形だけのものではありません。購入を伴うすべての事項は署名の前に決定されるか、契約が forge-guard contract によって拒否されます。つまり、その後は次のとおりです。

理由	方法
契約との不一致	state.js client --kind=ecart …
あなたが決める判断事項	state.js client --kind=decision …

4つのフィールド（what、price、by、if_no_answer）は必須で、これらがない事項をコマンドは拒否します。期限のない判断事項を保留にはしません。判断を下すのは Forge です。期限を過ぎると、Forge は「回答なし」の条項を適用し、次回のレビューであなたに知らせます。

コンテキストの基盤にはルールが含まれていません。 呼び出し1と呼び出し2の間、プロジェクトにはメモリーがあり、ルールセットはありません。これは正常な状態であり、作業が中途半端なのではありません。呼び出し1で AGENTS.md または .opencode/rules/ が返された場合、scaffold モードが迂回されています。scaffold モードは、スタックの調査に進む前に終了します。

---

project-rules-architect への2回の呼び出し

Forge が呼び出し元となるのは、決められた2つの時点だけです。呼び出し先になることはありません。

呼び出し	タイミング	渡すもの	受け取るもの
1 — コンテキストの基盤	フェーズ0、ステップ5	プロダクト名、ユーザーがすでに伝えた内容	メモリーファイル4つ（配置済み）
2 — ルールセット	architecture が approved になったとき	決定済みのスタック、採用した規約、MVP の範囲	AGENTS.md とルール（配線済み）

呼び出し1 — コンテキストの基盤

project-rules-architect を呼び出し、scaffold モードを明示的に指定します。

「このプロジェクトのコンテキスト構造を作成してください。ファイルは AGENTS.md、SESSION_LOG.md、 DECISIONS.md、LEARNINGS.md です。ルールも、AGENTS.md も、スタックの調査も不要です。スタックはまだ決まっていません。」

返されるべきものは、anchor のルートに置かれた、タイトル付きの4つのファイルだけです。それ以外は何も必要ありません。ルールが含まれている場合、その応答は誤りです。

呼び出し 2 — ルールセット

architecture が approved になった時点で、それより前ではなく：

「決定したスタックと、このプロジェクトのスコープはこちらです。ルールセットを作成し、対象ツールに接続してください。」

.forge/architecture.md と .forge/conventions.md から、正確なバージョンを含むスタック、採用した規約、スコープ、そしてルールにしてはならない未解決の質問を渡します。

ファイル全体ではなく、抜粋を渡してください。 この2つのドキュメントは数千行に及ぶことがあり、ルールを決める部分は常に全体の一部です。構造化された要約（スタックの表、ライブラリの選択、未解決の質問）は、ファイル全体を斜め読みするより小さく、信頼性も高くなります。原則：渡す事実は1行であり、章ではありません。

なぜそれより前ではないのか。 ルールはスタックを前提として生成されます。スタックが決まる前に作成するのは推測です。推測で作られたルールにはルールの権威がありながら、仮定の信頼性しかないため、エージェントはそれを適用してしまいます。

この呼び出しには時期だけでなく、ゲートもあります。 architecture approved の前は未実施であるべきですが、その後も未実施なら不備となり、forge-guard が報告します：

node "$FORGE/scripts/forge-guard.js" rules-present <anchor>

ルールディレクトリが存在しない、空である、または存在していても接続されていない場合に失敗します。何も読み込まない4つの Markdown ファイルは、見た目だけは完全なルールセットでも、まったく機能しないからです。これが欠けていたチェックです。呼び出し 2 は記述され、日付が設定され、条件も定められていましたが、一度も実行されていませんでした。同じ進捗状況にある研究室の5つのプロジェクトのうち、ルールセットがあったのは1つだけで、それを示すものは何もありませんでした。

続行する前に、結果を検証してください：

node "$PRA/scripts/rules-selftest.js" <anchor>

納品されたルールセットに対する10項目のチェックです：接続、インデックス、プレースホルダー、相互参照、矛盾するしきい値、.forge/ との結合、汚染、検証不能な文章、ゲート、予算。ここでの失敗は納品不備であり、議論の余地はありません。

Forge がこれらのファイルに対して決して行わないこと

❌ 決してしないこと	✅ 代わりに行うこと
AGENTS.md、SESSION_LOG.md、DECISIONS.md、LEARNINGS.md に書き込む	何もしません。これらはエージェントのメモリであり、エージェント自身が管理します。
独自の AGENTS.md または .opencode/rules/ を作成する	呼び出し 2 で作成されたルールセットを使います。
ルールを conventions.md にコピーする	スタックの事実を呼び出し 2 に渡します。

2人の writer がメモリを書き込むと、痕跡を残さずにデータが失われます。一方が追加し、もう一方が上書きしても、ファイルは存在し続け、もっともらしく見えます。これが契約を設ける理由であり、単なる整理上の注意ではありません。

メモリの実際の状態は、state.js start が project_memory に報告します。

conventions.md は更新され続けるドキュメントです。 Phase 0 で判明している内容から始まり、Phase 4（アーキテクチャ：validation library や state management の選択）で充実し、いつでも修正できます。実装計画（Phase 5）はこれを参照します。その後に conventions.md を変更すると、それに依存する計画は無効になります。修正のたびに state.js check-stale を実行してください。

修正の原則 — 番号を振り直さず、拡張する

ほかの成果物から番号で参照されている文書は、番号を振り直してはいけません。拡張してください。§ 5.9 に挿入すると、§ 5.10、§ 5.11、その後のすべての番号がずれます。すると、それぞれの参照先は今も存在するセクションを指すため、誤った参照になります。これは最悪のドリフトです。解決できてしまい、チェックでも問題なしと判定され、何も知らせてくれません。

確認された事例、INC-011：2 つの重大な根本原因を修正する際、§ 5.9 と § 5.10 に 2 つのエンドポイントを挿入しました。8 つの計画にある17 件の参照が誤ったものになりました — error-handling（4）、restriction-lignes（3）、journal-acces（4）、export-provenance（4）。しかも、そのことを示す行はひとつもありませんでした。リスクのない修正方法は、2 つのエンドポイントを**§ 5 の末尾に**追加することでした。

承認済みの成果物を編集してはいけません。修正として適用してください：

node "$FORGE/scripts/state.js" amend <anchor> <clé> \
  --reason "<pourquoi cet amendement existe>" \
  [--changes <fichier-listant-ce-qui-change>]

このコマンドが行うことと、それぞれの項目が必要な理由：

--reason が必須	理由のない修正は通常の編集です。理由を記すことで、修正と区別できます。
見出しマップ	承認時に取得されます。これは、ほかの成果物が参照しているバージョンです。これがなければ、最初の修正で自由に番号を振り直せてしまいます。
番号の振り直し → 拒否	別の内容を示す番号や、存在しなくなった番号があれば、コマンドを拒否し、ドリフトの内容を順番に示します。警告は無視できますが、拒否されれば記述せざるを得ません。
--allow-renumber	単なるスイッチではありません。--renumber-reason <texte> が必須で、その理由は、壊れた番号とともに状態に残ります。なぜそうしたのか誰も覚えていないときに残る、唯一の記録です。
ステータス → stale	修正された成果物は、もはや承認されたものと同じではありません。draft ではなく stale です。これは、すでに記載されている進行経路に従って、正式なゲートで再度 approved になります。

拒否された場合、次にすべきことが示されます：

Un document cité par numéro s'étend, il ne se renumérote pas.
Corrige sans risque : ajouter les sections NOUVELLES en fin de numérotation,
et ne toucher à aucun numéro existant.

参照には対象を明記する必要があります。 § 5.15 だけでは、どの文書を指すのかわかりません。`architecture.md` § 5.15 と書けば、チェックで解釈を挟まずに参照先を正確に確認できます。consistency-check references は、次の 2 種類の判定を返します：

• リンク切れ — 対象が明記されているのに、セクションがない → 失敗。これは番号のドリフトで、INC-011 と同じケースです；
• 未宣言の対象 — 文書名のない参照 → カウント対象ですが、失敗にはなりません。テストプロジェクトでは 276 件です。これらを失敗扱いにすれば、1 週間後には無効化されるチェックになります。このプロジェクトでは実際に 4 回そうなりました。解決方法は出力に記載されています。ファイル名を指定すれば、カウントが減ります。

フェーズ 1 — ディスカバリー（PRD）

目的：漠然としたアイデアを、完全で一貫性のある Product Requirements Document にします。

これは文書作成のフェーズではありません。 インタビューを行い、アイデアを成熟させるフェーズです。PRD は成果物であり、プロセスではありません。

premise-challenger はこのフェーズで 2 回参加します：インタビューの中盤で出発点となるアイデアを検証し、最後に PRD を検証します。書き換えは行わず、問題点を指摘し、あなたが反映します。agents/premise-challenger.md を参照してください。

1.1 初回インタビュー

質問は一度に 1 つか 2 つずつ、段階的に行います。ユーザーに質問を浴びせないでください。次のカテゴリーを順番に確認します：

1. 問題：このプロダクトはどのような問題を解決しますか？誰のためのものですか？なぜ今なのでしょうか？
2. ユーザー：ユーザーは誰ですか？どのようなセグメントがありますか？スキルレベルはどの程度ですか？どのような状況で使いますか？
3. ソリューション：プロダクトはどのように問題を解決しますか？提供価値は何ですか？
4. 機能：主な機能は何ですか？副次的な機能は何ですか？
5. 制約：法律、技術、予算、時間に関する制約はありますか？
6. 既存製品：競合製品や類似製品はありますか？このプロダクトとの違いは何ですか？
7. リスク：想定されるリスクや、まだわかっていないことは何ですか？
8. 成功：プロダクトの成功をどのように判断しますか？

1.2 課題の洗い出しと深掘り

最初のヒアリングの後、回答を掘り下げます。

• 矛盾を見つける：「製品はシンプルであるべきだと言っていますが、機能 X は複雑です。どのように両立させますか？」
• 暗黙の前提を特定する：「エラー処理について触れていませんが、製品で失敗ケースに対応する必要はありますか？」
• 限界を試す：「ユーザーが状態 Y で X を実行した場合、どうなりますか？」
• 野心的すぎないか確認する：「この機能は作業の 40% を占める一方で、利用の 5% にしか関わらない可能性があります。本当に必要ですか？」
• 見落としを指摘する：「パスワード回復の仕組みが見当たりませんが、これは意図的ですか？」
• 依存関係を特定する：「機能 A を動作させるには、まず B、C、D が必要です。この順序で問題ありませんか？」
• 代替案を提案する：「V1 で複雑なロールシステムを実装する代わりに、管理者／ユーザーの単純なフラグで十分ではありませんか？」

1.3 PRD の作成

回答が十分に固まったら、templates/prd.md.tmpl をもとに、.forge/prd.md に PRD を作成します。state.json に書いてはいけません。他の場所にも書いてはいけません。

ルール：

• 各ビジネスルールに、固定 ID（B1、B2 など）を割り当てます。
• 各エッジケースに、固定 ID（E1、E2 など）を割り当てます。
• 各制約に、固定 ID（C1、C2 など）を割り当てます。
• ID は確定したものであり、再利用してはいけません。
• ユーザーストーリーには番号を付け、優先順位を設定します。
• PRD に実装の技術的な専門用語（フレームワーク、データベースなど）を含めてはいけません。これは純粋なプロダクト文書です。
• 特定したものの解決していない曖昧さは、すべて「確認事項」セクションに記載します。

続いて、state.js register、forge-guard.js placeholders の順に実行し、その後でのみゲートに進みます。

1.4 多角的なレビュー

最終ゲートの前に、視点のローテーション を適用します。この工程は PRD で必須です。

• 品質の視点：あらゆる種類のユーザー（管理者、サポートを含む）が特定されていますか？ ユーザーストーリーはすべてのユースケースを網羅していますか？ 非機能要件は網羅されていますか？
• リスクの視点：ユーザーストーリー間に矛盾はありませんか？ 明文化されていない暗黙のビジネスルールはありませんか？ 検証されていない仮定はありませんか？

見つかった問題を修正してから、PRD を提示します。

1.5 調査 — 車輪の再発明を避ける

PRD を確定する前に、references/research-protocol.md を適用します。

1. アーキタイプ（references/archetypes.md）を特定します。
2. 少なくとも 2 つの参考製品を探して、実際に確認します。調査結果は .forge/benchmarks.md に記録します。state.json には記録しません。
3. PRD のビジネス上の問題ごとに、コードではなく 不変条件（誤りであってはならない特性）を抽出します。
4. アーキタイプの繰り返し発生する問題（archetypes.md の § 9）を読み、それぞれについて「私たちの設計はより優れているか、そしてそれをどう確かめるか」と自問します。
5. 意図的な差異は、可逆性のコストとともに benchmarks.md の § 5 に記載します。

どの決定も変えない調査は、何も生み出していません。その場合は、文書を埋めるのではなく、そのことを明記します。

1.6 ゲート

PRD 全体を提示します。ゲートのチェックリスト（references/review-checklists.md#prd）。

フェーズ 2 — スコープ（ロードマップ）

目的：各バージョンに何を含めるか、その理由を定義します。

2.1 スコープの分析

1. PRD を確認し、すべての機能／ユーザーストーリーを一覧にします。
2. 機能ごとに、ユーザー価値、複雑さ、依存関係、リスクを評価します。
3. MVPを特定します。主要な問題を解決し、実際のユーザーが利用できる最小限の機能セットです。
4. V1を定義します。MVP に、スコープを大幅に広げずに差別化をもたらす機能を加えたものです。
5. 「あると便利」な機能や、ユーザーからのフィードバックに依存する機能は、V2 以降に先送りにします。

2.2 分割の根拠

各バージョンについて、以下を説明します：

• これらの機能を含める理由。
• これらの機能を先送りする理由。
• どのようなトレードオフを行ったか。
• どのようなリスクを受け入れるか。

2.3 ロードマップ

templates/roadmap.md.tmplから**.forge/roadmap.md**を生成します。state.jsonには絶対に含めないでください。

各バージョンに以下を含めます：

• ID（B*）付きの機能
• 成功基準
• バージョン間の依存関係
• 工数の見積もり（日数ではなく相対的な値）
• そのバージョン固有のリスク

2.4 複数視点レビュー

ゲートの前に、視点のローテーションを適用します：

• 品質の視点：バージョンごとのリスクを網羅していますか？明記されていないバージョン間の依存関係はありますか？
• リスクの視点：MVPは本当に主要な問題を解決していますか？実際のユーザーの妨げになり得る、先送りしたものは何ですか？

2.5 GATE

ロードマップを提示します。ゲートのチェックリスト（references/review-checklists.md#roadmap）。

Phase 3 — デザイン（UI/UX）

目的：機能を実装する前にインターフェースを設計し、明確なビジュアル方針を定め、実際の利用頻度に基づいてナビゲーションの優先順位を付けます。

このフェーズの順序は、構造上重要です。省略しないでください。

3.1 ビジュアル方針と標準 — デザインに着手する前に

以下の2つのドキュメントが揃うまで、何も描き始めてはいけません。

1. アプリケーションのアーキタイプ（references/archetypes.md）を特定し、作業のループを1文で記述します。state.json（product.archetype）に記録します。
2. 状況に適したデザインスキルを呼び出します — 必須です。references/design-quality.md § 2を参照してください（モバイル → imagegen-frontend-mobile、ランディングページ → frontend-design、高密度なWebアプリ → impeccableなど）。利用できるスキルがない場合は、最低限§ 3の禁止事項を適用し、監査でその旨を報告します。
3. 3つのアンカーを定めます：参考資料、雰囲気（3つの言葉）、反面教師となる参考資料。これらが揃っていなければ、Phase 3は完了していません。
4. templates/benchmarks.md.tmplから**.forge/benchmarks.md**を生成します：参考製品、アーキタイプへの適合度を評価するチェックリスト、意図的に許容する差異。このドキュメントはFast Trackでバリデーターの参照資料として使用します。

3.2 利用頻度を優先したナビゲーション

ナビゲーション項目の順序は優先順位を示すものであり、モバイルアプリの設計で最も頻繁に見られる誤りです。

references/module-prioritization.mdを適用します：

1. 各モジュールに、正当化の根拠とともに頻度（1～5）× 中心性（1～5）のスコアを付けます。
2. 並べ替えます：まずメインのループ、次に繰り返し行う操作、その次にライフサイクルの項目、最後に設定を配置します。
3. 主要項目は5つ以内にします — 残りはオーバーフロー（「その他」）に配置します。
4. 「ホーム」が最初とは限りません：ループを開始するか、最もよく使われる場合に最初に配置します。

この順序は検証可能になります：

node "$FORGE/scripts/state.js" set-nav <anchor> '{ "archetype": "...", "core_loop": "...", "items": [ ... ] }'

3.3 デザインシステム

1. 具体的な値を使ってデザイントークンを定義します。「後で定義」としてはいけません。

2. プリミティブコンポーネントを定義します：ボタン、入力欄、モーダル、カード、テーブルなど。

3. ナビゲーションパターンを定義します：ルーティング、パンくずリスト、サイドバー、ナビゲーションバー、項目の順序（3.2 を参照）。

4. references/design-quality.md § 3 の禁止事項を適用します：選択していない純白を使わない、デフォルトの区切りとして影を使わない、デフォルトのパレットを使わない、均一なタイポグラフィスケールを使わない。

5. .forge/design/design-system.md を templates/design-system.md.tmpl から生成します。

6. デザインシステム（テンプレートの § 0.0）で色のクラスを宣言します。 そのうえで、コントラストを測定し、書き込まないでください。 チェックリストは「コントラスト N:1」を求めていますが、それを検証するものはありませんでした。そのため、比率は計算されず、記述されていました。

   宣言は形式的なものではありません。色の名前から色のクラスを推測するチェックは、その名前と同じ言語でしか機能しません。従来の判定シグナルは英語のリテラル（--color-text-*、--color-ink-50、*-subtle）ですが、このスキルが生成するものはすべてフランス語です。フランス語の語彙では、すべてが「非テキストコンポーネント」と判定され、3:1 で評価されます。その結果、コントラスト比 3,80:1 のテキストが合格していました。このチェックが見つけるために作られた欠陥が、測定したばかりのドキュメントに再び現れていたのです。

   on: は、テキストが実際にどの背景の上に置かれるかを示します。これがないと、インク色の上にしか置かれない反転テキストが紙色と比較され、必然的に不合格になります。exempt: には理由を記載します。装飾用の色合いはインターフェースコンポーネントではありません。リストにない色トークンは警告されます。宣言は責任を伴うものなので、省略するのも一つの選択です。

   node "$FORGE/scripts/design-check.js" contrast <anchor>
   node "$FORGE/scripts/design-check.js" tokens <anchor>
   

   このチェックで検出でき、読み返すだけでは見つけられないことが2つあります。 記載された比率が実測値と一致しないこと——何の根拠もない保証です。そして、背景の上では読めるものの、別のサーフェス、たとえばテーブルの交互の行やくぼんだパネルの上では明るすぎるテキストです。不合格になるのは、多くの場合こうした箇所です。

   しきい値は WCAG に準拠しています。すべてのサーフェスに対するテキストは 4,5:1（1.4.3）、非テキストコンポーネント（フォーカスリングを含む）は 3:1（1.4.11）です。各トークンのクラス（テキスト、コンポーネント、塗りつぶし、免除）は、宣言、用途、名前から判定され、出力に表示されます。トークンをそのように分類した理由を示さないチェックは、異議を申し立てることができません。

3.4 画面とフロー

ユーザーインターフェースを持つ PRD の各機能について：

1. 必要なすべての画面を一覧にし、それぞれをナビゲーション階層のランクに関連付けます。
2. .forge/design/screens/<nom>.md に画面ごとに1ファイル作成し、templates/screen.md.tmpl から生成します。
3. テンプレートでは、9つの状態、画面ごとのビジュアル方針、インタラクション、各ブレークポイントでのレスポンシブ対応、アクセシビリティ、トレーサビリティが求められます。すべて埋めてください。{{PLACEHOLDER}} が残っているということは、その状態が実装されないということです。
4. 画面間のナビゲーションフロー（ハッピーパス、代替フロー、エラー、オンボーディング）を定義します。

次に：

node "$FORGE/scripts/forge-guard.js" placeholders <anchor>
node "$FORGE/scripts/design-check.js" contrast <anchor>
node "$FORGE/scripts/design-check.js" component-parity <anchor>

トークンを参照する画面では、実在し、かつ読み取り可能な値を指定する必要があります。後者は画面を読み返してもわかりません。測定が必要です。

コンポーネントを表示する画面では、そのサーフェスを把握する必要があります。コンポーネントにスロットや状態が追加された場合、それを表示するすべての画面に反映することは、単なる配慮ではありません。同じコンポーネントの表示が二通りにならないための条件です。component-parity は、反映を忘れたときに生じる形、たとえば誤った列挙（スロットが7つあるのに「6つのスロット」）を検出します。状態を表示しないことを選んだ画面は、その理由を記載します：`Tile` — exempt: `offline` (テーブルがオンライン)。

3.5 検証の設計

1. PRD の各ビジネスルール（B*）に対応する画面またはフローがあることを確認します。
2. 各エラー状態（E*）に視覚的な表現があることを確認します。
3. すべての画面で視覚的な一貫性が保たれていることを確認します。
4. すでにコードがある場合：Chrome MCP を使用してインターフェースを確認します（オーバーフロー、レスポンシブ、レイアウト、ナビゲーション）。

3.6 多角的なレビュー

ゲートの前に、視点のローテーションを適用します。

• 品質の観点：各エッジケースに視覚的な状態がありますか？ アクセシビリティは考慮されていますか？ レスポンシブ対応はすべてのブレークポイントをカバーしていますか？
• リスクの観点：画面間に視覚的な不整合はありますか？ 未対応のエラー状態はありますか？

3.7 ゲート

標準、優先順位を付けたナビゲーション、デザインシステム、画面を提示します。アーキテクチャに進む前に、ユーザーが視覚的に承認します。ゲートのチェックリスト（references/review-checklists.md#design）。

Phase 4 — アーキテクチャ（システム設計）

目的：製品をスライス、モジュール、基盤に分解し、それらの依存関係を明らかにします。

4.1 スライスへの分解

1. PRD の各機能を確認します。
2. 機能をモジュール（技術的に一貫したまとまり）にまとめます。モジュールの順序とグループ分けは references/module-prioritization.md に従います。まず頻度を基準とし、ドメインの組織図は決して基準にしません。
3. 各モジュールをスライス（独立して実装できる、エンドツーエンドの機能）に分割します。
4. 横断的な基盤（Phase 3 のデザインシステム、認証、エラー処理、i18n、設定、ロギング、API クライアント）を特定します。

分割ルール：

• スライスは独立して実装・テストできる必要があります（依存関係にモックを使う場合も含みます）。
• スライスは新規ファイルが約 10 個を超えないようにします。
• スライスが大きすぎる場合は、複数の異なる機能が含まれているということです。
• 2 つのスライスでコードの 50% 以上を共有している場合は、統合を検討します。

4.2 データモデル

各スライスについて、以下を定義します。

• エンティティとそのフィールド（型、制約、関連）。
• バリデーションスキーマ。
• API コントラクト（エンドポイント、リクエスト、レスポンス、エラー）。

ルール：すべてのモデルは要約せず、フィールドごとに定義します。この段階でフィールドを漏らすと、実装時のバグにつながります。

4.3 依存関係グラフ

1. スライスごとにグラフを宣言します。

   node "$FORGE/scripts/state.js" dep <anchor> <slice|fondation> <a,b,c>
   

   state.js dep は、存在しないスライスへの依存、自己依存、または循環を生じさせる依存を拒否します。誤ったグラフと不完全なグラフは見分けがつきません。解決されることのない依存関係が残っても、その後に警告は出ません。
2. node "$FORGE/scripts/dependency-check.js" check <anchor> --write を実行し、depended_on_by と impl_wave を計算します。
3. 循環依存、トポロジカル順序、並行して開発できるスライスを特定します。

最小要件より細かい場合は、ウェーブ計画を宣言してください。 dependency-check はトポロジカル順序の最小値を計算します。より細かなスケジュール計画にも正当性はあります。たとえば、RLS ポリシーと差異の計算式を 2 人が同時に担当することはできません。しかし、その計画はアーキテクチャのフロントマターに記述する必要があります。

impl_waves: 13
impl_waves_rationale: >-
  Plan d'ordonnancement, pas minimum topologique. Le graphe se réduit à 8 vagues ;
  on en retient 13 parce que F4 et F9 ne doivent pas être portées par la même personne.

この宣言がないと、writeBack は何も通知せずに impl_wave を上書きするため、Phase 4 の 2 つのドキュメントの内容が食い違ったまま CI が成功します。理由を示さずに宣言した場合は、失敗となります。正当化されていない計画は、カウントミスと見分けがつきません。理由とともに宣言すれば、警告として確認できる状態に保たれます。

4.4 アーキテクチャドキュメントの生成

templates/architecture.md.tmpl から .forge/architecture.md を生成します。

4.5 DDL は実行するか、記述しない

ドキュメント内の DDL はコンパイルも型チェックも実行もされません。 読み返されるだけです。そのため、不備が見つかるのは記述するとき、つまり作成者が書いた内容を読み返すときだけです。

この種の不備が、実地テストで3つのゲートをすり抜けました。そして、どれも読み返しただけでは見つかりませんでした。

• ALTER TABLE … ADD CONSTRAINT … CHECK (… <> (SELECT … FROM …)) — サブクエリを含む CHECK です。PostgreSQL は作成時にこれを拒否します。CHECK は行単体で評価できなければならないためです。制約は存在しません。
• トリガーの先頭にある IF NEW.status = OLD.status THEN RETURN NEW; END IF; — このガードはステータスが遷移したときにしか実行されません。別のカラムを更新する UPDATE はすり抜けます。ゲートは記述され、コメントも付いていますが、機能していません。
• トリガーが必須とする published_at を生成するものがありません。

ゲートの前に実行します。

node "$FORGE/scripts/ddl-exec.js" all <anchor>

3つの判定には、それぞれ異なる意味があります。

コマンド	確認する内容	エンジン
completeness	DDL が変更する各テーブルが作成されているか、カラムの表として記述されているか。未定義のテーブルが使用されていないか。	なし
execute	PostgreSQL が各ステートメントを受け付けるか。拒否された制約は存在しません。	pglite
guards	ドキュメントが宣言した各ガードが、禁止された操作を実際に拒否するか。	pglite

ガードを宣言してください。 先頭行が -- forge:ddl-refuse の sql ブロックには、拒否されるべきステートメントが含まれています。実行が通ればチェックでその旨が通知されます。読み返したのではなく PostgreSQL が実行した結果なので、その通知は正確です。

-- forge:ddl-refuse
-- Publier sans signature doit être refusé. Si cette instruction passe, la
-- porte n'est pas une porte.
UPDATE definition_version SET status = 'published' WHERE definition_version_id = 1;

禁止する操作の名前をチェックが推測するのではありません。ドキュメントで名前を明示します。これが、機能するチェックと推測に頼るチェックの違いです。推測が必要なチェックは、すべてノイズを生みます。

宣言されていないガードはテストされません。スクリプトでも、レビュー担当者でも、ガード自身でも同じです。ガードを宣言していないアーキテクチャでは、guards は guards_declared: 0 とともに pass を返し、そのことを明示します。見つからなかったものについて何も言わないチェックでは、空白が見過ごされるためです。

エンジンは任意です。pglite がなければ、execute と guards はインストール方法を示して skipped を返します。実行していないのに pass を返すことは決してありません。completeness はエンジンを必要とせず、ドキュメントだけを対象とするため、引き続き利用できます。

4.6 多視点レビュー

ゲートの前に、視点のローテーションを適用してください。アーキテクチャでは必須です。

• 品質の視点：データモデルの各フィールドはすべて網羅されていますか？各エンドポイントにはすべてのエラーコードが列挙されていますか？スライスは PRD のすべてのユーザーストーリーをカバーしていますか？
• リスクの視点：依存関係の循環はありますか？流入する依存関係が多すぎるスライスはありますか？正当化されていないアーキテクチャ上の決定はありますか？

標準への準拠も追加します。plan-validator はアーキテクチャを .forge/benchmarks.md およびアーキタイプ（references/archetypes.md）と比較します。

4.7 ゲート

ゲートのチェックリスト（references/review-checklists.md#architecture）。

Phase 5 — スライスごとの実装計画

目的：性能の低い AI でも間違えないほど、精度の高い実装計画を作成します。

スライスごとに、1つずつ進めます。Guided モードでは、スライスごとにゲートを設けます。Fast Track モードでは、references/fast-track.md の自動検証ループを使用します。

5.1 データ契約（コード）

対象スタックの構文で、実際のコードを生成します。

• 検証スキーマ（Zod、Pydantic、Dart クラスなど）。
• 型とインターフェース。
• API 契約（リクエスト／レスポンスの型）。

譲れないルール：コード内の各フィールドは、アーキテクチャ（Phase 4）で定義されたフィールドと一致していなければなりません。フィールドを勝手に追加してはいけません。

5.2 重要なアルゴリズム

複数の条件分岐または複数のステップがあるビジネスルール（B*）ごとに、疑似コードまたは実際のコードを記述してください。文章による言い換えは不可です。

5.3 コンポーネント計画

• コンポーネントツリー。
• 各コンポーネントの Props、state、イベント。
• 状態の管理（loading、empty、error、success、edge cases）。

5.4 状態管理（state management）

• グローバルデータとローカルデータを明記します。
• 各データに使用するストレージの仕組みを明記します。
• コンポーネント間のデータフローを明記します。

5.5 避けるべき落とし穴

よくある解釈ミスを予測します。各落とし穴は特定の B*/E* ID に紐づけ、明確な対比として記述します：「X と Y を混同しないでください。正しい動作は Z です（B12 を参照）。」

5.6 タスクチェックリスト

フェーズごとに、具体的なタスクを順番に並べたチェックリストを作成します：

1. データ層（スキーマ、型、API クライアント）。
2. ビジネスロジック（アルゴリズム、サービス、状態管理）。
3. ユーザーインターフェース（コンポーネント、画面、フォーム、ナビゲーション）。
4. 統合（権限、feature flags、ルーティング）。
5. 単体テスト。
6. コンポーネントテスト。
7. 統合テスト / E2E。
8. 仕上げ（アクセシビリティ、レスポンシブ対応、アニメーション、エラー）。

5.7 受け入れ基準

各基準は個別に検証可能で、B*/E*/C* ID に紐づいている必要があります。

5.8 テスト計画

このスライス固有の内容のみを列挙します：

• 対象となる B*/E*/C* ID と、それぞれのテスト種別。
• このスライス固有の E2E シナリオ。
• このスライスの画面に対する Chrome MCP の検証項目。

共通の枠組み（フレームワーク、パターン、カバレッジルール）は、全体テスト計画（Phase 6 で生成される .forge/test-plan.md）で定義します。ここでは重複させないでください。

5.9 カバレッジ検証

ゲートに進む前に、node "$FORGE/scripts/coverage-check.js" slice <anchor> <slice> を実行し、続けて node "$FORGE/scripts/forge-guard.js" placeholders <anchor> を実行します。

pass: false の場合は、計画を完成させるために差し戻します。スクリプトは以下を検証します：

• PRD 内の各 B*/E*/C* ID に、計画内の対応項目があること。
• 必須の各セクションが存在し、空でないこと。
• {{PLACEHOLDER}} が残っていないこと。

5.10 GATE

ゲートチェックリスト（references/review-checklists.md#implementation-plan）。

フェーズ 6 — 検証（全体テスト計画）

目的：全体的なテスト戦略を定義し、テスト環境を設定します。

6.1 テストの設定

1. テストフレームワーク（Jest、Vitest、Pytest など）をインストール / 初期化します。
2. E2E ツール（Playwright、Cypress など）をインストール / 初期化します。
3. UI 検証用に Chrome MCP を設定します。

6.2 基盤テスト

各基盤について、スライスの実装前にテストを作成します：

• デザインシステム：プリミティブコンポーネントのレンダリングテスト。
• 認証：認証フローのテスト。
• エラーハンドリング：エラー発生時の動作テスト。
• i18n：翻訳の存在確認テスト。
• API クライアント：インターセプター、リトライ、タイムアウトのテスト。

6.3 回帰テスト計画

各マージ前に通過させる回帰テストスイートを定義します。

6.4 GATE

ゲートチェックリスト（references/review-checklists.md#validation）。

フェーズ 7 — 実装

計画が承認された各スライスについて、次の手順を実行します。

1. すべての依存関係が実装済み（またはモック済み）であることを確認します：node "$FORGE/scripts/state.js" check-stale <anchor> <slice>。
2. まず、そのスライスの実装計画と規約（.forge/conventions.md）を読みます。別のスライスとの連携について計画が曖昧な場合は、アーキテクチャ全体ではなく、該当するセクションだけを確認します。
3. タスクチェックリストに従って実装し、文書化されたデータ契約、アルゴリズム、注意点を厳守します。
4. 該当する場合は、まずテストを作成します（TDD）。それ以外の場合は、各レイヤーの実装直後にテストを作成します。
5. 各受け入れ条件を確認します。
6. 終了条件を実行します。これはゲートであり、単なるチェックリストではありません：

   node "$FORGE/scripts/forge-exit.js" <anchor> <slice>
   

   実際のプロジェクトコマンドを実行し、そのスライスにテストファイルがあるだけでなく、テストケースがあることを確認します。「テストが存在する」とは、「少なくとも1つのケースがある」という意味です。14個のスライスがテストなしで承認された際に欠けていたのは、この区別です。
7. Chrome MCP のチェック（オーバーフロー、レスポンシブ、ナビゲーション、エラー状態）を実行します。
8. 明らかになった問題は、ドメインを指定して振り分けます。対象のない問題を残してはいけません：

   node "$FORGE/scripts/state.js" finding <anchor> --domain=<règle visée> --severity=<s> "<fait>" "<correction>"
   

9. node "$FORGE/scripts/consistency-check.js" all <anchor> を実行します。このスライスが不整合として表示されてはいけません。
10. ステータスを更新します：state.js set-status <anchor> slice <slice> implemented。検証後に validated に更新します。
11. 各スライスの後にゲートを実施します。

ルール：現在のスライスのテストと検証が完全に終わるまで、次のスライスに進んではいけません。

Fast Track の場合、手順 1〜9 は中断せずに進め、3〜5 スライスごとに、求めに応じてマイルストーンレポートを作成します。レポートでは、機械的に検証した内容と、検証していない内容を明確に区別します。

ドメインに期限がある場合（家賃、サブスクリプション、締め切りなど）、ライフサイクル全体のシナリオは、そのライフサイクルを導入するスライスの終了条件に含めます。最後のスライスの終了条件にはしません。references/scenario-tests.md を参照してください。

フェーズ 8 — 最終検証

1. 回帰テストスイート全体を実行します。
2. PRD のすべての受け入れ条件が満たされていることを確認します。
3. 視点のローテーション（品質の視点＋リスクの視点）を、プロジェクト全体に対して最後にもう一度適用します。
4. node "$FORGE/scripts/forge-guard.js" all <anchor> を実行します。
5. state.json を更新します：プロジェクト → validated。
6. インシデントログ（.forge/audit/issues.md）を締めくくり、プロジェクトの監査レポートを生成します。

---

変更管理と影響分析

あらゆる変更には影響が生じる可能性があります。

ユーザーから変更（機能、ルール、インターフェース、アーキテクチャなど）を依頼された場合、影響分析を行わずに変更を適用してはいけません。

影響分析の手順

変更を適用する前に、references/impact-protocol.md の手順に従います。次の内容をユーザーに要約します。

1. 影響を受ける機能：どの業務ルール（B*）が変更、追加、削除されますか？
2. 影響を受けるインターフェース：どの画面を変更する必要がありますか？
3. 影響を受けるモジュール／スライス：どのスライスに手を加える必要がありますか？
4. 影響を受ける依存関係：変更対象に依存するほかのスライスはありますか？
5. 変更が必要なテスト：既存のどのテストが失敗しますか？
6. 更新が必要なドキュメント：PRD、アーキテクチャ、計画、ロードマップのうち、どれを更新する必要がありますか？
7. リスク：気づかないうちに何が壊れる可能性がありますか？
8. 工数：影響の相対的な見積もり（局所的／中程度／大規模／構造的）。

変更を適用する前に、ユーザーがその影響を受け入れることを明示的に確認する必要があります。

変更の適用後

1. 元のドキュメントを更新します（PRD、アーキテクチャ、設計など）。
2. 影響を受けるすべてのドキュメント（計画、ロードマップ、テスト）に変更の影響を反映します。
3. 影響を受けるドキュメントに stale のマークを付けます：state.js set-status <anchor> <kind> <clé> stale。
4. 該当するスライスに対して state.js check-stale を実行します。
5. 全体の整合性を確認します：forge-guard.js all。
6. 整合性が失われた箇所があれば報告します。

---

マルチパースペクティブ — 2 つの検証モード

重要なドキュメントを、一度確認しただけで確定することはありません。モードに応じて、2 つの仕組みを使います。

Guided モード — 視点の切り替え（デフォルト）

メインセッションで、明確に異なる 2 つの視点からドキュメントを読み直します。

1. 品質の視点：不足しているエッジケース、対応するテストのないルール、未対応の非機能要件。
2. リスクの視点：内部の矛盾、未検証の仮定、暗黙の依存関係、見落とし。

その後、修正してから、次のように提示します：「品質とリスクの観点から、このドキュメントを読み直しました。見つけて修正した内容は次のとおりです：[一覧]。判断が必要な点は次のとおりです：[一覧]。」

適用するタイミング：PRD（フェーズ 1）、アーキテクチャ（フェーズ 4）、最終検証（フェーズ 8）の各ゲートの前に必須です。ロードマップ、設計、計画には推奨されます。

サブエージェントではなくセッション内で行う理由：視点の切り替えは即座に実行でき、追加の LLM 呼び出しも不要です。また、セッションで作成したばかりのドキュメントにも、同じレベルの厳密さを適用できます。大半のプロジェクトでは、ゲートごとのエージェントのオーケストレーションを行っても、それに見合う効果は得られません。

Fast Track モード — 専門サブエージェント（自動）

方向性（PRD、規約、設計、画面、承認済みベンチマーク）がすでに承認されている場合、15 件の計画を手作業で検証するのは負担が大きく、形式的な承認につながります。そのため Fast Track では、相互に補完し、見落としを異なる観点から探す専門エージェントに検証を委任し、並行して起動します。

エージェント	探す対象	質問
quality-analyst	欠落	「この仕様は網羅されていますか？」
red-team	誤り	「何がうまくいかないでしょうか？」
plan-validator	標準からの逸脱	「この種のアプリの標準と整合していますか？」

各エージェントには、入力契約（読み取る対象となる唯一のファイル群）と出力契約（厳格な JSON 形式）があります。.forge 全体を見せることはありません。コンテキストにはコストがかかり、コンテキストを詰め込まれた検証エージェントは検証の精度が下がるからです。

決定論的なスクリプトはエージェントより先に実行します。スクリプトなら 1 秒で検出できることを、エージェントは 3 回読み直してようやく見つけることがあります。

入口は実行可能で、拒否する場合は理由を明示します：

node "$FORGE/scripts/forge-guard.js" fast-track <anchor> \
     [--scope plans|phases4-7] [--autonomy milestone|full]

これは forge-guard all には含まれていません。benchmarks はフェーズ 3、test_plan はフェーズ 6 のため、通常のプロジェクトでは失敗してしまうからです。ただし、忘れたために回避されることはありません。state.js status でモードが有効かどうかを確認でき、state.js fast-track --attempt は3 回目の試行で停止します。

完全なプロトコル、開始条件、制限事項、回避策については、references/fast-track.md を参照してください。

---

専門エージェント

各エージェントは契約です。役割、入力一覧、手順、出力形式、そして行わないことの明示的な一覧で構成されます。役割の説明ではなく、委任を可能にするものです。

エージェント	フェーズ	モード	役割
product-analyst	1, 2	作成、レビュー	ディスカバリー、インタビュー、PRD、ユーザーストーリー
scope-architect	2	作成、レビュー	ロードマップ、MVP、バージョン分割、トレードオフ
ux-designer	3	作成、レビュー	標準、ビジュアルの方向性、優先順位付けされたナビゲーション、画面、フロー
systems-architect	4	作成、レビュー	アーキテクチャ、スライス、モジュール、データ、API、依存関係
quality-analyst	1–8	作成、検証	網羅性、エッジケース、テスト計画；Fast Track のバリデーター
red-team	1–8	検証	矛盾、見落とし、未検証の仮定
plan-validator	4, 5	検証	アプリケーションのアーキタイプに関する標準への準拠
premise-challenger	1–4	異議申し立て	ユーザーの仮定に異議を唱えます — 出発点となるアイデア、要望された機能、MVP
scenario-tester	6–8	作成、レビュー	ビジネスシナリオに基づくテスト：ライフサイクル、時間、インバリアント
forge-implementer	7, 8	作成	実装、TDD、検証
client-liaison	0, 4, 5, 7, 8	確認、ストレステスト	クライアントが理解できないこと — 未回答の質問、判定は行いません

premise-challenger は Forge の文書を読み返さない唯一のエージェントです。読み返すのはあなたの要望であり、アイデアが悪い、すでに解決済み、不釣り合い、または適切でないときにはその旨を伝えます。フェーズ 1、2、3 の終わりに起動され、作業途中で機能を追加した場合にも必ず起動されます。critical の判定が 1 つでもあれば、あなたの回答があるまでブロックされます。

client-liaison — クライアントと話す唯一のエージェント

ほかの 10 エージェントはエンジニアです。彼らが探すのは、誤り、不完全さ、またはテスト不能な点です。client-liaison が探すのは理解できない点であり、これは別の専門分野です。文書が完全に正確でも、宛先の人には読めないことがあります。そして、ほかの 10 エージェントにはそれが決してわかりません。全員が、文書の書き手と同じ言葉で読んでいるからです。

モード	質問	出力
check	このクライアントは質問せずに署名できますか？	文書で回答されていない質問
stress	情報を持つクライアントは何と言い、Forge は何を書いていないでしょうか？	主な異議と、沈黙によって生じる代償

判定を下すことはありません。 承認するサブエージェントはクライアントを偽のクライアントに置き換え、ゲートを自己認証にしてしまいます。これはここで最も大きな損失につながる過失です。なぜなら、目に見えないからです。返すのは質問であり、判断するのはクライアントです。

コードも、計画も、アーキテクチャも読みません。この制限は予防措置ではなく、専門分野そのものです。アーキテクチャを読んだ人が書くクライアント向け文書には、必ずアーキテクチャが含まれます。このエージェントの価値は、アーキテクチャを読んでいないことに全面的にあります。

契約（フェーズ 0）、各差異の報告、および実装前のチェックポイントで使用します。

サブエージェントを利用できない場合：現在のフェーズに適したエージェントの指示を読み込み、姿勢の切り替えを適用します。この場合、Fast Track は利用できません — Guided モードが引き継ぎます。

---

Audit — Forge を自身の実行から改善する

Forge の実行ごとに、.forge/audit/ に次の情報が記録されます。

ファイル	種類	用途
run-log.jsonl	機械向け、追記専用	すべてのイベント：遷移、ゲート、バリデーター、ガードレール、インシデント
issues.md	人間向け	インシデントログ：症状、根本原因、回避策、是正措置
metrics.json	機械向け	集計カウンター

記録されていないインシデントは、発生していないのと同じです。 これこそが、スキルを改善するための唯一のデータです。

記録が必要な内容

node "$FORGE/scripts/state.js" log <anchor> <type> "<message>" [k=v ...]

必ず記録する種類：

状況	種類
サブエージェントが REVISE を返す	fast_track_validate
サブエージェントが BLOCK を返す	fast_track_block
ユーザーが出力を修正する（「違います、そうではありません」）	user_correction
ガードレールが失敗する	guard_failure
スクリプトが失敗する	script_failure
状態の不一致が検出される	（sync による自動記録）
.forge の外で成果物が見つかる	（strays --relocate による自動記録）
フェーズを再開する必要がある	phase_retry
人間によるゲートが却下される	gate_revise
ユーザーが Fast Track を終了する	fast_track_escape

issues.md の origine 列（forge / projet / environnement）は、最も重要なフィールドです。「Forge の誘導に問題があった」のか、「PRD が曖昧だった」のかを区別できます。

プロジェクト横断分析

node "$FORGE/scripts/audit-report.js" <dossier-contenant-les-projets> --out reports/

複数プロジェクトのログを統合し、失敗を正規化されたシグネチャごとに分類して、構造的な問題（複数プロジェクトで発生するため、スキルに起因）と、単発のインシデント（1つのプロジェクト内で発生）を区別します。通常は 0 で終了し、構造的な問題が検出された場合は 2 で終了します。

---

検証の規律

これらのルールは好みではありません。実際のプロジェクトで蓄積された43件の修正から導かれた結論です。その43件すべてが知識不足ではなく、検証ミスでした。エージェントは知っていました。欠けていたのは、その知識を実際のファイルに適用する手順でした。

ここに記されているのは、これまでルールとして採用されてこなかったからです。ルールにならない指摘は、何も変えていません。

1. 主張には、それを検証する実行が伴います。 「Xを行うコードは存在しない」はシステムに関する主張であり、「コードがXを行う」と同じ厳密さが求められます。ブロック全体を読むか、何も主張しないでください。

2. 終了コードは結果ではありません。 コマンドが無視されていても、終了コードが0になることがあります。非推奨のフラグが黙って削除された場合も、該当箇所のない replace も、どちらも誤った成功を示しました。

3. 変更の有無を確認するチェックでは、内容を検証できません。 ファイルが変更されたことを証明するチェックゲートが証明するのは、ファイルが変更されたということだけです。その内容が正しいことまでは証明しません。

4. 変更された箇所しか見られないチェックでは、見落とされたものを決して検出できません。 git status が示すのは変更された箇所です。更新されていないファイルは、最新のファイルと見分けがつきません。

5. テスト対象のルールをテスト自体が再実装しているなら、ルールではなく、その複製をテストしています。 しかも、そのテストは通ります。

6. 誤った理由で通るテストは、失敗するテストよりも悪質です。 本当の不具合を見つけるはずだったテストの場所を占めてしまうからです。

7. 不具合のある行に触れないテストは、カバレッジではありません。 「ルールが書かれている」ことと「ルールが実際に組み込まれている」ことは同じではありません。

8. 期待値は主張であり、作り出すものではありません。 テストデータについての問いとして書き、その問いに答えてください。テスト対象のコードと同じコードで計算された期待値は、何も検証しません。

9. 不変条件には明確な形が必要です。 対称性は 仮定 するものですが、不変条件は証明するものです。「ただし、〜の場合を除く」としか書けないなら、それは不変条件ではありません。

10. 事実は一つ、表現は一つです。 二つの場所で同じものを計算していても、どちらも整合性を取っていません。両者が食い違ったとき、どちらが正しいのか誰にも分かりません。正規の関数を一つだけ抽出してください。計算箇所を二つにしてはいけません。

11. 二つのテストがない境界は、境界ではありません。 正常系の経路しか通らないテストでは、それ以外の何も検証できません。

12. 文書化できないルールは削除すべきルールです。 そして、実行できないルールは飾りにすぎません。

13. 適用範囲のない指摘は不完全です。 採用先がないため、何も変えません。

14. ルールファイルに反映されない指摘は、何も変えていません。 それはルールに 加えて 読まれるのではなく、ルールの 代わりに 読まれてしまいます。

---

参考資料

スクリプト — 決定的で、依存関係なし

呼び出し方法：node "$FORGE/scripts/<fichier>" [<anchor>] [args…]。$FORGE は スキルのフォルダーです。前述の「スクリプトの実行方法」を参照してください。

例外は1つだけで、明示されています：ddl-exec.js は PostgreSQL エンジン （@electric-sql/pglite）を読み込み、DDLを実行します。このエンジンは リポジトリの開発時依存関係であり、配布されるスキルの依存関係ではありません。エンジンがない場合、スクリプトは何もシミュレートせず、skipped を返し、実行しなかった内容を伝え、インストールするためのコマンドを示します。実行していないのに実行したと主張するチェックは、成功を示してしまうため、最悪のチェックです。

スクリプト	役割	タイミング
state.js start	実際の状態：フェーズ、ゲート、テストケース数を含むスライス、昇格されていない所見	ステップ0、毎回のセッション
state.js anchor	現在のプロジェクトを解決し、参照プロジェクトを拒否	ステップ0 bis
state.js finding	昇格先のドメインを指定して所見を振り分け	不具合が見つかったらすぐ
state.js set-status	権威ある情報源とそのミラーを1回の操作で書き込む	ステータス変更のたび
state.js sync	状態 ↔ フロントマターを同期	各ゲートの前
state.js set-nav	ナビゲーション順とその根拠を記録	フェーズ3
state.js check-stale	派生ドキュメント、または承認後に変更された計画を確認	実装の前
state.js dep	スライスまたは基盤の依存関係グラフを宣言	フェーズ4
state.js amend	修正を記録し、番号の振り直しを拒否。amended_from、理由、変更一覧を書き込む	各修正時
state.js migrate	v1 → v2	既存プロジェクト
forge-guard.js all	パス、状態、用語、同期、derived_from の出所情報、先行して生成された成果物、不要な文字、「要決定」項目、プレースホルダー、バージョン、プロジェクトメモリー、キットの整合性、宣言済みツール、未記録のインシデント	各ゲートの前
forge-guard.js memory-present	4つのメモリーファイルが存在し、AGENTS.md に3つすべてが起動条件とともに記載されていることを確認	フェーズ0、その後は各ゲート
forge-guard.js kit-integrity	キットのスクリプトが記録済みのフィンガープリントと一致することを確認。スクリプトの変更はハードエラー、ドキュメントの変更は警告	各ゲートの前
forge-guard.js kit-integrity --write-manifest	.forge/kit-manifest.json を書き込む — 明示的な操作であり、自動では実行されません	1回、およびキットの更新後
forge-guard.js tools	補助スクリプトがすべて .forge/tools/ にあり、目的とともに宣言されていることを確認	各ゲートの前
forge-guard.js incidents	ゲートが検出した逸脱が .forge/audit/issues.md に記録されていることを確認	各ゲートの前
consistency-check.js all	成果物間の不整合：PRD ↔ アーキテクチャ ↔ 計画 ↔ テスト ↔ 画面、および解決済みのセクション参照	各ゲートの前
forge-exit.js	スライスの終了条件を実行	フェーズ7、スライスごと
coverage-check.js	スライス計画のカバレッジ	フェーズ5
design-check.js	コントラスト（WCAG 1.4.3 / 1.4.11）、値のないトークン、およびコンポーネントと画面の表示範囲の同等性を測定	フェーズ3、ゲート時
ddl-exec.js	アーキテクチャのDDLを実行：PostgreSQLが拒否するかどうかを確認します。DDLが変更対象のテーブルを作成すること、および宣言済みのガードが機能することを検証	フェーズ4、ゲート時
dependency-check.js	循環依存、トポロジカル順序。--write でグラフを保存	フェーズ4
audit-report.js	複数プロジェクトの横断分析	複数のプロジェクトの後
selftest	スキル自体のテスト	公開前

確認項目は、失敗を目にするまでは検証済みとは言えません

追加または変更した確認項目はすべて、同じ変更セット内で、検出対象としている不具合を再現させる必要があります — そして正常な証人は通過させます。両方です。

これは形式的な予防策ではありません。同じプロジェクトで2回確認されています。PowerShellで Get-Content -Raw と正規表現 \u を使ったスキャンは、破損したファイルに対して「問題なし」と判定しました。それを置き換えたNodeのスキャンは、破損箇所がCJKだという前提で設計されたため、_USERNAMEOục 内の U+1EE1 を含むファイルを正常と判定しました — Latin Extended Additionalです。3つ目の異物は、ホワイトリストを導入して初めて見つかりました。

そこから導かれるルールは3つです。

1. 疑わしい文字のリストではなく、ホワイトリストを使います。 許可対象 = ASCII + Latin-1 + Latin Extended-A + 句読点 + 記号 + 絵文字 + リポジトリの言語で使うタイポグラフィ（序数 1ᵉʳ、下付き文字 CO₂）。それ以外はすべて報告します。 このホワイトリストの初回テストでは、正しいフランス語の序数が28件も報告されました。リポジトリの言語を網羅しないホワイトリストは、無効化される確認項目になってしまいます。
2. unicode-scan:ignore と記された行は無視します。ログ内で不具合を引用しても、その引用が検出されないようにするためです。これがないと、不具合を証明するレポートをコミットできません。
3. skip は pass ではありません。 実行されない確認項目は、何を検査できなかったかを明示します。失敗を一度も目にしていない確認項目は、検証済みではなく、未確認です。

そして、入力が生成物ファイルである確認項目については、all に組み込む前に実際のプロジェクトで検証する必要があります。手動で実行する確認項目は、all の対象外でもコマンドから利用できます。

参考ドキュメント

ファイル	内容
references/skill-boundaries.md	Forge と project-rules-architect の担当範囲；検出事項の振り分け
references/state-schema.md	.forge/state.json（v2）の形式、書き込みルール、正とする情報源
references/migration-v1-v2.md	過剰な内容を含む state.json v1 の移行手順
references/module-prioritization.md	利用頻度に基づくモジュールとナビゲーションの順序付け
references/design-quality.md	汎用的なデザインを避けるための禁止事項、必須のデザインスキル、ビジュアルの方向性
references/scenario-tests.md	業務シナリオ別テスト — ライフサイクル、注入されたクロック、不変条件
references/test-strategies.md	テストの種類、選び方、デバイスなしで実行できるもの
references/archetypes.md	アーキタイプ別の標準と、測定された繰り返し発生する問題
references/research-protocol.md	再発明しないこと：コードではなく不変条件を抽出する
references/fast-track.md	自動検証、2段階の自律性、制限事項
references/impact-protocol.md	変更の影響分析プロトコル
references/review-checklists.md	ドキュメントの種類別ゲートチェックリスト

プロダクトインタビューは agents/product-analyst.md に記載されています。

---

ワークフローの概要

anchor → Interview (Phase 1) → PRD → Roadmap (Phase 2)
  → Standards + Direction + Navigation priorisée + Design (Phase 3)
  → Architecture (Phase 4) → Plans d'implémentation (Phase 5) → Tests (Phase 6)
  → Implémentation (Phase 7) → Validation (Phase 8)

全工程を通じて、次の点も重要です。

Anchor résolu · Livrables dans .forge · État = autorité, front matter = miroir
Gates humains (ou Fast Track) · Analyse d'impact · Multi-perspective
Identifiants stables · Exhaustivité · Garde-fous déterministes · Audit