aw-ecc 1.4.21 → 1.4.25

package/.cursor/rules/common-aw-routing.md

@@ -0,0 +1,43 @@
+---
+description: "AW global routing: use the AW router skill first, then apply org rules and references by domain"
+alwaysApply: true
+---
+# AW Global Routing
+
+- Before any substantive response, load `using-aw-skills` from `~/.cursor/skills/using-aw-skills/SKILL.md`.
+- Select the smallest correct AW route first:
+  - `/aw:plan`
+  - `/aw:build`
+  - `/aw:investigate`
+  - `/aw:test`
+  - `/aw:review`
+  - `/aw:deploy`
+  - `/aw:ship`
+- For non-trivial requests, the first substantive line should be `Selected AW Route: <route>`.
+- After the route is known, load the matching AW stage skill from `~/.cursor/skills/` and only the smallest supporting skills needed.
+
+## Org Rules
+
+- Always read:
+  - `~/.aw_rules/platform/universal/AGENTS.md`
+  - `~/.aw_rules/platform/security/AGENTS.md`
+- Then pick the smallest correct domain rule based on the requirement and current context, and read it before acting:
+  - `api-design` -> `~/.aw_rules/platform/api-design/AGENTS.md`
+  - `backend` -> `~/.aw_rules/platform/backend/AGENTS.md`
+  - `data` -> `~/.aw_rules/platform/data/AGENTS.md`
+  - `frontend` -> `~/.aw_rules/platform/frontend/AGENTS.md`
+  - `infra` -> `~/.aw_rules/platform/infra/AGENTS.md`
+  - `mobile` -> `~/.aw_rules/platform/mobile/AGENTS.md`
+  - `sdet` -> `~/.aw_rules/platform/sdet/AGENTS.md`
+- Load `references/` under the chosen domain on demand when implementation details or canonical links matter.
+- If repo-local instructions conflict with org-level AW rules, follow the org-level AW rules.
+
+## Route Hints
+
+- Ideas, architecture, specs, planning, new project setup, and database choice -> `/aw:plan`
+- Implementation, bug fixing, and build work -> `/aw:build`
+- Unclear failures, alerts, or root-cause hunting -> `/aw:investigate`
+- QA proof, regression evidence, and validation -> `/aw:test`
+- Findings, readiness, and approval decisions -> `/aw:review`
+- One release action -> `/aw:deploy`
+- Rollout, rollback readiness, and closeout -> `/aw:ship`

package/.cursor/skills/api-and-interface-design/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: api-and-interface-design
+description: Designs stable APIs and module boundaries. Use when changing public contracts, service interfaces, component props, or any boundary another system or team depends on.
+origin: ECC
+---
+
+# API and Interface Design
+
+## Overview
+
+Design interfaces that are stable, documented, and hard to misuse.
+This applies to REST and GraphQL APIs, TypeScript contracts, event payloads, component props, database-informed boundaries, and service-to-service interfaces.
+
+## When to Use
+
+- designing or changing API endpoints
+- defining interfaces between modules, services, or teams
+- shaping component props or shared library contracts
+- planning data contracts that other code depends on
+- changing existing public behavior that consumers may already rely on
+
+**When NOT to use**
+
+- the change is fully internal and does not cross a meaningful boundary
+- the work is purely implementation with no contract implications
+
+## Workflow
+
+1. Name the boundary and its consumers first.
+   Clarify who consumes the interface and what kind of compatibility risk exists:
+   user clients, internal services, frontend callers, workers, or shared packages.
+2. Define the contract before the implementation.
+   Write the request and response shape, error semantics, idempotency rules, and ordering guarantees before coding the handler.
+   Use `../../references/interface-stability.md` and `api-design` when the surface is HTTP-facing.
+3. Treat observable behavior as part of the contract.
+   Apply Hyrum's Law thinking:
+   if consumers can observe it, they may depend on it.
+   Avoid leaking implementation details, inconsistent error patterns, or unstable defaults.
+4. Validate at the boundary, not everywhere.
+   Validate user input, third-party responses, environment configuration, and external payloads where they enter the system.
+   Keep internal code paths simpler once the boundary is trusted.
+5. Prefer extension over breaking change.
+   Add optional fields, new endpoints, new event versions, or adapters before removing or changing existing semantics.
+   If a breaking change is unavoidable, load `deprecation-and-migration`.
+6. Record the long-lived design decision.
+   For important public or architectural contracts, update docs or ADRs through `documentation-and-adrs`.
+   In GHL- or AW-governed repos, align the contract with `.aw_rules`, platform APIs, and baseline expectations.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "We can document the contract later." | The contract is the design. If it is unclear now, implementation will drift. |
+| "Nobody depends on that behavior." | If it is observable, somebody eventually will. |
+| "We can just support two versions forever." | Version sprawl multiplies maintenance and creates dependency pain. |
+| "Validation everywhere is safer." | Boundary validation is safer and simpler than repeating checks throughout internal code. |
+
+## Red Flags
+
+- different endpoints or modules expose inconsistent error behavior
+- breaking changes are introduced without migration or compatibility planning
+- boundary validation is missing for user or third-party input
+- implementation details leak into public behavior or naming
+- the team cannot explain what part of the behavior is contract versus accident
+
+## Verification
+
+After designing or changing an interface, confirm:
+
+- [ ] the consumers and compatibility surface are explicit
+- [ ] the contract exists before or alongside implementation
+- [ ] error semantics and validation boundaries are consistent
+- [ ] additions were preferred over breaking changes where possible
+- [ ] deprecation or migration is planned for any unavoidable break
+- [ ] important interface decisions are documented for future engineers and agents

