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.
GPT-5.5 high is the default committed model policy for current wave-critical Copilot agents (explorer, implementer, verifier, and resolver). Do not inherit the active Copilot model, and do not assign any current wave-critical Copilot agent to GPT-5.5 medium.
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.
Hardening-prefix guard: when the exact docs-only chain is active, every explorer, implementer, and verifier dispatch prompt must begin with the full hardening prefix from COPILOT_ORCHESTRATION_HARDENING_PROMPT.txt, placed before the wave brief, task body, or failure list. Missing or altered prefix text is a process FAIL, and verifier must fail the wave on prompt-evidence grounds.
Stop-on-drift guard: if the orchestrator notices inline exploration, broad repo inspection, or non-agent analysis after named-chain hard mode activates, stop and report PROCESS FAIL: named-chain hard-mode drift. Do not continue inline; restart from the current wave's first incomplete named step with the full hardening prefix.
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.
Git process guard: mutating/destructive git or file-recovery commands are process FAIL. This is not a blanket no-git policy; read-only git evidence gathering remains allowed where current agent guidance already permits it.
Resolver throttle: resolver is only for concrete blockers that would otherwise force a user question or halt. Do not use it for ordinary planning, coverage-matrix choices, or routine artifact selection.
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, docs-site/content/valenar/**/*.md, examples/valenar-v2/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-v2/README.md.
Forbidden edits for this workflow: examples/valenar-v2/Content/**, examples/valenar-v2/Generated/**, examples/valenar-v2/Host/**, examples/valenar-v2/Client/**, examples/valenar-v2/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.
FAIL repair lane: after verifier FAIL, only re-dispatch implementer with the exact failure list, then re-dispatch verifier. No inline repair, prompt patching, or orchestrator synthesis in between.
Verify reporting guard: verifier must report each acceptance item as PASS or FAIL, with evidence, the command/test run or inspected artifact, and any remaining gap.
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. Chat history, Repomix bundles, and uploaded summaries are seed evidence only — re-read the live committed file before acting on any prior-session memory. 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.
Contract backing gate: when a docs-only wave adds or changes a contract doc, adjudicator term, state machine, or runtime-facing design promise, the implementer must complete the gate defined in .claude/rules/valenar-contract-backing.md before marking the wave shipped. The verifier must check gate item 6 — missing canonical propagation is a FAIL even when the new doc is internally coherent.
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. Core Grounds is the committed preferred physical-area term for the MC's personal anchor compound at the starting Nexus/Wardheart; acceptable alternates when the fiction calls for variation are Nexus Grounds, Wardheart Grounds, Core Enclave, Anchor Grounds, and Core Homestead. 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.
Story-layer governance mirror: when a docs-only wave touches docs-site/content/valenar/story/** or the valenar-story-* rule / agent surfaces, follow .claude/rules/valenar-story-lore.md, especially Valenar Atomic Rename, No-Fallback, And Story-Authoring Discipline. Keep atomic renames one-way with no live legacy aliases or redirect stubs, keep Journal and story prose single-authored with no voiceText / Voice Readback / spoken-readback / narration-safe channel, require explicit canon_delta routing for any non-none delta, keep story-author as the only write-capable story role, and run the story validator plus repo-scoped forbidden-token grep guards; the read-only verifier lane reruns the grep guards independently.