aw-ecc 1.4.31 → 1.4.47

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

@@ -1,152 +0,0 @@
----
-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

@@ -1,28 +0,0 @@
-{
-  "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

@@ -1,49 +0,0 @@
----
-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

@@ -1,101 +0,0 @@
----
-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

@@ -1,32 +0,0 @@
-{
-  "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

@@ -1,47 +0,0 @@
----
-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

package/.cursor/skills/aw-execute/references/mode-code.md

@@ -1,47 +0,0 @@
-# Mode: Code — TDD Execution
-
-## Iron Law
-
-> **Every [code] task follows TDD. No exceptions. No rationalizations.**
-
-## Red-Green-Refactor Cycle
-
-### 1. RED — Write the test first
-
-- Write a failing test that describes the expected behavior.
-- Run the test. It MUST fail. If it passes, the test is wrong or the behavior already exists.
-- The test defines the contract. Implementation serves the test.
-
-### 2. GREEN — Write minimal code to pass
-
-- Write the simplest implementation that makes the test pass.
-- Do not add features, optimizations, or "nice-to-haves" at this stage.
-- Run the test. It MUST pass.
-
-### 3. REFACTOR — Clean up without changing behavior
-
-- Extract helpers, rename variables, reduce duplication.
-- Run tests after every refactor step. They MUST still pass.
-- Stop refactoring when the code is clean and readable.
-
-## Rules
-
-- **Test file per source file** — `feature.service.ts` gets `feature.service.spec.ts`.
-- **Descriptive test names** — `it('should return empty array when no features exist for locationId')`.
-- **No mocking internals** — Mock boundaries (HTTP, database, external services), not internal functions.
-- **Coverage gate** — 80% minimum. Check with `npm run test:cov` or equivalent.
-- **No skipped tests** — `it.skip` and `xit` are not allowed in committed code.
-- **Platform logger** — Use `@platform-core/logger`, never `console.*`.
-- **DTO validation** — Every `@Body()` parameter has a class-validator DTO.
-- **Error handling** — Every async call has explicit error handling.
-
-## Rationalization Table
-
-| Rationalization | Why It Is Wrong |
-|---|---|
-| "I'll write tests after" | You will not. And the code will be shaped for implementation, not testability. |
-| "This is too simple to test" | Simple code breaks too. The test documents the contract. |
-| "Tests slow me down" | Tests slow you down now. Bugs slow you down forever. |
-| "I'll just test the happy path" | Errors happen on unhappy paths. Test both. |
-| "The integration test covers it" | Integration tests are slow and broad. Unit tests are fast and precise. |
-| "I know this works" | Prove it. Run the test. |

package/.cursor/skills/aw-execute/references/mode-docs.md

@@ -1,28 +0,0 @@
-# Mode: Docs — Write, Review, Commit
-
-## Process
-
-### 1. Write
-
-- Write the documentation in the appropriate location.
-- Follow existing documentation style and format in the repo.
-- Include code examples where they aid understanding.
-- Keep language clear, concise, and direct.
-
-### 2. Self-Review Checklist
-
-Before committing documentation:
-
-- [ ] **Accuracy** — All technical details are correct and verified against the code.
-- [ ] **Completeness** — All public APIs, config options, and workflows are documented.
-- [ ] **Examples** — Code examples compile/run and match current API signatures.
-- [ ] **Links** — All internal links resolve. No broken references.
-- [ ] **Formatting** — Consistent heading levels, code block languages, and list styles.
-- [ ] **No stale content** — Removed or updated references to deprecated features.
-- [ ] **Audience** — Written for the target reader (developer, operator, end user).
-
-### 3. Commit
-
-- Commit documentation changes with `docs:` prefix.
-- If docs accompany code changes, include in the same PR.
-- Update the table of contents or index if one exists.

package/.cursor/skills/aw-execute/references/mode-infra.md

@@ -1,44 +0,0 @@
-# Mode: Infra — Dry-Run First
-
-## Core Principle
-
-> **Never apply infrastructure changes directly. Validate first, deploy via Jenkins.**
-
-## Process
-
-### 1. Validate
-
-- Run `helm lint` for Helm chart changes.
-- Run `terraform plan` for Terraform changes.
-- Run `docker build` to verify Dockerfile changes.
-- Review the diff carefully before proceeding.
-
-### 2. Dry-Run
-
-- `terraform plan -out=tfplan` — Review every resource change.
-- `helm template` — Render and inspect the full manifest.
-- `helm diff upgrade` — Compare current state with proposed changes.
-
-### 3. Deploy via Jenkins
-
-- **Never** run `kubectl apply`, `helm install`, or `terraform apply` directly.
-- Use Jenkins shared library functions for all deployments.
-- Trigger deployments via Jenkins pipeline, not CLI.
-
-### 4. Verify
-
-- Check pod status after deployment.
-- Verify health probes are responding.
-- Check logs for startup errors.
-- Confirm the change is reflected in the running system.
-
-## Platform Rules
-
-- **Resource requests** — Set `resources.requests` for every container. Limits auto-calculated for servers.
-- **Health probes** — Configure for every deployment (default path `/` on port 6050).
-- **No CPU limits = requests** — Never set CPU limits equal to CPU requests (causes throttling).
-- **No secrets in Helm** — Use GCP Secret Manager, not Helm values or ConfigMaps.
-- **No KEDA** — KEDA is deprecated. Use `peakLoad.peakLoadMinReplicas` instead.
-- **Pin image tags** — Never use `latest`. Use specific digest or semver.
-- **Graceful shutdown** — `terminationGracePeriodSeconds` >= 30 seconds.
-- **Terraform managed** — All GCP resources via Terraform. No manual console changes.

package/.cursor/skills/aw-execute/references/mode-migration.md

@@ -1,58 +0,0 @@
-# Mode: Migration — Staged Rollout
-
-## Process
-
-### 1. Script
-
-- Write the migration script. It MUST be **idempotent** — running it twice produces the same result.
-- Use `up()` and `down()` functions (or equivalent) for forward and rollback.
-- Include validation checks that confirm the migration was applied correctly.
-- Test the migration against a copy of production data (or realistic test data).
-
-### 2. Rollback
-
-- Every migration MUST have a rollback path.
-- Write the rollback script before applying the migration.
-- Test the rollback independently.
-- Document the rollback procedure in the migration file header.
-
-### 3. Validate
-
-- Run the migration in a test/staging environment first.
-- Verify data integrity after migration.
-- Check that dependent queries still work with the new schema.
-- Confirm indexes are in place before queries execute.
-
-### 4. Commit
-
-- Commit migration files with `migration:` or `feat:` prefix.
-- Include the rollback script in the same commit.
-- Document the migration in the PR description.
-
-## Rules
-
-### Indexes
-
-- **Deploy indexes BEFORE** deploying schema or query changes that use them.
-- Use `background: true` for index creation (or rely on MongoDB 4.2+ default).
-- Add compound indexes for multi-field queries — avoid multiple single-field indexes.
-- Scope all MongoDB queries by `locationId` (compound index required).
-
-### Fields
-
-- New fields MUST have default values or be nullable — never break existing documents.
-- Remove fields in two phases: (1) stop writing, (2) remove after migration window.
-- Never rename fields in a single migration — add new, migrate data, remove old.
-
-### Secrets
-
-- Never store secrets in migration scripts.
-- Use environment variables or GCP Secret Manager for connection strings.
-- Never log sensitive data during migration (PII, credentials, tokens).
-
-### Data Safety
-
-- Back up the collection/table before running destructive migrations.
-- Use transactions where available for multi-document updates.
-- Set reasonable batch sizes for bulk operations — avoid OOM.
-- Log progress for long-running migrations (every N records).

package/.cursor/skills/aw-execute/references/worker-implementer.md

@@ -1,26 +0,0 @@
-# Worker Role: Implementer
-
-## Objective
-
-Own one bounded task unit from the approved AW execution inputs.
-Change only the smallest correct file set for that unit.
-
-## Inputs
-
-- approved feature inputs from `.aw_docs/features/<feature_slug>/`
-- current task-unit bundle
-- repo-local AW execution contract
-
-## Required Behavior
-
-1. confirm the task-unit goal and file scope
-2. capture the RED or failure-first signal when behavior changes
-3. implement the smallest correct GREEN change
-4. record handoff notes for spec and quality review
-5. stop when the task unit is complete or blocked
-
-## Hard Gates
-
-- do not widen the write scope without naming why
-- do not skip runnable tests silently
-- do not mark the task done without concrete notes for the next review roles

package/.cursor/skills/aw-execute/references/worker-parallel-worker.md

@@ -1,23 +0,0 @@
-# Worker Role: Parallel Worker
-
-## Objective
-
-Execute one task unit that has already been marked `parallel_candidate` with a disjoint write scope.
-The orchestrator should keep active parallel workers within the configured cap, which defaults to `3`.
-
-## Inputs
-
-- current task-unit bundle
-- declared disjoint write scope
-- repo-local AW execution contract
-
-## Required Behavior
-
-1. stay inside the declared write scope
-2. keep notes concise so the merge-back step can reconcile outputs cleanly
-3. stop immediately if the work crosses into another worker's files
-
-## Hard Gates
-
-- do not edit shared files outside the declared scope
-- do not claim a task unit is parallel-safe if overlap was discovered during execution

package/.cursor/skills/aw-execute/references/worker-quality-reviewer.md

@@ -1,23 +0,0 @@
-# Worker Role: Quality Reviewer
-
-## Objective
-
-Check maintainability, reliability, and stage readiness for one completed task unit.
-
-## Inputs
-
-- implementer handoff notes
-- spec review outcome
-- current task-unit bundle
-
-## Required Behavior
-
-1. inspect the changed files and local validation notes
-2. flag maintainability or reliability issues that would block handoff
-3. state `pass`, `pass_with_notes`, or `fail`
-4. hand back the smallest concrete repair scope when failing
-
-## Hard Gates
-
-- do not reopen planning
-- do not wave through unresolved reliability or validation gaps