feat(native): make Supervisor parent changes integration-first and user-readable

[benym]

🔎 Existing issue check

• I have searched the existing issues.

这是 #299 的后续改进，不重新申请父子 Change、依赖关系、readyChildren 或父级最终 Verify 的基础能力。

• feat(native): support parent changes with ordered and parallel child changes #299 已实现父子 Change 的最小编排。
• feat(dashboard): show worktree changes and Native parent-child hierarchy #301 已覆盖 Dashboard 的跨 worktree 发现与父子层级。
• feat(workspace): prepare and route parallel changes before binding #302 已覆盖普通并行 Change 的 worktree 准备和路由。
• Question: 边界设计问题-Archive 发现本机 Runtime overlay 在归档边界不可复用，因此 Comet 按规则把状态退回 Verify，要求对同一候选重新生成 Runtime receipts。 #313 继续单独跟踪 Archive 预览导致可移植状态（Portable State）与本机 Runtime 不一致、重复 Verify 的具体缺陷；本 Issue 不重复实现该修复。

本 Issue 将 Supervisor 升级为 integration-first、可选多 Agent 加速的 Native 父级模式：

Runtime 管依赖、工作区、验证事实、串行集成和恢复；宿主只负责派发 Agent。多 Agent 可用时并行，不可用时按相同 Runtime 语义顺序执行。

它不是新的 Agent Team、通用 DAG 平台或 worker scheduler。

🧭 Problem

在 beta20 使用 self-evolving-memory-team-contracts 父级 Change 实际推进插件运行时、个人记忆、项目规则、Dashboard 和宿主接入时，当前 Supervisor 模式证明了独立 worktree、依赖顺序、Child 独立 Verify 和父级最终 Verify 的价值，但也暴露出明显的用户体验和 Runtime 建模问题。

1. “已集成”和“已归档”被合并成一个状态

当前 Child 只有完成 Archive 并合入父分支后才算 done。这导致：

• Child 已被移动到 Archive，但父级仍然活跃；
• 每个 Child 都触发一次 Archive、merge、目标工作区 clean 检查和父级刷新；
• unrelated dirty files 会反复阻塞 Child 收尾，而不是只在父级最终交付时检查一次；
• 用户无法区分“实现和独立验证已经完成”“已经进入父级集成结果”和“整个需求已经交付”。

2. 父级直接使用真实目标分支作为集成分支

本次父级的 change branch 与 target branch 都是 beta20。前四个 Child 合入后，父级第一次整体验证仍有 169/333 项失败，但真实目标分支已经包含不完整的组合结果。随后又追加 memory-rules-host-integration-repair 才完成宿主接入。

父级需要一个专用 integration branch/worktree。Child 只能合入该集成分支；父级整体验证通过前，真实目标分支不应发生变化。

3. 用户能力、实施 Child 和验收映射混在一起

本次父级有 3 个目标 Spec、多个领域 Child、横向集成 Child 和修复 Child。这个数量差异本身合理：Spec 描述用户能力，Dashboard、Skill/CLI 或宿主接入可以是横向实施工作。

但当前 children.yaml 使用位置型 A1...An 和逐项 covers。最终归档文件达到 546 行，512 条覆盖记录只对应 333 个唯一验收项。大量映射没有避免宿主接入遗漏，反而增加了维护、上下文和输出成本。

4. 多 Agent 目前只是 Skill 约定，不是稳定交接

当前 Skill 已要求支持时并行推进 readyChildren，不支持时顺序执行，但 Runtime 只提供 Child 列表和派生状态：

• 没有面向宿主 Agent 的精简任务包；
• 父级协调者、Child Builder 和独立 Verifier 的责任边界不明确；
• Child Agent 如果还需要自行启动 Verifier，会依赖宿主是否支持嵌套 Agent；
• Agent 返回的文字结果可能被误当成 Runtime 事实；
• 恢复时缺少最小的重复派发和迟到回报保护。

Comet 需要接入宿主原生 Agent 能力，但不应因此引入共享任务列表、mailbox、claim、lease、heartbeat 或通用 scheduler。

5. Runtime 内部流程泄漏给 Skill 和用户

正常推进过程中出现了多次无决策价值的“继续”，并暴露 runner-input 临时 JSON、candidate、iteration、attempt、Agent 运行标识、Archive preview/finish 等内部步骤。

