sdlc-plan

sdlc-plan

ユーザーのアイデアを、その人自身の言葉で intent/<slug>/intent.md に記述します。1 ページです。これは合意書であり、達成度を評価するチェックリストでもあります。

トリアージ

• 実現可能性に関する質問はスパイクとして扱います。質問に答え、intent は作成しません。
• 既存のフローに対するバグ修正、調整、小さな動作変更には sdlc-fix を使い、intent は作成しません。
• プロダクトの動作を変えるものはすべて intent です。ティアを選び、フロントマターに記載します。
  • change：通常の機能です。intent ファイルを 1 つ作成してから、実装します。
  • critical：影響が大きいもの（データが入力済みのテーブルの移行、認証、シークレット、プライバシーや PII、破壊的または不可逆な操作、生成内容や承認を変える LLM プロンプトやゲート、外部への送信、スクレイピングポリシー）。同じファイルに ## Spec セクションを追加し、より厳格なレビューを行います（独立したレビュアーがいない場合はブロックされます）。
  • どちらのティアでも、適用後に新しいコンテキストで sdlc-verify を実施します。
  • 迷った場合は critical を選びます。

重要なルール

• 要望された成果をそのまま維持します。明示的な自動化、指定されたプロバイダーや連携、要望されたデータ範囲は要件です。手動での代替手段や後続対応では満たしたことになりません。また、ユーザーが求めたものを、明示的な合意なしにスコープ外へ移してはいけません。
• スコープを追加しません。新しい画面、必須入力、確認、ゲートはプロダクト上の判断です。ユーザーが求めたことに根拠を求めるか、トレードオフを提示して判断を委ねます。
• ユーザーの規模に合わせます。1 人、1 デプロイです。仮定に基づく設定や拡張ポイントは追加しません。
• critical の ## Spec では、間違えると修正コストが高い判断のみを確定し、読んだコードを引用します。対象は、契約とその呼び出し元、データと移行（追加のみとし、適用済みのマイグレーションは編集せず、前の状態をシードした使い捨てデータベースでアップグレードをどう検証するか）、失敗・再試行・再読み込み後の永続化状態、実際のアダプターまたはバージョンが一致するドキュメントに基づくプロバイダーエラー、認証・シークレット・PII とマシンの外部に送信される情報、ロールアウトとロールバック、未決事項（それぞれユーザーが回答するか、ユーザーが受け入れるデフォルトを設定する）です。Acceptance の内容を繰り返してはいけません。
• Acceptance では、欠陥が潜みやすい境界を扱います。状態を持つ処理、非同期処理、または外部プロバイダーの結果には、拒否、期限切れ、失敗、再試行、再読み込みのケースを追加します。
• 確信度に基づいて検証します。高いとは、成果と制約が明確で、現在のソースコードがアプローチを裏付け、契約と失敗モードに根拠があり、未解決の仮定がない状態です。その場合は先に進みます。それ以外の場合は、最も重要な未解決の仮定を、新しいコンテキストで読み取り専用のレビュアー 1 人に提示し、引用内容を確認して、変更点を記録します。確定済みの判断を再度問い直してはいけません。
• 広範な要望は分割します。最初に独立して価値のある完全な提供内容を特定し、その intent を作成します。残りはスコープ外の一覧にするか、後続の intent にします。

手順

1. リポジトリの指示と intent/*/ を読み、進行中の作業を確認します。質問で答えが得られることは、質問する前にコードを読みます。
2. 具体的になるまでヒアリングします。現状でできないこと、それが実際の問題である根拠（または not checked）、影響を受ける人、望ましい状態、制約、スコープ外を確認します。質問は一度に 1 つだけとし、回答によって実装内容が変わる場合に限ります。それ以外は仮定を明示して先に進みます。
3. 変更対象のコードを読み、そこから ## Approach を作成します。変更するパス、再利用するもの、意図的に実装しないもの、判断とその理由を記載します。実装前にユーザーが過剰な開発を指摘できるようにします。自律実行では、これらのパスを使って intent 間の重複を見つけます。
4. intent/ で未使用の kebab-case の slug を選び、以下のテンプレートから intent/<slug>/intent.md を作成します。
5. パスと短い要約を提示します。ユーザーが承認または修正します。承認されたら status: accepted に設定してファイルをコミットします。その後、成果または Acceptance に重要な変更があった場合は、再承認まで draft に戻します。
6. 次は sdlc-apply です。1 回の承認で intent 全体を承認し、critical の場合は Spec も承認します。

テンプレート

---
status: draft   # draft | accepted
tier: change    # change | critical
slug: example-slug
---

# Intent: short name

## Problem
What cannot be done today, and who feels it. Evidence it is real, or `not checked`.

## Outcome
What better looks like, observable, in the user's words. Keep short decisive quotes.

## Acceptance
- WHEN <trigger> THEN <observable result>. One line each, each checkable. Quote limits and enum values exactly.

## Approach
Paths that change. What is reused. What is deliberately not built. Decisions taken, one line each with the reason. 8 lines or fewer.

## Out of scope
Only what the user agreed to leave out.

## Steps
- [ ] First coherent slice. check: how you will know it works
- [ ] ...

## Spec (critical only)
Contracts and callers. Data and migration. Failure and retry. Security and privacy. Rollout and rollback. Open decisions.

## Result
Filled at the end: one line per Acceptance item (PASS/FAIL, evidence), plus anything not checked.