Right-size verification, repair shared causes, and dispatch routine Luna work

Plugin-Submission: d77fbfc482bf93fdb2203b097c07d51b2f01d3e7c29ed776305b9f3d38b35075

VERSION

@@ -1 +1 @@
-2.3.1
+2.4.0

docs/behavior-scenarios.md

@@ -56,6 +56,30 @@ These are static review cases, not a record that a model executed them. Use them
 | Several independent ready slices, parent only has later synthesis, host permits this dispatch | Run useful children concurrently and integrate on return; no universal requirement to invent simultaneous parent work |
 | Host explicitly requires useful concurrent parent work | Honor that stricter requirement even when the fleet policy otherwise permits parent waiting |
 
+## 2.4 verification, causal repair and routine Luna work
+
+These are static expected decisions, not live rollouts or measured improvements. Use the user request, relevant changed artifact and actual host conditions for future forward tests.
+
+| Scenario | Expected behavior |
+| --- | --- |
+| Reversible UI label correction, no executable behavior change, relevant required checks pass | Inspect the changed result and stop; no new unit suite, full build or extra reviewer by default |
+| Small adapter fix changes a local boundary | Check the affected behavior and nearest relevant boundary; add a regression test if it protects a recurring defect |
+| Two-line patch changes authorization or persisted financial state | Assess the actual invariants/consumers and relevant failure paths; do not classify as low-risk from diff size |
+| Required project suite is broad despite a small change | Run the required suite; the skill cannot waive it |
+| Proposed extra fuzz/build/review has no uncovered affected invariant | Stop validation; do not add work to fill idle capacity |
+| Worker checks passed on the same relevant files/dependencies/artifact/environment | Parent reviews patch and coverage, reuses checks, and tests only new integration interactions and mandatory project items |
+| Unrelated documentation edit after a passed parser test | Reuse that test result; the unrelated edit does not require rerunning it |
+| Worker checks predate a changed shared dependency or ran against moving output | Recheck affected behavior on a stable current artifact; do not treat the stale result as final |
+| First bug is an obvious isolated typo | Correct locally and check the direct result; no architecture audit |
+| First bug reveals duplicated caller fallbacks and inconsistent producer/consumer assumptions | Inspect shared cause and nearest sibling consumers; repair the demonstrated failure class at its owning layer |
+| Original failure is fixed only by adding another caller-specific default that masks a contract violation | Revisit the contract/owner and check a representative sibling before acceptance |
+| Environment prevents a full repair, user requests a temporary mitigation | Apply the scoped mitigation if authorized; state its limits and remaining cause without claiming root resolution |
+| Authorized routine batch has several independent Luna-sized coding outcomes | Dispatch useful bounded batches early; single-item simplicity does not justify keeping the entire batch local |
+| Behavior and ownership are clear, exact local edit sites are not yet known | Let the bounded worker locate edits; no parent pre-solution or full repository map required |
+| Ordinary bounded Luna task with no structured consumer | Short outcome/baseline/ownership/acceptance contract and concise paths/checks/gaps return; no mandatory JSON packet |
+| Large batch completes, runtime identity is unknown, identity is not an explicit requirement | Keep identity unknown and evaluate output normally; batch size alone does not trigger a packet or another probe |
+| Parent patches share one changing contract even though paths differ | Settle the contract and serialize its ownership; aggressive Luna dispatch does not remove integration gates |
+
 ## 2.3 Sol version and migration scenarios
 
 These are static expected decisions, not live executions or benchmarks.

docs/development.md

@@ -15,6 +15,10 @@ The bundled validator validates evidence structure only. It cannot authenticate
 
 Use Python 3.9+ and the standard library. The optional upstream skill-creator quick_validate.py requires PyYAML; if missing, report the missing dependency rather than substituting an unreported result.
 
+For this repository, run the checks required by AGENTS.md once on the final relevant baseline, including the available skill-creator validator. Unit tests already cover validator smoke behavior and installer safety; do not stack their equivalent standalone examples after a passing run. Instruction changes need a focused static review of representative decisions, not wording-matching unit tests. Installation comparison is for an installation task, not a requirement that a contributor's active global prompt equal the template.
+
+For tasks using the skill, select checks through [verification scope and causal repair](../skills/codex-subagent-router/references/engineering-workflow.md). Preserve required checks; reuse unaffected evidence and stop when the relevant outcome is supported. Static scenarios remain expectations until real authorized forward tests observe behavior. Do not claim this policy reduced elapsed time, cost or defects without measurements.
+
 ## Compatibility with other skills
 
 Do not automatically rewrite unrelated skills. Older orchestration skills may assume forked workspaces, a close tool, or a Sol-only parent. Resolve conflicting applicable instructions according to host precedence and identify the exact remaining gate. For a coordinated migration, explicitly include those files and their project-specific requirements.

docs/releases/2.4.0.md