package/.cursor/skills/aw-brainstorm/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: aw-brainstorm
+description: Internal discovery helper that deepens pre-code exploration, compares approaches, and hands an approved direction to aw-plan without expanding the public command surface.
+trigger: Internal only. Invoked by aw-plan or aw-ship when discovery is still too fuzzy for direct planning.
+---
+
+# AW Brainstorm
+
+## Purpose
+
+`aw-brainstorm` is an internal depth skill.
+It should make the planning input sharper, not create a parallel public workflow or a second artifact system.
+
+The canonical public route for planning remains `/aw:plan`.
+
+## Hard Gate
+
+No implementation code may be written while discovery is still open.
+This skill stops at an approved direction and hands that direction to `aw-spec` through `aw-plan`.
+In other words, the public handoff is still: invoke `aw-plan`.
+
+## Discovery Loop
+
+Use this loop only when direct planning would otherwise guess:
+
+1. explore project context first:
+   - current files
+   - docs
+   - recent commits or adjacent artifacts when useful
+2. decide whether the request is actually one feature or multiple independent subsystems
+3. if the scope is too large for one spec, decompose it before detailed design work
+4. identify the unknowns, assumptions, and decision points
+5. ask at most one clarifying question at a time when a real decision is blocked
+6. propose 2-3 distinct approaches with trade-offs
+7. recommend one approach explicitly
+8. present the proposed direction in a way the user can approve or correct
+9. confirm the chosen direction or record the current best default
+10. run a quick self-review for placeholders, contradictions, ambiguity, and overscope
+11. hand the approved direction to `aw-spec` through `aw-plan`
+
+## Scope Check
+
+Before deepening the design, decide whether the request needs decomposition.
+
+If the request spans multiple independent subsystems, do not force one giant planning artifact.
+Break it into smaller spec-worthy scopes and continue with the smallest correct slice.
+If the request is too large for one spec, decompose it before moving on.
+
+## Design Expectations
+
+Discovery should be concrete enough that the next planning step does not need to rediscover the core shape of the work.
+
+Capture:
+
+- problem framing
+- purpose and success criteria
+- constraints
+- compared approaches
+- chosen approach with rationale
+- major risks
+- non-goals
+- the next planning artifact that should be written
+
+If the topic is visual and the active harness supports it, a browser-based visual companion may be offered as its own message before visual questions.
+
+## Required Output
+
+Produce a discovery summary that `aw-plan` and `aw-spec` can consume without redoing the ideation step.
+
+The summary should capture:
+
+- problem framing
+- assumptions and open questions
+- compared approaches
+- chosen approach with rationale
+- major risks
+- constraints and non-goals
+- what planning artifact should come next
+
+## Artifact Rule
+
+`aw-brainstorm` should not create a second planning file system or revive any legacy non-deterministic planning path.
+
+If it needs to persist discovery context, keep it inside:
+
+- `.aw_docs/features/<feature_slug>/state.json`
+
+or pass it directly into `aw-plan`.
+
+`aw-plan` remains responsible for canonical planning artifacts such as `prd.md`, `design.md`, `spec.md`, and `tasks.md`.
+
+## Platform Context
+
+| Domain Signal | Platform Skills to Load |
+|---|---|
+| API, controller, endpoint | `api-design`, `platform-services:development`, `platform-services:rate-limiting` |
+| Vue, component, UI | `platform-frontend:vue-development`, `platform-frontend:highrise-compliance`, `platform-design:system` |
+| Database, schema, collection | `platform-data:mongodb-patterns`, `platform-data:firestore-patterns` |
+| Auth, IAM, permissions | `platform-services:authentication-authorization` |
+| Deploy, k8s, helm | `platform-infra:kubernetes-workloads`, `platform-infra:jenkins-pipelines` |
+| Worker, queue, pub/sub | `platform-services:worker-patterns`, `platform-infra:pubsub-messaging` |
+| Multi-tenant, locationId | `platform-services:multi-tenancy` |
+
+## Anti-Patterns
+
+- jumping straight to code or implementation planning without resolving the real decision
+- batching many questions at once
+- presenting only one approach when meaningful alternatives exist
+- writing final planning artifacts directly instead of routing through `aw-plan`
+- reopening brainstorming after the direction is already clear
+- ignoring platform rules, repo context, or known constraints
+
+## Next Skill
+
+After the direction is approved, invoke `aw-plan`, which should then invoke `aw-spec`.

