ビルドスクリプト: 世界最高基準テンプレート18点パック生成

from pathlib import Path

base = Path('/home/ubuntu/world_class_template_pack')
base.mkdir(parents=True, exist_ok=True)

common_header = """---
version: 1.0
author: Manus AI
purpose: 非エンジニアの希望を、世界最高基準の開発前文書・検証・レビュー・改善ループへ変換するためのテンプレート
status: template
---

"""

templates = {}

templates['00_index.md'] = common_header + """# 世界最高基準リサーチ駆動・安全実装テンプレート体系 Index

このテンプレート体系は、非エンジニアが「やりたいこと」を伝えるだけで、リサーチ、要件定義、仕様書、技術要件、アーキテクチャ、ハーネス設計、テスト計画、CI品質ゲート、リスク対策、レビュー、再リサーチ、再提案までを一貫して作るための実務フォーマットである。

## 使用順序

| 順番 | ファイル | 目的 | 完了条件 |
|---:|---|---|---|
| 1 | 01_intent_intake_template.md | 希望を構造化する | やりたいこと、対象者、制約が明文化されている |
| 2 | 02_research_plan_template.md | 調査計画を作る | 公式、論文、コミュニティ、競合、規約の調査範囲がある |
| 3 | 03_evidence_matrix_template.md | 根拠を紐づける | 各重要判断に一次ソースまたは仮説ラベルがある |
| 4 | 04_prd_template.md | プロダクト要件を定義する | 価値、MVP、成功指標、非対象が決まっている |
| 5 | 05_requirements_definition_template.md | 要件定義を作る | Must要件に受入基準とテストIDがある |
| 6 | 06_functional_spec_template.md | 機能仕様を作る | 画面、操作、状態、例外が定義されている |
| 7 | 07_technical_requirements_template.md | 技術要件を作る | 性能、セキュリティ、運用、外部依存が定義されている |
| 8 | 08_architecture_design_template.md | アーキテクチャを作る | C4、責務、データ流、ADRがある |
| 9 | 09_sdd_template.md | 詳細設計を作る | 実装単位、データモデル、API、例外処理がある |
| 10 | 10_harness_design_template.md | 安全検証ハーネスを作る | dry-run、mock、sandbox、kill switchがある |
| 11 | 11_test_plan_template.md | テスト計画を作る | 単体、統合、E2E、回帰、受入の範囲がある |
| 12 | 12_ci_quality_gate_template.md | CI品質ゲートを作る | 自動判定の赤緑条件がある |
| 13 | 13_risk_register_template.md | リスク台帳を作る | リスク、影響、対策、残余リスクがある |
| 14 | 14_external_api_terms_template.md | 外部API・規約確認を作る | 公式ドキュメント、規約、自動化制限が確認済み |
| 15 | 15_codex_review_template.md | Codexレビューを依頼する | 実装・テスト・CI観点のレビュー指示がある |
| 16 | 16_opus_reanalysis_template.md | Opus再分析を依頼する | 採否・運用・事業リスクの再判断指示がある |
| 17 | 17_discovery_reproposal_log_template.md | 発見と再提案を管理する | 発見事項が再リサーチと再提案に戻っている |
| 18 | 18_red_yellow_green_gate_template.md | 素人向け意思決定を行う | GO/CONDITIONAL GO/NO-GO/ESCALATEが明確 |

## 絶対ルール

すべてのMust要件は、受入基準、テストID、根拠ID、リスクIDのいずれかを欠いてはならない。欠けた場合は、実装開始ではなく、再リサーチまたは再提案に戻す。
"""