@@ -0,0 +1,16 @@
+# 2.4.0 — 最小充分验证、因果修复与简单任务并行
+
+## 变化
+
+- 验证按实际影响分档，并明确停止条件。低风险改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动覆盖相关消费者与集成；保留项目必需检查。可信 worker 结果按相关产物和环境复用，整合只补查新增交互，不默认叠加全量测试、额外审查或 JSON 证据包。
+- 排障在第一次实质问题出现时定位原因并简查同机制的相邻调用点。重复特判、兜底或生产者/消费者分歧触发合同、设计与流程调查，优先在原因所属层修复已证实的一类问题；明显局部错误仍局部处理，不要求普遍架构审计或无关重构。
+- 已获授权的多个简单编码批次属于正常 Luna 工作。有明确行为、基线与文件/语义所有权即可分派，由 worker 定位局部改动；不等完整仓库地图或主线程预先解完任务。按实际容量及时补位，普通合同和返回使用简短文字，验证只分配实际需要的检查。
+- 新增按需读取的工程工作流参考，并同步技能入口、可选全局提示词、舰队/升级参考、维护文档与静态行为场景。README 不再把单元测试已覆盖的校验器样例、self-test 或本机安装一致性列成每轮必做项。
+
+## 兼容与验证边界
+
+保留子智能体授权、真实宿主槽位、文件与语义所有权、主线程整合及外部操作边界。证据 schema、决策 schema、模型路由和安装备份行为不变。仓库内模板不会自动成为当前会话指令，安装技能不会开启并行能力。
+
+本轮静态场景描述预期决策，不是实时 agent 行为或性能测量。节省时间、成本与减少缺陷需通过后续已授权真实任务核实。
+
+更新个人全局规则应先备份并做定向合并；`--include-prompt --apply` 仍整体替换提示词，不用于合并个人规则。

prompts/AGENTS.md

@@ -21,10 +21,10 @@
 
 ## 3. 实现与验证
 
-- 理解合同与消费者，做最小完整改动；人工编辑使用 apply_patch。共享 schema、注册表、生成器和公共 API 的修改同时检查消费者与生成产物。
+- 理解合同与消费者，做最小完整改动；人工编辑使用 apply_patch。排障先定位原因，简查同机制的相邻调用点；重复特判、兜底或生产者/消费者分歧须检查合同、设计与流程，优先在原因所属层修复已证实的一类问题，不扩展成无关重构。共享 schema、注册表、生成器和公共 API 的修改同时检查消费者与生成产物。
 - 中间材料放 work/，独立交付物放 outputs/；项目代码在原项目编辑，不复制成脱离项目的源码。
-- 按影响运行定向行为检查、类型/lint、构建或烟雾测试，完成项目必需检查；不为低影响可逆改动新增照抄实现的测试。视觉文档与网页按适用技能渲染或检查功能。
+- 采用最小充分验证并完成项目必需检查：低风险可逆改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动检查相关消费者与集成。不默认叠加全量测试、构建、额外审查或证据包，不新增照抄实现的测试。视觉文档与网页按适用技能渲染或检查功能。
-- 同一基线、产物和环境的可信结果可复用。相关检查通过后，只有新改动、失败或未决疑点才扩大或重跑。区分回归、既有失败和环境阻塞，说明验证缺口。
+- 同一相关基线、产物与环境的可信结果可复用，包括子智能体检查；主线程检查补丁与覆盖，整合只补查新增交互，不重做各 worker 全套验证。相关检查通过且无实质未决问题即停止；追加检查须对应具体变更、失败或未覆盖不变量。区分回归、既有失败和环境阻塞，说明验证缺口。
 - 审查只报告可执行发现：位置、触发条件、影响与修复方向。
 
 ## 4. 工具与任务连续性
@@ -37,13 +37,13 @@
 ## 5. 模型与子智能体
 
 - 新通用工程会话建议 GPT-6.1 Sol / medium，复杂推理按需 high，保留用户已选模型。Astra 可在相对 Sol 的深度有价值时前置处理高影响困难方案、跨系统综合和独立反例审查，不以先失败为条件，也不固定参与每次规划或审查。
-- 规划后、关键检查失败、共享合同变化及验收前复核疑难。同类失败两次暂停切片，严重反例立即处理；问题 ID 与计数不随换 agent 清零。按可复现证据裁决，主线程不理解或无法验证的关键结论不得验收；专家续轮须有新证据或可测试进展，解决后回到最低足够路线。
+- 关键失败、共享合同变化或实质反例出现时复核原因与方案，普通检查点不自动增加专家审查。同类失败两次暂停切片，严重反例立即处理；问题 ID 与计数不随换 agent 清零。按可复现证据裁决，主线程不理解或无法验证的关键结论不得验收；专家续轮须有新证据或可测试进展，解决后回到最低足够路线。
 
 - 主线程负责关键路径、共享决定、冲突裁决、整合与最终验收；权限判断、生产写入、PR/merge/deploy 由主线程串行处理。
 - 本提示词作为适用指令时，明确授权在用户任务范围内，对普通开发、检索、诊断、审查和验证积极使用子智能体并行；审查仍只读。用户禁止、仅要求审计并行配置或更高优先级宿主限制时不启动。技能被自动发现本身不构成授权，不扩大外部操作权限。
