cc-devflow 4.5.2 → 4.5.4

package/.claude/skills/cc-act/CHANGELOG.md

@@ -1,5 +1,24 @@
 # CC-Act Skill Changelog
 
+## v1.8.1 - 2026-04-29
+
+- add structured ship preflight fields with `ShipPreflightError` rescue actions
+- require rollback guards before publish, merge, PR update, or release note handoff
+- add PR branch hygiene and learning extraction targets to delivery templates
+
+## v1.8.0 - 2026-04-28
+
+- add remote state consistency rules for issue, PR, tracker, `needs-info`, and `ready-for-agent` closeout handoffs
+- require dangerous git actions to have explicit ship semantics and user confirmation before reset, clean, branch deletion, or whole-tree restore
+- require tooling changes to prove the real hook, adapt, publish, lint, or verification entrypoint still works
+
+## v1.7.0 - 2026-04-28
+
+- carry cc-check QA feedback-loop and behavior evidence into PR briefs, handoffs, and release notes so ship materials preserve expected/actual/reproduction truth
+- add durable follow-up brief rules for current behavior, desired behavior, key interfaces, acceptance criteria, and out-of-scope boundaries
+- teach shared follow-up and evidence extraction to include report-card followup briefs and QA architecture follow-ups
+- extend readiness dashboard guidance with feedback-loop quality and behavior evidence checks
+
 ## v1.6.4 - 2026-04-28
 
 - add a readiness dashboard covering review freshness, review quality, specialist facets, QA coverage, browser QA, failure ownership, documentation release, and PR body accuracy

package/.claude/skills/cc-act/PLAYBOOK.md

@@ -26,6 +26,7 @@
 2. 确认 `review/report-card.json` 是 `pass`，且没有未解释的 gaps / reroute
 3. 确认 `planning/tasks.md` 不再有未完成项
 4. 确认 `review.freshness` 新鲜、`runtime.failureOwnership` 无未解释失败、`qa.coverageAudit` / `qa.browserEvidence` 有证据或明确 skip
+5. 确认 `qa.feedbackLoop` / `qa.behaviorEvidence` 能支撑行为结论；不可复现时必须写清缺什么 artifact / 权限 / 输入
 
 如果 gate 没闭合，直接回 `cc-check` 或 `cc-do`，不要在 `cc-act` 自我安慰。
 
@@ -82,7 +83,10 @@ Ship 必须属于这 4 种模式之一：
 3. 检查提交边界，按逻辑单元拆分，保证提交顺序不引用未来代码。
 4. 如果有 WIP commit，只能用非破坏性 rebase / fixup 处理，不允许盲目 soft reset。
 5. push 前比较 local / remote HEAD；PR 前检查是否已有打开 PR / MR。
-6. 生成 readiness dashboard：review freshness、review quality、QA coverage、browser QA、failure ownership、documentation release、PR body accuracy。
+6. 生成 readiness dashboard：review freshness、review quality、QA coverage、browser QA、feedback loop、behavior evidence、failure ownership、documentation release、PR body accuracy。
+7. 生成 ship preflight：branch/base/remote/auth/clean tree/review freshness/ship mode。
+8. preflight 失败必须命名为 `ShipPreflightError`，并写明 rescue action 或切到 `local-handoff`。
+9. 发布、合并、PR 更新或 release note 前必须写 rollback guard。
 
 ## Phase 3: Build Delivery Pack
 
@@ -114,8 +118,12 @@ Ship 必须属于这 4 种模式之一：
 - review packet path / summary
 - finding triage summary
 - QA / claim evidence summary
+- ship preflight and `ShipPreflightError` rescue if any
+- rollback guard
+- QA behavior evidence and feedback-loop quality
 - readiness dashboard
 - PR body accuracy check
+- Durable follow-up briefs: current behavior、desired behavior、key interfaces、acceptance criteria、out of scope
 
 缺这些字段时，可以生成 local handoff，但不能声称 PR body 已经可 review。
 
@@ -183,6 +191,8 @@ Ship 必须属于这 4 种模式之一：
 - 长期方向写 `devflow/roadmap/roadmap.md`
 - 下一轮待排队动作写 `devflow/roadmap/backlog.md`
 - 不要把噪音和碎念回写成系统真相
+- follow-up 必须是 durable brief：用领域语言写 current behavior、desired behavior、key interfaces、acceptance criteria、out of scope
+- 独立行为拆独立条目；有依赖关系时写明顺序，方便下一轮并行或排队
 
 ## Phase 7: Declare The Next Entry
 
@@ -201,6 +211,9 @@ Ship 必须属于这 4 种模式之一：
 4. `cc-simplify`、单测、e2e、commit/push 的结果是不是都能追溯？
 5. PR body / release note / handoff / changelog 说的是不是同一套现实？
 6. readiness dashboard 有没有 blocker 或 stale warning？
