agentvibes 2.9.7 → 2.12.0

package/v4-backup/.bmad-core/utils/bmad-doc-template.md

@@ -1,327 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# BMad Document Template Specification
-
-## Overview
-
-BMad document templates are defined in YAML format to drive interactive document generation and agent interaction. Templates separate structure definition from content generation, making them both human and LLM-agent-friendly.
-
-## Template Structure
-
-```yaml
-template:
-  id: template-identifier
-  name: Human Readable Template Name
-  version: 1.0
-  output:
-    format: markdown
-    filename: default-path/to/{{filename}}.md
-    title: '{{variable}} Document Title'
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-
-sections:
-  - id: section-id
-    title: Section Title
-    instruction: |
-      Detailed instructions for the LLM on how to handle this section
-    # ... additional section properties
-```
-
-## Core Fields
-
-### Template Metadata
-
-- **id**: Unique identifier for the template
-- **name**: Human-readable name displayed in UI
-- **version**: Template version for tracking changes
-- **output.format**: Default "markdown" for document templates
-- **output.filename**: Default output file path (can include variables)
-- **output.title**: Document title (becomes H1 in markdown)
-
-### Workflow Configuration
-
-- **workflow.mode**: Default interaction mode ("interactive" or "yolo")
-- **workflow.elicitation**: Elicitation task to use ("advanced-elicitation")
-
-## Section Properties
-
-### Required Fields
-
-- **id**: Unique section identifier
-- **title**: Section heading text
-- **instruction**: Detailed guidance for LLM on handling this section
-
-### Optional Fields
-
-#### Content Control
-
-- **type**: Content type hint for structured sections
-- **template**: Fixed template text for section content
-- **item_template**: Template for repeatable items within section
-- **prefix**: Prefix for numbered items (e.g., "FR", "NFR")
-
-#### Behavior Flags
-
-- **elicit**: Boolean - Apply elicitation after section rendered
-- **repeatable**: Boolean - Section can be repeated multiple times
-- **condition**: String - Condition for including section (e.g., "has ui requirements")
-
-#### Agent Permissions
-
-- **owner**: String - Agent role that initially creates/populates this section
-- **editors**: Array - List of agent roles allowed to modify this section
-- **readonly**: Boolean - Section cannot be modified after initial creation
-
-#### Content Guidance
-
-- **examples**: Array of example content (not included in output)
-- **choices**: Object with choice options for common decisions
-- **placeholder**: Default placeholder text
-
-#### Structure
-
-- **sections**: Array of nested child sections
-
-## Supported Types
-
-### Content Types
-
-- **bullet-list**: Unordered list items
-- **numbered-list**: Ordered list with optional prefix
-- **paragraphs**: Free-form paragraph text
-- **table**: Structured table data
-- **code-block**: Code or configuration blocks
-- **template-text**: Fixed template with variable substitution
-- **mermaid**: Mermaid diagram with specified type and details
-
-### Special Types
-
-- **repeatable-container**: Container for multiple instances
-- **conditional-block**: Content shown based on conditions
-- **choice-selector**: Present choices to user
-
-## Advanced Features
-
-### Variable Substitution
-
-Use `{{variable_name}}` in titles, templates, and content:
-
-```yaml
-title: 'Epic {{epic_number}} {{epic_title}}'
-template: 'As a {{user_type}}, I want {{action}}, so that {{benefit}}.'
-```
-
-### Conditional Sections
-
-```yaml
-- id: ui-section
-  title: User Interface Design
-  condition: Project has UX/UI Requirements
-  instruction: Only include if project has UI components
-```
-
-### Choice Integration
-
-```yaml
-choices:
-  architecture: [Monolith, Microservices, Serverless]
-  testing: [Unit Only, Unit + Integration, Full Pyramid]
-```
-
-### Mermaid Diagrams
-
-```yaml
-- id: system-architecture
-  title: System Architecture Diagram
-  type: mermaid
-  instruction: Create a system architecture diagram showing key components and data flow
-  mermaid_type: flowchart
-  details: |
-    Show the following components:
-    - User interface layer
-    - API gateway
-    - Core services
-    - Database layer
-    - External integrations
-```
-
-**Supported mermaid_type values:**
-
-**Core Diagram Types:**
-
-- `flowchart` - Flow charts and process diagrams
-- `sequenceDiagram` - Sequence diagrams for interactions
-- `classDiagram` - Class relationship diagrams (UML)
-- `stateDiagram` - State transition diagrams
-- `erDiagram` - Entity relationship diagrams
-- `gantt` - Gantt charts for timelines
-- `pie` - Pie charts for data visualization
-
-**Advanced Diagram Types:**
-
-- `journey` - User journey maps
-- `mindmap` - Mindmaps for brainstorming
-- `timeline` - Timeline diagrams for chronological events
-- `quadrantChart` - Quadrant charts for data categorization
-- `xyChart` - XY charts (bar charts, line charts)
-- `sankey` - Sankey diagrams for flow visualization
-
-**Specialized Types:**
-
-- `c4Context` - C4 context diagrams (experimental)
-- `requirement` - Requirement diagrams
-- `packet` - Network packet diagrams
-- `block` - Block diagrams
-- `kanban` - Kanban boards
-
-### Agent Permissions Example
-
-```yaml
-- id: story-details
-  title: Story
-  owner: scrum-master
-  editors: [scrum-master]
-  readonly: false
-  sections:
-    - id: dev-notes
-      title: Dev Notes
-      owner: dev-agent
-      editors: [dev-agent]
-      readonly: false
-      instruction: Implementation notes and technical details
-    - id: qa-results
-      title: QA Results
-      owner: qa-agent
-      editors: [qa-agent]
-      readonly: true
-      instruction: Quality assurance test results
-```
-
-### Repeatable Sections
-
-```yaml
-- id: epic-details
-  title: Epic {{epic_number}} {{epic_title}}
-  repeatable: true
-  sections:
-    - id: story
-      title: Story {{epic_number}}.{{story_number}} {{story_title}}
-      repeatable: true
-      sections:
-        - id: criteria
-          title: Acceptance Criteria
-          type: numbered-list
-          item_template: '{{criterion_number}}: {{criteria}}'
-          repeatable: true
-```
-
-### Examples with Code Blocks
-
-````yaml
-examples:
-  - 'FR6: The system must authenticate users within 2 seconds'
-  - |
-    ```mermaid
-    sequenceDiagram
-        participant User
-        participant API
-        participant DB
-        User->>API: POST /login
-        API->>DB: Validate credentials
-        DB-->>API: User data
-        API-->>User: JWT token
-    ```
-  - |
-    **Architecture Decision Record**
-
-    **Decision**: Use PostgreSQL for primary database
-    **Rationale**: ACID compliance and JSON support needed
-    **Consequences**: Requires database management expertise
-````
-
-## Section Hierarchy
-
-Templates define the complete document structure starting with the first H2 - each level in is the next H#:
-
-```yaml
-sections:
-  - id: overview
-    title: Project Overview
-    sections:
-      - id: goals
-        title: Goals
-      - id: scope
-        title: Scope
-        sections:
-          - id: in-scope
-            title: In Scope
-          - id: out-scope
-            title: Out of Scope
-```
-
-## Processing Flow
-
-1. **Parse Template**: Load and validate YAML structure
-2. **Initialize Workflow**: Set interaction mode and elicitation
-3. **Process Sections**: Handle each section in order:
-   - Check conditions
-   - Apply instructions
-   - Generate content
-   - Handle choices and variables
-   - Apply elicitation if specified
-   - Process nested sections
-4. **Generate Output**: Create clean markdown document
-
-## Best Practices
-
-### Template Design
-
-- Keep instructions clear and specific
-- Use examples for complex content
-- Structure sections logically
-- Include all necessary guidance for LLM
-
-### Content Instructions
-
-- Be explicit about expected format
-- Include reasoning for decisions
-- Specify interaction patterns
-- Reference other documents when needed
-
-### Variable Naming
-
-- Use descriptive variable names
-- Follow consistent naming conventions
-- Document expected variable values
-
-### Examples Usage
-
-- Provide concrete examples for complex sections
-- Include both simple and complex cases
-- Use realistic project scenarios
-- Include code blocks and diagrams when helpful
-
-## Validation
-
-Templates should be validated for:
-
-- Valid YAML syntax
-- Required fields present
-- Consistent section IDs
-- Proper nesting structure
-- Valid variable references
-
-## Migration from Legacy
-
-When converting from markdown+frontmatter templates:
-
-1. Extract embedded `[[LLM:]]` instructions to `instruction` fields
-2. Convert `<<REPEAT>>` blocks to `repeatable: true` sections
-3. Extract `^^CONDITIONS^^` to `condition` fields
-4. Move `@{examples}` to `examples` arrays
-5. Convert `{{placeholders}}` to proper variable syntax
-
-This specification ensures templates are both human-readable and machine-processable while maintaining the flexibility needed for complex document generation.

