Bug: DP-5 can be persisted without three failed fix attempts

[jack-lrx]

Problem

The bug-investigator workflow documents that DP-5 escalation is allowed only after at least three failed fix attempts.

However, the generic state command currently allows callers to persist DP-5 state fields (for example, dp_5_result, dp_5_timestamp, and related evidence fields) without enforcing that requirement.

This can allow an execution agent to enter DP-5 prematurely.

Expected behavior

DP-5 should only be persisted through a guarded escalation path after all of the following are true:

1. At least three distinct failed fix attempts have been recorded.
2. Every attempt contains structured failure evidence.
3. The evidence belongs to the current execution plan.
4. The workflow is in an eligible debugging state.
5. The user explicitly confirms the escalation.

Important distinction

A failed Wave code review and a failed debugging fix attempt are different events. A Wave Review failure count should not automatically satisfy the DP-5 debugging-attempt requirement.

Suggested direction

• Add a structured debugging-attempt ledger.
• Add guarded commands such as ssf debug attempt record/show and ssf debug escalate --confirm.
• Prevent the generic state command from directly writing protected DP-5 fields.
• Extend audit checks to detect DP-5 records that are not backed by valid evidence.
• Preserve compatibility for legacy state while reporting unsupported escalation records.

Suggested tests

• Reject escalation with zero, one, or two failed attempts.
• Allow escalation after three distinct valid failed attempts and explicit confirmation.
• Reject duplicate evidence.
• Reject evidence from a stale execution plan.
• Reject direct writes to protected DP-5 state fields.
• Verify that a Wave Review failure does not count as a debugging fix attempt.
• Detect unsupported legacy DP-5 records during audit.

[MageByte-Zero]

@jack-lrx 感谢提交 #103。我们核对贡献者图谱时发现，合并提交 6ba0e2e 的 Git 作者身份是 luorenxin luorenxin@boulderaitech.com，GitHub 尚未将这个邮箱映射到任何账号，因此 Contributors 图谱不会显示对应的 GitHub 用户资料。

如果这是你的邮箱，请在 GitHub Settings → Emails 中添加并完成验证；后续提交请将 git config user.email 设为该已验证邮箱，或使用 GitHub 账号提供的 noreply 邮箱。若不是你的邮箱，也请改用与你账号绑定的邮箱。无需为了展示效果重写已合并历史；邮箱完成绑定后，GitHub 通常会重新关联已有提交，统计页面可能需要一点时间刷新。