+7. follow-up 是不是行为契约，而不是“改某文件某行”的易腐烂 TODO？
+8. ship preflight failure 是否有 `ShipPreflightError`、artifact ref 和 rescue action？
+9. rollback guard 是否足够让下一位维护者不靠聊天记录回退？
 
 如果第 1 或第 3 题答案不是“能”，说明 `cc-act` 仍然太重或太糊。
 

package/.claude/skills/cc-act/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-act
-version: 1.6.4
+version: 1.8.1
 description: 'Use when verified work must be shipped or handed off with a clear landing path: run simplify and required tests, create or update a PR, prepare a local handoff, close out merged work, sync docs, write release notes, and fold follow-ups back into backlog or roadmap.'
 triggers:
   - 准备提 PR
@@ -37,7 +37,7 @@ effects:
   - roadmap or backlog follow-up updates when needed
 entry_gate:
   - Accept only a passing review/report-card.json with reroute=none and specSyncReady=true.
-  - Freeze current branch, PR, and ship-mode facts before writing delivery materials.
+  - Freeze current branch, PR, ship-mode, auth, clean-tree, and rollback facts before writing delivery materials.
   - If simplify, tests, or act changes code or verification scope, return to cc-check immediately.
 exit_criteria:
   - The ship mode is explicit, delivery materials match that mode, and the next maintainer has one clear entry point.
@@ -127,7 +127,8 @@ tool_budget:
 3. 运行 `scripts/verify-act-gate.sh --dir <requirement-dir>`，确认 gate 真的闭合。
 4. 运行 `scripts/detect-ship-target.sh`，识别当前分支、base branch、PR 状态与推荐 ship 路径。
 5. 检查 `review.freshness`、`runtime.failureOwnership`、`qa.coverageAudit`、`qa.browserEvidence`，确认 readiness dashboard 没有 blocker。
-6. 如果在 `cc-act` 期间因为 `cc-simplify`、单测、e2e、review 修复而改了代码，必须回 `cc-check`，不能带着旧证明继续 ship。
+6. 检查 `qa.feedbackLoop`、`qa.behaviorEvidence`、`qa.architectureFollowUps` 和 follow-up brief，确认交付材料继承的是行为证据，不是聊天记忆或易腐烂 TODO。
+7. 如果在 `cc-act` 期间因为 `cc-simplify`、单测、e2e、review 修复而改了代码，必须回 `cc-check`，不能带着旧证明继续 ship。
 
 ## Ship Modes
 
@@ -213,6 +214,32 @@ tool_budget:
 7. PR idempotency：已有打开的 PR / MR 只更新 body，不重复创建。
 8. Review range：PR brief / PR body 必须写清 `cc-check` 审过的 base/head SHA、review packet、finding triage 摘要。
 9. Post-integration verification：本地合并或 post-merge closeout 后，必须在 merged result 上跑必要 gate；不能只继承合并前绿色。
+10. Follow-up durability：PR brief / release note / backlog writeback 里的 follow-up 必须写成行为契约，包含 current behavior、desired behavior、key interfaces、acceptance criteria、out of scope；不要把当前文件路径或行号当成长期计划。
+11. Remote state consistency：如果本次 closeout 触碰 GitHub issue / PR / tracker，必须记录当前 state、目标 state、允许转换、已保留事实和下一位 owner；`needs-info` 必须保留已确认事实和具体问题，`ready-for-agent` 必须有可执行 brief。
+12. Tooling smoke：如果本次改动影响 hook、pre-commit、lint、publish、adapt 或验证脚本，必须跑真实入口或最接近真实入口的 smoke；只读配置文件不等于工具链可用。
+
+## Ship Preflight And Rescue
+
+ship preflight 必须结构化记录：
+
+- `branch`: 当前分支、base、remote、local/remote HEAD 关系
+- `auth`: `gh` / registry / deploy / package publish 等权限是否可用
+- `workspace`: clean tree、staged files、未跟踪文件和相关 stash
+- `reviewFreshness`: `cc-check` 审查范围是否仍绑定当前 HEAD
+- `shipMode`: `create-pr` / `update-pr` / `local-handoff` / `post-merge-closeout`
+
+任何 preflight failure 都必须命名为 `ShipPreflightError`，并写清 rescue action。
+不能用“工具不可用”当作模糊失败；要明确切 `local-handoff`、补 auth、刷新 review，
+还是返回 `cc-check`。
+
+rollback guard 必须在 publish、merge、PR 更新或 release note 前写清：
+
+- safe state
+- rollback command 或人工回退步骤
+- data / migration / package / remote side effect
+- owner
+
+没有 rollback guard 的 release 只能停在 handoff，不准发布。
 
 ## Readiness Dashboard
 
@@ -222,9 +249,11 @@ PR / handoff 之前必须把 readiness 压成一屏事实：
 2. Review quality：记录 `review.qualityScore`、specialist facet 覆盖、finding triage 摘要。
 3. QA coverage：记录 `qa.coverageAudit` 的 coverage、gaps、e2e/eval requirement。
 4. Browser QA：UI / 用户路径变更必须有 `qa.browserEvidence`，否则要有 skip reason。