package/v4-backup/.bmad-core/utils/workflow-management.md

@@ -1,71 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# Workflow Management
-
-Enables BMad orchestrator to manage and execute team workflows.
-
-## Dynamic Workflow Loading
-
-Read available workflows from current team configuration's `workflows` field. Each team bundle defines its own supported workflows.
-
-**Key Commands**:
-
-- `/workflows` - List workflows in current bundle or workflows folder
-- `/agent-list` - Show agents in current bundle
-
-## Workflow Commands
-
-### /workflows
-
-Lists available workflows with titles and descriptions.
-
-### /workflow-start {workflow-id}
-
-Starts workflow and transitions to first agent.
-
-### /workflow-status
-
-Shows current progress, completed artifacts, and next steps.
-
-### /workflow-resume
-
-Resumes workflow from last position. User can provide completed artifacts.
-
-### /workflow-next
-
-Shows next recommended agent and action.
-
-## Execution Flow
-
-1. **Starting**: Load definition → Identify first stage → Transition to agent → Guide artifact creation
-
-2. **Stage Transitions**: Mark complete → Check conditions → Load next agent → Pass artifacts
-
-3. **Artifact Tracking**: Track status, creator, timestamps in workflow_state
-
-4. **Interruption Handling**: Analyze provided artifacts → Determine position → Suggest next step
-
-## Context Passing
-
-When transitioning, pass:
-
-- Previous artifacts
-- Current workflow stage
-- Expected outputs
-- Decisions/constraints
-
-## Multi-Path Workflows
-
-Handle conditional paths by asking clarifying questions when needed.
-
-## Best Practices
-
-1. Show progress
-2. Explain transitions
-3. Preserve context
-4. Allow flexibility
-5. Track state
-
-## Agent Integration
-
-Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.

