roast-ai 0.4.6 → 0.4.8

data/examples/no_model_fallback/generate_report_for_rb/prompt.md

@@ -1,3 +0,0 @@
-Generate a nicely formatted report based on the following metadata:
-
-<%= workflow.output[:analyze_patterns] %>

data/examples/no_model_fallback/sample.rb

@@ -1,42 +0,0 @@
-# frozen_string_literal: true
-
-# Sample Ruby file for testing interpolation in workflows
-
-class Calculator
-  def initialize
-    @memory = 0
-  end
-
-  def add(number)
-    @memory += number
-  end
-
-  def subtract(number)
-    @memory -= number
-  end
-
-  def multiply(number)
-    @memory *= number
-  end
-
-  def divide(number)
-    raise "Division by zero!" if number.zero?
-
-    @memory /= number
-  end
-
-  attr_reader :memory
-
-  def clear
-    @memory = 0
-  end
-end
-
-# Example usage
-if __FILE__ == $PROGRAM_NAME
-  calc = Calculator.new
-  calc.add(10)
-  calc.multiply(2)
-  calc.subtract(5)
-  puts "Result: #{calc.memory}"
-end

data/examples/no_model_fallback/workflow.yml

@@ -1,19 +0,0 @@
-name: no_model_fallback_example
-
-tools:
-  - Roast::Tools::ReadFile
-
-steps:
-  - analyze_file
-  - analyze_patterns
-  - generate_report_for_{{File.extname(workflow.file).sub('.', '')}}
-  - '$(echo "Processing completed for file: {{File.basename(workflow.file)}}")'
-
-analyze_patterns:
-  json: true
-
-generate_report_for_rb:
-  print_response: true
-
-generate_report_for_md:
-  print_response: true

data/examples/openrouter_example/README.md

