sdlc-fix 属于 AI SDLC 工作流中的修复环节，目标是在已有的、可读的流程中修复一个有边界的缺陷，或进行一次保持行为不变的重构。它适用于具体的缺陷修复，以及不改变行为的重构，而不用于引入新能力。若调查后发现出现了新能力、未解决的产品选择、架构决策，或工作跨越多个子系统，应改用 sdlc-plan，不应把扩大后的范围伪装成一次修复。
【用途与适用范围】 该技能用于修复现存流程中的具体缺陷或做保持行为的重构。它要求判断改动的规模以及出错后的影响：一个很小的补丁可能后果很重，而一个很大的机械式改动可能后果很低。它不是用来把每个小修复都升级成完整的功能意图或完整的验证工作流。
【保证级别如何选择】 保证级别由后果而非代码行数决定。一个不改变事实、选择、权限、持久数据或共享行为的标签、大小写或布局修复，使用聚焦回归和受影响的渲染/预览检查，无需常规独立审查者。局部行为修复则增加对其受影响契约以及相关主路径/错误路径的检查。对于有后果的改动、具体未解决的高影响风险，或具有约束力的用户/仓库规则，需要独立审查，并应在既有修复记录中说明原因。若改动可能影响授权、敏感数据、不可逆操作或迁移、财务计算、安全关键行为或其他重要不变量，则必须在编辑前建立独立审查路线，并在稳定完成的修复边界使用宿主可用的委派机制（不继承实现历史），或使用独立的全新会话进行有界交接；若宿主无法提供这种能力，则不应进行自主的有后果修复，而应说明阻塞。
【设计原则】 在理解受影响流程之后应用 YAGNI：先复用合适的现有代码和模式，其次优先使用标准库、原生平台或已安装依赖提供的能力。只有当存在被证明的缺口时，才添加自定义代码或依赖。避免为未来功能添加推测性的配置、扩展点和脚手架，但保留由当前契约或清晰性所证明合理的抽象。这是快速的设计选择，而非新的研究或审查阶段。应最小化实现复杂度，而不是削减被请求的能力：保留明确的结果、兼容性、验证、错误处理、安全与可访问性。可读、完整的代码优先于更少的行数。
【所有权预检】 编辑前先记录仓库根、分支和 HEAD，然后检查 git status --short、git diff --cached、git diff、git ls-files --others --exclude-standard。默认使用当前拥有该工作的检出；只有在需要隔离具体重叠工作或提供干净审查候选时才创建另一个。由代理创建的检出，默认使用约定项目工作区的 .worktrees/<purpose>，并从初始工作区一次性锚定其根，以避免嵌套 worktree 区域；创建前确保其被排除在 Git 跟踪及相关源码/测试发现之外。保留宿主管理的隔离，并记录其路径与原因。可恢复的检出和保留的证明凭据应使用持久、非缓存存储；临时目录仅作一次性草稿。保留所有现有工作，不要 reset、stash、clean 或包含无关改动。如果已有的暂存或未暂存差异触及你需要编辑的路径，应使用隔离工作树，或在继续前分离出确切的代码块；git commit --only 会提交所选路径的完整工作树内容。若无法安全分离所有权，则在编辑该路径前停止。对于无关的已暂存文件，保持其暂存状态，并在审查该命令将包含的内容后，使用显式路径提交（git commit --only -- <owned-paths>）提交本次修复。绝不使用 git add -A。
【置信度与检查范围】 每个产品仓库通过其最终审查保持一条活跃的实现通道；默认在此实现，或保留一个委派所有者。并行研究是只读的。除非明确重新排定优先级，其他修复/功能应排队，切换前先做检查点。只有当置信度低于高时才需要单独的决策挑战者：结果/约束、当前源码支持、相关契约与重要失败模式的证据，以及不存在未解决的重大假设，这些全部成立才算高置信度。有后果的行为需要更强的证据。缺少偏好或权限时需要用户决定。
【检查与证明】 在声明修复已通过本地检查之前，必须把每项必需的验收条件对应到既有 Proof/凭据中观察到的断言或操作及其结果。测试名称或整套绿色并不能证明其断言从未执行的某个条件。对于变更的请求/状态契约，应从规范和源码中选择适用的不同分支，包括当重放/冲突行为重要时同一身份但载荷变化与身份变化的情况；在需要时断言拒绝以及持久状态不变。缺少证据会令修复不完整。检查应绑定到所报告的行为、完整的修复 diff 以及具体受影响的契约/调用方。对于相邻流程，应指明变更的依赖/不变量，并使用其最小有意义的回归或冒烟测试，不要重新认证整个较早的功能。更广泛的检查需要具有约束力的仓库/用户要求、具体的集成风险或观察到的失败。
【工作流程】 阅读适用的仓库说明和受影响的源码。对于缺陷，确定其报告到的失败和原因；在可行时编辑前先运行原始重现。不要声称已重现，如果实际无法复现。在更改提供者/运行时边界前检查既有的适配器/错误解析器；对重要响应/错误形态使用源码、版本匹配文档或经授权的捕获证据，而不是编造的 mock。检查共享该缺陷契约、转换或错误处理的相关分支，并在这一有界范围内修复已确认的缺陷。更大的范围回到 sdlc-plan。做最小的根因改动。对于重构，说明必须保持为真的行为。
在另一次广泛运行或独立审查之前，先运行原始重现和针对受影响失败家族的聚焦检查。对于有状态缺陷，应针对一次性持久化运行实际路由/运行时，并在相关失败、重试或重载后断言已提交结果；仅靠辅助函数返回值无法确立持久行为。由契约支撑的 fixture 只能确立本地处理，而非真实提供者成功。阅读检查输出。当持久的自动化检查有用时，回归测试应因所报告的原因而失败；否则记录具体重现以及为何测试不适合。若所需环境或权限不可用，记录为阻塞而非通过。
审查最终 diff 并确认未包含无关路径或用户改动。在独立审查前提交完整的本地检查候选。遵循 Conventional Commits 1.0.0：type(scope): 祈使式摘要（scope 可选；缺陷用 fix，保持行为的变化用 refactor）。添加空行并写一句解释原因，附上本地检查证据；破坏性变更用 ! 或 BREAKING CHANGE: 尾注标记。
对于有后果的变化，应针对该确切的已提交候选在干净检出中派遣全新的独立审查者；结合源码审查与最终验证，而不是常规的逐次编辑审查。只有在保留其先前报告和所需凭据，并确认可在不丢弃工作的情况下准备后，才能将拥有的、干净的、非活跃的审查检出复用于后续候选；审查者仍必须使用全新上下文。它独立重现已修复行为和重要失败路径。
当请求发生在事故或逃逸缺陷之后时，应识别该缺陷如何通过此前的检查，并添加与原因相符的持久预防措施：回归测试、更清晰的契约、缺失的诊断信息，或聚焦的仓库说明。更广泛的产品变更走 sdlc-plan。
【限制】 该技能不授权推送或外部操作（除非用户要求推送）。不得使用 git add -A。不得把每个小修复都变成功能意图或完整验证工作流。缺少独立审查路径时，有后果的修复应被视为阻塞而非已验证。在独立通过前不得声称完成或推送有后果的修复。
【完成与知识检查】 在验证完成时，仅当项目或环境已配置知识包或维护工作流时，才进行有界知识检查；使用该工作流更新相关现有持久笔记（若本次修复取代了它），否则跳过。不要仅为记录会话而创建笔记，不要扫描整个知识包或无关知识，也不要引导缺失的知识包。任何知识编辑应保持在被审查候选之外，以免使修复的独立验证失效。
【整理】 完成时，检查你拥有的工作树，仅移除干净、非活跃、无未完成任务/交接、其提交与证据已保留且没有活跃进程使用的检出。不要强制移除、删除分支、移动活跃检出或全局修剪。若所有权或安全性不明确，保留检出并在交接中记录其路径与原因。