Harness Ceilf6

harness-ceilf6：开发 + 对抗式 CR 循环

权限前提：循环全程不允许权限打断。评审员（traex）侧已在脚本内固化 --dangerously-bypass-approvals-and-sandbox；claude 侧即当前会话——建议以 bypass permissions 模式启动会话跑循环。

开发者是当前会话本身（不 shell 出 claude 子进程）；只有评审员是外部进程。用户全程在场、随时可插话纠偏。

机械层脚本（均在 ~/.claude/skills/harness-ceilf6/scripts/，依赖 git、jq、traex CLI，拉群与发布另需 bytedcli、lark-cli）：cr-round.sh（CR 轮次）、squash-branch.sh（收尾压单提交）、rebase-base.sh（fetch 后把需求分支变基到 base 远端最新；冲突停在现场交会话处置）、rename-session.sh（会话改名）、threads.sh（线程全局登记与唤回、里程碑 mark/progress、续入返工 rework，另经 ~/.local/bin/harness-threads 与短别名 ht 暴露为全局命令）、cr-group.sh（评审群与喊人：group 建群拉人、request 发求CR消息、qa 一键提醒 QA 并知会、wip 返工挂标；这四者的 bytedcli / lark-cli 调用收敛于此，web.py 只转调、不直调外部 CLI）、publish-board.sh（对外看板快照发布）。MR 评论的拉取/水位/回复不在本技能内，走独立 skill mr-comments（~/.claude/skills/mr-comments/scripts/mr-comments.sh，bot 巡检与会话共用，处置纪律见 references/mr-comment-duty.md）。

