ARCHIVED — historical context only. This document captures the Stat → Channel migration as it was planned/executed. It is NOT live spec. For current vocabulary, read .claude/rules/secs-concepts.md:49. Linked from older wave roadmap docs for traceability.

Project File-Update Prompt

0. Orchestrator role and mandatory wave protocol

You are the orchestrator.

You are not the explorer, implementer, or verifier.

You do not perform project work inline.

You coordinate waves and dispatch the existing configured agents named exactly:

• explorer
• implementer
• verifier

The main agent receiving this prompt in the project CLI is the orchestrator.

The orchestrator's job is to:

• break the work into waves
• send each wave brief to explorer
• send explorer findings to implementer
• send implementer changes to verifier
• loop verifier failures back to implementer
• synthesize the final report

The orchestrator must not:

• read, grep, inspect, audit, or edit files inline as a substitute for explorer
• make implementation changes inline as a substitute for implementer
• validate changed files inline as a substitute for verifier
• collapse a wave into one long direct answer
• skip verifier
• continue inline when verifier fails
• patch around the wave process inline

Inline wave work by the orchestrator is a process failure.

MANDATORY WAVE PROTOCOL

The main agent receiving this prompt is the orchestrator.

The orchestrator does not perform wave work inline.

The orchestrator must use the existing configured project agents named explorer, implementer, and verifier.

Every wave runs in this order:

1. explorer
2. implementer
3. verifier

On a fresh run, the first project action is Wave 0 explorer. In the current recovered repo state for this prompt, Point 1 and Waves 0, 2, 3, and 4 are already complete, Wave 1 remains explicitly skipped, and the first new project action is Wave 5 explorer.

No project file reads, greps, edits, audits, fixes, or validation may be performed by the orchestrator before the first required explorer dispatch for the current run.

Do not collapse required wave work into one inline pass.

Do not skip verifier.

If verifier returns FAIL, the orchestrator must dispatch implementer again with the verifier failure list, then dispatch verifier again.

Repeat until PASS or until the remaining blocker requires a user decision.

Never patch around the wave process inline.

If the project CLI cannot dispatch the configured agents named explorer, implementer, and verifier, stop immediately and report that blocker. Do not do the work inline.

The wave subsections below are dispatch briefs for the existing agents. They are not inline work for the orchestrator.

CURRENT REPO RESUME STATE

Apply the current repo state before dispatching any new wave work:

• docs/RECOVERED_MIGRATION_PROMPT.md is the recovery source for the remaining-wave list and execution constraints.
• docs/RECOVERY_WORK_REPORT.md is the recovery source for completed slices, drift summary, and concrete open blockers.
• Point 1 template data/template value carrier cleanup is already complete.
• Wave 0 is already complete.
• Wave 1 is explicitly skipped by user instruction and must not be dispatched unless the user changes that instruction.
• Waves 2, 3, and 4 are already complete.
• The prompt/report docs the user asked for already exist and must not be recreated during the remaining implementation waves.
• Unless a later verifier failure proves a direct regression in one of those completed slices, do not restart them.
• Keep Wave 5 identity work separate from Wave 6 stat -> channel work.
• Do not use staging/reset mechanics as a substitute for repairing the live failing surface.

---

1. Chat-discussion context to apply

This prompt converts the current chat discussion and uploaded SECS corpus audit into project file updates.

Additional recovery evidence for this resumed run:

• docs/RECOVERED_MIGRATION_PROMPT.md — recovered working prompt, recovered remaining-wave list, and explicit Wave 1 skip.
• docs/RECOVERY_WORK_REPORT.md — completed slices, open Wave 5 blockers, and the requirement to keep Wave 5 separate from Wave 6.

The user wants a real file-update execution prompt, not another audit-only prompt and not a generic process document.

