implement

実装

エージェントツールキットのパイプラインの 実装 フェーズを実行しています。スパインのフェーズ 4 です。あなたの役割は plan.md を忠実に実行することです。公開コントラクト、セキュリティポリシー、互換性／移行、確定した境界、取り消せない、またはコストのかかる決定、重要なアーキテクチャ上／運用上のトレードオフについて、新たな判断をしてはいけません。こうした判断が必要な場合は差し戻してください。慣例に沿った、慣用的でローカル／プライベート／可逆な実装上の選択は行います。

ヘルパースクリプトの実行

このスキルには、独自の scripts/ ディレクトリにあるヘルパースクリプトが含まれています（この SKILL.md と同じ場所にインストールされています）。SKILL_DIR にこのスキルの絶対パスを設定します。パスはこのファイルの末尾にある このスキルのベースディレクトリ に表示されています。その後、プロジェクトのルートからスクリプトを実行してください（プロジェクトの .changes/ ファイルと CONTEXT.md ファイルを操作します）。

SKILL_DIR="<absolute path to this skill's directory>"

以下の node "$SKILL_DIR/scripts/..." コマンドはすべて、この設定に依存します。packages/build/ は参照しないでください。このパスはツールキットの開発リポジトリにのみ存在し、インストール済みスキルにはありません。

実装者の姿勢

実装者は、確認済みの結果とスコープに従います。動作やコントラクトを独自に決めてはいけません。不確実な点はまず調査し、証拠をもとにしてもユーザーが決めるべき重要な事項が未解決の場合に限り差し戻してください。プライベートヘルパー、ローカルのデータ構造、制御フロー、同等の慣用的な仕組みは実装上の選択であり、仕様の欠陥ではありません。

コード品質もあなたの責任ですが、セクションごとにはレビューしません。各セクションはグリーンベースラインに到達させ、すべてのセクションがグリーンになった後に、範囲を限定したレビューと動作を保つ修正を一度だけ行います（references/implementation-review.md を参照）。

前提条件

manifest.yaml を読み込み、以下を確認してください。

• phase が implement である（計画の承認は approved）。
• approvals.implement が pending である。
• plan.md が存在する。

まず change-brief.md を読み、その後 references/engineering-fundamentals.md を読んでください。manifest.language が設定されている場合は、idioms スキルを使って、実装とレビューに対応する言語パックを読み込んでください。一致するパックがインストールされていない場合は、その旨を明記し、リポジトリの慣例とツールを使用してください。

手順：セクションごと（実装 → テスト合格）

plan.md を一度に 1 セクションずつ進めてください。各セクションで、次の手順を実施します。

ステップ 1：確定した境界のテストを先に作成する

このセクションにある [seam: <id>] [firmness: firm] とラベル付けされたテストタスクをすべて見つけてください。まずそれらのテストを作成します。実装コードを一切書く前に、テストが 失敗 することを確認してください。これは必須です。

ステップ 2：グリーンになるまで実装する

計画にある実装タスクを作成します。チェックリストを上から順に進め、完了したタスクは plan.md でチェック済みにしてください（ファイルを更新して [x] にします）。目標は、確定した境界のテストをすべて合格させることです。

ステップ 3：柔軟な境界のテストを作成し、グリーンベースラインに到達する

このセクションにある [seam: <id>] [firmness: soft] とラベル付けされたテストタスクを作成してください。テストを実行し、次に進む前にセクションをグリーンベースラインに到達させてください。この段階ではリファクタリングしないでください。リファクタリングは後で一度だけ行います。セクションの検証タスクをチェック済みにして、次のセクションへ進んでください。

すべてのセクション完了後

範囲を限定した独立レビューと、動作を維持する修正（L3）

これは変更全体に対して一度だけ実行し、実装承認に必須です。詳細は references/implementation-review.md に記載されています。

1. 広範な調査を一度実施します。 別のコンテキストで、新しい読み取り専用の監査担当者を起動します。完全な差分、関連する CONTEXT／シーム、および有効なスコープに該当するイディオムパックのみを渡します。references/adversarial-review.md に従い、該当する範囲でデータ／状態、データ構造、インターフェース／トレイト、エラー、セキュリティ、可観測性、シンプルさ、保守性、イディオムを詳細にレビューします。必須の N/A 定型文は不要です。
2. 指摘を一度にまとめます。 blocker／major の指摘を重複排除します。安定した RV-NNN ID を計画のレビューテーブルに記録し、重要度は blocker|major、カテゴリは correctness|security|simplicity|maintainability|idioms とし、根拠、具体的な影響、具体的な代替案を記載します。軽微な指摘や後続バッチは出しません。次の内容で証明します。

node "$SKILL_DIR/scripts/review-log.mjs" record --id --phase implement --cycle implement-N --role auditor
--reviewer "" --verdict changes-requested
--finding '{"id":"RV-001","severity":"major","category":"maintainability","location":"file:line","impact":"","alternative":""}'

問題がなければ、計画に `approved` と、根拠に基づく簡潔な理由を記録します。
3. **修正は一度だけ行います。** バッチ全体を動作を維持したまま解決します。ローカル／プライベートで元に戻せる、イディオムに沿った修正を自動選択します。重要性の境界を越える修正は差し戻します。変更できるのは実装とソフトシームのテストのみです。ファームシームのテストは引き続き成功する必要があります。失敗した場合は STOP し、差し戻します。テストを編集してはいけません。
4. **すべてのテストを成功させます。** 修正後、該当するテストスイート全体を実行します。
5. **対象を絞って検証します。** 別のコンテキストで、新しい読み取り専用の検証担当者を起動します。元の `RV-*` ID と、維持されたことを示す証拠のみを確認します。調査を繰り返したり、スコープを広げたり、新たな low／major 指摘を追加したりしません。

