aios-core 1.0.0

package/.aios-core/product/data/test-priorities-matrix.md

@@ -0,0 +1,175 @@
+<!-- Powered by AIOS™ Core -->
+
+# Test Priorities Matrix
+
+Guide for prioritizing test scenarios based on risk, criticality, and business impact.
+
+## Priority Levels
+
+### P0 - Critical (Must Test)
+
+**Criteria:**
+
+- Revenue-impacting functionality
+- Security-critical paths
+- Data integrity operations
+- Regulatory compliance requirements
+- Previously broken functionality (regression prevention)
+
+**Examples:**
+
+- Payment processing
+- Authentication/authorization
+- User data creation/deletion
+- Financial calculations
+- GDPR/privacy compliance
+
+**Testing Requirements:**
+
+- Comprehensive coverage at all levels
+- Both happy and unhappy paths
+- Edge cases and error scenarios
+- Performance under load
+
+### P1 - High (Should Test)
+
+**Criteria:**
+
+- Core user journeys
+- Frequently used features
+- Features with complex logic
+- Integration points between systems
+- Features affecting user experience
+
+**Examples:**
+
+- User registration flow
+- Search functionality
+- Data import/export
+- Notification systems
+- Dashboard displays
+
+**Testing Requirements:**
+
+- Primary happy paths required
+- Key error scenarios
+- Critical edge cases
+- Basic performance validation
+
+### P2 - Medium (Nice to Test)
+
+**Criteria:**
+
+- Secondary features
+- Admin functionality
+- Reporting features
+- Configuration options
+- UI polish and aesthetics
+
+**Examples:**
+
+- Admin settings panels
+- Report generation
+- Theme customization
+- Help documentation
+- Analytics tracking
+
+**Testing Requirements:**
+
+- Happy path coverage
+- Basic error handling
+- Can defer edge cases
+
+### P3 - Low (Test if Time Permits)
+
+**Criteria:**
+
+- Rarely used features
+- Nice-to-have functionality
+- Cosmetic issues
+- Non-critical optimizations
+
+**Examples:**
+
+- Advanced preferences
+- Legacy feature support
+- Experimental features
+- Debug utilities
+
+**Testing Requirements:**
+
+- Smoke tests only
+- Can rely on manual testing
+- Document known limitations
+
+## Risk-Based Priority Adjustments
+
+### Increase Priority When:
+
+- High user impact (affects >50% of users)
+- High financial impact (>$10K potential loss)
+- Security vulnerability potential
+- Compliance/legal requirements
+- Customer-reported issues
+- Complex implementation (>500 LOC)
+- Multiple system dependencies
+
+### Decrease Priority When:
+
+- Feature flag protected
+- Gradual rollout planned
+- Strong monitoring in place
+- Easy rollback capability
+- Low usage metrics
+- Simple implementation
+- Well-isolated component
+
+## Test Coverage by Priority
+
+| Priority | Unit Coverage | Integration Coverage | E2E Coverage       |
+| -------- | ------------- | -------------------- | ------------------ |
+| P0       | >90%          | >80%                 | All critical paths |
+| P1       | >80%          | >60%                 | Main happy paths   |
+| P2       | >60%          | >40%                 | Smoke tests        |
+| P3       | Best effort   | Best effort          | Manual only        |
+
+## Priority Assignment Rules
+
+1. **Start with business impact** - What happens if this fails?
+2. **Consider probability** - How likely is failure?
+3. **Factor in detectability** - Would we know if it failed?
+4. **Account for recoverability** - Can we fix it quickly?
+
+## Priority Decision Tree
+
+```
+Is it revenue-critical?
+├─ YES → P0
+└─ NO → Does it affect core user journey?
+    ├─ YES → Is it high-risk?
+    │   ├─ YES → P0
+    │   └─ NO → P1
+    └─ NO → Is it frequently used?
+        ├─ YES → P1
+        └─ NO → Is it customer-facing?
+            ├─ YES → P2
+            └─ NO → P3
+```
+
+## Test Execution Order
+
+1. Execute P0 tests first (fail fast on critical issues)
+2. Execute P1 tests second (core functionality)
+3. Execute P2 tests if time permits
+4. P3 tests only in full regression cycles
+
+## Continuous Adjustment
+
+Review and adjust priorities based on:
+
+- Production incident patterns
+- User feedback and complaints
+- Usage analytics
+- Test failure history
+- Business priority changes
+ 

package/.aios-core/product/data/wcag-compliance-guide.md