The work must update the SECS documentation, .secs source/examples, hand-written Generated/*.cs compiler-output stand-ins, C# runtime/compiler-target code, tests, scripts, diagnostics, and project rule files where needed.

The project is SECS: Scripting Engine C Sharp.

SECS is game-agnostic. Valenar is an example game / integration test / generated stand-in pressure test. Valenar names may be used as examples but must not become generic engine vocabulary.

Current uploaded/docs context established these facts:

• .secs is modified C# plus SECS declarations.
• Content/*.secs is designer-facing source/spec today.
• Generated/*.cs is hand-written stand-in output for the future compiler.
• The future compiler reads .secs and emits the Generated shape.
• Existing docs currently mix four modes:
  1. current canonical model
  2. Generated stand-in reality
  3. future compiler target
  4. wave/audit/recovery history
• The docs are conceptually strong but too hard to use as a clean live spec because canonical design prose still contains too much recovery/wave history.
• File count should stay low. Prefer a compact live reading path over dozens of tiny documents.
• Current/future cleanup should be game-agnostic, no-fallback, future-proof, and not constrained by backward compatibility unless a project rule explicitly says otherwise.
• Recovery/history files should remain available for traceability but should not be required in the live reading path.

Important prior failure modes that must not repeat:

• invented SECS source syntax
• fabricated .secs files created only to satisfy Generated provenance tests
• Generated // Source: comments pointing at fake source
• runtime/compiler-lowering C# types presented as live source syntax
• process prompts that made agent dispatch optional
• verifier not inspecting wave prompts, deviation notes, and fabricated artifacts
• fallback/default behavior introduced to make tests pass
• old action / program behavior vocabulary leaking back into live docs

Current committed behavior vocabulary:

• activity is the canonical runnable behavior noun.
• policy is the canonical chooser/scorer noun.
• action as a standalone behavior noun or keyword is banned in live docs/source/code except allowlisted cases.
• program as a behavior noun or keyword is banned in live docs/source/code.
• on_action / OnActionId remain metadata-only labels on activities.
• ActionSpeed is allowlisted as a Valenar in-game stat name and should not be treated as old behavior vocabulary.
• C# Action<T> remains allowed.

Current recovery decision:

• candidate_builder, nested slot X.Y of Type;, nested activity Y;, method ActivityRequest[] Build(...), and from collection X with builder Y are not committed live .secs source syntax.
• CandidateBuilderId, CandidateBuilderDelegate, SelectorSource.FromCollection(SlotKindId Slot, CandidateBuilderId Builder), and concrete candidate-builder classes are runtime/compiler-lowering support only.
• A Generated stand-in with no real .secs source must use a truthful no-source marker rather than forcing a fake source file.

Current no-fallback doctrine:

• Missing required slots, policies, candidate sources, previews, scope edges, template fields, unknown typed ids, and required prev-tick snapshots must not silently default.
• Reserved future behavior should throw or be clearly rejected/deferred, not silently behave like another mode.
• Explicit nullable/optional authored game state is allowed when documented, for example a declared walk returning null for an unowned location.
• Infrastructure unknowns must be loud.

Added discussion decisions and cleanup targets:

• The next major work is a documentation cleanup and source/model vocabulary consolidation pass, not a new feature.
• The live spec should be readable without understanding every recovery wave.
• Historical reports, audits, wave logs, and rejected syntax notes should move out of the first-pass reading path.
• stat as the engine noun is problematic because the game itself may use “stats” for Health, Strength, Stamina, Armor, etc.
• Recommended engine noun: channel.
• Recommended game noun: game stat.
• A SECS channel is a runtime value resolved through the SECS value resolver.
• A game stat may be backed by a SECS channel, but not every channel is a player-facing game stat.
• field is too overloaded as a core SECS noun.
• Keep “host field” / “scope field” for raw host-owned scope storage.
• Replace template field vocabulary with template data for authored immutable content and template value for base/effective reads.
• Prefer source syntax target:
  • channel instead of stat
  • data instead of template field
  • template_value(...) instead of template_field(...)
  • provide inside templates instead of template-body stat declarations for intrinsic channel sources
  • base =, mirror =, and storage = instead of overloaded source =
• Current docs still commit stat and field; this project change intentionally updates that language/runtime/compiler target. Do not leave both models live.
• If an existing accepted project decision contradicts this target in a way that cannot be resolved mechanically, stop the relevant wave and report the blocker. Do not silently mix the models.

Identity/naming discussion to apply:

• Current docs conflict between lowercase-name FNV hash convention and canonical identity strings such as valenar:template/farm.
• Canonical identity strings should become the committed compiler/runtime target.
• Lowercase short-name hashing, if still present, must be marked as legacy stand-in behavior or short-name alias lookup only.
• Hash inputs should include namespace/source-set and declaration kind.
• Channel and template-data identities should be owner/domain qualified so generic names like Level, Amount, Cost, Quality, Power, and Capacity can exist in different domains without collision.
• Short names may remain valid in source only when unambiguous.
• Typed ID wrappers should remain, but the value/channel rename should be reflected in type names where appropriate.

Practical cleanup order from the chat:

1. Separate live spec from history/audit/recovery notes.
2. Clean old behavior vocabulary while keeping ActionSpeed.
3. Split or consolidate monster docs into a small coherent live reading path.
4. Resolve identity and hash model.
5. Rewrite value vocabulary: stat -> channel, field -> template data/value, source -> base/mirror/storage, template-body stat -> provide.
6. Apply game-agnostic labeling.
7. Remove fallback-ish language.
8. Clean diagnostics/status drift.
9. Update .secs, Generated stand-ins, runtime C# code, tests, scripts, compiler plan, and rule files to match.

---

2. Mission

Implement a SECS source-of-truth cleanup and vocabulary migration across the project.

The end state should be:

• Live docs are clean final-state specifications, not recovery logs.
• The core SECS reading path is small and coherent.
• SECS remains game-agnostic.
• Valenar remains an example/integration pressure test, not engine vocabulary.
• Behavior vocabulary uses activity / policy; old behavior action / program is removed except allowed contexts.
• candidate_builder and related invented forms remain rejected as live source syntax.
• No Generated file fabricates source provenance.
• No silent fallback/default behavior remains for required infrastructure paths.
• Canonical identity strings are the committed identity/hash model.
• SECS technical resolver concept is renamed from stat to channel.
• Game-facing “stats” remain available to the game as game vocabulary.
• Template field is replaced with template data / template value.
• Raw host storage is consistently called host field or scope field.
• The overloaded source = stat clause is replaced by explicit base =, mirror =, and storage =.
• Template-body intrinsic stat/channel sources use a non-redeclaration form such as provide.
• Docs, .secs source, Generated stand-ins, C# runtime/compiler-target code, tests, diagnostics, CI guards, and project rules are coherent.
• No project work is performed inline by the orchestrator.

---

3. Source-of-truth hierarchy

Use this hierarchy when files conflict:

1. explicit user instructions in this prompt and current chat
2. project rule files if present
   • CLAUDE.md
   • AGENTS.md
   • .claude/rules/*
   • contributor/workflow docs
   • prompt templates
   • equivalent project instruction files
3. current project files
4. accepted ADRs / decisions
5. current design docs / specs
6. generated stand-ins only when clearly marked current
7. tests as validation, not permission to fabricate
8. future-work docs as backlog, not current truth
9. audit docs and wave reports as evidence/history, not current truth

If project rule files contradict this prompt's mandatory orchestrator/wave protocol, update the rule files during the rule-file wave so future runs match the user’s required process.

If accepted ADRs still contain stale statements contradicted by current governance docs or this prompt, update the ADR text or add a superseding note. Do not silently let stale ADR wording win.

If historical/audit files mention old terms or rejected syntax, do not treat that as current truth unless live docs/code repeat it.

If Generated stand-ins conflict with current design docs, determine whether Generated is current implementation evidence or historical stand-in lag. Update Generated when this prompt's migration wave requires it.

---

4. Non-negotiable user requirements

• Use the existing agents exactly: explorer, implementer, verifier.
• The main project agent is the orchestrator.
• The orchestrator must not do wave work inline.
• Every wave must run explorer -> implementer -> verifier.
• If verifier fails, dispatch implementer again with the failure list, then verifier again.
• Do not assign model names.
• Do not rename or reconfigure agents.
• Do not invent source syntax beyond the migration targets explicitly stated in this prompt.
• Do not invent APIs, files, tests, diagnostics, generated provenance, project rules, lore, mechanics, or canon.
• Do not create .secs files solely to satisfy tests, provenance checks, Generated headers, expected paths, or verifier expectations.
• Do not use fallback/default behavior to paper over missing required data.
• Do not let Valenar-specific names define generic SECS concepts.
• Keep file count low.
• Move or demote history from the live reading path instead of deleting traceability.
• Update docs and actual project artifacts together: .secs, Generated/*.cs, C# runtime/compiler-target code, tests, scripts, and rule files.
• Do not leave mixed stat/channel or field/data terminology as live current truth unless explicitly marked transitional with a tracked cleanup item.
• Prefer clean rewrite over backward compatibility for source syntax and docs unless a project rule or user instruction explicitly requires a transition layer.

---

5. Existing agents and role definitions

explorer

• inspect the relevant project files and chat-derived requirements
• identify current state, source-of-truth hierarchy, constraints, risks, and exact targets
• do not edit files
• produce file/path-backed findings where project tools support it
• distinguish committed source of truth from proposals, examples, generated output, stale docs, historical audit notes, and assumptions
• identify project rule files that may need updates
• identify validation commands/checks available in the repo
• identify risks of invented syntax, fabricated provenance, fallback/default behavior, or stale vocabulary
• identify all affected docs, .secs files, Generated stand-ins, C# runtime/compiler-target files, tests, scripts, and prompt/rule files for the wave

implementer

• update the relevant files according to explorer findings and user requirements
• do not invent syntax, APIs, canon, files, provenance, diagnostics, tests, mechanics, or project rules beyond this prompt’s explicit migration targets
• update project rule files when recurring rules/guards need to persist
• update docs, .secs source, Generated stand-ins, C# runtime/compiler-target code, tests, scripts, and compiler-plan artifacts together when the wave requires it
• report exact files changed and why
• report deviations instead of silently working around rules
• do not run verifier's job inline
• do not fabricate source files or provenance
• do not leave broken references without listing them as blockers or fixing them

verifier

• verify changed files against user requirements, project rules, and source of truth
• inspect explorer and implementer outputs
• inspect the orchestrator's wave prompts/instructions when available
• inspect deviation notes and unexpected changes when available
• run or specify relevant tests/searches/checks
• check that no invented/fabricated material was introduced
• check that no fallback/default behavior was introduced for required paths
• check that docs, source, Generated output, runtime code, tests, scripts, and rule files agree
• check that examples remain examples and are not turned into generic rules unless authorized
• check that the orchestrator used explorer -> implementer -> verifier for the wave
• return PASS or FAIL with exact reasons

If verifier returns FAIL:

• the orchestrator dispatches implementer again with the verifier failure list
• then the orchestrator dispatches verifier again
• repeat until PASS or until a user decision is required
• the orchestrator must not fix the failure inline

---

6. No-invention / no-fabrication guards

HARD GUARDS

Do not invent source syntax, APIs, file formats, schemas, game canon, lore, mechanics, terminology, tests, diagnostics, runtime types, generated provenance, or project rules.

Do not create files solely to satisfy a test, provenance check, generated-source header, expected path, verifier requirement, or reviewer expectation.

A failing test or provenance check is a signal to fix the source-of-truth issue, header, metadata, test, or rule. It is not permission to fabricate source, canon, syntax, or files.

Do not silently fall back from required data to defaults unless the project already has an explicit optional/try/null rule for that case.

Do not turn examples into generic project rules unless the source of truth says they are generic.

Mark proposals as proposals. Mark unverified assumptions as unverified.

SECS-specific guards

Do not invent source-language keywords or grammar to satisfy implementation pressure.

Do not claim generated/source provenance that is not real.

Do not treat runtime/compiler-lowering support as author-facing syntax unless the current source of truth commits it.

Do not revive old behavior action or program vocabulary.

Do not remove the ActionSpeed allowlist solely because it contains the word Action; it is a Valenar game stat name unless the project deliberately renames it as a separate game-content change.

Do not add action or program as parser keywords.

Do not present candidate_builder, nested slot X.Y of Type;, nested activity Y;, method ActivityRequest[] Build(...), or from collection X with builder Y as live source syntax.

Do not create fake Content/*.secs files for Generated stand-ins.

Use the canonical no-source marker for runtime-only Generated stand-ins with no real source, if that marker exists in the project. If it does not exist, create/update the relevant rule and test support first.

Do not silently map unknown StatId/ChannelId, TemplateId, PolicyId, ActivityId, EventId, OnActionId, ScopeId, or other typed id wrappers to raw ulong.

Do not alias old behavior ids such as ActionId to ActivityId.

Do not silently treat missing preview as useful/safe. Missing preview must rank unrelated/zero or produce diagnostics according to the current model.

Do not silently treat missing required policy slots as empty/default lists.

Do not silently default template data/template values, channels, scope fields, prev-tick snapshots, or required bridge calls.

Prompt/process/rule guards

Do not write prompts that make agent dispatch optional.

Do not write prompts that let the orchestrator do wave work inline.

Do not write prompts that rename or reconfigure explorer, implementer, or verifier.

Do not write prompts that assign model names.

Do not omit verifier checks for prompt-level failures, deviation notes, fabricated artifacts, or process-rule violations.

Do not update project rules in a way that contradicts the mandatory wave protocol in this prompt.

---

7. Files and areas likely affected

Start from the files and areas mentioned here, then inspect all accessible related files needed to make the update coherent. Do not treat this list as exhaustive unless explorer proves the project only has these files.

Likely docs and design files:

• README.md
• docs/design/README.md
• docs/design/00-overview.md
• docs/design/01-world-shape.md
• docs/design/02-templates.md
• docs/design/03-stats-and-modifiers.md
• docs/design/04-behavior.md
• docs/design/05-expressions.md
• docs/design/06-overrides-and-modding.md
• docs/design/07-structured-template-data-and-callables.md
• docs/design/08-collections-and-propagation.md
• docs/design/09-ai-policies-and-activities.md
• docs/design/10-host-secs-execution-boundary.md
• docs/design/behavior-vocabulary.md
• docs/decisions/ADR-0002-behavior-vocabulary.md
• any new/split canonical docs created by this work
• docs/FUTURE_WORK.md or docs/design/FUTURE_WORK.md
• docs/deferred-ideas.md or equivalent
• docs/WAVE_REFACTOR_AUDIT.md
• docs/RECOVERY_WAVES.md
• docs/RECOVERY_BOUNDARY_FINAL_REPORT.md
• docs/mod-coverage-audit.md
• docs/audit-findings.md
• relationship bridge docs if present:
  • relationship-bridge-architecture.md
  • relationship-bridge-open-questions.md
  • equivalent project path under docs/

Likely source and generated areas:

• examples/valenar/Content/**/*.secs
• examples/valenar/Generated/**/*.cs
• examples/valenar/Host/**/*.cs
• examples/valenar/Server/**/*.cs
• examples/valenar/docs/**/*.md
• src/SECS.Abstractions/**/*.cs
• src/SECS.Engine/**/*.cs
• src/SECS.Localization/**/*.cs
• tests/**/*.cs
• scripts/**/*.sh
• compiler plan and compiler source if present:
  • SECS-Compiler-Plan.md
  • secs-roslyn/**
  • any parser/binder/lowering docs or code
• task/process files:
  • TASKS.md
  • CLAUDE.md
  • AGENTS.md
  • .claude/rules/*
  • .claude/agents/*
  • contributor/workflow docs
  • prompt templates

Likely C# rename/migration targets:

• StatId -> ChannelId or equivalent
• StatDeclaration -> ChannelDeclaration
• StatResolver -> ChannelResolver or ValueResolver
• StatSourceStore -> ChannelSourceStore
• RegisterStatSource / RegisterDynamicStatSource -> channel-source equivalents
• ResolveStatInt/Long/Float/Double/Bool -> channel-resolution equivalents
• ResolveIntFast etc. on resolver types, if naming currently implies stat
• StatKind -> ChannelMode / ChannelBindingMode / equivalent
• Base / Contributed / Accumulative mode values -> HostBacked / Resolved / Stored
• source = stat/channel binding -> base =, mirror =, storage =
• TemplateFieldDeclaration -> TemplateDataDeclaration or TemplateValueDeclaration according to chosen code boundary
• TemplateFieldResolver -> TemplateValueResolver
• template_field(...) APIs -> template_value(...)
• modifier effect target TemplateField -> TemplateValue or equivalent
• docs/tests/scripts containing old terminology

The exact C# class/type/file names must follow project conventions discovered by explorer. Do not rename blindly without updating call sites, tests, docs, and generated stand-ins.

---

8. Project rule-file updates

explorer must identify project rule/instruction files if present, such as:

• CLAUDE.md
• AGENTS.md
• .claude/rules/*
• contributor docs
• workflow docs
• prompt templates
• equivalent project instruction files

implementer must update the relevant rule file when the change adds or clarifies recurring guardrails.

The rule update must encode:

• the project-specific guardrails from this chat
• the mandatory orchestrator role
• the required explorer -> implementer -> verifier wave protocol
• the failure loop from verifier back to implementer
• the no-invention / no-fabrication rules relevant to SECS
• the no fake .secs provenance rule
• the no invented source syntax rule
• the runtime/lowering-vs-source distinction
• the no silent fallback/default rule
• the game-agnostic Valenar-example rule
• the behavior vocabulary rule
• the new channel/template-data vocabulary once implemented
• the canonical identity string rule once implemented

Do not add model names.

Do not change agent configuration.

Do not rename explorer, implementer, or verifier.

If no rule-file location exists, explorer must identify the closest correct project-rule location and implementer must create or update it only if the project conventions allow that. If project conventions do not allow new rule files, implementer must record the blocker and verifier must decide PASS/FAIL for that wave.

---

9. Waves

Wave 0 — Baseline inventory and source-of-truth map (already completed in the current repo state; rerun only if later verifier evidence shows a direct regression or missing baseline fact)

explorer

• Inspect the actual repository state.
• Identify all accessible project files relevant to:
  • SECS live design docs
  • ADRs/governance docs
  • recovery/audit/history docs
  • future-work/backlog docs
  • relationship/kernel docs
  • .secs source
  • Generated/*.cs stand-ins
  • C# runtime/compiler-target code
  • tests
  • scripts/CI guards
  • project rule files
  • compiler plan / parser / lowering artifacts
• Build a source-of-truth map:
  • live normative docs
  • governance/ADR docs
  • historical/audit-only files
  • future-work/proposal docs
  • generated stand-ins
  • runtime code
  • tests
  • rule/prompt files
• Identify stale/conflicting docs/files.
• Identify actual file paths for all likely target areas.
• Identify current validation commands/checks available.
• Identify risks of invention, fabricated provenance, fallback/default semantics, stale behavior vocabulary, and mixed stat/channel or field/data terminology.
• Identify whether existing project rules already require orchestrator -> explorer -> implementer -> verifier.
• Identify whether existing project rules contain old model routing or old agent names.
• Identify whether the repo uses a wave log / implementation note pattern.
• Do not edit files.

implementer

• Create or update a lightweight implementation note / wave log only if the project already uses one or explorer recommends it as project-conformant.
• Record:
  • source-of-truth map
  • affected file list
  • validation command list
  • rule files to update
  • docs/source/generated/runtime/test migration risks
  • any blocker that prevents safe implementation
• Do not make substantive design/source/runtime edits in Wave 0.

verifier

• Confirm Wave 0 was grounded in actual files.
• Confirm no substantive implementation started before the source-of-truth map.
• Confirm explorer did not skip relevant file families.
• Confirm any implementation note/wave log does not invent project state.
• Confirm rule files requiring update are identified.
• Return FAIL if implementation changes began from assumptions or if the orchestrator performed Wave 0 work inline.

---

Wave 1 — Project rule and process guard updates (explicitly skipped by user instruction; do not dispatch unless the user changes that instruction)

explorer

• Inspect rule/prompt/workflow files identified in Wave 0.
• Check whether they enforce:
  • main agent is orchestrator
  • mandatory explorer -> implementer -> verifier
  • no inline orchestrator wave work
  • verifier failure loop back to implementer
  • no model routing / no agent renaming
  • no invented SECS syntax
  • no fabricated .secs provenance
  • no runtime/lowering support presented as source syntax
  • no fallback/default behavior to satisfy tests
  • verifier checks wave prompts, deviation notes, fabricated artifacts
• Identify exact files and sections requiring updates.
• Identify whether existing guard scripts need updates.

implementer

• Update relevant project rule/process files.
• Encode the mandatory wave protocol from this prompt.
• Encode no-invention / no-fabrication / no-fallback SECS guards.
• Encode that candidate_builder and related invented forms are not live source syntax.
• Encode that Generated stand-ins with no .secs source must use truthful no-source markers.
• Encode that Valenar examples are examples only.
• Encode that ActionSpeed is allowlisted unless separately renamed as game content.
• Encode that action / program behavior vocabulary remains banned in live source/docs/code.
• Do not add model names.
• Do not rename explorer, implementer, or verifier.
• Update scripts/CI guards if the project already has behavior-vocabulary/provenance guard scripts.

verifier

• Inspect changed rule/prompt/script files.
• Confirm they make agent dispatch mandatory, not optional.
• Confirm they do not let the orchestrator work inline.
• Confirm they use exact agent names: explorer, implementer, verifier.
• Confirm they do not assign model names or change agent configuration.
• Confirm they preserve the no-invention / no-fabrication / no-fallback rules.
• Confirm guard scripts, if updated, do not produce false pressure to fabricate source.
• Return FAIL if any prompt/rule makes agent dispatch optional or renames the agents.

---

Wave 2 — Live reading path and history/spec separation (already completed in the current repo state; rerun only on direct regression)

explorer

• Inspect all live docs and history/audit/recovery/future-work docs.

• Identify sections in live normative docs that are actually:

  • wave history
  • recovery narrative
  • audit findings
  • rejected syntax history
  • Generated stand-in caveats
  • future compiler target
  • open questions

• Identify which content should remain in live spec as a short guardrail and which should move/demote to history/audit/backlog.

• Identify overly large docs that need splitting or consolidation.

• Propose a low-file live reading path. Keep file count low.

• Use this target unless project conventions strongly require different names:

  README.md or docs/design/README.md
    orientation, Content/Generated/compiler triangle, doc map
  
  00-language-contract.md or updated 00-overview.md
    SECS identity, committed keywords, source governance, live vs historical,
    behavior vocabulary, no-fallback doctrine, diagnostics overview
  
  01-world-schema-and-values.md
    scopes, host/scope fields, contracts, identity/ids, channels,
    template data/value, base/mirror/storage rules
  
  02-templates-and-contracts.md
    template shell, contracts, activation/deactivation, registry_only,
    template data assignments, lifecycle
  
  03-modifiers-resolution-and-expressions.md
    channel resolution, modifiers, template value effects,
    expression lowering, read/write context rules
  
  04-behavior-and-policies.md
    systems, events, on_action metadata, activities, activity requests/runs,
    policies, slots, candidate builders as runtime/lowering only
  
  06-modding-and-source-sets.md
    source sets, operations, slot schema, identity, conflicts, compile-time merge,
    startup FinalizeModRegistration
  
  10-host-boundary-save-load.md
    ownership, host bridge, invocation matrix, read-only vs command-producing,
    save/load payloads, no fallback
  
  11-relationship-kernel.md
    proposed future SECS Kernel architecture, clearly marked future/proposed
  
  FUTURE_WORK.md
    backlog only

• Identify if exact filenames should differ to minimize churn.

implementer

• Update the reading guide / README doc map.
• Move or demote recovery/audit/wave material out of the live reading path.
• Rewrite live docs so they state current contract first and history second, if history must remain.
• Add explicit mode labels where needed:
  • current live spec
  • Generated stand-in reality
  • future compiler target
  • historical/recovery/audit note
  • proposal/deferred
• Keep historical reports/audits available for traceability, but do not require them for first-pass spec understanding.
• Keep file count low. Do not split into dozens of tiny docs.
• If moving/renaming docs is too disruptive, implement the same conceptual split through headings and README map first, then record a follow-up for physical split.

verifier

• Confirm live reading path is small and coherent.
• Confirm historical files are not required to understand current rules.
• Confirm moved/demoted content remains traceable.
• Confirm live docs no longer read like recovery logs where they should be final-state specs.
• Confirm docs clearly distinguish current spec, Generated stand-in, future compiler target, history, and proposals.
• Confirm no design truth was lost.
• Return FAIL if a live design doc still depends on wave-history narrative to explain core current behavior.

---

Wave 3 — Behavior vocabulary, candidate-builder recovery, and provenance cleanup (already completed in the current repo state; rerun only on direct regression)

explorer

• Search all live docs, source, Generated output, tests, scripts, compiler plan, task files, and rule files for:
  • action
  • ActionId
  • SecsAction
  • ActionRun
  • ActionContext
  • GetAiWeight
  • AiTickFrequency
  • ai_will_do
  • program
  • ProgramId
  • SecsProgram
  • ProgramRun
  • candidate_builder
  • slot X.Y of Type
  • method ActivityRequest[] Build
  • from collection
  • with builder
  • KnownSpells
  • Activity_<ContentName> content-family smells
• Classify each hit:
  • allowed live usage
  • historical/governance mention
  • source syntax rejection note
  • live misuse
  • proposed-only future syntax
  • runtime/compiler-lowering support
• Check Generated provenance headers and tests for no-source handling.
• Identify stale deferred docs that still present old action/program systems as alive.

implementer

• Preserve activity, policy, and metadata-only on_action.
• Preserve ActionSpeed unless this wave explicitly includes a game-content rename; do not treat it as old behavior vocabulary.
• Remove or rewrite live old-behavior vocabulary:
  • action as behavior noun
  • ActionId where ActivityId or OnActionId is meant
  • ActionExecutor
  • ExecuteAction(actionId)
  • GetAvailableActions()
  • GetValidTargets(actionId)
  • program behavior references
• Delete, archive, or rewrite deferred sections such as “Action Target Selection UI Integration” so they do not imply the old action system exists.
• Keep historical/audit mentions in clearly historical files.
• Keep governance allowlist text.
• Ensure candidate-builder docs say:
  • runtime/compiler-lowering support only
  • no committed live source syntax
  • future source syntax, if mentioned, is proposed/deferred and not parser-accepted
• Ensure Generated stand-ins with no source use truthful no-source markers.
• Update tests/scripts/guards to catch banned live uses without flagging allowed uses.
• If any fabricated .secs source files still exist solely for provenance, delete them and fix tests/headers/policy instead.

verifier

• Re-run relevant vocabulary/provenance searches and scripts.
• Confirm remaining old behavior terms are allowlisted, historical, governance, or plain-English non-behavior uses.
• Confirm no live .secs file uses candidate_builder or related invented forms.
• Confirm CandidateBuilderId / CandidateBuilderDelegate remain runtime/compiler-lowering only.
• Confirm Generated provenance does not point at fake source files.
• Confirm tests do not pressure implementers to fabricate source.
• Return FAIL on any live behavior action/program misuse, fake source provenance, or invented source syntax.

---

Wave 4 — No-fallback boundary and runtime semantics cleanup (already completed in the current repo state; rerun only on direct regression)

explorer

• Search live docs, Generated output, C# runtime code, tests, and compiler plan for:
  • fallback
  • fall back
  • default
  • returns null silently
  • returns type default
  • no-op
  • empty candidates
  • ResolveSlotOrDefault
  • Try methods
  • unknown id
  • missing source
  • missing preview
  • EffectPlan.Empty
  • prev tick
  • ReadPrevTick
  • WalkScope
  • LookupTemplate
  • ResolveTemplateField
  • template field/value read defaults
  • registry duplicate overwrite
• Classify each case:
  • explicit optional/try semantics
  • authored nullable game state
  • test-only shim
  • historical mention
  • live silent infrastructure fallback
• Inspect host bridge interfaces, activity/policy executors, template/template-value resolvers, prev-tick store, registry duplicate handling, and Generated examples.

implementer

• Rewrite live docs and code so required infrastructure does not silently default.
• Replace fallback-ish language with one of:
  • throws
  • compile error
  • runtime error
  • reserved and throws
  • deferred
  • rejected
  • explicit nullable/optional result
• Fix host bridge/read semantics:
  • unknown template id must not silently look like a valid absent value unless using explicit TryLookupTemplate
  • unknown template data/value id must not return type default
  • missing required prev-tick snapshot must not return type default
  • unknown required activity/policy/event/template ids must be loud
  • resolver pre-attach / uninitialized bridge calls must not return zero silently
• Split optional/null game state from infrastructure errors:
  • declared walk returning null for an unowned location is allowed
  • undeclared walk is compile/runtime validation error
• Fix formula/query examples such as missing @Location returning a useful fallback constant unless the .secs source explicitly authored that branch.
• Fix policy slot behavior:
  • explicitly seeded slots only
  • unseeded required slots throw/diagnose
  • no fallback to compiled defaults
• Fix preview scoring:
  • missing preview ranks unrelated/zero or produces diagnostic
  • missing preview is not useful/safe by default
• Update tests to lock no-fallback behavior.
• Update FUTURE_WORK.md for any runtime catch-up that cannot land in this wave.

verifier

• Confirm no required infrastructure path silently defaults.
• Confirm every remaining null/empty/default is explicit optional/try/authored semantics.
• Confirm tests cover no-fallback behavior for slots, templates, template values, prev-tick, unknown ids, preview, and bridge initialization where applicable.
• Confirm docs and code agree.
• Return FAIL on any live “type default on unknown,” “zero silently,” “fallback to compiled defaults,” “bare-template fallback,” or equivalent required-path default.

---

Wave 5 — Canonical identity strings, typed IDs, and hash namespace cleanup

explorer

• Inspect identity/hash documentation and code:
  • H.*
  • Hashes.cs
  • typed id wrappers
  • declaration id generation
  • collision diagnostics
  • source aliases
  • canonical strings
  • short-name lookup
  • source-set/mod identity
  • generated constants
  • save/load ids
• Start from the currently open recovery blockers in docs/RECOVERY_WORK_REPORT.md, especially examples/valenar/Generated/Templates/TemplateScalarFieldAccess.cs, src/SECS.Engine/SecsRegistry.cs, and ChannelId-family canonical literals that still use stat-era text such as valenar.stat.*.
• Identify every place that still says IDs are hashes of lowercase short names.
• Identify every place that already says canonical identity strings are preferred.
• Identify all declaration families needing canonical identity:
  • template
  • contract
  • scope
  • channel
  • template data/value
  • modifier
  • system
  • event
  • on_action
  • activity
  • policy
  • need
  • selector
  • rule
  • slot kind
  • phase/tick rate/tag plain-C# values
  • formula/trigger/generated helper ids
• Report the smallest coherent file set that closes Wave 5 without reopening general Wave 6 vocabulary migration.
• Identify code/tests/scripts that need updating for canonical identity strings.

implementer

• Make canonical identity strings the committed identity/hash model.
• Repair the currently open identity failures from the recovery report:
  • TemplateScalarFieldAccess.cs provenance / namespace fallout
  • SecsRegistry raw-name vs canonical-identity lookup truth
  • stat-era canonical channel identity literals such as valenar.stat.*
• Mark lowercase short-name hashing as legacy stand-in behavior or alias lookup only.
• Define identity string format consistently, for example:
  • valenar:template/building/farm
  • valenar:contract/building
  • valenar:scope/settlement
  • valenar:channel/settlement/morale
  • valenar:data/building/gold_cost
  • valenar:modifier/house_morale_presence
  • valenar:activity/cast_spell
  • valenar:policy/character_survival
  • better_farms:template/building/irrigated_farm
• Use owner/domain qualification for channels and template data so generic names can repeat safely in different domains.
• Preserve short source names only as compiler-resolved aliases when unambiguous.
• Add ambiguity diagnostics for short names.
• Update Generated identity tables / hash constants to record canonical strings or generate from them.
• Update C# typed id wrappers and declaration metadata to carry or reference canonical identity where appropriate.
• Update collision diagnostics to cite canonical strings.
• Update docs to explain:
  • semantic identity
  • display name
  • source alias
  • generated constant
  • typed id wrapper
  • canonical hash input
• Update tests to verify canonical identity hashing and ambiguity behavior.
• Do not use raw ulong as the public identity surface when a typed id wrapper exists.
• Do not pull general stat -> channel migration into this wave except where removing a stat-era canonical identity literal is necessary to close the identity slice.

verifier

• Confirm one identity model wins.
• Confirm docs no longer leave lowercase-name hashes and canonical identity strings as two live targets.
• Confirm generated/code/tests agree on canonical hash input.
• Confirm short-name aliases are unambiguous or diagnostic.
• Confirm generic names can repeat when owner-qualified.
• Confirm no raw ulong identity leaks were introduced where typed ids should be used.
• Confirm TemplateScalarFieldAccess.cs no longer fails provenance or namespace expectations.
• Confirm no canonical channel identity still uses valenar.stat.* or other stat-era canonical text.
• Return FAIL on mixed live identity models, silent collisions, false provenance, or Wave 6 scope bleed.

---

Wave 6 — Value vocabulary and source syntax contract migration

explorer

• Begin this wave only after Wave 5 returns PASS.
• Distinguish the already-closed template data/template value cleanup from the remaining technical stat -> channel migration work.
• Inspect all docs, .secs files, Generated output, runtime C# code, tests, scripts, and compiler plan for:
  • stat
  • Stats
  • StatId
  • StatDeclaration
  • StatKind
  • StatResolver
  • StatSource
  • field
  • TemplateField
  • TemplateFieldDeclaration
  • TemplateFieldResolver
  • template_field
  • source =
  • kind = Base
  • kind = Contributed
  • kind = Accumulative
  • template-body stat int X =
  • template-body stat int X {
• Classify hits:
  • engine technical noun to migrate
  • game-facing “game stat” prose to preserve
  • host/scope field prose to preserve
  • C# field prose to preserve
  • historical/audit mention
  • transition alias
• Identify required source grammar/doc/test/code changes.
• Identify whether parser/compiler code exists; if compiler is deferred, identify docs/Generated/runtime stand-in targets.

implementer

Implement the value vocabulary migration consistently.

• Carry forward the already-completed template data/template value cleanup; do not reopen Point 1 unless Wave 5/6 validation proves a direct regression.

Target source-language vocabulary:

channel
  SECS runtime value resolved through the value/channel resolver.

game stat
  Optional game/player-facing concept such as Health, Strength, Armor, Stamina.
  A game stat may be backed by a SECS channel.

host field / scope field
  Raw host-owned storage exposed through a scope schema.

template data
  Authored immutable content on a template.

template value
  Base/effective value read from template data.

modifier
  Named effect bundle that changes channels or effective template values.

Target source syntax:

channel int Population
{
    mode = HostBacked;
    base = settlement.Population;
    min = 0;
}

channel int Morale
{
    mode = Resolved;
    mirror = settlement.Morale;
    min = 0;
    max = 100;
}

channel int Food
{
    mode = Stored;
    storage = settlement.Food;
    min = 0;
}

data int GoldCost
{
    name = "Gold Cost";
    min = 0;
}

template<Structure> Farm
{
    data GoldCost = 10;

    provide FoodOutput = 5;

    provide FoodOutput
    {
        return (int)(5 * @Location.Fertility / 33);
    }

    query bool CanBuild()
    {
        return @Settlement.Gold >= template_value(Farm, GoldCost, BuildCostContext);
    }
}

modifier RoyalBuilderDiscount
{
    template_value GoldCost *= 80%;
}

Required migration table:

Current	Target
stat keyword for resolver declaration	channel
Stat as engine noun	channel
game/player “stats”	game stats
StatId	ChannelId unless explorer finds a stronger project-conforming name
StatDeclaration	ChannelDeclaration
StatKind	ChannelMode or ChannelBindingMode
kind = Base	mode = HostBacked
kind = Contributed	mode = Resolved
kind = Accumulative	mode = Stored
source = scope.Field for host base	base = scope.Field
source = scope.Field for resolved mirror/writeback	mirror = scope.Field
source = scope.Field for stored mutable amount	storage = scope.Field
template-body stat int X = N	provide X = N
template-body stat int X { ... }	provide X { ... }
top-level template field declaration	data declaration
template-body field int GoldCost = 10	data GoldCost = 10
template_field(...)	template_value(...)
“effective template field”	“effective template value”
TemplateFieldDeclaration	TemplateDataDeclaration and/or TemplateValueDeclaration according to runtime boundary
TemplateFieldResolver	TemplateValueResolver
modifier field GoldCost *= 80%	template_value GoldCost *= 80%

Implementation requirements:

• Update docs first enough to define the new live contract.
• Update .secs source/examples to the new syntax.
• Update Generated stand-ins to match the new source syntax and new C# lowering target.
• Update C# runtime/compiler-target types and method names where feasible.
• Update tests and scripts.
• Update compiler plan / parser plan / grammar docs if present.
• Do not leave old stat and new channel both as live source keywords.
• Do not leave old field and new data/template_value both as live template-data syntax.
• If transition aliases are unavoidable for intermediate compilation, mark them explicitly as temporary compatibility shims, add FUTURE_WORK cleanup rows, and keep verifier aware. Prefer no aliases if the project can compile without them.
• Keep C# field as normal programming-language terminology when specifically talking about C# fields.
• Keep host field / scope field for raw host storage.
• Keep “game stats” for player-facing game concepts.

verifier

• Confirm docs define channel narrowly and do not use it as “any value.”
• Confirm the already-closed template data/template value cleanup remains intact and Wave 5 identity repair was not conflated with this wave.
• Confirm docs preserve “game stat” as game-facing vocabulary.
• Confirm live source uses channel / data / template_value / provide consistently.
• Confirm Generated stand-ins match source examples and lowering docs.
• Confirm C# runtime/compiler-target names are coherent.
• Confirm source = overload is gone from live channel declarations.
• Confirm base / mirror / storage semantics are distinct.
• Confirm template-body assignments do not repeat the data type.
• Confirm modifier effects clearly distinguish channel effects from template-value effects.
• Confirm tests/scripts no longer expect old stat/field syntax as live current syntax.
• Return FAIL on mixed live vocabulary, ambiguous field, Wave 5/Wave 6 scope mixing, or old stat source keyword remaining outside historical/proposal contexts.

---

Wave 7 — Source, Generated, and C# code migration pass

explorer

• Using Wave 6’s final vocabulary decisions, inspect actual .secs, Generated, runtime, host, server, tests, and compiler artifacts.
• Build a concrete file-by-file migration map.
• Identify generated/source pairs and no-source stand-ins.
• Identify runtime API renames and required compatibility cleanup.
• Identify tests that must be updated or added.
• Identify generated provenance updates needed after syntax changes.
• Identify any C# public API rename that requires broad call-site changes.

implementer

• Apply the migration to actual project files.
• Update examples/valenar/Content/**/*.secs or equivalent source files:
  • stat declarations to channel
  • template-body stat sources to provide
  • template fields to data
  • template_field(...) reads to template_value(...)
  • needs/selectors/policies to use channel = where appropriate
  • mode/base/mirror/storage syntax
