chore(trellis): clarify scope boundaries and parallelism

.agents/skills/trellis-orchestrator/SKILL.md

@@ -48,12 +48,14 @@ worker 不得再委派、暂存、提交、合并或管理 worktree。
 
 ### 范围拆分
 
-在任务材料中记录当前的范围与依赖计划。一个 scope 是具备交付物、拥有/排除路径、依赖和验收目标的完整职责，而非按文件大小分割，也不是自动按包拆分。构成同一职责的源码变更、适配器和本地测试必须放在一起。研究只提出事实和边界，不能自行决定最终架构。
+在任务材料中记录当前的范围与依赖计划。拆分的第一优先级是“一个 Agent 能独立完成并验收的功能模块”：它有单一清晰的功能责任、可观测交付物和局部闭环验收，且不需要另一个未完成的 sibling scope 与它联合实现才能成立。构成该模块的源码、适配器、配置与本地测试必须放在同一 scope，即使它们跨越多个目录或包。
+
+只有功能模块边界成立后，才用拥有/排除路径限定写权，用依赖描述其启动前提和收敛顺序。文件、目录、包、函数或“最小依赖块”都不是首要拆分维度，也不能为了多创建 worker 将同一功能闭环拆散。若两组变更必须共同设计、联合实现或联合验收同一 invariant，它们就是一个 scope；若共享边界可以先产出稳定接口并独立验收，则把它记为明确的前置 scope。研究只提出事实和边界，不能自行决定最终架构。
 
 | Scope ID | 职责 | 拥有/排除 | 依赖于 | 验收 | 研究证据 |
 | --- | --- | --- | --- | --- | --- |
 
-共享或根级文件交给拥有其行为的 scope。每项依赖都要注明所需输出或接口；计划顺序和 worker 复用不是依赖。不得只为提高并发度拆分 scope，也不能授予其重写无关区域的权限。
+共享或根级文件交给拥有其行为的 scope。每项依赖都要注明所需输出或接口；计划顺序和 worker 复用不是依赖。不得只为提高并发度拆分 scope，也不能授予其重写无关区域的权限。当功能模块已完整、模块间低耦合且依赖就绪后，所有写入不相交、无共享写入且运行时可隔离的 ready scope 应尽可能并发；不要因为文件数量、包边界或可复用某个 worker 而无故串行。
 
 ### 共享验收与执行通道选择
 

.agents/skills/trellis-orchestrator/references/worktrees.md

@@ -1,6 +1,6 @@
 # 并行 Scope Worktree
 
-只有综合结果确认确有并发 writer 时才阅读本文件。任务分支本身已是规范任务状态；worktree 只是给并行 writer 提供临时隔离，并不是必需的实现或集成工作区。
+只有综合结果已先按“一个 Agent 能独立完成并验收的功能模块”定义 scope，且确认确有并发 writer 时，才阅读本文件。不得先按文件、包或 worktree 拆出通道，再倒推功能 scope。任务分支本身已是规范任务状态；worktree 只是给并行 writer 提供临时隔离，并不是必需的实现或集成工作区。
 
 ## 准入门槛
 
@@ -13,6 +13,8 @@
 
 无法隔离运行时资源时，应降低并发度或在任务分支上串行执行。不得用 worktree 绕过未解决的共享变更或尚未 accepted 的依赖。
 
+通过上述门槛的 ready scope 应在实际 worker 与平台上限内尽可能并发。这是功能模块完整性和低耦合已成立后的调度决策，不是新的 scope 拆分依据。
+
 ## Accepted Base 与最小登记表
 
 先在任务分支上实现并独立 Check 所有基础共享变更。其 accepted commit 成为每个并行 scope worktree 冻结的 accepted_base。通道仍在运行时如必须变更 base，暂停受影响通道，在任务分支接受新的基础变更，并明确刷新或替换过期通道。

.codex/agents/trellis-check.toml

@@ -38,14 +38,14 @@ Trellis 上下文加载协议：
 
 - 只能在被分配的 implementer 进入终态后开始。Checker 可以写测试，因此在其进入终态前，它是该 workspace 唯一的 active writer。绝不能与 implementer 并发检查或写入同一 workspace。
 - 每次检查派发必须说明 Execution workspace、Workspace role（task-branch 或 scope-worktree）、Owns、Excludes、Scope 和检查类型。scope-worktree 检查还需要 Worktree record 与 Accepted base。验收或写测试前报告解析出的 Git root、HEAD 和 diff。字段缺失或登记的 scope worktree 不匹配即为 blocked；不得换用其他 checkout。
-- 派发将检查标为 scope 或 final。scope check 证明其语义职责和直接消费者边界。final check 在收敛后的任务分支上进行，证明集成 diff、跨 scope invariant、派生共享变更和每个必需 scope check 均已存在。
+- 派发将检查标为 scope 或 final。scope check 验收的是单个 Agent 可独立交付的完整功能模块及其直接消费者边界，不是逐文件、目录或包的局部检查。final check 在收敛后的任务分支上进行，证明集成 diff、跨 scope invariant、派生共享变更和每个必需 scope check 均已存在。
 - scope worktree 只有在派发证明其 ports、database、container、临时状态、测试账号和生成输出与 sibling workspace 隔离时，才可运行 runtime check。否则应报告精确命令与冲突，改在任务分支串行执行。
 
 你的工作是依据 spec 检查代码变更，并且只修复测试文件中安全的问题。非测试文件中的机械问题（lint、type、import、死分支或生产 assertion）必须报告，不能修复。设计或判断调用、公共接口、模块边界、spec/config/documentation 漂移，或当前任务范围外的任何问题，也必须带证据和建议报告，同时保持受影响的非测试文件不变。
 
 ## 本地验收与延后的运行时证据
 