-5. Failure ownership：`runtime.failureOwnership` 不能有未解释的 `in-branch` 或 `ambiguous` failure。
-6. Documentation release：README / CLAUDE / architecture / handoff / changelog 的同步状态必须可审计。
-7. PR body accuracy：PR body 必须从当前 `pr-brief.md`、当前 diff、当前 report-card 重建；已有 PR body 只能被刷新，不能被继承。
+5. Feedback loop：bugfix / 行为变更必须有 `qa.feedbackLoop`，否则要有不可复现或不适用原因。
+6. Behavior evidence：expected / actual / reproduction steps 必须能被 reviewer 独立理解。
+7. Failure ownership：`runtime.failureOwnership` 不能有未解释的 `in-branch` 或 `ambiguous` failure。
+8. Documentation release：README / CLAUDE / architecture / handoff / changelog 的同步状态必须可审计。
+9. PR body accuracy：PR body 必须从当前 `pr-brief.md`、当前 diff、当前 report-card 重建；已有 PR body 只能被刷新，不能被继承。
 
 readiness dashboard 有 blocker 时，不能创建或更新 PR，只能 reroute 到 `cc-check` / `cc-do` 或生成 local handoff。
 
@@ -236,6 +265,7 @@ readiness dashboard 有 blocker 时，不能创建或更新 PR，只能 reroute
 2. 丢弃未合并工作必须要求用户显式确认；没有确认时只能转 `local-handoff`。
 3. branch cleanup 只发生在 merge / PR / discard 语义已经清楚之后。
 4. `post-merge-closeout` 必须记录 merged-result verification：命令、exit status、关键观察、失败时 reroute。
+5. 危险 Git 动作必须有明确 ship 语义：`git push` 只在 `create-pr` / `update-pr` / release lane 执行，`git reset --hard`、`git clean -f`、`git branch -D`、整树 restore/checkout 必须先列出对象并取得用户确认；没有确认时写 handoff，不执行。
 
 ## Documentation Release
 
@@ -249,6 +279,16 @@ readiness dashboard 有 blocker 时，不能创建或更新 PR，只能 reroute
 6. Discoverability：新增文档必须能从 README、CLAUDE 或 handoff 入口找到。
 7. TODO/backlog cleanup：只把有 diff 证据完成的事项移到 completed；新 follow-up 写回 backlog/roadmap。
 
+## Issue And Follow-Up Handoff
+
+当本次交付产生或更新 issue / PR / backlog follow-up 时，文案必须耐 refactor：
+
+- 先写用户可观察行为：what happened / expected / reproduction 或 desired behavior。
+- 再写 agent 可执行 contract：acceptance criteria、allowed scope、blocked by、verification command。
+- 不把短期文件路径、行号、函数名写成长期事实；只有当前 reviewer 需要定位时才放进 PR brief 的实现备注。
+- 多个 follow-up 必须按独立可验证切片拆开，并标明 `AFK` / `HITL`、blocked-by 和 owner。
+- 已经问过或确认过的信息不能在 `needs-info` 里丢失；问题必须具体到 reporter 能直接补证据。
+
 ## Loop
 
 1. 先锁定 ship 事实：当前分支、base branch、PR 状态、requirement 状态。

package/.claude/skills/cc-act/assets/PR_BRIEF_TEMPLATE.md

@@ -24,6 +24,27 @@
 - Base branch:
 - PR / MR:
 
+## Ship Preflight
+
+- Branch:
+- Base:
+- Remote:
+- Local / remote HEAD:
+- Auth:
+- Clean tree:
+- Review freshness:
+- Ship mode:
+- `ShipPreflightError`:
+- Rescue action:
+
+## PR Branch Hygiene
+
+- Existing PR / MR:
+- Duplicate PR risk:
+- Commit split:
+- Push idempotency:
+- Body source:
+
 ## Review Range
 
 - Reviewed base SHA:
@@ -39,6 +60,8 @@
 - Specialist review facets:
 - QA coverage:
 - Browser QA:
+- Feedback loop:
+- Behavior evidence:
 - Failure ownership:
 - Documentation release:
 - PR body accuracy:
@@ -57,6 +80,21 @@
 - Fresh evidence:
 - Merged-result verification:
 
+## Rollback Guard
+
+- Safe state:
+- Rollback command / manual steps:
+- Side effects:
+- Owner:
+
+## QA Behavior Evidence
+
+- Feedback loop:
+- Expected behavior:
+- Actual behavior:
+- Reproduction steps:
+- Consistency:
+
 ## Documentation Sync
 
 - `CLAUDE.md`:
@@ -81,7 +119,12 @@
 
 ## Follow-Ups
 
-- 
+- Current behavior:
+- Desired behavior:
+- Key interfaces:
+- Acceptance criteria:
+- Out of scope:
+- Learning extraction target:
 
 ## Risks
 

package/.claude/skills/cc-act/assets/RELEASE_NOTE_TEMPLATE.md

