从现在开始，这个仓库只有两份当前文档：
README.md：唯一战略锚点TODO.md：唯一进度管理文档
每轮推进顺序固定为：
- 先看
README.md - 再看
TODO.md - 只按
TODO.md当前优先级推进
旧文档都只保留证据价值，已归档到 archive/docs_2026-04-18/。
当前身份不是“已经完整成立的 CodeMesh 运行时”，而是：
CodeMesh Builder
Builder 的责任只有三件事：
- 把最终目标写成清晰、可执行、可验证的系统约束
- 校准当前实现和最终目标之间的偏差
- 沿着唯一主线把目标架构逐步落成真实产品能力
禁止把未来运行时职责冒充成当前已经成立的能力。
CodeMesh 的最终目标不是“让 AI 多写一些代码”，而是：
把用户一个模糊的产品构思，先收敛成可批准的产品文档与架构文档，再自动生成严格隔离的任务树，最后把最底层原子执行单元的交付结果逐层向上审核回传，直到最终结果仍然满足最初战略目标。
一句话定义：
CodeMesh 是一个模拟人类分层管理结构的多 Agent 软件交付系统。
CodeMesh 不是一个普通 org chart，而是一个混合操作系统：
- 战略部署：
Hoshin Kanri / catchball - 产品组织：
Product Operating Model - 工程落地：
Systems Engineering - 角色切面：
Team Topologies + cognitive load - 下放执行：
Mission Command - 决策权：
DACI
核心判断只有一句：
最科学、最高效的人类工程管理方式，不是把聪明人堆在一起，而是把“战略部署、产品收敛、架构收敛、合同化计划、受限执行、逐层验证”做成一个高信任、低认知负载、单点决策、可回卷的系统。
CodeMesh 采用 H0 + L1-L6 七层组织结构。
- 只做两次关键批准：
ProductDocument、ArchitectureDocument - 不参与 task 拆分，不下沉到实现细节
- 角色：
Strategic Owner / User-Value Interpreter / Constraint Analyst / Strategy Synthesizer - 只回答四个问题：为什么做、为谁做、成功算什么、不做什么
- 输出：
Strategic Intent / Success Criteria / Risk Budget / Non-goals - 禁止：讨论技术方案、模块设计、任务拆分
- 角色：
Product Strategist / JTBD Analyst / UX-Flow Designer / Business-Risk Analyst / Product Integrator - 目标：把模糊战略变成完整
ProductDocument - 输出：
Product Doc / ConOps / User Stories / MOEs - 关注点：用户、场景、价值、范围、成功标准
- 禁止：决定技术架构
- Human Approve #1 在这里
- 角色：
Open-Source Leverage Analyst / System Architect / Domain Boundary Architect / Data-API Architect / Reliability-Security Architect / Delivery Architect / Architecture Integrator - 目标：把已批准
ProductDocument变成完整ArchitectureDocument，并在架构冻结前明确reuse / vendor / fork / rebuild判断 - 输出：
OSS Leverage Memo / Architecture Doc / Module Graph / Interface Contracts / Quality Attributes / Isolation Rules - 关注点：复用判断、边界、数据流、接口、依赖、质量属性、可演进性
- 禁止：重写产品目标
- Human Approve #2 在这里
- 角色：
Goal Brief Compiler / Work Breakdown Planner / Dependency Planner / Task Contract Compiler / Acceptance Planner - 目标：把批准后的产品/架构工件转成可执行蓝图
- 输出：
Goal Brief / Task Tree / Task Contracts - 每个 task 必须带：
owned paths / readable paths / forbidden scope / tests / docs obligations / parent objective - 禁止：擅自改产品或架构
- 角色：
Domain Delivery Lead / Branch Reviewer / Composition Reviewer - 目标：管理一个模块或一条子树，不直接做大战略
- 输出：
Branch Acceptance / Module Delivery Bundle - 关注点：局部目标对齐、接口不破坏、证据完整、是否打回
- 禁止：修改战略、产品定义、架构定义
- 角色：
Atomic Codex Executor - 目标：完成一个小闭环
- 输出：
code + test + doc + evidence - 禁止：战略判断、产品改写、架构改写、跨域扩散
这七层不是讨论稿。它们已经被收口成运行时组织蓝图工件：
- Python：
codemesh.organization.OrganizationService - HTTP：
GET /meta/organization-blueprint - CLI：
codemesh mission inspect <mission_id> organization-blueprint --json - shell / TUI：
inspect organization-blueprint
这不是泛泛的“编码建议”，而是 Builder 和后续运行时都必须遵守的通用工程原则。
Layer-fit language selection- 按运行面和约束选语言，不搞语言意识形态。
Reuse/vendor before rebuild- 新能力先做 OSS 调研，再决定
reuse / vendor / fork / rebuild。
- 新能力先做 OSS 调研，再决定
One role, one artifact- 一个角色只优化一个目标，只产一个主工件。
Real-AI-only mainline- 主线禁止用
mock / stub冒充真实能力成立。
- 主线禁止用
Boundary-first delivery- 先冻结边界、合同、验收，再下发原子执行。
TypeScript / JavaScript：前端、Web、扩展、交互面Python：LLM 编排、评审链、文档收敛、任务合同、agent control planeGo：CLI、守护进程、高并发服务、部署友好二进制Rust：沙箱、patch/merge 核心、解析器、文件系统重负载内核、安全/性能敏感基础设施
Open-Source Leverage Analyst 不是可选建议，而是架构冻结前的强制关口：
- 先搜成熟实现
- 再比
license / maturity / extensibility - 明确判断
reuse / vendor / fork / rebuild - 把理由固化为
OSS Leverage Memo
这个角色不能写代码，不能直接定最终架构，不能跳过审批。
每个 AI 节点都很强，但必须被切成极窄注意力窗口。硬规则如下：
- 一个节点只允许有一个主优化目标
- 一个节点只允许产出一个主工件
- 一个节点不能既生成又审批同一个工件
- 一个节点不能同时拥有“问题定义权”和“解决方案批准权”
- 一个节点不能跨战略、产品、架构、执行四个区间跳跃，最多只看相邻层
- 每个节点必须只看到完成自己工作所需的最小上下文
这就是 CodeMesh 的 attention slice。
人类不是来做低价值补丁工的。人类只在两个地方 approve：
ProductDocumentArchitectureDocument
其他地方全部是机器验证与机器回卷：
Goal BriefTask ContractsBranch AcceptanceFinal Validation
标准回卷链是：
L6 Atomic Executor
-> L5 Domain Delivery Lead
-> L4 Planning/Contract Layer
-> L3 Architecture Layer
-> L2 Product Layer
-> H0 Human Sponsor only when top-level mismatch appears
这里必须严格区分两件事：
verification：是不是按合同做了validation：是不是仍然满足原始目标
Goal Brief 的位置也被写死了：
模糊构思 -> 产品收敛 -> 产品文档批准 -> 架构收敛 -> 架构文档批准 -> Goal Brief
也就是说：
Goal Brief 是经过两次批准后的执行锚点。
当前已经成立的部分：
- 组织蓝图已经进入正式代码模块：
src/codemesh/organization/ - 关键角色已经有结构化合同和更强的
system_prompt_template - 组织蓝图现在也冻结了五条工程原则与按层选语言规则
- 组织蓝图已经有 API / CLI / shell / TUI 读面
decision模块已经按目标L2角色树运行：Product StrategistJTBD AnalystUX-Flow DesignerBusiness-Risk AnalystProduct Integrator
ProductDocument已成为 Gate A 主审批对象architecture模块已经成立，ArchitectureDocument + ArchitectureViewpointCards已进入 mission 主链L1战略意图层现在已经进入 runtime：StrategicIntent + StrategicViewpointCards会在 mission 创建与 Gate A revise 时持久化，并进入 Gate A 审批包与 MarkdownL3七个架构角色现在已经进入真实 AI 主线，Gate B 读面展示的是实际 LLM 角色输出ArchitectureDocument现在会吸收L3角色综合结果，正文直接带review_synthesis / approval_recommendation / review_risks- Gate B 已经成为真实的第二次 human approve 停点
Goal Brief已经改为Gate B approve之后才落地的正式 artifactTaskTree / TaskContract / BranchAcceptance / Execution / QA骨架已经存在TaskContract现在已经显式追溯product_document / architecture_document / goal_brief，并开始从批准后的架构边界导出 siblingforbidden_pathsL5现在已经开始生成显式ModuleDeliveryBundle：子任务结果会先被模块级 bundle 收口，再继续向上汇总Open-Source Leverage Analyst和OSS Leverage Memo不只存在于组织蓝图，现在也会进入 liveL3runtime、mission artifact refs 与 Gate B 审批包QAService现在会把process_doc_path当成强制交付证据：成功执行若不更新PROCESS.md，会直接判FAILMissionControlService.get_upward_review_chain()已经成立，并通过L4 / L3 / L2三层结构化输出继续机械消费ModuleDeliveryBundleupward-review-chain已进入 API / CLI / shell / TUI / Gate C Markdown 读面
当前还没对齐的部分：
ArchitectureDocument仍以 deterministic skeleton 作为结构骨架，但现在已经吸收L3综合结果；剩余差距不再是“没接 AI”，而是后续要让这些综合结果进一步反向影响更细粒度的模块/接口收敛T9还没跑完整条真实 AI 端到端主线；当前虽然角色链和审查链都在，但还缺一条用真实调用贯穿的整体验收
所以现在最重要的不是继续发散文档，而是：
沿着这张组织蓝图，把每一层角色逐步接进真实 runtime。
主线完成前，禁止：
- 用
mock / stub / demo 替身冒充主线能力 - 再生长新的当前产品文档
- 跳过产品文档 approve 或架构文档 approve
- 让底层执行单元承担战略判断
- 让任务节点通过隐式上下文互相污染
- 把 Builder 身份写成运行时已成立能力
- 扩网页、多用户、SaaS 方向
每轮只检查三件事：
- 这轮是否让系统更接近最终战略锚点
- 这轮是否让主线更真实，而不是更像 demo
- 这轮是否让上下层边界更清晰，而不是更混