templates['01_intent_intake_template.md'] = common_header + """# 01. Intent Intake Template：やりたいこと入力シート

## 1. 非エンジニア入力欄

| 項目 | 記入欄 | 補足 |
|---|---|---|
| やりたいこと |  | 専門用語不要。何を実現したいかを書く。 |
| 誰のためか |  | 自分、顧客、社内、一般ユーザーなど。 |
| なぜ必要か |  | 困りごと、期待する変化、避けたい失敗を書く。 |
| いつまでに必要か |  | 希望時期。不明なら「未定」。 |
| 使いたいサービス |  | 例: Google Drive、GitHub、SNS、決済、AI API。 |
| 絶対に避けたいこと |  | 誤投稿、課金事故、情報漏えい、アカウント停止など。 |
| 予算・運用制約 |  | 無料優先、月額上限、手作業可否など。 |

## 2. AIによる構造化欄

| ID | 仮説化された目的 | 成功状態 | 失敗状態 | 要確認 |
|---|---|---|---|---|
| INT-001 |  |  |  |  |

## 3. 初期赤黄緑判定

| 判定 | 条件 | 該当 | 理由 |
|---|---|---|---|
| 緑 | 既存の安全な手作業を補助するだけ |  |  |
| 黄 | 外部API、認証、DB、定期実行を含む |  |  |
| 赤 | 課金、投稿、削除、本番データ、規約違反リスクを含む |  |  |

## 4. 次に必要な調査

| 調査ID | 調査テーマ | 必要な理由 | 優先度 |
|---|---|---|---|
| RES-001 |  |  | High/Medium/Low |
"""

templates['02_research_plan_template.md'] = common_header + """# 02. Research Plan Template：強化リサーチ計画

## 1. 調査目的

この調査は、やりたいことを実現するための材料を集めるだけでなく、実現不可能性、規約違反、開発破綻、運用事故、代替案を発見するために行う。

## 2. 調査スコープ

| 領域 | 調査対象 | 必須ソース | 完了条件 |
|---|---|---|---|
| 公式仕様 | API、SDK、利用上限、認証、Webhook | 公式ドキュメント | 主要制約がEvidence Matrixに登録済み |
| 規約 | 利用規約、自動化制限、商用利用 | 公式規約 | 赤条件が抽出済み |
| 技術実装 | 類似実装、GitHub、SDK例 | 公式サンプル、OSS | 実装可能性が判定済み |
| セキュリティ | 認証、秘密情報、権限、データ保護 | OWASP、NIST、公式 | セキュリティ要件に反映済み |
| テスト | テスト手法、CI、mock、sandbox | 公式、実務記事 | ハーネス設計に反映済み |
| コミュニティ | 失敗例、制約、ハッカソン事例 | GitHub Issues、Forum | リスク台帳に反映済み |

## 3. 調査ログ

| RES-ID | 論点 | ソースURL | 種別 | 信頼度 | 要約 | 反映先 |
|---|---|---|---|---|---|---|
| RES-001 |  |  | 公式/論文/コミュニティ/実装例 | High/Medium/Low |  | EVD/REQ/SPEC/TECH/HRN/RSK |

## 4. 再リサーチ発火条件

| 条件 | 戻り先 | 実施内容 |
|---|---|---|
| 一次ソースがない | Research | 公式・規約・論文を再検索する |
| Codexが実装不能を検出 | Research/Technical | API・SDK・類似実装を再確認する |
| Opusが採否不明と判断 | Research/Product | 目的・代替案・MVP境界を再調査する |
| テストで再現不能 | Research/Harness | mock、fixture、sandbox、CI事例を再調査する |
"""

templates['03_evidence_matrix_template.md'] = common_header + """# 03. Evidence Matrix Template：根拠接続表

## 1. Evidence Matrix

| EVD-ID | 主張・判断 | ソース | ソース種別 | 信頼度 | 反映先ID | 未確認リスク | 次アクション |
|---|---|---|---|---|---|---|---|
| EVD-001 |  |  | 公式/標準/論文/実装例/コミュニティ/仮説 | High/Medium/Low | REQ- / SPEC- / TECH- / HRN- |  |  |

## 2. 根拠品質基準

| 評価 | 条件 | 使い方 |
|---|---|---|
| High | 公式ドキュメント、標準、査読論文、一次情報 | Must要件やNO-GO判断に使える |
| Medium | 公式ブログ、主要OSS、信頼できる技術記事 | 設計候補や実装方針に使える |
| Low | 個人記事、断片的なForum、未検証SNS投稿 | 仮説として扱い、再確認が必要 |

## 3. 根拠不足時のルール

根拠がLowまたは仮説のままの項目は、Must要件にしてはならない。Mustにする必要がある場合は、再リサーチを行い、HighまたはMediumの根拠へ引き上げる。
"""