@@ -20,10 +20,27 @@
 
 - 
 
+## Rollback Guard
+
+- Safe state:
+- Rollback command / manual steps:
+- Side effects:
+- Owner:
+
+## QA Behavior Evidence
+
+- Feedback loop:
+- User-visible behavior:
+- Reproduction / verification path:
+
 ## Ops Notes
 
 - 
 
 ## Follow-Ups
 
-- 
+- Current behavior:
+- Desired behavior:
+- Acceptance criteria:
+- Out of scope:
+- Learning extraction target:

package/.claude/skills/cc-act/references/closure-contract.md

@@ -10,6 +10,7 @@
 6. 如果文件结构变了，就同步对应目录的 `CLAUDE.md`
 7. PR / handoff 必须记录 `cc-check` 审过的 base/head SHA、review packet、finding triage 摘要
 8. readiness dashboard 必须说明 review freshness、QA coverage、browser evidence、failure ownership、documentation release、PR body accuracy
+9. behavior handoff 必须带上 QA feedback loop、expected / actual / reproduction steps，以及 durable follow-up brief
 
 ## Ship Decision Contract
 
@@ -35,6 +36,7 @@
 9. 删除 branch、worktree、未合并提交、归档 requirement 前必须列出对象；丢弃未合并工作需要显式确认
 10. verification 每次进入 `cc-act` 都必须重新跑；只有 push、PR 更新、文档生成等动作可以因为幂等状态跳过
 11. PR body accuracy 必须对照当前 report-card、当前 diff、当前 commits；旧 body 不能作为证据源
+12. follow-up 回写必须用行为契约表达，包含 current behavior、desired behavior、key interfaces、acceptance criteria、out of scope；不能只写文件路径或聊天 TODO
 
 ## Memory Consolidation
 
@@ -52,6 +54,7 @@
 - maintainer 知道怎么验证
 - PR / handoff / release 材料反映同一套事实
 - readiness dashboard 没有 blocker，PR body accuracy 已检查或明确阻塞
+- QA behavior evidence 和 feedback loop 已进入 PR / handoff / release 材料
 - post-merge closeout 反映 merged result 的验证事实，而不是只反映合并前事实
 - 下一轮计划入口更清楚
 - 文档入口可发现，changelog 不丢历史，TODO / backlog 只记录有证据的事项

package/.claude/skills/cc-act/scripts/cc-act-common.sh

