# Harness Ceilf6

> 个人需求交付 harness：装载 harness-context 的需求上下文（harness-context 各动作完成后默认自动接续进入本技能），过计划门（轻量复述自动过门 / 实在不明确才转 superpowers 完整规划 / 续入跳过），过门后确保需求 wiki 子文档并把会话改名为需求短题，当前会话直接开发（TDD 红绿纪律），自动驱动评审员（traex gpt-5.6-sol）对抗式 CR 循环（送审→结构化判定→修复→再送审）直至通过或熔断，通过后全量 squash 成单个实质性 commit、变基到 base 远端最新、force-with-lease 推送、经 bytedcli-bits-mr 建 MR、沉淀到需求子文档，收尾汇总不以完成姿态给 MR（待人工 CR → 自测两节点 mark 齐后才产可交付版汇总）；支持无人值守模式（bot 场景由调用方声明）。人工 CR / 测试发现问题后可带全部历史续跑。当用户在装载上下文后要求「开始开发」「跑 harness」「继续 CR 循环」「续跑」时使用。前置：需求分支 + harness-context 已 init。

- Skill: `ceilf6/harness-ceilf6` (Agent Skill, multi-file: 29 files)
- Install (CLI): `npx skillmds@latest add ceilf6/harness-ceilf6`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ceilf6/harness-ceilf6/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ceilf6 (https://skillmd.com/u/ceilf6)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ceilf6/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> 人）」，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…编号）：

```markdown
# Round N 处置

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

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

```markdown
## 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` 齐备后输出**可交付版汇总**；在此之前对本需求不得使用「完成 / 可交付」措辞：

```markdown
## 可交付
- 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 必须显式处置（修复或书面不采纳），禁止静默忽略。