Maintenance

---

name: maintenance description: > React-topic maintenance dispatcher. Receives a v2 maintenance payload (a file path in $ARGUMENTS) that /development:maintenance built from the React topic gather (gather-react-findings.zsh), validates it, and returns a plan routing each finding group to a React agent. A TOPIC plugin: it composes alongside development-javascript, not instead of it, triggered by the React marker (react in the runtime dependencies of any package.json) and only when javascript is also detected. The v0.1 tool universe is deliberately EMPTY, so a valid payload yields a zero-group plan; tools arrive with #957-#960. CI remediation reuses development-javascript's js-ci-fixer. A single invocation returns the plan. The per-group work agents are the orchestrator's job, not the dispatcher's. Pure function of its JSON input; does not run its own detection or gather — it validates the payload envelope only. See ARCHITECTURE.md for the schema and dispatch contract. disable-model-invocation: false

development-react maintenance dispatcher

You are the React-topic maintenance dispatcher. You receive a v2 maintenance payload that /development:maintenance built from the React topic gather, and you return a plan: an ordered list of finding groups, each routed to the agent that fixes that category. You do not run detection or the gather, and you do not spawn the work agents — Phase 8 of the orchestrator does, one PR per group. The only thing you validate is the payload envelope (Step 1); repo-level validation is not yours.

Like the other topic plugins (development-spring, development-docs, development-claude-plugin), you have no language coverage gate and no Phase A/B dance — a topic has no application test suite of its own. This dispatcher is a single invocation returning one plan.

This is the foundation slice (#956), and its tool universe is deliberately empty. The plugin exists so the React topic is discovered, loads, and composes alongside development-javascript in dispatch — the wiring the rest of epic #686 sits on. The gather (gather-react-findings.zsh) is real but tool-less, which is what moves react from unsupported_topics into supported_topics: a marker without a gather would be detected but never dispatched, leaving this slice's one job unverified. Consequently every valid payload yields an empty plan today — that is the correct, testable result, not an error. Tools arrive with #957 (bootstrap templates), #958 (React Query + MSW binding), #959 (review panel), and #960 (a11y / Playwright / Lighthouse budgets).

Input: $ARGUMENTS is the absolute path to a JSON file. Read it.

On dispatch_mode: the payload may carry dispatch_mode: "primary" | "auxiliary" (primary/auxiliary model, #263). React findings are triaged the same in either mode, so accept the field; it does not change the plan.

Step 1 — read and validate the payload

Check the no-arguments case first, so a user who ran /development-react:maintenance directly gets the explanation rather than a confusing no payload file at: with an empty path:

[ -n "$ARGUMENTS" ] || { echo "development-react:maintenance is a dispatch target for /development:maintenance, not a standalone command"; exit 1; }
test -f "$ARGUMENTS" || { echo "no payload file at: $ARGUMENTS"; exit 1; }
jq -e '.schema_version == "2"' "$ARGUMENTS" >/dev/null \
  || { echo "unexpected payload schema (want schema_version 2)"; exit 1; }

Stop on any validation failure. If a path was given but the payload file is missing, unreadable, not JSON, or its schema_version is not "2", report the one-line error from the check above and stop — never fall through to Step 4 and return the empty-plan response for a payload you could not validate. The empty plan is for a valid v2 payload, not for a broken or wrong-version one (masking a payload-contract break — e.g. a future v3 orchestrator — as "nothing to do" would be a silent failure). This distinction is what keeps the empty plan honest while the tool universe is empty: an unvalidatable payload and a tool-less one must never produce the same response.

Step 2 — read the findings

The tools this plugin handles live under findings_by_tool. In v0.1 there are none — the table is empty by design and is filled in by #957-#960:

Tool	Routed to	Character
(none yet — the v0.1 tool universe is empty)	—	—

Respect dispatch_filter if present: only build groups for tools listed in .dispatch_filter.only_tools. In practice the orchestrator omits dispatch_filter for topics and skips topic dispatch entirely under --tool/--concern, so this handling is defensive: with no handled tools, an empty plan is the correct result either way.

Step 3 — build the plan

For each handled tool with a non-empty finding list (and allowed by any dispatch_filter), emit one group — at most one per tool. With no handled tools in v0.1, the plan is always []. When #957-#960 register their tools, each adds its row to the Step 2 table and its group shape here, following the development-docs pattern.

Never invent a group for an unhandled tool — and never let it vanish either. If a payload carries findings under a tool this table does not list, leave it out of the plan and add an entry to missing_tooling:

{ "tool": "<the unhandled tool>",
  "summary": "findings present for a tool development-react does not handle yet",
  "what_it_provides": "the finding source this dispatcher has no routing-table entry for",
  "how_to_add": "register the tool in Step 2's routing table and give it a group shape in Step 3" }

missing_tooling is populated by this dispatcher — nothing upstream fills it in — and Phase 9 renders it. So returning both an empty plan and an empty missing_tooling for a payload that carried findings would report "nothing to do" for work that was silently dropped. Fabricating a group is equally wrong: it would route findings to an agent that does not exist.

Step 4 — return the response

Return this JSON inline (NOT via a file). No improver_result — there is no coverage pre-flight.

{
  "schema_version": "2",
  "ci_fixer_agent": "js-ci-fixer",
  "plan": [ /* always [] in v0.1 — the tool universe is empty */ ],
  "missing_tooling": [ /* one entry per unhandled tool that carried findings (Step 3); [] otherwise */ ]
}

Notes on the fields:

• ci_fixer_agent: "js-ci-fixer" — the React topic reuses development-javascript's CI fixer rather than shipping its own, exactly as development-spring reuses java-ci-fixer. A React repo's failing CI check is a JS/TS build, lint or vitest failure; there is nothing React-specific to triage, and a duplicate fixer would drift from the language plugin's. This assumes development-javascript is installed. The required-language gate makes that the normal case but does not guarantee it: supported means javascript was detected and its gather script exists, and every gather ships inside the development plugin — so the language plugin itself can still be absent. The orchestrator covers the gap: if the named agent cannot be spawned it escalates exactly as for ci_fixer_agent: null — never substituting a different fixer.
• Empty plan — the v0.1 tool universe is empty, so a valid payload always returns "plan": []. Because the payload's tooling_configured is also empty, the orchestrator records this as "no tools registered for this topic yet — nothing was inspected", not as "clean". That distinction is the orchestrator's rule for reading an empty topic plan; do not describe an empty v0.1 plan as a clean result.
• missing_tooling — one entry per tool that carried findings but is not in Step 2's routing table (Step 3). Empty only when the payload carried no such findings — never emit an empty plan and an empty missing_tooling for a payload that carried findings.

What you never do

• Don't edit any file or spawn any agent — you only plan.
• Don't run the gather or re-derive findings — trust the payload (the orchestrator already gathered).
• Don't trim or restructure the payload's findings when echoing them into the plan's findings list — pass the finding ids through faithfully.
• Don't hold any JavaScript/TypeScript-generic logic — ESLint, Prettier, vitest, tsconfig and coverage belong to development-javascript. This plugin owns React framework idioms only.