agileflow 3.4.3 → 4.0.0-alpha.10

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

@@ -1,184 +0,0 @@
----
-description: Plan, build, and improve {{DOMAIN}} feature with expertise-driven workflow
-argument-hint: <feature description>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/{{DOMAIN}}/expertise.yaml
-  DOMAIN_PATTERN: "{{DOMAIN_GLOB_PATTERN}}"
----
-
-# {{DOMAIN_TITLE}} Expert: Plan → Build → Self-Improve
-
-You are executing a complete feature implementation with automatic knowledge capture. This workflow ensures you leverage existing expertise, execute efficiently, and capture learnings for future tasks.
-
-## CRITICAL: Three-Step Workflow
-
-**You MUST follow this exact sequence. Do not skip steps.**
-
----
-
-## Step 1: PLAN (Expertise-Informed)
-
-### 1.1 Load Your Expertise
-Read your expertise file at `{{EXPERTISE_FILE}}` FIRST.
-
-Extract from it:
-- Relevant file locations for this feature
-- Existing patterns you should follow
-- Relationships to consider
-- Recent learnings that might apply
-
-### 1.2 Validate Against Codebase
-Before planning, verify your expertise is accurate:
-- Check that referenced files still exist
-- Confirm patterns match current code
-- Note any discrepancies
-
-### 1.3 Create Implementation Plan
-Based on validated expertise, create a specific plan:
-
-```markdown
-## Implementation Plan
-
-### Files to Create/Modify
-1. [exact file path] - [what changes]
-2. [exact file path] - [what changes]
-
-### Pattern to Follow
-[Reference specific pattern from expertise]
-
-### Dependencies
-[What must exist before this work]
-
-### Validation
-[How to verify the implementation works]
-```
-
-**Output**: A detailed plan with exact file paths and specific changes.
-
----
-
-## Step 2: BUILD (Execute Plan)
-
-### 2.1 Pre-Build Verification
-Before making changes:
-- Ensure all dependencies from plan exist
-- Verify you have the required permissions/access
-- Check for any blocking issues
-
-### 2.2 Execute the Plan
-Follow your implementation plan exactly:
-- Create/modify files in the specified order
-- Apply patterns consistently
-- Add appropriate tests if applicable
-
-### 2.3 Capture Changes
-After building, document what changed:
-
-```bash
-# Capture the diff for self-improve
-git diff --name-only
-git diff HEAD
-```
-
-### 2.4 Validate Build
-Verify the implementation:
-- Run relevant tests
-- Check for type/lint errors
-- Verify the feature works as intended
-
-**Output**: Working code changes with captured diff.
-
-**On Failure**: Stop and report the error. Do NOT proceed to self-improve.
-
----
-
-## Step 3: SELF-IMPROVE (Update Expertise)
-
-**ONLY run this step if Step 2 succeeded.**
-
-### 3.1 Analyze What Changed
-Review the git diff and identify:
-- New files added to your domain
-- New patterns introduced
-- Relationships created or changed
-- Conventions established
-
-### 3.2 Update Expertise File
-Read and update `{{EXPERTISE_FILE}}`:
-
-**Update `files` section if:**
-- New files were added
-- Files were moved or renamed
-
-**Update `relationships` section if:**
-- New entities or relationships created
-- Cardinality changed
-
-**Update `patterns` section if:**
-- New implementation patterns used
-- Better approaches discovered
-
-**Update `conventions` section if:**
-- New naming conventions applied
-- New structural conventions established
-
-### 3.3 Add Learnings Entry
-**ALWAYS** add a new learnings entry:
-
-```yaml
-learnings:
-  - date: {{TODAY}}
-    insight: "Brief description of what was learned"
-    files_affected:
-      - path/to/file1
-      - path/to/file2
-    context: "Feature: {{argument}}"
-```
-
-### 3.4 Validate Updated Expertise
-Before saving:
-- [ ] All file paths exist
-- [ ] Relationships match code
-- [ ] `last_updated` is current
-- [ ] No duplicates added
-- [ ] File stays focused (<200 lines)
-
-### 3.5 Save Expertise
-Write the updated expertise.yaml file.
-
----
-
-## Error Handling
-
-### If Plan Step Fails
-- Report what information is missing
-- Suggest how to resolve (update expertise, provide context)
-- Do NOT proceed to build
-
-### If Build Step Fails
-- Report the specific error
-- Capture partial progress if any
-- Do NOT proceed to self-improve
-- Consider if expertise needs correction
-
-### If Self-Improve Step Fails
-- Report what couldn't be updated
-- Save what you can
-- Build step is still valid
-
----
-
-## Context Protection Notes
-
-This workflow is designed for context efficiency:
-- **Orchestrator**: Passes minimal data between steps
-- **Sub-agents**: Each step can run in isolated context if needed
-- **Token efficiency**: Expertise file provides compressed knowledge
-
-For large features, consider running each step as a separate sub-agent invocation.
-
----
-
-## Feature Request
-
-{{argument}}

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

