orgOSv8 Build Principles
本文档记录 orgOSv8 在正式实现前确定的硬约束。后续架构、拆卡、实现、验收,默认都以这些原则为准。
1. Cloudflare-only
orgOSv8 只使用云服务,并且系统组件只使用 Cloudflare 提供的能力。
这意味着:
- 不引入自建服务器作为正式系统组件
- 不依赖本地常驻进程作为运行前提
- 不以 VM / VPS / 自托管容器作为核心架构基础
- 优先使用 Cloudflare 官方提供的 agent / serverless / state / workflow 相关能力
当前首要参考目录:
/home/patrix/orgOSv8/ref/cloudflare-docs/src/content/docs/agents
设计含义:
- 先问“Cloudflare 原生能力能不能解决”
- 如果能,就不要额外造一层平替基础设施
- 系统形态必须从一开始就符合云原生、可唤醒、可恢复、无单机依赖的约束
2. Do not reinvent the wheel
orgOSv8 绝不重新发明轮子。
遇到问题时,参考优先级固定为:
/home/patrix/orgOSv8/ref/hermes-agent
/home/patrix/orgOSv8/ref/claw-code
- Cloudflare 官方 agents 文档与示例
执行要求:
- 先看现成做法,再决定是否需要自己设计
- 能复用概念、模式、目录契约、状态模型、harness 机制的,就优先复用
- 只有在现有方案明显不适配 orgOSv8 目标时,才允许新增自定义设计
注意:
- “不重新发明轮子”不等于机械照抄
- 允许做针对 orgOSv8 的收敛、删减、组合与改写
- 但默认立场应是 复用优先,原创靠后
3. Dogfooding as the default test case
orgOSv8 每次迭代的测试用例,都使用同一个核心问题:
如何使用新构建的 agent 开发当前项目?
这意味着:
- 每一轮新增能力,都要回到“能不能反过来用于开发 orgOSv8 自己”来验证
- 测试不只看单点 API 是否返回成功
- 更看这个 agent 是否真的能进入项目开发闭环
典型测试方向:
- 能否理解当前项目目标与目录结构
- 能否基于现有文档继续推进任务
- 能否在中断后恢复开发现场
- 能否在模型切换后继续做同一项工作
- 能否在能力下降时自动转入更保守的开发策略
设计含义:
- test case 不是抽象 benchmark,而是项目内生 dogfooding
- orgOSv8 的每一轮能力,都要经受“是否能反过来建设 orgOSv8”这一关
4. Kanban-first and delegate-only coding workflow
orgOSv8 的所有编码工作都必须遵守以下流程:
- 先写看板文件
- 按顺序编号
- 在当前 Discord channel 里委派给小 c 实现
- 绝不由我直接修改代码
这意味着:
- 任何正式编码前,必须先有对应的 kanban card
- 卡片编号需要保持顺序递增
- 实现动作必须在本频道通过 mention 发起
- @ 的格式使用:
<@userid>
- 小 c 的 user id 是:
1484770321612542013
- 同时优先带上角色:
<@&1484803944394915863>
默认执行方式:
- 我负责先定义 milestone,再拆卡、定义约束、整理验收标准、做 review、做纪要
- 小 c 负责具体编码实现
- 我不直接改业务代码,除非 Pat 后续明确单独改这条规则
4.0 Milestone-first
从现在起,orgOSv8 后续推进必须遵守:
- 先建 milestone
- 再在 milestone 下面开卡
目的:
- 先收拢阶段目标,避免卡片一张张往前推时逐步走偏
- 让后续 3~5 张卡共享同一条主线与边界
- 每张卡都能明确知道自己在 milestone 里的位置
执行要求:
- milestone 必须先落盘到
docs/milestones/
- milestone 需要明确:阶段目标、边界、建议卡片序列、验收焦点
- 后续卡片应默认显式挂到当前 milestone 下推进
4.1 最近五张卡的流程加速规则
Pat 已追加指示:最近五张卡 在小 c 回报完成后,我可以继续往下推进,不用等待小 q 先完成复核。
适用范围:
- 第一轮:Card 04 ~ Card 08
- 第二轮:Card 10 ~ Card 14
- 第三轮:Card 15 ~ Card 19
执行方式:
- 小 c 回报完成后,我可直接进入下一步(继续开下一张、部署、推进主线)
- 小 q 仍可继续做复核,但不再作为这些加速卡的推进阻塞条件
注意:
- 这是近期加速规则,不等于永久取消复核
- 若 Pat 后续撤回或改口,以最新指示为准
5. 对现有文档的约束影响
因此,后续文档和实现需要统一遵守:
- M0/M1 设计不得引入非 Cloudflare 核心系统组件
- 拆卡前应优先阅读 hermes-agent 与 claw-code 相应实现
- 每张卡都应明确自己的 dogfooding 测试方式
- 每次实现前都必须先落 kanban card,再在频道中委派给小 c
- 不允许跳过卡片直接自己改代码
6. 立即生效的执行规则
从本文件落盘起:
- 架构设计优先 Cloudflare 原生能力
- 参考优先级固定为 hermes-agent > claw-code > 其他
- 测试问题默认写成:
如何使用新构建的 agent 开发当前项目
- 所有编码工作先写顺序编号的 kanban 文件
- 然后在本频道 @
<@1484770321612542013>,并优先同时带 <@&1484803944394915863>
- 我自己不直接下手改业务代码
7. Code hygiene 守则
后续 coding agent 在实现卡片时,默认还必须遵守 docs/CODE-HYGIENE.md。
这份守则来自 M8.9 代码清理返工后的经验,重点约束:
- 拆分模块时同步清 dead import、漂移注释和 code map。
npm run typecheck / npm run build:web / git diff --check 是默认自检。
- pure helper 优先补 first-party unit test,不把所有风险都推给生产 smoke。
- 一张卡只提交相关文件,不用
git add -A 混入无关 meeting/docs/ref。
- 类型逃逸、console log、一次性脚本、route/DO 边界都必须有明确理由和验收证据。