Add review finding reception loop

CHANGELOG.md

@@ -8,6 +8,15 @@
 - 使用校验和固定的 `actionlint` 检查 GitHub Actions 语义，并将官方 Actions 固定到完整 commit SHA。
 - 本地发布检查与 CI 使用相同的 Markdown 和 Harness contract 入口，避免只在 GitHub 上发现结构问题。
 
+## Review Finding Receiving / Fix Loop - 2026-07-23
+
+- 在 Plan、Code Review 和 Fix 三个角色中正向建立 Review Finding Receiving / Fix Loop 心智：artifact owner（Plan Writer / Fix）收到 finding 后先 Receiving（理解→核对→判断→响应），成立且在 scope 内时最小修正并验证，不成立或依据不足时返回依据，含义不清时返回澄清问题，改变需求时标记决策点交回小P和秦鹏。
+- 修正 Plan Reviewer 和 Code Reviewer 的复审语义：复审修正或有依据的反馈，不只看是否按建议修改；接受反馈理由和证据时可以关闭 finding，信息不足时澄清或修订 finding，争议涉及需求或范围时经小P交秦鹏。所有开放 finding 闭合后才给出当前 gate GO。
+- 明确小P的 finding 路由边界：保留 finding 原意和证据路由给 artifact owner，不预判 finding 成立或有效，不替 artifact owner 完成 Receiving，不替 Reviewer 判断 finding 是否闭合。原 Reviewer 不可用时选择另一位独立于 artifact owner 的 Reviewer 接续，并完整移交上下文，不随意换人绕过分歧。
+- 删除 `roles/fix.md`、`docs/2026-07-20-harness-core-workflow-spec.md` 和 `HARNESS.md` 中将 finding 预判为"有效 finding""已确认 finding""确认应修复"等诱发盲目执行的旧表达；改为"已路由 finding""对已路由 finding 完成 Receiving""判断并响应 finding"。
+- `roles/plan-writer.md` 和 `roles/fix.md` 新增 Receiving 责任段；`roles/plan-reviewer.md` 和 `roles/code-reviewer.md` 新增复审反馈规则；`roles/coordinator.md` 新增 finding 路由边界与 Reviewer 改派规则。
+- 本次只调整 Harness 文档和角色心智，不新增状态机、finding 数据库、强制 disposition 表、新 Reviewer 身份或语义 marker validator；不改变 `scripts/validate_repository.py` 或 `tests/` 的现有结构 contract。
+
 ## Event-driven orchestration mindset - 2026-07-23
 
 - 在设计北极星中正向定义秦鹏、小P、云上C总、小C或云上小C的稳定身份：小P是中心编排者和状态所有者，云上C总是承担 Plan Writer 与 Code Reviewer 的架构师，实现 Bot 负责编码与自检。

HARNESS.md

@@ -36,7 +36,7 @@ Harness 先确定具体协作主体，再理解它们在不同阶段承担的角
 | 云上C总 | 架构师 | 作为 Plan Writer 把 confirmed Spec 转成可执行 Plan；实现完成后作为非实现方 Code Reviewer 独立审查结果 |
 | 小C或云上小C | 当前群 live discovery 唯一解析的实现者 | 作为 Implementer 在指定 workspace 实现、自检并交付可 Review 结果；收到 finding 后进入 Fix |
 
-Plan Writer 不批准自己的 Plan，Implementer 不批准自己的实现。Code Reviewer 默认是云上C总在 Review 阶段承担的职责，不是一个身份不明的常驻 Bot；只有秦鹏明确改变分工，或云上C总是本轮实现方时，小P才路由给另一个经确认的非本轮实现方。Fix 也不是新的 Bot 身份，而是原实现方处理已路由 finding 时重新进入的工作角色。
+Plan Writer 不批准自己的 Plan，Implementer 不批准自己的实现。Code Reviewer 默认是云上C总在 Review 阶段承担的职责，不是一个身份不明的常驻 Bot；只有秦鹏明确改变分工，或云上C总是本轮实现方时，小P才路由给另一个经确认的非本轮实现方。Fix 也不是新的 Bot 身份，而是原实现方对已路由 finding 完成 Receiving 时重新进入的工作角色。
 
 稳定角色心智位于 `roles/`。小P始终读取角色接口；目标 Bot 尚未稳定拥有对应心智时，派工随 Task Brief 附简短 Role Card 或目标可读的明确引用，已经具备时只发送 Task Brief。
 

HARNESS_DESIGN_PRINCIPLES.md

@@ -31,7 +31,7 @@ Harness 先建立具体协作主体的稳定心智，再说明它们在不同阶
 
 每个阶段角色应专注一个主要问题，并对一个清楚结果负责。
 