@@ -1,48 +0,0 @@
-# OpenRouter Example
-
-This example demonstrates how to use OpenRouter with Roast to access models from different providers through a single API.
-
-## Setup
-
-1. Sign up for an account at [OpenRouter](https://openrouter.ai/)
-2. Get your API key from the OpenRouter dashboard
-3. Set the API key as an environment variable:
-   ```bash
-   export OPENROUTER_API_KEY=your_api_key_here
-   ```
-
-## Running the Example
-
-```bash
-# Run without a specific target (general analysis)
-roast execute workflow.yml
-
-# Run with a specific file to analyze
-roast execute workflow.yml path/to/your/file.txt
-```
-
-## How it Works
-
-This example configures Roast to use OpenRouter as the API provider:
-
-```yaml
-api_provider: openrouter
-api_token: $(echo $OPENROUTER_API_KEY)
-model: anthropic/claude-3-haiku-20240307
-```
-
-The workflow consists of two steps:
-1. `analyze_input`: Analyzes the provided content (or generates general insights if no target is provided)
-2. `generate_response`: Creates a structured response based on the analysis
-
-## Available Models
-
-When using OpenRouter, you can access models from multiple providers by specifying the fully qualified model name, including the provider prefix. Some examples:
-
-- `anthropic/claude-3-opus-20240229`
-- `anthropic/claude-3-sonnet-20240229`
-- `meta/llama-3-70b-instruct`
-- `google/gemini-1.5-pro-latest`
-- `mistral/mistral-large-latest`
-
-Check the [OpenRouter documentation](https://openrouter.ai/docs) for the complete list of supported models.

data/examples/openrouter_example/analyze_input/prompt.md

@@ -1,16 +0,0 @@
-I'd like you to analyze the following input and provide your insights.
-
-<% if workflow.file && workflow.resource.content %>
-Here is the content to analyze:
-
-```
-<%= workflow.resource.content %>
-```
-<% else %>
-The workflow is running without a specific file target. Please provide general insights based on the context.
-<% end %>
-
-Please provide:
-1. A summary of the key points
-2. Any notable patterns or issues
-3. Recommendations based on your analysis

data/examples/openrouter_example/generate_response/prompt.md

@@ -1,9 +0,0 @@
-Based on the analysis from the previous step, please generate a response that addresses the findings.
-
-Your response should be well-structured and include:
-1. An introduction summarizing the analysis
-2. Detailed discussion of key points
-3. Clear recommendations for improvements
-4. A conclusion
-
-Format the response in markdown for better readability.

data/examples/openrouter_example/workflow.yml

@@ -1,12 +0,0 @@
-name: OpenRouter Example
-api_provider: openrouter
-api_token: $(echo $OPENROUTER_API_KEY)
-model: google/gemini-2.0-flash-001
-
-tools:
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-
-steps:
-  - analyze_input
-  - generate_response

data/examples/pre_post_processing/README.md

@@ -1,111 +0,0 @@
-# Pre/Post Processing Example: Test Suite Optimization
-
-This example demonstrates how to use Roast's pre/post processing framework to optimize an entire test suite across multiple files.
-
-## Overview
-
-The workflow processes multiple test files, but performs setup and aggregation tasks only once:
-
-- **Pre-processing**: Runs once before any test files are processed
-  - Gathers baseline metrics for comparison
-  - Sets up the test environment
-  
-- **Main workflow**: Runs for each test file matching the target pattern
-  - Analyzes test quality and coverage
-  - Improves test coverage
-  - Optimizes test performance
-  - Validates changes
-  
-- **Post-processing**: Runs once after all test files have been processed
-  - Aggregates metrics from all files
-  - Generates a comprehensive report
-  - Cleans up the environment
-
-## Workflow Structure
-
-```yaml
-name: test_optimization
-model: gpt-4o
-target: "test/**/*_test.rb"
-
-pre_processing:
-  - gather_baseline_metrics
-  - setup_test_environment
-
-steps:
-  - analyze_test_file
-  - improve_test_coverage
-  - optimize_test_performance
-  - validate_changes
-
-post_processing:
-  - aggregate_metrics
-  - generate_summary_report
-  - cleanup_environment
-```
-
-## Directory Structure
-
-```
-pre_post_processing/
-├── workflow.yml
-├── pre_processing/
-│   ├── gather_baseline_metrics/
-│   │   └── prompt.md
-│   └── setup_test_environment/
-│       └── prompt.md
-├── analyze_test_file/
-│   └── prompt.md
-├── improve_test_coverage/
-│   └── prompt.md
-├── optimize_test_performance/
-│   └── prompt.md
-├── validate_changes/
-│   └── prompt.md
-└── post_processing/
-    ├── aggregate_metrics/
-    │   └── prompt.md
-    ├── generate_summary_report/
-    │   └── prompt.md
-    └── cleanup_environment/
-        └── prompt.md
-```
-
-## Key Features Demonstrated
-
-1. **Shared State**: Pre-processing results are available to all subsequent steps
-2. **Result Aggregation**: Post-processing has access to results from all workflow executions
-3. **One-time Operations**: Setup and cleanup happen only once, regardless of target count
-4. **Metrics Collection**: Each file's results are stored and aggregated for reporting
-
-## Running the Example
-
-```bash
-cd examples/pre_post_processing
-roast workflow.yml
-```
-
-This will:
-1. Run pre-processing steps once
-2. Process each test file matching `test/**/*_test.rb`
-3. Run post-processing steps once with access to all results
-4. Generate a comprehensive optimization report
-
-## Use Cases
-
-This pattern is ideal for:
-- **Code migrations**: Setup migration tools, process files, generate migration report
-- **Performance audits**: Baseline metrics, analyze files, aggregate improvements
-- **Documentation generation**: Analyze codebase, generate docs per file, create index
-- **Dependency updates**: Check current versions, update files, verify compatibility
-- **Security scanning**: Setup scanners, check each file, generate security report
-
-## Customization
-
-To adapt this example for your use case:
-
-1. Update the `target` pattern to match your files
-2. Modify pre-processing steps for your setup needs
-3. Adjust main workflow steps for your processing logic
-4. Customize post-processing for your reporting requirements
-5. Use appropriate AI models for each step type

data/examples/pre_post_processing/analyze_test_file/prompt.md

@@ -1,23 +0,0 @@
-# Analyze Test File
-
-Current test file: <%= file %>
-
-Please analyze this test file and identify:
-
-1. **Test Structure**: Number of test cases, test suites, and overall organization
-2. **Coverage Gaps**: Areas of the code that aren't adequately tested
-3. **Test Quality Issues**:
-   - Tests that are too brittle or implementation-dependent
-   - Missing edge cases
-   - Unclear test descriptions
-   - Excessive mocking that reduces test value
-4. **Performance Issues**:
-   - Slow setup/teardown methods
-   - Inefficient test data generation
-   - Unnecessary database operations
-5. **Opportunities for Improvement**:
-   - Tests that could be parameterized
-   - Common patterns that could be extracted to helpers
-   - Better use of test fixtures or factories
-
-Provide specific, actionable recommendations for each issue found.

data/examples/pre_post_processing/improve_test_coverage/prompt.md

@@ -1,17 +0,0 @@
-# Improve Test Coverage
-
-Based on the analysis of <%= file %>, implement the following improvements:
-
-1. **Add Missing Test Cases**: Write tests for uncovered code paths, edge cases, and error conditions
-2. **Improve Test Descriptions**: Make test names more descriptive and follow consistent naming conventions
-3. **Enhance Assertions**: Add more specific assertions to catch regressions
-4. **Test Data**: Use more realistic test data that better represents production scenarios
-5. **Remove Redundancy**: Eliminate duplicate tests or merge similar ones
-
-Generate the improved test code and explain the rationale for each change.
-
-Remember to:
-- Maintain backward compatibility with existing test interfaces
-- Follow the project's testing conventions and style guide
-- Ensure new tests are fast and deterministic
-- Add appropriate comments for complex test scenarios

data/examples/pre_post_processing/optimize_test_performance/prompt.md

@@ -1,25 +0,0 @@
-# Optimize Test Performance
-
-Optimize the performance of <%= file %> by:
-
-1. **Reduce Setup Overhead**:
-   - Move expensive operations out of individual test setup
-   - Use shared fixtures where appropriate
-   - Lazy-load test data only when needed
-
-2. **Optimize Database Operations**:
-   - Use transactions for test isolation instead of truncation
-   - Minimize database queries in tests
-   - Use in-memory databases where possible
-
-3. **Improve Test Isolation**:
-   - Remove unnecessary dependencies between tests
-   - Clean up resources properly to avoid test pollution
-   - Use proper test doubles instead of hitting external services
-
-4. **Parallelize When Possible**:
-   - Identify tests that can run in parallel
-   - Remove shared state that prevents parallelization
-   - Group related tests for better cache utilization
-
-Generate the optimized test code and provide before/after performance metrics estimates.

data/examples/pre_post_processing/post_processing/aggregate_metrics/prompt.md

@@ -1,31 +0,0 @@
-# Aggregate Metrics
-
-Aggregate all the metrics collected during the workflow execution:
-
-Available data:
-- Pre-processing baseline metrics: <%= pre_processing.gather_baseline_metrics %>
-- Results from all processed test files: <%= output.targets %>
-
-Please calculate and provide:
-
-1. **Overall Coverage Improvement**:
-   - Total coverage before and after
-   - Percentage improvement
-   - Files with biggest improvements
-
-2. **Performance Gains**:
-   - Total execution time saved
-   - Average performance improvement per file
-   - Files with best optimization results
-
-3. **Test Quality Metrics**:
-   - Number of new tests added
-   - Number of tests optimized
-   - Reduction in flaky/brittle tests
-
-4. **Summary Statistics**:
-   - Total files processed
-   - Success rate
-   - Any files that had issues
-
-Output a comprehensive metrics summary that can be used in the final report.

data/examples/pre_post_processing/post_processing/cleanup_environment/prompt.md

@@ -1,28 +0,0 @@
-# Cleanup Environment
-
-Perform post-optimization cleanup tasks:
-
-1. **Commit Changes**: Create a commit with all the test improvements
-   - Use a descriptive commit message summarizing the optimization results
-   - Include key metrics in the commit description
-
-2. **Update Documentation**:
-   - Update test documentation if structure changed significantly
-   - Add notes about any new test helpers or patterns introduced
-
-3. **Clean Temporary Files**:
-   - Remove any temporary files created during optimization
-   - Clear test caches that were used for benchmarking
-
-4. **Final Verification**:
-   - Run the full test suite one more time to ensure everything works
-   - Verify CI/CD pipelines will work with the changes
-
-5. **Create PR Description**:
-   - Generate a pull request description template with:
-     - Summary of changes
-     - Key metrics improvements
-     - Any breaking changes or considerations
-     - Review checklist
-
-Output a summary of cleanup actions performed and any final notes for the team.

data/examples/pre_post_processing/post_processing/generate_summary_report/prompt.md

@@ -1,32 +0,0 @@
-# Generate Summary Report
-
-Generate a comprehensive test optimization report based on all the collected data:
-
-## Test Suite Optimization Report
-
-### Executive Summary
-Provide a high-level overview of the optimization results, key achievements, and any issues encountered.
-
-### Metrics Summary
-Include the aggregated metrics from the previous step:
-<%= aggregate_metrics %>
-
-### Detailed Results by File
-For each processed test file, include:
-- File name and path
-- Coverage improvement
-- Performance improvement
-- Number of tests added/modified
-- Key changes made
-
-### Recommendations
-Based on the optimization results, provide:
-1. Further optimization opportunities
-2. Best practices observed that should be adopted project-wide
-3. Common patterns that could be extracted into shared utilities
-4. Testing strategy improvements
-
-### Next Steps
-Suggest follow-up actions to maintain and build upon these improvements.
-
-Format the report in Markdown for easy sharing and include visual indicators (✅ ❌ ⚠️) for quick scanning.

data/examples/pre_post_processing/post_processing/output.txt

@@ -1,24 +0,0 @@
-=== Test Optimization Summary Report ===
-Generated at: <%= Time.now.strftime("%Y-%m-%d %H:%M:%S") %>
-
-## Baseline Metrics
-<%= pre_processing.gather_baseline_metrics %>
-
-## Files Processed
-Total files: <%= targets.size %>
-
-<% targets.each do |file, target| %>
-### <%= file %>
-Analysis: <%= target.output.analyze_test_file %>
-Coverage improvements: <%= target.output.improve_test_coverage %>
-Performance optimizations: <%= target.output.optimize_test_performance %>
-<% end %>
-
-## Post-Processing Results
-### Aggregated Metrics
-<%= output.aggregate_metrics %>
-
-### Summary Report
-<%= output.generate_summary_report %>
-
-=== End of Report ===

data/examples/pre_post_processing/pre_processing/gather_baseline_metrics/prompt.md

@@ -1,26 +0,0 @@
-# Gather Baseline Metrics
-
-Analyze the current test suite and gather baseline metrics for comparison. Please provide:
-
-1. Total number of test files to be processed
-2. Current overall test coverage percentage
-3. Average test execution time across all files
-4. Number of tests by type (unit, integration, system)
-5. Any test files that are particularly slow (> 5 seconds)
-
-Store these metrics in the workflow state for later comparison in post-processing.
-
-Output format:
-```json
-{
-  "total_test_files": 0,
-  "overall_coverage": 0.0,
-  "average_execution_time": 0.0,
-  "test_counts": {
-    "unit": 0,
-    "integration": 0,
-    "system": 0
-  },
-  "slow_tests": []
-}
-```

data/examples/pre_post_processing/pre_processing/setup_test_environment/prompt.md

@@ -1,11 +0,0 @@
-# Setup Test Environment
-
-Prepare the test environment for optimization. Please:
-
-1. Ensure all test dependencies are installed
-2. Create a backup branch for safety: `test-optimization-backup-<%= timestamp %>`
-3. Set up any necessary test databases or fixtures
-4. Configure test parallelization settings if available
-5. Clear any test caches that might affect benchmarking
-
-Return a summary of the setup steps completed and any warnings or issues encountered.

data/examples/pre_post_processing/validate_changes/prompt.md

@@ -1,24 +0,0 @@
-# Validate Changes
-
-Validate the changes made to <%= file %>:
-
-1. **Run the updated tests** and ensure they all pass
-2. **Check coverage metrics** to verify improvements
-3. **Measure execution time** to confirm performance gains
-4. **Verify no regressions** were introduced
-5. **Ensure code style** follows project conventions
-
-Store the validation results in the workflow state:
-```json
-{
-  "file": "<%= file %>",
-  "tests_passed": true,
-  "coverage_before": 0.0,
-  "coverage_after": 0.0,
-  "execution_time_before": 0.0,
-  "execution_time_after": 0.0,
-  "issues_found": []
-}
-```
-
-If any issues are found, provide recommendations for fixing them.

data/examples/pre_post_processing/workflow.yml

@@ -1,21 +0,0 @@
-name: test_optimization
-model: gpt-4o
-target: "test/**/*_test.rb"
-
-# Pre-processing steps run once before any test files are processed
-pre_processing:
-  - gather_baseline_metrics
-  - setup_test_environment
-
-# Main workflow steps run for each test file
-steps:
-  - analyze_test_file
-  - improve_test_coverage
-  - optimize_test_performance
-  - validate_changes
-
-# Post-processing steps run once after all test files have been processed
-post_processing:
-  - aggregate_metrics
-  - generate_summary_report
-  - cleanup_environment

data/examples/retry/workflow.yml

@@ -1,23 +0,0 @@
-description: Demonstrate retry functionality for steps
-
-# This example shows how to configure steps to automatically retry on failure
-# The 'retries' parameter specifies how many times to retry a failing step
-
-steps:
-  - check_network: "$(curl -f -s -o /dev/null -w '%{http_code}' https://httpstat.us/500)"
-  - process_data: "Process important data that might fail transiently"
-  - flaky_command: "$(./flaky_script.sh)"
-
-# Configuration for each step
-check_network:
-  retries: 3  # Will retry up to 3 times if it fails
-  exit_on_error: true  # Will exit workflow if all retries fail
-
-process_data:
-  model: gpt-4o-mini
-  retries: 2  # Will retry up to 2 times
-
-# Command with retries but won't exit on error after all retries fail
-flaky_command:
-  retries: 5
-  exit_on_error: false  # Continue workflow even after all retries fail

data/examples/rspec_to_minitest/README.md

@@ -1,68 +0,0 @@
-# RSpec to Minitest Migration Workflow
-
-This workflow demonstrates how to automate the migration of RSpec tests to their Minitest equivalents, following a structured approach to ensure proper test coverage and functionality.
-
-## Workflow Overview
-
-The workflow consists of three main steps:
-
-1. **Analyze Spec**: Understand the purpose and structure of the RSpec test, including its dependencies and testing patterns.
-2. **Create Minitest**: Generate a new Minitest file with equivalent test coverage and assertions.
-3. **Run and Improve**: Execute the Minitest file and iteratively improve it until all tests pass.
-
-## Prerequisites
-
-- Ruby environment with both RSpec and Minitest gems installed
-- Access to the original codebase being tested
-- Ability to run tests in the target environment
-
-## Usage
-
-To use this workflow:
-
-1. Configure the target pattern in `workflow.yml` to match the RSpec files you want to convert (or pass in via CLI --target option):
-   ```yaml
-   target: "path/to/specs/**/*_spec.rb"
-   ```
-
-2. Run the workflow with:
-   ```
-   roast execute examples/rspec_to_minitest/workflow.yml
-   ```
-
-3. Review the generated Minitest files and ensure they're correctly placed in your test directory.
-
-## Implementation Details
-
-The workflow leverages the following tools:
-
-- Standard file operations (read/write)
-- Code search capabilities to find related files
-- Command execution to run tests
-- CodingAgent for iterative improvements using AI-powered coding assistance
-
-## Required Tool: CodingAgent
-
-This workflow introduces a new tool called `CodingAgent` which leverages Claude Code to perform code-related tasks:
-
-1. Running tests
-2. Analyzing errors and failures
-3. Making iterative improvements to code
-
-The CodingAgent tool is implemented in `lib/roast/tools/coding_agent.rb`.
-
-## Conversion Mappings
-
-The workflow handles these common RSpec to Minitest conversions:
-
-| RSpec Feature | Minitest Equivalent |
-|---------------|---------------------|
-| `describe/context` | Test class |
-| `it` blocks | `test_*` methods |
-| `before/after` | `setup/teardown` methods |
-| `let/let!` | Instance variables or helper methods |
-| `expect(x).to eq(y)` | `assert_equal y, x` |
-| `expect(x).to be_truthy` | `assert x` |
-| `expect(x).to be_falsey` | `refute x` |
-| `expect { ... }.to raise_error` | `assert_raises { ... }` |
-| Mocks/doubles | Minitest mocking or Mocha |

data/examples/rspec_to_minitest/analyze_spec/prompt.md

@@ -1,30 +0,0 @@
-In this first step, try to understand the purpose and dependencies of the spec we will be migrating.
-
-1. Read the provided RSpec file carefully to understand:
-   - The purpose of the test suite
-   - The subject under test (SUT)
-   - Test structure and organization 
-   - Dependencies and fixtures used
-   - Mocks, stubs, and doubles
-
-2. Use your tools to search for the SUT implementation and any other important dependent files so that they will be in the context for future steps in this process.
-   - Dependencies include fixtures
-   - Note that test/fixtures already has quite a bit of fixture files present
-   - If any fixtures are missing, copy them over when you write the new test file later
-
-3. Identify RSpec-specific features being used, such as:
-   - describe/context blocks
-   - before/after hooks
-   - let and let! declarations
-   - expect(...).to syntax and matchers
-   - shared examples/contexts
-   - metadata and tags
-
-4. Provide a summary of your analysis, including:
-   - Purpose of the test suite
-   - Main subject under test
-   - Key dependencies
-   - Testing patterns used
-   - Any potentially challenging aspects for Minitest conversion
-
-This analysis will guide the next steps of creating an equivalent Minitest implementation.