package/.cursor/skills/aw-build/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: aw-build
+description: Build approved work from `.aw_docs/features/<feature_slug>/` artifacts in thin, reversible increments with org-standard validation and handoff discipline.
+trigger: User requests implementation of approved work, or a compatible `/aw:execute` request needs to route to the canonical build stage.
+---
+
+# AW Build
+
+## Overview
+
+`aw-build` owns implementation only.
+It turns approved work into the smallest correct code, config, docs, or migration changes, continues through the full approved build scope in thin slices, and then hands off to test or review instead of self-certifying success.
+
+## When to Use
+
+- approved implementation artifacts already exist
+- the request is to code, configure, migrate, or document an approved change
+- a bug was already investigated and now needs a concrete fix
+- a legacy `/aw:execute` request arrives
+
+Do not use for vague ideation, unclear bugs, or release-only work.
+
+## Workflow
+
+1. Intake the approved inputs.
+   Load `spec.md`, `tasks.md`, and any relevant design or PRD context.
+   If the plan has a critical gap, route back to `aw-plan`.
+2. Select the smallest correct build mode.
+   Choose `code`, `infra`, `docs`, `migration`, or `config`.
+3. Resolve the execution topology before editing.
+   Default to sequential slice execution.
+   Use bounded parallel fan-out only when the approved plan marks disjoint `parallel_candidate` slices, names `parallel_group` and `parallel_write_scope`, and supplies or accepts the default `max_parallel_subagents: 3`.
+4. Slice the work before editing.
+   Use `../../references/build-increments.md` to keep changes thin, reversible, and rollback-friendly.
+   For multi-file or high-risk work, load `incremental-implementation`.
+5. Build one slice or one bounded parallel wave at a time.
+   For behavior changes, require RED-GREEN or a concrete failing signal.
+   Use `../../references/testing-patterns.md` when test structure needs support.
+6. Continue through the approved build scope.
+   Keep moving slice-to-slice until the approved implementation scope for this stage is complete or the next unsatisfied need is no longer build.
+   Do not stop after the first passing slice if more approved build slices remain.
+   Only pause early for an explicit blocker, a requested checkpoint, or a real approval boundary already present in the artifacts.
+7. Apply org standards during the slice.
+   Respect `.aw_rules`, relevant platform playbooks, and the resolved GHL baseline.
+   When context quality or scope focus is degrading, load `context-engineering`.
+   For frontend work, load `../../references/frontend-quality-checklist.md`.
+   For non-trivial UI work, load `frontend-ui-engineering`.
+   For interface changes, load `../../references/interface-stability.md` and `api-and-interface-design`.
+   For deprecation, removal, or migration slices, load `deprecation-and-migration`.
+8. Record evidence and boundaries.
+   Note what changed, what did not change, which slices or parallel waves are complete, which build slices still remain, and which checks were run.
+   When the approved tasks are grouped into phases, record phase transitions explicitly: which phase completed, which phase is now active, and what remains in later phases.
+   Use `../../references/git-save-points.md` when the work needs explicit save-point discipline.
+   For meaningful completed slices, create focused save-point commits.
+   For non-trivial commit boundaries, branch hygiene, or worktree isolation, load `git-workflow-and-versioning`.
+9. Hand off cleanly.
+   If build scope is complete, route to `aw-test` for QA proof or `aw-review` when the work needs findings, governance, or readiness decisions.
+   If the work is blocked mid-build, name the blocker, the last completed slice, and the smallest safe next action instead of stopping with a vague pause.
+
+## Completion Contract
+
+Build is complete only when one of these is true:
+
+- the approved implementation scope for the current stage is complete and written down
+- a blocker prevents the next approved build slice and that blocker is named explicitly
+
+A successful slice is a checkpoint, not an automatic terminal state.
+
+Every build handoff must make these things obvious:
+
+- what approved inputs were used
+- which phases were completed, if the approved plan used phases
+- which phase is current or next, if phased execution is still in flight
+- which slices were completed
+- whether work ran sequentially or in bounded parallel waves
+- which build slices remain, if any
+- which validation was run
+- which save-point commits were created
+- which exact next command should run next
+
+Meaningful completed build slices must create save-point commits in git-capable workspaces.
+If a slice cannot support a clean save-point commit, that is a planning problem and the slice should usually be merged with its dependent follow-up before build treats it as complete.
+Parallel build fan-out must stay within the planned `max_parallel_subagents` cap, which defaults to `3` when the plan does not justify another number.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "This is small enough to do in one big patch." | Small tasks still benefit from thin slices and explicit validation. |
+| "I'll add tests after the code is working." | If the behavior is testable, failure-first proof should lead the change. |
+| "Frontend changes don't need special handling." | Responsive behavior, accessibility, and design-system compliance are part of the work. |
+| "I can just clean up adjacent code too." | Scope creep makes rollback and review harder. |
+
+## Red Flags
+
+- a slice touches unrelated files
+- a passing slice is treated as stage completion even though planned build work remains
+- tests are hand-waved instead of run or explicitly declared unavailable
+- the diff is large enough that rollback is unclear
+- interface changes are made without boundary validation
+- bugfix code appears before the failing signal is concrete
+
+## State File
+
+`state.json` should record at least:
+
+- `feature_slug`
+- `stage: "build"`
+- `mode`
+- `status`
+- written artifacts
+- inputs used
+- files changed
+- `completed_phases` when the approved plan used phases
+- `current_phase` for the active or next build phase when phase sequencing exists
+- completed slices
+- remaining slices
+- parallel execution mode and cap when parallel build fan-out was used
+- validation commands
+- `save_point_commits`
+- blockers or concerns
+- recommended next commands
+
+## Verification
+
+Before leaving build, confirm:
+
+- [ ] the change came from approved inputs or a clearly approved direct technical request
+- [ ] the work was split into thin, reversible increments when non-trivial
+- [ ] behavior changes have failing-signal evidence or a clear explanation of why not
+- [ ] the approved build scope is either complete or blocked explicitly
+- [ ] relevant org standards, platform playbooks, and `.aw_rules` were applied
+- [ ] parallel execution, if used, stayed within the planned worker cap and disjoint write scopes
+- [ ] phased plans, if used, recorded phase completion plus the next phase transition
+- [ ] meaningful completed slices produced recorded save-point commits
+- [ ] `execution.md` and `state.json` are updated
+
+## Final Output Shape
+
+Always end with:
+
+- `Mode`
+- `Approved Inputs`
+- `Parallelization`
+- `Phase Progress`
+- `Completed Slices`
+- `Remaining Build Scope`
+- `Changes`
+- `Validation`
+- `Save Points`
+- `Blockers`
+- `Next`