-- 有可并行的独立产物时默认尽早分工，主线程优先同步推进关键路径；宿主允许时，也可让多个独立子任务并行，主线程等待后集中整合。不等再次点名 agent，不要求事先证明加速。优先用 Luna 分担有界收集、比对、验证、局部审查和已定方案修改，避免主线程包办所有机械工作。
+- 有可并行的独立产物时默认尽早分工，主线程优先同步推进关键路径；宿主允许时，也可让多个独立子任务并行，主线程等待后集中整合。不等再次点名 agent，不要求复杂任务、完整仓库地图或事先证明加速。优先用 Luna 分担有界收集、同类调用检查、比对、局部审查和行为已定的简单修改；验证只分配实际需要的检查。
 - 按真实可用槽位、独立工作量与验收能力展开并行，不固定只开一两个。维护简短待办队列，结果返回后及时验收并复用或补充任务，不等整批结束；主线程计入槽位时必须预留。出现验收积压、资源争用或限流时先消化已有工作。
-- 按完整任务块而非微小步骤分工；单条命令可直接用工具。没有独立工作、主线程下一步立即依赖结果或任务太小时本地完成；不凑舰队数量，不重复派同一任务，不递归无限扩张。
+- 按独立结果分批，多个简单批次可以派多个 Luna，不因单项简单而整批留给主线程。行为与所有权明确即可分派，由 worker 定位局部改动；普通合同只需目标、相关基线、文件/语义边界与验收返回，不默认 JSON 证据包。单条命令直接用工具；单个任务太小、没有独立工作或下一步立即依赖时本地完成，不凑数量、不重复派工、不递归无限扩张。
 - 默认三档：GPT-6 Luna 做输入有界、合同已定、易验收且失败可控的工作；GPT-6.1 Sol 做开发、调查与复杂分析；GPT-6 Astra 做最困难的独立综合。精确模型与 effort 以宿主 schema 为准；旧版 Sol 是显式兼容路径，不是 6.1 的别名。Terra 退出推荐与自动回退，用户显式指定仍须尊重。
 - 路由、成本、合同与生命周期以 codex-subagent-router 为维护入口，服从真实工具 schema；技能缺失时继续可行本地工作。支持选择时显式指定足够的模型与 effort，核对 fork 限制；不逐级试错，不假装切换参数。
 - 先区分宿主子智能体和 6.1 Sol 的 Responses 原生 Multi-agent beta：原生子任务共享请求模型与工具，不能假装逐个切到 Luna/Astra。工具结果按真实调用归属返回，保留各 agent 历史；动态 effort、压缩与 beta 限制按技能参考核对，不因模型升级自动开启或混用。

readme.md

@@ -1,6 +1,6 @@
 # Codex Subagent Router
 
-当前版本：**2.3.1**。执行范围以用户任务及所述边界为准，任务必需的发布、合并、部署等不再因操作类别触发二次确认。保留 GPT-6.1 Sol 首选路由、Luna 舰队、Astra 按需介入及原生 Multi-agent 兼容边界。见 [2.3.1 发行说明](docs/releases/2.3.1.md)、[2.3 发行说明](docs/releases/2.3.0.md)、[舰队调度](skills/codex-subagent-router/references/fleet.md) 和 [专家介入与裁决](skills/codex-subagent-router/references/escalation.md)。
+当前版本：**2.4.0**。采用按风险选择的最小充分验证，排障检查共同机制，已获授权的简单编码批次尽早交给 Luna 并行。见 [2.4 发行说明](docs/releases/2.4.0.md)、[验证与因果修复](skills/codex-subagent-router/references/engineering-workflow.md) 和 [舰队调度](skills/codex-subagent-router/references/fleet.md)。保留 GPT-6.1 Sol 首选路由、Astra 按需介入、任务边界与原生 Multi-agent 兼容规则。
 
 面向 **GPT-6 Luna / GPT-6.1 Sol / GPT-6 Astra** 的 Codex 路由技能与工程提示词。把可独立完成的工作交给合适的模型，并让触发、运行状态、证据与最终责任保持清楚。Terra 已退出推荐与自动回退路线；旧宿主按实际能力显式兼容。
 
@@ -10,6 +10,8 @@
 
 - 区分只读审查、已授权委派和普通本地工作，避免“选中了技能就自动启动 agent”。
 - 按任务形状分配模型与 effort，创建任务时显式选择，避免所有子任务继承昂贵的主模型。
+- 按实际影响选择充分检查，通过即停止；复用可信 worker 结果，整合只补查新增交互与项目必需项。
+- 从症状定位原因，简查同机制的相邻调用点；在原因所属层修复已证实的问题类别，避免堆积特判。
 - 区分文件写集与语义写集、共享目录与真实隔离、合同约束与宿主强制能力。
 - 管理运行中补充、空闲复用、等待、中断与收口；没有 close 工具时不要求虚构关闭。
 - 分开记录请求的模型、宿主确认的运行身份、子任务完成和主线程验收；缺失身份使用 unknown。