templates['04_prd_template.md'] = common_header + """# 04. Product Requirements Document Template：プロダクト要件定義

## 1. 概要

| 項目 | 内容 |
|---|---|
| プロダクト名 |  |
| 解決する課題 |  |
| 対象ユーザー |  |
| 主要価値 |  |
| 成功指標 |  |
| 非対象 |  |

## 2. MVP範囲

| PRD-ID | 機能・価値 | 優先度 | 採用理由 | 根拠ID | 除外条件 |
|---|---|---|---|---|---|
| PRD-001 |  | Must/Should/Later/Reject |  | EVD- |  |

## 3. ユーザーストーリー

| US-ID | ユーザーとして | したいこと | その理由 | 受入基準ID |
|---|---|---|---|---|
| US-001 |  |  |  | AC- |

## 4. 成功・失敗の定義

| 区分 | 定義 | 測定方法 | 判定周期 |
|---|---|---|---|
| 成功 |  |  |  |
| 失敗 |  |  |  |
| 中止 |  |  |  |
"""

templates['05_requirements_definition_template.md'] = common_header + """# 05. Requirements Definition Template：要件定義書

## 1. 機能要件

| REQ-ID | 要件 | 優先度 | 根拠ID | 受入基準ID | テストID | リスクID | 状態 |
|---|---|---|---|---|---|---|---|
| REQ-001 |  | Must/Should/Later/Reject | EVD- | AC- | TST- | RSK- | Draft/Reviewed/Approved |

## 2. 非機能要件

| NFR-ID | 分類 | 要件 | 測定方法 | 閾値 | テストID | リスクID |
|---|---|---|---|---|---|---|
| NFR-001 | 性能/可用性/セキュリティ/保守性/監査性 |  |  |  | TST- | RSK- |

## 3. 受入基準

| AC-ID | 対象REQ | Given | When | Then | 自動化可否 | テストID |
|---|---|---|---|---|---|---|
| AC-001 | REQ- |  |  |  | Yes/No | TST- |

## 4. NO-GO条件

Must要件に根拠ID、受入基準ID、テストID、リスクIDのいずれかが欠ける場合、実装開始はNO-GOとする。
"""

templates['06_functional_spec_template.md'] = common_header + """# 06. Functional Specification Template：機能仕様書

## 1. 機能一覧

| SPEC-ID | 対象REQ | 機能名 | 入力 | 処理 | 出力 | 例外 | テストID |
|---|---|---|---|---|---|---|---|
| SPEC-001 | REQ- |  |  |  |  |  | TST- |

## 2. 画面・操作仕様

| UI-ID | 画面/操作 | ユーザー操作 | システム反応 | エラー表示 | 権限 | 関連SPEC |
|---|---|---|---|---|---|---|
| UI-001 |  |  |  |  |  | SPEC- |

## 3. 状態遷移

| STATE-ID | 現在状態 | イベント | 次状態 | 禁止遷移 | テストID |
|---|---|---|---|---|---|
| STATE-001 |  |  |  |  | TST- |

## 4. 例外・失敗時仕様

| ERR-ID | 失敗条件 | ユーザー表示 | 内部処理 | ログ | 復旧方法 | リスクID |
|---|---|---|---|---|---|---|
| ERR-001 |  |  |  |  |  | RSK- |
"""

templates['07_technical_requirements_template.md'] = common_header + """# 07. Technical Requirements Template：技術要件定義

## 1. 技術スタック

| TECH-ID | 項目 | 採用候補 | 採用理由 | 代替案 | 根拠ID | リスクID |
|---|---|---|---|---|---|---|
| TECH-001 | 言語/Framework/DB/Hosting/API |  |  |  | EVD- | RSK- |

## 2. セキュリティ要件

| SEC-ID | 対象 | 要件 | 実装方針 | 検証方法 | テストID | ゲート |
|---|---|---|---|---|---|---|
| SEC-001 | 認証/認可/秘密情報/入力検証/監査 |  |  |  | TST- | Green/Yellow/Red |

## 3. 性能・可用性・運用要件

| OPS-ID | 項目 | 目標 | 測定方法 | アラート | 復旧方針 | テストID |
|---|---|---|---|---|---|---|
| OPS-001 |  |  |  |  |  | TST- |

## 4. 外部依存

| DEP-ID | 外部サービス | 用途 | 代替策 | 障害時挙動 | 利用上限 | 規約確認ID |
|---|---|---|---|---|---|---|
| DEP-001 |  |  |  |  |  | EXT- |
"""

