Use the docs-only wave workflow for this scope: explorer -> implementer -> verifier. The exact Copilot agent dispatch names are explorer, implementer, and verifier. Verify is the step name for the validation phase; dispatch verifier for that step. Verify FAIL loops directly back to implementer. Do not rename, alias, substitute, or append model assignments when this guidance specifies those exact names.
Use GPT-5.4 xhigh, or inherit the active Copilot model only when it is already GPT-5.4 xhigh. Keep reasoning at xhigh. Do not silently downgrade models.
The orchestrator dispatches work. Sub-agents do not spawn agents or scheduling/background tools. Copilot workspace agents have the same repository file access as the orchestrator, so inspect workspace docs directly before asking for files already present.
Dispatch-first guard for named docs-only waves: if the prompt explicitly assigns the main agent as orchestrator and names this docs-only chain or an explicit wave order, the first project step must be a real dispatch to explorer. Before that dispatch, no inline repo reads, greps, edits, verification, or synthesis may occur.
Named-chain hard mode: if the prompt assigns the main agent as orchestrator or requires the exact named agents explorer, implementer, and verifier, the orchestrator becomes dispatcher-only. Real dispatch means an actual tool, sub-agent, or handoff invocation to the named agent. If real named-agent dispatch is unavailable in the current environment, stop and report exactly: Blocked: this environment cannot perform the required explorer -> implementer -> verifier named-agent orchestration.
Anti-simulation guard: wave briefs, todos, plans, progress text, status text, prose roleplay, "dispatching..." claims, manual summaries, inline reads, inline edits, and inline verification do not count as Explore, Implement, or Verify and never satisfy a named step.
Question-only user turns are explanation-only. If the user asks what changed, why something changed, what they asked for, or what should change, answer without editing unless they explicitly ask for a file change.
If a docs-only guidance edit was mistaken or disputed, do not auto-revert, restore, or rewrite files. Answer first and wait for an explicit instruction to edit again.
When editing an existing prompt, instruction, or guidance document in this scope, patch it in place. Do not replace the whole document with a rewritten version unless the user explicitly asks for a rewrite or replacement.
Allowed edits for this workflow are documentation and guidance files only: docs/design/**/*.md, docs/decisions/**/*.md, examples/valenar/docs/**/*.md, examples/valenar/README.md, README.md when needed for docs navigation, SECS-Compiler-Plan.md, TASKS.md, .github/copilot-instructions.md, .github/instructions/**, AGENTS.md, CLAUDE.md, .claude/rules/**, and examples/valenar/CLAUDE.md.
Forbidden edits for this workflow: examples/valenar/Content/**, examples/valenar/Generated/**, examples/valenar/Host/**, examples/valenar/Client/**, examples/valenar/Server/**, src/**, tests/**, all *.cs, *.ts, *.tsx, *.secs, and project or build files. If a requested fix requires those files, report it as OUT OF SCOPE instead of working around it.
Docs-only scope guard: do not imply that code, content, Generated output, Host, Server, Client, or test behavior changed when this wave only edited Markdown. If the requested fix really needs those files, call it OUT OF SCOPE for the docs-only wave.
Process guard: the main project agent is the orchestrator and must not do wave work inline. Use the exact agent chain explorer -> implementer -> verifier; for docs-only waves, the verifier agent performs the Verify step instead of collapsing validation into the orchestrator or implementer.
Evidence guard: Explore, Implement, and Verify count only when the matching dispatched sub-agent returned a result in-thread. Inline orchestrator work never satisfies those steps.
Status guard: do not claim or imply that Explore, Implement, or Verify ran, passed, failed, or completed unless the matching explorer, implementer, or verifier result exists in-thread.
Unsupported-claims guard: do not report explorer findings without explorer output, implementer changes without implementer output, verifier PASS/FAIL without verifier output, or docs-only wave completion without the full required dispatch sequence.
Final report guard for orchestrated docs-only runs: include waves run, actual agents dispatched, verifier PASS/FAIL history, failure loops and their resolutions, files changed, validation performed, blockers, and explicit confirmation that no inline work replaced agent dispatch. If transcripts, tool traces, or log IDs are exposed, reference or summarize them.
Treat committed repository docs as source of truth first. Distinguish committed documentation, approved prompt instructions, proposals, historical/rejected material, missing evidence, and implementation issues that are out of scope. Do not invent files, project facts, APIs, canon, lore, mechanics, balance numbers, diagnostics, tests, or provenance links.
Keep generic SECS docs, syntax docs, compiler or lowering docs, runtime docs, and provenance or rule docs game-agnostic. Valenar names in those docs are illustrative or reference-only unless the target file is explicitly Valenar or example-game content.
Vocabulary guard for Valenar docs: use activity as the canonical Valenar behavior / execution / planning noun. Use more specific terms where needed: Atomic Activity, Composite Activity, Routine Activity, Mission, Assignment, and Policy. Do not preserve removed legacy behavior / planning categories, compatibility language, or redirect stubs in Valenar docs; git history is the legacy record. Mirror the removal contract from .claude/rules/behavior-vocabulary.md and docs/design/behavior-vocabulary.md rather than keeping both old and current terms. Do not confuse deprecated legacy behavior vocabulary with SECS on_action. The SECS terms on_action, OnActionId, OnActionDeclaration, FireOnAction, and on-action event subscription remain valid metadata / extension-point vocabulary and must not be renamed unless a future SECS decision explicitly changes them. When docs, Content, Generated stand-ins, runtime code, or tests disagree on this vocabulary, mark the drift explicitly and do not silently keep both terms; if the fix needs non-doc artifact changes, route it to the appropriate non-doc wave.
Character-model guard for Valenar docs: do not invent a generic attribute layer. Skills feed resolved stats through modifiers and formulas. Affinities target one exact skill, a skill tag, or a skill family. Players act through techniques, missions, assignments, and planning surfaces. Conditions and injuries are not traits by default. Named characters are skill-bearing assignable individuals. Pops fill ordinary jobs.
Example guard: when a doc introduces illustrative labels, technique lists, or sample traits, mark them as examples unless they are already committed canon catalogs.
Valenar canon guard for docs-only work: Acts, not legacy Stages. Legacy, moved, or superseded docs are not canon. Core Base is legacy wording for the Core, not the Settlement or the player-facing Realm birth. Camp, Core, and Settlement stay distinct. Act I is First People. Act II is First Outpost. Sites are first-class; dungeons become Sites once discovered or enterable. Clues, Missions, Objectives, Activities, and higher-level planning context stay distinct. Mechanics changes require a design record, and balance numbers or worldbuilding claims require an explicit source. Reclamation starts early; full reclamation comes last.