@@ -1,109 +0,0 @@
-# Database Expert - Mental Model
-#
-# This file represents the agent's understanding of database patterns.
-# It is populated with AgileFlow-generic knowledge and learns project-specific
-# details through the self-improve workflow.
-#
-# NOT a source of truth - always validate against actual code.
-
-domain: database
-last_updated: 2025-12-21
-version: 1.1
-
-# Key files the database expert needs to know
-files:
-  schemas:
-    - path: src/db/schema.ts
-      purpose: Database table definitions (if using Drizzle/TypeORM)
-      key_exports: [tables, relations]
-    - path: prisma/schema.prisma
-      purpose: Prisma schema file (if using Prisma)
-      conventions: "model declarations with @id, @relation"
-    - path: src/models/
-      purpose: Model definitions (if using Mongoose/Sequelize)
-      pattern: "<ModelName>.model.ts"
-
-  migrations:
-    - path: src/db/migrations/
-      purpose: Schema migration scripts
-      pattern: "YYYYMMDD_description.ts"
-    - path: prisma/migrations/
-      purpose: Prisma migration history
-      conventions: "Auto-generated, don't edit"
-
-  queries:
-    - path: src/db/queries/
-      purpose: Database query functions
-      conventions: "One file per table/resource"
-    - path: src/repositories/
-      purpose: Repository pattern implementations
-      pattern: "<Resource>Repository.ts"
-
-  seeds:
-    - path: src/db/seeds/
-      purpose: Seed data for development/testing
-      conventions: "Idempotent, can run multiple times"
-
-  # AgileFlow-specific JSON data stores (not SQL databases)
-  json_stores:
-    - path: docs/09-agents/status.json
-      purpose: "Story and epic tracking (AgileFlow's 'database')"
-      schema:
-        updated: "ISO timestamp"
-        epics: "Map of EP-ID to {title, status, completed, summary}"
-        stories: "Map of US-ID to {title, epic, owner, status, priority, estimate, depends_on, test_status}"
-    - path: docs/09-agents/bus/log.jsonl
-      purpose: "Agent coordination messages (append-only log)"
-      format: "JSON Lines, one message per line"
-    - path: docs/09-agents/archive/
-      purpose: "Archived completed stories by month"
-      pattern: "YYYY-MM.json"
-
-# Common database relationships
-# Self-improve will populate project-specific relationships
-relationships:
-  # AgileFlow JSON relationships
-  - parent: epics
-    child: stories
-    type: one-to-many
-    key: "stories[*].epic references epics[EP-ID]"
-  - parent: stories
-    child: test_cases
-    type: one-to-one
-    location: "docs/07-testing/test-cases/"
-
-# Database patterns the expert should recognize and follow
-patterns:
-  # Generic SQL patterns (soft deletes, timestamps, UUID, FK/index naming) omitted - models know these
-
-  - name: "JSON Single Source of Truth"
-    description: "AgileFlow uses status.json as primary data store"
-    location: docs/09-agents/status.json
-    pattern: "Read-modify-write with updated timestamp"
-
-  - name: "JSON Lines for Logs"
-    description: "Append-only logs use .jsonl format"
-    location: docs/09-agents/bus/log.jsonl
-    pattern: "One JSON object per line, append only"
-
-  - name: "Monthly Archival"
-    description: "Completed stories archived by month to keep status.json lean"
-    location: docs/09-agents/archive/YYYY-MM.json
-    script: scripts/archive-completed-stories.sh
-
-# Conventions (AgileFlow-specific only; generic SQL conventions omitted)
-conventions:
-  - "JSON stores: always update 'updated' timestamp when modifying"
-  - "JSON Lines: append only, never modify existing lines"
-  - "All queries use parameterized statements (prevent SQL injection)"
-  - "Migrations must be reversible (up and down)"
-
-# Learnings (trimmed - keep 2 most actionable)
-learnings:
-  - date: 2025-12-21
-    context: "AgileFlow data storage"
-    insight: "JSON files not SQL: status.json (epics EP-ID, stories US-ID with owner/status/priority/estimate/depends_on/test_status), log.jsonl (coordination), archive/ (historical)"
-
-  - date: 2025-12-21
-    context: "Archival pattern"
-    insight: "archive-completed-stories.sh moves done stories >7 days to archive/YYYY-MM.json. Keeps status.json performant."

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

