# GDScript Parser Interview Transcript

## Q1: Signal Argument Representation
**Q:** Should signal args capture types too? e.g. `cash_changed(new_amount: float, delta: float)` — store as `[("new_amount", "float"), ...]` or just `["new_amount", "delta"]`?

**A:** Name + type tuples. Store `(arg_name, type_hint)` pairs for richer AI analysis data.

## Q2: Autoload Detection Strategy
**Q:** For autoload detection (e.g. `EconomyManager.add_cash()`), should the parser use a hardcoded list from config, scan project.godot, or detect heuristically?

**A:** Configurable list. Pass known autoload names to `parse_gd()` — most accurate, no false positives.

## Q3: Function end_line Tracking
**Q:** For function `end_line` tracking, should the parser track indentation to find where each function body ends, or mark end_line as line before next declaration?

**A:** Indentation-based. Track indent level to precisely detect function body end — handles nested classes correctly.

## Q4: Export Annotation Representation
**Q:** Should the parser store the full annotation text or decompose it into structured fields?

**A:** Full annotation text. Store raw annotation string — simpler, lossless, easy to display.

## Q5: Error Handling Strategy
**Q:** How should malformed or partially-parseable .gd files be handled?

**A:** Best-effort parse. Extract what we can, skip unparseable lines, no exceptions — real codebases have WIP files.

## Q6: Inner Class Handling
**Q:** Should the parser detect inner classes and extract their contents, or just track names?

**A:** Track names only. Record inner class names — sufficient for cross-referencing without deep parsing complexity.

## Q7: API Signature Style
**Q:** Should `parse_gd()` accept a file path (like parse_tscn) or raw content string?

**A:** File path (like parse_tscn). `parse_gd(path: str)` reads file internally, matching existing pattern. Consistent API.