用户主要通过 Comet Skill 使用能力，这些细节应由 Runtime 和 Skill/宿主协调层吸收。只有产品范围变化、合并冲突、外部授权、无法保护用户文件或配置要求最终确认时才暂停。

6. 父级验证结果存在不必要的精确感

最终 333/333 passed 混合了不同层级的证据：

• Child 自己已经完成的领域验证；
• 父级 integration worktree 实际重新执行的检查；
• 没有重新运行、只继承 Child 验证记录的结果；
• 超时、环境阻塞或未完成检查。

当前父级 Builder 还可以用 checks=[] 和统一理由覆盖全部验收项。父级报告应展示证据来自哪里，而不是把所有条目展平为同一种“通过”。

7. 跨模块接入没有在 Shape 阶段明确负责人

初始 Child 分别负责领域模块，但正常 Comet workflow、Skill/CLI fallback、Git 同步、规则验证循环等横向连接没有明确实施责任，直到父级 Verify 才集中暴露。

最终 Verify 应负责收口，不应第一次发现大面积连接缺失。

✨ Proposed solution

术语约定

本 Issue 只保留下面这些必要概念；代码可以沿用现有内部类型名，但面向开发者的设计和状态输出统一使用这里的说法。

术语	本 Issue 中的含义
Supervisor / 父级 Change	代表一个完整用户目标，负责安排 Child、汇总验证并最终交付。
Child	父级拆出的一个可独立实现和验证的普通 Native Change。
integration branch/worktree	父级专用的临时集成分支和工作目录。Child 只合入这里；父级最终验证通过前不修改真实 target。
verified	Child 已在某个明确 commit 上通过独立验证，但还没有合入父级集成分支。
integrated	该 verified commit 已合入父级集成分支，并通过必要的集成检查。
Agent task	Runtime 交给一个 Agent 的单次工作，角色只有 Builder 或 Verifier，并绑定一个 Child worktree。
runId（替代旧称 taskToken）	业界常用的“单次执行 ID”。Runtime 每次派发 Agent task 时生成；返回结果必须携带当前 runId，旧结果或重复结果会被忽略。它不是权限凭证，也不证明 Verifier 独立性。
Child 验证记录	Runtime 生成并绑定具体 verified commit 的结构化验证结果。现有实现内部仍可使用 receipt 类型名，但 Issue 和用户输出不再单独引入 receipt 概念。
修复 Child	父级 Verify 失败后，为现有失败项新增的普通 Child；它只修复已确认范围，不改写已经完成的 Child。
最终权威 Specs	父级最终交付后写入 docs/comet/specs、供后续 Change 继续引用的正式规格。Child 的范围规格只作为本次实施历史保存。
恢复日志	Runtime 记录 merge、归档和清理各步骤是否完成的机器日志，用于进程中断后从未完成步骤继续。实现可以使用 journal，但用户不需要看到该名称。
summary / details / history	status 默认返回 summary 简洁摘要；排查时读取 details 或 history。长列表的 JSON API 使用标准 cursor pagination：响应返回 nextCursor，调用者用它请求下一页；Skill 用户只看到“还有更多详情”，不需要操作 cursor。
可移植状态（Portable State）	可以进入 Git、用于跨设备恢复的 Change 状态；本机 Agent run、进程和临时文件不属于可移植状态。
needs-reverify	Runtime 能恢复 Child 和 commit，但缺少可复用验证记录，因此必须重新 Verify。

用户最终体验

Skill 在创建、恢复、Agent/Child 状态变化和父级验证后，都显示同一份简洁摘要：

self-evolving-memory-team-contracts         Verify passed
├─ plugin runtime                           Integrated
├─ personal memory                          Integrated
├─ project rules                            Integrated
├─ dashboard                                Integrated
└─ host integration                         Integrated

Agents
├─ working                                  0
└─ completed                                5

Checks
├─ Child verification                       5/5 fresh
├─ Parent integration checks                38 passed
└─ Full suite                               incomplete: timeout

Next: final delivery

正常消息不显示完整验收编号、临时 JSON、Runtime 文件名、runId 或 Agent 运行标识。

1. children.yaml v2 只保留可读实施计划

新增 comet.native.children.v2，只保留名称、摘要和真实依赖：

schema: comet.native.children.v2

