Fix Traycer phase mode tools JSON syntax

Traycer AI/phase_mode_tools.json

@@ -292,7 +292,7 @@
   },
 
   "write_phases": {
-    "description": "Use this tool to break any sizeable coding task—refactor or new feature—into *independently executable phases* that **always leave the codebase compiling and all tests green**. Stay laser-focused on code-level work; skip phases that belong to infra provision, deployment, monitoring, or other non-development concerns.\n\n### Phase-sizing guidelines\n\n* Treat each phase like a well-scoped pull request: one coherent chunk of work that reviewers can grasp at a glance.\n* If a single file refactor (or similarly small change) completes the task, keep it to one phase—don't force extra steps.\n* Conversely, split phases when a change grows too large or mixes unrelated concerns.\n\n### Core principles\n\n1. **Shadow, don't overwrite**\n  * Introduce parallel symbols (e.g., `Thing2`) instead of modifying the legacy implementation.\n  * Keep the original path alive and functional until the final "cut-over" phase.\n\n2. **Phase-by-phase integrity**\n  * Every phase must compile, run existing tests, and, where necessary, add new ones.\n  * Do not advance while dead code, broken interfaces, or failing checks remain.\n  * For example, if an API's return type changes, update all its consumers in the same phase.\n\n3. **Leverage the legacy reference**\n  * Continuously compare new code to the old implementation.\n  * Can add explicit phases or instructions in phases to do this at critical junctures.\n\n4. **Final phase**\n  * This phase needs to verify that the required behavior is fully reproduced.\n  * Rename or swap entry points, remove `Thing` vs `Thing2` duplication, and delete obsolete paths once the new code is proven.\n\nNote: Before coming up with phase breakdown, step back to make sure you are following the core principles and guidelines.",
+    "description": "Use this tool to break any sizeable coding task—refactor or new feature—into *independently executable phases* that **always leave the codebase compiling and all tests green**. Stay laser-focused on code-level work; skip phases that belong to infra provision, deployment, monitoring, or other non-development concerns.\n\n### Phase-sizing guidelines\n\n* Treat each phase like a well-scoped pull request: one coherent chunk of work that reviewers can grasp at a glance.\n* If a single file refactor (or similarly small change) completes the task, keep it to one phase—don't force extra steps.\n* Conversely, split phases when a change grows too large or mixes unrelated concerns.\n\n### Core principles\n\n1. **Shadow, don't overwrite**\n  * Introduce parallel symbols (e.g., `Thing2`) instead of modifying the legacy implementation.\n  * Keep the original path alive and functional until the final \"cut-over\" phase.\n\n2. **Phase-by-phase integrity**\n  * Every phase must compile, run existing tests, and, where necessary, add new ones.\n  * Do not advance while dead code, broken interfaces, or failing checks remain.\n  * For example, if an API's return type changes, update all its consumers in the same phase.\n\n3. **Leverage the legacy reference**\n  * Continuously compare new code to the old implementation.\n  * Can add explicit phases or instructions in phases to do this at critical junctures.\n\n4. **Final phase**\n  * This phase needs to verify that the required behavior is fully reproduced.\n  * Rename or swap entry points, remove `Thing` vs `Thing2` duplication, and delete obsolete paths once the new code is proven.\n\nNote: Before coming up with phase breakdown, step back to make sure you are following the core principles and guidelines.",
     "parameters": {
       "howDidIGetHere": {
         "description": "Keep this section under 150 words, and use markdown format. Document the investigative steps and discoveries that shaped the phase plan. Do not mention exact tool names, instead mention that as a verb. E.g. list_files tool call can be described as 'I listed the files'.",