aw-ecc 1.4.32 → 1.4.48

package/.codex/hooks.json

@@ -1,62 +0,0 @@
-{
-  "hooks": {
-    "SessionStart": [
-      {
-        "matcher": "*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash -lc 'bash \"$HOME/.codex/hooks/aw-session-start.sh\"'"
-          }
-        ],
-        "description": "Load AW routing context at session start"
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash -lc 'bash \"$HOME/.codex/hooks/aw-user-prompt-submit.sh\"'"
-          }
-        ],
-        "description": "Inject compact AW routing and rule reminders on each prompt"
-      }
-    ],
-    "PreToolUse": [
-      {
-        "matcher": "*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash -lc 'bash \"$HOME/.codex/hooks/aw-pre-tool-use.sh\"'"
-          }
-        ],
-        "description": "Reserved AW pre-tool-use phase for Codex home installs"
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash -lc 'bash \"$HOME/.codex/hooks/aw-post-tool-use.sh\"'"
-          }
-        ],
-        "description": "Reserved AW post-tool-use phase for Codex home installs"
-      }
-    ],
-    "Stop": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash -lc 'bash \"$HOME/.codex/hooks/aw-stop.sh\"'"
-          }
-        ],
-        "description": "Reserved AW stop phase for Codex home installs"
-      }
-    ]
-  }
-}

package/.cursor/rules/common-agents.md

@@ -1,53 +0,0 @@
----
-description: "Agent orchestration: available agents, parallel execution, multi-perspective analysis"
-alwaysApply: true
----
-# Agent Orchestration
-
-## Available Agents
-
-Located in `~/.claude/agents/`:
-
-| Agent | Purpose | When to Use |
-|-------|---------|-------------|
-| planner | Implementation planning | Complex features, refactoring |
-| architect | System design | Architectural decisions |
-| tdd-guide | Test-driven development | New features, bug fixes |
-| code-reviewer | Code review | After writing code |
-| security-reviewer | Security analysis | Before commits |
-| build-error-resolver | Fix build errors | When build fails |
-| e2e-runner | E2E testing | Critical user flows |
-| refactor-cleaner | Dead code cleanup | Code maintenance |
-| doc-updater | Documentation | Updating docs |
-
-## Immediate Agent Usage
-
-No user prompt needed:
-1. Complex feature requests - Use **planner** agent
-2. Code just written/modified - Use **code-reviewer** agent
-3. Bug fix or new feature - Use **tdd-guide** agent
-4. Architectural decision - Use **architect** agent
-
-## Parallel Task Execution
-
-ALWAYS use parallel Task execution for independent operations:
-
-```markdown
-# GOOD: Parallel execution
-Launch 3 agents in parallel:
-1. Agent 1: Security analysis of auth module
-2. Agent 2: Performance review of cache system
-3. Agent 3: Type checking of utilities
-
-# BAD: Sequential when unnecessary
-First agent 1, then agent 2, then agent 3
-```
-
-## Multi-Perspective Analysis
-
-For complex problems, use split role sub-agents:
-- Factual reviewer
-- Senior engineer
-- Security expert
-- Consistency reviewer
-- Redundancy checker

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

@@ -1,43 +0,0 @@
----
-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/rules/common-coding-style.md

