sdlc-apply 是 acourtiol/ai-sdlc 项目中的一项技能，用于把已被接受的意图（intent）逐步实现、证明其可用，并交由用户接受，最后关闭该意图。它的定位不是自由开发，而是围绕一份已接受的意图文档执行受控的落地流程。
用途
该技能用于“构建已接受意图所描述的内容”，展示其确实工作，并让用户接受。除非被要求，否则不推送也不部署。其前置条件是：必须存在 intent/<slug>/intent.md 且状态为 accepted；对于 tier 为 critical 的意图，接受还需包含其 ## Spec。如果仍有一个会改变架构、安全性或验收方式的选择未定，则向用户提一个问题；否则说明假设并继续。
主要能力与工作约定
- Lane（工作通道）：默认为当前检出，一次只处理一个意图。相互独立的意图（文件不相交、无共享契约或迁移顺序依赖）可以并行，每个在 $(git rev-parse --show-toplevel)/.worktrees/<slug> 下使用独立 worktree，须位于仓库内、不能放在存放项目的文件夹中；若未忽略需加入 .git/info/exclude；根目录只锚定一次，不得嵌套；验证后以 fast-forward 或 rebase 合入主分支。不使用集成分支。worktree 不构成隔离：并发服务需要各自的数据库、compose 项目和端口，通过产品现有的 worktree 设置实现。
- 子代理：仅在能节省墙钟时间或主上下文大小时，用于只读研究或互不相交的并行工作，且每个目标有界。不要扇形扩散成群体，协调是有成本的。
- 中断恢复：在重启或中断后，继续前重新阅读 intent.md、git status 和已勾选的步骤。过去的派发不构成工作已运行的证据。
- 归属：写入前记录 git status --short。他人的脏文件属于他人，绝不要重置、暂存或 stash 它们。
- YAGNI：优先复用现有代码与模式，其次是已安装依赖或平台能力。只有出现已证明的缺口才添加依赖或抽象。保留验证、错误处理、安全性和可访问性。
- 不做未请求的范围：不新增用户未要求的界面、必填输入或关卡。若认为必要，停下并呈现权衡。
- 提交：每个连贯步骤一次提交，并在同一次提交中勾选该步骤的 checkbox。使用 Conventional Commits：type(scope): 祈使式摘要，空行，一句话说明原因。不要只为记录验证而提交。
使用方式
步骤依次为：
- 阅读 intent.md，并在其 frontmatter 中记录 base: <HEAD hash>（随第一个步骤一起提交）。如果 ## Steps 为空或含糊，现在就写出步骤：几个连贯的切片，每个带一个 check:。排序时应让风险最高的边界最先被检验。
- 对每个步骤：实现、运行其 check、仅在亲眼看到通过后才勾选方框、提交。
证明必须走真实路径，而非替代品：
- 管道中新增或变更的输入要在其被消费之处（发出的请求或消费者）断言，而不仅是在其被存储之处。
- 有状态或异步流程：检查失败后、重试后和重新加载后的持久化状态，而不仅是即时响应。
- Schema 变更：在一次性数据库上从先前已应用的迁移状态证明升级可行，且既有行得到保留。全新数据库通过是不够的。绝不修改已应用的迁移。
- 确认测试运行器确实发现了你所依赖的测试（组件测试、其他扩展）。
- 绝不要对生产或共享默认数据库运行检查。在任何会变更数据的操作前确认连接目标。
当最后一步完成时，运行 typecheck、lint 与受影响的测试。对于 UI，在本地运行的应用中走通主路径与一条错误路径，并保留截图或 DOM 片段路径。
填写 intent.md 中的 ## Result：每个 Acceptance 条目一行，带 PASS 或 FAIL 及证据，另加任何未检查的内容。FAIL 或未检查的必需条目必须上报，绝不隐藏。
提交完成的候选，并交给 sdlc-verify（两个 tier 都交）。用新的提交修复其发现的问题，然后重新评审。
向用户呈现 Result 与报告。由用户接受。
关闭（仅在 verify 通过且用户接受后）
顺序是固定的：apply、sdlc-verify（report.md 带 verdict: pass）、用户接受，然后关闭。绝不能在最后一步后直接关闭。关闭是记录接受，不是声称发布。
检查项：步骤已勾选，## Result 没有未解释的 FAIL，report.md 通过，且被评审的文件自评审后未变更（git diff --quiet <reviewed_head> HEAD -- $(git diff --name-only <base> <reviewed_head> -- . ':(exclude)intent')；期间落地的其他提交不影响），除非用户放弃评审，或对于无独立路径的 tier 变更，接受“未独立评审”。然后删除该文件夹并在历史中保留故事：rm -rf intent/<slug> && git add -A intent/<slug>，提交 chore(<slug>): close intent，正文中写入 Result 各行（每个 Acceptance 条目一行）及任何未解决的评审发现。意图在其文件夹存在期间即为开启；已完成的意图可用 git log --diff-filter=D --format='%h %s' -- intent/ 列出，并用 git show <commit>^:intent/<slug>/intent.md 阅读。如果项目有知识包且该工作取代了某条持久说明，则通过该流程更新。不要推送。
同类失败发生两次后，停止重复完整关卡，改为窄范围复现失败。如果工作实际上需要不同的结果，与用户一起更新意图，而不是偏离它。
适用场景与限制
适用场景：需要按照已接受意图的验收标准逐项落地开发任务，并要求每一步可验证、可追溯、可交由评审与用户接受的软件交付流程。
限制与边界：必须有已接受的 intent.md 才能开始；不推送、不部署；不添加未请求的范围；不使用集成分支；并行仅限互不相交的意图；不得修改已应用的迁移；不得对生产或共享默认数据库运行检查。关于具体收费、价格、平台支持范围及性能效果，资料未提供。