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

Plugin-Submission: d77fbfc482bf93fdb2203b097c07d51b2f01d3e7c29ed776305b9f3d38b35075

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.