@@ -75,9 +77,9 @@ python3 scripts/install.py --include-prompt --apply
 
 技能单独安装时，仍需用户或适用指令授权委派。可选全局提示词现在明确提供普通开发、检索、诊断、审查和验证的持续并行授权；审查仍只读，用户禁止、仅审计并行配置及更高优先级宿主限制优先。模板文件只有被作为适用指令加载时才生效，放在仓库或压缩包里不改变当前会话权限。
 
-有授权和独立工作时默认积极并行：尽早派发 Luna 收集、比对、验证、局部审查和已定方案修改，主线程继续关键路径。并发随真实槽位和验收能力扩展，不固定只开一两个；结果返回即验收并补充队列，不等整批结束。四个总槽位最多容纳主线程加三个子智能体，提示词不会突破宿主限制。
+有授权和独立工作时默认积极并行，包括多个简单编码批次：尽早派发 Luna 收集、同类调用检查、比对、局部审查和行为已定的修改，主线程继续关键路径；验证只分配实际需要的检查。行为和所有权明确即可派发，由 worker 定位局部改动，无须主线程先查完整仓库或预先解完任务。普通合同和返回使用简短文字，不默认 JSON 证据包。并发随真实槽位和验收能力扩展，不固定只开一两个；结果返回即验收并补充队列，不等整批结束。四个总槽位最多容纳主线程加三个子智能体，提示词不会突破宿主限制。
 
-任务太小、存在立即依赖、共享所有权冲突或验收积压时缩小并行。单条命令优先直接用工具；复杂判断直接选 Sol/Astra，不让 Luna 重试堆数量。配置示例的数值不是并行策略上限，安装不自动修改运行配置。
+单个任务太小、存在立即依赖、共享所有权冲突或验收积压时缩小并行；多个简单任务先按独立结果分批，不因单项简单而整批本地串行。单条命令优先直接用工具；复杂判断直接选 Sol/Astra，不让 Luna 重试堆数量。配置示例的数值不是并行策略上限，安装不自动修改运行配置。
 
 ## 模型策略
 
@@ -120,16 +122,16 @@ GPT-6 新增的异步工具、执行中纠偏与动态推理强度都有 API 或
 
 ## 验证
 
+应用技能时按改动影响选择最小充分检查，并完成项目必需项。低风险改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动覆盖相关消费者及集成。检查通过且无实质未决问题即停止；追加检查要说明具体未覆盖的不变量。主线程检查 worker 补丁与覆盖，复用同一相关产物/环境的可信结果，整合只补查新增交互。详见 [验证范围](skills/codex-subagent-router/references/engineering-workflow.md)。
+
+维护本仓库时，开发约定要求运行：
+
 ```sh
 python3 -m unittest discover -s tests -v
 python3 scripts/check_repository.py
-python3 skills/codex-subagent-router/scripts/validate_evidence_packet.py --self-test
-python3 skills/codex-subagent-router/scripts/validate_evidence_packet.py examples/completed-unknown.json
-python3 skills/codex-subagent-router/scripts/validate_decision_record.py examples/decisions/resolved.json
-python3 scripts/install.py --include-prompt --check
 ```
 
-最后一条命令只检查本机安装差异：一致返回 0，有差异返回 1；不会写入。单元测试和 examples 使用合成数据，不能证明任何模型已运行。
+单元测试已覆盖校验器与安装行为；无需每次额外运行各校验器的 self-test 和相同样例。`python3 scripts/install.py --include-prompt --check` 仅在需要比对本机安装时运行：一致返回 0，有差异返回 1，不会写入，也不是发布阻断项。单元测试和 examples 使用合成数据，不能证明任何模型已运行。
 
 新证据使用 v2；未带版本的旧格式按 v1 读取并提示迁移。校验成功只证明结构可接受，不能证明 child ID、身份或业务结论真实。真实环境的前向测试应在获授权的有界任务中进行，并保留实际工具回执。
 

scripts/check_repository.py

@@ -14,6 +14,7 @@ def check() -> list:
     for name in ("SKILL.md", "agents/openai.yaml", "references/lifecycle.md",
                  "references/platforms.md", "references/evidence-packet.md",
                  "references/routing-matrix.md", "references/escalation.md", "references/fleet.md",
+                 "references/engineering-workflow.md",
                  "references/gpt6-adaptation.md", "references/model-economics.md",
                  "references/sol61-adaptation.md",
                  "scripts/validate_decision_record.py", "scripts/validate_evidence_packet.py"):

skills/codex-subagent-router/SKILL.md

@@ -5,12 +5,18 @@ description: Route authorized Codex subagents across GPT-6 Luna, GPT-6.1 Sol and
 
 # Codex Subagent Router
 
-Version 2.3.1. For new general engineering sessions recommend GPT-6.1 Sol / medium, with high for demonstrated reasoning needs. Preserve the selected parent. Use Astra proactively for high-leverage difficult decisions, independent counterexample reviews and residual hard reasoning when its depth adds value over Sol; neither prior failure nor a model quota is required.
+Version 2.4.0. For new general engineering sessions recommend GPT-6.1 Sol / medium, with high for demonstrated reasoning needs. Preserve the selected parent. Use Astra proactively for high-leverage difficult decisions, independent counterexample reviews and residual hard reasoning when its depth adds value over Sol; neither prior failure nor a model quota is required.
 
 Make delegation useful, observable and bounded. Preserve the selected parent model. The parent owns the critical path, shared decisions, integration and final acceptance. This skill neither changes configuration nor grants external permissions.
 
 Determine execution scope from the user's task and stated boundaries. The parent carries out task-required external writes, publication, merges, deployment and production writes without adding a category-based approval or reconfirmation gate. Clarify only material ambiguity in the target or scope, and honor higher-priority host restrictions. Delegation authorization and parent ownership remain unchanged.
 