• Update examples/valenar/Generated/**/*.cs or equivalent stand-ins:
  • Generated comments/docstrings must reflect new source syntax
  • no fake source paths
  • Generated declaration arrays/tables use new channel/data/value terminology
  • formulas/sources/register calls use new channel naming
• Update src/**/*.cs runtime/compiler-target code:
  • type names
  • method names
  • resolver names
  • declaration structs
  • effect target kinds
  • diagnostics
  • save/load payload names where semantically needed
• Update host/server code that calls renamed APIs.
• Update tests:
  • runtime tests
  • generated provenance tests
  • vocabulary tests
  • parser/lowering tests if present
  • no-fallback tests
  • identity hash tests
• Update scripts:
  • vocabulary guards
  • generated provenance guards
  • grep baselines
• Update compiler plan / tasks.
• Update or remove transitional aliases if possible.
• Do not make tests pass by fabricating source or silently defaulting behavior.

verifier

• Run relevant build/test/check commands discovered in Wave 0, or report blockers if unavailable.
• Run repo-wide searches for old live terms.
• Confirm source and Generated stand-ins are aligned.
• Confirm C# runtime/API migration is coherent.
• Confirm tests validate the new model.
• Confirm no Generated file claims false provenance.
• Confirm no fake .secs files were created.
• Confirm no silent fallback was introduced to ease migration.
• Return FAIL on build/test failures, old live syntax, mixed Generated/source shape, or fabricated provenance.

