fortress-implement — 絶対失敗しない実装実行スキル

Learning Style Override: このスキル実行中は「Learn by Doing」（Your Task / TODO(human)）を無効とする。Slice実装ループの中断は品質保証パイプラインを破壊するため、人間への実装委譲は行わない。Insightの提供は各Phase完了時に限定する。

概要

単一の実装タスクをSlice（最小検証可能単位）に分解し、各Sliceで「テスト先行→実装→クロスチェック→Safe Point」のループを回す。失敗したら直近のSafe Pointに戻って再設計する。速く作るスキルではなく、止まるべき時に止まり、戻るべき時に戻り、最後に証明して終えるスキル。

  +-----------------------------------------------------+
  |  Phase 0: 要件凍結（曖昧さゼロをゲート条件）         |
  +------------------------+----------------------------+
                           |
                           v
  +-----------------------------------------------------+
  |  Phase 1: 設計検証 & Slice計画                       |
  |  （Tier判定 -> fortress-review[I2+] -> Slice分解）   |
  +------------------------+----------------------------+
                           |
                           v
  +-----------------------------------------------------+
  |  Phase 2: Slice実装ループ（コアフェーズ）             |
  |  LOOP(each Slice):                                  |
  |    A: テスト先行 -> B: 最小差分実装 -> C: クロスチェック|
  |    -> D: 全検証 -> E: Safe Point                    |
  |    Gate FAIL -> Self-Healing Loop                   |
  +------------------------+----------------------------+
                           |
                           v
  +-----------------------------------------------------+
  |  Phase 3: 統合検証（回帰テスト + E2E）               |
  +------------------------+----------------------------+
                           |
                           v
  +-----------------------------------------------------+
  |  Phase 4: 証跡パック & Go/No-Go 最終判定             |
  +-----------------------------------------------------+

設計根拠（四者分析の統合）

核心原則（四者一致点）

1. テスト先行は絶対 — bugは再現テスト、featは受入テストを先に書く
2. 1 Sliceは1つの関心事 — リファクタ・機能追加・依存更新を混ぜない
3. クロスチェックは実装者以外 — 自己正当化を構造的に排除
4. Safe Pointは省略不可 — 5点セット（スナップショット、合格テスト一覧、変更ファイル、ロールバック手順、前提メモ）
5. 完了 = 証明 — コードを書いたことではなく、証跡パックが揃ったこと

Phase 0: 要件凍結（Intake Freeze）

以下のいずれかを入力として受け付ける:

凍結チェックリスト

- [ ] 実装対象（何を作る/直すか）が1文で記述できる
- [ ] 受入条件が具体的に定義されている（「○○のとき△△になる」形式）
- [ ] 非対象（やらないこと）が明示されている
- [ ] 前提条件（依存するAPI、DB状態、環境）が列挙されている
- [ ] 成功の定義がテスト可能な形で記述されている

ゲート条件: 全項目にチェック。曖昧な項目が残る場合はユーザーに確認を求めて停止。

出力: Mission Brief — 対象(1文)、受入条件(箇条書き)、非対象、前提条件、成功の定義を凍結文書化。

Phase 1: 設計検証 & Slice計画

1.1 Tier判定（実装複雑度スコアリング）

Tier閾値

スコア0: fortress-implementは過剰。通常の実装フローを推奨して終了。

1.2 Slice分解

Sliceは「独立に検証・ロールバック可能な最小実装単位」。

Slice分解の原則:

1. 1 Sliceは1つの関心事のみ扱う
2. migration、設定変更、権限変更は専用Sliceに隔離
3. 各Sliceに明確な受入テストを定義
4. Slice間の依存順序を明示

出力形式（ユーザーに提示して承認を得る）:

【Slice計画】
Tier: {I0/I1/I2/I3}（スコア: {N}点）
推定所要時間: Slice数 x Tier別平均

| # | Slice名 | 目的 | 受入テスト | 依存 | 推定規模 |
|---|---------|------|----------|------|---------|
| 1 | DB schema追加 | 新テーブル作成 | migration適用確認 | なし | S |
| 2 | API実装 | CRUDエンドポイント | 単体テスト全PASS | Slice 1 | M |

1.3 fortress-review連携（Tier I2+のみ）