跨线程总览：harness-threads（短别名 ht）列出本机所有 harness 线程（检出 / 需求分支 / 状态 / 唤回命令，并标注检出分支漂移与会话丢失）。唤回只能由用户的 shell 执行（harness-threads resume <序号|关键词>）——它要起一个新 claude 进程接管终端，会话内的 agent 做不到；在会话里能做的只是列表与给出命令。评审员默认 traex -m gpt-5.6-sol，env CODEX_BIN / CR_MODEL 可覆盖。本地看板：ht web（127.0.0.1:7657，读线程聚合；节点按完成绿/当前黄/未做灰着色，点击可推进或回退——绝对定位走 threads.sh set-node；每线程附唤回命令与复制按钮；写入仍收敛在 threads.sh）。卡片另有四个动作：完成（MR 合入后点按：九节点全点亮 + status=done，本地默认视图收起、对外页照常展示全绿；误点可「撤销完成」回到待合入）、停止（转调 bot 控制端口，停掉在这棵工作树里跑的无人值守任务，现场保留可手工续跑；bot 未运行或该线程无任务在跑时置灰）、归档（从默认视图收起，勾选「显示已完成/已归档」可见，可取消，不删文件）、清理（删整棵工作树与需求分支，两道确认，不可撤销；该线程有任务在跑时置灰，须先停止）。有任务在跑的线程带运行态徽标（运行中 / 等回复 / 后台运行中；徽标按工作树路径匹配，尚无 worktree 的启动中、排队中任务不在看板上现身），数据来自 bot 控制端口，bot 未运行时看板照常渲染静态进度。卡片标题与其下的备注行都可就地编辑（点击进入，回车保存、Esc 取消，备注清空即删除；编辑期间暂停 3 秒轮询，否则整表重建会冲掉输入框）——备注存 meta.note、短题改的是登记表。列表按登记时间正序（先登记的在上），序号因此随线程终身不变。命令行同源：ht archive|unarchive --ctx-dir <路径>、ht clean --ctx-dir <路径>（主检出拒绝清理）、ht note --ctx-dir <路径> [文本]（省略文本即清除）、ht retitle --ctx-dir <路径> <新短题>。收尾段三步（拉群 / 发起CR / 发起QA）由用户在看板上逐个点，自测节点点完只标自测——喊人的时机归用户，发起QA 只在发起CR 之后（越级点提示「请先完成「<当前节点>」」，不执行）。三步都往外喊人，单次调用要几十秒且期间界面没有回执，最容易被当成没点上而重复点，故同一时刻只放行一次，进行中的重复点击直接忽略。拉群（cr-group.sh group）先确保平台代码评审已发起（bits mr code-review start——分支代码评审人由平台按默认规则在此时拉取，不发起则名单只有全局 QA/RD 位、建群只剩本人；已发起幂等放行，被 WIP 挡则摘 WIP 重试一次，「发起CR」步的摘 WIP 由此成幂等复核），名单不设配置，现读 MR 上的 reviewer（bits mr reviewer info）；平台坐标（group_name / project_id）现读 bits mr status（只认 --mr-id）后显式带给 start / reviewer info / chat create / chat add——bytedcli 默认从 cwd 的 .bits/project_config.json 兜底，需求仓没有这个文件、web.py 的工作目录也不定，缺坐标时 start 直接拒绝执行、reviewer info 静默回空数组（看着像「这个 MR 真没评审人」），坐标取不到时告警并照旧不带参数，建 Bits MR 原生群、逐个拉人，把群标识落 meta.cr_chat_id，收尾行报「群已就绪（MR <号>，拉入 人）」，N 是实际拉进群的人数（失败不计）；建群失败（群多半已存在）、拉人失败、名单解析为空都只告警继续，节点照常点亮——返工重来时群不必重建。发起CR（cr-group.sh request）先摘除 MR 的 WIP，再走 Bits 原生的一键提醒 RD（bits mr remind-review——群里那张「邀请大家进行代码审查 @人」的卡片与 reviewer 的待办都由它派发），最后往群里发「大佬们，有空辛苦 CR 一下[送心]」；提醒失败就不发群消息，判据与发起QA 同。发起QA（cr-group.sh qa）先调 Bits 原生的一键提醒 QA（QA 的待办由它派发），再往群里发「辛苦 QA 老师有空测一下[送心]」；提醒失败就不发群消息——只发消息不提醒是半吊子。一键提醒只对 MR 上已有的评审人生效：QA 位为空时接口照样回成功、群里什么都不出现（Bits 页面上「一键提醒 QA」此时也是灰的），故先探一次 bits mr qa-status，空则告警但不阻断。群消息默认以本人用户身份发；本企业管控不放行 im:message.send_as_user 且不可申请，被拒时脚本自动降级——以本人身份把 harness bot（无人值守 bot 的应用，profile 现读 harness-ceilf6-bot/config.json，env HARNESS_LARK_BOT_PROFILE 可覆盖）拉进群，改以 bot 身份补发。发起CR 与发起QA 的判据都严格：提醒或消息没送达就不标完成、节点留黄可重试，不让绿点掩盖没人收到消息。三者阻断都只有两种：线程无 MR（exit 3，web.py 据此回 400）与 ctx 缺 meta.json。返工只需重新喊人：回退到开发再走一遍，走到自测完成时拉群幂等通过，发起CR 与发起QA 各自重新喊一次。WIP 生命周期：MR 在「发起CR」之前恒挂 WIP——收尾建 MR 后立即挂（cr-group.sh wip），返工时重新挂：看板把节点往回点（set-node 判定为回退方向）且线程有 MR 时自动挂（web.py 转调 cr-group.sh wip），会话 / bot 值班任务经续入路径返工时由 threads.sh rework 挂（阶段 0 续入路径，内部转调 cr-group.sh wip）；摘除只在拉群的 code-review start 被 WIP 挡住时与「发起CR」步（都在 cr-group.sh）。「撤销完成」只回落 status、不挂 WIP。已知边界：拉群自动化只覆盖看板操作路径；CLI threads.sh set-node 回退与会话内 mark 不挂 WIP（评论返工走续入路径，已覆盖）。对外展示：publish-board.sh 由 launchd 每 5 分钟把静态快照（所有线程、只读）推到 wangjinghong.com/harness。标题两态——有 MR 显纯文本「MR <号>」（裸编号保留是用户 2026-08-10 对自身脱敏红线的显式豁免；不带链接，内部平台域名不出公开产物）、无 MR 显「线程 #N」加占位小字「MR 尚未创建 · 标题以序号暂代，避免泄露内部信息」。快照按白名单收敛：只含序号、九节点进度、状态、CR 轮数、时间戳、归档标记与 mr_id——需求短题、备注、分支名、启动命令与本机路径（cwd/ctx_dir）全留在本机；运行徽标由发布端把工作树路径配对成线程序号、只发 {idx, state}。完整看板仅限当面演示，不设登录；页脚口径「线程以 MR 号标识，可见性由 MR 平台的内网访问限制管控」。缺 ~/.harness-ceilf6/publish.json（dest / key）即拒绝执行，Mac 休眠即停更（页面标注数据时刻）。

