# Sprint — Script Error Detection + Real Gameplay Testing

## Deep plan richiesto

Leggi prima questi file per capire l'architettura attuale:
- `godot-addon/addons/godotiq/godotiq_server.gd` — handler principale
- `godot-addon/addons/godotiq/godotiq_debugger.gd` — cattura errori (se esiste)
- `src/godotiq/tools/bridge/run.py` — come runna il gioco
- `src/godotiq/tools/bridge/node_ops.py` — _editor_state helper
- `src/godotiq/prompts/godot_development.md` — prompt MCP

Poi genera il plan e aspetta conferma.

---

## Problema 1: L'agent non vede errori di compilazione GDScript

### Situazione attuale

Quando l'agent scrive uno script con errori (tipo `TONE_MAP_ACES` che non
esiste, o type inference fallita), Godot mostra gli errori nella tab "Errori"
dell'editor. Ma l'agent non li vede — nessun tool li restituisce.

Il `_editor_state.recent_errors` cattura solo errori runtime dal debugger
(push_error, crash durante l'esecuzione). Gli errori di compilazione script
sono un sistema diverso in Godot.

### Fix richiesto: Tool `godotiq_check_errors` o integrazione nel workflow

**Opzione A (preferita): Tool dedicato `godotiq_check_errors`**

Nuovo tool che chiede all'editor di fare un syntax check su tutti gli script
del progetto e restituisce gli errori di compilazione.

GDScript handler:
```gdscript
func _handle_check_errors(peer_id: int, id: String, params: Dictionary) -> void:
    var errors: Array = []

    # Metodo 1: Usa EditorInterface per ottenere errori script
    # Verifica se EditorInterface ha un metodo per script errors
    # Possibili API:
    # - EditorInterface.get_script_editor().get_open_scripts()
    # - Iterare sui file .gd e provare a load() ognuno — se fallisce, errore

    # Metodo 2: Usa la command line di Godot per check
    # Godot ha un flag --check-only o --validate-project che valida senza runnare
    # Ma questo richiede lanciare un processo separato

    # Metodo 3: Prova a load() ogni script modificato di recente
    var script_paths: Array = _get_all_script_paths()
    for path in script_paths:
        var script = load(path)
        if script == null:
            errors.append({"file": path, "error": "Failed to load script"})
            continue
        # Se carica ma ha errori di parsing, Godot li logga
        # Verifica se GDScript ha un metodo per validare

    # Metodo 4 (più affidabile): Leggi i log dell'editor
    # Godot scrive errori nel log file — trova il path del log e leggilo

    send_response(peer_id, id, {
        "errors": errors,
        "total": errors.size()
    })
```

**IMPORTANTE**: Cerca nel codebase Godot e nella documentazione quale API
è disponibile per ottenere errori di compilazione script dall'EditorPlugin.
Possibili strade:

1. `EditorInterface.get_resource_filesystem().get_filesystem()` — scan per errori
2. Ascoltare il signal `script_changed` o `resource_saved` dell'editor
3. `GDScript.new()` + `source_code` + controllare se ha errori
4. Leggere il file di log di Godot (`user://logs/godot.log`)
5. Usare `EditorInterface.get_script_editor()` per accedere alla lista errori

Testa quale approccio funziona e implementa quello più affidabile.

**Opzione B (fallback): Check errors post-build**

Se non c'è un modo pulito per ottenere errori di compilazione dall'editor,
aggiungi un check nel tool `run`. Quando l'agent chiama `run(action="play")`:

1. Prima di runnare, prova a caricare tutti gli script del progetto con `load()`
2. Se qualche script fallisce il load → restituisci gli errori SENZA runnare
3. Se tutti caricano → runna normalmente

Questo cattura almeno gli errori di sintassi e di riferimenti mancanti.

**Opzione C (minima ma utile): Log parser**

Godot scrive tutti gli errori in un file log. Trova il path del log
(tipicamente `~/.local/share/godot/app_userdata/PROJECT_NAME/logs/` su Linux,
`~/Library/Application Support/Godot/app_userdata/PROJECT_NAME/logs/` su macOS).

Aggiungi un metodo `_get_recent_errors()` che legge le ultime N righe del
log file e filtra per "ERROR" o "SCRIPT ERROR".

Questo non richiede nessuna API dell'editor — solo leggere un file di testo.

### Quale implementare

Analizza le opzioni, testa quale funziona nella tua versione di Godot, e
implementa la più affidabile. L'obiettivo finale è: quando l'agent chiama
qualsiasi tool bridge, se ci sono errori di compilazione negli script,
li riceve nella response.

---

## Problema 2: L'agent non testa davvero il gameplay

### Situazione attuale

Il prompt MCP dice di fare "gameplay test" ma l'agent interpreta questo come:
1. `run(action="play")`
2. `state_inspect` per verificare valori iniziali
3. `run(action="stop")`

Non prova MAI le interazioni reali: non clicca bottoni, non piazza torri,
non verifica che ogni feature del gioco funziona davvero.

### Fix: Sezione "Real Gameplay Testing" nel prompt MCP

Sostituisci la sezione "5. Gameplay Test" nel "MANDATORY: Final QA" con
questa versione espansa:

```markdown
### 5. Real Gameplay Testing (NOT just state_inspect)

You MUST actually PLAY the game, not just check initial values.

Step 1 — Start and verify initial state:
  run(action="play"), wait 3 seconds
  state_inspect → verify starting values (gold, lives, score, etc.)

Step 2 — Test EVERY interactive feature:
  For each button/interaction in the game:
  a) Use ui_map(detail="brief") to find clickable elements
  b) Use input to click/tap each interactive element
  c) Use state_inspect to verify the expected change happened
  d) If something didn't change → that's a bug, fix it

  Examples of what to test:
  - "Start Wave" button → enemies should spawn → verify with state_inspect
  - Tower placement → click on terrain → verify tower was created
  - Enemy reaches end → lives should decrease
  - Enemy killed → gold should increase
  - Game over condition → when lives reach 0

Step 3 — Wait for a complete cycle:
  If the game has waves/rounds:
  a) Start a wave
  b) input(commands=[{"wait_ms": 10000}]) to let it play out
  c) state_inspect → verify enemies were processed (killed or reached end)
  d) Verify gold changed, verify lives changed (or stayed same if all killed)

Step 4 — Check for runtime errors:
  After playing, check _editor_state.recent_errors in the response.
  If any errors appeared during gameplay → those are bugs, fix them.

Step 5 — Stop and report:
  run(action="stop")
  Report: "Gameplay test results: [what worked, what didn't, errors found]"

CRITICAL: If you built a game with tower placement, YOU MUST try placing
a tower during the test. If you built a game with a shop, YOU MUST try
buying something. Test every player-facing feature, not just wave spawning.
```

### Aggiunta: Prompt section "Test-Driven Completion"

Aggiungi PRIMA della sezione QA:

```markdown
## Test-Driven Completion

You are NOT done when the code compiles. You are NOT done when the game
starts without crashing. You are done when EVERY FEATURE WORKS during
actual gameplay.

A game that starts but where towers don't shoot is BROKEN.
A game that runs but where buttons don't work is BROKEN.
A game where the score doesn't update is BROKEN.

After building, always ask yourself: "If a player tried every feature
right now, would it all work?" If you're not sure, TEST IT with the
runtime tools (run, input, state_inspect).

The user cannot fix your bugs. You must find them yourself.
```

---

## Problema 3: Efficienza generale

### Fix: "Act, Don't Plan" reinforcement nel prompt

Trova la sezione "Efficiency Rules" nel prompt e aggiungi/rafforza:

```markdown
### Act immediately

When you know the next step, execute it. Do not write a multi-paragraph
plan of what you're about to do. The tool will tell you if something is
wrong — act on the response, don't pre-plan for every contingency.

Bad:
  "Now I need to create the enemy script. I'll need to consider the path
   following system, health management, signal emissions, and death
   handling. Let me plan the structure: first I'll define the exports,
   then the signals, then the _ready function..."
  [2 minutes of thinking]
  [then writes the script]

Good:
  [writes the script immediately]
  [calls validate]
  [if errors: fixes them]

The fastest workflow is: act → check → fix → repeat.
Not: think → think → think → act → discover problems → think again.

### Maximum 2 paragraphs of explanation between tool calls

After a tool call, explain what happened in 1-2 sentences max, then
make the next tool call. Do not write essay-length analysis of the
results. The user can read the tool output themselves.
```

---

## File da modificare

| File | Cosa |
|------|------|
| `godot-addon/addons/godotiq/godotiq_server.gd` | Nuovo handler `_handle_check_errors` (o integrazione in `_get_editor_state`) |
| `src/godotiq/tools/bridge/` | Nuovo tool `check_errors.py` OPPURE aggiornamento di `run.py` per pre-check |
| `src/godotiq/server.py` | Registra nuovo tool (se creato) |
| `src/godotiq/prompts/godot_development.md` | Real Gameplay Testing section + Test-Driven Completion + Act Don't Plan |

## File da NON toccare
- Parser (tscn, gd, scene_resolver, project_index)
- Tool di analisi (scene_map, dependency_graph, etc.)
- build_scene
- Test esistenti

## Verifica

```bash
pytest tests/ -v
```

E poi test manuale:
1. Scrivi uno script con errore intenzionale (tipo `TONE_MAP_ACES`)
2. Chiama il tool che cattura errori
3. Verifica che l'errore appare nella response