---

Wave 8 — Diagnostics, validation, and guard scripts

Resume-scope note

• For the current recovered repo state, the default remaining execution path is Wave 5 -> Wave 6 -> Wave 7.
• Waves 8 through 13 are retained from the broader prompt for reference.
• Do not dispatch Waves 8 through 13 in this resume run unless Wave 5-7 verifier evidence identifies a concrete unresolved blocker that explicitly requires one of them.

explorer

• Inspect diagnostic catalogs across docs/code/tests/scripts.
• Identify every code currently used or proposed.
• Classify status:
  • implemented compiler diagnostic
  • implemented runtime validation
  • registry validation
  • warn-only static analysis
  • reserved compiler diagnostic
  • backlog item
  • historical/audit-only code
• Search for collisions and renumbering drift.
• Identify diagnostics affected by:
  • stat -> channel
  • field -> data/template_value
  • source -> base/mirror/storage
  • canonical identity strings
  • no-fallback rules
  • behavior vocabulary/candidate-builder recovery

implementer

• Update diagnostic docs and code.
• Do not casually assign new codes if an existing catalog convention exists.
• Rename “active diagnostics” to “committed diagnostic catalog” or add status/channel columns if some diagnostics are not implemented.
• Add/update diagnostics for:
  • old stat source keyword if rejected after migration
  • old template field keyword if rejected after migration
  • source = in channel declarations after migration
  • missing required base / mirror / storage by channel mode
  • unknown canonical identity / ambiguous short alias
  • fake Generated source provenance
  • banned candidate_builder source syntax
  • live old behavior action / program terms where guardable
  • unknown required template values
  • no-preview policy-visible activities
  • unseeded required slots
  • read-only contexts attempting command operations