children:
  - name: comet-plugin-runtime
    summary: 提供第一方和第三方插件的统一运行时
    depends_on: []

  - name: personal-memory
    summary: 实现个人记忆领域能力
    depends_on: [comet-plugin-runtime]

  - name: host-integration
    summary: 接通 Skill、CLI、workflow 和端到端验证
    depends_on: [personal-memory, project-rules, dashboard]

Runtime 只做确定性校验：

• Child 名称唯一且合法；
• depends_on 引用存在；
• 依赖无环；
• 已 integrated Child 的名称、摘要和历史依赖不可被静默改写；
• children.v1 继续可读，已归档 v1 永不重写。

summary 用用户语言说明实施责任，不增加 covers、owns、位置型验收映射或新的用户可见 ID。父级完整目标仍以 brief 和 Specs 为准，由 Shape 做语义拆分确认，由父级 Verify 做最终完整验收。

本 Issue 不改变 Native 验收项的身份模型。现有 A1...An 可继续作为 Runtime 内部兼容字段，但不再进入 children.v2 或默认状态输出。命名验收场景若仍有独立价值，应另行设计，不与 Supervisor integration-first 绑定交付。

2. Shape 明确横向集成责任，但不建立 机器可解析的职责规则

Skill 在确认拆分前执行一次集成责任检查：

• 如果目标跨越两个及以上领域模块、Skill/CLI、Dashboard、Hook 或 workflow，必须由某个现有 Child 的 summary 明确负责，或增加一个小型 integration Child；
• integration Child 依赖相关领域 Child，只负责连接、fallback 和端到端验证，不吞并领域实现；
• Child 数量不需要和 Spec 数量一致；
• 需求文字长、验收项多本身不能触发拆分；
• 用户只确认一次父级 Shape；严格派生的 Child 不重复确认相同范围。

这是 Shape 的语义检查，不由 Runtime 解析 Markdown 标题或强制唯一文件 owner。

父级 Verify 失败后，可以追加处理现有失败项的修复 Child。只要没有新增用户可见范围或产品决定，就不要求用户重新确认；如果范围或决定变化，仍返回父级 Shape。已 integrated Child 的历史不可改写。

3. 分离 Child Verify、Integrate 和 Archive

Supervisor v2 使用以下父级派生状态：

pending → ready → active → verified → integrated
                    └──────────────→ blocked

parent final delivery → archived

• verified：Child 候选和独立验证已经通过，verified commit 已确定，但尚未进入父级 integration branch；
• integrated：父级集成器已将 verified commit 串行合入 integration branch，并校验结果；
• archived：只有父级最终交付成功后，父级和全部 Child 才统一进入 Archive。

默认用户摘要可将 pending/ready 合并显示为“等待”，将 active/verified 合并显示为“工作中”；详细状态仍保留确定性语义。

Standalone Native Change 和 v1 Child 继续使用原 Archive 语义。该扩展只适用于新建的 Supervisor v2。

4. 父级拥有专用 integration branch/worktree

父级 Shape 确认后，Runtime：

1. 记录真实 target branch 的起始 commit；
2. 创建专用 integration branch/worktree；
3. 从当前 integration HEAD 创建 ready Child 的独立 branch/worktree；
4. Child Verify 通过后记录 verified commit；
5. 父级集成器串行把 verified commit 合入 integration branch；
6. 后继 Child 只有在全部依赖 integrated 后才变为 ready，并从包含依赖结果的 integration HEAD 开始；
7. 所有 Child integrated 后，在 integration worktree 运行父级 Verify；
8. 父级通过后按 native.archive_confirmation: automatic | required 自动继续或最多确认一次，再统一交付到真实 target。

Runtime 在 Child 创建、验证、集成和最终交付时校验 Git commit 与祖先关系，不能只相信 Agent 报告或 Archive 文件。

集成操作使用短事务锁、Git 引用比较更新和恢复日志，保证中断后不会重复 merge。这是集成安全，不是通用 worker 调度器。

真实 target 在父级最终交付前保持不变。若 target 已产生新 commit，Runtime 将最新 target 重新带入 integration worktree，并重新运行父级 integration checks；不尝试推断“只受影响的部分”。target dirty 和最终合并条件只在最终交付边界处理一次。

5. 使用宿主原生 Agent，但由父级统一协调

多 Agent 是可选加速层。父级协调 Agent 始终保留最终责任，并统一派发 Child Builder 与独立 Verifier，Child Agent 不需要再创建嵌套 Agent。

