agileflow 3.4.2 → 4.0.0-alpha.1

package/src/core/experts/research/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/security/expertise.yaml

@@ -1,117 +0,0 @@
-domain: security
-last_updated: 2025-12-21
-version: 1.1
-
-# AgileFlow-specific security patterns (learned from actual codebase)
-files:
-  auth:
-    - path: src/auth/
-      purpose: Authentication implementation
-    - path: src/middleware/auth.ts
-      purpose: Auth middleware
-    - path: src/lib/jwt.ts
-      purpose: JWT handling
-    - path: src/lib/session.ts
-      purpose: Session management
-
-  security_config:
-    - path: .env.example
-      purpose: Environment variable template (no secrets!)
-    - path: src/config/cors.ts
-      purpose: CORS configuration
-    - path: src/middleware/rateLimit.ts
-      purpose: Rate limiting rules
-    - path: src/middleware/csrf.ts
-      purpose: CSRF protection
-
-  # AgileFlow-specific secret management
-  secrets_management:
-    - path: .npmrc
-      purpose: "npm token (GITIGNORED - never commit)"
-      note: "Contains NPM_TOKEN for publishing"
-    - path: .env
-      purpose: "Environment secrets (GITIGNORED)"
-
-  gitignored_security:
-    - path: .gitignore
-      purpose: "Ensures sensitive files are not committed"
-      sensitive_patterns:
-        - ".npmrc"
-        - ".env"
-        - "CLAUDE.md (internal docs)"
-
-  compliance:
-    - path: docs/03-decisions/
-      purpose: Security ADRs
-    - path: SECURITY.md
-      purpose: Security policy and disclosure
-    - path: docs/10-research/*security*.md
-      purpose: Security research notes
-
-relationships:
-  - component: authentication
-    patterns: [JWT, OAuth, Session]
-    files: [src/auth/, src/middleware/auth.ts]
-  - component: authorization
-    patterns: [RBAC, ABAC]
-    files: [src/middleware/authorize.ts]
-  - component: input_validation
-    patterns: [zod, yup, joi]
-    files: [src/validators/]
-  - component: encryption
-    patterns: [bcrypt, crypto]
-    files: [src/lib/crypto.ts]
-  - component: secrets
-    storage: "GitHub Secrets for CI, local gitignored files"
-    files: [".npmrc", ".env"]
-
-patterns:
-  - name: JWT with Refresh Tokens
-    description: "Short-lived access token, long-lived refresh token"
-  - name: RBAC
-    description: "Role-based access control for coarse permissions"
-  - name: Input Validation
-    description: "Whitelist valid inputs, validate type/length/format"
-  - name: Defense in Depth
-    description: "Multiple layers of security controls"
-
-  - name: GitHub Secrets for CI
-    description: "Store tokens in GitHub Secrets, reference in workflows"
-    location: ".github/workflows/npm-publish.yml"
-    example: "NPM_TOKEN stored in GitHub Secrets, used for npm publish"
-
-  - name: Gitignored Secrets
-    description: "Local secret files excluded from version control"
-    location: ".gitignore"
-    files: [".npmrc", ".env", "CLAUDE.md"]
-
-  - name: No Hardcoded Secrets
-    description: "Never commit tokens, passwords, or API keys"
-    violation_examples:
-      - "Hardcoded NPM_TOKEN in code"
-      - "API keys in JavaScript files"
-      - "Passwords in config files"
-
-conventions:
-  - "Never hardcode secrets in code"
-  - "Always validate user input on backend"
-  - "Use parameterized queries (no string concat)"
-  - "Hash passwords with bcrypt (cost 10+)"
-  - "JWT signed with RS256 or HS256"
-  - "HTTPS required in production"
-  - "Security headers: HSTS, CSP, X-Frame-Options"
-  - "Store CI secrets in GitHub Secrets (NPM_TOKEN)"
-  - "Gitignore sensitive files (.npmrc, .env)"
-  - "Warn user if they try to commit credentials files"
-
-# OWASP top 10 omitted - models know this standard
-
-# Learnings (trimmed - keep 2 most actionable)
-learnings:
-  - date: 2025-12-21
-    context: "Secret management"
-    insight: "NPM_TOKEN in GitHub Secrets for CI. Gitignored: .npmrc, CLAUDE.md. Never commit tokens."
-
-  - date: 2025-12-21
-    context: "Commit security"
-    insight: "CLAUDE.md forbids committing .env, credentials.json. Warn user if they request it. No AI attribution in commits."

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

@@ -1,77 +0,0 @@
----
-description: Ask questions about security - uses expertise for fast, accurate answers
-argument-hint: <your question>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/security/expertise.yaml
----
-
-# Security Expert - Question
-
-You are an expert on the security 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:
-- Authentication implementation locations
-- Authorization patterns and middleware
-- Security configuration files
-- OWASP Top 10 awareness
-- 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 each relevant piece of expertise:
-1. Check if auth files exist at expected locations
-2. Verify security middleware is configured
-3. Check for security headers and CORS
-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
-3. Include secure code examples
-4. Flag potential security risks
-5. If you don't know, say so (don't guess)
-
-## Security-Specific Knowledge
-
-**Authentication Patterns**:
-- JWT: tokens, refresh, validation
-- OAuth: providers, flows, tokens
-- Session: cookies, storage, invalidation
-
-**Common Questions I Can Answer**:
-- How is authentication implemented?
-- What authorization pattern is used?
-- Where is input validation?
-- How are secrets managed?
-- Is this code secure? (review)
-- How do I add rate limiting?
-
-## Security Awareness
-
-**Always Consider**:
-- OWASP Top 10 vulnerabilities
-- Input validation (SQL injection, XSS)
-- Authentication bypass risks
-- Authorization escalation
-- Sensitive data exposure
-
-## Anti-Patterns to Avoid
-
-- Reading expertise but ignoring it
-- Trusting expertise blindly without validation
-- Recommending security patterns without checking existing implementation
-- Suggesting security relaxations (disabling HTTPS, removing rate limits)
-- Giving vague security advice
-
-## Question
-
-{{argument}}

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

@@ -1,102 +0,0 @@
----
-description: Update security expertise after making changes
-argument-hint: [optional context about what changed]
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/security/expertise.yaml
----
-
-# Security Expert - Self-Improve
-
-You are updating your mental model (expertise file) to reflect changes in the codebase. 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:
-- Authentication implementation
-- Authorization patterns
-- Security configurations
-- OWASP awareness
-
-### Step 2: Analyze What Changed
-Identify changes using one of these methods:
-
-**If git diff available:**
-```bash
-git diff HEAD~1 --name-only | grep -E "(auth|security|middleware|jwt|session|crypt|valid)"
-```
-
-**If context provided:**
-Use the argument/context to understand what changed.
-
-**If neither:**
-Compare expertise file against actual codebase state.
-
-### Step 3: Update Expertise
-
-**Update `files` section if:**
-- New auth files created
-- Security middleware added
-- Config files relocated
-
-**Update `relationships` section if:**
-- New auth patterns introduced
-- Authorization flow changed
-- Validation approach updated
-
-**Update `patterns` section if:**
-- New security patterns implemented
-- Better validation approaches
-- New encryption methods
-
-**Update `conventions` section if:**
-- Security standards updated
-- New compliance requirements
-- Header policies changed
-
-### Step 4: Add Learnings Entry
-**ALWAYS** add a new learnings entry:
-
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Brief description of what was learned"
-    files_affected:
-      - src/auth/jwt.ts
-      - src/middleware/auth.ts
-    context: "Feature: {{argument}}"
-```
-
-### Step 5: Validate Updated Expertise
-Before saving:
-- [ ] All auth file paths exist
-- [ ] Security patterns accurate
-- [ ] `last_updated` is current
-- [ ] No duplicate entries
-- [ ] File stays focused (<200 lines)
-
-### Step 6: Save Expertise
-Write the updated expertise.yaml file.
-
-## Security-Specific Updates
-
-**After auth changes:**
-- Update auth files section
-- Document new patterns
-- Note any security improvements
-
-**After fixing vulnerabilities:**
-- Document CVE in learnings
-- Update relevant patterns
-- Add prevention to conventions
-
-**After security review:**
-- Document findings
-- Update OWASP awareness
-- Add any new patterns discovered
-
-## Context
-
-{{argument}}

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

@@ -1,152 +0,0 @@
----
-description: Plan, build, and improve security feature with expertise-driven workflow
-argument-hint: <security feature description>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/security/expertise.yaml
----
-
-# Security Expert: Plan → Build → Self-Improve
-
-You are executing a complete security feature implementation with automatic knowledge capture.
-
-## 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:
-- Authentication implementation locations
-- Authorization patterns
-- Security configuration
-- OWASP awareness
-
-### 1.2 Validate Against Codebase
-Before planning, verify your expertise:
-```bash
-ls -la src/auth/ src/middleware/auth* src/lib/jwt* 2>/dev/null || true
-grep -r "bcrypt\|jwt\|session" src/ --include="*.ts" -l 2>/dev/null || true
-```
-
-### 1.3 Create Implementation Plan
-```markdown
-## Security Implementation Plan
-
-### Security Changes
-1. [file path] - [change description]
-   - OWASP concerns: [list]
-   - Validation: [approach]
-   - Tests: [security tests needed]
-
-### Pattern to Follow
-[Reference security pattern from expertise]
-
-### Threat Model
-- Assets protected: [list]
-- Attack vectors: [list]
-- Mitigations: [list]
-
-### Validation
-- [ ] No hardcoded secrets
-- [ ] Input validation in place
-- [ ] Auth/authz enforced
-- [ ] Security tests pass
-```
-
----
-
-## Step 2: BUILD (Execute Plan)
-
-### 2.1 Pre-Build Verification
-- Check for existing security implementations
-- Verify no secrets in codebase
-- Review OWASP Top 10 for this feature
-
-### 2.2 Execute the Plan
-```typescript
-// Follow security patterns from expertise
-import { validateInput } from '@/lib/validation';
-import { requireAuth, requireRole } from '@/middleware/auth';
-
-// Always validate input
-const sanitizedInput = validateInput(userInput, schema);
-
-// Always check authorization
-if (!user.hasPermission('resource:action')) {
-  throw new ForbiddenError();
-}
-```
-
-### 2.3 Capture Changes
-```bash
-git diff --name-only | grep -E "(auth|security|middleware|valid)"
-git diff HEAD
-```
-
-### 2.4 Validate Build
-- Run security tests
-- Check for hardcoded secrets: `grep -r "password\|secret\|apikey" src/`
-- Run dependency audit: `npm audit`
-- Verify auth flows work correctly
-
-**On Failure**: Stop. Do NOT proceed to self-improve.
-
----
-
-## Step 3: SELF-IMPROVE (Update Expertise)
-
-**ONLY run if Step 2 succeeded.**
-
-### 3.1 Analyze What Changed
-- New auth files added
-- Security middleware updated
-- Validation patterns added
-- Configuration changes
-
-### 3.2 Update Expertise File
-Read and update `{{EXPERTISE_FILE}}`:
-
-**Update `files` if:**
-- New auth files created
-- Security middleware added
-
-**Update `relationships` if:**
-- Auth patterns changed
-- Authorization flow updated
-- New validation approach
-
-**Update `patterns` if:**
-- New security pattern implemented
-- Better validation approach
-- Improved encryption
-
-**Update `conventions` if:**
-- Security standards changed
-- New compliance requirements
-- Header policies updated
-
-### 3.3 Add Learnings Entry
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Added [security feature] for [protection]"
-    files_affected:
-      - src/auth/jwt.ts
-    context: "Feature: {{argument}}"
-```
-
-### 3.4 Validate and Save
-- [ ] All paths exist
-- [ ] `last_updated` current
-- [ ] No duplicates
-
----
-
-## Security Feature Request
-
-{{argument}}

package/src/core/experts/templates/expertise-template.yaml

@@ -1,67 +0,0 @@
-# Expertise Template - Mental Model for {{DOMAIN}} Expert
-#
-# This file represents the agent's "mental model" of the {{DOMAIN}} domain.
-# It is NOT a source of truth - the actual code is always the source of truth.
-# This is working memory that helps the agent work faster and more accurately.
-#
-# Usage:
-# 1. Copy this template to experts/{{domain}}/expertise.yaml
-# 2. Fill in domain-specific knowledge
-# 3. Let the self-improve prompt update it over time
-
-domain: {{DOMAIN}}
-last_updated: {{ISO_DATE}}
-version: 1.0
-
-# Key files this expert needs to know about
-# The agent reads these FIRST before exploring the codebase
-files:
-  # Group files by category relevant to your domain
-  # Examples: schemas, routes, components, migrations, etc.
-  primary:
-    - path: src/{{domain}}/
-      purpose: Main {{domain}} code location
-      key_exports: []
-      conventions: ""
-
-  secondary:
-    - path: src/lib/{{domain}}/
-      purpose: Shared {{domain}} utilities
-      key_exports: []
-
-# Relationships between entities in this domain
-# Helps agent understand data flow and dependencies
-relationships: []
-  # Example for database domain:
-  # - parent: users
-  #   child: posts
-  #   type: one-to-many
-  #   cascade: delete
-  #
-  # Example for UI domain:
-  # - component: Button
-  #   variants: [default, primary, destructive]
-  #   location: src/components/ui/button.tsx
-
-# Patterns used in this domain
-# Recurring approaches the agent should follow
-patterns: []
-  # - name: "Pattern Name"
-  #   description: "What this pattern does and when to use it"
-  #   location: "Where to find examples"
-  #   applies_to: [list, of, contexts]
-
-# Conventions and rules for this domain
-# The agent should follow these when making changes
-conventions: []
-  # - "Naming convention: lowercase_snake_case"
-  # - "All files must have corresponding test"
-  # - "Use TypeScript strict mode"
-
-# Learnings accumulated over time
-# AUTO-UPDATED by self-improve prompt - do not edit manually
-learnings: []
-  # - date: 2025-12-16
-  #   insight: "Discovered that X pattern works better than Y"
-  #   files_affected: [src/file1.ts, src/file2.ts]
-  #   context: "While implementing US-0001"