技术概览
CARVES.AI 是 AI 编程的项目调度台。 你继续让 Codex、Claude Code、Cursor、Gemini CLI 这些智能体（Agent）写代码；CARVES 负责把目标、计划、任务、证据、审核和项目记忆调度起来，让 AI 编程从一段段对话，变成可推进、可检查、可接手的项目工作流。
这里保留面向用户的公开机制：6 个机制组，每个机制组可以继续下钻到对应的技术文档。
解决什么问题
AI 写得很快，但项目会漂。 AI Agent 可以很快产出代码，但长项目容易失控：目标留在聊天里，计划中途变化，结果说完成却没有证据，下一次接手只能靠猜。
目标从聊天里拿出来。 结果先带证据回来。 下一次会话能接得上。 亮点
不换 Agent，只补控制层。 CARVES 不替代 Codex、Claude Code、Cursor 或 Gemini CLI。它像本地项目调度台，让目标、计划、任务、证据、审核和交接都留在你能看到的位置。
Agent 负责写。 CARVES 负责调度。 人负责接受、拒绝或重排。 关键技术说明
不是只靠 prompt，而是靠本地记录和检查。 Card / TaskGraph 管项目推进，CodeGraph / Context Pack 管项目理解，Execution Packet / Guard 管执行边界，Evidence / Review / Handoff / Audit / Shield / Matrix 管可检查结果。
本地优先的项目记录。 有边界的执行包。 仅摘要的证明和自检链路。 项目调度
Card / 计划草案 / TaskGraph 下层机制
Card 它把用户想法变成可讨论、可批准、可拆任务、可验收的目标。 计划草案 智能体可以提出路径，但提议不会自动变成可执行 truth。 TaskGraph 它记录任务、依赖、状态、证据、审核结果、阻塞、返工和下一步。
把一句请求变成目标、计划草案 和可追踪任务。
用户仍然可以和智能体（Agent）聊需求，但 CARVES 不让项目目标只停在聊天里。请求先变成 Card ，Card 再进入计划草案 ，批准后的工作进入 TaskGraph 。
稳定点在于分离：建议不是执行授权，执行结果也不会自动变成已接受。
为什么可检查
先捕获目标，再拆任务。 计划先是草案，批准后才执行。 任务带边界、依赖、状态、证据引用和验收条件。 完整机制说明
大白话功能说明 CARVES.AI 的项目调度 ，就是把一句“让 AI 帮我做这个项目”，拆成可讨论、可批准、可执行、可检查的项目推进流程。
你可以继续跟 Agent 聊需求，但 CARVES 不让这些需求只停留在聊天里。它会把目标整理成 Card ，把 Card 拆成 Plan 和 Task，再让任务按边界、依赖和审核状态推进。
简单说：
不是让 AI 想到哪做到哪，而是让 AI 的工作进入一个项目调度 流程。
它解决什么问题 Vibe coding 最大的问题不是 AI 不会写代码，而是项目一大就容易乱：
项目调度 解决的是：把 AI 的自由发挥，变成可控推进。
Agent 直接开写，目标还没定清楚。 聊天里说过的计划，下一轮就忘了。 多个任务混在一起，做完一个又污染另一个。 不知道当前项目到底做到哪一步。 AI 说完成了，但没有明确验收条件。 亮点 最核心亮点是：计划先进入调度，不直接进入执行。
CARVES 可以允许 Agent 提建议，但不会把建议直接当成已批准任务。人类仍然是调度者，决定目标是否成立、任务是否可以执行、结果是否可以接受。
对用户来说，它的价值是：
目标不会丢在聊天记录里。 任务不会凭感觉乱跑。 每个任务都有边界和验收条件。 项目状态可以被读回。 人类可以在关键节点 approve、reject、replan。 关键技术说明 项目调度 主要由三个机制组成：
关键点是：草案和正式 truth 分开。
AI 可以生成建议，但建议默认只是 SUGGESTED 或 draft。只有经过批准，才会进入可执行任务线。这样可以避免 Agent 自己提出任务、自己批准任务、自己执行任务，最后还自己宣布完成。
技术上，CARVES 会把这些状态保存成结构化项目 truth，而不是只存在聊天上下文里。Markdown 可以作为阅读视图，但真正的任务和状态应以机器可读的结构为准。
Card ：目标卡。用于承载一个用户认可的目标或项目切片。Planning draft：计划草案 。用于让 AI 先提出拆解方案，但不直接授权执行。 TaskGraph ：任务图。用于记录任务、依赖、状态、范围和验收要求。 边界 这里不能夸大成“CARVES 会自动规划好整个项目”。
更准确的说法是：
CARVES 提供项目调度 结构，让人类和 Agent 可以围绕目标、计划、任务和验收条件稳定推进。它不会替用户自动决定产品方向，也不会保证 AI 的计划一定正确。
持续理解
CodeGraph / 项目意图 / 上下文包 下层机制
CodeGraph 它记录模块、文件、函数、依赖、摘要和任务相关范围。 项目意图 它记录项目解决什么问题，以及当前方向应该是什么。 上下文包 它把任务、代码结构、历史、约束和证据组合成有边界的上下文包 。
先建立项目结构和方向，再给智能体有边界的上下文。
持续理解 让智能体通过 CodeGraph 、项目意图 、TaskGraph 状态、记忆、证据和审核结果来理解当前任务。
重点不是读更多，而是读取当前任务真正相关的项目事实。
为什么可检查
代码结构来自本地索引，而不是猜。 项目意图 可被人类确认。上下文包 按任务组装，而不是把整个项目塞进 prompt。 完整机制说明
大白话功能说明 持续理解 是 CARVES 让 AI 不断保持项目上下文稳定的机制。
CARVES 不要求 AI 一次性读懂整个项目，而是让它每次都从项目结构、项目意图 、任务推进、历史证据里拿到当前真正相关的上下文。
它解决的是：AI 不只是“聪明”，还要“知道这个项目现在是什么情况”。
它解决什么问题 普通 vibe coding 经常会遇到：
持续理解 解决的是：
让 AI 每次进入任务时，都能拿到项目当前状态，而不是靠聊天记忆或一次性读完整个仓库。
Agent 第一次看项目，靠猜。 聊久了之后，前面的背景丢失。 项目变大后，每次都要重新解释。 AI 会把旧结论当成当前事实。 项目结构改了，但 AI 还按旧理解继续做。 用户明明讲过边界，但换线程后又要重讲。 持续理解负责什么 持续理解 负责把项目上下文分成几层：
它不是让 AI 读更多，而是让 AI 读得更准。
CodeGraph ：项目代码现在长什么样。Project intent：这个项目要解决什么问题。 Memory / context pack：当前任务需要哪些历史、约束和背景。TaskGraph：项目推进到哪里。 Evidence / Review：哪些结果已经被证明或拒绝。 亮点 持续理解 的亮点是：上下文不是聊天残影，而是从项目事实里重新组装出来的。
这对大项目很重要。因为对话上下文会断、会污染、会遗漏，但项目事实可以被重新读取。
CARVES 的思路不是：
把整个项目都塞给 AI。
而是：
根据当前任务，把项目结构、推进状态、相关记忆和证据组合成有边界的上下文。
这样 AI 不需要每次重读整个项目，也不会完全依赖用户重复解释。
关键技术说明 持续理解 主要由三类机制支撑：
用来扫描源码，生成模块、文件、函数、依赖和摘要。它回答的是：这个项目的代码结构是什么。
用来记录项目目的和方向。它回答的是：这个项目为什么存在，当前想解决什么问题。
用来按任务组装相关上下文。它回答的是：当前任务需要知道哪些历史、约束、代码结构和证据。
持续理解 的关键点是：上下文是按任务组装的，不是全量灌入的。
这里的 Context Pack 是一个边界很重要的概念。它不是知识库全文，也不是聊天摘要，而是从多个事实来源里选出当前任务相关的上下文。
CodeGraph Project intent Memory / context pack
flowchart LR
A["Current Task"] --> B["Context Pack"]
C["CodeGraph"] --> B
D["Project Intent"] --> B
E["TaskGraph"] --> B
F["Memory"] --> B
G["Evidence / Review"] --> B
B --> H["Agent receives bounded context"]
它如何解决稳定性 持续理解 带来的稳定性主要有五个：
结构稳定：AI 从 CodeGraph 读取项目结构，不完全靠猜。 方向稳定：AI 从 Project intent 读取项目目的，不容易偏航。 任务稳定：AI 从 TaskGraph 读取当前推进状态，不靠聊天续命。 证据稳定：AI 从 Evidence / Review 知道哪些结果已被接受或拒绝。 上下文稳定：AI 每次拿到的是有边界的 context pack，而不是随机聊天残留。 边界 不能说 CARVES 能第一次完整理解项目。
更准确地说：
CARVES 的持续理解 不是全知，也不是自动读懂一切。它通过项目结构索引、项目意图 、任务推进记录、记忆和证据，不断为当前任务组装更稳定的上下文。项目越推进，CARVES 的理解越可靠。
安全执行
执行包 / 工作区租约 / Guard 下层机制
执行包 它在执行前打包任务范围、限制、证据要求和预期结果。 工作区租约 它把执行绑定到任务和工作区，避免失败尝试直接污染主项目。 Guard 它在 work 进入 review 或 merge 前检查 patch、diff、path、budget 和 risk。
让智能体先知道任务范围、限制、证据要求和补丁边界。
安全执行 不是阻止智能体干活，而是让它在任务边界、受控工作区预期、证据要求和补丁检查下工作。
执行和完成不是一回事。Worker result 仍然需要证据、边界检查和审核，才能被接受。
为什么可检查
执行从明确任务包开始。 工作区或租约边界降低主项目污染。 Guard 在 review 或 merge 前检查 diff、路径和风险。 完整机制说明
大白话功能说明 安全执行 是 CARVES 把“让 AI 去做事”变成“让 AI 在边界内做事”的机制。
安全执行 不是不让 Agent 干活，而是让 Agent 在清楚任务、范围、限制和证据要求之后再干活，并且尽量避免它直接污染主项目。
它解决的是：AI 可以很能干，但不能让它自由施工。
它解决什么问题 普通 vibe coding 里最危险的地方是：
安全执行 解决的是：
让 AI 的执行有边界、有隔离、有检查、有证据。
Agent 没有明确范围就开始改。 一个小任务顺手改了很多无关文件。 AI 不知道哪些文件不能碰。 执行过程中污染主分支或主目录。 结果没有证据，却直接说完成。 失败后继续硬做，越修越乱。 人类很难知道它到底改了什么、为什么改。 安全执行负责什么 安全执行 负责把执行前、执行中、执行后的关键控制点串起来：
它的重点是：让 Agent 的能力被放进项目边界里。
执行前：明确任务范围、约束、验收条件。 执行中：尽量在受控工作区或受控边界内操作。 执行后：提交结果、证据、diff 和说明。 审核前：检查是否越界、是否有风险、是否满足证据要求。 出问题时：停止、返工、重规划，而不是盲目继续。 亮点 安全执行 的亮点是：Agent 不是直接拿到“自由修改权”，而是拿到一份有边界的执行任务。
CARVES 不假设 AI 一定会自觉控制范围。它通过任务包、工作区、边界检查和审核，把执行过程变成可管理流程。
这让 CARVES 有一个很重要的稳定性：
AI 可以负责动手，但执行权必须带范围、证据和回收路径。
关键技术说明 安全执行 主要由三类机制组成：
执行任务包。它告诉 Worker 当前任务是什么、范围在哪里、不能做什么、需要什么证据。
受控工作区和租约。它让执行尽量绑定到某个任务和工作区，降低直接污染主项目的风险。
边界检查。它对 patch、diff、路径和风险类别进行检查，防止无关修改、危险删除或越界写入被轻易接受。
典型流程：
关键点是：执行和完成不是一回事。
Worker 可以执行，但执行结果必须经过证据、边界检查和审核，才可以被接受为完成。
Execution Packet Managed Workspace / LeaseGuard
flowchart LR
A["Approved Task"] --> B["Execution Packet"]
B --> C["Managed Workspace / Lease"]
C --> D["Agent / Worker executes"]
D --> E["Result + Diff + Evidence"]
E --> F["Guard Check"]
F --> G["Review Gate"]
G -->|Accept| H["Writeback / Complete"]
G -->|Reject| I["Rework"]
G -->|Replan| J["Planning"]
它如何解决稳定性 安全执行 带来的稳定性主要有五个：
范围稳定：任务先带 scope，减少无关修改。 隔离稳定：受控工作区降低主项目被直接污染的风险。 证据稳定：结果需要带测试、diff、日志或 artifact。 边界稳定：Guard 能拦住危险路径、异常删除、范围漂移。 恢复稳定：失败后可以 reject、rework、replan，而不是继续乱修。 边界 不能说安全执行 能保证 AI 永远不会犯错。
更准确地说：
安全执行 不能让 AI 变成绝对安全的执行者。它的价值是降低范围漂移、无证据完成、主项目污染和不可追溯修改的风险。最终是否接受结果，仍然需要证据和审核。
证据验收
Evidence / Review Gate / Shield 下层机制
Evidence 它记录 diff、测试、日志、artifact、运行输出或说明，让审核有东西可检查。 Review Gate 它把 worker result 转成 accept、reject、replan、block 或 reopen，并记录原因。 Shield 它读取摘要证据，输出 Guard / Handoff / Audit 维度、Lite 分数和 badge。
让“完成”依赖证据和审核，而不是依赖智能体的自信语气。
在 CARVES 里，“完成了”不是智能体一句话。结果需要 diff、测试、日志、artifact、运行输出或说明等证据，再由审核关口决定 accept、reject、replan、block 或 reopen。
这让任务状态绑定在证据和决定上，而不是绑定在自信语气上。
为什么可检查
证据先于验收。 审核决定明确且可追溯。 Shield 可以评估摘要证据，但不会变成认证。 完整机制说明
大白话功能说明 证据验收 是 CARVES 判断“AI 做完了”是否真的可以被接受的机制。
在 CARVES 里，Agent 说完成不算完成。它必须交出证据，再经过审核，才可以算这个任务真的被接受。
它解决的是：不要让 AI 自己宣布自己完成。
它解决什么问题 普通 vibe coding 里经常出现：
证据验收 解决的是：
让每个完成结果都有证明、有判断、有回写记录。
Agent 说“完成了”，但没有测试结果。 AI 改了代码，但没有解释为什么这样改。 用户不知道它到底验证了什么。 任务看起来完成，其实只是代码能编译。 有些结果应该返工，但被 AI 包装成完成。 换线程后，没人知道上一次完成的依据是什么。 证据验收负责什么 证据验收 负责三件事：
它的重点是：
完成不是一句话，而是一组可以检查的材料和一个明确审核结果。
收集证据：测试、diff、日志、运行结果、artifact、说明。 检查证据：证据是否足够支撑任务验收。 做出决定：接受、拒绝、返工、重规划或阻塞。 亮点 证据验收 的亮点是：把“AI 自称完成”变成“结果经过证明和审核”。
这对 AI 编程非常关键。因为 Agent 很容易给出自信回答，但自信不是证据。
CARVES 不要求所有任务都跑复杂测试，但至少要求结果有可读回的证明：
这让 CARVES 有一个很重要的稳定性：
任务状态不是由 Agent 的语气决定，而是由证据和审核决定。
它改了什么。 它为什么这样改。 它运行了什么检查。 哪些证据支持它已完成。 谁或哪个审核流程接受了结果。 关键技术说明 证据验收 主要由三类机制组成：
记录结果的证明材料，例如 diff、测试输出、日志、artifact、运行结果和说明。
判断证据是否足够，决定 accept、reject、replan、block 或 reopen。
对证据做本地自检，帮助用户快速判断证据质量，但不把它夸大成外部认证。
典型流程：
关键点是：证据和审核要在完成之前。
Worker result 只是候选结果。只有证据被检查、审核决策被记录后，任务才应该进入 accepted / completed 状态。
Evidence Review Gate Shield
flowchart LR
A["Worker Result"] --> B["Evidence"]
B --> C["Shield Self-check"]
B --> D["Review Gate"]
C --> D
D -->|Accept| E["Task Accepted"]
D -->|Reject| F["Rework"]
D -->|Replan| G["Planning"]
D -->|Block| H["Blocked"]
它如何解决稳定性 证据验收 带来的稳定性主要有五个：
结果稳定：任务完成需要证据支撑。 判断稳定：审核决定明确，不靠聊天语气判断。 返工稳定：reject / replan 能留下原因，避免重复犯错。 交接稳定：后续 Agent 能读回为什么这个结果被接受。 信任稳定：用户知道 CARVES 为什么认为任务可以继续推进。 边界 不能说证据验收 能保证结果一定正确。
更准确地说：
证据验收 不能消除所有 bug，也不能替代专业代码审查。它的价值是让完成状态有证据、有审核、有原因，而不是让 AI 自己宣布成功。
不断线交接
接入握手 / Runtime Manifest / Handoff Packet 下层机制
接入握手 它记录 attach request 和 acknowledgement，让下一位智能体不用猜要不要重新 init。 Runtime Manifest 它告诉目标项目应该解析回哪个 CARVES Runtime。 交接包 它保存当前目标、已完成事实、剩余工作、阻塞点、证据引用和下一步。
让项目接入、运行时绑定和下一步在下一次会话仍然可读。
不断线交接 解决线程断掉、智能体更换、上下文丢失的问题。它把接入、运行时绑定和会话交接拆成可读 artifact。
下一位智能体不应该猜项目是否已接入、Runtime 在哪里，或者上一轮留下了什么。
为什么可检查
接入状态可以读回。 Runtime root 可以解析，不需要把 Runtime 文档复制进目标项目。 下一步、阻塞点、证据引用和 confidence 可以交接。 完整机制说明
大白话功能说明 不断线交接 是 CARVES 用来保证 AI 项目不会因为线程结束、Agent 更换、上下文丢失而断掉的机制。
大白话说，它不是只让 Agent 留一句“我做到哪里了”，而是让项目在下一次被打开时，还能知道三件事：
它解决的是：AI 工作可以换线程、换 Agent、隔几天再回来，但项目不应该从零开始。
这个项目有没有接上 CARVES。 这个项目应该找哪个 CARVES Runtime。 上一次工作到底交接到哪里。 它解决什么问题 普通 vibe coding 里经常出现：
不断线交接 解决的是：
让下一次工作可以沿着已有接力线继续，而不是靠聊天记录续命。
线程一断，下个 Agent 又重新摸索项目。 已经完成的事被重复做。 曾经拒绝过的路线又被拿出来重试。 Agent 不知道当前项目是否已经接上 CARVES。 Agent 不知道应该读取哪个 Runtime 的文档和规则。 上一次工作留下了结论，但没有可靠交接入口。 三层核心 不断线交接 有三层核心：
这三层合起来，回答三个问题：
Attach Handshake：接入握手 ，确认这个项目已经接上 CARVES。 Runtime Manifest ：运行时绑定记录，确认这个项目应该找哪个 Runtime。Handoff Packet ：会话交接单，确认下一次 Agent 应该从哪里继续。项目接上了吗？ Runtime 在哪里？ 下一次该从哪里继续？ 亮点 不断线交接 的亮点是：CARVES 把“项目连续性”拆成接入、绑定、交接三件事，而不是把所有连续性都压在聊天上下文里。
这让项目有一条更稳定的接力线：
这让 CARVES 有一个很重要的稳定性：
Agent 换了、线程断了、上下文丢了，项目仍然可以从可读回的接力信息继续推进。
Attach Handshake 证明项目接上了 CARVES。 Runtime Manifest 证明项目该找哪个 Runtime。Handoff Packet 证明下一次会话该从哪里继续。 关键技术说明 不断线交接 不是单一文件，而是一条接力链：
典型路径包括：
在 attached target repo 里，CARVES 还会通过 runtime_document_root_mode 判断 Runtime 文档根应该来自 attach handshake，还是 Runtime manifest fallback。
这点很关键：目标项目不需要复制 Runtime 文档，也不应该把 Runtime 文档当成自己的项目 truth。目标项目负责自己的项目文件、计划、任务和证据；Runtime 负责提供 CARVES 的规则、入口和控制面。
.ai/runtime/attach-handshake.json .ai/runtime.json .ai/handoff/handoff.json
flowchart LR
A["Attach Handshake"] --> B["Runtime Manifest"]
B --> C["Handoff Packet"]
C --> D["Next Agent Resume"]
它如何解决稳定性 不断线交接 带来的稳定性主要有五个：
接入稳定：下一次会话能知道项目是否已经接上 CARVES。 入口稳定：下一次会话能知道应该找哪个 Runtime。 上下文稳定：下一次会话能读到当前目标、完成事实和剩余工作。 交接稳定：换 Agent 时不需要从聊天记录重新猜。 边界稳定：目标项目和 Runtime 文档根不会混在一起。 边界 不能说不断线交接 等于长期记忆、规划系统或安全审核。
更准确地说：
不断线交接 负责让下一次工作接得上。它不决定任务应不应该执行，不替代 TaskGraph、Memory、Evidence、Review Gate 或人工判断。
可审计闭环
Audit / Matrix / 提交卫生 下层机制
Audit 它读取 Guard 和 Handoff 记录，输出 summary、timeline、explain 和 Shield evidence。 Matrix 它编排 Guard -> Handoff -> Audit -> Shield，并记录仅摘要的 proof artifacts。 提交卫生 它帮助判断哪些路径应该进 git，哪些只是本地 residue 或需要人工 review。
读回历史、证明本地组合路径，并在提交前区分项目输出和 residue。
可审计闭环 处理的是工作发生之后：读回历史、证明本地治理链条可以组合，并在收尾时避免把所有脏文件都塞进 git。
它让“智能体改了东西”变成“我们可以检查发生了什么、跑过什么 proof lane、哪些东西应该提交”。
为什么可检查
Audit 只读历史，不改 Guard 或 Handoff truth。Matrix 证明 Guard -> Handoff -> Audit -> Shield 本地路径可以组合。提交卫生 避免本地 residue 意外变成项目 truth。 完整机制说明
大白话功能说明 可审计闭环 是 CARVES 让 AI 工作在完成之后还能被读回、被证明、被干净提交的机制。
大白话说，它管的是“事后怎么查”和“最后怎么收口”。AI 改完不是终点，项目还需要知道：过去发生过什么、证据链能不能被读出来、治理链条能不能跑通、最后哪些文件可以进入 git。
它解决的是：
AI 项目不能只看当前结果，还必须能回头查账。
它解决什么问题 普通 vibe coding 里经常出现：
可审计闭环 解决的是：
让 AI 工作有历史读回、组合 proof 和提交卫生 。
AI 改完了，但之后没人知道当时发生过什么。 Guard、Handoff、Evidence 各自有记录，但没有统一读回入口。 项目想展示治理状态，却没有本地 proof 证明工具链能串起来。 提交前直接 git add .，把临时文件、工具残留、未分类内容一起提交。 事后复盘时，只剩聊天记录和零散文件。 三层核心 可审计闭环 有三层核心：
这三层合起来，回答三个问题：
Audit ：历史读回。读取 Guard decisions、Handoff packets 等记录，生成 summary、timeline、explain，并产出 shield-evidence.v0。Matrix ：组合证明。把 Guard -> Handoff -> Audit -> Shield 串成一个本地 proof lane，证明这些治理工具能组合工作。Commit hygiene：提交收口。提交前分类 dirty paths，区分正式 truth、目标输出、本地 residue 和未分类风险，避免 git add . 把脏东西带进去。 过去发生了什么？ 治理链条能不能本地证明？ 最后哪些东西可以干净提交？ 全局流程
flowchart LR
A["Guard Decisions"] --> C["Audit"]
B["Handoff Packets"] --> C
C --> D["Summary / Timeline / Explain"]
C --> E["shield-evidence.v0"]
E --> F["Shield"]
F --> G["Matrix Proof"]
H["Dirty Worktree"] --> I["Commit Hygiene"]
I --> J["Commit Plan"]
J --> K["Closure"]
亮点 可审计闭环 的亮点是：CARVES 不只是让 AI 做事，还让 AI 做过的事能被查、能被证明、能被收干净。
普通 vibe coding 经常停在“AI 改完了”。但真实项目还要面对三个问题：
可审计闭环 就是为这三个问题收口。
以后能不能查？ 能不能证明治理链路没有断？ 提交时会不会把临时文件和工具残留一起塞进去？ 技术说明 Audit 是只读层。它不修改 Guard 或 Handoff 的 truth，只负责发现证据、生成摘要、时间线、解释和 Shield evidence。
Matrix 是组合层。它不拥有 Guard、Handoff、Audit 、Shield 的业务逻辑，只证明这些工具的本地 proof artifact 能串起来。
Commit hygiene 是提交前分类层。它不替用户 commit，而是告诉用户哪些路径可以进提交，哪些需要排除、清理或人工 review。
它如何解决稳定性 可审计闭环 带来的稳定性主要有五个：
读回稳定：历史记录可以通过 Audit 汇总、解释和生成证据。 证明稳定：Matrix 可以证明本地治理工具链能组合工作。 提交稳定：Commit hygiene 避免未分类文件和本地 residue 混进提交。 复盘稳定：事后可以从 summary、timeline、explain 和 proof artifact 查回上下文。 边界稳定：Audit 、Matrix 、Commit hygiene 各司其职，不互相夺权。 边界 不能说可审计闭环 是认证、hosted verification、代码正确性证明或人工 review 替代品。
更准确地说：
可审计闭环 提供的是历史读回、组合 proof 和提交卫生 。它不能证明代码绝对正确，也不能替代 QA、安全审计或人工判断。
← 返回上层机制: 项目调度 项目调度 / Card
Card 是目标锚点。 它把用户想法变成可讨论、可批准、可拆任务、可验收的目标。
Card 防止项目目标漂在聊天记录里。它记录要解决什么、为什么值得做、范围是什么、不能碰什么，以及成功后应该看到什么。
Card 草案不等于批准。人类确认之后，下游计划才有合法入口。
完整机制说明
大白话功能说明 Card 是 CARVES 里承载“项目目标”的最小调度单位。
Card 就是把一句“我想让 AI 做这件事”，变成一张可以讨论、确认、拆任务、验收的目标卡。
它不是普通 UI 卡片，而是 CARVES 用来防止项目目标漂在聊天里的机制。
它解决什么问题 没有 Card 时，vibe coding 很容易出现这些情况：
Card 解决的是：先把目标钉住，再允许项目推进。
用户一句话说了目标，Agent 直接开写。 目标还没定清楚，AI 已经拆了很多任务。 聊天往后滚，最初为什么做这件事没人记得。 后面发现做偏了，但找不到“原始目标”。 多个目标混在同一个对话里，范围不断膨胀。 Card 负责什么 一张 Card 应该说明：
所以 Card 的重点不是“写得漂亮”，而是让目标变得可追踪、可审核、可拆解。
这件事要解决什么问题。 为什么现在值得做。 成功后应该看到什么结果。 哪些范围可以做。 哪些范围不能碰。 它后续可以拆成哪些任务。 它目前处于什么状态。 亮点 Card 的亮点是：它把 AI 的工作入口从聊天变成目标卡。
也就是说，Agent 不能只因为一句聊天就默认获得长期项目授权。用户提出想法后，CARVES 可以先形成 Card draft。只有当 Card 被确认，它才变成后续 Plan 和 Task 的上游依据。
这让 CARVES 有一个很重要的稳定性：
项目的每一条执行线，都能往上追溯到一个被确认的目标。
关键技术说明 Card 在技术上是目标层 truth 的载体。
它通常会进入以下流程：
关键点是：Card draft 不等于批准。
Agent 可以帮助生成 Card ，但不能因为自己生成了 Card，就自动获得执行权。Card 必须经过明确状态变化，后续任务才有合法上游。
技术上，Card 与 TaskGraph 是上下游关系：
create-card -draft：创建 Card 草案。 inspect-card ：查看 Card 内容。 approve-card ：确认 Card 可以进入后续规划。 reject-card / archive-card：拒绝或归档不再推进的目标。 create-taskgraph-draft：从已批准 Card 继续拆任务。 approve-taskgraph-draft：确认任务图后才进入执行线。
flowchart LR
A["User idea / request"] --> B["Card draft"]
B --> C{"Human decision"}
C -->|Approve| D["Approved Card"]
C -->|Reject| E["Rejected / Archived"]
D --> F["TaskGraph draft"]
F --> G{"Human decision"}
G -->|Approve| H["Executable Tasks"]
G -->|Replan| F
它如何解决稳定性 Card 带来的稳定性主要有四个：
这就是为什么 CARVES 不应该让 Agent 一上来就直接执行大目标。先有 Card ，项目才有锚点。
目标稳定：先确认目标，再拆任务。 范围稳定：Card 记录能做什么、不能做什么。 追溯稳定：任务可以往上追溯到 Card 。 决策稳定：目标是否推进，需要明确批准或拒绝。 边界 不能说 Card 会自动保证目标正确。
更准确地说：
Card 不能替用户决定产品方向。它只是把目标变成可检查、可批准、可追踪的项目入口，让人类更容易判断这件事是否值得继续推进。
边界
Card 不替用户决定产品方向，它只是让方向可检查。
← 返回上层机制: 项目调度 项目调度 / 计划草案
计划草案让计划保持 provisional。 智能体可以提出路径，但提议不会自动变成可执行 truth。
计划草案 位于想法和执行之间。它让智能体先提出拆解、风险、顺序和证据要求，再由人决定是否进入任务线。
这样可以保留智能体的建议能力，但不让它自己创建任务、自己批准任务。
完整机制说明
大白话功能说明 计划草案 是 CARVES 在“目标卡”和“正式任务”之间放的一层缓冲区。
计划草案 就是让 AI 先说“我打算怎么做”，但不允许它说完计划就马上开工。
它的作用不是拖慢进度，而是防止 Agent 把自己的想法直接变成执行命令。
它解决什么问题 在普通 vibe coding 里，Agent 很容易这样做：
计划草案 解决的是：先审计划，再执行任务。
用户提出目标。 Agent 立刻拆很多步骤。 Agent 直接开始改文件。 做到一半才发现方向不对。 用户想回头改计划，但代码已经动了很多。 计划草案负责什么 一份好的计划草案 应该说明：
它不是最终任务图，而是进入任务图之前的讨论材料。
这个目标准备拆成哪些阶段。 每个阶段要解决什么问题。 哪些任务必须先做。 哪些任务可以并行。 哪些地方需要人工确认。 哪些范围不能碰。 做完后如何验收。 亮点 计划草案 的亮点是：AI 可以参与规划，但不能独自批准规划。
这很重要，因为 AI 很擅长生成看起来完整的计划，但计划是否值得做、是否顺序正确、是否成本可接受，必须由人类或 CARVES 的审核流程确认。
计划草案 让 CARVES 保留一个关键控制点：
Agent 可以提出路线，但不能自己决定路线已经合法。
关键技术说明 计划草案 通常处于 draft / suggested 状态。它可以由 Agent 生成，但不会自动成为正式 TaskGraph。
典型流程是：
关键点是：Planning draft 和 TaskGraph truth 分开。
这避免了一个很危险的问题：Agent 自己生成计划后，直接把计划当作已批准任务执行。
Planning draft 是计划建议。 TaskGraph draft 是更结构化的任务图草案。 Approved TaskGraph 才能进入执行线。
flowchart LR
A["Approved Card"] --> B["Planning draft"]
B --> C{"Review plan"}
C -->|Approve| D["TaskGraph draft"]
C -->|Revise| B
C -->|Reject| E["Stop / Archive"]
D --> F{"Approve TaskGraph"}
F -->|Approve| G["Executable Tasks"]
F -->|Replan| B
它如何解决稳定性 计划草案 带来的稳定性主要有五个：
方向稳定：先看路线是否对，再动手。 顺序稳定：先确认前置任务和依赖关系。 范围稳定：计划阶段就能拦住范围膨胀。 成本稳定：提前发现任务过大、拆分不合理或验证成本过高。 控制权稳定：人类保留批准、修改、拒绝计划的权力。 边界 不能说计划草案 会保证计划一定正确。
更准确地说：
计划草案 不能替用户判断产品方向，也不能保证 AI 拆分出的路线一定最优。它的价值是把计划放到执行之前，让用户能先审路线、改范围、确认依赖，再允许 Agent 做事。
边界
计划草案 不保证计划正确，它让计划在执行前可检查。
← 返回上层机制: 项目调度 项目调度 / TaskGraph
TaskGraph 是项目推进账本。 它记录任务、依赖、状态、证据、审核结果、阻塞、返工和下一步。
TaskGraph 不是普通待办，也不是 Wiki。它记录项目如何推进：任务来自哪个 Card、哪些任务互相依赖、哪里被阻塞、哪些结果有证据和审核。
下一位智能体可以沿着项目事实继续，而不是从旧聊天里猜。
完整机制说明
大白话功能说明 TaskGraph 是 CARVES 的项目推进账本。
它记录一个目标被拆成了哪些任务、任务之间怎么依赖、每个任务推进到哪里、哪些任务被完成、阻塞、返工或重规划，以及这些推进背后有什么证据和审核结果。
它不是普通待办清单，也不是 Wiki。它负责保存项目“怎么一步步走到现在”。
它解决什么问题 普通 vibe coding 很容易靠聊天续命：
TaskGraph 解决的是：
让项目推进过程脱离聊天上下文，变成可读回、可追溯、可审核的推进脉络。
这件事为什么做，藏在很早以前的对话里。 Agent 换了、线程断了，就不知道项目走到哪里。 AI 只看当前 prompt，容易重复走已经被拒绝的路线。 任务之间的依赖不清楚，导致乱序执行。 做完了没有清楚回写，后续不知道它到底算不算完成。 TaskGraph 负责什么 TaskGraph 负责记录项目推进关系，而不是保存全部项目知识。
它关注的是：
它的重点不是“这个项目知道什么”，而是：
这个项目正在怎么走，为什么走到这里，下一步应该接哪里。
目标从哪个 Card 来。 目标被拆成哪些任务。 哪些任务必须先完成。 哪些任务可以后续推进。 哪些任务被阻塞、拒绝、返工或重规划。 哪些任务已经有结果，但还需要审核。 哪些证据和审核结果支撑当前状态。 亮点 TaskGraph 的亮点是：它把项目记忆从资料堆，变成推进账本。
Wiki / Memory 保存项目知识，CodeGraph 保存代码结构，Review / Evidence 保存验收事实，而 TaskGraph 保存项目推进脉络。
这让 CARVES 有一个很强的稳定性：
Agent 不需要每次从聊天记录里重新猜项目进度，也不需要读完整个知识库才能开始工作。它可以沿着已经验证过的推进脉络继续做事。
关键技术说明 TaskGraph 在技术上是 CARVES 的任务层 truth。
它承接 Approved Card，生成任务图，再把任务推进到执行、证据、审核和回写流程。
关键点是：
TaskGraph 不只是任务列表，而是任务图、状态机和推进账本的结合。
它同时表达三件事：
TaskGraph 还应该只引用证据和审核材料，而不是把所有证据正文塞进自己里面。否则 TaskGraph 也会变成另一个臃肿 Wiki。
图：任务之间的依赖关系。 状态机：任务处于等待、执行、审核、完成、阻塞、返工等状态。 账本：任务为什么推进、产出了什么、为什么通过或返工。
flowchart LR
A["Approved Card"] --> B["TaskGraph draft"]
B --> C{"Approve TaskGraph"}
C -->|Approve| D["Task Nodes"]
C -->|Replan| B
D --> E["Execution Packet"]
E --> F["Worker Result"]
F --> G["Review Gate"]
G -->|Accept| H["Task Completed"]
G -->|Reject| I["Task Rework"]
G -->|Replan| B
它如何解决稳定性 TaskGraph 带来的稳定性主要有五个：
推进稳定：项目不是靠聊天继续，而是靠任务状态继续。 依赖稳定：任务知道前置条件，减少乱序执行。 记忆稳定：历史任务、拒绝路线、审核结果都能成为后续判断依据。 范围稳定：任务 scope 明确，避免 Agent 顺手扩大范围。 恢复稳定：线程断了、Agent 换了，也能通过 TaskGraph 读回当前进度。 边界 不能说 TaskGraph 会替代所有文档。
更准确地说：
TaskGraph 是项目推进记忆，不是百科知识库。它适合记录目标、任务、依赖、状态、拒绝路线、返工路线和审核结果；而 API 说明、领域知识、长期设计背景，仍然可以存在于 Wiki、Memory 或普通文档中。TaskGraph 的核心价值，是让项目“如何走到现在”变得清楚。
边界
TaskGraph 应引用证据和审核材料，不应变成巨大的证据仓库。
← 返回上层机制: 持续理解 持续理解 / CodeGraph
CodeGraph 是本地代码结构图。 它记录模块、文件、函数、依赖、摘要和任务相关范围。
CodeGraph 给 CARVES 一张结构化代码地图。智能体可以先看模块、文件、可调用单元和依赖事实，而不是随机翻文件。
对大项目来说，这能降低上下文有限带来的猜测和漂移。
完整机制说明
大白话功能说明 CodeGraph 是 CARVES 对项目代码结构的本地地图。
CodeGraph 让 CARVES 知道项目里有哪些模块、文件、函数、依赖关系，而不是每次都让 AI 从一堆文件里重新猜项目结构。
它不是完整语义大脑，也不是万能代码理解引擎。它更像项目的“代码地形图”。
它解决什么问题 普通 AI 编程里，Agent 很容易出现这些问题：
CodeGraph 解决的是：
先给 AI 一张项目结构地图，让它从结构事实开始理解项目，而不是从随机阅读开始猜。
不知道项目真正有哪些模块。 看了一个文件，就以为理解了整个项目。 改一个地方，却不知道会影响哪些模块。 任务 scope 很模糊，越改越远。 每次换线程都要重新扫项目结构。 大项目里，AI 容易靠文件名和直觉猜依赖。 CodeGraph 负责什么 CodeGraph 主要负责记录代码结构事实：
它回答的是：
这个项目的代码现在长什么样？
项目有哪些代码目录。 有哪些模块。 模块里有哪些文件。 文件里有哪些类型、函数或 callable。 模块之间有哪些依赖。 哪些文件和当前任务 scope 有关。 当前代码结构摘要是什么。 亮点 CodeGraph 的亮点是：把代码理解从“读文件碰运气”变成“先看结构地图”。
Agent 不需要一开始就翻完整个仓库。CARVES 可以先用 CodeGraph 给它一个结构化入口：模块数量、文件数量、依赖关系、相关 scope、影响范围。
这对大项目尤其重要，因为 AI 的上下文有限。CodeGraph 可以让 AI 先知道“地图”，再决定要深入读哪里。
关键技术说明 CodeGraph 是 .ai/codegraph/ 下的一组本地结构化投影。
当前核心产物包括：
CodeGraph 的关键点是：结构事实优先，文本总结其次。
也就是说，CARVES 不应该只给 Agent 一段“项目大概是什么”的自然语言总结，而应该优先给它结构化事实：哪些模块、哪些文件、哪些依赖、当前任务 scope 命中了哪里。
manifest.json：记录模块数、文件数、callable 数、依赖数、生成时间。 index.json：轻量索引，用于快速读取模块和文件结构。 search/index.json：搜索入口。 modules/：模块级 shard，保存模块内文件、类型、函数等更细信息。 summaries/：模块摘要，给人和 Agent 快速阅读。 dependencies/module-deps.json：依赖关系 shard。
flowchart LR
A["Source files"] --> B["CodeGraph scan"]
B --> C["Manifest"]
B --> D["Index"]
B --> E["Module shards"]
B --> F["Dependency shards"]
C --> G["Context Pack"]
D --> G
E --> G
F --> G
G --> H["Agent reads scoped structure facts"]
它如何解决稳定性 CodeGraph 带来的稳定性主要有五个：
结构稳定：项目结构可读回，不靠 Agent 临场猜。 范围稳定：任务可以和具体模块、文件、scope 对齐。 影响稳定：依赖关系帮助判断改动可能影响哪里。 上下文稳定：Agent 可以先读相关结构，再决定深入文件。 刷新稳定：当源码更新后，CodeGraph 可以重新生成，避免长期拿旧结构判断。 边界 不能说 CodeGraph 已经等于完整代码语义理解。
更准确地说：
CodeGraph 是代码结构地图，不是全自动架构师。它能提供模块、文件、函数、依赖和 scope 线索，但复杂业务语义、运行时行为、隐性设计意图，仍然需要结合 Memory、TaskGraph、Evidence、Review 和人工判断。
边界
CodeGraph 不是完整语义大脑，也不是正确性证明。
← 返回上层机制: 持续理解 持续理解 / 项目意图
Project Intent 让方向保持可见。 它记录项目解决什么问题，以及当前方向应该是什么。
项目意图 是面向用户的方向层。它帮助智能体在改实现细节前先理解项目为什么存在。
意图可以从 README 和结构生成草案，但人类确认才让它真正适合作为方向依据。
完整机制说明
大白话功能说明 Project intent 是 CARVES 对“这个项目到底要做什么”的方向记录。
Project intent 就是先把项目的目的、用户、范围和第一步方向讲清楚，避免 AI 一上来就只看代码然后乱规划。
它解决的是：AI 不只是知道“项目有什么代码”，还要知道“这个项目为什么存在”。
它解决什么问题 普通 vibe coding 里经常出现：
Project intent 解决的是：
先确认项目方向，再进入正式计划和任务。
AI 看了代码，但不知道产品真正目标。 用户想做 A，Agent 根据代码结构推成 B。 项目早期方向没写清楚，后面越做越散。 Agent 每次换线程都要重新问“这个项目是干嘛的”。 README 里有一些说明，但没有进入正式推进流程。 目标和范围没有被确认，AI 就开始拆任务。 Project intent 负责什么 Project intent 负责记录：
它不是写一篇漂亮的产品介绍，而是给 CARVES 和 Agent 一个方向锚点。
项目要解决什么问题。 谁会使用这个项目。 当前最重要的能力是什么。 项目现在应该聚焦什么范围。 哪些方向还没确认。 第一条可推进的目标线是什么。 当前方向是否已经被人类接受。 亮点 Project intent 的亮点是：项目方向必须被明确接受，不能让 AI 自己脑补。
CodeGraph 可以告诉 AI “代码长什么样”，但不能告诉 AI “项目应该往哪里走”。Project intent 补的是方向层。
这很重要，因为 AI 很容易根据当前代码推断目标，但代码只是历史结果，不一定代表用户现在真正想要的方向。
Project intent 让 CARVES 形成一个控制点：
先确认项目为什么存在，再让 Agent 规划怎么推进。
关键技术说明 Project intent 通常来自 README、项目名称、CodeGraph 摘要和用户对话，但它不能自动成为长期 truth。
典型流程是：
关键点是：intent draft 不等于项目 truth。
AI 可以生成 intent draft，但项目方向必须经过人类确认。否则 CARVES 会把 AI 的推测误当成项目目标。
Project intent 也不应该和 TaskGraph 混在一起：
Project intent 说明项目为什么存在。 Card 承载一个可推进目标。 TaskGraph 记录这个目标如何被拆解和推进。 Memory 保存长期知识和架构背景。 CodeGraph 保存代码结构事实。
flowchart LR
A["README / user discussion / CodeGraph"] --> B["Intent draft"]
B --> C{"Human review"}
C -->|Accept| D["Accepted Project Intent"]
C -->|Revise| B
C -->|Reject| E["Discard / pause"]
D --> F["Card / Planning"]
它如何解决稳定性 Project intent 带来的稳定性主要有五个：
方向稳定：Agent 不再只根据代码猜项目目标。 范围稳定：用户确认的方向能限制后续规划漂移。 沟通稳定：换线程后，Agent 能读回项目目的。 规划稳定：Card 和 TaskGraph 可以围绕已确认方向展开。 纠偏稳定：如果 intent stale 或不完整，可以先刷新方向，而不是直接执行。 边界 不能说 Project intent 会自动决定产品方向。
更准确地说：
Project intent 是方向锚点，不是产品老板。它可以帮助整理项目目的和范围，但是否接受这个方向，仍然需要人类确认。它的价值是防止 AI 在目标未确认时就进入规划和执行。
边界
项目意图 在被确认前不应自动变成长期 truth。
← 返回上层机制: 持续理解 持续理解 / 上下文包
Memory / Context Pack 只携带相关上下文。 它把任务、代码结构、历史、约束和证据组合成有边界的上下文包 。
上下文包 不是完整记忆数据库。它是当前任务需要的选中上下文：现在重要什么、已经发生什么、不能重复什么、哪些证据或审核事实相关。
它让长项目不用从零开始，也不把所有内容灌给智能体。
完整机制说明
大白话功能说明 Memory / Context Pack 是 CARVES 给 Agent 准备“当前任务所需上下文”的机制。
Memory 保存项目长期重要信息；Context Pack 负责在执行某个任务时，把真正相关的记忆、任务、代码结构、证据和限制打包给 Agent。
它解决的是：AI 不需要每次读完整个项目，也不应该只靠当前聊天上下文做事。
它解决什么问题 普通 vibe coding 里经常出现：
Memory / Context Pack 解决的是：
把项目记忆分层保存，再按当前任务取用，而不是每次全部灌给 AI。
Agent 忘记项目长期规则。 用户之前说过的架构边界，换线程后失效。 AI 为了保险读太多文件，浪费 token。 AI 读太少，又漏掉关键约束。 项目记忆散落在 README、聊天、代码注释、历史任务里。 上下文越塞越多，反而让 AI 抓不住重点。 Memory 负责什么 Memory 负责保存长期、稳定、有复用价值的项目知识，例如：
Memory 回答的是：
这个项目长期需要记住什么？
架构原则。 模块职责。 长期约束。 重要决策背景。 已确认的项目规则。 反复出现的问题模式。 人类明确要求保留的上下文。 Context Pack 负责什么 Context Pack 负责把当前任务需要的信息组装出来。
它可以从多种来源取上下文：
Context Pack 回答的是：
这个任务现在需要知道什么？
当前 Task。 上游 Card。 TaskGraph 推进状态。 CodeGraph 结构事实。 Memory 长期知识。Evidence / Review 审核结果。 Failure / blocker 历史。 当前 scope 相关文件线索。 亮点 Memory / Context Pack 的亮点是：不是把记忆全部塞给 AI，而是按任务打包相关上下文。
这和普通知识库不一样。知识库更像“你自己去搜资料”，而 Context Pack 更像“CARVES 根据当前任务，把你现在该看的东西整理好”。
它让 CARVES 有一个很重要的稳定性：
Agent 拿到的不是随机聊天残留，也不是整本项目百科，而是当前任务相关的项目事实包。
关键技术说明 Memory 和 Context Pack 是两层机制：
关键点是：Memory 是存储层，Context Pack 是取用层。
它和 TaskGraph 的区别也要讲清楚：
Memory 不应该变成所有内容的垃圾桶。Context Pack 不应该盲目塞满 prompt。 进入 Agent 的上下文应该和当前任务有关。 如果 Memory 和 CodeGraph 冲突，不能直接靠记忆覆盖结构事实。 如果历史记忆不确定，应该进入审核或刷新，而不是静默当真。 Memory 保存长期项目知识。TaskGraph 保存项目推进过程。 Context Pack 把当前任务需要的信息组合起来。 CodeGraph 提供代码结构事实。 Evidence / Review 提供已验证或被拒绝的结果事实。
flowchart LR
A["Long-term Memory"] --> E["Context Pack"]
B["TaskGraph"] --> E
C["CodeGraph"] --> E
D["Evidence / Review"] --> E
F["Current Task Scope"] --> E
E --> G["Agent bounded context"]
它如何解决稳定性 Memory / Context Pack 带来的稳定性主要有五个：
长期稳定：重要架构原则不会因为换线程而丢失。 任务稳定：Agent 拿到的是当前任务相关上下文。 成本稳定：减少每次全量读取项目资料的 token 浪费。 判断稳定：上下文包 含已审核证据，而不只是模型猜测。 恢复稳定：中断后可以重新组装上下文继续推进。 边界 不能说 Memory 会自动保存所有知识，也不能说 Context Pack 一定包含全部相关信息。
更准确地说：
Memory / Context Pack 是上下文稳定机制，不是全知记忆。它能保存和组装项目事实，但哪些内容应该进入长期 Memory、哪些上下文和当前任务最相关，仍然需要规则、审核和人工判断。
边界
上下文包 不会让智能体全知，它只是降低上下文丢失和漂移。
← 返回上层机制: 安全执行 安全执行 / 执行包
Execution Packet 告诉执行者什么是被允许的。 它在执行前打包任务范围、限制、证据要求和预期结果。
执行包 是已批准任务到实际执行之间的交接。它避免智能体只拿到一句模糊自然语言命令。
它应该把 scope、非目标、证据要求和预期结果说明到足够后续审核。
完整机制说明
大白话功能说明 Execution Packet 是 CARVES 发给执行者的任务包。
Execution Packet 就是 Agent 开工前拿到的“施工单”：这次要做什么、只能改哪里、不能碰什么、完成后要交什么证据。
它解决的是：不要让 Agent 只凭一句聊天就直接动手。
它解决什么问题 普通 vibe coding 里，Agent 经常这样执行：
Execution Packet 解决的是：
执行前先把任务、范围、限制、验收和证据说清楚。
用户说一句目标，Agent 直接开始改。 Agent 不知道这次任务的准确边界。 改着改着顺手重构了无关模块。 做完只说“完成了”，没有证据要求。 换一个 Agent 接手时，不知道前一个 Agent 被要求做什么。 任务失败后，很难判断是执行错了，还是任务本身定义错了。 Execution Packet 负责什么 一份 Execution Packet 应该告诉执行者：
它的重点是：让执行者拿到的是任务合同，不是自由发挥空间。
当前任务是什么。 它来自哪个 Card / TaskGraph。 本次允许处理的 scope 是什么。 哪些文件或区域不能碰。 任务完成需要满足什么验收条件。 需要收集哪些证据。 应该运行哪些检查或测试。 如果发现范围不够，应该停止并要求 replan，而不是自己扩大范围。 亮点 Execution Packet 的亮点是：它把执行权变成带边界的授权。
Agent 仍然可以写代码，但它开工前必须知道：
这让 CARVES 有一个很重要的稳定性：
Worker 执行的是已批准任务，不是自由解释用户意图。
这次为什么做。 做到什么算够。 改哪里算越界。 凭什么证明完成。 失败时该停下来还是继续尝试。 关键技术说明 Execution Packet 通常由已批准任务编译而来，并结合多层项目事实：
关键点是：Packet 是执行入口，不是完成证明。
Execution Packet 可以告诉 Worker 怎么执行，但 Worker 返回结果后，仍然需要 Evidence、Guard 和 Review Gate 判断是否可以接受。
它和 TaskGraph 的关系是：
所以 Execution Packet 不是长期知识库，也不是最终任务状态。它是执行前的明确授权材料。
TaskGraph 保存任务推进状态。 Execution Packet 是某个任务在某次执行中的工作说明。 Worker Result 是执行结果。 Review Gate 决定结果能不能回写为完成。
flowchart LR
A["Approved Task"] --> E["Execution Packet"]
B["TaskGraph"] --> E
C["CodeGraph scope"] --> E
D["Memory / Context"] --> E
F["Acceptance / Evidence requirements"] --> E
E --> G["Worker / Agent"]
G --> H["Result + Evidence"]
它如何解决稳定性 Execution Packet 带来的稳定性主要有五个：
范围稳定：Worker 知道本次 task scope。 验收稳定：Worker 知道完成要满足什么。 证据稳定：Worker 知道需要提交什么证明。 交接稳定：换 Agent 时可以读回原始执行要求。 安全稳定：Worker 如果发现范围不够，应请求 replan，而不是自行扩大任务。 边界 不能说 Execution Packet 能保证执行一定正确。
更准确地说：
Execution Packet 只是执行前的任务合同。它能降低范围漂移和无证据执行的风险，但不能替代实际测试、代码审查、Guard 检查和最终审核。
← 返回上层机制: 安全执行 安全执行 / 工作区租约
Managed Workspace / Lease 降低项目污染。 它把执行绑定到任务和工作区，避免失败尝试直接污染主项目。
受控工作区是一种约束模式。智能体应尽量在受控区域或租约边界里工作，让失败尝试和任务残留不自动变成项目 truth。
这是项目卫生，不是操作系统级安全声明。
完整机制说明
大白话功能说明 Managed Workspace / Lease 是 CARVES 给 Agent 执行任务时准备的受控工作区和任务租约。
Managed Workspace 是让 Agent 在一个受控地方干活；Lease 是告诉系统“这个工作区现在属于哪个任务、谁在用、什么时候该交回”。
它解决的是：不要让 Agent 直接在主项目里随便施工。
它解决什么问题 普通 vibe coding 里，Agent 很容易直接改主目录：
Managed Workspace / Lease 解决的是：
把 Agent 的执行放进一个可追踪、可回收、可审核的工作区。
改错文件后很难回滚。 多个任务同时做会互相污染。 Agent 不知道哪些改动属于哪个任务。 任务失败后留下临时文件、半成品和脏状态。 用户很难判断哪些文件可以接受，哪些只是执行残留。 多个 Agent 或多线程工作时更容易冲突。 Managed Workspace 负责什么 Managed Workspace 负责给执行任务提供隔离空间。
它的作用包括：
它回答的是：
Agent 应该在哪里执行这次任务？
给某个任务准备独立工作区。 降低主项目被直接污染的风险。 让 patch、diff、artifact 更容易归属到任务。 让任务失败后可以清理或回收。 让执行结果先经过 review，再决定是否写回主线。 Lease 负责什么 Lease 是工作区的使用权记录。
它负责说明：
它回答的是：
这个工作区现在归谁负责，是否还能继续用？
哪个任务占用了这个 workspace。 谁或哪个 worker 正在使用它。 当前 lease 是否还有效。 工作区结果是否已经提交审核。 工作区是否可以清理、继续使用或释放。 是否存在过期、冲突或残留状态。 亮点 Managed Workspace / Lease 的亮点是：执行可以先隔离，结果再进入审核。
这让 CARVES 的执行流程更像专业开发流程：
先在受控分支或工作区里施工，再把结果提交给审核，而不是直接把主项目改成最终状态。
对 AI 编程来说，这非常关键。因为 Agent 执行速度快，但也容易越界、试错、留下残留。Managed Workspace 让这些过程不直接污染主项目。
关键技术说明 Managed Workspace / Lease 主要连接 TaskGraph、Execution Packet、Worker 和 Review Gate。
关键点是：workspace 里的执行结果不自动等于主项目结果。
Worker 可以在 workspace 里做改动，但这些改动需要被提交、审核、接受，才应该进入正式项目状态。
Lease 的关键价值是防止执行混乱：
没有 lease，就不知道谁在用这个工作区。 没有 lease，就不知道这个结果属于哪个任务。 没有 lease，就很难判断残留是要保留、提交还是清理。
flowchart LR
A["Approved Task"] --> B["Lease"]
B --> C["Managed Workspace"]
C --> D["Worker executes"]
D --> E["Patch / Diff / Artifacts"]
E --> F["Submit for Review"]
F --> G{"Review Gate"}
G -->|Accept| H["Writeback"]
G -->|Reject| I["Keep / Rework / Cleanup"]
G -->|Replan| J["Return to Planning"]
它如何解决稳定性 Managed Workspace / Lease 带来的稳定性主要有五个：
隔离稳定：Agent 执行不直接污染主项目。 归属稳定：每个工作区和任务绑定，结果有来源。 并行稳定：多个任务更容易区分边界和冲突。 恢复稳定：失败后可以判断保留、返工、清理或重规划。 审核稳定：结果先提交审核，再决定是否写回。 边界 不能说 Managed Workspace 能彻底消除所有风险。
更准确地说：
Managed Workspace / Lease 降低主项目污染、任务混淆和执行残留风险，但不能替代测试、Guard、Review 和人工判断。它提供的是受控执行空间，不是绝对安全沙箱。
边界
受控工作区不是 OS sandbox，也不是 syscall 级安全边界。
← 返回上层机制: 安全执行 安全执行 / Guard
Guard 检查补丁准入边界。 它在 work 进入 review 或 merge 前检查 patch、diff、path、budget 和 risk。
Guard 存在是因为小任务也可能漂移到无关文件、危险删除或超大改动。它判断 patch 应该 allow、review 还是 block。
Guard 不负责会话连续性，也不负责最终审核。它是本地证明路径里的补丁准入门。
Diff 边界。 路径与变更预算。 Allow / review / block。 完整机制说明
大白话功能说明 Guard 是 CARVES 对 AI 改动结果做边界检查的机制。
Guard 就像 AI 改代码后的安全检查员。它会看这次 patch 有没有越界、有没有危险删除、有没有碰不该碰的地方、有没有明显违反项目边界。
它解决的是：Agent 写得快，但不能让每个改动都无条件进入项目。
它解决什么问题 普通 AI 编程里经常会发生：
Guard 解决的是：
给 AI 的 patch 加一道边界和风险检查。
用户只让改一个小问题，Agent 顺手重构很多文件。 Agent 删除了文件，但没有合理替代。 patch 改到了任务 scope 外的区域。 AI 修改了配置、脚本、生成文件或敏感路径，却没有说明风险。 diff 太大，人类很难快速判断是否安全。 Agent 说“这是必要修改”，但没有边界证据。 Guard 负责什么 Guard 主要负责检查：
它回答的是：
这个 patch 看起来是否还在安全边界内？
这次改动是否超出任务范围。 是否删除了重要文件。 是否存在没有替代方案的删除。 是否触碰敏感路径或不该写入的区域。 diff 规模是否异常。 改动形状是否像无关重构。 是否需要人工强制审核。 亮点 Guard 的亮点是：它不判断代码一定正确，但能先判断改动是否危险或越界。
这点很重要。CARVES 不应该把 Guard 说成万能审查工具。Guard 更像第一道安全门：
它让 CARVES 有一个很重要的稳定性：
AI 的 patch 不能只因为“看起来能跑”就进入项目，还要先过边界检查。
它可以拦住明显越界。 它可以提示风险。 它可以要求人工 review。 它可以阻止无证据的大范围改动被轻易接受。 关键技术说明 Guard 通常工作在 diff / patch 层。
它不需要完全理解业务语义，也能检查很多高价值风险：
关键点是：Guard 是边界检查，不是最终验收。
Guard 可以告诉你 patch 是否有边界风险，但它不能替代测试、业务审查、人工判断或 Review Gate。
它和其他机制的关系是：
Execution Packet 给出任务范围。 Managed Workspace 产生 patch / diff。 Guard 检查 patch 是否越界或危险。Evidence 证明结果是否有效。 Review Gate 决定是否接受。
flowchart LR
A["Worker Patch / Diff"] --> B["Guard Check"]
C["Task Scope"] --> B
D["Path Policy"] --> B
E["Risk Rules"] --> B
B --> F{"Guard Decision"}
F -->|Pass| G["Review Gate"]
F -->|Warn| H["Human Review Required"]
F -->|Block| I["Reject / Replan"]
它如何解决稳定性 Guard 带来的稳定性主要有五个：
范围稳定：检查 patch 是否超出任务 scope。 删除稳定：拦截危险删除或无替代删除。 路径稳定：检查敏感路径和不该写入的区域。 审核稳定：高风险改动自动进入人工 review。 节奏稳定：避免 AI 一次性提交巨大、难审、难回滚的改动。 边界 不能说 Guard 能保证代码安全或没有 bug。
更准确地说：
Guard 是 patch 边界和风险检查，不是完整安全审计，也不是业务正确性证明。它能降低越界修改、危险删除和无关重构进入项目的风险，但最终仍需要测试、证据和审核。
边界
Guard 不是实时写入阻止、自动回滚或 OS sandbox。
← 返回上层机制: 证据验收 证据验收 / Evidence
Evidence 是结果背后的材料。 它记录 diff、测试、日志、artifact、运行输出或说明，让审核有东西可检查。
证据让完成不再只是感觉。它告诉人类改了什么、怎么检查、凭什么可以继续。
证据可以轻量，但聊天消失后仍然应该能读回。
Diff 或改动摘要。 测试或运行输出。 Artifact 或证明引用。 完整机制说明
大白话功能说明 Evidence 是 CARVES 用来记录“凭什么说这个任务完成了”的证明材料。
Evidence 就是 AI 交作业时必须附上的证据：它改了什么、跑了什么、结果是什么、为什么这个结果可以被相信。
它解决的是：AI 不能只交结论，还要交证明。
它解决什么问题 普通 AI 编程里经常出现：
Evidence 解决的是：
让每个结果都有可读回、可引用、可审核的证明材料。
Agent 说完成，但没有测试。 Agent 说修好了，但没有复现或验证说明。 用户只看到最终回答，看不到过程证据。 后续 Agent 不知道前一个任务为什么被接受。 审核时只能重新打开 diff 和日志慢慢查。 任务失败后没有证据链，无法判断该返工还是重规划。 Evidence 负责什么 Evidence 负责保存或引用任务结果的证明：
它回答的是：
这个结果凭什么可信？
改动摘要。 patch / diff。 测试命令和测试结果。 构建结果。 运行日志。 截图、报告或 artifact。 失败原因。 人工检查说明。 与任务验收条件对应的证明。 亮点 Evidence 的亮点是：它把 AI 的完成声明变成可检查材料。
CARVES 不要求每个任务都必须有复杂证明，但至少要让完成状态有依据。
Evidence 的价值不是“证明永远正确”，而是让项目有审计线索：
这让 CARVES 有一个很重要的稳定性：
项目不是靠 Agent 自信推进，而是靠可检查证据推进。
以后可以读回。 审核可以引用。 返工可以定位。 新 Agent 可以接上。 人类可以判断是否接受。 关键技术说明 Evidence 通常不是塞进 TaskGraph 正文，而是作为 artifact / reference 被 TaskGraph、Review 或 Handoff 引用。
关键点是：Evidence 应该可引用，不应该把所有内容塞进任务状态里。
这样可以避免 TaskGraph 或 Memory 变成庞大的证据堆，同时保留可追溯性。
Evidence 和其他机制的关系：
Worker Result 产生候选结果。 Evidence 保存证明材料。Shield 可以对证据做本地自检。 Review Gate 判断证据是否支撑验收。 TaskGraph 记录任务状态，并引用证据。 Handoff 在交接时引用关键证据。
flowchart LR
A["Worker Result"] --> B["Evidence Artifact"]
B --> C["Review Gate"]
B --> D["TaskGraph refs"]
B --> E["Handoff refs"]
C --> F{"Decision"}
F -->|Accept| G["Accepted Evidence"]
F -->|Reject| H["Rework Evidence"]
F -->|Replan| I["Planning Evidence"]
它如何解决稳定性 Evidence 带来的稳定性主要有五个：
验收稳定：任务完成有证明，不靠一句话。 追溯稳定：后续可以查看为什么当时接受。 返工稳定：失败证据帮助判断是修复、重试还是重规划。 交接稳定：换 Agent 时可以读回关键证明。 信任稳定：人类可以看到判断依据，而不是只信 AI 语气。 边界 不能说 Evidence 能证明结果绝对正确。
更准确地说：
Evidence 是验收依据，不是绝对真理。它能提高可检查性和可追溯性，但是否足够支持任务完成，仍然需要 Review Gate、测试、人工判断或后续审计。
← 返回上层机制: 证据验收 证据验收 / Review Gate
Review Gate 决定结果如何处理。 它把 worker result 转成 accept、reject、replan、block 或 reopen，并记录原因。
审核关口是人类控制点回来的地方。Worker 可以交候选结果，但是否接受由审核决定。
拒绝和重排应留下原因，让下一轮不要盲目重复旧路线。
完整机制说明
大白话功能说明 Review Gate 是 CARVES 的任务验收闸门。
AI 可以交结果，但不能自己宣布“完成”。结果必须先带着 Evidence 进入 Review Gate ，由它判断：接受、拒绝、返工、重规划，还是标记为阻塞。
它解决的是：不要让 Agent 自己给自己盖章。
它解决什么问题 普通 vibe coding 里经常出现：
Review Gate 解决的是：
让“完成”变成一个明确的审核决定，而不是 Agent 的自信表达。
Agent 说完成，但证据不够。 代码确实改了，但没有满足任务验收条件。 测试没跑，任务状态却被推进了。 patch 有风险，但被包装成“已经完成”。 失败结果没有明确返工原因。 任务明明需要重规划，却被 Agent 继续硬修。 后续 Agent 不知道为什么上一次结果被接受或拒绝。 Review Gate 负责什么 Review Gate 负责在结果写回之前做验收判断：
它回答的是：
这个结果是否已经足够可信，可以进入下一步？
检查结果是否对应任务目标。 检查 Evidence 是否足够支撑验收。 检查 Guard / Shield 给出的边界与证据信号。 判断是否可以接受。 判断是否需要拒绝、返工、重规划或阻塞。 记录审核原因，供后续交接和追溯使用。 亮点 Review Gate 的亮点是：它把完成权从 Agent 手里拿回来，交给证据和审核。
在 CARVES 里，Worker 的结果只是候选结果。它可以很有用，但不能直接成为项目 truth。
Review Gate 会把结果放到一个明确的判断点：
这让 CARVES 有一个很重要的稳定性：
项目不是靠 Agent 自己宣布完成来推进，而是靠可检查的审核决定推进。
证据够不够。 范围有没有越界。 是否满足验收条件。 是否应该返工。 是否应该重规划。 是否需要人工介入。 关键技术说明 Review Gate 位于 Worker Result -> Evidence -> Truth Writeback 之间。
关键点是：Worker result 是候选结果，Review Gate 才决定状态。
Review Gate 通常不应该把所有 Evidence 正文塞进任务状态里。更好的方式是记录审核结论、原因、状态，以及相关 evidence references。
它和其他机制的关系是：
Worker Result 提交候选结果。 Evidence 提供证明材料。 Guard 检查 patch 是否越界或危险。 Shield 对证据质量做本地自检。 Review Gate 做最终验收判断。TaskGraph 根据审核结果更新任务推进状态。
flowchart LR
A["Worker Result"] --> B["Evidence"]
C["Guard / Shield"] --> D["Review Gate"]
B --> D
D --> E{"Decision"}
E -->|Accept| F["Writeback as accepted"]
E -->|Reject| G["Reject / Rework"]
E -->|Replan| H["Back to planning"]
E -->|Block| I["Mark blocked"]
它如何解决稳定性 Review Gate 带来的稳定性主要有五个：
结果稳定：完成状态必须经过审核判断。 决策稳定：accept / reject / replan / block 有明确原因。 返工稳定：失败不是混在聊天里，而是形成可读回的审核结论。 追溯稳定：后续可以知道为什么当时接受或拒绝。 控制稳定：AI 可以执行，但不能自己批准自己。 边界 不能说 Review Gate 能保证结果绝对正确。
更准确地说：
Review Gate 不是完整 QA、安全审计或专业代码审查的替代品。它的价值是让“完成”这件事变成可检查、可追溯、可拒绝的明确决策。
边界
审核关口不能替代专业代码审查、QA 或人类判断。
← 返回上层机制: 证据验收 证据验收 / Shield
Shield 是本地治理自检。 它读取摘要证据，输出 Guard / Handoff / Audit 维度、Lite 分数和 badge。
Shield 让工作流治理可见。它检查项目是否有边界检查、交接和审计读回的基本证据。
用户可以看到当前治理证据，不需要默认上传源码、raw diff、prompt、模型输出、密钥或凭据。
Standard G/H/A 维度。 Lite 分数。 本地 badge 输出。 完整机制说明
大白话功能说明 Shield 是 CARVES 的本地治理自检。
大白话说，它像一份“AI 项目治理体检报告”：它不看你代码写得多漂亮，而是看这个项目有没有基本的 AI 工作流治理证据，例如边界检查、交接记录、审核记录和证据链。
它解决的是：用户不只想知道 AI 有没有写代码，还想知道这个项目的 AI 工作流到底稳不稳。
它解决什么问题 普通 AI 编程里经常出现：
Shield 解决的是：
把分散的治理证据变成一个可读、可复查、可展示的本地自检结果。
项目用了很多 AI，但没有办法证明过程是否可控。 有 patch，但不知道有没有边界检查。 有聊天记录，但不知道能不能交接。 有历史记录，但不知道能不能审计。 有结果，但没有一个简单指标让用户快速理解治理状态。 项目看起来在推进，但无法向别人展示“我们是怎么控制 AI 风险的”。 Shield 负责什么 Shield 负责读取 summary evidence，并输出治理自检结果：
它回答的是：
这个项目有没有足够的 AI 工作流治理证据？
读取 shield -evidence.v0。 评估 Guard 维度。 评估 Handoff 维度。 评估 Audit 维度。 输出 Standard G/H/A 结果。 输出 Lite 分数。 输出 badge。 保持本地优先，不默认上传源码、raw diff、prompt、模型输出或密钥。 亮点 Shield 的亮点是：它把“项目治理得怎么样”变成一个用户能读懂的自检结果。
Guard、Handoff、Audit 各自都有作用，但用户需要一个更容易判断的结果：
Shield 不把自己包装成认证平台。它更适合作为一个本地自检层：
这让 CARVES 有一个很重要的稳定性：
项目不是只靠“我相信 AI 做得对”，而是可以展示“我有治理证据，而且这些证据能被本地检查”。
边界检查有没有做。 交接记录是否存在。 历史证据是否能读回。 项目是否能生成可展示的治理标签。 可以快速发现治理缺口。 可以给开源项目展示基础治理状态。 可以给团队一个低成本的风险沟通入口。 可以让用户知道自己下一步应该补什么证据。 关键技术说明 Shield 的默认输入是 shield-evidence.v0。
它不直接读取所有源码、raw diff 或聊天记录，而是读取由 Guard、Handoff、Audit 等机制汇总出来的 summary evidence。
关键点是：Shield 是 evidence evaluator，不是源码审查器。
它和其他机制的关系是：
Guard 提供 patch 边界治理证据。 Handoff 提供交接连续性证据。 Audit 提供历史读回和证据发现。 Shield 读取 shield-evidence.v0，输出 Standard / Lite / badge。Matrix 可以把 Guard -> Handoff -> Audit -> Shield 串成 proof lane，但不拥有 Shield scoring。
flowchart LR
A["Guard Evidence"] --> D["shield-evidence.v0"]
B["Handoff Evidence"] --> D
C["Audit Evidence"] --> D
D --> E["Shield Evaluate"]
E --> F["Standard G/H/A"]
E --> G["Lite Score"]
E --> H["Badge"]
它如何解决稳定性 Shield 带来的稳定性主要有五个：
展示稳定：用户可以看到项目治理状态，而不是只看聊天结果。 治理稳定：Guard、Handoff、Audit 的证据被汇总成统一入口。 交付稳定：badge 和 Lite 分数让外部读者更容易理解项目状态。 隐私稳定：默认本地自检，不需要上传源码、raw diff、prompt 或密钥。 边界稳定：明确声明 self-check，不夸大成认证、安全证明或代码正确性证明。 边界 不能说 Shield 是认证平台、安全审计、源码审查、模型安全评分或代码正确性证明。
更准确地说：
Shield 是 local-first self-check。它能帮助用户检查和展示 AI 工作流治理证据，但不能证明项目没有 bug，不能替代专业代码审查，也不能把本地自检结果包装成第三方认证。
边界
Shield 不是认证、模型安全评分、源码审计或语义正确性证明。
← 返回上层机制: 不断线交接 不断线交接 / 接入握手
Attach Handshake 记录项目怎么接上的。 它记录 attach request 和 acknowledgement，让下一位智能体不用猜要不要重新 init。
Attach Handshake 把“项目已接上 CARVES”变成可读事实。它可以记录目标 repo、git root、runtime root、host session、attach status 和 attached time。
这是连续性的第一层：项目可以证明自己已经被 CARVES attach 路径接住。
Attach status。 Runtime root 提示。 Host session 和 attached time。 完整机制说明
大白话功能说明 Attach Handshake 是 CARVES 的“接入握手 ”。
大白话说，它记录的是：这个项目什么时候、通过哪个 Runtime、以什么状态接上了 CARVES。
它解决的是：下一个 Agent 进入项目时，不需要猜这个项目有没有接上 CARVES，也不需要猜是不是应该重新 init。
它解决什么问题 普通 AI 项目接入里经常出现：
Attach Handshake 解决的是：
让“项目已经接上 CARVES”变成可读回的接入事实。
Agent 不知道这个项目是否已经接上 CARVES。 用户已经 init 过，但下个 Agent 又想重新初始化。 项目文件里有 .ai/，但不知道它是怎么来的。 Agent 不知道当前接入用的是哪个 Runtime root。 Runtime 文档根和目标项目根容易混在一起。 迁移到本地 dist 或新 Runtime 时，接入来源不清楚。 Attach Handshake 负责什么 Attach Handshake 负责记录一次接入的请求与确认。
典型文件：
.ai/runtime/attach-handshake.json
它通常包含两类信息：
request 可以记录目标 repo、git root、branch、client version、runtime version、client repo root、runtime root。
acknowledgement 可以记录 repo id、host session id、attach status、attached time、runtime status、repo summary、attach mode。
它回答的是：
这个项目是否已经通过 CARVES 的接入路径被接住？
request：这次接入从哪里来。 acknowledgement：CARVES 接住后的结果。 亮点 Attach Handshake 的亮点是：它把“项目已接入 CARVES”从口头状态变成可检查文件。
这对外部 Agent 很重要。因为 Agent 不应该靠猜测决定是否重新初始化，也不应该手动拼接 Runtime 文档根。
Attach Handshake 可以帮助 Agent 判断：
这让 CARVES 有一个很重要的稳定性：
项目接入状态可以被读回，而不是每个新会话重新猜。
这个项目是否已经 attach。 attach 是什么时候发生的。 attach 时指向哪个 Runtime。 接入是否由 Host 接住。 后续文档根解析是否可以从 handshake 开始。 关键技术说明 Attach Handshake 位于 carves init / attach 之后，是不断线交接的第一层。
关键点是：Attach Handshake 记录接入事实，不记录项目计划。
它和其他机制的关系是：
carves init / attach 触发接入。 Host 接住接入请求。 Attach Handshake 记录接入请求和接入确认。 Runtime Manifest 记录更长期的 Runtime 绑定。 Handoff Packet 记录下一次会话如何继续。
flowchart LR
A["carves init / attach"] --> B["Attach Request"]
B --> C["CARVES Host"]
C --> D["Attach Acknowledgement"]
D --> E["attach-handshake.json"]
E --> F["Next Agent Confirms Project Is Attached"]
它如何解决稳定性 Attach Handshake 带来的稳定性主要有五个：
接入稳定：项目是否接上 CARVES 有记录可查。 入口稳定：接入时使用的 Runtime root 有记录。 会话稳定：下一个 Agent 不需要重新猜接入状态。 初始化稳定：避免重复 init 或误判未接入。 边界稳定：目标项目和 Runtime 文档根更容易区分。 边界 不能说 Attach Handshake 是项目计划、任务进度、长期记忆或审核证据。
更准确地说：
Attach Handshake 只记录接入关系和接入来源。不要手动修改它来 retarget Runtime；需要更换 Runtime 绑定时，应该走 CARVES 的正式 init / attach / dist-binding 路径。
边界
Attach Handshake 不是项目计划、任务进度或审核证据。
← 返回上层机制: 不断线交接 不断线交接 / Runtime Manifest
Runtime Manifest 记录运行时绑定。 它告诉目标项目应该解析回哪个 CARVES Runtime。
Runtime Manifest 是更长期的绑定记录。它帮助 CLI、Host 和智能体入口找到 Runtime root、runtime version、client version 和绑定状态。
目标项目保持自己的项目 truth；manifest 只在需要时指回 CARVES 规则和文档。
Runtime root。 版本和 session 元数据。 Handshake 不可用时 fallback。 完整机制说明
大白话功能说明 Runtime Manifest 是 CARVES 在目标项目里的“Runtime 绑定记录”。
大白话说，Attach Handshake 记录“这个项目是怎么接上的”，Runtime Manifest 记录“这个项目现在应该找哪个 Runtime”。
它更像一张长期绑定卡，让下一个 Agent、CLI 或 Host 知道当前项目的 CARVES 运行时来源。
它解决什么问题 普通 AI 项目接入里经常出现：
Runtime Manifest 解决的是：
让目标项目可以长期读回它绑定到哪个 CARVES Runtime。
项目已经接上工具，但下次打开不知道该找哪个工具根目录。 目标项目复制了太多工具文档，导致项目 truth 和工具 truth 混在一起。 Agent 不知道 Runtime 版本、Runtime root 或 host session。 Attach Handshake 不可用时，没有 fallback 可以解析 Runtime 文档根。 用户换成本地 dist 后，目标项目绑定关系不清楚。 Agent 手动猜路径，容易把目标项目根和 Runtime 根搞混。 Runtime Manifest 负责什么 Runtime Manifest 负责记录目标项目和 Runtime 的绑定关系。
典型文件：
.ai/runtime.json
它通常记录：
它回答的是：
这个目标项目当前应该回到哪个 CARVES Runtime？
repo_id repo_path git_root runtime_root active_branch runtime_version client_version host_session_id runtime_status repo_summary state created_at last_attached_at last_repair_at 亮点 Runtime Manifest 的亮点是：它让 Runtime 入口变成目标项目可以读回的绑定事实。
这点很重要。目标项目不需要复制 Runtime 文档，也不应该把 Runtime 规则当成自己的项目文件来维护。
Runtime Manifest 可以帮助 CARVES 判断：
这让 CARVES 有一个很重要的稳定性：
目标项目可以保持自己的项目 truth，同时通过 manifest 找回 Runtime 的规则、文档和控制面。
目标项目绑定的 Runtime root。 当前绑定是否健康、脏、或需要修复。 当前项目的 Runtime 版本和 client version。 当 Attach Handshake 不可用时，是否可以用 manifest fallback 解析 Runtime 文档根。 关键技术说明 Runtime Manifest 是不断线交接的第二层。
关键点是：Runtime Manifest 记录 Runtime 绑定，不记录任务进度。
在 attached target repo 里，CARVES 可以通过 runtime_document_root_mode 判断文档根来源：
它和其他机制的关系是：
attach_handshake_runtime_root：优先从 attach handshake 解析 Runtime root。 runtime_manifest_root：当 handshake 不可用时，从 Runtime Manifest fallback。 Attach Handshake 记录接入发生过。 Runtime Manifest 记录长期 Runtime 绑定。Handoff Packet 记录下一次会话如何继续。 Agent Start / Handoff Readback 可以基于 manifest 找回 Runtime 文档根。
flowchart LR
A["Target Repo"] --> B[".ai/runtime.json"]
B --> C["Resolve Runtime Root"]
C --> D["Load Runtime Docs / Rules"]
C --> E["Host / CLI Readiness"]
C --> F["Agent Handoff Readback"]
它如何解决稳定性 Runtime Manifest 带来的稳定性主要有五个：
入口稳定：目标项目知道应该找哪个 Runtime。 文档稳定：Runtime 文档根不需要复制进目标项目。 绑定稳定：Runtime root、版本、host session 等信息可读回。 修复稳定：绑定状态可以标记为 healthy、dirty 或 repairing。 fallback 稳定：handshake 不可用时仍可用 manifest 找回 Runtime root。 边界 不能说 Runtime Manifest 是任务 truth、项目计划、Memory、Evidence 或用户应该手写的配置。
更准确地说：
Runtime Manifest 只记录目标项目和 Runtime 的绑定关系。不要手动编辑 .ai/runtime.json 来切换 Runtime；需要 retarget 时应该走 CARVES 的正式 dist-binding / init / attach 路径。
边界
Runtime Manifest 记录 Runtime 绑定，不记录任务进度。
← 返回上层机制: 不断线交接 不断线交接 / 交接包
Handoff Packet 告诉下一次会话从哪里继续。 它保存当前目标、已完成事实、剩余工作、阻塞点、证据引用和下一步。
Handoff Packet 是真正的会话连续性交接包 。它让下一位人类或智能体知道工作停在哪里，以及下一步应该做什么。
它降低重启成本，但不假装自己是万能记忆数据库或规划器。
完整机制说明
大白话功能说明 Handoff Packet 是 CARVES 的“会话交接单”。
大白话说，它告诉下一个 Agent：当前目标是什么、哪些事实已经完成、证据在哪里、剩下什么、哪些坑不要再踩、下一步应该怎么开始。
它解决的是：线程断了、Agent 换了、隔几天再回来，下一次工作仍然可以从已有事实继续。
它解决什么问题 普通 vibe coding 里经常出现：
Handoff Packet 解决的是：
把上一个会话的关键交接压成结构化、可检查、可读回的 packet。
下一个 Agent 不知道上一个会话做到哪里。 已经完成的事实没有证据引用。 已经试错过的路径又被重复尝试。 上一次拒绝的方案在新会话里又被重开。 剩余工作散在聊天记录里，无法稳定读回。 会话结束后没有明确的继续、停止、重定位或人工确认状态。 Handoff Packet 负责什么 Handoff Packet 负责记录下一次会话需要接住的信息。
典型路径：
.ai/handoff/handoff.json
它通常记录：
它回答的是：
下一个 Agent 应该从哪里继续，或者是否应该先停止、重定位、找人确认？
current_objective completed_facts remaining_work must_not_repeat context_refs decision_refs confidence freshness resume_status 亮点 Handoff Packet 的亮点是：它把“上个会话发生了什么”压成可检查的结构化事实，而不是依赖聊天记录。
下一个 Agent 不需要猜，它可以先读 packet，再决定：
这让 CARVES 有一个很重要的稳定性：
AI 项目可以跨会话继续推进，而不是靠聊天上下文续命。
是否可以继续。 是否需要重新定位。 是否已经完成，不需要继续。 是否被阻塞，需要找人确认。 哪些事实已经完成，并且证据在哪里。 哪些坑不要重复。 关键技术说明 Handoff Packet 是不断线交接的第三层。
关键点是：Handoff Packet 记录会话连续性，不记录任务 truth。
它和其他机制的关系是：
Attach Handshake 证明项目已经接上 CARVES。 Runtime Manifest 证明项目应该找哪个 Runtime。 Handoff Packet 证明下一次会话应该从哪里继续。 Evidence 为完成事实提供证据引用。 Review Gate 决定结果是否被接受。 TaskGraph 记录项目推进状态，不由 Handoff Packet 替代。
flowchart LR
A["Outgoing Session"] --> B["Handoff Packet"]
B --> C["Inspect Packet"]
C --> D{"Resume Status"}
D -->|ready| E["Next Agent Continues"]
D -->|stale| F["Reorient First"]
D -->|blocked| G["Ask Human / Stop"]
D -->|done| H["No Next Action"]
它如何解决稳定性 Handoff Packet 带来的稳定性主要有五个：
会话稳定：换线程后仍能读回当前目标和剩余工作。 事实稳定：完成事实可以带证据引用。 返工稳定：必须避免重复的坑可以明确写出。 判断稳定：ready、stale、blocked、done 等状态让下个 Agent 不乱接。 协作稳定：人类和 Agent 都能看到下一步应该怎么开始。 边界 不能说 Handoff Packet 是 Planner、长期 Memory、安全准入门或任务 truth。
更准确地说：
Handoff Packet 只负责会话交接。它不拥有 Guard、Audit、TaskGraph 或 Review truth，也不自动决定任务应不应该执行。
边界
Handoff Packet 不是独立记忆库、规划权威或最终 truth。
← 返回上层机制: 可审计闭环 可审计闭环 / Audit
Audit 是只读历史和证据发现。 它读取 Guard 和 Handoff 记录，输出 summary、timeline、explain 和 Shield evidence。
Audit 帮用户在多轮 AI 工作后回头查。它可以汇总 Guard decisions、发现 Handoff packets、解释记录，并为 Shield 生成隐私友好的摘要证据。
它的价值来自只读：发现证据，但不发明或修改 truth。
Summary。 Timeline。 Explain。 shield-evidence.v0。 完整机制说明
大白话功能说明 Audit 是 CARVES 的“历史读回”和“证据发现”机制。
大白话说，它不是负责改代码，也不是负责打分。它负责回头查：之前有哪些 Guard 决策、有没有 Handoff 交接单、这些记录能不能生成摘要、时间线、解释，以及能不能整理成 Shield 可以读取的 shield-evidence.v0。
它解决的是：AI 项目做过很多事之后，用户不能只靠聊天记录复盘。
它解决什么问题 普通 vibe coding 里经常出现：
Audit 解决的是：
用只读方式发现历史证据，并生成可读回、可解释、可交给 Shield 的摘要证据。
历史决策散在聊天里，之后很难读回。 Guard 记录和 Handoff 记录存在，但用户不知道怎么查。 想知道某次 allow / review / block 的来源，却没有 explain 入口。 想生成治理自检证据，但不想上传源码、raw diff、prompt 或模型回复。 历史日志太大，直接全文读取成本高、风险高。 证据语义被夸大，把“看到了记录”说成“证明了完整审计”。 Audit 负责什么 Audit 负责读取已有治理记录，并生成读回结果。
默认输入通常是：
.ai/runtime/guard/decisions.jsonl .ai/handoff/handoff.json
它可以输出：
它回答的是：
过去发生过什么？这些记录能不能被读回、解释，并整理成后续自检可用的证据？
summary timeline explain shield-evidence.v0 亮点 Audit 的亮点是：它是只读层。
它不修改 Guard truth，不改 Handoff packet，也不替 Shield 打分。这让它适合作为安全的历史读回入口。
Audit 可以帮助用户看到：
这让 CARVES 有一个很重要的稳定性：
历史记录不是沉在文件里，而是能被读回、解释和交给后续 proof 链条。
Guard 最近允许、要求复查、还是阻止了哪些变更。 当前仓库有没有可用的 Handoff packet。 某个 Guard run id 或 Handoff id 的来源和状态。 当前项目能不能生成安全的 Shield 摘要证据。 关键技术说明 Audit 是可审计闭环的第一层：历史读回。
关键点是：Audit 只发现证据，不发明证据。
技术上需要注意：
Audit 默认读取 Guard decisions 和 Handoff packet。summary 负责聚合当前可见状态。 timeline 负责按时间展示可读记录。 explain 负责解释某个 Guard run id 或 Handoff id。 evidence 负责输出隐私安全的 shield-evidence.v0。 大型 Guard JSONL 历史只保留有界尾部，避免无限读取。 CI evidence 是启发式 workflow 文本检测，不是托管 CI 实际运行证明。 没有明确来源时，不会伪造 append-only、explain coverage、summary report、change report 或 failure-pattern report 这类高信任声明。
flowchart LR
A["Guard decisions"] --> C["Audit"]
B["Handoff packet"] --> C
C --> D["Summary"]
C --> E["Timeline"]
C --> F["Explain"]
C --> G["shield-evidence.v0"]
G --> H["Shield"]
它如何解决稳定性 Audit 带来的稳定性主要有五个：
读回稳定：历史 Guard / Handoff 记录可以被 summary、timeline、explain 读取。 证据稳定：可以生成 Shield 使用的摘要证据。 隐私稳定：默认不包含源码、raw diff、prompt、模型回复、secret 或 credential。 成本稳定：大日志读取有边界，不默认无限加载。 语义稳定：证据不足时保守输出，不夸大治理成熟度。 边界 不能说 Audit 是认证、评分器、代码审查、truth writer 或完整审计证明。
更准确地说：
Audit 是只读证据发现层。它能发现、汇总、解释已有记录，并生成后续 Shield / Matrix 可用的摘要证据，但不修改记录、不替 Shield 打分，也不证明代码绝对正确。
边界
Audit 不打分、不认证，也不修改 Guard / Handoff truth。
← 返回上层机制: 可审计闭环 可审计闭环 / Matrix
Matrix 证明本地组合路径。 它编排 Guard -> Handoff -> Audit -> Shield，并记录仅摘要的 proof artifacts。
Matrix 展示四个 peer modules 可以在普通本地仓库里组合工作。它记录 artifact manifest、proof summary 和 verification reason codes。
Matrix 的意义是 proof chain 可以被运行和检查，而不是只写在文档里。
本地 proof lane。 Artifact manifest。 仅摘要 bundle。 完整机制说明
大白话功能说明 Matrix 是 CARVES 的“组合证明层”。
大白话说，Guard、Handoff、Audit、Shield 各自都有用，但用户还需要知道：这些东西能不能串起来跑通。Matrix 就是把它们组成一条本地 proof lane，证明 CARVES 的治理工具链可以组合工作。
它解决的是：单个工具有输出，不等于整条治理链路是连起来的。
它解决什么问题 普通 AI 工具链里经常出现：
Matrix 解决的是：
把 Guard -> Handoff -> Audit -> Shield 这条本地治理链路组成 summary-only proof bundle，并提供 verify readback。
每个工具都能单独跑，但不知道能不能组成闭环。 Guard 有 decision，Handoff 有 packet，Audit 有 summary，Shield 有 badge，但缺少统一 proof。 用户不知道这些 artifact 之间有没有 provenance 关系。 proof 输出可能混入 private path、raw diff、prompt 或其他不该公开的信息。 本地结果被误包装成 hosted verification 或 certification。 Matrix 负责什么 Matrix 负责本地组合证明。
它可以记录和验证：
它回答的是：
这些本地治理 artifact 是否能按边界组成一条可读回的 proof 链？
Guard decision。 Handoff packet。 Audit summary。 Shield evidence。 Shield evaluation。 Shield badge。 Matrix summary。Artifact manifest。 亮点 Matrix 的亮点是：它是组合层，不是第五个治理引擎。
它不重写 Guard 规则，不拥有 Handoff truth，不替 Audit 发现证据，不重新计算 Shield 分数。
Matrix 的价值是把这些已经存在的工具链起来：
这让 CARVES 有一个很重要的稳定性：
用户可以验证治理链条是否串起来，而不是只相信单点输出。
Guard 负责 patch 边界。 Handoff 负责会话交接。 Audit 负责历史读回和证据发现。 Shield 负责本地治理自检标签。 Matrix 负责证明这些 artifact 能组合成一条本地 proof lane。 关键技术说明 Matrix 是可审计闭环的第二层：组合证明。
关键点是：Matrix 记录组合 proof，不拥有各子系统 truth。
技术上需要注意：
carves-matrix proof 生成本地 proof bundle。 carves-matrix verify 读取已有 bundle 做验证，不重跑 Guard / Handoff / Audit / Shield。 Matrix proof 默认走 summary-first，不需要上传源码、raw diff、prompt、模型回复、secret 或 credential。Matrix proof output 可以记录 Shield evidence、Shield evaluation、badge JSON、badge SVG 和 manifest provenance。matrix -proof-summary.json 是封闭公共读回 contract，未知 public field 会失败，避免私有信息混入 public proof summary。Matrix verify 会通过 manifest-bound verified reads 读取摘要和 Shield evaluation，再信任 public fields。
flowchart LR
A["Guard"] --> B["Handoff"]
B --> C["Audit"]
C --> D["shield-evidence.v0"]
D --> E["Shield"]
E --> F["Matrix Proof"]
F --> G["Matrix Verify"]
它如何解决稳定性 Matrix 带来的稳定性主要有五个：
组合稳定：证明 Guard / Handoff / Audit / Shield 可以按边界串起来。 读回稳定：proof summary 和 artifact manifest 让结果可复查。 隐私稳定：默认 summary-only，不要求上传源码或 raw diff。 边界稳定：Matrix 不接管子系统业务逻辑。 验证稳定：verify 读取已有 bundle，不通过重跑工具来掩盖 artifact 问题。 边界 不能说 Matrix 是认证、hosted verification、代码正确性证明、模型安全评分或第五个治理引擎。
更准确地说：
Matrix 是 local-first summary-only composition proof。它证明本地治理 artifact 可以组合和验证，但不证明代码绝对正确，不替代人工 review，也不把本地 proof 变成第三方认证。
边界
Matrix 不是第五个安全引擎、上传服务或认证系统。
← 返回上层机制: 可审计闭环 可审计闭环 / 提交卫生
Commit hygiene 区分项目输出和本地 residue。 它帮助判断哪些路径应该进 git，哪些只是本地 residue 或需要人工 review。
AI 项目经常以 dirty worktree 收尾。提交卫生 防止临时文件、工具残留和未分类路径被 git add . 一起扫进去。
它让最终状态可检查：什么是项目 truth、什么是目标输出、什么是 residue、什么仍需人工 review。
Dirty path 分类。 Commit plan。 Closure boundary。 边界
提交卫生 不替代人类是否 commit 的决定。