maestro-flow 0.1.0 → 0.1.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "maestro-flow",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Workflow orchestration CLI with MCP endpoint support and extensible architecture",
   "type": "module",
   "bin": {
@@ -38,12 +38,14 @@
     "node": ">=18.0.0"
   },
   "dependencies": {
+    "@anthropic-ai/claude-agent-sdk": "^0.2.77",
     "@hono/node-server": "^1.14.0",
     "@inquirer/prompts": "^8.3.2",
     "@modelcontextprotocol/sdk": "^1.12.1",
     "chokidar": "^4.0.0",
     "commander": "^13.1.0",
     "hono": "^4.7.0",
+    "node-cron": "^4.2.1",
     "ws": "^8.19.0",
     "zod": "^3.25.76"
   },

package/templates/cli/prompts/rules-tech-rules-agent-prompt.txt

@@ -1,89 +1,89 @@
-# Tech Stack Rules Generation Agent Prompt
-
-## Context Variables
-- {TECH_STACK_NAME}: Normalized tech stack name (e.g., "typescript-react")
-- {PRIMARY_LANG}: Primary language (e.g., "typescript")
-- {FILE_EXT}: File extension pattern (e.g., "{ts,tsx}")
-- {FRAMEWORK_TYPE}: frontend | backend | fullstack | library
-- {COMPONENTS}: Array of tech components
-- {OUTPUT_DIR}: .claude/rules/tech/{TECH_STACK_NAME}/
-
-## Agent Instructions
-
-Generate path-conditional rules for Claude Code automatic loading.
-
-### Step 1: Execute Exa Research
-
-Run 4-6 parallel queries based on tech stack:
-
-**Base Queries** (always execute):
-```
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} best practices principles 2025", tokensNum: 8000)
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} implementation patterns examples", tokensNum: 7000)
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} testing strategies conventions", tokensNum: 5000)
-mcp__exa__web_search_exa(query: "{PRIMARY_LANG} configuration setup 2025", numResults: 5)
-```
-
-**Component Queries** (for each framework in COMPONENTS):
-```
-mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} {component} integration patterns", tokensNum: 5000)
-```
-
-### Step 2: Read Rule Templates
-
-Read each template file before generating content:
-```
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-core.txt)
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-patterns.txt)
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-testing.txt)
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-config.txt)
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-api.txt)       # Only if backend/fullstack
-Read(~/.ccw/workflows/cli-templates/prompts/rules/rule-components.txt) # Only if frontend/fullstack
-```
-
-### Step 3: Generate Rule Files
-
-Create directory and write files:
-```bash
-mkdir -p "{OUTPUT_DIR}"
-```
-
-**Always Generate**:
-- core.md (from rule-core.txt template)
-- patterns.md (from rule-patterns.txt template)
-- testing.md (from rule-testing.txt template)
-- config.md (from rule-config.txt template)
-
-**Conditional**:
-- api.md: Only if FRAMEWORK_TYPE == 'backend' or 'fullstack'
-- components.md: Only if FRAMEWORK_TYPE == 'frontend' or 'fullstack'
-
-### Step 4: Write Metadata
-
-```json
-{
-  "tech_stack": "{TECH_STACK_NAME}",
-  "primary_lang": "{PRIMARY_LANG}",
-  "file_ext": "{FILE_EXT}",
-  "framework_type": "{FRAMEWORK_TYPE}",
-  "components": ["{COMPONENTS}"],
-  "generated_at": "{ISO_TIMESTAMP}",
-  "source": "exa-research",
-  "files_generated": ["core.md", "patterns.md", "testing.md", "config.md", ...]
-}
-```
-
-### Step 5: Report Completion
-
-Provide summary:
-- Files created with their path patterns
-- Exa queries executed (count)
-- Sources consulted (count)
-
-## Critical Requirements
-
-1. Every .md file MUST start with `paths` YAML frontmatter
-2. Use {FILE_EXT} consistently across all rule files
-3. Synthesize Exa research into actionable rules
-4. Include code examples from Exa sources
-5. Keep each file focused on its specific domain
+# Tech Stack Rules Generation Agent Prompt
+
+## Context Variables
+- {TECH_STACK_NAME}: Normalized tech stack name (e.g., "typescript-react")
+- {PRIMARY_LANG}: Primary language (e.g., "typescript")
+- {FILE_EXT}: File extension pattern (e.g., "{ts,tsx}")
+- {FRAMEWORK_TYPE}: frontend | backend | fullstack | library
+- {COMPONENTS}: Array of tech components
+- {OUTPUT_DIR}: .claude/rules/tech/{TECH_STACK_NAME}/
+
+## Agent Instructions
+
+Generate path-conditional rules for Claude Code automatic loading.
+
+### Step 1: Execute Exa Research
+
+Run 4-6 parallel queries based on tech stack:
+
+**Base Queries** (always execute):
+```
+mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} best practices principles 2025", tokensNum: 8000)
+mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} implementation patterns examples", tokensNum: 7000)
+mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} testing strategies conventions", tokensNum: 5000)
+mcp__exa__web_search_exa(query: "{PRIMARY_LANG} configuration setup 2025", numResults: 5)
+```
+
+**Component Queries** (for each framework in COMPONENTS):
+```
+mcp__exa__get_code_context_exa(query: "{PRIMARY_LANG} {component} integration patterns", tokensNum: 5000)
+```
+
+### Step 2: Read Rule Templates
+
+Read each template file before generating content:
+```
+Read(~/.maestro/templates/cli/prompts/rules/rule-core.txt)
+Read(~/.maestro/templates/cli/prompts/rules/rule-patterns.txt)
+Read(~/.maestro/templates/cli/prompts/rules/rule-testing.txt)
+Read(~/.maestro/templates/cli/prompts/rules/rule-config.txt)
+Read(~/.maestro/templates/cli/prompts/rules/rule-api.txt)       # Only if backend/fullstack
+Read(~/.maestro/templates/cli/prompts/rules/rule-components.txt) # Only if frontend/fullstack
+```
+
+### Step 3: Generate Rule Files
+
+Create directory and write files:
+```bash
+mkdir -p "{OUTPUT_DIR}"
+```
+
+**Always Generate**:
+- core.md (from rule-core.txt template)
+- patterns.md (from rule-patterns.txt template)
+- testing.md (from rule-testing.txt template)
+- config.md (from rule-config.txt template)
+
+**Conditional**:
+- api.md: Only if FRAMEWORK_TYPE == 'backend' or 'fullstack'
+- components.md: Only if FRAMEWORK_TYPE == 'frontend' or 'fullstack'
+
+### Step 4: Write Metadata
+
+```json
+{
+  "tech_stack": "{TECH_STACK_NAME}",
+  "primary_lang": "{PRIMARY_LANG}",
+  "file_ext": "{FILE_EXT}",
+  "framework_type": "{FRAMEWORK_TYPE}",
+  "components": ["{COMPONENTS}"],
+  "generated_at": "{ISO_TIMESTAMP}",
+  "source": "exa-research",
+  "files_generated": ["core.md", "patterns.md", "testing.md", "config.md", ...]
+}
+```
+
+### Step 5: Report Completion
+
+Provide summary:
+- Files created with their path patterns
+- Exa queries executed (count)
+- Sources consulted (count)
+
+## Critical Requirements
+
+1. Every .md file MUST start with `paths` YAML frontmatter
+2. Use {FILE_EXT} consistently across all rule files
+3. Synthesize Exa research into actionable rules
+4. Include code examples from Exa sources
+5. Keep each file focused on its specific domain

