Phanes v3.4.1

Patch release, one theme: a "good enough" threshold for every Opus-run role. It answers a field report from a downstream Phanes-managed project. Measured over three consecutive plan steps there, agent dispatches went 8, 13, 17; Critic passes 1, 3, 4; prose produced about 2,450, 3,700 and 7,760 lines; the plan's scope estimate was missed by 3.2x and then 9.5x; and the same "still owed elsewhere" list appeared verbatim in all three session summaries. The reviewers were catching real bugs, so review presence is not the problem. The problem is that the architect, the Critic, the security auditor and the Orchestrator each had a duty to observe and record, and none of them had a rule for when an observation creates no further work. Obligations accrued faster than steps discharged them, and by the third step the chain was producing four lines of review prose per line of code.

Five thresholds close that, each placed where the generated agents are told to restate it. Nothing about chain composition, review presence, the two mandatory verdicts, the security pass's cardinality or the self-fix bounds moves.

Added

• Acceptance criteria are checks, not counts. The architect/designer protocol now states that every acceptance criterion is satisfied by a named test or by a structural check that ignores comments, string literals, docs and test fixtures, and that token-count criteria (X appears exactly N times, no file mentions Y) are forbidden: comments and tests legitimately contain the token, the criterion is unsatisfiable as written, and the chain spends a Critic pass proving that instead of reviewing code. The Critic's protocol gains the matching rule: an unsatisfiable criterion is a plan defect routed to the planning-class agent in one line, never proven at length. Ten of the report's recorded "AC wordings owed correction" items were this class.
• The Reflect loop is bounded at two, then a whole-file rewrite. A step gets at most two Reflect passes by its original producer. A third fix_required is a recycle trigger: the producer is retired and a fresh one rewrites the affected files whole from the current on-disk state and the Critic's findings, reviewed once more, after which the step fails. Rework is always a whole-artifact rewrite, never a delta applied on top of an earlier delta, because a producer patching its own patch without reloading the file is how each loop injected the defect the next pass found (two of the report's three steps had fix-introduced bugs found on pass two and three). Stated in §II, in the Orchestrator's duty (5), in the recycle triggers, in the Failure paragraph and in the orchestrator's self-carrying list.
• Severity ladder and stopping rule for the security pass. Findings are graded CRIT, HIGH, MED, LOW or INFO. Only CRIT, HIGH and MED can return fix_required or create work anywhere; LOW and INFO stay in the report file and are never rehomed to another step, never become a plan amendment, a follow-up step, an invariant elsewhere or a session-summary obligation, and are not re-raised by a later pass. A finding whose preconditions cannot be named as reachable in this codebase is INFO at most. Every security report closes with No further findings at or above MED. or the list of those that remain; a report without that line is returned as incomplete. Stated in §III rule 13, the security specialization's protocol and the Security Review Gate.
• Review reports are files. The Critic writes its Actionable Audit Report to reports/reviews/<date>_<step-id>_critic.md (the security specialization to _security.md, later passes appending a dated section) and returns only the path, the two verdicts and the finding IDs with severities. reports/ is outside the stamped trees by design, so the write needs no phanes new-file and trips no stamp guard.
• Batch SS shape and carry-over rule. A batch session summary is verdicts and pointers, never transcripts: per step the two verdicts, the report paths, the MED-or-above finding IDs with one line each, the applied-diff summary and the Reflect count; then the mandatory record lines; then open items. Soft cap 150 lines; past 200 means a report body was pasted in, and it moves to reports/reviews/. An open item carried across two batches is either scheduled as a plan step (the primary is told in register_lines.blockers) or dropped with a one-line reason, never copied a third time.
• Scope halt at 4x. The architect's batch_recommendation gains a scope_ratio field: the designed scope over the scope the plan step states, in the plan's own unit, n/a where the plan states none. A ratio of 4 or more is a plan defect, not a bigger step: the Orchestrator takes the existing failure path for that step (verdict: fail, failed_step set, blocker scope: design is <R>x the plan's stated scope, split the step) and the primary returns it to planning. Below 4 the existing renegotiation handles it. No receipt schema change.

Changed

• The Critic's tools: grant. It carried a scoped Edit (existing files only, "never Write, never new-file creation"), while §IV had always listed reports/ as the Critic's output directory. Generated agents resolved the contradiction by denying all file creation, so every verdict landed in the session summary, which is why the report's summaries ran 365 to 484 lines. The grant now carries the scoped Edit for the self-fix duty plus Write for reports/reviews/ only (the report file and the handoff digest; never a source, test or documentation file, never phanes new-file). The self-fix bound "never new files" is stated to concern the reviewed tree.
• The Batch sizing: record line gains halted: scope <R>x as a disposition and a trailing scope ratio <R | n/a> field, in both places it is specified.
• Deliberately unchanged. Chain composition at every tier, review presence, the two mandatory Critic verdicts per step, the security pass serial and single-shot after Critic pass, the self-fix bounds (trivial class, soft cap 10, hard cap 20), the batch cap 1 to 3, the receipt JSON schema, the four renegotiation clamps. The report's sixth proposal, a burn-down batch for the frozen "still owed" list, is a downstream project action, not a spec change; the carry-over rule above is what keeps such a list from freezing again.

Installed project impact:

• Affected: .claude/agents/<projectSlug>-orchestrator.md (Reflect cap and recycle trigger, scope halt, SS shape and carry-over rule, the extended sizing line), the Critic agent file (report file duty, Write grant scoped to reports/reviews/, unsatisfiable-criteria rule), the security-review agent file where the roster carries one (severity ladder, stopping line), the architect/designer agent file (acceptance-criteria rule, scope_ratio in batch_recommendation), .phanes/config.json (phanesVersion), all template stamps (phanes-template v3.4.1, fetched pinned to the v3.4.1 tag).
• Breaking: none at the file level. Behaviorally, a LOW or INFO security finding no longer creates a follow-up anywhere, a third fix_required on a step now retires the producer instead of resuming it, and a 4x scope miss now fails the step for re-planning instead of being recorded; an installation left at v3.4.0 keeps the old behavior. Existing plans whose acceptance criteria are token counts are flagged for a one-time architect rewrite by the upgrade, not edited by it.
• Verify: .phanes/config.json contains "phanesVersion": "3.4.1"; the Critic agent file names reports/reviews/ and carries Write in its tools:; the orchestrator agent file states the two-pass Reflect cap, the scope_ratio halt and the 150-line SS cap; the security agent file (where present) carries the five severity grades and the closing line No further findings at or above MED.; the architect agent file forbids token-count criteria and its batch_recommendation schema carries scope_ratio.