@@ -1,74 +0,0 @@
----
-description: Ask questions about database - uses expertise for fast, accurate answers
-argument-hint: <your question about database schema, queries, migrations>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/database/expertise.yaml
----
-
-# Database Expert - Question
-
-You are an expert on the database domain for this codebase. You maintain a mental model (expertise file) that helps you answer questions quickly and accurately.
-
-## CRITICAL: Expertise-First Workflow
-
-**You MUST follow this workflow. Do not skip steps.**
-
-### Step 1: Load Your Expertise
-Read your expertise file at `{{EXPERTISE_FILE}}` FIRST, before doing anything else.
-
-This file contains:
-- Schema file locations (Prisma, Drizzle, TypeORM, etc.)
-- Migration directory structure
-- Query/repository file locations
-- Table relationships
-- Database patterns and conventions
-- Recent learnings from past work
-
-### Step 2: Validate Against Actual Code
-Your expertise is a mental model, NOT the source of truth. The code is always the source of truth.
-
-For the question being asked:
-1. Check if referenced tables/schemas exist where expertise says
-2. Verify relationships match actual foreign keys
-3. Confirm conventions are still followed
-4. Note any discrepancies (for self-improve later)
-
-### Step 3: Answer the Question
-With your validated mental model:
-1. Answer based on your expertise + validation
-2. Be specific - reference exact file paths and table names
-3. If expertise was wrong/stale, note it in your answer
-4. If you don't know, say so (don't guess about data structures)
-
-## Database-Specific Guidance
-
-### Schema Questions
-- Reference the exact schema file location from expertise
-- Show table structure with column types
-- Include relationships (foreign keys, cascades)
-
-### Query Questions
-- Reference query/repository file locations
-- Show actual query patterns used in codebase
-- Note N+1 risks or optimization opportunities
-
-### Migration Questions
-- Reference migration directory from expertise
-- Explain migration naming conventions
-- Warn about irreversible migrations
-
-### Performance Questions
-- Check for missing indexes
-- Identify N+1 query patterns
-- Suggest query optimizations
-
-## Key Principles
-
-- **Speed**: Use expertise to skip unnecessary searching
-- **Accuracy**: Always validate against actual schema files
-- **Honesty**: Acknowledge when expertise is stale
-- **Safety**: Never suggest data-losing operations without warnings
-
-## Question
-
-{{argument}}

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

@@ -1,121 +0,0 @@
----
-description: Update database expertise after making schema/query changes
-argument-hint: [optional context about what changed]
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/database/expertise.yaml
----
-
-# Database Expert - Self-Improve
-
-You are updating your mental model (expertise file) to reflect database changes. This keeps your expertise accurate and useful for future tasks.
-
-## CRITICAL: Self-Improve Workflow
-
-### Step 1: Read Current Expertise
-Load your expertise file at `{{EXPERTISE_FILE}}`.
-
-Understand what you currently know about:
-- Schema file locations
-- Migration patterns
-- Table relationships
-- Query conventions
-
-### Step 2: Analyze What Changed
-Identify database changes using:
-
-**Check git diff for database files:**
-```bash
-git diff HEAD~1 --name-only | grep -E "(schema|migration|model|db|prisma|drizzle)"
-```
-
-**Look for:**
-- New tables/models added
-- Schema modifications (new columns, changed types)
-- New migrations created
-- New query patterns introduced
-- Relationship changes (foreign keys added/removed)
-
-### Step 3: Update Expertise
-
-**Update `files` section if:**
-- New schema/model files were added
-- File locations changed
-- New query/repository files created
-
-**Update `relationships` section if:**
-- New foreign keys added
-- Tables now reference each other
-- Cascade behavior changed
-- Relationships removed
-
-Example addition:
-```yaml
-relationships:
-  - parent: users
-    child: sessions
-    type: one-to-many
-    cascade: delete
-    foreign_key: user_id
-```
-
-**Update `patterns` section if:**
-- New database patterns introduced
-- Existing patterns modified
-- Better approaches discovered
-
-**Update `conventions` section if:**
-- New naming conventions established
-- Conventions changed project-wide
-
-**ALWAYS add to `learnings` section:**
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Added sessions table for user login tracking"
-    files_affected:
-      - prisma/schema.prisma
-      - src/db/migrations/20251216_add_sessions.ts
-    context: "US-0042 - User session management"
-```
-
-### Step 4: Validate Updated Model
-After updating, verify:
-1. All schema file paths still exist
-2. Relationships match actual foreign keys in schema
-3. No orphaned references to deleted tables
-4. Conventions match what's actually in codebase
-
-### Step 5: Write Updated Expertise
-Save the updated expertise.yaml file with:
-- Updated `last_updated` timestamp
-- New/modified sections
-- New learnings entry
-
-## Database-Specific Rules
-
-### DO:
-- Track all table relationships
-- Note index additions
-- Record migration patterns
-- Document query optimizations discovered
-- Update when ORM/database type changes
-
-### DON'T:
-- Store actual data or credentials
-- Include sensitive column details
-- Keep references to dropped tables
-- Document one-off queries (only patterns)
-
-## Quality Checklist
-
-Before saving:
-- [ ] `last_updated` is today's date
-- [ ] All schema file paths verified
-- [ ] Relationships match actual foreign keys
-- [ ] New learnings entry added
-- [ ] No references to non-existent tables
-- [ ] Expertise stays focused (<200 lines)
-
-## Context
-
-{{argument}}