reactor-dev: prefer mur check over dotnet build; ignore runs/ (#295)

- Steer the reactor-dev agent at `mur check` as the inner loop (same exit
  code as `dotnet build`, plus `→ try:` did-you-mean suggestions). Tells
  the agent to trust suggestions verbatim and not re-run `dotnet build`
  to confirm a green check — mirrors the eval-prompt guidance we use to
  A/B test agents in TokenCountTest.
- Ignore `runs/` — local eval/scratch output that shouldn't be tracked.

Author: codemonkeychris

.gitignore

@@ -213,6 +213,9 @@ tests/stress_perf/publish_log*.txt
 coverage/
 *.cobertura.xml
 
+# Eval / scratch run output — local artifacts from eval drivers, never tracked.
+runs/
+
 # Stress-perf benchmark run artifacts (local measurement data).
 tests/stress_perf/bench-results/
 tests/stress_perf/baseline-*.csv

plugins/reactor/agents/reactor-dev.agent.md

@@ -6,24 +6,48 @@ user-invocable: true
 
 ## Process
 
-You build Reactor apps in this rhythm:
+> ### ⚠️ ALWAYS start a new app with `dotnet new reactorapp`
+>
+> Unless the user has explicitly asked you to do something else (e.g. modify an existing project, write a single-file `#:package` script on purpose, or convert from XAML/MVVM into an existing tree), **your very first action on a new Reactor app is:**
+>
+> ```
+> dotnet new reactorapp -n <AppName>
+> ```
+>
+> Run it from the workspace root. It produces a working `.csproj` and `App.cs` already wired against `Microsoft.UI.Reactor` (the `App.cs` carries its own `using` directives — there is no `GlobalUsings.cs`, and you should not add one). **Edit that. Do not hand-write a `.csproj` and `App.cs` from scratch** — that path consistently leads to invented API names (`UseElementFocus`, `AutomationLandmarkType.Complementary`, etc.), wasted `mur check` round-trips, and longer sessions.
+>
+> If the template isn't installed yet, install it before scaffolding:
+>
+> ```
+> dotnet new install Microsoft.UI.Reactor.ProjectTemplates
+> ```
 
-1. **Understand the task.** Note what the app needs to do and what shape (single-file vs. .csproj). Don't guess at requirements.
-2. **Draft.** Sketch the component tree, identify state, decide where each piece lives. If you know how you'd build the equivalent in React, you already know the shape — just translate to the C# spelling.
-3. **Write the files in a batch.** Create the csproj, models, app root, and child components together in one stretch. Don't stop and rebuild after each file — build once at the end.
-4. **Build and read the output.** `dotnet build` (or `dotnet run`). Read errors and analyzer warnings; fix them in another batch; rebuild.
+You build Reactor apps in this rhythm: scaffold → understand requirements → draft component tree → write files in a batch → `mur check`.
 
-You generally do **not** need to load anything beyond `reactor-getting-started` — it carries the hooks table, the most-used factories, the React-to-Reactor mapping, theme tokens, and the critical gotchas. The full signatures index lives in `reactor-dsl/references/reactor.api.txt` if you need a less-common control.
+Before continuing
+
+1. Load the `reactor-getting-started` skill — it carries the hooks table, the most-used factories, the React-to-Reactor mapping, theme tokens, and the critical gotchas.
+2. Load the `reactor-design` skill — it has Fluent Design rules for Reactor (theme tokens, typography, 4px grid, High Contrast, accessibility audit).
+
+Then for each task:
+
+1. **Scaffold first** (see the callout above). For a new app: `dotnet new reactorapp -n <AppName>`. Skip this step *only* if the user has told you to write a single-file script, edit an existing project, or otherwise asked for a non-scaffolded shape.
+2. **Understand the task.** Note what the app needs to do. Don't guess at requirements.
+3. **Draft.** Sketch the component tree, identify state, decide where each piece lives. If you know how you'd build the equivalent in React, you already know the shape — just translate to the C# spelling.
+4. **Write the files in a batch.** Add models and child components in one stretch on top of the scaffolded `App.cs`. Don't stop and rebuild after each file — build once at the end.
+5. **Run `mur check` and read the output.** `mur check <path>` is the build — it runs `dotnet build` under the hood, returns the same exit code, and adds skill pointers for `REACTOR_*` IDs plus `→ try: <name>` did-you-mean suggestions for unknown identifiers. When it exits 0, you are done — **do not re-run `dotnet build` to confirm**; it's the same compilation. Read errors and analyzer warnings; fix them in another batch; re-run `mur check`. Fall back to `dotnet build` / `dotnet run` only if `mur` isn't on PATH.
+
+Beyond those two, load topical skills only when the task hits them — see the table below. The full signatures index lives in `reactor-dsl/references/reactor.api.txt` if you need a less-common control.
 
 ## When to load each skill
 
 | Skill | Trigger |
 |---|---|
-| `reactor-getting-started` | Any new Reactor work. Always first, almost always sufficient. |
+| `reactor-getting-started` | **Always load up front** — hooks table, factories, React-to-Reactor mapping, theme tokens, critical gotchas. |
+| `reactor-design` | **Always load up front** — Fluent Design rules, theme tokens, typography, 4px grid, High Contrast, accessibility audit. |
 | `reactor-dsl` | Only when `reactor-getting-started` doesn't list the factory/modifier you need — points to the full api index. |
-| `reactor-build-and-check` | Build fails, you see a `REACTOR_*` analyzer warning, or you want one-line diagnostic output. |
+| `reactor-build-and-check` | `mur check` reports an error you can't fix from the diagnostic alone, you see a `REACTOR_*` analyzer warning you don't recognize, or you need the iteration-vs-`--final` / passthrough-flag details. |
 | `reactor-async` | Fetching data, caching, pagination, optimistic writes. `UseResource`, `UseMutation`, `UseInfiniteResource`. |
-| `reactor-design` | Visual styling — theme tokens beyond the basics, High Contrast, typography, 4px grid, accessibility audit. |
 | `reactor-forms` | Data-entry screens, validation, masked input. `UseValidationContext`, `FormField`. |
 | `reactor-navigation` | Multi-page apps, sidebar/tab navigation, routes, deep linking. |
 | `reactor-input` | Gestures, drag-drop, focus management. |
@@ -39,9 +63,9 @@ If the plugin isn't installed, fall back to `mur --skill` / `mur --api` / cache-
 ## Best practices
 
 - **Trust your React intuition for shape.** Reactor's component model, hook semantics, key-based reconciliation, and "lift state up" pattern are all React. The C# spelling is the only thing new — verify exact names against the table in `reactor-getting-started` or the api index.
-- **Batch your edits.** A single turn that creates five related files is much cheaper than five turns that each create one. Same for fix-ups: read the build output, plan all the fixes, apply them together, then rebuild.
-- **Build at the end, not after every file.** One green build at the end is the goal, not a green build at every step.
+- **Batch your edits.** A single turn that creates five related files is much cheaper than five turns that each create one. Same for fix-ups: read the build output, plan all the fixes, apply them together, then re-run `mur check`.
+- **Build at the end, not after every file.** One green `mur check` at the end is the goal, not a green build at every step.
+- **`mur check` is the inner loop; trust `→ try:` suggestions verbatim.** A `→ try: <name>` suggestion has already been computed against the live Reactor surface for that exact diagnostic — use the suggested name in your next edit. **Do not grep the codebase, `reactor.api.txt`, or sibling names to second-guess it.** If it's wrong, the next `mur check` will say so and emit a new suggestion — that self-correcting cycle is the cheap loop; manual verification breaks it. Once `mur check` exits 0, you're done — never re-run `dotnet build` to "confirm" the same compilation.
 - **Hooks must be called unconditionally.** Same order every render. Conditionally use the *result*, not the call.
-- **Single-file `#:package` is the default for new apps.** Use a `.csproj` only when the app needs multiple files, analyzers (which only run with `.csproj`), or shared project references.
 - **Don't grep `src/Reactor/`.** The bundled api index is the source of truth for public API. Source-code grep is slower and includes private/internal noise.
 - **Don't add features beyond what's asked.** Reactor's DSL composes; resist building elaborate scaffolding for simple tasks.