+## Engineering judgment
+
+Choose the smallest sufficient verification for the changed behavior and actual impact, plus mandatory project checks. Low-risk reversible work does not need a new test suite, full build, extra reviewer or structured evidence packet by default. Stop when relevant checks pass and no material concern remains; broaden only for a specific uncovered invariant, failure or change. Reuse trustworthy worker checks on the same relevant artifact/environment instead of rerunning them ceremonially.
+
+When debugging, follow symptom to cause and briefly inspect the nearest sibling uses of that mechanism before patching. Repeated special cases, duplicated workarounds or producer/consumer disagreement call for a contract or workflow repair. Prefer the smallest fix that covers the demonstrated failure class; keep unrelated redesign outside scope. Read [engineering workflow](references/engineering-workflow.md) when selecting validation depth or distinguishing a local bug from a systemic defect.
+
 ## Trigger before routing
 
 Classify the request before using child tools:
@@ -37,16 +43,16 @@ For queue states, integration backpressure and proactive expert formations, read
 
 ## Proactive Luna fleet
 
-Once authorized, parallel execution is the default for ready independent work. At the first useful decomposition and after each material result or scope change, look for slices that can run alongside the parent's critical path. Dispatch those slices promptly instead of finishing the parent's entire investigation first. Do not require proof of measured speedup before a clearly useful split.
+Once authorized, parallel execution is the default for ready independent work, including batches of simple coding tasks. At the first useful decomposition and after each material result or scope change, look for slices that can run alongside the parent's critical path. Dispatch those slices promptly instead of finishing the parent's entire investigation first. Do not require a complex task, a full repository map or proof of measured speedup before a clearly useful split.
 
-- Fan out bounded Luna assignments by independent evidence source, module, test suite or settled file/semantic ownership. Useful lanes include source inventory, artifact comparison, fixed validation, focused first-pass review and settled patches. Batch tiny homogeneous items into meaningful assignments.
+- Fan out bounded Luna assignments by independent evidence source, module or settled file/semantic ownership. Useful lanes include source inventory, sibling-use checks, artifact comparison, focused review and small settled coding changes. Delegate validation only when those checks are needed. Batch tiny items by outcome; several simple batches can justify several Luna workers even when each item alone would stay local.
 - Keep a small ready queue. Use as many actually available child slots as useful independent work and parent review capacity support; there is no fixed one-child or two-child ceiling. Reserve the parent when the host counts it. For example, four total active slots permit at most three concurrent children alongside the parent, not an unlimited fleet.
 - Refill available capacity when a result is handed back: accept/triage it, reuse an eligible idle child or dispatch the next ready slice. Do not wait for a whole wave if another independent slice is ready. Verify actual capacity; completed or interrupted does not necessarily mean released.
 - The parent owns contract decisions, cross-result synthesis and acceptance, and advances a parent-suitable critical-path slice when one is available. Integrate incrementally. If review backlog, conflicting ownership, I/O contention or rate limits becomes the bottleneck, reduce new dispatch and drain it.
 - One owner per file AND shared semantic contract. Parallel disjoint writes only when the host permits them; shared registries, integration and external gates remain serial. Read-only workers also need stable baselines and coordinated mutable sessions.
 - Choose Sol directly for slices requiring open-ended investigation or design, and Astra for the hardest synthesis. A fleet is a capacity strategy, not an instruction to force every task onto Luna or to duplicate the same review.
 
-Stay local for a trivial task, no useful parallel benefit, an immediate dependency with no independent work, or inadequate host support. State the relevant reason briefly when a requested parallel run cannot proceed; do not produce a routing report for every small task. Standing authorization does not authorize recursive unbounded fan-out, new user-owned tasks, configuration changes or external writes.
+Stay local for a single trivial task, no useful parallel benefit, an immediate dependency with no independent work, or inadequate host support. Judge a batch as a whole before using the trivial-task exception. State the relevant reason briefly when a requested parallel run cannot proceed; do not produce a routing report for every small task. Standing authorization does not authorize recursive unbounded fan-out, new user-owned tasks, configuration changes or external writes.
 
 ## Select a supported route explicitly
 
@@ -59,7 +65,7 @@ Stay local for a trivial task, no useful parallel benefit, an immediate dependen
 | High-leverage difficult design, cross-system synthesis, independent high-impact counterexample review | GPT-6 Astra medium/high |
 | Shared decisions, integration and external/final gates | Current parent, serial |
 