@@ -1,52 +0,0 @@
----
-description: "ECC coding style: immutability, file organization, error handling, validation"
-alwaysApply: true
----
-# Coding Style
-
-## Immutability (CRITICAL)
-
-ALWAYS create new objects, NEVER mutate existing ones:
-
-```
-// Pseudocode
-WRONG:  modify(original, field, value) → changes original in-place
-CORRECT: update(original, field, value) → returns new copy with change
-```
-
-Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
-
-## File Organization
-
-MANY SMALL FILES > FEW LARGE FILES:
-- High cohesion, low coupling
-- 200-400 lines typical, 800 max
-- Extract utilities from large modules
-- Organize by feature/domain, not by type
-
-## Error Handling
-
-ALWAYS handle errors comprehensively:
-- Handle errors explicitly at every level
-- Provide user-friendly error messages in UI-facing code
-- Log detailed error context on the server side
-- Never silently swallow errors
-
-## Input Validation
-
-ALWAYS validate at system boundaries:
-- Validate all user input before processing
-- Use schema-based validation where available
-- Fail fast with clear error messages
-- Never trust external data (API responses, user input, file content)
-
-## Code Quality Checklist
-
-Before marking work complete:
-- [ ] Code is readable and well-named
-- [ ] Functions are small (<50 lines)
-- [ ] Files are focused (<800 lines)
-- [ ] No deep nesting (>4 levels)
-- [ ] Proper error handling
-- [ ] No hardcoded values (use constants or config)
-- [ ] No mutation (immutable patterns used)

package/.cursor/rules/common-development-workflow.md

@@ -1,33 +0,0 @@
----
-description: "Development workflow: plan, TDD, review, commit pipeline"
-alwaysApply: true
----
-# Development Workflow
-
-> This rule extends the git workflow rule with the full feature development process that happens before git operations.
-
-The Feature Implementation Workflow describes the development pipeline: planning, TDD, code review, and then committing to git.
-
-## Feature Implementation Workflow
-
-1. **Plan First**
-   - Use **planner** agent to create implementation plan
-   - Identify dependencies and risks
-   - Break down into phases
-
-2. **TDD Approach**
-   - Use **tdd-guide** agent
-   - Write tests first (RED)
-   - Implement to pass tests (GREEN)
-   - Refactor (IMPROVE)
-   - Verify 80%+ coverage
-
-3. **Code Review**
-   - Use **code-reviewer** agent immediately after writing code
-   - Address CRITICAL and HIGH issues
-   - Fix MEDIUM issues when possible
-
-4. **Commit & Push**
-   - Detailed commit messages
-   - Follow conventional commits format
-   - See the git workflow rule for commit message format and PR process

package/.cursor/rules/common-git-workflow.md

@@ -1,28 +0,0 @@
----
-description: "Git workflow: conventional commits, PR process"
-alwaysApply: true
----
-# Git Workflow
-
-## Commit Message Format
-```
-<type>: <description>
-
-<optional body>
-```
-
-Types: feat, fix, refactor, docs, test, chore, perf, ci
-
-Note: Attribution disabled globally via ~/.claude/settings.json.
-
-## Pull Request Workflow
-
-When creating PRs:
-1. Analyze full commit history (not just latest commit)
-2. Use `git diff [base-branch]...HEAD` to see all changes
-3. Draft comprehensive PR summary
-4. Include test plan with TODOs
-5. Push with `-u` flag if new branch
-
-> For the full development process (planning, TDD, code review) before git operations,
-> see the development workflow rule.

package/.cursor/rules/common-hooks.md

@@ -1,34 +0,0 @@
----
-description: "Hooks system: types, auto-accept permissions, TodoWrite best practices"
-alwaysApply: true
----
-# Hooks System
-
-## Hook Types
-
-- **PreToolUse**: Before tool execution (validation, parameter modification)
-- **PostToolUse**: After tool execution (auto-format, checks)
-- **Stop**: When session ends (final verification)
-
-## Auto-Accept Permissions
-
-Use with caution:
-- Enable for trusted, well-defined plans
-- Disable for exploratory work
-- Never use dangerously-skip-permissions flag
-- Configure `allowedTools` in `~/.claude.json` instead
-
-## TodoWrite Best Practices
-
-Use TodoWrite tool to:
-- Track progress on multi-step tasks
-- Verify understanding of instructions
-- Enable real-time steering
-- Show granular implementation steps
-
-Todo list reveals:
-- Out of order steps
-- Missing items
-- Extra unnecessary items
-- Wrong granularity
-- Misinterpreted requirements

package/.cursor/rules/common-patterns.md