Runtime/continuation 为当前可执行工作返回精简的内部任务包：

interface NativeSupervisorAgentTask {
  role: "builder" | "verifier";
  child: string;
  projectRoot: string;
  baseCommit: string;
  runId: string;
}

规则：

• builder 只在指定 Child worktree 中推进 Build，达到 Verifier 边界或 blocker 后返回；
• verifier 是新的只读 Agent，只验收指定 Child 的当前候选；
• 父级协调 Agent 可以并行派发彼此独立的 Builder 或 Verifier；
• 同一个 Child 同时最多有一个有效任务；
• Agent 之间不直接通信，不共享 mailbox 或宿主任务列表；
• Agent 完成消息只是唤醒信号，Runtime 必须重新读取 Child state、verified commit、Git 状态和Child 验证记录；
• runId 只绑定当前 Child、角色、父级状态和 base commit，用于拒绝重复或迟到回报，不证明 Agent 身份或 Verifier 独立性；
• Verifier 独立性继续沿用 Native 现有可信宿主或 skill-coordinated 降级规则，不在本 Issue 中建设新的宿主身份认证协议（provider attestation）；
• 宿主返回 Agent 运行标识（例如线程 ID）时可作为本机恢复信息保存，但不作为验收通过依据。

宿主支持原生 Agent 工具时，Skill 按宿主并发上限并行派发；无法获得上限时最多同时派发 2 个。宿主不支持时，同一协调流程按稳定顺序逐项执行，依赖、验证和集成语义不变。

不在平台注册表中硬编码 supportsMultiAgent。能力由当前会话实际可用工具决定，因为同一宿主也可能通过配置关闭 Agent。

恢复时：

• 可恢复的宿主任务优先重新连接；
• 只有宿主确认旧任务已结束或取消后，Runtime 才失效旧 runId 并为同一 Child 发出替代任务；
• 无法确认旧任务是否仍在写入时返回 blocker，不同时启动第二个 Worker；
• 已 verified 或 integrated 的 Child 不会因为协调会话重启而重复派发。

6. 保留 status / next / archive，自动推进无决策步骤

不新增 comet supervisor 命令族，也不把内部 Module 方法变成新的用户概念。

• comet native status 返回父级摘要、Child 状态、当前 Agent 任务和按需详情；
• comet native next 计算下一批 Builder/Verifier 任务、执行串行集成或进入父级 Verify；
• comet native archive 只负责父级最终交付；
• Skill 在一次协调过程中持续执行无决策动作，直到需要真实用户决定、外部授权或遇到 blocker；
• 临时输入文件统一由 Runtime 在 .comet/runtime 内创建、消费和清理；
• Dashboard 只读取同一份 status JSON，不复制 readiness、Agent 或集成状态推导。

Runtime 内部可以抽取更深的 Supervisor Module，但不需要公开 inspect / advance / finish 作为新的产品协议，也不接受一个可以绕过具体动作校验的泛化 result。

7. 默认 status 返回简洁摘要

默认摘要 只包含：

• 父级阶段和整体验证状态；
• Child 总数以及等待、工作中、已集成、阻塞数量；
• 当前 active/blocked Child 的名称、简短职责、实际 worktree 和原因；
• 正在运行的 Agent 数量与对应 Child；
• 下一动作和已知风险；
• 目标 Spec 数量与实施 Child 数量的分别说明。

完整验收项和 Child 验证记录放在 details；状态变化历史与恢复日志放在 history；调试时再显示 Agent 运行标识。默认 status 不内联这些内容。长列表的 JSON API 使用标准 cursor pagination，响应返回 nextCursor，调用者用它读取下一页；Skill 用户只看到“还有更多详情”，无需手动处理 cursor。按父级名称查询时直接定位声明的 Child，不先扫描所有 worktree 的全部 Change。

8. 建立分层验证记录，不再展平全部验收

每个 Child 集成时保存：

• Child 名称和摘要；
• verified commit；
• integration commit；
• Child 验证记录；
• 实际执行的检查及结果引用；
• 未完成检查和已知风险。

父级报告分为：

1. Child verification：来自通过验证的准确 commit、且在集成后未漂移的 Child 验证记录；
2. Parent integration：在父级 integration worktree 实际重新执行；
3. Not rerun：本轮没有重新执行，但保留明确来源和原因；
4. Incomplete：超时、环境阻塞或缺少证据。

