/gm-fixgap

name: gm-fixgap
description: |
  Fix gaps identified by the Evaluator. Generates GAP.md from evaluation.json,
  dispatches workers to address critical/major issues, then runs one final
  verify+review pass. Unlike gm-build (PLAN.md-driven), gm-fixgap is GAP.md-driven.
  Explicit invocation only — use /gm-fixgap.
disable-model-invocation: true

GodotMaker Fix Gap

$ARGUMENTS

You are fixing specific issues identified by the Evaluator. You read the evaluation report, generate a GAP.md task list, dispatch workers to address each gap, then run one final verify+review pass.

**Loop position:** `/gm-fixgap` is never terminal. The cycle is `/gm-fixgap → /gm-verify → /gm-evaluate`. Evaluate either approves (→ `/gm-accept`) or surfaces new gaps (→ another `/gm-fixgap`).

Session Setup

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

Resume Check

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

• If **no event with `role == "evaluate"`** exists anywhere in the file OR `.godotmaker/evaluation.json` does not exist → STOP. Tell user to run `/gm-evaluate` first.
• If `evaluation.json` `result` is `"approve"` → STOP. Tell the user:

> "The latest evaluation was already approved. Recommended next: /gm-accept. > If you need to redo this step or have other plans, just tell me."

• If the **last event** has `role == "fixgap"` AND `GAP.md` is not at project root (already archived) → STOP. Tell the user:

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

• Otherwise → proceed (fresh fixgap or repeat fixgap is both valid).

Then read context:

• `GAP.md` (if present) → existing fix progress; find tasks not yet `verified`. If missing, Step 1 will generate it from `evaluation.json` (and `verify_report.json`).
• `.godotmaker/evaluation.json` → the source of truth for product-layer issues to fix
• `.godotmaker/verify_report.json` → mechanical-layer failures from the most recent verify
• `PLAN.md` → read-only; current tag's `**Tag:**` header tells you which tag's gaps you're fixing. The same tag-scope discipline as gm-build applies: previous tags' code is touchable only when a GAP item explicitly names it.
• `STRUCTURE.md` → architecture (fixes need to respect existing system boundaries)
• `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 → stable architecture decisions and project constraints

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 GAP.md/PLAN.md/STRUCTURE.md/ASSETS.md.** 4. **Worker reports are validated by hooks** — incomplete reports are blocked and retried. 5. **Only fix what `evaluation.json` or a fresh `verify_report.json` identified.** Do not add features or refactor unrelated code. 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. **Do not promote non-blocking visual findings.** If evaluation or verification marks a visual finding as style-only or non-blocking, keep it in notes/minor issues; do not create a new C/J task from it.

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)

GAP.md tasks transition forward only:

pending → in_progress → completed → verified

• **Never** move backward (e.g., `verified` → `pending`)
• **Never** skip states
• Update GAP.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`) in GAP.md describing the fix. The original task stays `verified`. The new task goes through the full lifecycle. REJECT and SKIP do not create tasks; 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.

Do NOT update PLAN.md task statuses — fixgap operates from `evaluation.json` gaps, not the original plan.

Build Cycle

Step 1 — Read Evaluation (+ Verify Feedback), Generate or Resume GAP.md

GAP.md may need tasks from two sources:

1. **`.godotmaker/evaluation.json`** — product-layer issues found by the evaluator. Always processed. 2. **`.godotmaker/verify_report.json`** — mechanical-layer failures from the most recent verify pass. Processed only when fresh.

1a. Pull issues from `evaluation.json`

Create one critical evaluation-source GAP task for each `playable_unit.rows.*` entry with `result == "fail"`. Include the row key, test path, and evidence entries. Fix the game code or runtime path. Do not reduce the `PLAN.md` or `e2e/` contract.

For each E2E-sourced issue, decide the repair path before writing GAP tasks:

• Fix runtime behavior when the observable gameplay requirement is missing.
• Add or expose deterministic test interfaces when evidence includes

`requested_test_