aios-core 1.0.0

package/.aios-core/product/checklists/story-dod-checklist.md

@@ -0,0 +1,102 @@
+# Story Definition of Done (DoD) Checklist
+
+## Instructions for Developer Agent
+
+Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
+
+This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
+
+IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
+
+EXECUTION APPROACH:
+
+1. Go through each section systematically
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add brief comments explaining any [ ] or [N/A] items
+4. Be specific about what was actually implemented
+5. Flag any concerns or technical debt created
+
+The goal is quality delivery, not just checking boxes.]]
+
+## Checklist Items
+
+1. **Requirements Met:**
+
+   [[LLM: Be specific - list each requirement and whether it's complete]]
+
+   - [ ] All functional requirements specified in the story are implemented.
+   - [ ] All acceptance criteria defined in the story are met.
+
+2. **Coding Standards & Project Structure:**
+
+   [[LLM: Code quality matters for maintainability. Check each item carefully]]
+
+   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
+   - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
+   - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
+   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
+   - [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
+   - [ ] No new linter errors or warnings introduced.
+   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
+
+3. **Testing:**
+
+   [[LLM: Testing proves your code works. Be honest about test coverage]]
+
+   - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
+   - [ ] Test coverage meets project standards (if defined).
+
+4. **Functionality & Verification:**
+
+   [[LLM: Did you actually run and test your code? Be specific about what you tested]]
+
+   - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
+   - [ ] Edge cases and potential error conditions considered and handled gracefully.
+
+5. **Story Administration:**
+
+   [[LLM: Documentation helps the next developer. What should they know?]]
+
+   - [ ] All tasks within the story file are marked as complete.
+   - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
+   - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
+
+6. **Dependencies, Build & Configuration:**
+
+   [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
+
+   - [ ] Project builds successfully without errors.
+   - [ ] Project linting passes
+   - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
+   - [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
+   - [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
+   - [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
+
+7. **Documentation (If Applicable):**
+
+   [[LLM: Good documentation prevents future confusion. What needs explaining?]]
+
+   - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
+   - [ ] User-facing documentation updated, if changes impact users.
+   - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
+
+## Final Confirmation
+
+[[LLM: FINAL DOD SUMMARY
+
+After completing the checklist:
+
+1. Summarize what was accomplished in this story
+2. List any items marked as [ ] Not Done with explanations
+3. Identify any technical debt or follow-up work needed
+4. Note any challenges or learnings for future stories
+5. Confirm whether the story is truly ready for review
+
+Be honest - it's better to flag issues now than have them discovered later.]]
+
+- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
+ 

package/.aios-core/product/checklists/story-draft-checklist.md

@@ -0,0 +1,216 @@
+# Story Draft Checklist
+
+The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. The story document being validated (usually in docs/stories/ or provided directly)
+2. The parent epic context
+3. Any referenced architecture or design documents
+4. Previous related stories if this builds on prior work
+
+IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
+
+VALIDATION PRINCIPLES:
+
+1. Clarity - A developer should understand WHAT to build
+2. Context - WHY this is being built and how it fits
+3. Guidance - Key technical decisions and patterns to follow
+4. Testability - How to verify the implementation works
+5. Self-Contained - Most info needed is in the story itself
+
+REMEMBER: We assume competent developer agents who can:
+
+- Research documentation and codebases
+- Make reasonable technical decisions
+- Follow established patterns
+- Ask for clarification when truly stuck
+
+We're checking for SUFFICIENT guidance, not exhaustive detail.]]
+
+## 1. GOAL & CONTEXT CLARITY
+
+[[LLM: Without clear goals, developers build the wrong thing. Verify:
+
+1. The story states WHAT functionality to implement
+2. The business value or user benefit is clear
+3. How this fits into the larger epic/product is explained
+4. Dependencies are explicit ("requires Story X to be complete")
+5. Success looks like something specific, not vague]]
+
+- [ ] Story goal/purpose is clearly stated
+- [ ] Relationship to epic goals is evident
+- [ ] How the story fits into overall system flow is explained
+- [ ] Dependencies on previous stories are identified (if applicable)
+- [ ] Business context and value are clear
+
+## 2. TECHNICAL IMPLEMENTATION GUIDANCE
+
+[[LLM: Developers need enough technical context to start coding. Check:
+
+1. Key files/components to create or modify are mentioned
+2. Technology choices are specified where non-obvious
+3. Integration points with existing code are identified
+4. Data models or API contracts are defined or referenced
+5. Non-standard patterns or exceptions are called out
+
+Note: We don't need every file listed - just the important ones.]]
+
+- [ ] Key files to create/modify are identified (not necessarily exhaustive)
+- [ ] Technologies specifically needed for this story are mentioned
+- [ ] Critical APIs or interfaces are sufficiently described
+- [ ] Necessary data models or structures are referenced
+- [ ] Required environment variables are listed (if applicable)
+- [ ] Any exceptions to standard coding patterns are noted
+
+## 3. REFERENCE EFFECTIVENESS
+
+[[LLM: References should help, not create a treasure hunt. Ensure:
+
+1. References point to specific sections, not whole documents
+2. The relevance of each reference is explained
+3. Critical information is summarized in the story
+4. References are accessible (not broken links)
+5. Previous story context is summarized if needed]]
+
+- [ ] References to external documents point to specific relevant sections
+- [ ] Critical information from previous stories is summarized (not just referenced)
+- [ ] Context is provided for why references are relevant
+- [ ] References use consistent format (e.g., `docs/filename.md#section`)
+
+## 4. SELF-CONTAINMENT ASSESSMENT
+
+[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
+
+1. Core requirements are in the story, not just in references
+2. Domain terms are explained or obvious from context
+3. Assumptions are stated explicitly
+4. Edge cases are mentioned (even if deferred)
+5. The story could be understood without reading 10 other documents]]
+
+- [ ] Core information needed is included (not overly reliant on external docs)
+- [ ] Implicit assumptions are made explicit
+- [ ] Domain-specific terms or concepts are explained
+- [ ] Edge cases or error scenarios are addressed
+
+## 5. TESTING GUIDANCE
+
+[[LLM: Testing ensures the implementation actually works. Check:
+
+1. Test approach is specified (unit, integration, e2e)
+2. Key test scenarios are listed
+3. Success criteria are measurable
+4. Special test considerations are noted
+5. Acceptance criteria in the story are testable]]
+
+- [ ] Required testing approach is outlined
+- [ ] Key test scenarios are identified
+- [ ] Success criteria are defined
+- [ ] Special testing considerations are noted (if applicable)
+
+## 6. CODERABBIT INTEGRATION (CONDITIONAL)
+
+[[LLM: CONDITIONAL SECTION - Check `coderabbit_integration.enabled` in `.aios-core/core-config.yaml`
+
+**IF `coderabbit_integration.enabled: false`:**
+- SKIP this entire section (6)
+- Verify the story contains the skip notice:
+  > **CodeRabbit Integration**: Disabled
+- Mark section as N/A in validation result
+- Log: "ℹ️ CodeRabbit validation skipped - disabled in core-config.yaml"
+
+**IF `coderabbit_integration.enabled: true`:**
+- Validate ALL items below
+- Story must have complete CodeRabbit section including Story 6.3.3 Self-Healing
+
+CodeRabbit integration ensures automated code review and quality gates. Verify:
+
+1. The 🤖 CodeRabbit Integration section is present
+2. Story type is correctly identified (Database, API, Frontend, Deployment, Security, Architecture, Integration)
+3. Specialized agents are assigned appropriately (@dev required, type-specific agents as needed)
+4. Quality gates are defined (Pre-Commit required, Pre-PR/Pre-Deployment as applicable)
+5. Self-Healing Configuration (Story 6.3.3) is present with correct mode
+6. Focus areas match the story type]]
+
+**Section Presence:**
+- [ ] 🤖 CodeRabbit Integration section exists
+- [ ] All subsections are populated (Story Type Analysis, Specialized Agents, Quality Gates, Self-Healing, Focus Areas)
+
+**Story Type Analysis:**
+- [ ] Primary story type is correctly identified
+- [ ] Complexity level matches story scope
+- [ ] Secondary types listed if applicable
+
+**Specialized Agent Assignment:**
+- [ ] @dev listed as primary agent (required for all stories)
+- [ ] Type-specific agents assigned appropriately:
+  - Database stories → @db-sage
+  - Frontend stories → @ux-expert
+  - Deployment stories → @github-devops
+  - Security stories → @architect
+
+**Quality Gate Tasks:**
+- [ ] Pre-Commit (@dev) defined - REQUIRED for all stories
+- [ ] Pre-PR (@github-devops) defined if PR will be created
+- [ ] Pre-Deployment (@github-devops) defined for production stories
+
+**Self-Healing Configuration (Story 6.3.3):**
+- [ ] Self-healing configuration section is present
+- [ ] Mode matches primary agent:
+  - @dev: light mode (2 iterations, 15 min, CRITICAL only)
+  - @qa: full mode (3 iterations, 30 min, CRITICAL+HIGH)
+  - @github-devops: check mode (report only)
+- [ ] Severity behavior is documented
+
+**Focus Areas:**
+- [ ] Focus areas match the story type
+- [ ] Type-specific validations are listed
+
+## VALIDATION RESULT
+
+[[LLM: FINAL STORY VALIDATION REPORT
+
+Generate a concise validation report:
+
+1. Quick Summary
+
+   - Story readiness: READY / NEEDS REVISION / BLOCKED
+   - Clarity score (1-10)
+   - Major gaps identified
+
+2. Fill in the validation table with:
+
+   - PASS: Requirements clearly met
+   - PARTIAL: Some gaps but workable
+   - FAIL: Critical information missing
+
+3. Specific Issues (if any)
+
+   - List concrete problems to fix
+   - Suggest specific improvements
+   - Identify any blocking dependencies
+
+4. Developer Perspective
+   - Could YOU implement this story as written?
+   - What questions would you have?
+   - What might cause delays or rework?
+
+Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
+
+| Category                             | Status | Issues |
+| ------------------------------------ | ------ | ------ |
+| 1. Goal & Context Clarity            | _TBD_  |        |
+| 2. Technical Implementation Guidance | _TBD_  |        |
+| 3. Reference Effectiveness           | _TBD_  |        |
+| 4. Self-Containment Assessment       | _TBD_  |        |
+| 5. Testing Guidance                  | _TBD_  |        |
+| 6. CodeRabbit Integration (conditional) | _TBD_ or N/A |        |
+
+**Final Assessment:**
+
+- READY: The story provides sufficient context for implementation
+- NEEDS REVISION: The story requires updates (see issues)
+- BLOCKED: External information required (specify what information)
+ 

package/.aios-core/product/data/atomic-design-principles.md

@@ -0,0 +1,108 @@
+# Atomic Design Principles
+
+**Source:** Brad Frost's Atomic Design methodology
+**Application:** Atlas component organization
+
+---
+
+## The Five Levels
+
+### Atoms
+**Definition:** Basic building blocks that can't be broken down further.
+
+**Examples:**
+- Button
+- Input
+- Label
+- Icon
+- Heading
+- Text
+
+**Rules:**
+- Standalone, reusable
+- No dependencies on other atoms
+- Uses tokens only (no hardcoded values)
+- Single responsibility
+
+### Molecules
+**Definition:** Groups of atoms functioning together as a unit.
+
+**Examples:**
+- FormField (Label + Input + HelperText)
+- SearchBar (Input + Button)
+- Card Header (Icon + Heading + Text)
+
+**Rules:**
+- Composes atoms (doesn't reimplement)
+- Adds composition logic
+- Atoms remain independent
+
+### Organisms
+**Definition:** Complex UI components composed of molecules and/or atoms.
+
+**Examples:**
+- Navigation (Logo + NavLinks + SearchBar + UserMenu)
+- LoginForm (FormFields + Button + Link)
+- ProductCard (Image + CardHeader + CardBody + Button)
+
+**Rules:**
+- Distinct section of interface
+- Can be reused across templates
+- Manages internal state if needed
+
+### Templates
+**Definition:** Page-level layout without real content.
+
+**Examples:**
+- DashboardLayout
+- ArticleLayout
+- CheckoutFlowLayout
+
+**Rules:**
+- Defines page structure
+- Placeholder content
+- Reusable across pages
+
+### Pages
+**Definition:** Templates with real content.
+
+**Examples:**
+- Homepage
+- Product Detail Page
+- User Dashboard
+
+**Note:** Atlas focuses on atoms → organisms. Pages are application-specific.
+
+---
+
+## Benefits
+
+1. **Consistency:** Reusing atoms ensures UI consistency
+2. **Scalability:** New features built from existing components
+3. **Maintenance:** Fix once, applies everywhere
+4. **Testing:** Test atoms thoroughly, compose with confidence
+5. **Collaboration:** Clear component taxonomy
+
+---
+
+## Atlas Implementation
+
+```
+design-system/
+├── atoms/
+│   ├── Button/
+│   ├── Input/
+│   └── Label/
+├── molecules/
+│   ├── FormField/
+│   └── SearchBar/
+├── organisms/
+│   ├── Navigation/
+│   └── LoginForm/
+└── templates/
+    └── DashboardLayout/
+```
+
+**Atlas builds:** atoms first → molecules → organisms → templates
+
+**Reference:** https://atomicdesign.bradfrost.com/

package/.aios-core/product/data/brainstorming-techniques.md

@@ -0,0 +1,37 @@
+# Brainstorming Techniques Data
+
+## Creative Expansion
+
+1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
+2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
+3. **Reversal/Inversion**: Pose the reverse question, let them work through it
+4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
+
+## Structured Frameworks
+
+5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
+6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
+7. **Mind Mapping**: Start with central concept, ask them to suggest branches
+
+## Collaborative Techniques
+
+8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
+9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
+10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
+
+## Deep Exploration
+
+11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
+12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
+13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
+
+## Advanced Techniques
+
+14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
+15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
+16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
+17. **Time Shifting**: "How would you solve this in 1995? 2030?"
+18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
+19. **Metaphor Mapping**: Use extended metaphors to explore solutions
+20. **Question Storming**: Generate questions instead of answers first
+ 

package/.aios-core/product/data/consolidation-algorithms.md

@@ -0,0 +1,142 @@
+# Pattern Consolidation Algorithms
+
+**Agent:** Brad (Design System Architect)
+**Purpose:** How Brad reduces 176 patterns to 32
+
+---
+
+## Color Clustering (HSL-based)
+
+**Algorithm:** Perceptual similarity in HSL color space
+
+```python
+def cluster_colors(colors, threshold=0.05):
+    """
+    Group colors within 5% HSL difference
+    threshold: 0.05 = 5% difference in H, S, or L
+    """
+    clusters = []
+    for color in colors:
+        hsl = hex_to_hsl(color)
+        found_cluster = False
+
+        for cluster in clusters:
+            cluster_hsl = hex_to_hsl(cluster['primary'])
+            if hsl_distance(hsl, cluster_hsl) < threshold:
+                cluster['members'].append(color)
+                found_cluster = True
+                break
+
+        if not found_cluster:
+            clusters.append({
+                'primary': color,  # Most-used in this cluster
+                'members': [color]
+            })
+
+    return clusters
+```
+
+**Example:**
+```
+Input: #0066CC, #0065CB, #0067CD, #0064CA
+HSL distance: All within 2% of each other
+Output: Cluster → Keep #0066CC (most-used)
+```
+
+**Why HSL not RGB:** Perceptually similar colors cluster better in HSL space.
+
+---
+
+## Button Semantic Analysis
+
+**Algorithm:** Keyword matching + usage frequency
+
+```python
+def analyze_button_semantics(button_classes):
+    """
+    Group buttons by semantic purpose
+    Keywords: primary, main, secondary, default, danger, delete, destructive
+    """
+    semantic_groups = {
+        'primary': [],
+        'secondary': [],
+        'destructive': []
+    }
+
+    for btn_class, usage_count in button_classes:
+        if any(kw in btn_class.lower() for kw in ['primary', 'main', 'cta']):
+            semantic_groups['primary'].append((btn_class, usage_count))
+        elif any(kw in btn_class.lower() for kw in ['secondary', 'default', 'ghost']):
+            semantic_groups['secondary'].append((btn_class, usage_count))
+        elif any(kw in btn_class.lower() for kw in ['danger', 'delete', 'destructive', 'error']):
+            semantic_groups['destructive'].append((btn_class, usage_count))
+
+    # Keep most-used in each group
+    return {
+        group: max(classes, key=lambda x: x[1])[0]
+        for group, classes in semantic_groups.items()
+        if classes
+    }
+```
+
+**Result:** 47 buttons → 3 variants (primary, secondary, destructive)
+
+---
+
+## Spacing Scale Generation
+
+**Algorithm:** Base unit detection + scale building
+
+```python
+def generate_spacing_scale(spacing_values):
+    """
+    Detect base unit (4px or 8px)
+    Build scale from base unit
+    """
+    # Find GCD of all spacing values
+    base_unit = gcd_multiple(spacing_values)
+
+    # Common: 4px or 8px
+    if base_unit not in [4, 8]:
+        base_unit = 4  # Default to 4px
+
+    # Generate scale
+    scale = {
+        'xs': base_unit,
+        'sm': base_unit * 2,
+        'md': base_unit * 4,
+        'lg': base_unit * 6,
+        'xl': base_unit * 8,
+        '2xl': base_unit * 12,
+        '3xl': base_unit * 16
+    }
+
+    return scale
+```
+
+**Example:**
+```
+Input: 2, 4, 6, 8, 12, 16, 20, 24, 32
+Base unit: 4px
+Output: xs=4, sm=8, md=16, lg=24, xl=32, 2xl=48, 3xl=64
+```
+
+---
+
+## Consolidation Targets
+
+**Brad's Targets:**
+- Colors: >85% reduction
+- Buttons: >90% reduction
+- Spacing: >60% reduction
+- Typography: >50% reduction
+- **Overall:** >80% reduction
+
+**Achieved:** Typically 81-86% overall reduction
+
+---
+
+## References
+
+- HSL color space: https://en.wikipedia.org/wiki/HSL_and_HSV
+- Brad Frost patterns: https://bradfrost.com/blog/