父级 Verifier 仍需读取完整 brief、Specs、所有 Child 验证记录和最终集成结果，对完整目标作出判断；但默认报告不复制 Child 的全部逐项表格，也不得使用 checks=[] 和同一条泛化理由把所有验收项自动标记为通过。

跨 Child、宿主和 workflow 的结果必须具有父级实际集成验证记录。全量测试超时必须显示为 Incomplete，不能折算为 passed。

9. 一次最终交付和安全清理

父级 Verify 通过后，Runtime 按 native.archive_confirmation 自动继续或最多确认一次，并在一个可恢复流程中：

1. 确认 integration HEAD 与父级验证记录一致；
2. 确认真实 target 没有未经处理的漂移；
3. 由父级唯一发布最终权威 Specs；
4. 将 Child scoped Specs、验证记录和 Agent 执行摘要保存为父级 Archive 下的历史，不分别发布最终权威 Specs；
5. 将 integration branch 合入真实 target；
6. 确认 target 已包含最终结果；
7. 统一归档父级和 Child；
8. 安全清理不再使用的 Child/integration worktree 与 branch；
9. 刷新父级最终状态。

任何步骤中断后都可以恢复且不会重复合并或误删 worktree。存在未提交文件、未合入 commit、当前进程位于待删除 worktree 或合并冲突时，保留现场并返回明确 blocker，禁止强制清理。

#313 中 Archive preview 改变状态并导致重复 Verify 的具体修复继续独立完成；本 Issue 只要求 Supervisor 最终交付调用修复后的统一 Archive 能力。

10. Runtime 文件布局与恢复边界

父级目录只保留用户可读内容：

• brief.md
• specs/
• 精简后的 children.yaml
• 简洁的最终 verification.md

Supervisor 动态状态、integration worktree 信息、Agent runId、Agent 运行标识、Child 集成记录、验证记录、恢复日志和临时传输文件统一放在：

.comet/runtime/native/changes/<parent>/supervisor/

这些 Runtime 文件不要求提交到 Git。

Runtime 丢失时可以从 children.yaml、父级/Child 用户文档、可移植状态（Portable State）、Git branch/worktree 和已归档结果重建计划、依赖、工作区与集成状态。只有可移植验证记录足以证明准确 commit 的 Child 才恢复为 verified；缺失时进入 needs-reverify 或 blocked。

宿主 Agent 会话本身不是可移植状态：能重连就重连，不能重连就按安全规则取消旧任务并从 Child 当前状态重新派发，不根据 Git 祖先关系猜测 Agent 是否完成。

11. 分阶段实施

该 Feature 可以由一个 Supervisor Change 管理，建议拆成三个可独立评审的 Child/PR：

1. Integration core

   • children.v2 最小结构与 v1 双读；
   • 父级专用 integration branch/worktree；
   • verified / integrated / archived 生命周期；
   • Git 祖先校验、串行集成和一次最终交付；
   • 先用单 Agent 完成真实 linked-worktree 全流程。

2. Optional parallel Agents

   • agentTasks 和 runId；
   • 父级统一派发 Builder/Verifier；
   • 宿主并行与顺序降级；
   • 恢复、取消、重复/迟到回报保护；
   • Skill 隐藏内部任务交接。

3. 验证记录、状态与恢复

   • 默认简洁 status 摘要 与按需详情；
   • 分层验证记录；
   • 修复 Child；
   • Runtime 重建、最终归档和安全清理；
   • Dashboard status JSON 与规模测试。

三个阶段全部完成前，不把 v2 设为默认，避免出现一半使用独立集成、一半仍按 v1 Archive 的混合模式。

🎯 Primary area

Other — Native workflow runtime (domains/comet-native) and bundled Native Skill

🪐 Workflow phase

Not phase-specific

🔀 Alternatives considered

1. 只优化 Skill 文案和状态摘要

可以缓解“看不到 Child”的问题，但不会解决 Child Archive 与集成混淆、真实目标分支提前包含半成品、dirty target 反复阻塞和父级验证证据失真。

2. 保留 v1，每个问题单独打补丁

可以分别修复 status、Archive 和 runner 交互，但这些问题来自相同的生命周期分界。继续叠加补丁会让调用顺序和恢复更加复杂。

3. 使用宿主 Agent Team 或完整多 Agent Scheduler