templates['08_architecture_design_template.md'] = common_header + """# 08. Architecture Design Template：アーキテクチャ設計書

## 1. コンテキスト

| ARC-ID | システム | 外部利用者 | 外部システム | 主な責務 | 境界外 |
|---|---|---|---|---|---|
| ARC-001 |  |  |  |  |  |

## 2. コンテナ・コンポーネント設計

| CMP-ID | コンポーネント | 責務 | 入力 | 出力 | 依存 | 失敗時挙動 |
|---|---|---|---|---|---|---|
| CMP-001 |  |  |  |  |  |  |

## 3. データフロー

| FLOW-ID | 開始 | 終了 | データ | 保存場所 | 保護方法 | ログ |
|---|---|---|---|---|---|---|
| FLOW-001 |  |  |  |  |  |  |

## 4. ADR：設計判断記録

| ADR-ID | 判断 | 採用案 | 却下案 | 採用理由 | 根拠ID | 見直し条件 |
|---|---|---|---|---|---|---|
| ADR-001 |  |  |  |  | EVD- |  |
"""

templates['09_sdd_template.md'] = common_header + """# 09. Software Design Document Template：詳細設計書

## 1. 実装単位

| SDD-ID | 対象SPEC | モジュール | 責務 | 公開I/F | 内部I/F | テストID |
|---|---|---|---|---|---|---|
| SDD-001 | SPEC- |  |  |  |  | TST- |

## 2. データモデル

| DATA-ID | エンティティ | フィールド | 型 | 制約 | 個人情報 | 保存期間 |
|---|---|---|---|---|---|---|
| DATA-001 |  |  |  |  | Yes/No |  |

## 3. API設計

| API-ID | メソッド | パス | 入力 | 出力 | 認証 | エラー | テストID |
|---|---|---|---|---|---|---|---|
| API-001 |  |  |  |  |  |  | TST- |

## 4. 例外処理・ログ

| LOG-ID | 事象 | ログレベル | 含める情報 | 含めない情報 | アラート | 復旧手順 |
|---|---|---|---|---|---|---|
| LOG-001 |  |  |  | 秘密情報・個人情報 |  |  |
"""

templates['10_harness_design_template.md'] = common_header + """# 10. Harness Design Template：安全検証ハーネス設計

## 1. ハーネスの目的

ハーネスは、壊してはいけない本番環境、外部アカウント、課金、投稿、データ削除を直接触らずに、実装の正しさを検証するための仕組みである。

## 2. 検証境界

| HRN-ID | 検証対象 | 本番接続 | 代替手段 | 許可操作 | 禁止操作 | Kill Switch |
|---|---|---|---|---|---|---|
| HRN-001 |  | No/Read-only/Limited | mock/sandbox/fixture/dry-run |  |  | あり/なし |

## 3. ハーネス構成

| 部品 | 役割 | 実装方法 | 失敗時挙動 | ログ | テストID |
|---|---|---|---|---|---|
| Mock |  |  |  |  | TST- |
| Fixture |  |  |  |  | TST- |
| Dry-run |  |  |  |  | TST- |
| Sandbox |  |  |  |  | TST- |

## 4. 破壊防止ルール

| ルールID | ルール | 強制方法 | 違反時処理 |
|---|---|---|---|
| SAFE-001 | 本番データの書き込みは明示承認まで禁止 | CI/環境変数/権限 | 即停止 |
| SAFE-002 | 外部投稿・課金・削除はdry-runを既定にする | feature flag | 即停止 |
| SAFE-003 | テストを弱体化する変更は人間承認必須 | PR check | NO-GO |
"""