package/templates/cli/prompts/workflow-codex-feasibility-validation.txt

@@ -1,176 +1,176 @@
-Validate technical feasibility and identify implementation risks for proposed solution design.
-
-## CORE CHECKLIST ⚡
-□ Read context-package.json and gemini-solution-design.md
-□ Assess complexity, validate technology choices
-□ Evaluate performance and security implications
-□ Focus on TECHNICAL FEASIBILITY and RISK ASSESSMENT
-□ Write output to specified .workflow/active/{session_id}/.process/ path
-
-## PREREQUISITE ANALYSIS
-
-### Required Input Files
-1. **context-package.json**: Task requirements, source files, tech stack
-2. **gemini-solution-design.md**: Proposed solution design and architecture
-3. **workflow-session.json**: Session state and context
-4. **CLAUDE.md**: Project standards and conventions
-
-### Analysis Dependencies
-- Review Gemini's proposed solution design
-- Validate against actual codebase capabilities
-- Assess implementation complexity realistically
-- Identify gaps between design and execution
-
-## REQUIRED VALIDATION
-
-### 1. Feasibility Assessment
-- **Complexity Rating**: Rate technical complexity (1-5 scale)
-  - 1: Trivial - straightforward implementation
-  - 2: Simple - well-known patterns
-  - 3: Moderate - some challenges
-  - 4: Complex - significant challenges
-  - 5: Very Complex - high risk, major unknowns
-
-- **Resource Requirements**: Estimate development effort
-  - Development time (hours/days/weeks)
-  - Required expertise level
-  - Infrastructure needs
-
-- **Technology Compatibility**: Validate proposed tech stack
-  - Framework version compatibility
-  - Library maturity and support
-  - Integration with existing systems
-
-### 2. Risk Analysis
-- **Implementation Risks**: Technical challenges and blockers
-  - Unknown implementation patterns
-  - Missing capabilities or APIs
-  - Breaking changes to existing code
-
-- **Integration Challenges**: System integration concerns
-  - Data format compatibility
-  - API contract changes
-  - Dependency conflicts
-
-- **Performance Concerns**: Performance and scalability risks
-  - Resource consumption (CPU, memory, I/O)
-  - Latency and throughput impact
-  - Caching and optimization needs
-
-- **Security Concerns**: Security vulnerabilities and threats
-  - Authentication/authorization gaps
-  - Data exposure risks
-  - Compliance violations
-
-### 3. Implementation Validation
-- **Development Approach**: Validate proposed implementation strategy
-  - Verify module dependency order
-  - Assess incremental development feasibility
-  - Evaluate testing approach
-
-- **Quality Standards**: Validate quality requirements
-  - Test coverage achievability
-  - Performance benchmark realism
-  - Documentation completeness
-
-- **Maintenance Implications**: Long-term sustainability
-  - Code maintainability assessment
-  - Technical debt evaluation
-  - Evolution and extensibility
-
-### 4. Code Target Verification
-Review Gemini's proposed code targets:
-- **Validate existing targets**: Confirm file:function:lines exist
-- **Assess new file targets**: Evaluate necessity and placement
-- **Identify missing targets**: Suggest additional modification points
-- **Refine target specifications**: Provide more precise line numbers if possible
-
-### 5. Recommendations
-- **Must-Have Requirements**: Critical requirements for success
-- **Optimization Opportunities**: Performance and quality improvements
-- **Security Controls**: Essential security measures
-- **Risk Mitigation**: Strategies to reduce identified risks
-
-## OUTPUT REQUIREMENTS
-
-### Output File
-**Path**: `.workflow/active/{session_id}/.process/codex-feasibility-validation.md`
-**Format**: Follow structure from `~/.ccw/workflows/cli-templates/prompts/workflow/analysis-results-structure.txt`
-
-### Required Sections
-Focus on these sections from the template:
-- Executive Summary (with Codex perspective)
-- Current State Analysis (validation findings)
-- Implementation Strategy (feasibility assessment)
-- Solution Optimization (risk mitigation)
-- Confidence Scores (technical feasibility focus)
-
-### Content Guidelines
-- ✅ Focus on technical feasibility and risk assessment
-- ✅ Verify code targets from Gemini's design
-- ✅ Provide concrete risk mitigation strategies
-- ✅ Quantify complexity and effort estimates
-- ❌ Do NOT create task breakdowns
-- ❌ Do NOT provide step-by-step implementation guides
-- ❌ Do NOT include code examples
-
-## VALIDATION METHODOLOGY
-
-### Complexity Scoring
-Rate each aspect on 1-5 scale:
-- Technical Complexity
-- Integration Complexity
-- Performance Risk
-- Security Risk
-- Maintenance Burden
-
-### Risk Classification
-- **LOW**: Minor issues, easily addressable
-- **MEDIUM**: Manageable challenges with clear mitigation
-- **HIGH**: Significant concerns requiring major mitigation
-- **CRITICAL**: Fundamental viability threats
-
-### Feasibility Judgment
-- **PROCEED**: Technically feasible with acceptable risk
-- **PROCEED_WITH_MODIFICATIONS**: Feasible but needs adjustments
-- **RECONSIDER**: High risk, major changes needed
-- **REJECT**: Not feasible with current approach
-
-## CONTEXT INTEGRATION
-
-### Gemini Analysis Integration
-- Review proposed architecture and design decisions
-- Validate assumptions and technology choices
-- Cross-check code targets against actual codebase
-- Assess realism of performance targets
-
-### Codebase Reality Check
-- Verify existing code capabilities
-- Identify actual technical constraints
-- Assess team skill compatibility
-- Evaluate infrastructure readiness
-
-### Session Context
-- Consider session history and previous decisions
-- Align with project architecture standards
-- Respect existing patterns and conventions
-
-## EXECUTION MODE
-
-**Mode**: Analysis with write permission for output file
-**CLI Tool**: Codex with --skip-git-repo-check -s danger-full-access
-**Timeout**: 60-90 minutes for complex tasks
-**Output**: Single file codex-feasibility-validation.md
-**Trigger**: Only for complex tasks (>6 modules)
-
-## VERIFICATION CHECKLIST ✓
-□ context-package.json and gemini-solution-design.md read
-□ Complexity rated on 1-5 scale with justification
-□ All risk categories assessed (technical, integration, performance, security)
-□ Code targets verified and refined
-□ Risk mitigation strategies provided
-□ Resource requirements estimated
-□ Final feasibility judgment (PROCEED/RECONSIDER/REJECT)
-□ Output written to .workflow/active/{session_id}/.process/codex-feasibility-validation.md
-
-Focus: Technical feasibility validation with realistic risk assessment and mitigation strategies.
+Validate technical feasibility and identify implementation risks for proposed solution design.
+
+## CORE CHECKLIST ⚡
+□ Read context-package.json and gemini-solution-design.md
+□ Assess complexity, validate technology choices
+□ Evaluate performance and security implications
+□ Focus on TECHNICAL FEASIBILITY and RISK ASSESSMENT
+□ Write output to specified .workflow/active/{session_id}/.process/ path
+
+## PREREQUISITE ANALYSIS
+
+### Required Input Files
+1. **context-package.json**: Task requirements, source files, tech stack
+2. **gemini-solution-design.md**: Proposed solution design and architecture
+3. **workflow-session.json**: Session state and context
+4. **CLAUDE.md**: Project standards and conventions
+
+### Analysis Dependencies
+- Review Gemini's proposed solution design
+- Validate against actual codebase capabilities
+- Assess implementation complexity realistically
+- Identify gaps between design and execution
+
+## REQUIRED VALIDATION
+
+### 1. Feasibility Assessment
+- **Complexity Rating**: Rate technical complexity (1-5 scale)
+  - 1: Trivial - straightforward implementation
+  - 2: Simple - well-known patterns
+  - 3: Moderate - some challenges
+  - 4: Complex - significant challenges
+  - 5: Very Complex - high risk, major unknowns
+
+- **Resource Requirements**: Estimate development effort
+  - Development time (hours/days/weeks)
+  - Required expertise level
+  - Infrastructure needs
+
+- **Technology Compatibility**: Validate proposed tech stack
+  - Framework version compatibility
+  - Library maturity and support
+  - Integration with existing systems
+
+### 2. Risk Analysis
+- **Implementation Risks**: Technical challenges and blockers
+  - Unknown implementation patterns
+  - Missing capabilities or APIs
+  - Breaking changes to existing code
+
+- **Integration Challenges**: System integration concerns
+  - Data format compatibility
+  - API contract changes
+  - Dependency conflicts
+
+- **Performance Concerns**: Performance and scalability risks
+  - Resource consumption (CPU, memory, I/O)
+  - Latency and throughput impact
+  - Caching and optimization needs
+
+- **Security Concerns**: Security vulnerabilities and threats
+  - Authentication/authorization gaps
+  - Data exposure risks
+  - Compliance violations
+
+### 3. Implementation Validation
+- **Development Approach**: Validate proposed implementation strategy
+  - Verify module dependency order
+  - Assess incremental development feasibility
+  - Evaluate testing approach
+
+- **Quality Standards**: Validate quality requirements
+  - Test coverage achievability
+  - Performance benchmark realism
+  - Documentation completeness
+
+- **Maintenance Implications**: Long-term sustainability
+  - Code maintainability assessment
+  - Technical debt evaluation
+  - Evolution and extensibility
+
+### 4. Code Target Verification
+Review Gemini's proposed code targets:
+- **Validate existing targets**: Confirm file:function:lines exist
+- **Assess new file targets**: Evaluate necessity and placement
+- **Identify missing targets**: Suggest additional modification points
+- **Refine target specifications**: Provide more precise line numbers if possible
+
+### 5. Recommendations
+- **Must-Have Requirements**: Critical requirements for success
+- **Optimization Opportunities**: Performance and quality improvements
+- **Security Controls**: Essential security measures
+- **Risk Mitigation**: Strategies to reduce identified risks
+
+## OUTPUT REQUIREMENTS
+
+### Output File
+**Path**: `.workflow/active/{session_id}/.process/codex-feasibility-validation.md`
+**Format**: Follow structure from `~/.maestro/templates/cli/prompts/workflow/analysis-results-structure.txt`
+
+### Required Sections
+Focus on these sections from the template:
+- Executive Summary (with Codex perspective)
+- Current State Analysis (validation findings)
+- Implementation Strategy (feasibility assessment)
+- Solution Optimization (risk mitigation)
+- Confidence Scores (technical feasibility focus)
+
+### Content Guidelines
+- ✅ Focus on technical feasibility and risk assessment
+- ✅ Verify code targets from Gemini's design
+- ✅ Provide concrete risk mitigation strategies
+- ✅ Quantify complexity and effort estimates
+- ❌ Do NOT create task breakdowns
+- ❌ Do NOT provide step-by-step implementation guides
+- ❌ Do NOT include code examples
+
+## VALIDATION METHODOLOGY
+
+### Complexity Scoring
+Rate each aspect on 1-5 scale:
+- Technical Complexity
+- Integration Complexity
+- Performance Risk
+- Security Risk
+- Maintenance Burden
+
+### Risk Classification
+- **LOW**: Minor issues, easily addressable
+- **MEDIUM**: Manageable challenges with clear mitigation
+- **HIGH**: Significant concerns requiring major mitigation
+- **CRITICAL**: Fundamental viability threats
+
+### Feasibility Judgment
+- **PROCEED**: Technically feasible with acceptable risk
+- **PROCEED_WITH_MODIFICATIONS**: Feasible but needs adjustments
+- **RECONSIDER**: High risk, major changes needed
+- **REJECT**: Not feasible with current approach
+
+## CONTEXT INTEGRATION
+
+### Gemini Analysis Integration
+- Review proposed architecture and design decisions
+- Validate assumptions and technology choices
+- Cross-check code targets against actual codebase
+- Assess realism of performance targets
+
+### Codebase Reality Check
+- Verify existing code capabilities
+- Identify actual technical constraints
+- Assess team skill compatibility
+- Evaluate infrastructure readiness
+
+### Session Context
+- Consider session history and previous decisions
+- Align with project architecture standards
+- Respect existing patterns and conventions
+
+## EXECUTION MODE
+
+**Mode**: Analysis with write permission for output file
+**CLI Tool**: Codex with --skip-git-repo-check -s danger-full-access
+**Timeout**: 60-90 minutes for complex tasks
+**Output**: Single file codex-feasibility-validation.md
+**Trigger**: Only for complex tasks (>6 modules)
+
+## VERIFICATION CHECKLIST ✓
+□ context-package.json and gemini-solution-design.md read
+□ Complexity rated on 1-5 scale with justification
+□ All risk categories assessed (technical, integration, performance, security)
+□ Code targets verified and refined
+□ Risk mitigation strategies provided
+□ Resource requirements estimated
+□ Final feasibility judgment (PROCEED/RECONSIDER/REJECT)
+□ Output written to .workflow/active/{session_id}/.process/codex-feasibility-validation.md
+
+Focus: Technical feasibility validation with realistic risk assessment and mitigation strategies.