模式

默认交互模式。当调用方在会话开头明确声明「无人值守模式」（如任务大厅 bot 的 bootstrap prompt）时，仅以下四处分叉，其余（含计划门自动过门）两种模式一致：

• 计划门·完整路径：交互模式转 superpowers brainstorming 与用户协商；无人值守模式按调用方约定输出 ask 结果（question 写清缺口与分歧），等用户回复视作计划门协商输入继续，可多轮。
• 僵局熔断：交互模式停下交用户裁决；无人值守模式同样不擅断——按调用方约定输出 ask 结果（question 写清熔断现场与候选项），等用户裁决后继续。
• 开发中关键决策拿不准（多方案取舍缺依据、需求解读分歧大）：交互模式问用户；无人值守模式以 ask 输出等待回复。
• 结果输出：无人值守模式每轮结束按调用方约定输出结果行（如 RESULT 契约），pass/fail/skip 为终态、ask 为等待用户回复的中间态；「未人工CR/未自测」标注写进结果 JSON 的 summary 字段内，不得缀在 JSON 之后或另起一行——契约消费方按行取前缀后整体 JSON.parse，行尾散文会让 pass 被误判为 fail。bot 不能替人完成人工节点，milestones 停在 mr_created；交互模式面向用户汇总。

流程

里程碑与进度图

meta.json.milestones 是节点进度唯一真源：plan_gate → dev_done → cr_passed → mr_created → human_cr_done → selftest_done → cr_group_created(拉群) → cr_requested(发起CR) → qa_requested(发起QA)，值为完成时间戳、缺键即未完成，当前节点 = 第一个缺键节点。端点「完成」不是里程碑键：亮灯条件是 meta.status == done（九键全齐仅是「待合入」）。写入单点是 threads.sh mark，cr_group_created / cr_requested / qa_requested 也走它（由 cr-group.sh 在各自动作成功后调用）；唯一例外是 cr_passed——cr-round.sh 判定通过时内联改写 meta，不经 mark，故 mark 拒收该节点。进度图一律用 bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh progress --ctx-dir "$CTX" 输出并原样转发用户，不手绘。输出时机：过计划门后、进入 CR 循环前、收尾汇总顶部、续入装载后、每次人工节点 mark 后。

前置：装载上下文

1. CTX=$(bash ~/.claude/skills/harness-context/scripts/ctx-dir.sh resolve)。resolve 在主分支/detached 上失败，或 $CTX 缺 meta.json（未初始化）→ 走 harness-context 的 init（其主分支恢复流会从需求源派生分支名、经用户确认后创建并切换，再初始化）；detached HEAD 由用户自行处理。
2. 按 harness-context 的 get 约定读取 $CTX 全部内容装入会话。

阶段 0：计划门（开发不允许直接开始）

出口统一为 $CTX/plan.md（目标 / 范围 / 改法 / 验收标准 四段；可选第五节「运行包络」——声明执行环境的结构性事实以约束 CR 循环的 finding 准入，缺省时评审按默认包络裁决）。三条路径：

