v3.3.1

Patch release, one correction to plan-batch economics. v3.3 gave the Orchestrator a dial for how many steps a batch covers, and left a second one missing: whether those steps' chains run once per step or once for the whole batch. Three small steps run per-step pay a producer turn, a Critic turn, and an Executor turn three times over for work amounting to a few dozen lines, and the review depth those repeats buy is real at T3 and largely ceremony at T1. Agent Persistence had already deleted the respawn tax on the repeats; this release deletes the repeats. No gate is removed at any tier.

Added

• Grouped Batch Execution. A batch may now run as ONE chain over all of its steps instead of one chain per step: one producer turn, one Critic turn, one Executor turn. A grouped batch of 3 T1 steps runs 2 spawned turns instead of 6; a grouped batch of 3 T2 steps runs 4 instead of 12. close-verifier runs once at batch close on T2 structural work, one phanes regen-registry and one phanes api-diff rather than one pair per step, which is better verification for less spend rather than a weaker one. The designated visual verifier likewise runs once, over the union of the batch's declared viewports and screens.
• The grouping gate, decided by the Orchestrator at triage. A batch groups only when all three hold: every step is T1 or T2 (any T3 step forces per-step); no step is security-triggering (those fire elevation trigger (a) and the Security Review Gate is one pass per step by design, so they earn isolated attention); and the steps' working sets do not overlap, no step editing a file another step in the batch edits and no step consuming another's output. Per-step stays the default, grouping is the exception the gate has to earn, and ambiguity resolves to per-step. The overlap test is judgment rather than arithmetic: the Orchestrator already holds every step body, since tier triage cannot be performed without reading them, and T1 is itself defined by a scope test of the same kind. A step whose scope cannot be bounded is not groupable.
• Per-step Critic verdicts. In grouped mode the two mandatory verdicts are returned once per step, keyed by step id, and a single undifferentiated pair spanning several steps is fix_required on arrival, the same treatment a missing verdict already got. This is what carries the per-step review guarantee through grouping, and it is the clause that makes grouping a scheduling change rather than a review change.
• Per-step Executor checkpointing. In grouped mode the Executor applies the batch's approved diffs in plan order with a checkpoint per step, and on failure stops at the failing step, leaves the already-applied steps applied, and names that step id. failed_step in the receipt therefore stays exact, and §III rule 12's failure handling needs nothing new.
• Reflect over the failing subset. On a mixed verdict the producer is resumed ONCE with the findings for every failing step and the Critic ONCE to re-review that subset only. Steps that passed stay applied and are not re-reviewed: the non-overlap gate is precisely what makes that safe, since a fix to one step cannot reach a sibling's files. The grouped rework counts as one loop against the bounded Reflect cap, never one per failing step.
• Mandatory mode record. Every batch session summary now carries Batch mode: grouped | per-step (<gate condition that failed>), steps <ids>, chain turns <N>. whether the batch grouped or not. A mode decision leaving no trace is indistinguishable from the mechanism not working, the same reason the sizing and effort lines are mandatory.

Changed

• Batch renegotiation gains a fifth clamp. An adopted growth is clamped when the batch is running grouped and the absorbed step fails the grouping gate. A batch is never part grouped and part per-step.
• Deliberately unchanged. The batch cap stays 1 to 3 steps, grouping never earns a wider batch. No tier's chain composition changes, no gate is skipped at any tier, review presence stays universal, and the batch receipt schema is untouched.

Installed project impact:

• Affected: .claude/agents/<projectSlug>-orchestrator.md (restates the grouping gate, the fifth renegotiation clamp, the two agent contracts, subset Reflect, and the mandatory batch-mode line), the Critic agent file (per-step verdict duty for grouped assignments), the Executor agent file (ordered per-step checkpoint duty), documentation/session-summaries/* (batch SS gains the Batch mode: line), .phanes/scripts/*, .claude/template/* and .phanes/config.json (re-stamped to 3.3.1)
• Breaking: none. No schema change, no frontmatter change, no chain recomposition. An installation left at v3.3 behaves exactly as it did, since per-step is the default and grouping only ever engages where the gate passes.
• Verify: .phanes/config.json contains "phanesVersion": "3.3.1"; the orchestrator agent file mentions the grouping gate's three conditions, the ambiguity-resolves-to-per-step rule, and the Batch mode: session-summary line; the Critic agent file states that grouped assignments return verdicts per step keyed by step id; the Executor agent file states that grouped assignments are applied in plan order with a checkpoint per step; .claude/template/agent-definition.md and .claude/template/report.md each carry the phanes-template v3.3.1 <name> stamp within their first two lines