agileflow 3.4.3 → 4.0.0-alpha.10

package/src/core/experts/mobile/workflow.md

@@ -1,240 +0,0 @@
-# Mobile Expert - Complete Workflow
-
-**Purpose**: End-to-end workflow for implementing mobile features with expertise-first approach.
-
-## The Three-Step Workflow
-
-```
-Plan (with Expertise) → Build (Execute) → Self-Improve (Update Expertise)
-```
-
----
-
-## Step 1: Plan (with Expertise)
-
-### 1.1 Load Expertise First
-```
-Read: packages/cli/src/core/experts/mobile/expertise.yaml
-```
-
-Parse and internalize:
-- Known file locations (screens, components, navigation, services)
-- React Native vs Flutter patterns
-- Navigation conventions
-- Native module patterns
-- Performance targets
-
-### 1.2 Validate Expertise Against Codebase
-
-Before planning, verify expertise is current:
-```bash
-# Check key directories exist
-ls src/mobile/screens/
-ls src/mobile/components/
-ls src/mobile/navigation/
-```
-
-Note any discrepancies for later update.
-
-### 1.3 Create Detailed Plan
-
-With expertise loaded, create implementation plan:
-
-1. **Identify affected files** (from expertise, not searching)
-2. **Determine patterns to use** (from patterns section)
-3. **List specific changes needed**
-4. **Note any gaps** in expertise that need exploration
-
-Example Plan:
-```markdown
-## Implementation Plan: Add Profile Screen
-
-### Files to Create/Modify (from expertise):
-- Create: src/mobile/screens/ProfileScreen.tsx
-- Modify: src/mobile/navigation/MainNavigator.tsx (add route)
-- Create: src/mobile/components/ProfileCard.tsx
-
-### Patterns to Use:
-- Screen component pattern (from expertise)
-- Stack navigation registration (from expertise)
-- Platform-agnostic component (from conventions)
-
-### Implementation Steps:
-1. Create ProfileScreen with standard screen structure
-2. Add ProfileCard reusable component
-3. Register in MainNavigator
-4. Add navigation params types
-5. Test on iOS and Android
-```
-
----
-
-## Step 2: Build (Execute Plan)
-
-### 2.1 Execute Implementation
-
-Follow the plan exactly:
-- Use file paths from expertise
-- Apply patterns from expertise
-- Follow conventions from expertise
-
-### 2.2 Handle Discoveries
-
-If you discover something not in expertise:
-```markdown
-## Discovery Log
-- Found: src/mobile/utils/gestures.ts (not in expertise)
-- Pattern: useNavigation hook preferred over navigation prop
-- Convention: Screens export default, components named export
-```
-
-### 2.3 Test Implementation
-
-Per expertise conventions:
-- Test on real iOS device
-- Test on real Android device
-- Verify navigation flows
-- Check performance targets
-
-### 2.4 Capture Changes
-
-Document what was actually changed:
-```markdown
-## Changes Made
-- Created: src/mobile/screens/ProfileScreen.tsx
-- Created: src/mobile/components/ProfileCard.tsx
-- Modified: src/mobile/navigation/MainNavigator.tsx
-- Modified: src/mobile/navigation/types.ts (added ProfileParams)
-```
-
----
-
-## Step 3: Self-Improve (Update Expertise)
-
-### 3.1 Load Current Expertise
-```
-Read: packages/cli/src/core/experts/mobile/expertise.yaml
-```
-
-### 3.2 Identify Updates Needed
-
-Compare discoveries with current expertise:
-- New files not documented?
-- New patterns discovered?
-- Conventions that need updating?
-- Performance insights gained?
-
-### 3.3 Update Expertise File
-
-Add learning entry:
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "ProfileScreen requires ProfileParams in RootStackParamList"
-    files_affected:
-      - src/mobile/screens/ProfileScreen.tsx
-      - src/mobile/navigation/types.ts
-    context: "US-0090: Add profile screen"
-```
-
-Update `last_updated` date.
-
-Add any new patterns discovered:
-```yaml
-patterns:
-  - name: Screen Params Pattern
-    description: "All screen params must be typed in RootStackParamList"
-    location: src/mobile/navigation/types.ts
-```
-
-### 3.4 Validate Update
-
-Ensure expertise.yaml:
-- Is valid YAML
-- Reflects current codebase state
-- Stays under ~200 lines
-
----
-
-## Quick Reference
-
-### Before ANY Mobile Work
-```
-1. Read expertise.yaml
-2. Validate against codebase
-3. Plan with expertise knowledge
-```
-
-### After ANY Mobile Work
-```
-1. Document what was learned
-2. Update expertise.yaml
-3. Validate the update
-```
-
-### Key Files (from expertise)
-- Screens: `src/mobile/screens/`
-- Components: `src/mobile/components/`
-- Navigation: `src/mobile/navigation/`
-- Services: `src/mobile/services/`
-- Native: `ios/`, `android/`
-
-### Key Conventions (from expertise)
-- Test on real devices (not just simulators)
-- Use platform-agnostic code first
-- Abstract native modules through services
-- Handle safe area insets
-- Minimum touch target: 44x44 points
-
----
-
-## Example: Complete Feature Implementation
-
-**Task**: Implement biometric login
-
-### Plan Phase
-```markdown
-From expertise:
-- Services location: src/mobile/services/
-- Native modules need abstraction layer
-- Must test on both platforms
-
-Plan:
-1. Create BiometricService.ts in services/
-2. Add native setup for iOS (Face ID) and Android (Fingerprint)
-3. Integrate with login screen
-4. Test on both platforms
-```
-
-### Build Phase
-```markdown
-Created:
-- src/mobile/services/BiometricService.ts
-- Updated ios/Podfile (react-native-biometrics)
-- Updated android/app/build.gradle
-
-Tested:
-- ✅ iOS Face ID working
-- ✅ Android fingerprint working
-```
-
-### Self-Improve Phase
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Biometric auth requires react-native-biometrics and native setup"
-    files_affected:
-      - src/mobile/services/BiometricService.ts
-      - ios/Podfile
-      - android/app/build.gradle
-    context: "US-0091: Biometric login"
-
-# Updated files section:
-native_modules:
-  - path: src/mobile/services/BiometricService.ts
-    purpose: "Face ID / Touch ID authentication wrapper"
-```
-
----
-
-This workflow ensures the agent learns from every task and becomes faster over time.

