sdlc-apply

sdlc-apply

承認された意図に記載された内容を実装し、動作することを示して、ユーザーに受け入れてもらいます。依頼がない限り、プッシュやデプロイは行いません。

status: accepted の intent/<slug>/intent.md が必要です（tier: critical の場合、承認には ## Spec も含まれます）。アーキテクチャ、安全性、受け入れ基準に影響する選択肢が未決定の場合は、ユーザーに質問を1つします。それ以外の場合は、前提を明示して作業を続けます。

作業上の合意事項

• 作業レーン。 デフォルトでは、現在のチェックアウトで一度に1つの意図を扱います。独立した意図（対象ファイルが重ならず、共有する契約やマイグレーションの順序もないもの）は、並行して進めてもかまいません。その場合は、リポジトリ内の $(git rev-parse --show-toplevel)/.worktrees/<slug> に意図ごとに1つのワークツリーを作成します。プロジェクトを格納しているフォルダー内には作成しません（無視されていない場合は .git/info/exclude に追加します。ルートは一度だけ固定し、ネストさせません）。検証後、fast-forward または rebase でメインブランチにマージします。統合ブランチは作成しません。ワークツリーは隔離環境ではありません。サービスを並行して起動する場合は、製品に既存のワークツリー設定を使い、それぞれに専用のデータベース、Compose プロジェクト、ポートを割り当てます。
• サブエージェント。 読み取り専用の調査や、作業時間またはメインコンテキストの削減につながる独立した並行作業に使います。それぞれに範囲を限定した目標を設定します。むやみに多数のエージェントを投入しないでください。調整にはコストがかかります。
• 再起動または中断後。 作業を再開する前に、intent.md、git status、チェック済みの手順を読み直します。以前に作業を割り当てた記録があっても、実際に作業が行われた証拠にはなりません。
• 所有権。 書き込みを始める前に git status --short を記録します。他の人の変更済みファイルには手を加えません。リセット、スタッシュ、ステージングも行いません。
• YAGNI。 既存のコードとパターンを再利用し、それが難しい場合はインストール済みの依存関係やプラットフォームの機能を使います。実証された不足がある場合に限り、依存関係や抽象化を追加します。検証、エラー処理、セキュリティ、アクセシビリティは維持します。
• 依頼されていない範囲には手を広げない。 ユーザーが求めていない新しい画面、必須入力、ゲートは追加しません。必要に思われる場合は作業を止め、トレードオフを提示します。
• コミット。 一貫した手順ごとに1つのコミットを作成し、その手順のチェックボックスをコードと同じコミットでチェックします。Conventional Commits の形式は type(scope): imperative summary とし、空行の後に理由を1文で記述します。検証記録だけのコミットは作成しません。

手順

1. intent.md を読み、フロントマターに base: <HEAD hash> を記録します（最初の手順と同じコミットに含めます）。## Steps が空、または曖昧な場合は、ここで手順を記述します。いくつかの一貫した作業単位に分け、それぞれに check: を付けます。最もリスクの高い境界を最初に検証する順序にします。
2. 各手順について、実装し、チェックを実行し、成功を確認してからチェックボックスにチェックを入れ、コミットします。
3. 実証では代替手段ではなく、実際の経路を検証する必要があります。
   • パイプライン内で新規または変更された入力は、保存された場所だけでなく、消費される場所（送信リクエストまたはコンシューマー）でアサートします。
   • 状態を持つフローや非同期フローでは、即時応答だけでなく、失敗、再試行、再読み込み後の永続化状態を確認します。
   • スキーマを変更する場合は、破棄可能なデータベースで、既存の行を保持したまま、以前に適用されたマイグレーション状態からのアップグレードを実証します。新規データベースでの成功だけでは不十分です。適用済みのマイグレーションは編集しません。
   • 依存するテストがテストランナーによって実際に検出されることを確認します（コンポーネントテストやその他の拡張機能を含みます）。
   • 本番環境や共有のデフォルトデータベースに対してチェックを実行しません。変更を加える操作の前に、接続先を確認します。
4. 最後の手順が完了したら、typecheck、lint、影響を受けるテストを実行します。UI の場合は、実行中のローカルアプリでメイン経路とエラー経路を1つずつ操作し、スクリーンショットまたは DOM 抜粋のパスを保存します。
5. intent.md の ## Result に、Acceptance 項目ごとに PASS または FAIL と証拠を1行で記載し、未確認の項目も記載します。FAIL または未確認の必須項目は隠さず、報告します。
6. 完成候補をコミットし、両方の tier について sdlc-verify に引き渡します。指摘事項を新しいコミットで修正し、再レビューします。
7. Result を提示し、ユーザーに報告します。最終的な受け入れはユーザーが行います。

クローズ（検証に合格し、ユーザーが承認した後に限る）

順序は固定です：適用、sdlc-verify（verdict: pass の report.md）、ユーザーの承認、その後にクローズします。最後のステップの直後にクローズしてはいけません。クローズは承認を記録するものであり、リリースを宣言するものではありません。

確認項目：ステップにチェックが付いていること、## Result に説明のない FAIL がないこと、report.md が合格していること、またレビュー対象のファイルがその後変更されていないこと（git diff --quiet <reviewed_head> HEAD -- $(git diff --name-only <base> <reviewed_head> -- . ':(exclude)intent')。その間に別のコミットが入っても問題ありません）。ただし、ユーザーがレビューを免除した場合、または独立した確認手段がない tier change で「独立したレビューを受けていない」ことを承認した場合を除きます。その後、フォルダーを削除し、ストーリーを履歴に残します：rm -rf intent/<slug> && git add -A intent/<slug> を実行し、Acceptance の各項目につき1行の Result 行と、未解決のレビュアー指摘があれば本文に含めて、chore(<slug>): close intent でコミットします。フォルダーが存在する間、インテントはオープンです。完了したものは git log --diff-filter=D --format='%h %s' -- intent/ で一覧表示し、git show <commit>^:intent/<slug>/intent.md で内容を確認できます。プロジェクトにナレッジバンドルがあり、この作業によって長期保存するメモが更新される場合は、そのワークフローを通じて更新してください。プッシュしてはいけません。

同じ種類の失敗が2回続いたら、ゲート全体を繰り返すのをやめ、失敗を絞り込んで再現してください。別の結果が必要だと判明した場合は、インテントから逸脱せず、ユーザーとともにインテントを更新してください。