package/.cursor/skills/aw-build/evals/build-stage-cases.json

@@ -0,0 +1,28 @@
+{
+  "cases": [
+    {
+      "id": "backend-approved-slice",
+      "request": "Implement the approved Communities moderation API change in thin slices.",
+      "buildMode": "code",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-services:development", "incremental-implementation"]
+    },
+    {
+      "id": "frontend-ui-slice",
+      "request": "Take the approved Communities feed MFA UI change forward and update the app accordingly.",
+      "buildMode": "code",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-frontend:vue-development", "highrise-ui-governance", "frontend-ui-engineering"]
+    },
+    {
+      "id": "migration-slice",
+      "request": "Apply the approved migration slice without widening scope.",
+      "buildMode": "migration",
+      "expectedFollowupStages": ["aw-test", "aw-review"],
+      "expectedArtifacts": ["execution.md", "state.json"],
+      "expectedSupportingSkills": ["platform-data:migration-patterns", "deprecation-and-migration"]
+    }
+  ]
+}

package/.cursor/skills/aw-debug/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: aw-debug
+description: Internal debugging helper that drives reproduction, root-cause isolation, confirming probes, and guarded repair.
+trigger: Internal only. Invoked by aw-investigate, aw-build, aw-test, or aw-review when failure remains uncertain.
+---
+
+# AW Debug
+
+## Overview
+
+`aw-debug` is the internal debugging playbook.
+It keeps bug work from devolving into guess-and-patch behavior.
+
+## When to Use
+
+- the failure is real but the cause is still uncertain
+- multiple fix attempts already happened
+- alerts or regressions need a concrete next probe
+
+## Workflow
+
+1. Capture a reproduction or equivalent failure signal.
+2. Define expected vs actual behavior.
+3. Identify the smallest plausible fault surface.
+4. Run the next confirming probe.
+5. Update the hypothesis based on evidence, not intuition.
+6. Only then hand back to investigation, build, test, or review.
+
+Use `../../references/debug-triage.md` for the stable checklist.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I already know the likely fix." | Likely is not confirmed. |
+| "Another patch is faster than another probe." | Repeated speculative fixes usually waste more time. |
+
+## Red Flags
+
+- third fix attempt without new evidence
+- patch size grows while root cause stays vague
+- reproduction disappears and the team starts guessing from memory
+
+## Verification
+
+- [ ] a reproduction or equivalent failure signal exists
+- [ ] expected vs actual behavior is explicit
+- [ ] the next probe or likely cause is evidence-backed
+- [ ] no speculative repair is treated as root-cause understanding