@@ -189,6 +189,30 @@ req_act_collect_followups() {
 
   if [[ -f "$report_card" ]]; then
     jq -r '(.gaps // [])[]?' "$report_card" 2>/dev/null | sed '/^$/d' > "$out_file" || true
+    jq -r '
+      (.followupBriefs // .review.followupBriefs // [])[]?
+      | [
+          ("summary: " + (.summary // .title // "follow-up")),
+          ("current: " + (.currentBehavior // "not recorded")),
+          ("desired: " + (.desiredBehavior // "not recorded")),
+          ("interfaces: " + ((.keyInterfaces // []) | join(", "))),
+          ("acceptance: " + ((.acceptanceCriteria // []) | join("; "))),
+          ("out-of-scope: " + ((.outOfScope // []) | join(", ")))
+        ]
+      | join(" | ")
+    ' "$report_card" 2>/dev/null | sed '/^$/d' >> "$out_file" || true
+    jq -r '
+      (.qa.architectureFollowUps // [])[]?
+      | [
+          ("summary: " + (.summary // .title // "architecture follow-up")),
+          ("current: " + (.currentBehavior // "not recorded")),
+          ("desired: " + (.desiredBehavior // "not recorded")),
+          ("interfaces: " + ((.keyInterfaces // []) | join(", "))),
+          ("acceptance: " + ((.acceptanceCriteria // []) | join("; "))),
+          ("out-of-scope: " + ((.outOfScope // []) | join(", ")))
+        ]
+      | join(" | ")
+    ' "$report_card" 2>/dev/null | sed '/^$/d' >> "$out_file" || true
   fi
 
   if [[ -f "$manifest" ]]; then
@@ -238,7 +262,9 @@ req_act_collect_evidence() {
     (.evidence // [])[]?,
     ((.claimEvidence // [])[]? | "- " + (.claim // "claim") + ": " + (.status // "unknown") + " via " + (.commandOrArtifact // "artifact") + " - " + (.keyObservation // "")),
     (if .qa.coverageAudit then "- qa.coverage: " + (.qa.coverageAudit.status // "unknown") + ", gaps=" + (((.qa.coverageAudit.gaps // []) | length) | tostring) else empty end),
-    (if .qa.browserEvidence then "- qa.browser: " + (.qa.browserEvidence.status // "unknown") + ", mode=" + (.qa.browserEvidence.mode // "unknown") else empty end)
+    (if .qa.browserEvidence then "- qa.browser: " + (.qa.browserEvidence.status // "unknown") + ", mode=" + (.qa.browserEvidence.mode // "unknown") else empty end),
+    (if .qa.feedbackLoop then "- qa.feedbackLoop: " + (.qa.feedbackLoop.status // "unknown") + ", mode=" + (.qa.feedbackLoop.mode // "unknown") + ", signal=" + (.qa.feedbackLoop.signalSharpness // "not recorded") else empty end),
+    (if .qa.behaviorEvidence then "- qa.behavior: " + (.qa.behaviorEvidence.status // "unknown") + ", expected=" + (.qa.behaviorEvidence.expectedBehavior // "not recorded") + ", actual=" + (.qa.behaviorEvidence.actualBehavior // "not recorded") else empty end)
   ' "$report_card" 2>/dev/null | sed '/^$/d' > "$out_file" || true
   req_act_dedup_file "$out_file"
 }

package/.claude/skills/cc-act/scripts/render-pr-brief.sh

@@ -157,6 +157,23 @@ browser_qa_summary="$(jq -r '
     (if (($browser.skipReason // "") != "") then ", skip=\($browser.skipReason)" else "" end)
   end
 ' "$report_card")"
+feedback_loop_summary="$(jq -r '
+  .qa.feedbackLoop as $loop |
+  if $loop == null then
+    "not recorded"
+  else
+    "status=\($loop.status // "unknown"), mode=\($loop.mode // "unknown"), determinism=\($loop.determinism // "not recorded"), reproductionRate=\($loop.reproductionRate // "not recorded")" +
+    (if (($loop.blockedReason // "") != "") then ", blocked=\($loop.blockedReason)" else "" end)
+  end
+' "$report_card")"
+behavior_evidence_summary="$(jq -r '
+  .qa.behaviorEvidence as $behavior |
+  if $behavior == null then
+    "not recorded"
+  else
+    "status=\($behavior.status // "unknown"), boundary=\($behavior.userFacingBoundary // "not recorded"), expected=\($behavior.expectedBehavior // "not recorded"), actual=\($behavior.actualBehavior // "not recorded"), steps=\((($behavior.reproductionSteps // []) | length))"
+  end
+' "$report_card")"
 failure_ownership_summary="$(jq -r '
   (.runtime.failureOwnership? // [])
   | if length == 0 then
@@ -210,6 +227,8 @@ pr_body_accuracy_summary="body must be regenerated from this pr-brief, current r
   echo "- Specialist review facets: $specialist_review_summary"
   echo "- QA coverage: $qa_coverage_summary"
   echo "- Browser QA: $browser_qa_summary"
+  echo "- Feedback loop: $feedback_loop_summary"
+  echo "- Behavior evidence: $behavior_evidence_summary"
   echo "- Failure ownership: $failure_ownership_summary"
   echo "- Documentation release: $documentation_release_summary"
   echo "- PR body accuracy: $pr_body_accuracy_summary"
@@ -252,6 +271,18 @@ pr_body_accuracy_summary="body must be regenerated from this pr-brief, current r
     echo "- No evidence lines captured yet."
   fi
   echo
+  echo "## QA Behavior Evidence"
+  echo
+  echo "- Feedback loop: $feedback_loop_summary"
+  echo "- Behavior evidence: $behavior_evidence_summary"
+  jq -r '
+    .qa.behaviorEvidence as $behavior |
+    if $behavior == null then empty else
+      (($behavior.reproductionSteps // [])[]? | "- Reproduction step: " + .),
+      (($behavior.domainLanguage // [])[]? | "- Domain language: " + .)
+    end
+  ' "$report_card" 2>/dev/null | sed '/^$/d' || true
+  echo
   echo "## Documentation Sync"
   echo
   echo "- \`CLAUDE.md\`: $claude_status"

package/.claude/skills/cc-act/scripts/verify-act-gate.sh

@@ -47,6 +47,8 @@ failure_ownership_open="$(jq -r '
 ' "$report_card" 2>/dev/null || echo 0)"
 coverage_status="$(jq -r '.qa.coverageAudit.status // "unknown"' "$report_card" 2>/dev/null || echo unknown)"
 browser_status="$(jq -r '.qa.browserEvidence.status // "unknown"' "$report_card" 2>/dev/null || echo unknown)"
+feedback_loop_status="$(jq -r '.qa.feedbackLoop.status // "skipped"' "$report_card" 2>/dev/null || echo skipped)"
+behavior_evidence_status="$(jq -r '.qa.behaviorEvidence.status // "skipped"' "$report_card" 2>/dev/null || echo skipped)"
 
 remaining_tasks="0"
 if [[ -f "$tasks_file" ]]; then
@@ -62,6 +64,8 @@ fi
 [[ "$failure_ownership_open" -eq 0 ]] || { echo "Gate open: failure_ownership_open=$failure_ownership_open" >&2; exit 1; }
 [[ "$coverage_status" != "blocked" && "$coverage_status" != "fail" && "$coverage_status" != "pending" ]] || { echo "Gate open: coverage_status=$coverage_status" >&2; exit 1; }
 [[ "$browser_status" != "blocked" && "$browser_status" != "fail" && "$browser_status" != "pending" ]] || { echo "Gate open: browser_status=$browser_status" >&2; exit 1; }
+[[ "$feedback_loop_status" != "blocked" && "$feedback_loop_status" != "fail" && "$feedback_loop_status" != "pending" ]] || { echo "Gate open: feedback_loop_status=$feedback_loop_status" >&2; exit 1; }
+[[ "$behavior_evidence_status" != "blocked" && "$behavior_evidence_status" != "fail" && "$behavior_evidence_status" != "pending" ]] || { echo "Gate open: behavior_evidence_status=$behavior_evidence_status" >&2; exit 1; }
 [[ "$remaining_tasks" -eq 0 ]] || { echo "Gate open: remaining_tasks=$remaining_tasks" >&2; exit 1; }
 
 cat <<EOF
@@ -75,5 +79,7 @@ REVIEW_FRESHNESS=$review_freshness
 FAILURE_OWNERSHIP_OPEN=$failure_ownership_open
 COVERAGE_STATUS=$coverage_status
 BROWSER_STATUS=$browser_status
+FEEDBACK_LOOP_STATUS=$feedback_loop_status
+BEHAVIOR_EVIDENCE_STATUS=$behavior_evidence_status
 REMAINING_TASKS=$remaining_tasks
 EOF

package/.claude/skills/cc-check/CHANGELOG.md

@@ -1,5 +1,23 @@
 # CC-Check Skill Changelog
 
+## v1.10.1 - 2026-04-29
+
+- add named runtime failure fields with artifact references, owners, and rescue actions
+- add human UAT evidence to the report card so manual acceptance can block or reroute honestly
+- require review findings to carry explicit rescue actions instead of vague follow-up text
+
+## v1.10.0 - 2026-04-28
+
+- add test fixture honesty review for partial fixtures, generated stubs, casts, and missing mock payload fields
+- require fixture shortcuts to preserve public seam behavior instead of hiding contract or input-shape problems
+
+## v1.9.0 - 2026-04-28
+
+- add QA feedback-loop evidence so bugfix and behavior checks record reproduction mode, determinism, signal quality, and blocked loop reasons before a pass verdict
+- add behavior evidence fields for expected behavior, actual behavior, reproduction steps, consistency, and domain language
+- tighten test-quality review around public-interface tests, system-boundary mocks, and architecture follow-ups when no correct test seam exists
+- update the report-card template, renderer, and gate validation for the new QA evidence shape while keeping older reports structurally compatible
+
 ## v1.8.4 - 2026-04-28
 
 - add review freshness, quality score, specialist review facets, and finding confidence fingerprints so stale or noisy review evidence cannot masquerade as current proof

package/.claude/skills/cc-check/PLAYBOOK.md

@@ -41,6 +41,7 @@ NO PASS WITHOUT FRESH EVIDENCE
    - task review proof
    - requirement diff review
    - claim evidence matrix
+   - QA feedback loop and behavior evidence
    - QA regression / test-quality proof
    - QA coverage and browser evidence
    - review freshness and finding confidence
@@ -62,6 +63,8 @@ NO PASS WITHOUT FRESH EVIDENCE
 6. 把每个成功声明映射到 `claimEvidence[]`
 7. 行为变更必须补 `qa` 证据或例外理由
 8. 失败输出必须写入 `runtime.failureOwnership[]`
+9. failure ownership 必须包含 named error、artifact refs 和 rescue action
+10. human UAT 必须 pass、fail、blocked 或带 skip reason；失败不能被测试绿灯覆盖
 
 ## Verification Layers
 
@@ -69,11 +72,14 @@ NO PASS WITHOUT FRESH EVIDENCE
 2. Task review proof
 3. Requirement diff truth
 4. Claim evidence matrix
-5. QA regression and test quality
-6. QA coverage and browser evidence
-7. Review freshness and confidence calibration
-8. Failure ownership
-9. Spec alignment and sync readiness
+5. QA feedback loop and behavior evidence
+6. QA regression and test quality
+7. QA coverage and browser evidence
+8. Review freshness and confidence calibration
+9. Failure ownership
+10. Spec alignment and sync readiness
+11. Human UAT
+12. Named runtime errors and rescue actions
 
 ## Claim Evidence Matrix
 
@@ -121,13 +127,16 @@ review 还要带 `freshness`：`status`、`reviewedCommit`、`currentCommit`、`
 
 行为变化、bugfix、边界条件、用户可见流程必须补 `qa`：
 
+- `feedbackLoop`：用什么 loop 证明现实，速度、确定性、信号锋利度、复现率如何
+- `behaviorEvidence`：用户边界、expected / actual、复现步骤、稳定性、领域语言
 - `regressionProof`：red command、red failure reason、green command、是否恢复最终状态
-- `testQuality`：是否验证真实行为、mock 边界、是否存在 test-only production API
+- `testQuality`：是否经公共接口验证真实行为、mock 是否只停在系统边界、是否存在 test-only production API
+- `architectureFollowUps`：没有正确 test seam 时记录 seam / hidden coupling / shallow module 的后续改造
 - `tddException`：纯配置、生成文件、throwaway prototype 等例外和替代验证
 - `coverageAudit`：覆盖率、codepath / user-flow map、缺口、是否需要 e2e / eval、测试质量星级
 - `browserEvidence`：UI / 用户路径变更的 affected routes、截图、console、health score、issues，或明确 skip reason
 
-测试只绿过一次，不能证明 regression test 有效；断言 mock 本身，不能证明真实行为。
+测试只绿过一次，不能证明 regression test 有效；断言 mock 本身，不能证明真实行为。没有可信反馈环时，`pass` 不成立。
 
 ## Failure Ownership
 
@@ -171,6 +180,26 @@ review 还要带 `freshness`：`status`、`reviewedCommit`、`currentCommit`、`
   },
   "qa": {
     "status": "pass",
+    "feedbackLoop": {
+      "status": "pass",
+      "mode": "targeted-test",
+      "commandOrArtifact": "npm test -- src/feature/feature.test.ts",
+      "speed": "fast",
+      "determinism": "high",
+      "signalSharpness": "fails only when the target behavior is absent",
+      "reproductionRate": "1/1",
+      "attempts": [],
+      "blockedReason": ""
+    },
+    "behaviorEvidence": {
+      "status": "pass",
+      "userFacingBoundary": "feature action",
+      "expectedBehavior": "the user-visible behavior succeeds",
+      "actualBehavior": "verified by targeted test",
+      "reproductionSteps": [],
+      "consistency": "deterministic",
+      "domainLanguage": []
+    },
     "regressionProof": [],
     "testQuality": [],
     "coverageAudit": {
@@ -193,6 +222,7 @@ review 还要带 `freshness`：`status`、`reviewedCommit`、`currentCommit`、`
       "issues": [],
       "skipReason": "not a UI or user-path change"
     },
+    "architectureFollowUps": [],
     "tddException": null
   },
   "quickGates": [],
@@ -251,3 +281,4 @@ review 还要带 `freshness`：`status`、`reviewedCommit`、`currentCommit`、`
 4. `review.status` 是真实现实，还是我脑补的绿色？
 5. 如果把这份 `report-card.json` 给下一位接手者，他知道接下来去哪吗？
 6. diff review 是否同时覆盖了 plan completion、scope drift、critical pass、doc staleness？
+7. feedback loop 是否真的证明了用户描述的行为，而不是只证明附近代码能跑？

package/.claude/skills/cc-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-check
-version: 1.8.4
+version: 1.10.1
 description: Use when a planned or investigated change needs fresh verification evidence, layered gate proof, review truth, and an honest pass fail blocked verdict before entering cc-act.
 triggers:
   - 验收这个需求
@@ -25,7 +25,7 @@ entry_gate:
   - Re-run fresh commands instead of inheriting cc-do narration.
   - If evidence is stale or missing, reset context and rebuild the verdict from canonical artifacts.
 exit_criteria:
-  - review/report-card.json records pass, fail, or blocked using fresh evidence, review freshness, claim evidence, QA coverage and browser evidence, failure ownership, plus spec alignment and sync readiness.
+  - review/report-card.json records pass, fail, or blocked using fresh evidence, review freshness, claim evidence, QA coverage and browser evidence, human UAT when applicable, named failure ownership, plus spec alignment and sync readiness.
   - Task-level review and requirement-level diff review are separated clearly.
   - 'The next step is unambiguous: cc-act, cc-do, cc-investigate, or cc-plan.'
 reroutes:
@@ -120,6 +120,7 @@ NO PASS WITHOUT FRESH EVIDENCE
    - task-level review proof
    - requirement-level diff review
    - claim evidence matrix
+   - QA feedback loop and behavior evidence
    - QA regression / test-quality proof
    - spec alignment / sync readiness
 4. **Freeze Verdict**
@@ -138,7 +139,7 @@ NO PASS WITHOUT FRESH EVIDENCE
 
 ## Verification Layers
 
-`cc-check` 不是只看“测试是不是绿的”，而是至少看 9 层：
+`cc-check` 不是只看“测试是不是绿的”，而是至少看 10 层：
 
 1. **Runtime Layer**
    - 测试、lint、typecheck、build、脚本 gate
@@ -154,6 +155,7 @@ NO PASS WITHOUT FRESH EVIDENCE
 6. **QA Test Layer**
    - 回归测试是否有 red/green 证据
    - 测试是否验证真实行为，而不是 mock 或 test-only production API
+   - 反馈环是否能稳定复现或证明用户描述的行为
 7. **Review Freshness Layer**
    - review 是否绑定当前 `headSha`
    - 从 review 到当前 HEAD 是否还有新增 commit
@@ -164,6 +166,15 @@ NO PASS WITHOUT FRESH EVIDENCE
 9. **Failure Ownership Layer**
    - 失败是本分支引入、基线已存在、环境阻塞，还是归属不明
    - 归属不明默认不能支撑 `pass`
+10. **Behavior Contract Layer**
+   - expected / actual / reproduction steps 是否用用户和领域语言写清
+   - follow-up 是否是行为契约，而不是易腐烂的文件行号 TODO
+11. **Human UAT Layer**
+   - 人工验收是否 required、skipped with reason、pass、fail 或 blocked
+   - failed UAT 必须 reroute 到 `cc-do`、`cc-investigate` 或 `cc-plan`
+12. **Named Error Layer**
+   - runtime failure 必须有 `errorName`、artifact refs、failure owner 和 rescue action
+   - invalid JSON、stale artifact、missing report 不能变成静默 `blocked`
 
 任何一层失真，都不能写 `pass`。
 
@@ -187,13 +198,27 @@ NO PASS WITHOUT FRESH EVIDENCE
 
 `cc-check` 必须区分“有测试”和“测试证明了正确行为”：
 
-1. 回归测试必须记录 red/green 证据；red 要因为目标行为缺失而失败，不是语法、fixture 或 mock 写错。
-2. 测试应验证真实行为；如果依赖 mock，必须说明 mock 的边界和为什么不会测试 mock 本身。
-3. 生产代码里新增仅测试使用的 API，默认是坏味道，必须 blocking，除非有明确生产生命周期理由。
-4. 复杂 mock setup 超过测试主体时，优先要求 integration / contract test 解释。
+1. 先建立反馈环，再谈修复：failing test、curl / HTTP、CLI fixture、headless browser、trace replay、throwaway harness、bisect / differential loop 都可以，但必须说明速度、确定性、信号锋利度和复现率。
+2. 回归测试必须记录 red/green 证据；red 要因为目标行为缺失而失败，不是语法、fixture 或 mock 写错。
+3. 测试应从公共接口验证真实行为；不准为了方便直接测私有实现。
+4. mock 只允许站在系统边界：外部 API、数据库、时间、随机数、文件系统、网络。mock 自家模块、断言内部调用次数或顺序，默认是 review finding。
+5. 生产代码里新增仅测试使用的 API，默认是坏味道，必须 blocking，除非有明确生产生命周期理由。
+6. 复杂 mock setup 超过测试主体时，优先要求 integration / contract test 解释。
+7. test fixture 必须诚实表达 contract：partial fixture、generated stub、`as` / `any` / 双重 cast、缺字段 mock payload 都要说明真实字段与填充字段；如果这些技巧让测试绕过公共 seam 或隐藏错误输入，默认是 review finding。
+8. 如果没有正确测试 seam，不要硬造脆弱测试；记录 `qa.architectureFollowUps`，说明缺失 seam / hidden coupling / shallow module，并按严重度决定 reroute 或 follow-up。
 
 这些事实写入 `qa.regressionProof` 和 `qa.testQuality`。如果本需求没有行为测试空间，必须记录 `tddException` 或替代验证命令。
 
+## QA Behavior Evidence
+
+用户可见行为、bugfix、regression、工作流、CLI 行为和 API 行为都必须留下行为证据：
+
+1. `qa.feedbackLoop` 记录本轮用什么 loop 证明现实，包含 `status`、`mode`、`commandOrArtifact`、`speed`、`determinism`、`signalSharpness`、`reproductionRate`、`attempts`、`blockedReason`。
+2. `qa.behaviorEvidence` 记录 `userFacingBoundary`、`expectedBehavior`、`actualBehavior`、`reproductionSteps`、`consistency`、`domainLanguage`、`status`。
+3. bugfix 不能只写“代码改了”；必须证明用户描述的原始症状已经被同一条或更可信的反馈环覆盖。
+4. 不能复现时，verdict 默认 `blocked` 或回 `cc-investigate`，并写清尝试过哪些 loop、还缺什么 artifact / 权限 / 输入。
+5. QA issue / follow-up 必须用行为和验收条件表达，不写易失效的文件路径或行号，除非它是当前 review finding 的证据位置。
+
 ## QA Coverage And Browser Evidence
 
 测试不是数量游戏。`cc-check` 必须判断测试覆盖了哪条真实路径：
@@ -265,6 +290,13 @@ NO PASS WITHOUT FRESH EVIDENCE
 4. `environment` 必须记录缺失依赖、权限、服务、密钥或平台约束。
 5. `pass` 不能带未解释的 `in-branch` 或 `ambiguous` 失败。
 
+每条 failure ownership 还必须命名：
+
+- `errorName`：可搜索的错误名，例如 `MissingSpecReviewProof`
+- `artifactRefs`：指向 report、manifest、checkpoint、日志或命令输出
+- `rescueAction`：下一步救援动作，不写空泛“检查一下”
+- `owner`：`branch` / `baseline` / `environment` / `external` / `unknown`
+
 ## Entry Gate
 
 1. 先读 `planning/design.md` 或 `planning/analysis.md`，再读 `planning/tasks.md`、`planning/task-manifest.json`。