1. 续入路径：$CTX/plan.md 已存在 → 跳过门。本轮新增问题以「## 验收增补（<日期>）」小节追加进 plan.md。同时执行返工入口 bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh rework --ctx-dir "$CTX"：里程碑退回「开发」——plan_gate/mr_created 保留（计划门跳过、MR 复用），其余七键整体删除，拉群 / 发起CR / 发起QA 也在内（返工后要重新喊人；这三键若残留，返工走到自测后九键再度齐备、看板直接显示待合入，摘 WIP 与提醒都没有入口），cr_chat_id 不动（群不重建）；有 MR 即挂回 WIP（内部转调 cr-group.sh wip）——续入即返工（评论 / 意见打回、自测发现问题），MR 回到「发起CR」之前的状态；无 MR 时跳过，挂载失败只告警继续（MR 可能已合入），并在收尾汇总如实报。bot 值班任务经此路径修复评论，同样挂上。同时同步 base：bash ~/.claude/skills/harness-ceilf6/scripts/rebase-base.sh --dir "$CTX"——续入通常隔着人工 CR / QA 等待期，base 前进最多；发生变基则阶段 1 第一件事是重跑自检确认上游未破坏现状，冲突按脚本回显指引处置。随后输出进度图。用户明确说「重新规划」才走重规划：旧内容整体降级为「## 历史版本（<日期>归档）」小节保留于文件尾部，新四段写在文件头。
2. 轻量路径（默认，自动过门）：能从上下文复述出可信的目标/范围/改法/验收四段 → 写入 plan.md 并向用户播报（交互场景你在场，随时可打断修正），不等待确认直接过门——用户 2026-07-29 裁定：只有实在不明确的需求才需要人工协商。plan.md 头部加一行「> 计划门自动通过（<日期>）」。
3. 完整路径（实在不明确才走）：复述不出可信四段（缺关键信息或解读分歧大），或用户点名「走 brainstorming」→ 交互模式转 superpowers 的 brainstorming → writing-plans 全流程与用户协商，结束后把最终 plan 内容归一写入 plan.md；无人值守模式按「模式」节输出 ask 等待用户回复。

过门后依次执行（交互与无人值守一致）：

1. bash ~/.claude/skills/harness-context/scripts/ctx-dir.sh set-status developing；
2. 需求短题：从 plan.md 目标提炼 ≤20 字短题；会话名 / wiki 子文档标题 / MR 标题三处同源用它；
3. 会话改名：bash ~/.claude/skills/harness-ceilf6/scripts/rename-session.sh --title '<短题>'（同名自动跳过；非会话环境自动跳过，不阻塞）。bot 无人值守场景 runner 已用 --name 给初始名，这里过门后覆盖为短题；
4. 需求 wiki 子文档：meta.wiki_url 已指向「02-需求」（JhrcwNjUdiUXPMkIUnWcIiOdntc）下的文档（用 lark-cli 的 wiki 节点查询确认其父节点，机械用法见 lark-cli skills read lark-wiki）→ 复用不重建；否则在「02-需求」下新建子文档（space_id 7658115519924686035，--obj-type docx，标题 = 短题），初始内容 = plan 四段 + 来源（bot 场景带 chat/message id），并回写 meta.wiki_url（jq '.wiki_url="<url>"' "$CTX/meta.json" > "$CTX/tmp" && mv "$CTX/tmp" "$CTX/meta.json"）。wiki 操作失败如实报告后继续——文档可收尾时补建，不阻塞开发。
5. Meego 关联：需求材料含 meego 链接 → bash ~/.claude/skills/bytedcli-meego/scripts/meego.sh resolve --ctx-dir "$CTX" --url '<链接>' 落 meta；没有 → … create --ctx-dir "$CTX" --title '<短题>' --description-file <(plan 四段摘要 + 任务来源) 自动创建（事后报告）。随后 … schedule --ctx-dir "$CTX" --start <起> --due <止> --points <估分> 回填排期（按 plan 工作量估算）。输出 {"skipped":true}（仓库未绑定空间）则本步与后续一切 meego 动作静默跳过。resolve 失败停下报告（链接是高确定性来源，不许静默转创建）；create/schedule 失败如实报告后继续——meego 硬门在收尾建 MR 前拦截。首次映射（配置缺项）按 bytedcli-meego SKILL.md 处理，无人值守走 ask。
6. 登记线程：bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh register --ctx-dir "$CTX" --title '<短题>'。登记表 ~/.harness-ceilf6/threads.jsonl 是所有 harness 线程的全局索引，session_id 取自 CLAUDE_CODE_SESSION_ID（取不到则记 null，唤回退化为新会话续入）。必须在会话本身的 cwd 下执行：claude --resume 严格按进程 cwd 判定作用域，登记的 cwd 差一层就恢复不了。续入时重复登记即覆盖（读时 last-wins）。
7. 里程碑：bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh mark --ctx-dir "$CTX" plan_gate，回显进度图转发用户。

阶段 1：开发（TDD 红绿纪律）

当前会话按 plan.md 实现，测试先行：

