[Guard Flow] 对齐 security fragment 与 security_review_required 状态轮次

[liuli195]

This was generated by AI during triage.

详细背景

PR #135 引入 repo-pr-governance Guard Profile 后，Guard artifact 的 freshness scope 使用 current_state_entry。实际推进时，Security fragment 曾在 local_review_required 阶段提前由 builder 写入；随后 Guard Instance 进入 security_review_required，再提交 security_review_required 的 state_completed 事件时，Runtime 判定 security_fragment 不属于当前状态轮次，返回 guard_failed / missing_artifacts。

主 agent 需要手动在进入 security_review_required 后重新运行 build-review-fragment 写 security fragment，然后第二次提交 state_completed 才能进入 completed。

这是流程顺序问题，不是 review 结论问题。它会让 Guard 状态推进需要人工知道“先推进 local review，再重新写 security fragment，再推进 security”。

产品解决方案

让 repo-pr-governance Guard 流程把“进入 security_review_required 后生成 security fragment”变成明确、可恢复、可验证的标准路径。用户或 agent 不应靠失败信息猜测需要重新写 fragment。

用户视角：local review 完成后，Guard Brief 或 handoff 应直接说明下一步是运行 security review 并写当前状态轮次的 security fragment；如果 security fragment 是进入状态前生成的，应被明确标记为 stale-state evidence。

详细技术实现方案

• 在 repo-pr-governance Guard Profile / docs 中明确 local_review_required 和 security_review_required 的 artifact 写入时序。
• 为 security_review_required 增加接手说明：进入该状态后必须重新生成 security fragment，不能复用进入状态前的 fragment。
• 可选地调整 artifact reuse_policy 或引入状态轮次感知的 builder payload 路径，使 builder 输出和 Guard Runtime 的 current_state_entry freshness 对齐。
• 在本仓库增加一个最小回归验证：先写 security fragment，再推进 local review，确认 security state_completed 会失败；随后重写 security fragment，确认可完成。该测试应固化预期，避免未来 agent 误判为 review 失败。
• 保持 PR Flow fragment 内容语义仍由 build-review-fragment / pr-submit 校验，不把 JSON 内容语义塞进当前 Guard Point。