package/src/core/experts/monitoring/expertise.yaml

@@ -1,132 +0,0 @@
-# Monitoring Expert - Domain Knowledge
-# This file is the agent's "mental model" of the monitoring domain
-# AUTO-UPDATED by self-improve.md after completing work
-
-domain: monitoring
-last_updated: 2025-12-21
-version: 1.1
-
-files:
-  logging:
-    - path: src/logging/
-      purpose: "Structured logging implementation"
-      key_exports: [logger, createLogger]
-      conventions: "JSON structured logs"
-    - path: src/logging/logger.ts
-      purpose: "Logger factory and configuration"
-      conventions: "Singleton logger instance"
-    - path: src/logging/context.ts
-      purpose: "Request context for correlation IDs"
-      conventions: "AsyncLocalStorage for request context"
-
-  metrics:
-    - path: src/metrics/
-      purpose: "Application metrics collection"
-      key_exports: [metrics, histogram, counter, gauge]
-      conventions: "Prometheus-compatible metrics"
-    - path: src/metrics/registry.ts
-      purpose: "Metrics registry and exporters"
-    - path: src/metrics/middleware.ts
-      purpose: "HTTP metrics middleware"
-
-  health:
-    - path: src/health/
-      purpose: "Health check implementations"
-      key_exports: [healthCheck, readinessCheck]
-      conventions: "Return 200 if healthy, 503 if degraded"
-    - path: src/health/checks/
-      purpose: "Individual dependency health checks"
-      conventions: "One check per dependency"
-
-  alerting:
-    - path: monitoring/alerts/
-      purpose: "Alert rule definitions"
-      conventions: "YAML or Prometheus alerting rules"
-    - path: monitoring/runbooks/
-      purpose: "Incident response runbooks"
-      conventions: "Markdown with diagnosis and resolution steps"
-
-  dashboards:
-    - path: monitoring/dashboards/
-      purpose: "Grafana dashboard JSON definitions"
-      conventions: "One dashboard per service or domain"
-
-relationships:
-  - parent: api_endpoints
-    child: metrics_middleware
-    type: measured_by
-    notes: "All API requests measured by metrics middleware"
-  - parent: logger
-    child: log_aggregator
-    type: ships_to
-    notes: "Logs shipped to ELK/Datadog/CloudWatch"
-  - parent: metrics
-    child: prometheus
-    type: scraped_by
-    notes: "Prometheus scrapes /metrics endpoint"
-  - parent: alerts
-    child: runbooks
-    type: links_to
-    notes: "Each alert links to its runbook"
-
-patterns:
-  - name: Structured Logging
-    description: "JSON logs with correlation IDs and context"
-    location: src/logging/
-    example: |
-      logger.info('Request completed', {
-        request_id: ctx.requestId,
-        user_id: ctx.userId,
-        duration_ms: 142,
-        status: 200
-      });
-
-  - name: RED Metrics
-    description: "Rate, Errors, Duration for every service"
-    location: src/metrics/
-    example: |
-      - http_requests_total (counter)
-      - http_request_duration_seconds (histogram)
-      - http_request_errors_total (counter)
-
-  - name: Health Check Pattern
-    description: "Check all dependencies and return aggregate health"
-    location: src/health/
-    example: |
-      /health returns { status: 'healthy', checks: { db: true, cache: true } }
-
-  - name: Alert with Runbook
-    description: "Every alert links to resolution runbook"
-    location: monitoring/alerts/
-    example: |
-      - alert: HighErrorRate
-        annotations:
-          runbook: /runbooks/high-error-rate.md
-
-  - name: SLO-Based Alerting
-    description: "Alert on error budget burn rate, not just thresholds"
-    location: monitoring/alerts/
-    example: "Alert if burning >2% error budget per hour"
-
-conventions:
-  - "NEVER log PII, passwords, or API keys"
-  - "ALWAYS include request_id/trace_id in logs"
-  - "Use structured JSON logging (not plain text)"
-  - "Expose /metrics endpoint for Prometheus"
-  - "Expose /health endpoint for load balancer"
-  - "Link every alert to a runbook"
-  - "Use log levels appropriately: ERROR, WARN, INFO, DEBUG"
-  - "Set retention policies for logs and metrics"
-  - "Test alerts in staging before production"
-
-# Log levels, metric types, SLO targets: generic observability knowledge (models know - omitted)
-
-# Learnings (trimmed - keep 2 most actionable)
-learnings:
-  - date: 2025-12-21
-    context: "Session hooks and status line"
-    insight: "SessionStart hooks in .claude/settings.json. Status line via agileflow-statusline.sh shows git branch, current story, WIP count, completion %."
-
-  - date: 2025-12-21
-    context: "Agent activity logging"
-    insight: "docs/09-agents/bus/log.jsonl: append-only JSON Lines with timestamp, agent_id, message_type, payload. Never edit existing lines."