1. 从 plan.md 的验收标准（含验收增补）派生可测试的行为点；bug 类需求的复现步骤直接写成失败测试——复现即红灯。
2. 先写测试并实际运行确认红：记录命令与关键失败输出，并确认失败原因正是「行为尚未实现/缺陷存在」，不是环境或拼写问题。
3. 实现最小改动让测试转绿，重跑记录通过输出。测试写法遵循仓库自身的测试技能与规范（如 unit-test、storybook 等），本技能只管纪律不管框架。
4. 红绿证据（每个行为点：测试文件、红灯命令+失败摘要、绿灯命令+通过摘要）落 $CTX/tdd-evidence.md，按需求进展追加。
5. 豁免规则：纯文案、样式微调等确无可断言行为的变更可豁免红绿，但豁免理由必须写进 tdd-evidence.md——不可测是性质判断，不是成本判断。
6. MR 范围纪律：本次 MR 只装与 plan.md 目标（即 harness-context 的需求目标）紧密相关的改动。开发或 CR 过程中发现的存量问题（既有 bug、顺手可改的坏味道、范围外重构）一律不掺入——判据是「不改它，本次验收是否受影响」，不受影响即范围外。范围外发现追加记入 $CTX/out-of-scope.md（位置 / 现象 / 一句处置建议），处理路径固定为另开 harness 线程（新需求分支 + harness-context init，可把该条目文本 add 作种子），不在本线程顺手修；是否立刻开线程由用户定。

完成自检（typecheck、全量相关测试）后 bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh mark --ctx-dir "$CTX" dev_done（转发进度图），进入阶段 2。

阶段 2：CR 循环（无轮次上限）

循环体，直到出口条件：