@@ -0,0 +1,267 @@
+# WCAG Compliance Guide
+
+**Standard:** WCAG 2.1 Level AA (minimum), AAA target
+**Purpose:** Ensure design system components meet accessibility standards
+**Reference:** https://www.w3.org/WAI/WCAG21/quickref/
+
+---
+
+## Quick Reference: WCAG AA Requirements
+
+### Color Contrast
+
+**Text:**
+- Normal text (< 18px): ≥ 4.5:1 contrast ratio
+- Large text (≥ 18px or bold ≥ 14px): ≥ 3:1 contrast ratio
+
+**Non-Text (UI components):**
+- Icons, buttons, form borders: ≥ 3:1 contrast ratio
+
+**Testing:**
+```bash
+# Use browser dev tools or:
+npm install -g pa11y
+pa11y --standard WCAG2AA http://localhost:3000
+```
+
+### Keyboard Navigation
+
+**Required:**
+- All interactive elements accessible via Tab key
+- Logical tab order (top → bottom, left → right)
+- Enter/Space activates buttons
+- Arrow keys for radio groups, menus
+- Escape closes modals, dropdowns
+
+**Focus Indicators:**
+- Visible focus outline (≥ 3:1 contrast)
+- Never `outline: none` without replacement
+
+```css
+/* Good */
+button:focus {
+    outline: 2px solid var(--color-primary);
+    outline-offset: 2px;
+}
+
+/* Bad */
+button:focus {
+    outline: none;  /* ❌ Removes keyboard navigation indicator */
+}
+```
+
+### ARIA Attributes
+
+**When to use:**
+- Custom widgets (not semantic HTML)
+- Dynamic content updates
+- Complex interactions
+
+**Common ARIA:**
+```html
+<!-- Button with icon only -->
+<button aria-label="Close dialog">
+    <CloseIcon />
+</button>
+
+<!-- Loading state -->
+<div aria-live="polite" aria-busy="true">
+    Loading...
+</div>
+
+<!-- Expanded state -->
+<button
+    aria-expanded="false"
+    aria-controls="menu"
+>
+    Menu
+</button>
+
+<!-- Disabled -->
+<button disabled aria-disabled="true">
+    Submit
+</button>
+```
+
+---
+
+## WCAG AAA (Target, not required)
+
+**Enhanced Requirements:**
+- Text contrast: ≥ 7:1 (normal), ≥ 4.5:1 (large)
+- No images of text
+- Enhanced visual presentation (line height ≥ 1.5)
+
+---
+
+## Component-Specific Guidelines
+
+### Buttons
+
+```tsx
+// ✅ Good
+<button
+    onClick={handleClick}
+    disabled={isDisabled}
+    aria-disabled={isDisabled}
+    aria-label="Save changes"
+>
+    Save
+</button>
+
+// ❌ Bad
+<div onClick={handleClick}>  // Not keyboard accessible
+    Save
+</div>
+```
+
+### Forms
+
+```tsx
+// ✅ Good
+<label htmlFor="email">Email</label>
+<input
+    id="email"
+    type="email"
+    required
+    aria-required="true"
+    aria-invalid={hasError}
+    aria-describedby="email-error"
+/>
+{hasError && (
+    <span id="email-error" role="alert">
+        Invalid email format
+    </span>
+)}
+
+// ❌ Bad
+<input placeholder="Email" />  // No label
+```
+
+### Modals
+
+```tsx
+// ✅ Good
+<div
+    role="dialog"
+    aria-modal="true"
+    aria-labelledby="dialog-title"
+>
+    <h2 id="dialog-title">Confirm Action</h2>
+    <p>Are you sure?</p>
+    <button onClick={onConfirm}>Yes</button>
+    <button onClick={onCancel}>No</button>
+</div>
+
+// Focus trap: Tab cycles within modal
+// Escape closes modal
+```
+
+---
+
+## Testing Checklist
+
+### Automated Testing
+
+```bash
+# Install tools
+npm install --save-dev @testing-library/jest-dom
+npm install --save-dev jest-axe
+
+# Test example
+import { axe } from 'jest-axe';
+
+test('Button is accessible', async () => {
+    const { container } = render(<Button>Click me</Button>);
+    const results = await axe(container);
+    expect(results).toHaveNoViolations();
+});
+```
+
+### Manual Testing
+
+- [ ] Navigate entire app with keyboard only (no mouse)
+- [ ] Test with screen reader (NVDA, JAWS, VoiceOver)
+- [ ] Zoom to 200% - all content still accessible
+- [ ] Check color contrast with dev tools
+- [ ] Test with high contrast mode
+
+---
+
+## Common Violations & Fixes
+
+### Violation 1: Missing Alt Text
+
+```tsx
+// ❌ Bad
+<img src="logo.png" />
+
+// ✅ Good
+<img src="logo.png" alt="Company logo" />
+
+// ✅ Good (decorative)
+<img src="decoration.png" alt="" />
+```
+
+### Violation 2: Low Contrast
+
+```css
+/* ❌ Bad */
+.text {
+    color: #999;           /* 2.8:1 contrast */
+    background: #fff;
+}
+
+/* ✅ Good */
+.text {
+    color: #666;           /* 5.7:1 contrast ✓ */
+    background: #fff;
+}
+```
+
+### Violation 3: Click-Only Elements
+
+```tsx
+// ❌ Bad
+<div onClick={handleClick}>Click me</div>
+
+// ✅ Good
+<button onClick={handleClick}>Click me</button>
+
+// ✅ Good (if div required)
+<div
+    role="button"
+    tabIndex={0}
+    onClick={handleClick}
+    onKeyDown={(e) => {
+        if (e.key === 'Enter' || e.key === ' ') {
+            handleClick();
+        }
+    }}
+>
+    Click me
+</div>
+```
+
+---
+
+## Resources
+
+- **WCAG Quick Reference:** https://www.w3.org/WAI/WCAG21/quickref/
+- **ARIA Authoring Practices:** https://www.w3.org/WAI/ARIA/apg/
+- **axe DevTools:** Browser extension for automated testing
+- **WAVE:** Web accessibility evaluation tool
+
+---
+
+## Design System Enforcement
+
+**All components MUST:**
+- Pass axe automated tests
+- Have ≥ 4.5:1 text contrast
+- Be keyboard navigable
+- Have visible focus indicators
+- Include proper ARIA attributes
+- Be tested with screen readers
+
+**Non-negotiable. Brad says: "Accessibility is quality."**

