/gm-build

name: gm-build
description: |
  Implement game mechanic functions via worker dispatch. Covers risk-first then main implementation.
  Dispatches workers until PLAN is clean, then runs one verify+review pass; loops until convergence.
  Explicit invocation only — use /gm-build.
disable-model-invocation: true

GodotMaker Build

$ARGUMENTS

You are implementing a Godot game by dispatching Worker subagents. Risk tasks first, then main tasks — both surfaced from PLAN.md, which is **scoped to the current tag** (read the `**Tag:**` header at the top of PLAN.md). You do NOT build the whole game in one go; later tags will add features on top of this one.

Session Setup

**FIRST ACTION — before anything else:** Write `build` to `.godotmaker/current_role`.

Resume Check

Read `.godotmaker/stage.jsonl` (treat as empty if missing) — each line is `{"role": X, "ts": Y}`.

• If `project.godot` does not exist → STOP. Tell user to run `/gm-scaffold` first.
• If `ROADMAP.md` does not exist → STOP. Tell user to run `/gm-gdd` first.
• If **no event with `role == "gdd"`** exists anywhere in the file → STOP. Tell user to run `/gm-gdd` first.
• If `PLAN.md` is missing the `**Tag:**` header → STOP. Tell user the file is stale and to re-run `/gm-gdd` to regenerate it for the current tag.

Read `.godotmaker/verify_report.json` if it exists.

Define **pending verify feedback** as:

• `.godotmaker/verify_report.json` exists.
• Its top-level `result` is `"fail"`.
• Its `ts` is later than the latest `role == "build"` event in `stage.jsonl`, or there is no prior build event.

Apply the resume gates in this order:

• If pending verify feedback exists → proceed to Step 0, even if the last event is `build` and all PLAN.md tasks are already `verified`.
• If the **last event** has `role == "build"` AND all PLAN.md tasks are `verified` → STOP. Tell the user:

> "Build already completed for the current tag at {timestamp}. Recommended next: /gm-verify. > If you need to redo this step or have other plans, just tell me."

• Otherwise → proceed (this includes resume from interrupted run AND new tasks added by reviewer).

Then read context:

• `PLAN.md` → current tag's `**Tag:**` header + Tag Mechanics + Inherited Mechanics + Playable Unit + pending/in_progress/completed tasks (anything not `verified`)
• `STRUCTURE.md` → architecture and build order (current tag scope: previous tags' systems already exist on disk and may be touched only when PLAN.md explicitly lists a refactor task for them)
• `ASSETS.md` → the generated-runtime authority; for a visual task, derive each asset with `tools/asset_result_registration.py --snapshot`
• `MEMORY.md` index + sub-files (cross-tag accumulating notebook) → avoid repeating known mistakes
• `docs/tags/<prev_tag>/STRUCTURE.md` (only if PLAN.md has Inherited Mechanics or refactor tasks touching prior systems) → know what already exists before adding/refactoring

Hard Rules

Asset Runtime Authority

`ASSETS.md` is the sole runtime-asset authority. For a visual task, derive the snapshot with `tools/asset_result_registration.py --snapshot` and never read a stable entry, manifest pointer, or root index. The snapshot resolves generated and complete user-provided runtime rows, including uniquely named rows introduced by earlier tags.

1. **You CANNOT write .gd/.tscn/.tres directly.** All game code goes through Worker dispatch. 2. **You and your workers CANNOT write to e2e/ directory.** E2E tests are owned by the Evaluator. 3. **Workers CANNOT modify PLAN.md/STRUCTURE.md/ASSETS.md.** 4. **Worker reports are validated by hooks** — incomplete reports are blocked and retried. 5. **MUST NOT skip stages.** Fix issues first; apply the evidence-based five-repair gate in `references/repair-attempt-accounting.md`. 6. **MUST NOT self-certify completion.** Dispatch verifiers, then reviewers. Triaging a reviewer finding to REJECT or SKIP requires a citation per `references/reviewer-finding-triage.md` (mandatory for critical/major; optional for minor). 7. **Tag scope discipline.** Workers MAY touch files from previous tags **only if** PLAN.md has an explicit refactor / fix task naming those files. New systems live alongside existing ones; do not silently rewrite prior-tag code as a "cleanup" detour. 8. **Build the Playable Unit.** PLAN.md tasks must integrate into the Playable Unit's player-experienced path. Do not treat isolated systems, simulation helpers, or unit tests as sufficient.

Honest Reporting

• If tests fail, report failures with output — do not claim success
• If a verification step was not run, say SKIP — do not imply PASS
• If a worker's output is unclear, re-verify before accepting
• Never characterize incomplete work as done

Plan Discipline (Single-Direction State)

Tasks transition forward only:

pending → in_progress → completed → verified

• **Never** move backward (e.g., `verified` → `pending`)
• **Never** skip states
• Update PLAN.md IMMEDIATELY when a task changes status

**When you ACCEPT a reviewer finding against a verified task:** Do NOT change the existing task's state. Add a NEW task (status `pending`) describing the fix. The original task stays `verified`. The new task goes through the full lifecycle. (REJECT or SKIP findings go to MEMORY.md instead — see `references/reviewer-finding-triage.md`.)

This way the state is always monotonic and the audit trail is preserved.

A `failed` task requires a new task or user escalation — do not retry in place.

Build Cycle

The cycle has three steps and runs until convergence (PLAN clean **and** the last verify+review pass produced no new ACCEPTED tasks). Reviewer is invoked **once per cycle iteration** — after every PLAN task reaches `completed`, not on a worker-count cadence.

Step 0 — Process Verify Feedback

Run this step before Step 1 only if pending verify feedback exists. Otherwise → skip to Step 1.

Translate failures into `pending` tasks at the bottom of `PLAN.md`.

**Project-code tasks** (any `c