-Luna is the first candidate when inputs are bounded, the contract is settled, correctness is cheaply checkable, and failure is contained. All four conditions matter; a short diff can still hide a shared semantic decision. Use Sol directly when investigation, design choices or cross-file causal reasoning dominate. Use Astra directly for the hardest independent synthesis when expected quality or saved rework justifies it. Do not make high/max Luna a mandatory step before Sol.
+Luna is the first candidate when inputs are bounded, the contract is settled, correctness is cheaply checkable, and failure is contained. Settled means the required behavior and ownership are clear, not that the parent has already located every edit or done the worker's investigation. A bounded read-only question can be ready while implementation contracts remain open. A short diff can still hide a shared semantic decision. Use Sol directly when investigation, design choices or cross-file causal reasoning dominate. Use Astra directly for the hardest independent synthesis when expected quality or saved rework justifies it. Do not make high/max Luna a mandatory step before Sol.
 
 These are starting heuristics, not measured task-cost rankings. Lower prices broaden the useful Luna workload; fill supported capacity with useful work under existing authorization, never infer extra host slots from price. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, stop that slice and return the evidence to the parent; escalate earlier when the contract no longer fits. Preserve useful evidence on handoff instead of restarting discovery.
 
@@ -87,17 +93,17 @@ For 6.1-specific request compatibility, native tool-result attribution and compa
 
 ## Dispatch, observe, accept
 
-Give a compact contract: goal/symptom; baseline and non-goals; read/write/forbidden paths and semantic owner; requested model/effort/working role and real isolation; permitted actions; acceptance; return evidence; escalation. Include a time/checkpoint budget when useful, but do not call it an enforced timeout unless the host supplies one.
+For ordinary bounded work, give a short contract: outcome, relevant baseline, file AND semantic ownership/action limits, and sufficient acceptance/return evidence. Specify supported model/effort in the tool call; keep the real child ID and state. Add isolation details, checkpoints or an expert packet only when the task needs them. Do not require a formal report before a useful simple dispatch or call an advisory budget an enforced timeout.
 
 Read [lifecycle](references/lifecycle.md) before a multi-round or cancellation-sensitive run. Keep child IDs, ownership, state and acceptance in a small ledger. Send running agents only incremental context; reuse idle agents for follow-up; interrupt obsolete work and verify its state. Never infer completion from a wait timeout or slot release from interruption. Only call close if that tool exists.
 
-Ask for bounded facts, paths, changes, real check outcomes, gaps and escalation. Review artifacts/diffs and provenance; resolve conflicts from original evidence, not votes. Reuse checks only for the same relevant baseline, artifact and environment. Before delivery verify no unneeded child remains running or writing.
+Ask for changed paths or findings, relevant real check outcomes and remaining gaps. Review artifacts/diffs and provenance; resolve conflicts from original evidence, not votes. Reuse checks only for the same relevant baseline, artifact and environment. Check integration risks introduced by combining patches; do not repeat each worker's entire suite or investigation. Before delivery verify no unneeded child remains running or writing.
 
-Use [evidence packets](references/evidence-packet.md) when structured evidence is required, a run is material, or identity is disputed. Ordinary bounded work can return concise prose with the same relevant facts; do not generate ceremonial JSON for every local decision. The validator checks structure, not truth or semantic correctness.
+Use [evidence packets](references/evidence-packet.md) when an explicit consumer requires structure or disputed identity/provenance needs an audit trail. Ordinary bounded work returns concise prose with the relevant facts; a large batch or long run alone does not require JSON. The validator checks structure, not truth or semantic correctness.
 
 ## Context and ownership discipline
 
-Read [escalation and adjudication](references/escalation.md) when planning exposes uncertainty, a key check fails, shared contracts change or acceptance has unresolved counterexamples. Preserve issue IDs and failure counts across agents. Repair missing inputs first; adjudicate by reproducible evidence, not model rank. The parent must understand and verify decisive conclusions. Continue expert rounds only with evidence-based progress, and recover to an adequate cheaper route after resolution.
+Read [escalation and adjudication](references/escalation.md) for unresolved causal/design uncertainty, repeated failures, consequential shared-contract changes or material counterexamples. Routine checkpoints do not require another review round. Preserve issue IDs and failure counts across agents. Repair missing inputs first; adjudicate by reproducible evidence, not model rank. The parent must understand and verify decisive conclusions. Continue expert rounds only with evidence-based progress, and recover to an adequate cheaper route after resolution.
 
 Load only needed references; keep long logs on disk. Avoid whole-history forks and repeating contracts, packets or prior findings. Account for parent context/reasoning, child usage, waiting, retries and integration when evaluating cost.
 

skills/codex-subagent-router/references/engineering-workflow.md