package/.aios-core/product/templates/activation-instructions-inline-greeting.yaml

@@ -0,0 +1,63 @@
+# Activation Instructions Template with Inline Greeting Logic
+# Version: 2.0 (Story 6.1.2.5-T1 - Option A Implementation)
+# Date: 2025-11-16
+
+# This template provides inline greeting logic that works reliably without
+# external JavaScript execution. It implements the greeting-builder.js logic
+# directly in YAML activation-instructions.
+
+activation-instructions:
+  - STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
+
+  - STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
+
+  - STEP 3: Generate contextual greeting using inline logic
+    # Session Type Detection (simplified inline version)
+    - If this is first message in conversation → session_type = "new"
+    - If conversation has history → session_type = "existing"
+    - Default to "new" if uncertain
+
+    # Greeting Components
+    - Start with greeting from persona_profile.greeting_levels.named
+    - Add role description from persona.role
+
+    # Project Status (check git)
+    - Use Bash tool to get: git branch --show-current
+    - Use Bash tool to get: git status --short | wc -l (count modified files)
+    - Use Bash tool to get: git log -1 --pretty=format:"%s" (recent commit)
+    - Format as:
+      📊 **Project Status:**
+      - 🌿 **Branch:** [branch_name]
+      - 📝 **Modified:** [count] files
+      - 📖 **Recent:** [commit_message]
+
+    # Command Filtering by Session Type
+    - If session_type = "new":
+      - Show commands with visibility: ["full", "quick", "key"] (up to 12)
+      - Header: "**Available Commands:**"
+    - If session_type = "existing":
+      - Show commands with visibility: ["quick", "key"] (6-8 commands)
+      - Header: "**Quick Commands:**"
+
+    # Command Formatting
+    - For each command:
+      - Format as: "   - `*{command.name}`: {command.description}"
+
+    # Footer
+    - Add: "Type `*guide` for comprehensive usage instructions."
+
+  - STEP 4: Display the greeting you generated in STEP 3
+
+  - STEP 5: HALT and await user input
+
+# Important Notes:
+# - This approach sacrifices DRY for reliability
+# - All 11 agents will have similar inline logic
+# - Changes require updating all agents (use batch script)
+# - No external dependencies = no execution failures
+# - Works 100% of the time in Claude Code environment
+
+# Maintenance:
+# - Use .aios-core/scripts/batch-update-greetings.js to update all agents
+# - Keep this template synchronized with actual agent files
+# - Document any greeting logic changes in ADR-001-IMPLEMENTATION-SUMMARY.md