jpmschweitzerandClaude Fable 5
346d87df7a
- make test-tooling: planet-gen determinism guard + import_economics
--dry-run, wired into pre-push on TOOLING_CHANGED; ruff widened to
E4/E7/E9/F/W (90 safe auto-fixes applied; E402/E702/F841 ignored with
documented counts)
- one-generator reality fixed in DEVOPS.md, asset-pipeline rule, CLAUDE.md
(import_economics sole generator since #951/D-223); dead check-protocol
target deleted; DEVOPS hook/config sections rewritten from the actual
hook sources; team-patterns gate description updated (client+tooling)
- project.yaml: 0.2.0 → 0.4.0 per the 0.{phase}.{n} scheme, description
refreshed from the v0.1 Sova narration to cascade reality
- stale comment sweep: voxel.rs stub claims (all 8 families implemented),
cascade.rs TODO recited to T-1044, main.rs D-192 handshake claim,
relationships.rs/chunk_streaming.rs version targets → phase language
- gitignore: client/settings.db* e2e-run artifacts
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.1 KiB
Team Patterns
Model selection
Default model is Opus 4.6 (200K context). For heavy sessions (workshops, large reviews, milestone planning), switch to extended context on-demand:
/model sonnet[1m]— Sonnet 4.6 with 1M context window/model opus[1m]— Opus 4.6 with 1M context window- Cost: 2x input + 1.5x output for tokens beyond 200K (Tier 4 required)
Large content pushes
When producing many files (wiki pages, content batches, bulk docs):
- Lore librarian agent (read-only): ingests all source material, answers focused context queries from writers, tracks cross-file consistency
- Multiple writer agents (parallel, by domain): each gets a task slice, writes directly to disk using the Write tool — one file at a time, write often, no text accumulation
- Reviewer agents (blocked until writing done): check voice consistency, attribute uniformity, style
Key: writers use Write tool directly (no transcription bottleneck), librarian catches contradictions early, split work by domain not volume.
Team monitoring (stuck agent detection)
When leading a team (workshop, batch, or any multi-agent session):
Agent heartbeat rule — include in every agent spawn prompt:
If you have been working on a single task for more than 15 minutes without making progress, message the team lead with what is blocking you. Do not keep retrying the same approach silently.
Team lead proactive checks:
- If an agent has not sent a message in ~20 minutes, ping them for a status update.
- Bottleneck detection: if other agents are idle and waiting on one agent's output, that agent's silence is a red flag — check on them immediately, do not wait for the next natural message.
- When checking on a stuck agent, offer to reassign the task or pull in another agent to help.
Agent verification — don't duplicate the push gate
The pre-push hook (.config/hooks/pre-push) is the source of truth for
verification and runs on every push the lead makes: when server/ changed —
cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test;
when client/ changed — the full gdUnit4 suite via tests/run-godot (T-1065);
when tooling/ changed — make test-tooling (plus cargo deny, ruff, JSON
validation, systems.db stamp). There is no CI (no
.gitea/.github/.forgejo workflows) — the push gate is the only automatic
verification, so it is deliberately comprehensive.
Therefore, when spawning implementation agents, do not tell them to run
cargo fmt, cargo clippy, or cargo test pre-emptively — the push gate enforces
all three, so it is pure duplication. Worse, an agent running a weaker check (e.g.
plain cargo clippy without -D warnings) reports a false "clean". Let agents write
code; the gate is authoritative.
On a gate failure at push: fmt auto-fixes (cargo fmt); clippy is a quick lead patch;
a cargo test failure is a real regression — fix it, or SendMessage the still-alive
agent to fix it in-context. Net: agents verify nothing the gate already covers, and the
lead lets the gate catch fallout on push.