[Enhancement] 让 trellis-start 和 trellis-continue 委托当前 workflow 的统一 continuation 合同

合同版本：2026-09-17-r3

背景：为什么必须修改入口所有权

Trellis 当前把 active task 的续接判断分散在多个位置：

• trellis-start 内置一份 task.json.status + artifact presence 路由；
• trellis-continue 内置另一份路由；
• workflow 的 [workflow-state:*] 区块描述 active task 行为；
• 各平台入口保存由上述规则派生的投影文本。

这组机制把三个不同事实压缩成一个判断：

1. session 与 task/workspace 的精确绑定；
2. task 的粗粒度 lifecycle status；
3. 当前 workflow 图中的下一合法 owner。

task.json.status 只能表示 planning、active 或 completed 生命周期，不能表示 workflow 已完成 Phase 2、Task Commit、Branch Review、Publication 中的哪一步。入口依据 status 和 artifact 名称判断具体步骤，会把 workflow-specific 语义复制到通用入口，并在 workflow 演进后产生漂移。

并行任务、跨 worktree 与跨会话恢复场景已经证明：项目任务清单、唯一 session 文件或 invocation checkout 不能替代当前 session binding。即使精确解析 current task，status=in_progress 仍无法确定 active task 的合法续接点；当后续阶段的 public DTO 丢失时，旧入口可能错误地重新路由到 implementation/Phase 2。

Trellis 不应建立长期 workflow-stage ledger 来解决该问题。semantic pass、typed exit 和 owner recovery 属于当前 workflow 及其 owner；通用入口无权根据 Git、artifact、旧会话文字或 task status 重建这些结论。

因此，入口必须只负责读取精确 current-task facts 和当前 workflow 的续接合同。当前 workflow 必须成为 continuation/resume 语义的唯一来源。

当前缺陷

• trellis-start 与 trellis-continue 各自维护 workflow-specific route table。
• 自定义 workflow 修改 phase、step、semantic owner 或 recovery route 后，官方入口仍执行旧 route table。
• trellis-meta 要求 workflow 作者同步修改入口 route table，形成第二 workflow authority。
• workflow switch 后，旧入口文本可能继续执行前一个 workflow 的规则。
• active task 的 PROJECT TASKS 展示信息存在被入口或 AI 当作 current-task authority 使用的风险。
• public DTO 在跨会话后丢失时，入口缺少 owner-preserving 的恢复合同。

目标

1. trellis-start 和 trellis-continue 成为 workflow-neutral 薄入口。
2. 当前 .trellis/workflow.md 中的唯一 continuation 区块拥有 active-task 续接语义。
3. 入口不再保存 phase/status/artifact route table。
4. current task 只来自 active-task resolver 的精确 session binding。
5. public DTO 丢失后的恢复返回 workflow 声明的原 producer、same-owner recovery、fresh semantic rerun 或 fail-closed stop。
6. workflow switch 后的下一次入口调用只读取切换后的 workflow。
7. 不新增 lifecycle ledger、长期 continuation checkpoint或用户授权状态。

交付边界

• 本 Issue 在 Trellis 根仓库交付固定 continuation 协议、确定性提取接口、workflow-neutral 入口、平台投影和 root-owned native workflow 迁移。
• Marketplace/custom workflow 作者负责在其 workflow 参与 active-task resume 前加入有效 continuation 区块；外部 workflow 内容迁移不由本 Issue 代为发布。
• 外部 workflow 缺少有效区块时必须 fail closed，不得回退到 native 或旧 route table。

设计合同

1. 固定 continuation 区块

Workflow Markdown 使用以下稳定标记：

[trellis-continuation]
<workflow-owned Markdown continuation contract>
[/trellis-continuation]

任何参与 active-task 续接的 workflow 都必须包含且仅包含一个非空区块。根仓库交付负责 bundled native 与 dogfood native；新安装或切换后的 marketplace/custom workflow 也必须满足该约束，但其内容迁移和发布由对应 workflow 作者负责。

以下结构返回 invalid_continuation_contract：

• 区块缺失；
• 区块重复；
• 区块正文为空或只含空白；
• 起始标记或结束标记缺失；
• 标记名称不一致；
• 区块嵌套。

invalid_continuation_contract 必须停止 active-task 自动续接。入口不得进入 native fallback，不得执行旧 status/artifact route table，不得从完整 workflow 文本自行重建另一份隐式 route table。

2. 固定提取接口

get_context.py 新增以下读取接口：

python3 .trellis/scripts/get_context.py --mode continuation

该接口执行以下确定性行为：

• 读取当前 .trellis/workflow.md；
• 校验第 1 节定义的区块结构；
• 成功时按原始顺序输出区块正文；
• 失败时返回非零退出码，并报告 workflow 路径和结构错误类型；
• 不依据 task status、artifact、Git history 或 conversation history选择步骤；
• 不生成 semantic pass、finding、typed exit、readiness 或 completion 结论；
• 不写 task、runtime、workflow、platform entry 或用户授权状态。

3. Current-task authority

Active-task continuation 只接受 active-task resolver 返回的精确 session binding。该 binding 必须包含 task identity、task workspace 和 repository identity。

以下输入不得用于选择 current task：

• PROJECT TASKS 清单；
• active task 数量；
• 唯一 in_progress task；
• assignee；
• invocation checkout；
• 唯一 session 文件；
• artifact 存在性。

resolver 返回 no binding、stale、conflict 或 ambiguous 时，入口停止 active-task continuation，并报告 resolver 结果。入口不得从项目 inventory 选择替代 task。

4. trellis-start 职责

trellis-start 执行以下顺序：