package/src/core/experts/monitoring/question.md

@@ -1,76 +0,0 @@
-# Monitoring Expert - Question Workflow
-
-**Purpose**: Answer questions about monitoring and observability using expertise-first approach.
-
-## Workflow
-
-### Step 1: Load Expertise
-```
-Read: packages/cli/src/core/experts/monitoring/expertise.yaml
-```
-
-Parse the expertise file to understand:
-- Known logging and metrics file locations
-- Structured logging patterns
-- Metric types and naming
-- Health check implementations
-- Alert rules and runbooks
-- SLO targets
-
-### Step 2: Validate Against Codebase
-
-Before answering, verify expertise is current:
-1. Check if mentioned files/directories exist
-2. Spot-check logging implementation
-3. Verify metrics endpoint exists
-4. Note any discrepancies for later self-improve
-
-### Step 3: Answer with Expertise
-
-When answering questions:
-
-**If expertise covers the question:**
-- Provide direct answer from expertise
-- Include specific file paths
-- Reference patterns (RED metrics, structured logging)
-- Include SLO targets where relevant
-- Skip unnecessary exploration
-
-**If expertise is incomplete:**
-- Search codebase for missing information
-- Answer the question
-- Note gaps for self-improve
-
-### Step 4: Flag Updates Needed
-
-If you discovered new information:
-```
-Note for self-improve:
-- New metric discovered: [metric_name]
-- Alert not documented: [alert]
-- Runbook missing: [incident_type]
-```
-
-## Example Usage
-
-**Question**: "Where is the logger configured?"
-
-**Expertise-First Answer**:
-1. Check expertise.yaml → files → logging → logger.ts
-2. Verify file exists at `src/logging/logger.ts`
-3. Answer: "Logger is configured in `src/logging/logger.ts`. It exports a singleton logger instance. Request context for correlation IDs is in `src/logging/context.ts`."
-
-**Question**: "What are our SLO targets?"
-
-**Expertise-First Answer**:
-1. Check expertise.yaml → slo_targets
-2. List: availability 99.9%, latency p50 <100ms, p95 <200ms, error rate <0.1%
-3. Answer with targets and where they're monitored
-
-## Key Principles
-
-1. **Expertise First**: Always check expertise.yaml before searching
-2. **Security Focus**: Never log PII, passwords, or API keys
-3. **Correlation IDs**: Always include request_id/trace_id in logs
-4. **Runbooks**: Every alert should have a linked runbook
-5. **Learn**: Note gaps for self-improve to fill later