templates['11_test_plan_template.md'] = common_header + """# 11. Test Plan Template：テスト計画

## 1. テスト戦略

| TST-ID | 種別 | 対象 | 目的 | 自動化 | 実行タイミング | 合格条件 |
|---|---|---|---|---|---|---|
| TST-001 | Unit/Integration/E2E/Regression/Security/Acceptance |  |  | Yes/No | PR/merge/release/manual |  |

## 2. 要件トレーサビリティ

| REQ-ID | AC-ID | SPEC-ID | TST-ID | CI-ID | 状態 |
|---|---|---|---|---|---|
| REQ- | AC- | SPEC- | TST- | CI- | 未作成/作成済/自動化済/合格 |

## 3. テストデータ

| DATASET-ID | 用途 | データ種別 | 個人情報 | 生成方法 | 削除方法 |
|---|---|---|---|---|---|
| DS-001 |  | synthetic/fixture/sandbox | Yes/No |  |  |

## 4. テスト弱体化検出

| 検出項目 | NO-GO条件 | 例外承認 |
|---|---|---|
| skip追加 | 承認なしのskipはNO-GO | 理由、期限、代替テスト必須 |
| coverage低下 | 閾値未満はNO-GO | 一時許可は期限付き |
| flaky放置 | 再現調査なしはNO-GO | 隔離と再発防止が必須 |
"""

templates['12_ci_quality_gate_template.md'] = common_header + """# 12. CI Quality Gate Template：CI品質ゲート設計

## 1. CIゲート一覧

| CI-ID | ゲート | 実行条件 | 合格条件 | 失敗時処理 | 素人向け表示 |
|---|---|---|---|---|---|
| CI-001 | lint | PRごと | error 0 | 修正までmerge禁止 | 赤: 文法/品質エラー |
| CI-002 | test | PRごと | 全テスト合格 | 修正までmerge禁止 | 赤: 動作保証なし |
| CI-003 | build | PRごと | build成功 | 修正までmerge禁止 | 赤: 配布不能 |
| CI-004 | secret scan | PRごと | secret 0 | 即停止 | 赤: 情報漏えい危険 |

## 2. 赤黄緑変換

| CI状態 | 判定 | 非エンジニア向け意味 | 次アクション |
|---|---|---|---|
| 全部成功 | 緑 | 前進してよい | 次のレビューへ進む |
| 一部警告 | 黄 | 本番前に確認が必要 | 隔離PoCまたは修正 |
| 失敗あり | 赤 | 進めると壊れる可能性が高い | 実装停止、再リサーチまたは修正 |

## 3. NO-GO条件

mainブランチへの直接push、自動テストなし、secret scanなし、rollbackなし、テストskip放置、coverage閾値未定義はNO-GOとする。
"""

templates['13_risk_register_template.md'] = common_header + """# 13. Risk Register Template：開発破綻・運用事故リスク台帳

## 1. リスク一覧

| RSK-ID | リスク | 分類 | 発生確率 | 影響 | 検出方法 | 対策 | 残余リスク | 判定 |
|---|---|---|---|---|---|---|---|---|
| RSK-001 |  | 要件/技術/規約/セキュリティ/運用/データ/課金/投稿 | High/Medium/Low | High/Medium/Low |  |  |  | Green/Yellow/Red |

## 2. 重大リスク標準分類

| 分類 | 典型例 | 既定判定 |
|---|---|---|
| 本番データ破壊 | DB削除、上書き、migration失敗 | 赤 |
| 外部投稿事故 | SNS誤投稿、メール誤送信 | 赤 |
| 課金事故 | API大量実行、決済誤処理 | 赤 |
| 規約違反 | 自動化禁止、スクレイピング禁止 | 赤 |
| 認証事故 | token漏えい、権限過大 | 赤 |
| テスト弱体化 | skip追加、assert削除 | 赤 |
| 要件曖昧 | 受入基準なし | 黄以上 |

## 3. 対策の完了条件

リスクは、対策を書いただけでは完了しない。検出方法、テストID、CIゲート、運用手順、責任者、残余リスクが記入され、赤または黄の理由が明文化されて初めてレビュー可能とする。
"""