Tier I2以上: Slice計画を fortress-review --auto-gate に投入。

• CRITICAL=0 → Phase 2に進行
• CRITICAL>=1 → Slice計画の修正が必要。ユーザー判断を仰ぐ

Phase 2: Slice実装ループ（コアフェーズ）

2.1 ループ構造

各Sliceに対し5ステップを順次実行:

詳細手順: references/slice-execution-loop.md を Phase 2 開始時にRead

2.2 エージェント構成（Tier別）

エージェントプロンプト: references/agent-prompts.md をエージェント起動時にRead

2.3 Safe Point（5点セット）

状態ファイル: tasks/fortress-implement-state.json

2.4 Self-Healing Loop（失敗回復）

Gate FAILが発生した場合、以下の判定ロジックで回復戦略を決定する:

function decideRecoveryAction(failure, history) {
  // failure = { slice_id, attempt, error_type, error_pattern, severity }
  // history = 同一Sliceの過去failure配列
  // 返り値: "RETRY_SAME" | "RETRY_DIFFERENT" | "ROLLBACK" | "ESCALATE"

  // Layer 1: 即時判定（severity + attempt上限）
  if (failure.severity === "CRITICAL")               return "ROLLBACK";
  if (failure.attempt >= 3)                           return "ESCALATE";

  // Layer 2: パターン再発検知（同じ根本原因の繰り返しを断つ）
  const samePattern = history.filter(h => h.error_pattern === failure.error_pattern);
  if (samePattern.length >= 1)                        return "RETRY_DIFFERENT";

  // Layer 3: error_type別の最適戦略（機械的修正 vs 設計判断）
  switch (failure.error_type) {
    case "LINT":                                      return "RETRY_SAME";
    case "TYPE":                                      return "RETRY_SAME";
    case "TEST":
      return failure.attempt <= 1 ?                   "RETRY_SAME" : "RETRY_DIFFERENT";
    case "REVIEW":
      return failure.severity === "HIGH" ?            "ROLLBACK" : "RETRY_DIFFERENT";
    case "UNEXPECTED":                                return "ROLLBACK";
    default:                                          return "ESCALATE";
  }
}

判定の設計根拠:

制約（ガードレール）:

• 最大リトライ: Slice単位で3回まで
• 同一エラーパターン2回: RETRY_DIFFERENT を強制
• CRITICAL severity: 即時 ROLLBACK（リトライなし）
• 3回失敗: ROLLBACK + ESCALATE（ユーザーに報告）

Phase 3: 統合検証（Integration Fortress）

全Slice完了後、以下を順次実行:

1. lint — 全PASS確認
2. type-check — 全PASS確認
3. test — 全テストPASS確認（Slice単位テスト含む）
4. build — ビルド成功確認
5. 回帰テスト — 変更前に通っていたテストが引き続きPASS

Tier I2+: e2e-testスキルでE2E検証を追加実施。コアオペレーションの直接テスト必須。

Tier I3: N-version検証 — 重要ロジック部分をCodexに独立実装させ、2つの実装diffを比較。不一致箇所はレビューエージェントが裁定。

Phase 4: 証跡パック & 最終判定

Go/No-Go基準

証跡パック出力

## fortress-implement 証跡パック

### 基本情報
- 対象: {Mission Briefの1行要約}
- Tier: {I0/I1/I2/I3}（スコア: {N}点）
- Slice数: {N} / 完了: {N} / 失敗: {N}

### 判定: {Go / 条件付きGo / No-Go}

### Slice実行結果
| # | Slice名 | 試行回数 | 結果 | Safe Point |
|---|---------|---------|------|-----------|

### テスト結果サマリ
- lint: PASS / type-check: PASS / unit: N/N / integration: N/N / E2E: PASS|SKIP

### 残存リスク・Self-Healing統計

オプション引数

オンデマンドRead指示

トラブルシューティング

既存スキルとの連携

issue-planner（計画作成）
     |
     v
fortress-implement（確実な実装実行）  <-- THIS
     |-- fortress-review（Phase 1 設計検証、Tier I2+）
     |-- codex（クロスチェック + テスト生成）
     +-- e2e-test（Phase 3 E2E検証）
     |
     v
sub-review（最終diffレビュー）

関連スキル

改訂履歴