1. 加载 session、Git、current-task 和 project inventory facts；
2. 加载当前 workflow Phase Index；
3. current task 为空时，执行当前 workflow 的初始请求入口；
4. current task 存在时，调用 get_context.py --mode continuation；
5. 将 current-task facts、Phase Index 和 continuation 正文交给当前 AI 执行；
6. 不在入口文本中判断具体 phase、step、semantic owner 或 recovery route。

5. trellis-continue 职责

trellis-continue 执行以下顺序：

1. 加载 session、Git 和 current-task facts；
2. current task 为空时返回 no_current_task，不创建 task，不选择 project inventory 中的 task；
3. current task 存在时，调用 get_context.py --mode continuation；
4. 将 current-task facts和 continuation 正文交给当前 AI 执行；
5. 不在入口文本中判断具体 phase、step、semantic owner 或 recovery route。

6. Workflow ownership

Continuation 区块由当前 workflow 独占以下内容：

• lifecycle status 在该 workflow 中的解释；
• 当前 live facts 所要求的下一 owner；
• 相邻调用链中 current public DTO 的唯一 consumer；
• public DTO 丢失后的原 producer recovery 或 fresh semantic rerun；
• stale、identity mismatch、content drift 和 authority drift 的返回路径；
• fail-closed stop。

入口只加载并执行该区块，不理解其中引用的 skill、typed exit、owner、artifact 或 recovery 语义。

[workflow-state:*] 保持 broad lifecycle breadcrumb。active-task workflow-state 区块不得复制 continuation route table；它必须要求当前 AI 在执行续接前加载 [trellis-continuation]。

7. Lifecycle status 边界

task.json.status 保留 task lifecycle 含义。它不得单独决定具体 workflow step，也不得证明 implementation、check、commit、review、publication 或 finish 已完成。

Continuation 区块读取 status 时，必须同时遵守当前 workflow 声明的 owner、live-fact 和 recovery 规则。

8. 更新与冲突行为

• 根仓库受管 native workflow 模板通过 trellis update 获得 continuation 区块。
• 用户未修改的受管 native workflow 由 update 写入新模板。
• Marketplace/custom workflow 的迁移由其作者独立发布；根仓库不通过修改外部 workflow 内容完成该迁移。
• 用户修改导致模板冲突时，update 保留当前 workflow 并生成 .new。
• 当前 workflow 缺少有效区块时，active-task continuation 返回 invalid_continuation_contract。
• .new 文件不参与运行时提取。
• 旧 route table 不作为兼容 fallback。
• workflow switch 完成后，入口只读取当前 .trellis/workflow.md，不缓存前一个 workflow 的 continuation 正文。

9. Canonical entry 与平台投影

trellis-start、trellis-continue 以及 platform-template registry 生成的每个平台入口必须来自同一 canonical 模板源。

生成后的平台入口不得包含 workflow-specific status/artifact route row。平台投影只负责调用共享上下文读取接口和 continuation 提取接口。

trellis-meta 必须说明：

• workflow 作者只维护 workflow Markdown 中的 continuation 区块；
• workflow 作者不修改平台入口 route table；
• get_context.py 只执行确定性提取和诊断；
• semantic continuation 由当前 AI 按 workflow 合同执行。

验收标准

• 固定标记、结构校验和 invalid_continuation_contract 行为均有单元测试。
• get_context.py --mode continuation 对有效、缺失、重复、空白、未闭合、名称不一致和嵌套区块具有固定结果。
• trellis-start 与 trellis-continue 不包含 workflow-specific status/artifact route table。
• 两个入口对精确绑定的 active task 加载同一 continuation 正文。
• current-session binding 为空而 PROJECT TASKS 含一个或多个 active task 时，两个入口均不选择其中任何 task。
• current-session binding 指向 linked worktree 时，入口读取该 binding 的 task/workspace facts，同时从 invocation repository 的当前 .trellis/workflow.md 加载合同。
• resolver 返回 stale、conflict 或 ambiguous 时，入口不执行 continuation。
• trellis-continue 在 current task 为空时返回 no_current_task。
• Bundled native 与 dogfood native 各含一个有效 continuation 区块，且提取出的 native continuation 正文一致。
• 迁移前入口 route table 的每个 native case 均转换为具名 route；迁移后由 native workflow 选择同一步骤。
• fixture/custom workflow 定义不同于 native workflow 的 continuation；workflow switch 后两个入口立即执行 fixture workflow 合同。
• 缺失区块时不存在 native fallback、legacy route 或 inventory-based task selection。
• init、update、workflow switch、用户修改冲突和 .new 行为均有集成测试。
• platform-template registry 生成的每个平台入口通过同一模板源测试，且生成文件不含 workflow-specific route row。
• trellis-meta 不再要求 workflow 作者同步修改入口 route table。
• 测试证明提取器、hook 和入口未生成 semantic pass、finding、typed exit、readiness 或 completion 结论。

非目标

• 不实现、修改或发布 marketplace/custom workflow 的具体 continuation graph；外部作者自行迁移并满足固定协议。
• 不把 workflow-specific semantic judgment 写入 TypeScript、Python 或 shell resolver。
• 不新增 task stage ledger、长期 continuation checkpoint、通用 typed-exit graph或跨 workflow lifecycle schema。
• 不持久化用户确认、授权文本或授权状态。
• 不改变各 workflow 对 implementation、check、commit、review、publication 或 finish 的业务合同。
• 不修改 active-task resolver 的 session-binding 算法；该算法继续由其现有 owner 维护。

交付关系

• 本 Issue 负责薄入口、固定区块协议、确定性提取接口、root-owned native workflow 迁移、平台投影和 trellis-meta。
• Marketplace/custom workflow 继续由各自作者维护，其迁移不改变根仓库对协议和 fail-closed 行为的所有权。
• 后续集成应基于本修复合并后的精确上游候选验证 install、update、workflow switch 与自定义 workflow 行为。