用途
resolve-problem 是 guardrails 项目中的问题报告工作流技能，用于处理发现的缺陷、异常、测试失败或意外行为。它的核心纪律是：在调查问题或改动任何代码之前，先把问题记录下来。该技能适用于受监管软件项目，强调问题记录的可追溯性与修复证据的完整性。
主要能力
- 问题记录：在问题台账中新增 PR（Problem Report）条目，包含可观察症状、影响的需求/风险/设计/低层需求 ID、开启日期和状态。
- 重复检查：通过 find-items.sh 列出或查看已开启的问题报告，避免重复记录。
- 系统化调查：要求先定位根因，再提出修复，禁止投机性修复。
- 升级机制：当发现需求缺失、风险控制失效、规格错误或设计层面问题时，升级到 grill-requirements、analyze-risks 或 design-architecture 等技能。
- TDD 修复：先用带 ID 注解的失败测试复现问题，再做最小修复、转绿并重构，保留复现测试作为永久回归证据。
- 解决与裁决：在合并修复的同一变更中将条目置为 resolved；若决定不修复，则置为 accepted 并附 disposition 说明裁决与日期。
- 校验规则：check-trace.sh 会报告 INCOMPLETE-PROBLEM、UNRESOLVED-PR、ACCEPTED-PR 等状态，并依据 problem_age_days 和 problem_open_max 限制问题积压。
使用方式
技能开始时需声明“Using the resolve-problem skill.”。前置条件是已发现缺陷、异常、测试失败或意外行为，且处于 worktree 中。
§1 先记录：用 .guardrails/scripts/find-items.sh list --kind PR --status open 检查是否已有记录；若无，则在 docs/problems/<YYYY-MM-DD>-<slug>.md 中新增条目，先用 .guardrails/scripts/new-id.sh PR 生成 ID，再按格式写入症状、affects、opened 和 status: open。opened 必须是当天真实日历日期（YYYY-MM-DD），不得超前超过一天。不要添加 owner 字段。
§2 系统化调查：阅读错误、复现问题、形成假设、验证假设，找到根因后再提出修复。随着真实范围浮现，更新 affects 列表。遇到需求缺失、风险控制失效、规格错误或设计层面问题时，升级到相应技能。
§3 TDD 修复：先按 develop-tdd 将问题复现为带 verifies: 注解的失败测试，再写最小修复、转绿并重构。保留复现测试作为永久回归证据。
§4 在合并修复的同一变更中解决：在定义该条目的日期台账文件中更新 PR 条目，设置 status: resolved，并追加一行解决说明（根因与修复引用）。绝不在不包含修复的变更中标记问题已解决。随后运行 check-traceability，再运行 merge-change（其步骤 6a 门禁为 verify-before-merge）。
裁决为“不修复”时：将条目置为 status: accepted，并附 disposition: 行，说明裁决与日期。accepted 条目豁免 problem_age_days，不计入 problem_open_max，但 check-trace.sh 仍会以 ACCEPTED-PR 打印。disposition 为必填。不要为了清除红色 PROBLEM-BACKLOG 而设置 accepted。若裁决后来改变，将条目重新置为 open 并按 §3 解决。
适用场景
适用于 guardrails 项目中任何缺陷、异常、测试失败或意外行为的处理，尤其适合受监管软件项目，需要完整的问题记录、根因分析、TDD 修复证据和可追溯的解决或裁决记录。
限制
- 必须在 worktree 中操作。
- 必须先记录问题，再调查或改动代码。
- opened 日期必须是真实日历日期，不得超前超过一天。
- 不得添加 owner 字段。
- resolved 仅用于合并变更包含修复的情况；accepted 仅用于有可辩护裁决和日期的情况。
- 不得在文档中陈述未解决问题数量，应指明变更解决或开启的 ID。
- 具体脚本路径、配置项和校验行为以项目实际配置为准，本技能未提供其他平台或收费信息。