node "$SKILL_DIR/scripts/review-log.mjs" record --id --phase implement --cycle implement-N --role verifier
--reviewer "" --verdict approved --resolution RV-001=resolved

修正に起因する blocker の回帰のみ、新しい ID を追加できる例外です。`--regression` を付けて記録し、同じ対象範囲内で修正し、一度だけ行う対象限定の再検証で `--regression-resolution` を付けて解決します。未解決の ID が残る場合、または解決に広範なレビューが必要な場合は、サイクルを延長せず、停止して差し戻します。

### 実装承認

すべてのセクションが成功し、範囲を限定したレビュー／修正が完了し、検証レビューで承認が記録されたら、次のように確認します。

> 「実装のすべてのセクションが完了し、テストに合格し、独立レビューで承認されました。実装を承認しますか？」

node "$SKILL_DIR/scripts/manifest-approval.mjs" --id --approval implement --approve

この変更について、別の監査担当者によるレビューに裏付けられた検証レビューの承認が存在しない場合、承認は拒否されます。

## 差し戻しプロトコル

次の状況に遭遇した場合：
- 計画で扱われていない曖昧さ
- 成果物だけでは解決できない、重要性の境界に関わる判断
- リファクタリング中に失敗するファームシームのテスト（動作変更）
- 解決が必要な、計画と実態の不一致

**直ちに STOP してください。** 作業を続けてはいけません。独断で判断してはいけません。

1. 不足している点をユーザーに明確に説明します。
2. 分類します。仕様で検出すべきだった「defect」か、正当な新情報による「amendment」かを判断します。
3. 差し戻しを記録します。

node "$SKILL_DIR/scripts/kickback-log.mjs" --id --type defect|amendment --phase implement --impact specify|plan|implementation
--missed "<what the spec didn't cover>"

   重要な判断が変わる場合は `specify`、チェックリストのみが古い場合は `plan`、上流の成果物が無効にならない場合は `implementation` を選択します。スクリプトが正確な `restart_phase` と `invalidated_approvals` を記録します。
4. 記録されたフェーズから再開し、無効になった承認のみを再承認するようユーザーに伝えます。
5. 差し戻しが解決するまで、このセッションを続行してはいけません。
### ドキュメントの整合（ドキュメント承認）

`manifest.yaml` から `manifest.context_targets` を読み込みます。各対象の CONTEXT.md について、次の手順を実行します。
1. ベースラインとして `context-verify.mjs` を実行します。

node "$SKILL_DIR/scripts/context-verify.mjs" --path

2. `architecture.md` と `decisions.md` を CONTEXT.md と比較し、何が変わったか確認します。
3. 変更を反映するよう CONTEXT.md を更新します。
   - 堅牢性タグ付きの新しい境界
   - 更新されたインターフェース／コントラクト
   - 新しい用語集の用語
   - 新しい受け入れ基準（堅牢な境界を追加した場合）
   - `Known-soft-spots` の更新（導入された技術的負債を追加し、解消されたものを削除）
   - 来歴の再記録：`Provenance: validated-at: <current HEAD sha>`
4. 検証サブエージェントを実行します。
> 「これらの CONTEXT.md ファイルを実装と比較してください。記載内容はコードと一致していますか？不一致があれば列挙してください。」

5. 整合後に `context-verify.mjs` を実行します。該当する場合は堅牢な境界のテストも含め、検出された問題に対処します。
6. 整合の概要を提示します。検証で検出された問題に対処します。

ユーザーに尋ねます。
> 「CONTEXT.md ファイルの整合と検証が完了しました。この変更でよろしいですか？（ドキュメント承認により、この変更は `archive-ready` に移行します。）」

承認された場合：

node "$SKILL_DIR/scripts/manifest-approval.mjs" --id --approval docs --approve

### アーカイブ準備完了と検証済みアーカイブ

node "$SKILL_DIR/scripts/change-archive.mjs" --id

ドキュメント承認によって変更が `archive-ready` に移行した後にのみ、これを実行します。アーカイブ検証が成功し、zip が `.changes/archive/<id>.zip` に置かれた場合にのみ、変更は終了状態になります。

代わりにキャンセルするには、`manifest.yaml` に具体的な `archive.reason` を記録し、現在の成果物を削除せずにアーカイブします。

## 堅牢な境界のトリップワイヤー（概要）

**リファクタリングを通すために堅牢な境界のテストを編集してはいけません。** これがトリップワイヤーです。これは次のいずれかを意味します。
- リファクタリングが純粋なリファクタリングではない（動作が変わった）→ `--impact specify` を付けて差し戻します。
- または、堅牢な境界自体を変更する必要がある → 完全な堅牢な境界変更プロトコル（`references/firm-change-protocol.md` を参照）、`Firm-Change:` による差し戻し、影響を受ける承認の範囲を限定した再承認が必要です。

## 参照ファイル

- `references/implementation-review.md` — 範囲を限定した独立した実装レビューとレビュー記録
- `references/adversarial-review.md` — 範囲を限定したサイクル、レビュー観点、`RV-*` 指摘事項の契約
- `references/seam-and-test-taxonomy.md` — 堅牢／柔軟なテストの規則、トリップワイヤー
- `references/manifest-schema.md` — 差し戻しの種類
- `references/change-lifecycle.md` — ドキュメントの整合とアーカイブ
- `references/firm-change-protocol.md` — 堅牢な境界を変更する必要がある場合
- `references/drift-control.md` — CONTEXT.md の更新規則
- `idioms` スキル — 実装およびレビューに関する指針
- `references/engineering-fundamentals.md` — 言語横断のデータ、状態、抽象化、範囲を限定したリソースに関する指針