1. 送审前必须 commit：将本轮改动落成迭代式小提交（收尾统一 squash 成单提交）。未提交改动不会被 review 覆盖。
2. 送审：bash ~/.claude/skills/harness-ceilf6/scripts/cr-round.sh --dir "$CTX"。
3. 读 $CTX/cr/round-N/verdict.json：

   • pass=true → 循环结束（脚本已置 status=awaiting_human），进入收尾，顺序固定：

     1. squash：把 commit message 写入临时文件后 bash ~/.claude/skills/harness-ceilf6/scripts/squash-branch.sh --dir "$CTX" --message-file <文件>。message 实质性规则：描述改了什么行为、为什么，从 plan.md 目标 + 实际改动提炼；禁止「处理CR意见」「修复评审问题」「harness 自动开发」这类过程叙事；续入时重写为覆盖全部范围的最终表述。旧状态在 harness-backup/<分支> 引用可回退。
     2. rebase：bash ~/.claude/skills/harness-ceilf6/scripts/rebase-base.sh --dir "$CTX"——fetch 后把分支变基到 base 远端最新（本地跟踪 ref 常年滞后，脚本 fetch 失败即停、不降级），MR 必须基于最新 base 才能干净合入。已在最新上则空转通过。放在 squash 之后：单提交重放，冲突至多解一次。发生变基 → push 前重跑自检（typecheck + 相关测试），挂了回阶段 1 修复后从收尾第 1 步重来；解过冲突 → 冲突解决属未经机审的新改动，记入 $CTX/cr/round-N/fixes.md 并建议补一轮 cr-round 复核（通过后继续收尾，squash 无需重做——变基不新增提交）。冲突由会话解决；无人值守下解法拿不准按「模式」节关键决策分叉走 ask。
     3. push：git push --force-with-lease origin <分支>。force-with-lease 仅限 harness 需求分支——2026-07-30 用户裁定方案 A（MR 恒单 commit），是既有自动 push 豁免（2026-07-29）的延伸。
     4. MR：调用 bytedcli-bits-mr 建 MR——标题 = 需求短题，描述必含：任务来源（bot 场景带 chat/message id）、plan 四段摘要、CR 轮次表、遗留 minor/nit 清单、范围外存量清单（out-of-scope.md 非空时）。Meego 硬门：绑定空间的仓库里 meta 缺 meego_id → 先按阶段 0 第 5 步补 resolve/create，补建仍失败则停在建 MR 之前（交互如实报告 / 无人值守 ask），不降级建非正规 MR。建 MR 用 create-mr-with-meego.js 带 --meego <meta.meego_id>，--meego-type 按 meta.meego_type 映射（story→feature、issue→bug；缺失按分支前缀 feat/fix 兜底）。续入不重复建 MR：当前分支已存在开放 MR 时只在既有 MR 追加一条评论（本轮变更摘要 + 新增 CR 轮次 + 注明历史已重写），MR 链接沿用；既有 MR 若缺 meego 绑定（meego 集成前建的存量 MR），补 meego 后用 bytedcli --json bits mr update --mr-id <meta.mr_id> --meego <meta.meego_url> 原地补绑即可——2026-08-11 实测非正规（optimize）MR 也可绑，应答 meego_bindings[].status=="success" 即校验通过，不必重建 MR；MR 建成或复用既有 MR 后，后续动作顺序固定：① 回写 mr_id（jq '.mr_id="<id>"'，meego.sh comment 的 qa preset 与 cr-group.sh 都依赖它）；② 挂 WIP：bash ~/.claude/skills/harness-ceilf6/scripts/cr-group.sh wip --ctx-dir "$CTX"——MR 从建成到用户点「发起CR」之间恒为 WIP，摘除只发生在 cr-group.sh 的拉群 / 发起CR 步；挂载失败只告警、不回滚 MR，汇总里如实报；③ bash ~/.claude/skills/bytedcli-meego/scripts/meego.sh comment --ctx-dir "$CTX" --message-file <(MR 链接 + 一句变更摘要)，失败如实报告后继续；④ bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh mark --ctx-dir "$CTX" mr_created。挂 WIP 排在 meego 评论之前：评论是外部命令、会失败，挂 WIP 不能排在任何可失败步骤之后。
     5. 自测矩阵：矩阵独立成一篇 wiki 文档，挂在 meta.wiki_url 需求子文档之下。meta.selftest_url 已有 → 复用不重建，按本轮改动面就地更新（分发面变了加行列、涉及判定变了改格子与依据），已填的结果与截图保留；为空 → lark-cli wiki +node-get --node-token '<meta.wiki_url>' --as user --format json 取 .data.node_token 作父节点，lark-cli wiki +node-create --parent-node-token <父 node_token> --obj-type docx --title '<短题> · 自测矩阵' 建子文档并写入正文（机械用法见 lark-cli skills read lark-wiki 与 lark-doc），回写 meta.selftest_url（jq '.selftest_url="<url>"' "$CTX/meta.json" > "$CTX/tmp" && mv "$CTX/tmp" "$CTX/meta.json"），并在需求子文档正文追加一行「自测矩阵：<链接>」——子节点只在 wiki 树里露出，正文这行是给只拿到需求文档链接的人的入口。结构与随附说明必读并遵循 references/selftest-matrix.md——先列分发面（哪些产品线 × 哪些端会加载这份代码，vc-ai 为视频会议/妙记/豆包/文档空间四条线），两级列头（首行 = 产品线分组，次行 = 该线下用户可感知场景），行 = 端/环境；格子状态（待测留白 / 未涉及 / 测后 ✅/❌）、表前填写约定、表后「环境准入与版本确认」均按该文件执行。该文档是阶段 3 自测节点的执行清单。wiki 操作失败如实报告后继续，不阻塞收尾。
     6. 沉淀：harness-context 供料 + lark-sediment 流程——需求结论、CR 往返要点、踩坑追加到 meta.wiki_url 需求子文档（wiki_url 为空则先按阶段 0 第 4 步补建）；同批产出 B 线四问叙事节（lark-sediment「两条沉淀线」）追加到同一篇需求子文档；跨需求通用经验按 lark-sediment 正常去重、分类落位，不塞进需求文档；写 $CTX/sediment.md 台账。沉淀失败如实报告后继续汇总（MR 已建，不因沉淀失败回滚）。无人值守模式沉淀全程不需人工。沉淀完成后 … meego.sh comment --ctx-dir "$CTX" --message-file <(需求 wiki 子文档链接 + 自测矩阵子文档链接)——meego 成为 wiki（需求沉淀与自测矩阵）的入口，失败如实报告不回滚。
     7. 输出收尾汇总（模板见下，首行进度图、次行未自测警示，MR 为过程产物行）。

     失败/熔断/超时不 squash、不 rebase、不 push、不建 MR、不沉淀——半成品不进团队远端视野、不上 wiki。

   • pass=false → 逐条处置每个 finding，四选一：修复；书面不采纳（finding 本身不成立）；接受为已知边界（finding 为真但仅在运行包络外可触发——引用包络说明为何不改代码，追加记入 $CTX/cr/known-limits.md，该处置不计入僵局熔断）；范围外存量（finding 为真但问题在本次改动之前就存在、且修复超出 plan.md 范围——按阶段 1 的 MR 范围纪律记入 $CTX/out-of-scope.md，不在本 MR 修，该处置不计入僵局熔断）。判据是「这个场景在真实流程里会不会发生」，不是「能不能构造出来」；为不会发生的场景修复所付出的复杂度，由之后每个读代码的人偿还。全部 blocker/major 处置完后写 $CTX/cr/round-N/fixes.md（格式见下），回到第 1 步。