• Update guard scripts and baselines.
• Update FUTURE_WORK.md with any reserved-but-not-implemented diagnostics.

verifier

• Confirm no diagnostic code has two live meanings.
• Confirm implementation status is clear.
• Confirm reserved diagnostics are not claimed as implemented.
• Confirm runtime validations are not mislabeled compiler diagnostics unless deliberately cross-listed.
• Confirm scripts detect intended failures and do not force fabrication.
• Return FAIL on diagnostic collision, status drift, or guard-script pressure to invent/fabricate.

---

Wave 9 — Modding/source-set and compiler-plan reconciliation

explorer

• Inspect modding docs, compiler plan, runtime mod registry, source-set rules, tests, and generated output.
• Confirm:
  • compile-time semantic merge remains long-term model
  • startup FinalizeModRegistration runtime merge remains committed permanent lowering target for activity/policy mods
  • no runtime hot patching in the ticking game
  • host-capable vs third-party data-only source sets are clear
  • third-party data-only mods cannot add host-backed scopes, fields, walks, collections, or scope methods
  • semantic slots, not arbitrary C# text replacement
  • architectural slots are replace-only or require explicit migration
• Identify all places that still use old stat/field terms in mod slot names.
• Identify all places where canonical identity string and new channel/data/value names must be reflected.