@@ -0,0 +1,41 @@
+# Verification scope and causal repair
+
+Use when validation is expanding without a clear reason, a bug may reflect a shared mechanism, or parent/worker checks overlap. These decisions apply to local and authorized delegated work. Preserve mandatory project checks and existing functional/security requirements.
+
+## Choose sufficient evidence, then stop
+
+Choose checks by behavior and consequence, not diff length or how many tools are available. For a small task, make this choice directly; no written test plan or risk report is needed.
+
+| Change shape | Sufficient starting point |
+| --- | --- |
+| Text, presentation or reversible local edit with no executable behavior change | Inspect the diff/result and relevant format or resource checks; no new unit tests or unrelated build by default |
+| Bounded behavior change or local bug | Reproduce/check the affected behavior and nearest relevant boundary; use existing targeted tests where adequate |
+| Shared contract, authorization, persistence, financial correctness or difficult rollback | Check the changed invariants, affected consumers and relevant integration/failure paths; run required broader checks |
+
+A short patch can belong in the last row. A large mechanical edit can remain bounded. Add a regression test when it protects an actual recurring failure or contract; do not add tests that merely copy wording or implementation.
+
+Expand only when the current evidence misses a named affected invariant, a relevant check fails, a counterexample remains, or the change/environment invalidates prior evidence. Before another build, review, fuzz run or suite, identify what new decision its result can change. If no such gap exists, stop. Do not create extra checks solely to give idle workers something to do.
+
+Completion requires evidence covering the intended behavior, mandatory checks passed (or a clearly reported limitation), and no unresolved material contradiction. Unknown optional counters/model identity do not justify more testing unless explicitly required. Report a real verification gap without inventing a pass; hypothetical unrelated edge cases do not prevent delivery.
+
+## Reuse worker verification
+
+Return changed paths/findings, the relevant command/result and any gap. Trustworthy outcomes can be reused when the checked files, relevant dependencies, artifact and environment match. The parent inspects the patch and coverage; parent responsibility does not require duplicate execution.
+
+After integration, check new interactions and changed dependencies. An unrelated documentation edit does not invalidate a parser test. An overlapping shared-contract change does invalidate affected worker checks. If writers or shared mutable state made the artifact unstable, pin it or wait and run the affected checks once. Do not run a broad suite independently in every worker and again in the parent by default.
+
+## Repair the demonstrated failure class
+
+At the first substantive bug, trace the failing behavior to its owner and briefly inspect nearest sibling callers/consumers. A local typo with an obvious cause can end with a local correction; it does not need an architecture audit.
+
+Broaden diagnosis when evidence shows repeated caller exceptions, duplicated fallback/retry logic, inconsistent producer/consumer assumptions, stale/generated state, or patch A breaking invariant B. Distinguish implementation defects, contract/design defects, workflow/ownership defects and missing environment inputs. Use the smallest discriminating check when competing causes imply different repairs.
+
+Choose the smallest complete repair at the layer that owns the cause. Update demonstrated affected consumers/generated outputs and remove superseded workarounds within scope. Do not mask an invariant violation with another catch, retry, default value or caller-specific branch unless that behavior is the intended contract. A temporary mitigation may be appropriate when the user requests it or a full repair is currently blocked; state its limits and remaining cause.
+
+Verify the original failure and a representative sibling/boundary when the repair addresses a shared mechanism. Inspect additional affected sites where evidence warrants it; do not scan or refactor unrelated systems. For a material fix, summarize cause, demonstrated impact, repair layer and sufficient checks in a few sentences. No formal root-cause report is needed for routine work.
+
+## Keep simple delegation simple
+
+Once authorized, independent routine work is a normal Luna workload. The parent settles shared behavior/ownership, while workers can locate local edits and perform the necessary targeted checks. Give a batch a coherent outcome and a small return; avoid loading escalation, cost and packet references for every worker.
+
+For example, independent UI copy corrections, bounded adapter fixes under an agreed interface, and a sibling-use inventory may run in separate owned lanes. Three parts of one changing registry need one owner. Ten literal replacements that one command can perform need that command. A shared design decision stays with the parent or a separately authorized bounded investigation.

skills/codex-subagent-router/references/escalation.md

@@ -4,13 +4,14 @@ Recommend GPT-6.1 Sol / medium for new general engineering sessions; preserve an
 
 ## Reassess at observable checkpoints
 
-Reassess after planning, a key failed check, shared-contract changes and before acceptance. Track a material issue with a stable issue ID and baseline. Counters follow the issue across retries, replacement agents and model changes. After two same-class acceptance failures, pause that slice and classify before another attempt. A serious counterexample or unsafe assumption triggers immediately.
+Reassess when causal/design uncertainty remains, a key check fails, a consequential shared contract changes or a material counterexample appears. Routine planning and acceptance do not require an extra expert review. On the first substantive bug, inspect the cause and nearest sibling uses as described in [causal repair](engineering-workflow.md); do not wait for repeated failure to notice a shared defect. Track a material issue with a stable issue ID and baseline. Counters follow the issue across retries, replacement agents and model changes. After two same-class acceptance failures, pause that slice and classify before another attempt. A serious counterexample or unsafe assumption triggers immediately.
 
 | Observation | First response |
 | --- | --- |
 | Missing inputs, access, tool failure | Diagnose environment or obtain evidence; model escalation does not repair access |
 | Material requirement ambiguity | Inspect consumers/contracts; ask the user only for unresolved product choices |
 | Different root causes imply different fixes | Design the smallest discriminating check |