-- 验证检查范围与分配的语义 scope record 一致。ownership 边界缺失或已变更即为 blocked，必须回到主会话。
+- 验证检查范围与分配的语义 scope record 一致，且该 scope 确实构成可独立验收的功能闭环。ownership 边界缺失、已变更，或仅是按文件/包切出的局部片段，即为 blocked，必须回到主会话。
 - 检查所有分配功能，包括实现、适配器和本地测试。一个职责里的多个 invariant 不需要拆分。其他独立通道可仍在运行；只要求本通道的 writer 已释放 ownership。无需等待无关 sibling 先完成。
 - 只评判分配的 Scope ID 和其验收义务，不评判任务级 manifest 中描述的每项未来消费者实现。
 - scope 作出 accepted 决策，表示声明的本地检查在指定 HEAD/diff 上已通过，不代表全任务最终验收。

.codex/agents/trellis-implement.toml

@@ -29,10 +29,10 @@ Trellis 上下文加载协议：
 
 ## 单一限定的派发任务
 
-- 遵循 Orchestrator 定义的语义 scope：一个带有交付物、拥有/排除路径、依赖和验收目标的完整职责。源码、适配器和本地测试保持在一起。
+- 遵循 Orchestrator 定义的语义 scope：一个可由单个 Agent 独立完成并验收的功能模块，具有交付物、拥有/排除路径、依赖和验收目标。构成同一功能闭环的源码、适配器、配置和本地测试保持在一起；拥有/排除路径只限定写权，不得据此把功能模块再按文件或包拆分。
 - 任务级 PRD/设计/manifest 只作背景。只实现本次派发中的 Scope ID、交付物、拥有/排除路径和停止条件。
 - 不得自行拆分或扩大 ownership。scope 细节缺失或必须改动共享路径时，在 Orchestrator 解决前禁止编辑。
-- 交付物和本地检查一完成，就以范围终态报告结束本次派发。不得继续处理下一个计划中的包。下一个 scope 的复用必须在 Check 之后由主会话新建派发。
+- 交付物和本地检查一完成，就以范围终态报告结束本次派发。不得继续处理下一个计划中的功能模块。下一个 scope 的复用必须在 Check 之后由主会话新建派发。
 - 写明必要的运行时检查：精确命令、前置条件、隔离要求和预期证据。绝不能以 unit 替代物声称它们成功。下游 scope 不得依赖未证明的前提启动。
 
 ## 派发范围与 Worktree 边界

.codex/agents/trellis-research.toml

@@ -54,9 +54,9 @@ developer_instructions = """
 
 对每个分配的问题，用证据补充可复用材料，而不是重复已覆盖的仓库发现。记录已检查的 checkout/HEAD、相关 dirty path、检查过的 source anchor，以及哪些早期报告事实仍适用。将本次验证的事实与继承的主张或未决假设分开。
 
-研究边界应按语义划分：契约、持久化/API/事件路径、运行时/状态、展示/读取模型，或其他可独立变化的职责。研究主题可以比实现 scope 更细。候选 scope 应描述为含源码/适配器/测试的完整交付物，并包含拥有/排除路径、验收、接口依赖与实际共享写入。不要因为目录、文件、函数或希望增加并行 worker 而切分。研究不决定最终架构，也不授予写权限；由 Orchestrator 综合这些决策。
+研究边界可按语义证据划分：契约、持久化/API/事件路径、运行时/状态、展示/读取模型，或其他可独立验证的问题；研究主题可以比实现 scope 更细，但不得直接把研究切片当成实现 scope。候选 scope 首先应描述为“一个 Agent 能独立完成并验收的功能模块”，并将构成同一功能闭环的源码、适配器、配置和测试放在一起，即使它们跨目录或包。之后再补充拥有/排除路径、验收、接口依赖与实际共享写入。不要因为目录、文件、包、函数、最小依赖或希望增加并行 worker 而切分。研究不决定最终架构，也不授予写权限；由 Orchestrator 综合这些决策。
 
-当一个边界决定后续 scope 的前提时，将其归为 cross-cutting，例如公共 contract、schema、授权边界、共享状态机或依赖方向。指出哪些 writer 必须等待。package-local 研究可以并行推进，但必须在其 writer 开始前完成。对于拟并行 writer，识别是否存在 dependency-ready、write-disjoint、shared-write-free 与 runtime-isolated 的证据；目录不同不够。
+当一个边界决定后续 scope 的前提时，将其归为 cross-cutting，例如公共 contract、schema、授权边界、共享状态机或依赖方向。指出哪些 writer 必须等待。package-local 研究可以并行推进，但必须在其 writer 开始前完成。对于拟并行 writer，先确认功能模块已完整且模块间低耦合，再识别是否存在 dependency-ready、write-disjoint、shared-write-free 与 runtime-isolated 的证据；目录不同不够。对所有满足这些条件的 ready scope，明确标记可并发，不要因为小型依赖已稳定或某个 worker 可复用而默认串行。
 
 将 static/unit probe 与会使用 ports、database、container、测试账号或生成运行时状态的 runtime probe 分开。包含命令、预期证据和隔离要求。研究期间不要启动服务，也不要声称得到运行时证明。