templates['14_external_api_terms_template.md'] = common_header + """# 14. External API & Terms Template：外部API・規約・自動化制限チェック

## 1. 外部サービス一覧

| EXT-ID | サービス | 用途 | 公式Docs | 規約URL | 認証方式 | Rate Limit | Sandbox | 判定 |
|---|---|---|---|---|---|---|---|---|
| EXT-001 |  |  |  |  | OAuth/API Key/Other |  | あり/なし | Green/Yellow/Red |

## 2. 自動化制限

| EXT-ID | 自動化内容 | 許可/禁止/不明 | 根拠 | リスク | 対策 | 人間承認 |
|---|---|---|---|---|---|---|
| EXT-001 | 投稿/削除/取得/課金/通知 |  | EVD- | RSK- |  | 要/不要 |

## 3. 利用上限・費用

| EXT-ID | 制限 | 超過時挙動 | 監視方法 | 課金上限 | Kill Switch |
|---|---|---|---|---|---|
| EXT-001 |  |  |  |  |  |

## 4. NO-GO条件

規約URL、公式Docs、認証方式、Rate Limit、停止方法、費用上限が未確認の外部サービスをMust機能に使う場合はNO-GOとする。
"""

templates['15_codex_review_template.md'] = common_header + """# 15. Codex Review Template：実装・テスト・CI破綻レビュー依頼

## 1. 目的

Codexには、要件の良し悪しではなく、実装可能性、テスト可能性、CIで検出可能か、差分が安全か、テスト弱体化がないかを重点的にレビューさせる。

## 2. 入力資料

| 資料 | パスまたは内容 | 必須 |
|---|---|---|
| 要件定義 |  | 必須 |
| 仕様書 |  | 必須 |
| 技術要件 |  | 必須 |
| ハーネス設計 |  | 必須 |
| テスト計画 |  | 必須 |
| リスク台帳 |  | 必須 |
| 差分/PR |  | 実装時必須 |

## 3. コピー用レビュー依頼プロンプト

```text
あなたは実装・テスト・CI破綻を検出するシニアレビュー担当です。以下の資料を読み、要件の思想ではなく、実装不能、テスト不能、CI不能、復旧不能、データ破壊、テスト弱体化、外部API依存破綻を発見してください。

必ず以下の形式で出力してください。

1. 総合判定: GO / CONDITIONAL GO / NO-GO / ESCALATE
2. Blocker一覧
| ID | 問題 | 根拠 | 影響 | 修正案 | 反映先 |
3. Warning一覧
| ID | 問題 | 根拠 | 影響 | 修正案 | 反映先 |
4. テスト不足
| REQ/SPEC | 不足テスト | 追加すべきテスト | CI化可否 |
5. ハーネス不足
| 対象 | 危険操作 | 必要なmock/sandbox/dry-run/kill switch |
6. テスト弱体化の疑い
| 箇所 | 内容 | 危険性 | 対応 |
7. 非エンジニア向け赤黄緑判定
| 領域 | 判定 | 理由 | 次アクション |

資料:
<<<ここに資料を貼る>>>
```
"""

templates['16_opus_reanalysis_template.md'] = common_header + """# 16. Opus Re-Analysis Template：採否・運用・事業リスク再分析依頼

## 1. 目的

Opusには、Codexが見つけた技術的疑義やテスト不足を受けて、要件採否、MVP境界、事業目的との整合、運用可能性、規約・倫理・安全性、素人運用可能性を再分析させる。

## 2. コピー用再分析プロンプト

```text
あなたは要件採否、運用リスク、MVP境界、非エンジニア運用可能性を判断する上級アーキテクトです。以下の資料とCodexレビュー結果を読み、単なる修正案ではなく、要件・仕様・設計・ハーネス・テスト・リスク台帳へ戻す再提案を作成してください。

必ず以下の形式で出力してください。

1. 総合判定: GO / CONDITIONAL GO / NO-GO / ESCALATE
2. 採否見直し
| ID | 現在の扱い | 推奨扱い | 理由 | 根拠 | 反映先 |
3. MVP境界の再提案
| 機能 | Must/Should/Later/Reject | 理由 | 代替案 |
4. 運用リスク
| リスク | 非エンジニアが気づきにくい理由 | 対策 | ゲート |
5. 再リサーチ指示
| 論点 | 探すべき一次ソース | 期待する判断材料 |
6. テンプレート更新指示
| 更新対象 | 追加/修正内容 | 理由 |
7. 素人向け説明
専門用語を抑え、何を止め、何を小さく試し、何が確認できれば進めるか説明してください。

資料:
<<<ここに資料を貼る>>>

Codexレビュー結果:
<<<ここにCodex結果を貼る>>>
```
"""

