self-iteration

自迭代技能

5 阶段流程

阶段 1：数据收集 + 已应用提案闭环验证

(a) 数据源收集（主要在 .claude/workframe-state/（另含 .claude/agent-memory/ 与 projects/ 下若干路径，见下表） 下，由 hook / deterministic scripts / system skills 维护）：

• .claude/workframe-state/skill-metrics.yaml — 技能/规则使用汇总（由 recompute_skill_metrics.py 从 events.jsonl 重算）
• .claude/workframe-state/events.jsonl — 原始事件流（审计/追因时读，日常决策读 metrics 即可）
• .claude/workframe-state/activity-state.json — 活跃度 + dormant 状态 + pending_maintenance（status=open）；若 dormant=true 或 wake_up_pending=true 则本次自迭代直接退出（除非由 /core:maintenance-review 显式触发）。pending_maintenance 里的 kind/details 是本次识别模式的重要线索，应与 notes/events 证据一起纳入阶段 2 分析。
• .claude/agent-memory/*/notes.md — 各角色微反思
• .claude/agent-memory/shared/MEMORY.md 和 shared/notes.md — 跨角色共识
• projects/changelog.md — 历史操作日志
• projects/issues/ — 历史问题记录（若有结构化文件）

(b) 扫描 projects/proposals/applied/*.yaml 中 verified: null 的条目做闭合验证：

• 对每条读取 verify_by（日期）和 verify_signal（需观察到的信号表达式）
• 若今天 ≥ verify_by：
  • 读取 skill-metrics.yaml / events.jsonl，判断 verify_signal 是否已达成
  • signal_met=true → append events.jsonl：{"ts":"<ISO-8601>","type":"proposal_verified","proposal_id":"<id>","signal_met":true}；将提案文件中 verified: true
  • signal_met=false → append events.jsonl：{"ts":"<ISO-8601>","type":"proposal_verified","proposal_id":"<id>","signal_met":false}，再 append {"ts":"<ISO-8601>","type":"proposal_failed","proposal_id":"<id>"}（供 audit / 下一轮 self-iteration 反思用；proposal_failed 不计入 check-iteration-trigger.py 的 problem 加权分；recompute_skill_metrics.py 实际统计的是 proposal_verified.signal_met=false 累加到 proposal_failures_count，不直接读 proposal_failed）；将提案文件中 verified: false

阶段 2：模式识别 + 置信度评分

从阶段 1 收集的数据中识别候选模式：

• 重复问题：notes / changelog / events 中有明确证据显示同类问题重复出现。occurrences 是置信度计算的证据输入，不是硬门槛；低于 3 次仍可计算 confidence，但通常低于提案阈值。
• 低效流程：仅当 notes / changelog / issues 中存在明确的耗时或阻塞记录时方可使用；系统无耗时事件，不得凭感觉声称"平均耗时高于预期"。
• 未覆盖场景：仅当 notes / changelog 中有明确的"用户重复手工处理"记录时方可使用；不得无证据臆造"手工处理"场景。
• 技能低成功率：近 30 天某 skill success/invocations < 0.6（来自 skill-metrics.yaml）。仅供人工判读，不作自动触发信号（success 为 agent 自评，实测从未产出 false，作触发条件永不满足）——用它时须结合 notes / user_correction 等独立证据，不得仅凭该比值提案。
• 提案失败回路：有 proposal_failed 事件的旧提案 → 反思当初假设，识别失败原因。