-Plan writer 把 Spec 变成可执行 Plan，不批准自己的 Plan；Plan reviewer 判断 Plan 是否忠实、清楚、可执行；implementer 完成当前工作并自检；reviewer 独立判断结果；fix 只处理已经路由的 finding。
+Plan writer 把 Spec 变成可执行 Plan，不批准自己的 Plan；Plan reviewer 判断 Plan 是否忠实、清楚、可执行；implementer 完成当前工作并自检；reviewer 独立判断结果；fix 接收已经路由的 finding，独立核对其是否成立，并根据判断完成修正、反馈或提出决策点。
 
 这些角色是具体主体在某个阶段承担的职责，不是身份不明的新 Bot。默认由小P Review 云上C总写的 Plan，由云上C总 Review 小C或云上小C的实现；如果默认分工会造成自写自批，小P必须路由给另一个经确认的非产出方。小P负责选择角色和路由结果，不把多个角色重新合并到自己身上。
 
@@ -61,11 +61,11 @@ Plan writer 定义 Unit、完成条件和 gate；小P在收到并确认正式结
 
 ## 7. 优先塑造心智，而不是堆规则
 
-Harness 应先说清角色、目标、边界、结果和协作语义，让智能体能够判断和发挥。
+Harness 应先说清角色、目标、边界、结果和协作语义，让智能体能够判断和发挥。能够通过正向心智、充分上下文和清楚协作语义解决的问题，不增加负向规则。
 
-复杂流程仍需要少量薄协议，保护经常丢失或容易被绕过的交接点。但协议不是证据表格：代码、测试、日志、截图和 review finding 是认真工作后自然留下的结果，不应为了填表而重复制造。
+复杂流程仍需要少量薄协议，保护需求权威、角色分离、审批关系、不可逆操作等后果严重的边界。但协议不是证据表格：代码、测试、日志、截图和 review finding 是认真工作后自然留下的结果，不应为了填表而重复制造。
 
-只有真实运行反复证明某个问题仅靠清楚心智仍不稳定时，才为它增加一条最小 guardrail。
+只有问题会破坏上述严重边界，或者真实运行反复证明它会造成高成本失败且仅靠清楚心智仍不稳定时，才为它增加一条最小 guardrail。除此之外，任务策略和具体交互方式有意留给智能体根据现场判断。
 
 ## 8. 区分协议、心智和策略
 
@@ -96,3 +96,5 @@ Harness 重构的目标不是文档统一、字段增多或模板更整齐，而
 5. Plan 和 Execution Unit 是否能够完成、验证和交接？
 6. 这次修改的是协议、角色心智还是任务策略，是否改对了层？
 7. 真实流程是否能通过角色间的正式交接最终到达交付，而不是依赖小P持续监控其他 Bot？
+8. 目标行为能否通过正向心智、充分上下文或清楚协作语义解决，而不增加负向规则？
+9. 新增 guardrail 是否确实保护严重边界或反复的高成本失败，并把其余策略空间留给智能体？

README.md

@@ -25,7 +25,7 @@ Harness 在当时的目标项目 workspace 中执行。本仓库是控制面，
 
 ```text
 workspace 已指定 + 实现方已从群内唯一解析 → 需求输入 → confirmed Spec → Plan 写审分离
-→ Implementation → 独立 Code Review → Fix 后复审
+→ Implementation → 独立 Code Review → Fix Receiving 后复审
 → live verification → submit / CI → close
 ```
 

docs/2026-07-20-harness-core-workflow-spec.md

@@ -106,9 +106,9 @@ Harness 先正向定义具体协作主体，再说明它们在不同阶段承担
 
 ### 4.6 Fix
 
-Fix 不是新的长期 Bot 身份，而是实现方收到有效 finding 后重新进入的工作角色：
+Fix 不是新的长期 Bot 身份，而是实现方收到已路由 finding 后重新进入的工作角色：
 
-> 我的职责是理解已确认的 finding，在原 scope 内完成定向修复并重新验证。若 finding 实际改变需求，应交回小P和秦鹏，不应自行扩大范围。
+> 我的职责是对已路由的 finding 完成 Receiving（理解→核对→判断→响应）。成立且在 scope 内时最小修正并验证；不成立或依据不足时返回依据；含义不清时返回澄清问题；实际改变需求时标记决策点交回小P和秦鹏。
 
 ### 4.7 心智如何落地
 
@@ -156,7 +156,7 @@ workspace 与实现方已由秦鹏指定（Harness 外部前置条件）
 
 - Plan writer 不能给自己的 Plan 判定 GO。
 - Plan 没有说清任务边界时，小P退回 Plan，不替 Plan writer 编造实现步骤。
-- Code review finding 先由小P判断应进入 fix、需求决策还是 blocked。
+- Code review finding 先由小P路由到 Fix、需求决策或 blocked；小P不预判 finding 是否成立。
 - Fix 完成只表示可以重新 review；必须由 code reviewer 给出 GO，才能进入小P收口。
 - 一个 gate 的 GO 只表示允许进入下一步，不等于 submitted、deployed、verified 或 closed。
 - 缺仓库、权限、登录、工具、可读上下文或 runtime 条件时，当前节点进入 blocked；条件恢复后回到中断处继续。