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):

## 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.