4. 僵局熔断（会话判断）：同一条 finding，评审员连续两轮坚持、你连续两轮书面不采纳 → 停止循环；自激熔断：连续两轮 findings 全部落在上一轮修复自身引入的代码上（评审循环在消费自己的输出而非需求缺陷）→ 同样停止循环。两者都执行 bash ~/.claude/skills/harness-context/scripts/ctx-dir.sh set-status awaiting_human，把分歧点整理给用户裁决。
5. 脚本自身失败（两次尝试后）→ 停止并如实报告 stderr，不静默重试第三次。

meta.max_rounds 非 null 时，达到该轮数也停下交用户（默认 null 不限）。每轮结束向用户回显脚本输出的「第 N 轮 / 耗时」信息。

fixes.md 格式（finding 按 verdict.json 数组序号 F1、F2…编号）：

# Round N 处置

## F1 <severity> <file>:<line>
- 处置：修复 | 不采纳 | 接受为已知边界 | 范围外存量
- 说明：修复→改了什么、在哪个提交；不采纳→理由与依据；已知边界→引用包络 + known-limits 记录位置；范围外存量→为何属存量 + out-of-scope.md 记录位置

收尾汇总模板（pass 或熔断后输出给用户；首行进度图取 threads.sh progress 实际输出）：

## CR 循环收尾
<进度图>
⚠️ MR 已建，但人工 CR、自测未完成——请勿把 MR 链接作为完成交付外发（失败/熔断时本行改写：未建 MR，无可外发物）
- 结果：机审通过（第 N 轮），人工 CR 与自测未开始 ｜ 熔断待裁决
- MR（已建、已挂 WIP，待人工 CR → 自测；WIP 在看板点「发起CR」时摘除）：<链接>（失败/熔断时写「未创建」；挂 WIP 失败时注明）
- wiki 沉淀：<需求子文档链接>（失败/熔断时写「未沉淀」）
- 自测矩阵：<矩阵子文档链接>（自测按此逐格执行；失败/熔断时写「未建」）
- 改动概览：<一段话>
- 轮次记录：cr/round-1..N（verdict / fixes 齐全）
- 遗留 minor/nit：<清单，含文件位置>（修不修由你定）
- 范围外存量：<out-of-scope.md 条目摘要>（不进本 MR，另开 harness 线程处理；无则省略本行）
- 下一步（两步闭环）：① 人工 CR ② 自测（打开自测矩阵子文档逐格验证、填结果贴截图）。每完成一步就确认——会话里说「人工 CR 完成 / 自测完成」，或 `ht mark <序号> human-cr|selftest`，或 web 看板按钮。两步齐后输出「可交付版汇总」，那才是可外发版本。发现问题用 harness-context add 存入后喊我续跑

阶段 3：人工节点与可交付

收尾后进入人工区间，两节点顺序：人工 CR → 自测（依据 meta.selftest_url 指向的自测矩阵子文档逐格执行；该字段为空时先按收尾第 5 步补建）。自测完成后由用户在看板上逐个点拉群、发起CR、发起QA（等价命令 bash ~/.claude/skills/harness-ceilf6/scripts/cr-group.sh group --ctx-dir "$CTX"、… request --ctx-dir "$CTX"、… qa --ctx-dir "$CTX"）——三步都往外喊人，时机归用户，会话不代点、不代跑，除非用户明确要求；MR 合入后在看板点「完成」收束。用户在会话说「人工 CR 完成」「自测完成」→ bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh mark --ctx-dir "$CTX" <human_cr_done|selftest_done> 并转发进度图。另两条渠道（ht mark、web 看板）与此同一写入口、可能发生在会话外——收到用户后续消息时先 progress 一次核对现状再回应。