package/src/core/experts/monitoring/self-improve.md

@@ -1,150 +0,0 @@
-# Monitoring Expert - Self-Improve Workflow
-
-**Purpose**: Automatically update expertise.yaml after completing monitoring work.
-
-## When to Run
-
-Run this workflow after:
-- Adding new metrics or logging
-- Creating dashboards or alerts
-- Writing incident runbooks
-- Updating health checks
-- Discovering observability insights
-
-## Workflow
-
-### Step 1: Load Current Expertise
-```
-Read: packages/cli/src/core/experts/monitoring/expertise.yaml
-```
-
-### Step 2: Analyze Changes Made
-
-Review what was just implemented:
-1. What new metrics were added?
-2. What logging changes were made?
-3. What dashboards or alerts were created?
-4. What runbooks were written?
-5. What was learned during implementation?
-
-### Step 3: Generate Diff
-
-Identify what's new or changed:
-- New metric types or names
-- New logging patterns
-- New alert rules
-- SLO changes
-- Health check updates
-
-### Step 4: Update Expertise
-
-Add a new learning entry:
-```yaml
-learnings:
-  - date: YYYY-MM-DD
-    insight: "Brief description of what was learned"
-    files_affected:
-      - path/to/file1
-      - path/to/file2
-    context: "Story or task context"
-```
-
-Update other sections as needed:
-- Add new files to `files:`
-- Add new patterns to `patterns:`
-- Update `slo_targets:` if changed
-
-### Step 5: Validate Update
-
-Ensure the expertise file:
-- Is valid YAML
-- Has updated `last_updated` date
-- All alerts have linked runbooks
-- SLO targets are current
-
-## Learning Categories
-
-### New Metrics
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Added cache_hit_ratio gauge metric for Redis monitoring"
-    files_affected:
-      - src/metrics/cache.ts
-      - monitoring/dashboards/cache.json
-    context: "US-0080: Add cache monitoring"
-```
-
-### Logging Improvements
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Added trace_id propagation through async context"
-    files_affected:
-      - src/logging/context.ts
-      - src/logging/middleware.ts
-    context: "US-0081: Improve distributed tracing"
-```
-
-### Alert Tuning
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Error rate alert needs 5-minute window to reduce noise from transient spikes"
-    files_affected: [monitoring/alerts/api-alerts.yaml]
-    context: "US-0082: Reduce alert fatigue"
-```
-
-### Runbook Additions
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Created runbook for database connection pool exhaustion"
-    files_affected: [monitoring/runbooks/db-pool-exhausted.md]
-    context: "US-0083: Incident response preparation"
-```
-
-### SLO Updates
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Updated latency SLO from p95 <200ms to p95 <150ms after optimization"
-    files_affected:
-      - monitoring/slo/api-slo.yaml
-      - docs/slo/api-targets.md
-    context: "US-0084: Tighten SLO after performance work"
-```
-
-## Example Update
-
-Before work:
-```yaml
-slo_targets:
-  availability: "99.9%"
-  latency_p95: "<200ms"
-```
-
-After performance optimization:
-```yaml
-slo_targets:
-  availability: "99.9%"
-  latency_p50: "<50ms"
-  latency_p95: "<150ms"
-  latency_p99: "<300ms"
-
-learnings:
-  - date: 2025-12-16
-    insight: "After caching optimization, can tighten latency SLOs significantly"
-    files_affected:
-      - monitoring/slo/api-slo.yaml
-      - monitoring/dashboards/slo-dashboard.json
-    context: "US-0085: Update SLOs post-optimization"
-```
-
-## Key Principles
-
-1. **Alert Hygiene**: Note any alert tuning to reduce noise
-2. **Runbook Links**: Every alert needs a runbook reference
-3. **SLO Evolution**: Track SLO changes over time
-4. **Correlation IDs**: Always ensure tracing context is preserved
-5. **Security**: Never log sensitive data (PII, secrets)