@@ -1,35 +0,0 @@
----
-description: "Common patterns: repository, API response, skeleton projects"
-alwaysApply: true
----
-# Common Patterns
-
-## Skeleton Projects
-
-When implementing new functionality:
-1. Search for battle-tested skeleton projects
-2. Use parallel agents to evaluate options:
-   - Security assessment
-   - Extensibility analysis
-   - Relevance scoring
-   - Implementation planning
-3. Clone best match as foundation
-4. Iterate within proven structure
-
-## Design Patterns
-
-### Repository Pattern
-
-Encapsulate data access behind a consistent interface:
-- Define standard operations: findAll, findById, create, update, delete
-- Concrete implementations handle storage details (database, API, file, etc.)
-- Business logic depends on the abstract interface, not the storage mechanism
-- Enables easy swapping of data sources and simplifies testing with mocks
-
-### API Response Format
-
-Use a consistent envelope for all API responses:
-- Include a success/status indicator
-- Include the data payload (nullable on error)
-- Include an error message field (nullable on success)
-- Include metadata for paginated responses (total, page, limit)

package/.cursor/rules/common-performance.md

@@ -1,59 +0,0 @@
----
-description: "Performance: model selection, context management, build troubleshooting"
-alwaysApply: true
----
-# Performance Optimization
-
-## Model Selection Strategy
-
-**Haiku 4.5** (90% of Sonnet capability, 3x cost savings):
-- Lightweight agents with frequent invocation
-- Pair programming and code generation
-- Worker agents in multi-agent systems
-
-**Sonnet 4.6** (Best coding model):
-- Main development work
-- Orchestrating multi-agent workflows
-- Complex coding tasks
-
-**Opus 4.5** (Deepest reasoning):
-- Complex architectural decisions
-- Maximum reasoning requirements
-- Research and analysis tasks
-
-## Context Window Management
-
-Avoid last 20% of context window for:
-- Large-scale refactoring
-- Feature implementation spanning multiple files
-- Debugging complex interactions
-
-Lower context sensitivity tasks:
-- Single-file edits
-- Independent utility creation
-- Documentation updates
-- Simple bug fixes
-
-## Extended Thinking + Plan Mode
-
-Extended thinking is enabled by default, reserving up to 31,999 tokens for internal reasoning.
-
-Control extended thinking via:
-- **Toggle**: Option+T (macOS) / Alt+T (Windows/Linux)
-- **Config**: Set `alwaysThinkingEnabled` in `~/.claude/settings.json`
-- **Budget cap**: `export MAX_THINKING_TOKENS=10000`
-- **Verbose mode**: Ctrl+O to see thinking output
-
-For complex tasks requiring deep reasoning:
-1. Ensure extended thinking is enabled (on by default)
-2. Enable **Plan Mode** for structured approach
-3. Use multiple critique rounds for thorough analysis
-4. Use split role sub-agents for diverse perspectives
-
-## Build Troubleshooting
-
-If build fails:
-1. Use **build-error-resolver** agent
-2. Analyze error messages
-3. Fix incrementally
-4. Verify after each fix

package/.cursor/rules/common-security.md

@@ -1,33 +0,0 @@
----
-description: "Security: mandatory checks, secret management, response protocol"
-alwaysApply: true
----
-# Security Guidelines
-
-## Mandatory Security Checks
-
-Before ANY commit:
-- [ ] No hardcoded secrets (API keys, passwords, tokens)
-- [ ] All user inputs validated
-- [ ] SQL injection prevention (parameterized queries)
-- [ ] XSS prevention (sanitized HTML)
-- [ ] CSRF protection enabled
-- [ ] Authentication/authorization verified
-- [ ] Rate limiting on all endpoints
-- [ ] Error messages don't leak sensitive data
-
-## Secret Management
-
-- NEVER hardcode secrets in source code
-- ALWAYS use environment variables or a secret manager
-- Validate that required secrets are present at startup
-- Rotate any secrets that may have been exposed
-
-## Security Response Protocol
-
-If security issue found:
-1. STOP immediately
-2. Use **security-reviewer** agent
-3. Fix CRITICAL issues before continuing
-4. Rotate any exposed secrets
-5. Review entire codebase for similar issues