implementer

• Update modding docs and runtime/compiler-plan artifacts.
• Rename mod slot schema consistently:
  • stat slots -> channel slots
  • template_field slots -> template_data / template_value slots as appropriate
  • modifier stat effect -> modifier channel effect
  • modifier field effect -> modifier template-value effect
• Update source-set examples to use channel, data, provide, template_value, base/mirror/storage.
• Keep compile-time semantic merge as the model.
• Keep startup finalization as the permanent runtime lowering target for activity/policy mods.
• Update conflict report examples to canonical identity strings.
• Update compiler phase plan so it does not claim old syntax as current.
• Ensure future/proposed syntax is clearly marked.

verifier

• Confirm modding docs and compiler plan match the new vocabulary and identity model.
• Confirm source-set boundaries remain strict.
• Confirm no arbitrary C# text replacement is introduced.
• Confirm no runtime hot patching is introduced.
• Confirm startup finalization and compile-time merge are reconciled.
• Return FAIL if old stat/field syntax remains live in slot schema or examples.

---

Wave 10 — Relationship kernel alignment

explorer

• Inspect relationship bridge/kernel docs and any kernel/runtime code.
• Confirm the relationship work remains:
  • deterministic SECS semantic kernel
  • not a Flecs/raw primitive clone
  • host-agnostic
  • zero Unity package references in kernel/engine
  • Unity DOTS adapter-only
  • 64-bit SECS ids
  • relation metadata and target-as-data
  • SECS-first query planning
  • deterministic semantic iterators
  • not a replacement for .secs, compiler, scope model, or modding contract
