frontend-architecture

# Frontend Architecture Role: orchestrator. This command scopes the changeset to frontend component files and dispatches the `component-architecture-review` agent, then aggregates one report. It does not review files itself — it coordinates. `/code-review` dispatches the same agent automatically, but only when a frontend component file is newly *added* (`Scope: added-only`, #1733) — merely modifying an existing one does not trigger it there. This command scopes the agent to the frontend files you name (`--path`/`--since`/`--all`), regardless of whether any are newly added — use it for a diff that only modifies existing components, a standalone frontend-only pass (e.g. before extracting a component library), or to scope beyond a diff. `/repo-review` (#1735) covers the third, unconditional case: the whole component inventory, every pass, with no scoping flags at all. This command is executed under orchestrator direction. Dispatch the agent with its `model:`/`effort:` frontmatter as declared — the harness resolves both fields natively before dispatch, per Model/Effort Resolution in `agents/orchestrator.md` (ADR 0026). ## Orchestrator constraints 1. **Advisory only.** Aggregate findings and recommendations. Do not edit component code. Hand actionable fixes to `/apply-fixes` or `/build`. 2. **Scope to the frontend.** Only pass frontend component files to the agent; skip the run with a one-line note if none are in scope. 3. **No double-reporting.** This review owns component *reuse and composition*. Defer accessibility to `a11y-review`, framework reactivity to the framework-reactivity reviewers (`react-reactivity-review`/`vue-reactivity-review`/`angular-reactivity-review`), non-UI logic duplication and SRP/coupling to `structure-review`/`refactor-opportunity-review`, and naming to `naming-review`. When the same line belongs to one of those, drop it here. 4. **Be concise.** One aggregated report. Issue messages one sentence; recommendations map to a concrete next edit (extract X, lift Y to context). ## Parse Arguments Arguments: $ARGUMENTS Optional: - `--path <dir>`: target directory (default: current working directory) - `--since <ref>`: target files changed since a git ref (`git diff --name-only <ref>...HEAD`) - `--all`: review all frontend component files in the repository - `--json`: emit the agent's aggregated JSON instead of prose (for CI) ## Steps ### 1. Determine target files Same auto-scope logic as `/code-review`: review uncommitted changes if any exist, else the full repository; honor `--since`, `--path`, and `--all`. Then keep only frontend component files — `.jsx`, `.tsx`, `.vue`, `.svelte`, Angular `*.component.ts` and their templates, and `.js`/`.ts` modules that render UI. Exclude `node_modules`, `dist`, `build`, and test files. If no frontend component files are in scope, emit `No frontend component files in scope — nothing to review.` and stop. ### 2. Dispatch the review agent Spawn `component-architecture-review` as a sub-agent in a single batch, passing the in-scope files as full files (`Context needs: full-file`). It returns its standard JSON (`status`/`issues`/`summary`). If it skips, report that and stop. ### 3. Aggregate and rank Take the agent's issues. Rank: semantic UI duplication and prop-drilling that force multi-site edits first (`error`), then high-value extraction and granularity fixes (`warning`), then composition and API-consistency cleanups (`suggestion`). Group by file. Drop any finding that belongs to another agent per constraint 3. ### 4. Report If `--json`, emit the aggregated JSON object and stop. Otherwise produce one report (chat for a small target; `.dev-team-reports/frontend-architecture-<date>.md` for a module): ```markdown ## Frontend Architecture Review — <target> **Health**: <pass|attention|critical> **Component files**: N **Findings**: N ### Findings (by severity) | File:line | Issue | Severity | Suggested fix | ### Extraction & composition recommendations <reusable components to extract, prop-drilling to lift, APIs to align, missing or stale component-library `index` barrel to add — each with the concrete next edit> ### Next steps - Mechanical fixes (extract component, call existing primitive) → /apply-fixes - Larger refactors (lift state, recompose) → /plan or /build ``` Surface only what's actionable. If everything is clean, say so in one line.