templates['17_discovery_reproposal_log_template.md'] = common_header + """# 17. Discovery & Reproposal Log Template：発見・再リサーチ・再提案ログ

## 1. 発見台帳

| DRL-ID | 発見元 | 発見内容 | 重大度 | 影響範囲 | 戻り先 | 担当 | 状態 |
|---|---|---|---|---|---|---|---|
| DRL-001 | Codex/Opus/CI/Test/User/Research |  | Blocker/Warning/Info | REQ/SPEC/TECH/HRN/TST/RSK | Research/Definition/Design/Test |  | Open/In Progress/Closed |

## 2. 再リサーチログ

| DRL-ID | 再調査論点 | 確認ソース | 新Evidence | 判断変更 | 反映先 |
|---|---|---|---|---|---|
| DRL-001 |  |  | EVD- | あり/なし |  |

## 3. 再提案ログ

| Proposal-ID | 対象DRL | 提案 | 採用/保留/棄却 | 理由 | 反映先 | 再レビューID |
|---|---|---|---|---|---|---|
| PROP-001 | DRL- |  |  |  |  | CDR-/OAR- |

## 4. ループ終了条件

Blockerが0件になり、黄リスクに隔離PoCまたは人間承認が設定され、Must要件に根拠・受入基準・テスト・リスクが紐づいた場合のみ、次段階へ進む。
"""

templates['18_red_yellow_green_gate_template.md'] = common_header + """# 18. Red / Yellow / Green Gate Template：非エンジニア向け意思決定ゲート

## 1. 総合判定

| 判定 | 意味 | 実行可能アクション |
|---|---|---|
| Green | 必須根拠、テスト、復旧、ゲートが揃っている | 次段階へ進む |
| Yellow | 未確認があるが、隔離環境で安全に試せる | sandbox、mock、dry-runでPoCする |
| Red | 本番、規約、課金、投稿、DB、認証、セキュリティに危険が残る | 停止し、再リサーチへ戻す |
| Escalate | 専門家またはサービス提供者の確認が必要 | 法務、セキュリティ、公式サポートへ確認 |

## 2. 領域別ゲート

| 領域 | 判定 | 理由 | 必要な対策 | 次アクション |
|---|---|---|---|---|
| 要件 |  |  |  |  |
| 仕様 |  |  |  |  |
| 技術 |  |  |  |  |
| 外部API/規約 |  |  |  |  |
| セキュリティ |  |  |  |  |
| テスト |  |  |  |  |
| ハーネス |  |  |  |  |
| 運用・復旧 |  |  |  |  |

## 3. 即時NO-GO条件

| 条件 | 該当 | 理由 | 戻り先 |
|---|---|---|---|
| Must要件に受入基準がない |  |  | Requirements |
| Must要件にテストIDがない |  |  | Test Plan |
| 一次ソース未確認の外部APIを使う |  |  | Research |
| 規約・自動化制限が未確認 |  |  | External API & Terms |
| 本番書き込みにdry-runがない |  |  | Harness |
| Kill Switchがない |  |  | Harness |
| rollbackがない |  |  | Technical/Operations |
| CIがない、またはテストが走らない |  |  | CI Quality Gate |
| テストskipやassert削除がある |  |  | Codex Review |

## 4. 非エンジニア向け最終説明

| 質問 | 回答 |
|---|---|
| 今進めてよいか |  |
| 何が危ないか |  |
| 何を確認すれば安全になるか |  |
| 次にAIへ依頼すること |  |
"""

for name, content in templates.items():
    (base / name).write_text(content, encoding='utf-8')

# Also create a compact combined file for easy attachment and copying.
combined = ["# 世界最高基準リサーチ駆動・安全実装テンプレート全集\n\n作成者: **Manus AI**\n\n"]
for name in sorted(templates):
    combined.append(f"\n\n---\n\n<!-- Source: {name} -->\n\n")
    combined.append(templates[name])
(base / 'world_class_template_pack_combined.md').write_text(''.join(combined), encoding='utf-8')
print(f'created {len(templates)} template files in {base}')