• Identify terms requiring update after stat -> channel, field -> data/value, canonical identity strings, and no-fallback cleanup.
• Identify remaining open questions that are core invariants disguised as future work.

implementer

• Update relationship/kernel docs to match new vocabulary:
  • stat dependencies -> channel dependencies
  • stat resolver boundary -> channel/value resolver boundary
  • scope fields remain host fields
  • template fields -> template data/value
  • identity strings are canonical
• Preserve proposed/future status if the kernel is not implemented.
• Do not add new .secs syntax in relationship docs.
• Do not let relationship docs override core language/modding/boundary docs unless explicitly accepted.
• Keep Unity/DOTS adapter-only language.

verifier

• Confirm relationship docs remain aligned with SECS Kernel framing.
• Confirm no raw Flecs/pair id truncation leaks into semantic model.
• Confirm no new source syntax is invented.
• Confirm kernel docs use channel/data/value vocabulary consistently or explicitly mark old terms as historical.
• Return FAIL if relationship/kernel docs replace SECS language/compiler/scope/modding contract.

---

Wave 11 — Game-agnostic Valenar example labeling pass

explorer

• Search live docs for Valenar-specific terms in generic headings or unlabeled generic prose:
  • Settlement
  • Location
  • Character
  • Farm
  • House
  • Storehouse
  • KnownSpells
  • Fireball
  • Goblin
  • Lead
  • Wood
  • DrainStamina
  • AdvanceLead
  • Base Camp
  • any other project-specific concepts found
• Classify:
  • acceptable example body
  • generic heading misuse
  • unlabeled example
  • game-specific rule presented as engine rule
• Identify docs/examples needing caveats or generic rewrites.

implementer

• Rewrite generic headings to use SECS concepts, not Valenar-specific names.
• Add concise caveats to examples:
  • “Valenar example; another game would use different scopes/contracts/channels/data/activities/policies.”
• Keep Valenar as the worked example where useful.
• Do not erase useful examples.
• Do not create a second example game just for genericity.
• Update examples to new channel/data/value vocabulary.

verifier

• Confirm Valenar examples are clearly labeled.
• Confirm generic concepts are not named after Valenar systems.
• Confirm the docs still remain readable and concrete.
• Return FAIL if a game-specific Valenar concept is presented as a generic SECS primitive.

---

Wave 12 — Future-work, deferred-ideas, and backlog hygiene

explorer

• Inspect FUTURE_WORK.md, deferred-ideas.md, audit backlogs, open-question docs, and task files.
• Identify:
  • stale old behavior vocabulary
  • proposed syntax not marked proposed
  • core invariants incorrectly deferred
  • resolved items still listed as active
  • active blockers hidden in backlog
  • items needing update after channel/data/value migration
• Identify which historical audit findings remain live after current changes.

implementer

• Update backlog files.
• Remove or archive stale deferred sections that revive old systems.
• Mark proposal-only items clearly.
• Move completed items to Completed rather than deleting if project convention says history matters.
• Ensure no unresolved core invariant lives only in backlog.
• Add follow-up rows for any transitional aliases or deferred runtime/code work left by migration.
• Update terms to channel/data/value where applicable.
• Keep history traceable.