MR 评论处置：MR 存续期间用户说「看看 / 处理 MR 评论」时，当前会话经 skill mr-comments（fetch --ctx-dir "$CTX"）拉 MR 全部评论（Codebase 讨论线程 + Review 附言；BITS 详情页展示的是同一份）并按作者三分：机器人评论（kind=bot，如 Bits CodeGuard）在本会话按 references/mr-comment-duty.md 处置——评判三分法、需修复走续入返工、回复一律经 mr-comments.sh reply（强制【bot】前缀）、人工里程碑不代 mark、处置完 mark 推进水位；人工评论（kind=human）不评判、不回复，列给用户本人处理（reply 对人工参与的线程机械拒绝）。bot 的 mrwatch 轮询出厂关闭（harness-ceilf6-bot/config.json 的 mrWatch.enabled），打开后同一套纪律以无人值守值班任务跑、水位同源。熔断后人工确认再 bash ~/.claude/skills/mr-comments/scripts/mr-comments.sh enable --ctx-dir "$CTX" 复位。

Meego 收尾：发起QA 成功后看板自动串 meego.sh comment --preset qa 提测知会（CLI 路径由会话补调）；MR 合入后看板点「完成」自动串 meego.sh done——唯一的 meego 流转时刻（advance 按映射 confirm 本端节点 + 收束评论），CLI / 会话 set-node done 时由会话补调（自动化只覆盖看板路径，同拉群边界）。两处 meego 失败都只在看板弹 warning，不改变节点写入结果——看板进度与 meego 状态是两笔账，后者人工补。撤销完成不回滚 meego（看板无条件提醒一句），节点已流转时人工处理。

human_cr_done 与 selftest_done 齐备后输出可交付版汇总；在此之前对本需求不得使用「完成 / 可交付」措辞：

## 可交付
- MR：<链接>
- 改动：<一句话>
- 已完成：机审 CR（N 轮）+ 人工 CR + 自测

发现问题 → 用户经 harness-context add 存入（或直接口述）→ 再次调用本技能：走续入路径（plan.md 增补验收条目 + 重置里程碑），回到阶段 1 修复、阶段 2 再循环。MR 合入后在看板点「完成」（等价 bash ~/.claude/skills/harness-ceilf6/scripts/threads.sh set-node --ctx-dir "$CTX" done）收束。

约束

• 收尾自动 squash + 变基到 base 远端最新 + force-with-lease push + 建 MR + 沉淀是本技能职责（squash/force-with-lease：用户 2026-07-30 裁定方案 A；自动 push：2026-07-29 裁定；rebase：2026-08-11 裁定，方案 A 恒单 commit 的延伸——变基后必然 force push，沿用既有豁免；均仅限 harness 需求分支）。Meego 经 bytedcli-meego 技能收敛管理（关联/创建于计划门、评论于关键时刻、流转仅在 done——挂点见流程各步）；不打 SCM 包（workflow-bugfix / scm 技能另行处理）。
• 文档行文：本技能产出的一切给人看的文本都受此约束——需求 wiki 子文档（plan 四段、沉淀正文、B 线叙事节）、自测矩阵子文档（矩阵说明与准入段）、MR 描述、收尾汇总与可交付版汇总。只管行文，字段名、清单、表格、代码块与 URL 属结构、不受管。散文型行文（沉淀正文、B 线叙事节、MR 的改动说明、汇总里的改动概览）动笔前先加载 human-writing skill。技术型行文（plan 四段、矩阵说明、fixes.md、commit message）不套其散文形态，但四条硬约束始终生效：材料关（列不出具体材料就写短，不换四种说法灌字数）、禁翻案腔、禁名词化与黑话、禁洞察路标。自查脚本与判读口径见 lark-sediment 第 2 步，两处同一口径。
• 不修改 cr/round-*/ 下的历史产物；每轮产物只写本轮目录。
• 对 verdict 的每条 blocker/major 必须显式处置（修复或书面不采纳），禁止静默忽略。