build-loop

Review the cross-repo proposal backlog interactively. Scans every registered repo's .build-loop/proposals/ (incl. enforce-from-retro/ + self-review) plus ~/.assistant/proposals/, then walks each new item to apply / reject / defer. Never auto-applies.

The one build-loop command. Describe anything in plain language — build, fix, debug, optimize, research, test, root-cause, retrospective, plan, PRD — and it routes automatically. You never pick a mode.

The Frontier (Fable) standing role that AUTHORS and RE-PLANS the Phase 2 plan synthesis. Generating a plan is harder than evaluating one, so the deepest reasoning pays here. The Advisor frames the goal, decomposes the work, builds the dependency graph, MECE-partitions file ownership, and — on a diagnosed *planning miss* — re-plans and issues CORRECTED INSTRUCTIONS (a diff vs the prior plan + the failure evidence), not just a "no". Its output is still verified by the existing Frontier critics (plan-critic, scope-auditor); the Advisor never self-certifies. v1 scope is Phase 2 plan synthesis only — the take-over-execution rung (executing a chunk directly) is v2. <example> Context: Phase 2 of a high-stakes build (riskSurfaceChange + synthesisDensity 7). The orchestrator wants the plan authored at Frontier, not inline on Opus. user: "Author the Phase 2 plan for the auth-refactor build at frontier tier" assistant: "Dispatching the advisor agent. It reads intent.md + goal.md + the architecture baseline, walks the spec-writing checklist, and writes the plan to docs/plans/. plan-critic + scope-auditor then verify it before any implementer runs." </example> <example> Context: Iterate attempt 3 — the same chunk keeps failing and the failure evidence points at the plan itself (wrong decomposition), not a hard execution task. user: "The plan no longer fits — re-plan chunk 4 with the failure evidence" assistant: "Dispatching the advisor agent in re-plan mode. It reads the failure evidence + the diff vs the current plan, diagnoses planning-miss vs execution-miss, and (on planning-miss) emits corrected instructions: a diff against the prior plan plus the evidence that justifies the change." </example>

Advisory alignment judge for autonomous-iterate-loop queue items (plan §14.4 A). For each candidate item drained from `.build-loop/ux-queue/` + `.build-loop/issues/` + `.build-loop/proposals/`, reads the build's stated intent (`intent.md`, `goal.md`, canonical build-loop-memory constitution context, optional repo `.build-loop/prd.md`) plus the item body and returns a structured verdict (`aligned | misaligned | uncertain`) with cited anchors. Never blocks: the orchestrator routes verdicts (aligned → Phase 2, misaligned → `followup/`, uncertain → notify + continue). High-frequency call — once per queue item — so this agent is Sonnet, not Opus. <example> Context: Autonomous loop has just drained a fresh ux-queue/uxq-0042.md from Phase 4 Gate 7. About to decide whether to schedule it for Phase 2. user: "Run alignment-checker on uxq-0042" assistant: "I'll dispatch alignment-checker with the queue item body + the intent/goal/constitution anchors. Verdict + matched_anchors + violated_non_goals returned as JSON; orchestrator routes from there." </example> <example> Context: A `.build-loop/proposals/swap-router.md` proposal landed mid-run suggesting a wholesale architecture change that contradicts intent.md's "incremental migration only" non-goal. user: "Should we execute swap-router?" assistant: "alignment-checker reads intent.md non-goals, matches 'incremental migration only' against the proposal's 'wholesale rewrite' framing, returns verdict: misaligned with violated_non_goals populated. Orchestrator moves it to followup/." </example>

Use this agent when the debugging symptom involves API endpoints, REST/GraphQL errors, request/response issues, authentication, rate limiting, or server-side route handlers. Examples - "500 error", "endpoint not found", "auth failed", "CORS error".

Read-only architecture analyst. Dispatched by build-loop orchestrator with a task type ('baseline', 'chunk-impact', 'review-rules', 'iterate-subgraph', 'learn-sync'). Decides native engine vs NavGator escalation per task. Returns ≤500-word structured JSON envelope. Owns architecture-related side effects (violation capture, lessons sync).

Use this agent when debugging requires multi-domain analysis, when the symptom is unclear about which domain is affected, or when you need to coordinate parallel assessments across database, frontend, API, and performance domains.

Use when coordinating build-loop with peer coding agents, checking Rally Point presence/inbox state, posting handoffs or feedback, validating the embedded Rally Point boundary, or changing the future agent-rally-point spin-out surface.

Use when listening for Rally Point changes, wiring coordination watchers, debugging watch-loop behavior, or changing the future agent-rally-watcher spin-out surface.

Use when Phase 1 Assess or Phase 5 Iterate detects a new API dependency, API config fails, or the user asks to "register this API" or "check the API registry". Consults api-registry plugin; degrades gracefully if plugin is absent. NOT for PRD strategic grounding (use `prd-bridge`) or UI verification (use `ibr-bridge`).

Apply the canonical four-layer Apache-2.0 attribution model (NOTICE, per-file SPDX, REUSE.toml, canary markers) to a repo. Triggers on 'stamp attribution', 'add NOTICE', 'license headers', 'attribution layers', a newly public repo, or a repo with .git but no NOTICE / no REUSE.toml / no CONTRIBUTING.md. Build-loop Phase 1 Assess can advise running this when shipped source files lack SPDX headers.

Use when wiring auth to a new project, debugging login errors (redirect_uri_mismatch, invalid_grant, session callback, refresh_token), or adding social/magic link flows. Covers Better Auth (Drizzle/Neon), Supabase Auth (SSR), Google OAuth, and Resend transactional email.

28 hooks across 6 events