verifier

• Confirm backlog does not define current source truth.
• Confirm proposal-only syntax is marked proposed.
• Confirm old action/program vocabulary is gone or historical.
• Confirm no core invariant is buried as optional future work.
• Confirm completed/resolved items moved according to project convention.
• Return FAIL if deferred docs still mislead implementers about current syntax/model.

---

Wave 13 — Full consistency, build/test, and final source-of-truth sweep

explorer

• Re-run broad searches across the repo for:
  • old live stat syntax
  • old live template field syntax
  • template_field
  • source =
  • kind = Base
  • kind = Contributed
  • kind = Accumulative
  • StatId
  • StatDeclaration
  • StatKind
  • StatResolver
  • old behavior action/program misuse
  • candidate_builder
  • fake // Source: provenance
  • fallback/default/no-op language
  • lowercase-name hash model as live target
  • Valenar-specific generic headings
• Identify all remaining hits and classify allowed/historical/transitional/blocking.
• Identify final validation commands.

implementer

• Fix remaining consistency issues found by explorer.
• Run or prepare final validation according to project conventions.
• Update final docs/index/readme if necessary.
• Do not introduce new scope beyond fixing consistency.

verifier

• Run final validation commands where available.
• Verify:
  • rule files updated
  • docs/source/generated/runtime/tests/scripts agree
  • source-of-truth hierarchy respected
  • no invented syntax/API/files/provenance
  • no silent fallback
  • behavior vocabulary clean
  • candidate-builder recovery preserved
  • channel/data/value migration coherent
  • canonical identity strings are current truth
  • Valenar examples labeled
  • diagnostics consistent
  • relationship kernel aligned
  • resume-state override respected and orchestrator used explorer -> implementer -> verifier for every wave executed in this run
  • completed waves were not replayed without direct regression evidence
  • Wave 5 identity work remained separate from Wave 6 stat -> channel work
• Return PASS only if the project is ready for future file updates from the cleaned source of truth.
• If any blocker remains, return FAIL with exact remaining files and user decisions required.

---

10. Verification checklist

The final verifier must answer yes/no/blocked for each item:

Process

• The current resume-state override was respected: Point 1 and Waves 0, 2, 3, and 4 were treated as already completed, Wave 1 was treated as skipped, and Wave 5 explorer was the first new dispatch unless a scoped regression revisit was required.
• The orchestrator did not inspect/edit/validate inline before the first required explorer dispatch for this resume run.
• Every executed wave in this run ran explorer -> implementer -> verifier.
• Completed waves were not replayed without direct regression evidence.
• Wave 5 identity work remained separate from Wave 6 stat -> channel work.
• Every verifier FAIL was looped back to implementer, then verifier again.
• The configured agent names remained exactly explorer, implementer, verifier.
• No model names or model routing were added.
• No agent configuration was changed.
• Rule files encode the mandatory wave protocol.

Source-of-truth

• Live docs are separated from history/audit/recovery notes.
• The live reading path is small and coherent.
• Historical reports remain traceable but are not required for first-pass understanding.
• Current vs Generated stand-in vs future compiler target vs proposal is labeled.
• Source-of-truth hierarchy is respected.

Behavior/recovery/provenance

• activity / policy are canonical.
• action / program behavior vocabulary is absent from live docs/source/code except allowed/historical contexts.
• ActionSpeed remains allowed unless deliberately renamed as game content.
• on_action remains metadata-only.
• candidate_builder and related invented forms are absent as live source syntax.
• CandidateBuilderId / CandidateBuilderDelegate are runtime/compiler-lowering only.
• Generated no-source stand-ins use truthful no-source markers.
• No fake .secs files were created for provenance.
• Provenance tests/guards do not pressure fabrication.

No fallback

• Required slots do not fall back to compiled defaults.
• Required candidate sources do not silently become empty.
• Required policies/activities/events/templates do not silently no-op.
• Unknown typed ids do not fall back to raw ulong.
• Missing required preview is not scored as useful/safe by default.
• Template value reads do not return type defaults on unknown ids.
• Prev-tick reads do not return type defaults on missing required snapshots.
• Bridge initialization and unknown template lookups are loud unless explicit Try*/optional.

Identity

• Canonical identity strings are the committed hash input.
• Lowercase short-name hashing is not a live identity target.
• Short aliases are unambiguous or diagnostic.
• Channel/template-data identities are owner/domain qualified where needed.
• Typed ID wrappers are used instead of raw ulong.
• Collision diagnostics cite canonical strings.

Value vocabulary

• SECS technical resolver concept is channel.
• Game-facing “stats” are game stats, not engine stat declarations.
• Old stat source keyword is absent from live current syntax.
• Channel modes are distinct and explicit.
• base =, mirror =, and storage = replace overloaded source =.
• Template data uses data.
• Template body channel sources use provide.
• Template reads use template_value(...).
• Effective template values are not called fields in live current prose.
• Host/scope fields remain clearly named host fields / scope fields.
• C# fields are only called C# fields when discussing C# members.
• Generated output and runtime C# use matching terminology or clearly marked transitional compatibility.

Modding/compiler/generated/C#

• .secs source examples compile conceptually to matching Generated stand-ins.
• Generated comments/docstrings use new syntax and real/no-source provenance.
• Runtime C# names/types/APIs match the new model or have documented transitional shims.
• Compiler plan/parser/lowering docs match the new source grammar.
• Mod slot schema uses channel/data/value names.
• Startup FinalizeModRegistration remains reconciled with compile-time mod merge.
• Third-party data-only mod limits are preserved.

Relationship/kernel

• Relationship bridge remains SECS Kernel framing.
• It does not replace .secs, secs-roslyn, scope model, or modding contract.
• It keeps 64-bit SECS ids.
• Unity DOTS remains adapter-only.
• Kernel docs use channel/data/value vocabulary where relevant.

Game agnostic

• Valenar examples are labeled as examples.
• Generic headings use generic SECS terms.
• Valenar content names do not define engine vocabulary.

Diagnostics/tests/scripts

• Diagnostic codes are collision-free or collisions are explicitly fixed.
• Diagnostic implementation status is clear.
• Guard scripts catch forbidden live syntax/vocabulary/provenance issues.
• Tests were updated to the new model.
• Tests were not made green through fabricated source or fallback defaults.

---

11. Final report requirements

At the end, the orchestrator must produce a final Markdown report.

The final report must include:

• waves run
• which agents were dispatched for each wave
• PASS/FAIL status per verifier run
• verifier failure loops and how they were resolved
• files changed
• files moved/renamed
• files archived/demoted
• rule files changed
• docs changed
• .secs source files changed
• Generated files changed
• C# runtime/compiler-target files changed
• tests changed
• scripts changed
• validation performed
• validation commands run and results
• validation blockers if commands could not run
• remaining blockers or user decisions needed
• deviations from this prompt and why
• confirmation that no inline wave work replaced explorer / implementer / verifier
• confirmation that no fake source/provenance was created
• confirmation that no invented source syntax was introduced beyond the explicit migration target
• confirmation that no silent fallback/default behavior was introduced
• confirmation that the output artifacts are Markdown when applicable

If project tools expose dispatched prompts or agent transcripts, include or summarize them enough that prompt-level failures can be audited.

If any wave leaves transitional aliases or compatibility shims, list them explicitly with:

• file
• reason
• risk
• cleanup task
• target removal condition

If implementation cannot complete because a project decision is required, stop after verifier marks the blocker and report the exact decision needed. Do not guess and do not continue inline.