共享任务列表、Agent 间通信、claim、lease、heartbeat、抢占和自动重试可以构成更通用的多 Agent 平台，但会复制宿主能力，并把 Comet 从 workflow Runtime 扩张成 Agent 调度器。

本 Issue 只使用父级协调者加独立 Builder/Verifier 的一层派发。Agent 不互相通信，Runtime 不管理模型、消息或通用 worker 生命周期。

4. 同时迁移命名验收场景与 机器可解析的职责规则

可以减少位置型 ID 漂移，但与 integration-first 没有必然依赖，会显著扩大 Native acceptance、Verifier、报告、恢复和兼容范围。

本 Issue 通过删除 covers、隐藏默认验收明细和分层报告解决当前用户问题；命名验收模型另行评估。

最终选择：integration-first Supervisor v2 + optional parallel Agents。先让单 Agent 语义可靠，再在相同 Runtime 事实之上并行加速。

🧰 Compatibility notes

• 仅影响 Native Supervisor；Classic 状态机和 Hook Router 语义不变。
• 没有 children.yaml 的普通 Native Change 行为不变。
• 已归档 v1 永不重写；已有 active Child 的 v1 按旧语义完成，并标记为 legacy。
• 只有尚未启动任何 Child 的 v1 可以在用户确认后升级为 v2；不得静默移动分支或改写历史。
• children.v1、旧 Verifier response 和旧 status JSON 至少保留一个 beta 周期的读取兼容；JSON 字段语义改变时升级 status schema。
• 多 Agent 能力按当前会话工具检测，不修改 33 平台的 canonical registry 来维护易漂移的静态能力表。
• 新增 Git/worktree 操作继续通过 platform/ Adapter；Windows、macOS 和 Linux 共享同一 Runtime 语义。
• 修改 Native Runtime 后重新生成 Native bundles，并更新 assets/manifest.json 和对应 Runtime 资产测试。
• Native Skill 先更新中文版本，用户语义确认后同步英文版本。
• Dashboard 不新增状态机或编辑能力，只读取 Runtime status JSON。
• 最终验证包含相关 Native/Skill/Runtime 测试、真实 linked-worktree 与并行 Agent fixture、architecture lint、生成物检查、build，以及一次与风险匹配的全量测试。

🧩 Additional context

Acceptance criteria

User experience

• 从父级或任意 Child worktree 恢复时，Skill 无需用户操作 CLI/Dashboard 即显示父级阶段、Child 进度、正在运行的 Agent、实际位置、风险和下一动作。
• 摘要明确区分目标 Specs、实施 Child 和横向 integration/修复 Child。
• 无真实决策时，Builder/Verifier 派发、Child Verify、串行集成、父级刷新、下一波启动和进入父级 Verify 自动推进，不要求用户重复回复“继续”。
• 正常输出不包含临时 JSON、Runtime 文件名、完整验收编号、runId 或 Agent 运行标识。
• 父级 Verify 通过后遵循 native.archive_confirmation：automatic 不再询问，required 最多确认一次。

Plan and integration responsibility

• children.v2 只包含 name / summary / depends_on，不包含 covers / owns。
• Runtime 校验名称、依赖和无环，但不解析 Markdown 标题或推断语义 ownership。
• Shape 能发现跨模块连接需求，并要求现有 Child 的摘要明确接管，或增加小型 integration Child。
• 父级失败后可以追加严格处于现有范围内的修复 Child，但不能改写已经 integrated 的 Child 历史。
• 本 Issue 不改变 Native acceptance identity；默认状态和父级摘要不暴露位置型 ID。

Integration lifecycle

• 新 Supervisor 使用独立 integration branch/worktree，真实 target 在父级最终交付前保持原 commit。
• Child 独立 Verify 后进入 verified，串行合入并校验后进入 integrated，不会提前显示为 archived。
• 依赖 Child 从包含全部前置 integration commits 的基线创建；缺少任一前置提交时拒绝执行或集成。
• 所有 Child integrated 前父级不能进入最终 Verify。
• 父级 Verify 失败时 target 不变，可以追加修复 Child 后继续。
• 父级最终交付成功后，父级和 Child 一起归档并安全清理 worktree。
• 父级是最终权威 Specs 的唯一发布者；Child scoped Specs 只作为历史记录保存。

Optional parallel Agents