package/.cursor/rules/common-testing.md

@@ -1,33 +0,0 @@
----
-description: "Testing requirements: 80% coverage, TDD workflow, test types"
-alwaysApply: true
----
-# Testing Requirements
-
-## Minimum Test Coverage: 80%
-
-Test Types (ALL required):
-1. **Unit Tests** - Individual functions, utilities, components
-2. **Integration Tests** - API endpoints, database operations
-3. **E2E Tests** - Critical user flows (framework chosen per language)
-
-## Test-Driven Development
-
-MANDATORY workflow:
-1. Write test first (RED)
-2. Run test - it should FAIL
-3. Write minimal implementation (GREEN)
-4. Run test - it should PASS
-5. Refactor (IMPROVE)
-6. Verify coverage (80%+)
-
-## Troubleshooting Test Failures
-
-1. Use **tdd-guide** agent
-2. Check test isolation
-3. Verify mocks are correct
-4. Fix implementation, not tests (unless tests are wrong)
-
-## Agent Support
-
-- **tdd-guide** - Use PROACTIVELY for new features, enforces write-tests-first

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

@@ -1,75 +0,0 @@
----
-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/article-writing/SKILL.md

@@ -1,85 +0,0 @@
----
-name: article-writing
-description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
-origin: ECC
----
-
-# Article Writing
-
-Write long-form content that sounds like a real person or brand, not generic AI output.
-
-## When to Activate
-
-- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
-- turning notes, transcripts, or research into polished articles
-- matching an existing founder, operator, or brand voice from examples
-- tightening structure, pacing, and evidence in already-written long-form copy
-
-## Core Rules
-
-1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
-2. Explain after the example, not before.
-3. Prefer short, direct sentences over padded ones.
-4. Use specific numbers when available and sourced.
-5. Never invent biographical facts, company metrics, or customer evidence.
-
-## Voice Capture Workflow
-
-If the user wants a specific voice, collect one or more of:
-- published articles
-- newsletters
-- X / LinkedIn posts
-- docs or memos
-- a short style guide
-
-Then extract:
-- sentence length and rhythm
-- whether the voice is formal, conversational, or sharp
-- favored rhetorical devices such as parentheses, lists, fragments, or questions
-- tolerance for humor, opinion, and contrarian framing
-- formatting habits such as headers, bullets, code blocks, and pull quotes
-
-If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
-
-## Banned Patterns
-
-Delete and rewrite any of these:
-- generic openings like "In today's rapidly evolving landscape"
-- filler transitions such as "Moreover" and "Furthermore"
-- hype phrases like "game-changer", "cutting-edge", or "revolutionary"
-- vague claims without evidence
-- biography or credibility claims not backed by provided context
-
-## Writing Process
-
-1. Clarify the audience and purpose.
-2. Build a skeletal outline with one purpose per section.
-3. Start each section with evidence, example, or scene.
-4. Expand only where the next sentence earns its place.
-5. Remove anything that sounds templated or self-congratulatory.
-
-## Structure Guidance
-
-### Technical Guides
-- open with what the reader gets
-- use code or terminal examples in every major section
-- end with concrete takeaways, not a soft summary
-
-### Essays / Opinion Pieces
-- start with tension, contradiction, or a sharp observation
-- keep one argument thread per section
-- use examples that earn the opinion
-
-### Newsletters
-- keep the first screen strong
-- mix insight with updates, not diary filler
-- use clear section labels and easy skim structure
-
-## Quality Gate
-
-Before delivering:
-- verify factual claims against provided sources
-- remove filler and corporate language
-- confirm the voice matches the supplied examples
-- ensure every section adds new information
-- check formatting for the intended platform