package/.cursor/skills/aw-deploy/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: aw-deploy
+description: Turn reviewed work into one requested release outcome with explicit GHL provider resolution and deterministic release artifacts.
+trigger: Test and review passed and the user requests PR creation, branch handoff, or deployment.
+---
+
+# AW Deploy
+
+## Overview
+
+`aw-deploy` owns release action only.
+It should not reopen planning or implementation.
+
+## When to Use
+
+- reviewed work needs a PR
+- reviewed work should remain on a branch
+- reviewed work should go to staging or production
+
+Do not use for launch discipline or end-to-end orchestration.
+
+## Workflow
+
+1. Confirm the evidence gate.
+   The required QA and review outputs must exist.
+2. Select one release path.
+   PR, branch, staging, or production.
+3. Resolve the org-standard mechanism.
+   Use the repo archetype and resolved baseline profile to choose provider and mechanism.
+   Load `ci-cd-and-automation` for gate ordering, preview/deploy automation, and rollback-aware pipeline expectations.
+   For releases that retire or migrate legacy paths, load `deprecation-and-migration`.
+4. Execute or record the blocker.
+   Complete the selected release action end-to-end for the chosen mode.
+   External failure should still yield deterministic `release.md` evidence.
+5. Hand off to `aw-ship` when requested.
+   Use `aw-ship` for rollout safety, rollback readiness, and closeout.
+
+## Completion Contract
+
+Deploy is complete only when one of these is true:
+
+- the selected release action finished and was recorded clearly
+- the release action is blocked and the blocker is recorded clearly
+
+Every deploy handoff must make these things obvious:
+
+- which release mode was selected
+- which provider and mechanism were resolved
+- what evidence or links were produced
+- what rollback path is currently known
+- which exact next command should run next
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Deploy can also handle launch closeout." | Release action and launch discipline are related but distinct. |
+| "I'll just guess the staging mechanism." | Unknown deployment config must fail closed. |
+
+## Red Flags
+
+- deploy runs without clear test and review evidence
+- provider or mechanism is guessed
+- deploy silently turns into release orchestration
+
+## State File
+
+`state.json` should record at least:
+
+- `feature_slug`
+- `stage: "deploy"`
+- `mode`
+- `status`
+- written artifacts
+- provider
+- resolved mechanism
+- build or release links
+- execution evidence
+- rollback path
+- blockers
+- recommended next commands
+
+## Verification
+
+- [ ] one release action was selected explicitly
+- [ ] provider and mechanism came from repo archetype and baseline resolution
+- [ ] `release.md` and `state.json` are updated
+- [ ] handoff to `aw-ship` is clear when launch discipline is still needed
+
+## Final Output Shape
+
+Always end with:
+
+- `Selected Mode`
+- `Provider`
+- `Resolved Mechanism`
+- `Build Links`
+- `Execution Evidence`
+- `Rollback Path`
+- `Outcome`
+- `Next`