• 支持原生 Agent 的宿主可以同时派发至少两个无依赖 Child，且每个 Agent 使用独立 worktree。
• 父级协调 Agent 分别派发 Builder 和只读 Verifier；实现不依赖 Child Agent 能否创建嵌套 Agent。
• 宿主不支持 Agent 时自动顺序执行，得到相同的依赖、验证、集成和最终交付结果。
• Agent 完成消息不能直接推进状态；Runtime 必须核对可移植状态（Portable State）、Child 验证记录、verified commit 和 Git 关系。
• 同一 Child 同时最多有一个有效任务；重复或迟到 token 不能触发重复验证或集成。
• 重新派发前必须确认旧 Agent 已结束或取消；无法确认时阻塞，不能让两个 Agent 并发写同一 worktree。
• 一个 Agent 失败或需要授权时只阻塞对应 Child；其他无依赖任务仍可完成，但集成始终串行。
• Agent 不需要共享 mailbox、任务列表或直接互相通信。

Evidence and reporting

• 每个 integrated Child 的记录绑定真实 verified commit、integration commit、Child 验证记录和检查结果。
• 父级结果分别展示 Child verification、Parent integration、Not rerun 和 Incomplete。
• 跨 Child、宿主和 workflow 场景缺少父级实际集成验证记录时不能整体通过。
• 超时、环境阻塞或缺失检查保持为 Incomplete，不转换为 passed。
• 父级不得以 checks=[] 和同一条泛化理由自动通过完整目标。
• 默认 status 不内联完整验收、历史、Child 验证记录或 Agent 调试字段，并有固定输出预算；详情通过 cursor 按需读取。

Recovery and compatibility

• Child merge 前后、Runtime 写入前后、Agent 返回前后、父级最终 merge 前后中断，恢复后都不会重复合并、跳过验证或误删 worktree。
• 删除 Supervisor Runtime 后，可以恢复计划、依赖和 Git 集成状态；缺少可信可移植验证记录的 Child 必须进入 needs-reverify 或 blocked。
• 宿主 Agent 无法重连时可以在确认旧执行结束后从 Child 当前状态重新派发，不猜测完成结果。
• 两个 Child 同时完成 Verify 时，integration branch 仍串行处理。
• v1 父级可以继续完成；普通 Native Change、Classic 和现有 Dashboard 行为不回归。
• 测试覆盖至少一个真实 Git linked-worktree 的完整父级流程、两个并行 Child 的 Builder/Verifier 流程，以及 32 个 Child 下的默认状态大小和按名称查询性能。

Suggested implementation ownership

• domains/comet-native/：Supervisor plan、Agent tasks、status JSON、integration、evidence、recovery 和 continuation。
• platform/paths、platform/process：Git/worktree 的现有 Adapter；不在 domain 内散落平台命令。
• app/commands：只组合 Runtime Module，不承载 readiness、Agent 派发、集成或恢复规则。
• assets/skills-zh/comet-native/、assets/skills/comet-native/：用户主路径、宿主 Agent 派发、顺序降级和简洁摘要。
• domains/dashboard/：仅适配新的只读 status JSON，不复制状态计算。
• test/domains/comet-native/：无模型状态、runId、恢复、真实 worktree 和规模测试；Skill、Dashboard、Repository 测试按现有归属补充。

Non-goals

• Supervisor worker claim、lease、heartbeat、抢占或自动任务领取；
• Agent Team、共享 mailbox、Agent 间自由通信或嵌套 Supervisor；
• 通用 bounded-concurrency scheduler、自动选择模型或 exactly-once Agent execution；
• 新的宿主身份认证协议（provider attestation） 或跨平台 Agent SDK；
• 命名验收场景、Markdown 机器可解析的职责规则 或内容指纹迁移；
• 多层父子树、跨仓库 DAG、软依赖或多种依赖边；
• 自动解决 Git merge conflict；
• 新的 comet supervisor CLI 命令族；
• Dashboard 重新设计或在 Dashboard 中编辑父子计划；
• Classic 父子 Change；
• 在本 Issue 中重复修复 Question: 边界设计问题-Archive 发现本机 Runtime overlay 在归档边界不可复用，因此 Comet 按规则把状态退回 Verify，要求对同一候选重新生成 Runtime receipts。 #313。

本 Issue 只实现完成 integration-first 所必需的最小 runId 与迟到回报拒绝；真正的 durable multi-agent scheduler 如果以后有明确需求，再单独立项。