package/v4-backup/.bmad-core/workflows/brownfield-fullstack.yaml

@@ -1,298 +0,0 @@
-# <!-- Powered by BMAD™ Core -->
-workflow:
-  id: brownfield-fullstack
-  name: Brownfield Full-Stack Enhancement
-  description: >-
-    Agent workflow for enhancing existing full-stack applications with new features,
-    modernization, or significant changes. Handles existing system analysis and safe integration.
-  type: brownfield
-  project_types:
-    - feature-addition
-    - refactoring
-    - modernization
-    - integration-enhancement
-
-  sequence:
-    - step: enhancement_classification
-      agent: analyst
-      action: classify enhancement scope
-      notes: |
-        Determine enhancement complexity to route to appropriate path:
-        - Single story (< 4 hours) → Use brownfield-create-story task
-        - Small feature (1-3 stories) → Use brownfield-create-epic task  
-        - Major enhancement (multiple epics) → Continue with full workflow
-
-        Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
-
-    - step: routing_decision
-      condition: based_on_classification
-      routes:
-        single_story:
-          agent: pm
-          uses: brownfield-create-story
-          notes: "Create single story for immediate implementation. Exit workflow after story creation."
-        small_feature:
-          agent: pm
-          uses: brownfield-create-epic
-          notes: "Create focused epic with 1-3 stories. Exit workflow after epic creation."
-        major_enhancement:
-          continue: to_next_step
-          notes: "Continue with comprehensive planning workflow below."
-
-    - step: documentation_check
-      agent: analyst
-      action: check existing documentation
-      condition: major_enhancement_path
-      notes: |
-        Check if adequate project documentation exists:
-        - Look for existing architecture docs, API specs, coding standards
-        - Assess if documentation is current and comprehensive
-        - If adequate: Skip document-project, proceed to PRD
-        - If inadequate: Run document-project first
-
-    - step: project_analysis
-      agent: architect
-      action: analyze existing project and use task document-project
-      creates: brownfield-architecture.md (or multiple documents)
-      condition: documentation_inadequate
-      notes: "Run document-project to capture current system state, technical debt, and constraints. Pass findings to PRD creation."
-
-    - agent: pm
-      creates: prd.md
-      uses: brownfield-prd-tmpl
-      requires: existing_documentation_or_analysis
-      notes: |
-        Creates PRD for major enhancement. If document-project was run, reference its output to avoid re-analysis.
-        If skipped, use existing project documentation.
-        SAVE OUTPUT: Copy final prd.md to your project's docs/ folder.
-
-    - step: architecture_decision
-      agent: pm/architect
-      action: determine if architecture document needed
-      condition: after_prd_creation
-      notes: |
-        Review PRD to determine if architectural planning is needed:
-        - New architectural patterns → Create architecture doc
-        - New libraries/frameworks → Create architecture doc
-        - Platform/infrastructure changes → Create architecture doc
-        - Following existing patterns → Skip to story creation
-
-    - agent: architect
-      creates: architecture.md
-      uses: brownfield-architecture-tmpl
-      requires: prd.md
-      condition: architecture_changes_needed
-      notes: "Creates architecture ONLY for significant architectural changes. SAVE OUTPUT: Copy final architecture.md to your project's docs/ folder."
-
-    - agent: po
-      validates: all_artifacts
-      uses: po-master-checklist
-      notes: "Validates all documents for integration safety and completeness. May require updates to any document."
-
-    - agent: various
-      updates: any_flagged_documents
-      condition: po_checklist_issues
-      notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
-
-    - agent: po
-      action: shard_documents
-      creates: sharded_docs
-      requires: all_artifacts_in_project
-      notes: |
-        Shard documents for IDE development:
-        - Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
-        - Option B: Manual: Drag shard-doc task + docs/prd.md into chat
-        - Creates docs/prd/ and docs/architecture/ folders with sharded content
-
-    - agent: sm
-      action: create_story
-      creates: story.md
-      requires: sharded_docs_or_brownfield_docs
-      repeats: for_each_epic_or_enhancement
-      notes: |
-        Story creation cycle:
-        - For sharded PRD: @sm → *create (uses create-next-story)
-        - For brownfield docs: @sm → use create-brownfield-story task
-        - Creates story from available documentation
-        - Story starts in "Draft" status
-        - May require additional context gathering for brownfield
-
-    - agent: analyst/pm
-      action: review_draft_story
-      updates: story.md
-      requires: story.md
-      optional: true
-      condition: user_wants_story_review
-      notes: |
-        OPTIONAL: Review and approve draft story
-        - NOTE: story-review task coming soon
-        - Review story completeness and alignment
-        - Update story status: Draft → Approved
-
-    - agent: dev
-      action: implement_story
-      creates: implementation_files
-      requires: story.md
-      notes: |
-        Dev Agent (New Chat): @dev
-        - Implements approved story
-        - Updates File List with all changes
-        - Marks story as "Review" when complete
-
-    - agent: qa
-      action: review_implementation
-      updates: implementation_files
-      requires: implementation_files
-      optional: true
-      notes: |
-        OPTIONAL: QA Agent (New Chat): @qa → review-story
-        - Senior dev review with refactoring ability
-        - Fixes small issues directly
-        - Leaves checklist for remaining items
-        - Updates story status (Review → Done or stays Review)
-
-    - agent: dev
-      action: address_qa_feedback
-      updates: implementation_files
-      condition: qa_left_unchecked_items
-      notes: |
-        If QA left unchecked items:
-        - Dev Agent (New Chat): Address remaining items
-        - Return to QA for final approval
-
-    - step: repeat_development_cycle
-      action: continue_for_all_stories
-      notes: |
-        Repeat story cycle (SM → Dev → QA) for all epic stories
-        Continue until all stories in PRD are complete
-
-    - agent: po
-      action: epic_retrospective
-      creates: epic-retrospective.md
-      condition: epic_complete
-      optional: true
-      notes: |
-        OPTIONAL: After epic completion
-        - NOTE: epic-retrospective task coming soon
-        - Validate epic was completed correctly
-        - Document learnings and improvements
-
-    - step: workflow_end
-      action: project_complete
-      notes: |
-        All stories implemented and reviewed!
-        Project development phase complete.
-
-        Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
-
-  flow_diagram: |
-    ```mermaid
-    graph TD
-        A[Start: Brownfield Enhancement] --> B[analyst: classify enhancement scope]
-        B --> C{Enhancement Size?}
-        
-        C -->|Single Story| D[pm: brownfield-create-story]
-        C -->|1-3 Stories| E[pm: brownfield-create-epic]
-        C -->|Major Enhancement| F[analyst: check documentation]
-        
-        D --> END1[To Dev Implementation]
-        E --> END2[To Story Creation]
-        
-        F --> G{Docs Adequate?}
-        G -->|No| H[architect: document-project]
-        G -->|Yes| I[pm: brownfield PRD]
-        H --> I
-        
-        I --> J{Architecture Needed?}
-        J -->|Yes| K[architect: architecture.md]
-        J -->|No| L[po: validate artifacts]
-        K --> L
-        
-        L --> M{PO finds issues?}
-        M -->|Yes| N[Fix issues]
-        M -->|No| O[po: shard documents]
-        N --> L
-        
-        O --> P[sm: create story]
-        P --> Q{Story Type?}
-        Q -->|Sharded PRD| R[create-next-story]
-        Q -->|Brownfield Docs| S[create-brownfield-story]
-        
-        R --> T{Review draft?}
-        S --> T
-        T -->|Yes| U[review & approve]
-        T -->|No| V[dev: implement]
-        U --> V
-        
-        V --> W{QA review?}
-        W -->|Yes| X[qa: review]
-        W -->|No| Y{More stories?}
-        X --> Z{Issues?}
-        Z -->|Yes| AA[dev: fix]
-        Z -->|No| Y
-        AA --> X
-        Y -->|Yes| P
-        Y -->|No| AB{Retrospective?}
-        AB -->|Yes| AC[po: retrospective]
-        AB -->|No| AD[Complete]
-        AC --> AD
-
-        style AD fill:#90EE90
-        style END1 fill:#90EE90
-        style END2 fill:#90EE90
-        style D fill:#87CEEB
-        style E fill:#87CEEB
-        style I fill:#FFE4B5
-        style K fill:#FFE4B5
-        style O fill:#ADD8E6
-        style P fill:#ADD8E6
-        style V fill:#ADD8E6
-        style U fill:#F0E68C
-        style X fill:#F0E68C
-        style AC fill:#F0E68C
-    ```
-
-  decision_guidance:
-    when_to_use:
-      - Enhancement requires coordinated stories
-      - Architectural changes are needed
-      - Significant integration work required
-      - Risk assessment and mitigation planning necessary
-      - Multiple team members will work on related changes
-
-  handoff_prompts:
-    classification_complete: |
-      Enhancement classified as: {{enhancement_type}}
-      {{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
-      {{if small_feature}}: Creating focused epic with brownfield-create-epic task.
-      {{if major_enhancement}}: Continuing with comprehensive planning workflow.
-
-    documentation_assessment: |
-      Documentation assessment complete:
-      {{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
-      {{if inadequate}}: Running document-project to capture current system state before PRD.
-
-    document_project_to_pm: |
-      Project analysis complete. Key findings documented in:
-      - {{document_list}}
-      Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
-
-    pm_to_architect_decision: |
-      PRD complete and saved as docs/prd.md. 
-      Architectural changes identified: {{yes/no}}
-      {{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
-      {{if no}}: No architectural changes needed. Proceeding to validation.
-
-    architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
-
-    po_to_sm: |
-      All artifacts validated. 
-      Documentation type available: {{sharded_prd / brownfield_docs}}
-      {{if sharded}}: Use standard create-next-story task.
-      {{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
-
-    sm_story_creation: |
-      Creating story from {{documentation_type}}.
-      {{if missing_context}}: May need to gather additional context from user during story creation.
-
-    complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."