+| Repeated caller exceptions, duplicated workarounds or producer/consumer disagreement | Trace shared cause and ownership; repair the demonstrated failure class at its owning layer before adding another special case |
 | Conflicting records or stale baseline | Reconcile original evidence; suspend the dependent conclusion |
 | Fixes alternate between breaking invariants | Revisit shared contract and integration ownership |
 | High impact with no reliable verifier | Block affected acceptance/action; seek a verifier or explicit product decision |

skills/codex-subagent-router/references/evidence-packet.md

@@ -1,6 +1,6 @@
 # Evidence Packet v2
 
-Use structured packets for material runs, identity disputes or an explicit consumer requirement. Concise prose is sufficient for ordinary work when it preserves the relevant evidence.
+Use structured packets when an explicit consumer requires them or disputed identity/provenance needs an audit trail. Ordinary work returns concise facts, changed paths, relevant check outcomes and gaps. Batch size or duration alone does not require JSON; preserve truthful evidence without adding a reporting ceremony. Packet schema and validator compatibility remain unchanged.
 
 ## Contract
 

skills/codex-subagent-router/references/fleet.md

@@ -1,11 +1,13 @@
 # Proactive fleet scheduling
 
-Use for authorized complex parallel work. This is a decision procedure for the parent, not a background scheduler, permission grant or capacity override. Preserve the actual host schema, selected parent and final gates.
+Use for authorized parallel work, including several independent batches of simple coding tasks. This is a decision procedure for the parent, not a background scheduler, permission grant or capacity override. Preserve the actual host schema, selected parent and final gates.
 
 ## Discover and dispatch early
 
 After minimum goal/baseline discovery, identify independent questions and useful implementation slices. Do not finish reading every subsystem before dispatching ready investigations. Once a slice's input contract is stable, it may enter implementation while unrelated investigation continues. Shared decisions stay with the parent; preliminary independent drafts are not accepted contracts.
 
+Simple work is a reason to consider Luna. Judge parallel value across the ready batch, not each tiny item alone. A worker can locate local edit sites under agreed behavior and ownership; the parent need not pre-solve its task. For routine work, a short outcome/baseline/ownership/acceptance contract and concise result suffice. Use formal records only when required. A fixed one-command transformation still belongs in tools.
+
 Maintain a compact queue: task ID, dependency and contract baseline, file AND semantic owner, shared resources, acceptance, requested route, child ID, observed runtime state and integration state. Mark pending, ready, running, returned, accepted, blocked or superseded as task states; keep actual host state separate. Ready means the prerequisites, ownership and permitted actions are established and the output has independent value.
 
 At intake, dependency resolution, a child return or a meaningful baseline change:
@@ -22,7 +24,7 @@ If the next action is immediately dependent on an unassigned task, keep it local
 First identify whether execution uses host-managed per-child routes or [native Responses Multi-agent](sol61-adaptation.md). Native mode uses the request's model/tools across the tree; use several focused Sol lanes there, not fictional Luna/Astra child overrides. The formations below describe work ownership; mixed models require actual host support.
 
 - Independent investigation: several focused investigators may cover distinct sources, consumers or falsifiable hypotheses. They should not all produce the same broad summary.
-- Settled implementation: multiple GPT-6 Luna workers own bounded, settled, independently checkable slices; use GPT-6.1 Sol directly when implementation requires investigation or design judgment. Shared registries, schema and generated outputs require one owner even when paths differ.
+- Settled implementation: multiple GPT-6 Luna workers own bounded, independently checkable coding batches under agreed behavior, including simple adapter, UI or local consistency fixes. Use GPT-6.1 Sol directly when causal investigation or design judgment dominates. Shared registries, schema and generated outputs require one owner even when paths differ.
 - Difficult consequential decision: an Astra specialist analyzes the bounded uncertainty while the parent and other workers advance unaffected work. Gate dependent implementation on the parent's accepted contract. Read [expert intervention](escalation.md) for triggers and progress-based continuation.
 - Independent review: assign a stable commit/artifact and the relevant requirements, without supplying the parent's preferred verdict. Review can overlap unrelated work; stale observations must be rechecked before acceptance.
 
@@ -36,6 +38,8 @@ When returned patches are accumulating faster than the parent can inspect, or a
 
 Never run acceptance tests against a moving artifact and report them as final. Pin a commit/snapshot or wait until relevant writers stop; a worktree alone does not isolate external databases, generated directories or shared sessions. Before merge/delivery, resolve material counterexamples, verify the integrated baseline and audit the agent tree for remaining writers.
 
+Reuse checks from workers when the relevant checked artifact/dependencies/environment remain valid. Parent integration checks cover newly introduced interactions and mandatory project requirements, not a repeat of every worker's suite. Do not create more validation/review lanes solely to fill capacity. Follow [verification scope](engineering-workflow.md) and stop when sufficient evidence is complete.
+
 ## Evaluate effectiveness
 
 Optimize accepted quality and end-to-end time subject to the user's cost constraints. Include parent work, all children, context duplication, retries, expert rounds and integration in cost measurements. Expensive early reasoning can be worthwhile when it prevents downstream rework; cheap high-volume workers can be wasteful when contracts are unsettled. Both are hypotheses until measured.