跳转到内容
CVSM

状态

CVSM 的流程状态全部放在 GitHub 上：issue、子 issue、依赖、关联分支、PR、检查和关闭状态。仓库里没有计划、进度或笔记文件，会话也不存任何东西，所以哪个会话都可以随时断，下一个会话读一遍就知道进展到哪里。

人在会话里做决定
Agent四个 skill；Claude Code 或 Codex
记录GitHub 和 MLflow，随做随记

01 计划

人
Agent
plan讨论、起草
记录

Issue

  • study #10
  • code #11
  • run #12
  • Decision:

02 实现

人
Agent
implement写代码到 PR
记录

PR

  • Closes #11
  • guard · test
  • Decision:

03 审查

人
Agent
review新会话审查
记录

审查

  • Verdict: pass
  • @ 3f9c2a1

04 合并

人
Agent
merge.py唯一的合并入口
记录

main

  • squash 合并
  • 就是那个 head
  • Decision:

05 运行

人
Agent
run启动、核对
记录

MLflow run

  • cvsm.* cfg.*
  • artifacts
  • Decision:

06 分析

人
Agent
report三行汇报
记录

结果

  • 单个 issue 的表
  • 规格核对
  • 研究总表
  • Decision:

01发布

什么时候
新增或改变已批准的工作：发布计划；改任务的 Goal、Scope、Acceptance 或 Merge，或研究的 Arms、Controlled、Adaptable；改受保护路径。
你说
“发布”，或批准这处改动
记下什么
按波次建好的父 issue 和子 issue，以及父 issue 上的一条 Decision: 评论。

卡点

什么时候
同一个失败连续 3 次；审查连续 3 次给出 changes；目标有歧义且会影响交付物；某个 Controlled 设置不改变对比就满足不了。
你说
最多 3 个选项里的一个，例如“选 2”
记下什么
你不在时：needs-decision 标签和一条四行评论（Blocked:、Evidence:、Options:、Recommend:）；你答复后记一条 Decision:。

02合并

什么时候
PR 待合并：guard 和 test 全绿，当前 head 有 Verdict: pass。任务写了 Merge: agent 时，agent 自己用 merge.py 合并；碰了受保护路径或没审查过的 head，merge.py 会拒绝。
你说
“合并”，或“合并 #15”
记下什么
merge.py --human squash 合并那个 head；任务随之关闭，并记一条 Decision: 评论。

03预算

什么时候
下一步会超出预算：token、时间或 GPU 小时。
你说
“继续”，也可以给个新预算
记下什么
一条写明新预算的 Decision: 评论。

04下结论

什么时候
研究的子 issue 全部关闭，进入待分析。
你说
你的结论，例如“#10 下结论：……”
记下什么
研究带着你的结论关闭，结论记成一条 Decision: 评论。

把鼠标移到关口上，或用 Tab 聚焦

父 issue 和子 issue

Section titled “父 issue 和子 issue”

父 issue 说明为什么做，子 issue 承载具体的活。

  • study：一个研究问题。正文按研究表单写，规格也在里面。
  • plan：开发工作，正文有 ### Goal 和 ### Context。
  • code：一次限定在固定 Scope 内的改动，一个分支、一个 PR。
  • run：一组运行，以一条结果评论收尾。运行任务没有 PR。

另外只有一个 label：needs-decision。父子关系和依赖都是 GitHub 原生字段，建 issue 时设置，从不写进正文：

终端窗口
gh issue create --label run --title "<标题>" --parent 10 --blocked-by 11 --body "..."

例如研究 #10 下有代码任务 #11 和运行任务 #12；#12 的 run 要用合并后的代码，所以 #12 被 #11 挡住。

任务的状态

Section titled “任务的状态”

下面每种状态，GitHub 本来就显示得出来。

状态 在 GitHub 上怎么看
等依赖 被一个还开着的 issue 挡住
就绪 开着，没被挡住，也没有关联分支
进行中 有关联分支
等你决定 label needs-decision，加一条卡点评论
审查中 PR 已打开，检查或审查还没完成
待合并 guard 和 test 全绿，最新的审查结论是针对当前 head 的 Verdict: pass @ <head SHA>
完成 代码任务的 PR 合并后 issue 自动关闭（Closes #N）；运行任务由 agent 贴出结果评论后关闭
放弃 按人的明确指示关成 not planned

父 issue 的状态

Section titled “父 issue 的状态”
状态 在 GitHub 上怎么看
进行中 开着，还有没关的子 issue
待分析 开着，子 issue 全部关闭
结束 按人的明确指示关成 completed（附结论），或 not planned

研究下结论是关口 04。

先读状态

Section titled “先读状态”

每条指令开始时，agent 都先从 GitHub 读状态，从不凭聊天记忆：开着的 study 和 plan issue 及其子 issue 概况、打开的 PR 及其检查、带 needs-decision 的 issue。

认领任务

Section titled “认领任务”

会话用建关联分支的方式认领一个就绪的 issue，然后再查一次，确认没有别的分支同时关联上：

终端窗口
gh issue develop 11 --name t/11-<slug> --base main
gh issue develop --list 11

如果还有别的分支，就删掉自己的，转去做别的。已经在进行中的 issue，只有指令点名或本会话自己认领的才接着做。并行开几个会话之所以安全，靠的就是这一点。

一个任务，一套对应

Section titled “一个任务，一套对应”

一个任务 = 一个 issue = 一个分支 t/<N>-<slug> = 一个 worktree ../worktrees/<N>-<slug>（在主 clone 旁边）= 一个 PR。squash 合并之后，main 上的每条 commit 对应一个 issue。

相关页面

Section titled “相关页面”