Fleet roster and model/effort policy: retire pm-*-cc, coder holds PM, Sonnet 5 on the 02 seats, coder03 as coder-plus-auditor, /clear handoff with an idle guard
Elazar 2026-09-12 CLI, his design. (1) NO pm-(project)-cc. He already placed the PM role on the coder agent in the ARO and says it works just as well - and it is ALREADY the de facto state: pm-mars-cc, pm-terra-cc, pm-enamel-cc, pm-venus-cc and pm-pluto-cc all read NOT-FOUND and their projects kept shipping, while aro:enamel's recorded PM is coder-enamel-cc. Formalise it: coder-(project)-cc is PM, pm-* rows are pruned from the AROs. (2) MODELS AND EFFORT: coder Opus 5 med/high, coder02 Sonnet 5 med/high, db Opus 5 med/high, db02 Sonnet 5 mid-high. Rationale is measured: cache_read is 98.7 percent of total burn on the heaviest agent, so effort multiplies every turn, not just hard turns. (3) coder03-(project) acts as BOTH a coding agent and the auditor of what coder and coder02 produced, replacing audit-(project)-ca. HARD CONSTRAINT, non-negotiable and the reason this needs writing down: coder03 must NEVER audit its own code. It audits coder's and coder02's output; something else audits coder03's. A self-review is a green that was never forced red, and the MSG-400 deadlock exists precisely because pm-llmmsgsrv-cc refuses to both author and gate hub.mjs - that refusal was correct and this policy must not quietly repeal it. (4) /clear HANDOFF: coder may send /clear to coder02 and coder03. GUARD: only when the target is verified IDLE by scrp-monitor-agent-idle.sh first. A keystroke into a busy pane lands in the middle of whatever that agent is typing, and /clear destroys context that may hold uncommitted reasoning - so the idle check is part of the operation, not a courtesy. Same guard covers live model/effort changes by tmux send-keys. (5) OPEN QUESTION, do not guess: Elazar wrote coder03-(project)-ca with a -ca suffix. Every -ca agent in the fleet currently reads NOT-FOUND (audit-mars-ca, audit-terra-ca, audit-enamel-ca) while the -cc twins are live. Confirm whether -ca means the codex runtime before any agent is created under that name.
Activity
-
MEASURED ROSTER 2026-09-12, read from each pane's own statusline (model + effort), 21 venus claude agents. Corrects my earlier claim to Elazar that all agents are on Opus 5 high - they are not. Models: 11 Opus 5, 10 Sonnet 5. Effort: 17 high, 3 medium, 1 low. Six agents run the Opus 5 (1M context) variant with a 400k window. coder lane: coder-mars-cc Opus5 high, coder-terra-cc Opus5-1M high, coder-enamel-cc Opus5 high, coder-llmmsgsrv-cc Opus5 high, coder-apiimages-cc Opus5 LOW. coder02/03 lane: coder02-enamel-cc Sonnet5 high, coder03-mars-cc Sonnet5 high, coder03-terra-cc Sonnet5 high, coder02-mars-cc Opus5-1M high, coder02-terra-cc Opus5-1M high. db lane: db-mars-cc Opus5-1M high, db-terra-cc Opus5 medium, db-enamel-cc Opus5 medium. db02/03 lane: db02-enamel-cc Sonnet5 medium, db02-mars-cc Sonnet5 high, db03-terra-cc Sonnet5 high, db02-terra-cc Opus5-1M high. other: audit-terra-cc Sonnet5 high, nw-venus-cc Sonnet5 high, bin-venus-cc Opus5 high, pm-llmmsgsrv-cc Opus5 high. CONCLUSION: Elazar's proposed design (coder Opus med/high, coder02 Sonnet med/high, db Opus med/high, db02 Sonnet med/high) is ALREADY the de facto state for 18 of 21 agents. There are exactly THREE deviations, all in the same direction and all Opus 5 1M where his design says Sonnet 5: coder02-mars-cc, coder02-terra-cc, db02-terra-cc. Those three are the entire delta of the roster policy. He does not need a fleet migration, he needs three changes. The 1M-context variant is the second-order finding and nobody asked for it. cache_read is 98.7 percent of total burn on the heaviest agent, cache_read scales with context size, and a 400k window raises the ceiling that a long session drifts up to rather than capping it. Six agents hold 400k windows and four of them were measured above 150k. Whether the 1M variant is worth its cost is a separate question from model choice and should be measured per-agent against its own prior-week baseline, not argued. Effort outliers to resolve rather than normalise silently: coder-apiimages-cc is the only agent at eff:low, and db-terra-cc / db-enamel-cc / db02-enamel-cc are the only three at medium. If medium is the right default for a db lane then two db agents are miscofigured high; if high is right then three are low. Pick the direction from measured net_per_resp, not from the fact that high is the majority.
-
WORKFLOW INSTRUCTIONS WRITTEN 2026-09-12, closing Elazar's gap: 'yes but there are no instructions about workflow, sending work to 02 03 and /clear or whatever.' Two files, both written, neither pushed (PM lane never pushes - a coder or the commons maintainer must push both, and note that shared/md/evolutiva-audit-commons.md is ALREADY modified uncommitted by another lane, so the push must be --only on the two paths below, not a sweep): 1. shared/md/evolutiva-commons.md - new section 'Lane Delegation And /clear - coder->02/03, db->02/03', inserted after Bug Ownership And Parallelism. Records: coder-is-PM-where-no-pm-exists; the dispatcher holds the expensive context and spends it on judgement; a dispatch must name row id, files in scope, and acceptance or it returns as questions; /clear the 02/03 lane after it reports; /clear ONLY into a pane verified idle by scrp-monitor-agent-idle.sh, which also covers live model and effort keystrokes; never /clear an agent mid-task or holding unpushed work; 03 never reviews its own code; split by file or module boundary. 2. agents/pmmasterassistant-evolutiva/CLAUDE.md - the assistant's mandate. Merged into the scaffold rather than replacing it (the scaffold's sonnet + CLAUDE_CODE_AUTO_COMPACT_WINDOW=250000 convention is kept). Defines the sweep as the unit of work: read the six projects' rows, verify every assignee against its pane rather than its self-report, GO any idle agent holding a specified row, treat NOT-FOUND as unstaffed rather than in-progress, treat 'I am waiting for agent X' as a stall and DM X directly, clear a blockedReason whose blocker is discharged, write outcomes onto rows not into a summary, then /clear. Escalation list covers everything needing judgement. Also carries a standing warning that scrp-monitor-agent-idle.sh has failed twice by reporting BUSY fleet-wide, with the direct tmux cross-check and OPS-226 cited - so the assistant's very first sweep does not silently inherit a broken instrument. DESIGN NOTE ON WHY /clear RATHER THAN /compact FOR THE ASSISTANT, since this is the part that will get argued: the sweep is stateless by construction. Everything durable is already on a row. Carrying context between sweeps buys nothing and costs cache_read on every later turn, and it introduces the one error I have made most often - ruling from memory instead of from the row read this turn. /compact would preserve exactly the thing that should not be preserved. STILL OPEN on this row: the three model deviations (coder02-mars-cc, coder02-terra-cc, db02-terra-cc on Opus 5 1M where the policy says Sonnet 5); whether the global modelSettings effortLevel for claude-opus-5 and claude-sonnet-5 should drop from high; and the four effort outliers (coder-apiimages-cc low, db-terra-cc / db-enamel-cc / db02-enamel-cc medium). None applied - fleet stopped.
-
ELAZAR 2026-09-12, CLI, and this RESOLVES the -ca question that was marked do-not-guess: 'codex plan resets on Sep 15, 2026, 12:16 PM GMT-3 take that into account, as we0ll use -ca agents to share cost between claude code and codex subscription.' So -ca IS the codex runtime, deliberately, and coder03-(project)-ca is meant to run on the Codex subscription to split spend across two plans. That is not a naming slip and must not be normalised to -cc. Confirmed independently in code: scrp-monitor-agent-idle.sh maps the suffix directly, '*-cc) RUNTIME=claude', '*-ca) RUNTIME=codex', and parses codex panes by a different signature ('- Ready' for idle). THE CALENDAR, which changes the sequencing of the whole roster plan: - Claude 7d meter: 42 percent left, approximately 5.8 days of runway, so it stretches to about Sep 18 - but it has to cover Monday Sep 14, which is when Elazar starts working and needs capacity. - Codex plan resets Sep 15 12:16 PM GMT-3. - Therefore Sep 12 through Sep 15 midday is the PINCH: Claude is down to 42 percent and codex has NOT yet reset. After Sep 15 12:16, codex is full and is the right place to put bulk mechanical work. CONSEQUENCE FOR THE ROSTER ROLLOUT: do not plan to lean on -ca agents before Sep 15 12:16 on the assumption that codex is cheap right now. Nobody has measured what is left on the codex plan, and that is not a gap in diligence - it is the gap filed as OPS-225. The codex telemetry feed is STALE (whey 25.7h behind, venus 17.7h, lezama MISSING entirely) and roughly 20M net-new tokens per week land in the attribution bucket '(unresolved)'. Also, zero -ca agents are currently running anywhere in the fleet, so there is not even a live pane to read a meter off. So the cost-sharing plan currently rests on a blind meter, and OPS-225 is promoted from housekeeping to a precondition of this row. Sequence it that way: fix codex attribution first, read the remaining codex allowance, THEN decide how much load moves to -ca and when. Spending against an unmeasured plan is how the Claude side got to 42 percent.