sdlc-plan

sdlc-plan

根据用户的想法，用他们自己的措辞编写 intent/<slug>/intent.md。一页即可。它既是约定，也是你将据此接受评估的检查清单。

分流

• 可行性问题属于 spike：回答问题，不写 intent。
• 现有流程中的 bug、微调或小型行为变更属于 sdlc-fix，不写 intent。
• 任何会改变产品行为的事项都需要写 intent。选择级别并写入 frontmatter：
  • change：常规功能。一个 intent 文件，然后开始构建。
  • critical：影响重大（已填充数据的表迁移、身份验证、机密、隐私或 PII、破坏性或不可逆操作、会改变生成内容或审批结果的 LLM 提示词或关卡、外部发送、抓取政策）。在同一文件中增加 ## Spec 部分，并进行更严格的审查（缺少独立审查者时不得继续）。
  • 两种级别在应用后都要在全新上下文中执行 sdlc-verify。
  • 不确定时，选择 critical。

重要规则

• 保留用户要求的结果。明确要求的自动化、指定的提供商或集成，以及要求覆盖的数据，都是必需项。手动备用方案或后续跟进不能满足这些要求；未经用户明确同意，不得将用户要求的任何内容移至 Out of scope。
• 不要擅自扩大范围。新增界面、必填输入、确认或关卡都属于产品决策：要么能追溯到用户的明确要求，要么说明取舍并让用户决定。
• 按用户的实际需求确定规模：一个人，一次部署。不要臆测设置或扩展点。
• critical 的 ## Spec 只解决出错代价高昂的决策，并引用你阅读过的代码：契约及其调用方；数据和迁移（仅增量式，绝不修改已应用的迁移，以及如何在用先前状态填充的一次性数据库上验证升级）；失败、重试和重新加载后的持久化状态；基于真实适配器或匹配版本文档的提供商错误；身份验证、机密、PII 以及哪些内容会离开设备；发布和回滚；未决事项，每项都由用户回答或接受一个默认值。不要重复 Acceptance。
• Acceptance 应覆盖缺陷容易隐藏的边界：对于有状态、异步或涉及外部提供商的结果，要加入拒绝、过期、失败、重试和重新加载的情况。
• 根据把握程度进行质疑。把握度高意味着：结果和约束明确，当前代码支持该方案，契约和故障模式有依据，没有未解决的假设。此时继续推进。否则，将最重要的未决假设交给一位全新的只读审查者，核对其引用并记录修改内容。绝不重新质疑已敲定的决策。
• 范围宽泛的请求要拆分：明确指出首个可独立使用且完整交付的部分，并为其编写 intent。其余内容列入 Out of scope 或后续 intent。

步骤

1. 阅读仓库说明和 intent/*/，了解正在进行的工作。先读代码，再询问任何代码能够回答的问题。
2. 采访用户，直到需求具体：目前无法完成什么、证明问题确实存在的证据（或 not checked）、受影响的人、怎样才算更好、约束、范围外内容。一次只问一个问题，且只有当答案会改变构建内容时才提问；否则说明你的假设并继续。
3. 阅读变更将涉及的代码，并据此编写 ## Approach：列出变更路径、复用的内容、明确不构建的内容，以及每项决策及其理由。用户可以在构建前在此指出过度构建；自主执行过程会使用这些路径查找不同 intent 之间的重叠。
4. 选择一个尚未在 intent/ 中使用的 kebab-case slug。根据以下模板创建 intent/<slug>/intent.md。
5. 展示路径和简短摘要。由用户接受或修正。接受后，设置 status: accepted 并提交该文件。之后若对结果或验收标准进行重大修改，则将状态改回 draft，直到用户重新接受。
6. 接下来：sdlc-apply。一次接受涵盖 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.