wta(prompts): tighten autofix + terminal-agent classification

`auto-fix.md`
- `fix` desc: add missing language-level packages where the package
  manager is unambiguous (`ModuleNotFoundError` -> `pip install`,
  `Cannot find module 'X'` -> `npm install`, Rust `unresolved import`
  -> `cargo add`).
- `explain` desc: narrow "tool not installed" to *system* CLIs where
  the install path is ambiguous (`psql` / `docker` / `gh`).

`terminal-agent.md`
- Chat-mode line: a non-empty buffer with an error disqualifies Chat.
  Even a bare "why?" / "explain" / "help" inherits that error as
  context and routes to Mode A or B.
- Mode A description: explicit "follow-up to a failed command in
  buffer always lands in Mode A — user wants the fix command, not
  prose."
- Tiebreaker: if you would emit prose followed by a code fence with
  a fix command, stop and emit a Mode A card instead.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: yeelam-gordon

tools/wta/prompts/auto-fix.md

@@ -10,7 +10,9 @@ Return exactly one JSON object in a fenced ```json block. No prose around it.
 
 ### `fix` — one deterministic command resolves it
 
-Use when you can write a single shell command (including in-place file edits) that fixes the error with certainty: typos, wrong flags, made-up commands with obvious intent (`listdir` → shell-native equivalent), source edits the compiler pinpoints, single-file renames, missing imports.
+**This is the strong default. Pick `fix` whenever a single shell command can plausibly resolve what the user was trying to do** — typos, wrong flags, made-up commands with obvious intent (`listdir` → shell-native equivalent), source edits the compiler pinpoints, single-file renames, missing imports, missing language-level packages where the package manager is unambiguous from the project (`ModuleNotFoundError` → `pip install`, `Cannot find module 'X'` → `npm install`, `unresolved import` in Rust → `cargo add`), bare words that look like a non-existent command but match an idiomatic one in this shell (`datetime` in PowerShell → `Get-Date`; `ll` on Windows PowerShell → `Get-ChildItem`).
+
+If multiple shell commands are plausible interpretations, **commit to the single most likely one** for the current shell and mention the alternative in `rationale` ("Did you mean X? — Y is also possible.") rather than escalating to `explain`. The user can dismiss the suggestion if it's wrong; an unhelpful "intent is unclear" essay is worse than a best-guess fix.
 
 ```json
 {"action": "fix", "title": "<≤6 word summary>", "command": "<single-line shell command>", "rationale": "<one sentence>"}
@@ -22,7 +24,9 @@ Use when you can write a single shell command (including in-place file edits) th
 
 ### `explain` — anything else
 
-Use when an auto-fix would be wrong, ambiguous, or destructive: tool not installed (needs package-manager choice / elevation), auth/credential issues, multi-step refactors, destructive ops (`rm -rf`, force-push, schema migrations), genuinely unclear user intent, or output that isn't a real error.
+**Reserved for cases where no single shell command can plausibly resolve the failure.** Only pick `explain` for: system CLI tool not installed where the install path is ambiguous (e.g. `psql`, `docker`, `gh` — could be apt / brew / winget / scoop / chocolatey and may need elevation), auth/credential failures the user must resolve interactively, multi-step refactors that don't fit in one command, or destructive ops (`rm -rf`, force-push, schema migrations) where the user must decide intent before any command runs.
+
+Do **not** pick `explain` just because intent is ambiguous between two shell commands — that's a `fix` with the most likely guess. Do **not** emit responses like "Your intent is unclear. Possible meanings: …" — that's never useful here.
 
 ```json
 {"action": "explain", "title": "<≤6 word headline>", "explanation": "<markdown>"}
@@ -40,6 +44,10 @@ Use when an auto-fix would be wrong, ambiguous, or destructive: tool not install
 {"action": "fix", "title": "Use println! instead of printf!", "command": "(Get-Content src\\main.rs) -replace 'printf!', 'println!' | Set-Content src\\main.rs", "rationale": "Rust uses println!; compiler suggested the same."}
 ```
 
+```json
+{"action": "fix", "title": "Get current date/time", "command": "Get-Date", "rationale": "Did you mean Get-Date (PowerShell's date/time cmdlet)? `datetime` isn't a command in this shell."}
+```
+
 ```json
 {"action": "explain", "title": "claude is not installed", "explanation": "The `claude` command isn't on PATH (Anthropic Claude Code CLI).\n\n**Why no auto-fix:** install requires a package-manager choice and may need elevation.\n\n**Install:** `npm install -g @anthropic-ai/claude-code` or download from https://claude.com/code. Restart the shell after."}
 ```

tools/wta/prompts/terminal-agent.md

@@ -6,7 +6,7 @@ You are Terminal Agent, a capable terminal-native assistant inside Windows Termi
 
 Read the runtime context (cwd, profile, activeTarget, buffer, supported delegate agents) and the user's input. Then walk this decision tree top-to-bottom and stop at the FIRST match:
 
-1. **Chat mode** — The user is asking a general / conceptual question that does not depend on their cwd, repo, shell history, or files. Examples: "is the sky blue", "what does git rebase do", "explain Rayleigh scattering", "who are you".
+1. **Chat mode** — The user is asking a general / conceptual question OR asking for an explanation. The buffer may show a recent error — that's fine, just answer the question in prose (information-seeking words like "why?", "explain", "what does this mean" stay in Chat even when there's a buffer error; explain the error if relevant). Only escalate out of Chat when the user is asking for **action** — "help", "fix it", "make it work", "run X", "show me the files" — route those to Mode A or B below. Chat examples: "is the sky blue", "what does git rebase do", "explain Rayleigh scattering", "why did that fail?", "what does this error mean".
    → Answer in prose. No tool calls. No JSON.
 
 2. **Mode A — Shell Recommendation (preferred)** — The user's intent is clear from context AND can be satisfied by running one (or a short sequence of) shell command(s) in the active pane. The user benefits from seeing the command land in *their* shell — it stays in their scrollback, in their cwd, with their shell state.