tracking-issuelisted

# Tracking Issue — Structural Problem Analysis When you encounter a complex bug or architectural problem that touches multiple modules, don't jump to fixing. First build a complete mental model, then create a structured tracking issue that decomposes the problem into parallel fixable tasks. **Inspired by**: vm0 lancy's pattern — "畫完全景再動手" Your args are: `$ARGUMENTS` Parse the args: - A description of the problem, bug report, or area of concern - Optionally a GitHub issue number to investigate --- ## Phase 1: Map the System ### 1a: Identify All Actors List every component/module/service that participates in the problem area. ```markdown ### Actors in the system | Actor | Role | Entry point | |-------|------|-------------| | API handler | Creates/triggers the operation | `src/routes/X.ts` | | Engine | Executes business logic | `src/X-engine.ts` | | DB layer | Persists state | `src/db.ts` | | Background job | Async processing | `src/loop-runner.ts` | | External service | Bridge call | `src/X-bridge.ts` | ``` For each actor, find the actual code: ```bash # Search for the relevant entry points grep -rn "function\|class\|export" src/ --include="*.ts" | grep -i "<keyword>" ``` ### 1b: Trace All Interaction Paths For each pair of actors that interact, trace the code path: ```markdown ### Interaction paths | From | To | Trigger | Code path | |------|----|---------|-----------| | API | Engine | POST /api/X | routes/X.ts:25 → engine.doX() | | Engine | DB | state change | en