Code-role v0.4.0: Less Process, Stronger Outcomes
Code-role v0.4.0:更少流程,更强交付
Code-role v0.4.0 refactors both the four-workstation Minimal Profile and eight-role Full Profile around one rule:
A role is complete only when it produces the evidence required to change an accepted outcome KR from
0to1.
Code-role v0.4.0 用同一条规则重构了四工位最小版和八角色完整版:
只有当角色产出的证据足以把一个已确认的结果型 KR 从
0变成1,这个角色的任务才算完成。
What Changed / 核心变化
-
Outcome KRs only. Research, PRDs, architecture, code activity, tests written, reports, and reviews are methods or evidence, not delivery outcomes.
-
One failed evidence item per assignment. Roles no longer receive broad agendas or entire
KR=0backlogs. -
Immediate role execution. A complete assignment starts work; startup acknowledgements and readiness-only turns are removed.
-
One primary professional artifact. Annexes, manifests, and packet locks are optional audit support rather than daily routing gates.
-
Independent acceptance. Engineering produces candidate evidence but cannot approve its own delivery.
-
Two evaluation facts. Evaluators separately report
evaluation_executedandkr_observed_pass. -
Compact control state. Project Manager state records the current accepted objective, failed evidence, owner, and decision instead of process chronology.
-
KR 只描述结果。 调研、PRD、架构、代码活动、写测试、报告和评审都只是方法或证据,不是交付结果。
-
一次只处理一个失败证据。 角色不再接收宽泛议程或整组
KR=0待办。 -
任务书即启动。 完整任务书到达后直接工作,不再进行启动确认和 readiness-only 回合。
-
一份主专业产物。 附件、manifest 和 packet lock 降为可选审计支持,不再充当日常路由门槛。
-
独立验收。 工程可以生成候选证据,但不能批准自己的交付。
-
两个评估事实。 评估师分别报告
evaluation_executed与kr_observed_pass。 -
紧凑控制状态。 项目经理只记录当前目标、失败证据、责任人和决策,不记录流程流水账。
Why It Matters / 为什么重要
The previous workflow could be strict and still fail in practice: roles spent too much time satisfying workflow mechanics, while the actual software outcome remained unchanged. v0.4.0 preserves the hard acceptance boundary and removes work that does not change milestone evidence.
之前的流程即使严格,也可能在实践中失败:角色花费大量时间满足流程动作,真实软件结果却没有变化。v0.4.0 保留严格验收边界,同时删除不能改变里程碑证据的工作。
The design was calibrated against two real private projects:
- DeepBrain: strong partial benchmark and runtime evidence remained insufficient for a production claim.
- Leaper Agent: a professional evaluation plan was rejected because its task artifacts, holdout isolation, grader mechanism, and runtime conditions were not executable.
这套设计来自两个真实私有项目的校准:
- DeepBrain: 大量局部 benchmark 与 runtime 证据仍不足以支持生产结论。
- Leaper Agent: 一份专业评估方案因为任务数据、holdout 隔离、grader 机制和运行条件不可执行而被打回。
Start in 60 Seconds / 60 秒启动
git clone https://github.com/Deepleaper/Code-role.git
cd Code-role
python3 scripts/init_loop_workflow.py "/absolute/path/to/your-project" \
--project-name "Your Project"
python3 scripts/init_loop_workflow.py "/absolute/path/to/your-project" --checkThen define one Objective, binary outcome KRs, and the exact failed evidence item the next role owns.
然后定义一个 Objective、可二值验收的结果型 KR,以及下一个角色负责解决的唯一失败证据。
Verified / 已验证
- Repository test suite:
83 passed. - Minimal Profile initializer replay and
--check: passed. - Full Profile initializer replay: passed.
- Manifest JSON validation and HTML parsing: passed.
Read more: