amazingteam 3.0.0

package/.ai-team/memory/planner/decomposition_notes.md

@@ -0,0 +1,82 @@
+# Planner Memory - Task Decomposition Notes
+
+This file stores task decomposition and workflow orchestration knowledge.
+
+---
+
+## Task Decomposition Patterns
+
+### Feature Tasks
+
+| Complexity | Typical Phases | Typical Duration |
+|------------|----------------|------------------|
+| Simple | Design → Implement → Test | 1-2 days |
+| Moderate | Design → Implement → Test → Review | 3-5 days |
+| Complex | Analysis → Design → Implement → Test → Review → Release | 1-2 weeks |
+
+### Bug Tasks
+
+| Severity | Typical Flow | Priority |
+|----------|--------------|----------|
+| Critical | Triage → Fix → Test → Deploy | Immediate |
+| High | Triage → Fix → Test → Review | Within sprint |
+| Medium | Triage → Fix → Test | Next sprint |
+| Low | Triage → Fix | Backlog |
+
+---
+
+## Workflow Rules
+
+### Handoff Rules
+
+| From | To | Criteria |
+|------|-----|----------|
+| Architect | Developer | Design approved |
+| Developer | QA | Implementation complete |
+| QA | Reviewer | Tests passing |
+| Reviewer | Release | Review approved |
+
+### Blocking Conditions
+
+- Design not approved → Block implementation
+- Tests failing → Block review
+- Review not approved → Block merge
+- Dependencies incomplete → Block start
+
+---
+
+## Dispatch Log
+
+### [Date] - [Task ID]
+
+**Task**: [Description]
+
+**Decomposition**: [How it was broken down]
+
+**Dispatch**: [Which roles were involved]
+
+**Outcome**: [Result]
+
+---
+
+## Dependency Tracking
+
+### Active Dependencies
+
+| Task | Depends On | Status |
+|------|------------|--------|
+| | | |
+
+### Dependency Resolution Strategies
+
+- Parallelize when possible
+- Break dependencies with interfaces
+- Document assumptions when blocking
+
+---
+
+## Notes
+
+- Update after each task decomposition
+- Track patterns that work well
+- Note recurring dependency issues

package/.ai-team/memory/planner/flow_rules.md

@@ -0,0 +1,86 @@
+# Planner Memory - Flow Rules
+
+This file stores workflow progression rules and state machine logic.
+
+---
+
+## Task State Machine
+
+```
+backlog → ready → in_analysis → in_design → in_implementation → in_validation → in_review → release_candidate → done
+                              ↓                                              ↓
+                           blocked ←───────────────────────────────────────── ←
+```
+
+### Valid State Transitions
+
+| Current State | Valid Next States |
+|---------------|-------------------|
+| backlog | ready |
+| ready | in_analysis, blocked |
+| in_analysis | in_design, blocked, ready |
+| in_design | in_implementation, blocked, in_analysis |
+| in_implementation | in_validation, blocked, in_design |
+| in_validation | in_review, in_implementation, blocked |
+| in_review | release_candidate, in_implementation, blocked |
+| release_candidate | done, in_review, blocked |
+| blocked | (previous state before blocking) |
+| done | (terminal) |
+
+---
+
+## State Entry Criteria
+
+### ready
+
+- Task has clear description
+- Acceptance criteria defined
+- Priority assigned
+
+### in_analysis
+
+- Architect assigned
+- Analysis document created
+
+### in_design
+
+- Analysis complete
+- Design document created
+
+### in_implementation
+
+- Design approved
+- Developer assigned
+
+### in_validation
+
+- Implementation complete
+- Tests written
+
+### in_review
+
+- Tests passing
+- PR created
+
+### release_candidate
+
+- Review approved
+- All checks passing
+
+### blocked
+
+- Blocking issue documented
+- Escalation path defined
+
+### done
+
+- All acceptance criteria met
+- PR merged
+
+---
+
+## Notes
+
+- Follow state transitions strictly
+- Document blocking reasons
+- Escalate long-blocked tasks

package/.ai-team/memory/planner/github_issue_patterns.md

@@ -0,0 +1,229 @@
+# Planner Memory - GitHub Issue Orchestration Patterns
+
+This file stores patterns and rules for GitHub issue-based subtask orchestration.
+
+---
+
+## GitHub Issue Mapping
+
+### Parent Issue Structure
+
+```text
+Title: [Descriptive title]
+
+Background:
+[Context and problem statement]
+
+Overall Acceptance Criteria:
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+Decomposition Status:
+- required: true/false
+- child_issues_created: true/false
+
+Child Issues:
+- #XXX: [Subtask] Title 1
+- #YYY: [Subtask] Title 2
+- #ZZZ: [Subtask] Title 3
+
+Completion Rule:
+This issue closes only when all child issues are completed.
+```
+
+### Subtask Issue Structure
+
+```text
+Title: [Subtask] Brief title
+
+Parent Issue:
+- #{parent-number}
+
+Dependencies:
+- #{dependency-issue-number} (if any)
+
+Owner Role:
+- architect | developer | qa | reviewer | triage | ci-analyst
+
+Scope:
+- [what this subtask covers]
+
+Acceptance Criteria:
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+Out of Scope:
+- [what is not covered]
+```
+
+---
+
+## Issue Labels
+
+### Type Labels
+- `type:feature` - New functionality
+- `type:bug` - Bug fix
+- `type:tech-task` - Technical debt, refactoring
+- `type:subtask` - Child issue of a larger task
+
+### Role Labels
+- `role:architect` - Needs architecture work
+- `role:developer` - Needs implementation
+- `role:qa` - Needs validation
+- `role:reviewer` - Needs review
+- `role:triage` - Needs classification
+- `role:ci-analyst` - Needs CI investigation
+
+### State Labels
+- `state:ready` - Ready to work
+- `state:in-progress` - Currently being worked on
+- `state:blocked` - Blocked by something
+- `state:in-review` - Under review
+- `state:validated` - Tests passing
+
+---
+
+## Dependency Patterns
+
+### Sequential Chain
+```
+#201 (design) → #202 (implement) → #203 (test) → #204 (review)
+```
+Most common pattern. One subtask leads to the next.
+
+### Fan-Out
+```
+                    → #202 (implement A)
+#201 (design) ────→ → #203 (implement B)
+                    → #204 (implement C)
+```
+One design enables multiple parallel implementations.
+
+### Merge
+```
+#201 (implement A) ─┐
+#202 (implement B) ─┼→ #203 (integration test)
+#204 (implement C) ─┘
+```
+Multiple implementations merge into a validation step.
+
+### External Dependency
+```
+#201 → [external artifact] → #202
+```
+Blocked by something outside the issue graph.
+
+---
+
+## State Mapping
+
+| Local State | GitHub State | Label |
+|-------------|--------------|-------|
+| backlog | open | - |
+| ready | open | state:ready |
+| in_analysis | open | state:in-progress, role:architect |
+| in_design | open | state:in-progress, role:architect |
+| in_implementation | open | state:in-progress, role:developer |
+| in_validation | open | state:in-progress, role:qa |
+| in_review | open | state:in-review |
+| release_candidate | open | state:validated |
+| blocked | open | state:blocked |
+| done | closed | - |
+
+---
+
+## Dispatch Patterns
+
+### Design-First Flow
+```
+Parent Issue
+    │
+    ├── #201: [Subtask] Design (architect)
+    │       ↓
+    ├── #202: [Subtask] Implement (developer)
+    │       ↓
+    ├── #203: [Subtask] Test (qa)
+    │       ↓
+    └── #204: [Subtask] Review (reviewer)
+```
+
+### Parallel Implementation Flow
+```
+Parent Issue
+    │
+    ├── #201: [Subtask] Design API (architect)
+    │       ↓
+    │       ├→ #202: [Subtask] Implement Client (developer)
+    │       └→ #203: [Subtask] Implement Server (developer)
+    │              ↓
+    └── #204: [Subtask] Integration Test (qa)
+```
+
+### Bug Fix Flow
+```
+Parent Issue (Bug)
+    │
+    ├── #201: [Subtask] Investigate (triage)
+    │       ↓
+    ├── #202: [Subtask] Fix (developer)
+    │       ↓
+    ├── #203: [Subtask] Regression Test (qa)
+    │       ↓
+    └── #204: [Subtask] Review (reviewer)
+```
+
+---
+
+## GitHub CLI Commands
+
+### Create Subtask
+```bash
+gh issue create \
+  --title "[Subtask] Title" \
+  --body "Parent: #XXX
+Dependencies: #YYY
+Role: developer
+..." \
+  --label "type:subtask,role:developer,state:ready"
+```
+
+### Check Issue Status
+```bash
+gh issue view {number} --json number,title,state,labels
+```
+
+### Link PR to Issue
+```bash
+gh pr create --title "Title" --body "Fixes #XXX"
+```
+
+### Close Issue
+```bash
+gh issue close {number} --comment "Completed via PR #YYY"
+```
+
+---
+
+## Completion Verification
+
+### Subtask Completion Checklist
+- [ ] Acceptance criteria met
+- [ ] Linked PR merged (or not required)
+- [ ] Tests passing
+- [ ] GitHub issue closed
+
+### Parent Completion Checklist
+- [ ] All child issues closed
+- [ ] Overall acceptance criteria met
+- [ ] No unresolved blockers
+- [ ] Documentation updated (if required)
+
+---
+
+## Notes
+
+- Always maintain both GitHub and local task records
+- Use labels consistently for project board integration
+- One PR per subtask is preferred
+- Never close parent before all children are complete

package/.ai-team/memory/qa/regression_cases.md

@@ -0,0 +1,101 @@
+# QA Memory - Regression Cases
+
+This file tracks regression test cases and patterns for the QA agent.
+
+---
+
+## Regression Test Categories
+
+### Critical Path Tests
+
+These tests must always pass. They cover core functionality.
+
+| Test ID | Feature | Description | Priority |
+|---------|---------|-------------|----------|
+| REG-001 | AI Agents | Agent configuration loads correctly | P0 |
+| REG-002 | Memory | Memory directories are accessible | P0 |
+| REG-003 | Commands | Commands execute correctly | P0 |
+
+### Security Tests
+
+| Test ID | Feature | Description | Priority |
+|---------|---------|-------------|----------|
+| SEC-001 | Auth | Authentication validates tokens | P0 |
+| SEC-002 | Input | Input sanitization works | P0 |
+| SEC-003 | Access | Access control enforced | P1 |
+
+### Performance Tests
+
+| Test ID | Feature | Description | Priority |
+|---------|---------|-------------|----------|
+| PER-001 | Build | Build completes in reasonable time | P1 |
+| PER-002 | Tests | Test suite runs in reasonable time | P1 |
+
+---
+
+## Regression Checklist Template
+
+### Before Each Release
+
+- [ ] All P0 tests pass
+- [ ] All P1 tests pass
+- [ ] Coverage meets threshold
+- [ ] No new lint errors
+- [ ] Build succeeds
+- [ ] Documentation updated
+
+### After Bug Fixes
+
+- [ ] Bug reproduction test added
+- [ ] Related tests still pass
+- [ ] No regression in similar features
+
+---
+
+## Regression Patterns
+
+### Pattern: State Pollution
+
+**Symptoms**: Tests pass individually but fail when run together
+
+**Cause**: Shared state between tests
+
+**Prevention**: Reset state in beforeEach/afterEach
+
+### Pattern: Timing Issues
+
+**Symptoms**: Tests fail intermittently
+
+**Cause**: Race conditions or async timing
+
+**Prevention**: Use proper async handling, avoid arbitrary waits
+
+### Pattern: Environment Differences
+
+**Symptoms**: Tests pass locally but fail in CI
+
+**Cause**: Different environment configuration
+
+**Prevention**: Use consistent environment setup
+
+---
+
+## Regression Log
+
+### [Date] - [Regression Description]
+
+**Issue**: [What regressed]
+
+**Root Cause**: [Why it happened]
+
+**Fix**: [How it was resolved]
+
+**Test Added**: [What test prevents recurrence]
+
+---
+
+## Notes
+
+- Update regression cases when new features are added
+- Document any regression patterns discovered
+- Keep priority classifications current

package/.ai-team/memory/qa/test_strategy.md

@@ -0,0 +1,138 @@
+# QA Memory - Test Strategy
+
+This file defines the testing strategy and approach for the QA agent.
+
+---
+
+## Testing Philosophy
+
+### Core Principles
+
+1. **Test behavior, not implementation**
+2. **Tests should be deterministic**
+3. **Each test should verify one thing**
+4. **Tests should be independent**
+5. **Tests should be fast**
+
+### Test Pyramid
+
+```
+        /\
+       /  \
+      / E2E\         Few, slow, high confidence
+     /------\
+    /        \
+   /Integration\     Some, moderate speed
+  /-----------\
+ /             \
+/    Unit       \    Many, fast, focused
+-----------------
+```
+
+---
+
+## Test Categories
+
+### Unit Tests
+
+| Aspect | Guidelines |
+|--------|------------|
+| Scope | Single function or class |
+| Speed | < 100ms per test |
+| Dependencies | Mocked |
+| Coverage | > 80% for business logic |
+
+### Integration Tests
+
+| Aspect | Guidelines |
+|--------|------------|
+| Scope | Multiple components |
+| Speed | < 1s per test |
+| Dependencies | Real or test doubles |
+| Coverage | Critical paths |
+
+### End-to-End Tests
+
+| Aspect | Guidelines |
+|--------|------------|
+| Scope | Full system |
+| Speed | Seconds to minutes |
+| Dependencies | All real |
+| Coverage | User journeys |
+
+---
+
+## Test Structure (AAA Pattern)
+
+```typescript
+describe('ComponentName', () => {
+  describe('methodName', () => {
+    it('should do something when condition', () => {
+      // Arrange
+      const input = createTestInput();
+      const expected = createExpectedOutput();
+
+      // Act
+      const result = component.method(input);
+
+      // Assert
+      expect(result).toEqual(expected);
+    });
+  });
+});
+```
+
+---
+
+## Test Naming Convention
+
+```
+should_[expectedBehavior]_when_[condition]
+
+Examples:
+- should_returnUser_when_validId
+- should_throwError_when_invalidInput
+- should_sendEmail_when_userSubscribes
+```
+
+---
+
+## Test Data Management
+
+### Factories
+
+```typescript
+function createTestUser(overrides = {}) {
+  return {
+    id: 'test-user-id',
+    name: 'Test User',
+    email: 'test@example.com',
+    ...overrides
+  };
+}
+```
+
+### Fixtures
+
+- Store complex test data in `__fixtures__/` directories
+- Keep fixtures close to tests that use them
+- Use JSON for complex objects
+
+---
+
+## Coverage Targets
+
+| Type | Target | Rationale |
+|------|--------|-----------|
+| Branches | 80% | Catch edge cases |
+| Functions | 80% | All code paths tested |
+| Lines | 80% | Sufficient coverage |
+| Statements | 80% | Granular coverage |
+
+---
+
+## Notes
+
+- Update this file when testing approach changes
+- Document new testing patterns
+- Track coverage trends