package/.cursor/skills/aw-deploy/evals/deploy-stage-cases.json

@@ -0,0 +1,32 @@
+{
+  "cases": [
+    {
+      "id": "pr-creation",
+      "request": "Create a PR for this reviewed work.",
+      "releasePath": "pr",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["ci-cd-and-automation"]
+    },
+    {
+      "id": "service-staging",
+      "request": "Deploy this verified Communities moderation API service to staging.",
+      "releasePath": "staging",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["platform-infra:staging-deploy", "platform-infra:deployment-strategies", "platform-infra:production-readiness"]
+    },
+    {
+      "id": "mfa-staging",
+      "request": "Deploy this verified Communities feed MFA to staging.",
+      "releasePath": "staging",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["deploy-versioned-mfa", "platform-infra:staging-deploy", "platform-infra:production-readiness"]
+    },
+    {
+      "id": "release-automation",
+      "request": "Set up the release automation, preview gates, and rollback path for this service deployment.",
+      "releasePath": "deployment-automation",
+      "expectedArtifacts": ["release.md", "state.json"],
+      "expectedSupportingSkills": ["ci-cd-and-automation"]
+    }
+  ]
+}

package/.cursor/skills/aw-execute/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: aw-execute
+description: Compatibility skill for the older execute stage. Follow aw-build as the canonical implementation behavior.
+trigger: Internal compatibility only. Invoked when older docs, habits, or commands still reference aw-execute.
+---
+
+# AW Execute
+
+## Overview
+
+`aw-execute` is a compatibility layer.
+The canonical implementation stage is now `aw-build`.
+
+## When to Use
+
+- a legacy `/aw:execute` request arrives
+- an older doc or test still refers to execute semantics
+
+Do not create a separate execute-specific workflow.
+
+## Workflow
+
+1. Route to `aw-build`.
+2. Preserve the same artifact discipline:
+   - `execution.md`
+   - `state.json`
+3. Preserve the same continuation and downstream handoff:
+   - complete the current build scope or block it explicitly
+   - `aw-test`
+   - `aw-review`
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Execute can stay different from build for now." | Dual semantics create drift and confusion. |
+
+## Red Flags
+
+- execute-specific behavior diverges from build
+- old naming is used to bypass the new stage model
+
+## Verification
+
+- [ ] the request was routed to `aw-build`
+- [ ] the current build scope was completed or blocked explicitly
+- [ ] artifact and handoff behavior stayed consistent with the canonical build stage