@profoundlogic/coderflow-server 0.2.1

package/dist/web-ui/public/docs/templates/template-examples.md

@@ -0,0 +1,93 @@
+# Template Examples
+
+Templates can automate many types of repetitive work. Here are common use cases that show how templates turn manual, one-at-a-time tasks into scalable operations.
+
+## Code Modernization
+
+### Legacy RPG to Modern RPG
+
+Convert fixed-format RPG to modern free-format RPG:
+
+- **Parameter**: Source file to convert
+- **Instructions**: Analyze the program, convert to free-format syntax, update data definitions, add documentation
+- **Validation**: Compile the converted program, run Profound Automated Testing to verify behavior matches original
+- **Batch**: Select all programs in a library and convert them in parallel
+
+### Language Migration
+
+Convert from legacy languages to modern platforms:
+
+- **Parameter**: Source program
+- **Instructions**: Analyze code structure, convert to target language (Node.js, .NET, Java), adapt platform-specific patterns
+- **Validation**: Run Profound Automated Testing to ensure functional equivalence
+- **Batch**: Migrate complete applications program by program
+
+## Refactoring
+
+### Code Pattern Updates
+
+Apply consistent refactoring across a codebase:
+
+- **Parameter**: File to refactor
+- **Instructions**: Find deprecated patterns, replace with modern equivalents, update imports/dependencies
+- **Validation**: Run tests, verify compilation
+- **Batch**: Apply the same refactoring to every file matching a pattern
+
+### API Modernization
+
+Update legacy API calls to modern interfaces:
+
+- **Parameter**: Program using legacy APIs
+- **Instructions**: Identify deprecated API calls, update to current versions, handle signature changes
+- **Validation**: Test API interactions, verify responses
+- **Batch**: Update all programs using the legacy API
+
+## Testing
+
+### Test Generation
+
+Generate tests for existing code:
+
+- **Parameter**: Program or module to test
+- **Instructions**: Analyze code paths, generate unit tests covering key scenarios, create test data
+- **Output**: Test files ready for integration
+- **Batch**: Generate tests for all modules in a project
+
+### Test Expansion
+
+Add coverage for edge cases:
+
+- **Parameter**: Existing test file
+- **Instructions**: Analyze current coverage, identify gaps, add tests for boundary conditions and error paths
+- **Batch**: Expand coverage across entire test suite
+
+## Documentation
+
+### Code Documentation
+
+Generate documentation from source code:
+
+- **Parameter**: Source file or module
+- **Instructions**: Analyze code structure, document functions/procedures, explain business logic, create usage examples
+- **Output**: Markdown documentation files
+- **Batch**: Document entire libraries or applications
+
+### API Documentation
+
+Generate API reference documentation:
+
+- **Parameter**: API endpoint or service definition
+- **Instructions**: Extract endpoint details, document parameters and responses, provide example requests
+- **Batch**: Document all endpoints in a service
+
+## Building Effective Templates
+
+When creating templates for these use cases:
+
+1. **Start specific**: Write instructions that work perfectly for one item
+2. **Test thoroughly**: Validate the template produces correct results
+3. **Parameterize carefully**: Only expose parameters users need to change
+4. **Include validation**: Add steps for testing and verification
+5. **Scale gradually**: Start with small batches before processing hundreds
+
+See **Task Templates** for how to run templates, and **Batch Processing** for scaling to large operations.

package/dist/web-ui/public/docs/testing/profound-automated-testing.md

@@ -0,0 +1,77 @@
+# Profound Automated Testing
+
+Profound Automated Testing verifies that refactored code behaves identically to the original. Tests are recorded once against your original application, then replayed automatically against refactored versions to detect any discrepancies in screens or data.
+
+This is especially valuable for agent-driven refactoring tasks—like converting legacy RPG to modern RPG, or migrating from one language to another—where you need confidence that functionality remains intact.
+
+## How It Works
+
+### 1. Record Against the Original
+
+Before refactoring begins, tests are recorded against your original application:
+
+- Interact with the application (5250/Genie screens or Rich Display interfaces)
+- The system captures JSON payloads representing the UI state at each step
+- Database changes are also tracked at each step
+- This creates a baseline without writing any test code
+
+### 2. Validate to Establish Baseline
+
+Run the recorded test against the original environment to establish expected outcomes:
+
+- Data hashes are captured for each database table at every step
+- These hashes become the reference for future comparisons
+- Any dynamic elements (like timestamps) are accounted for
+
+### 3. Replay Against Refactored Code
+
+When an agent refactors code, the tests replay automatically:
+
+- The same interactions run against the refactored application
+- UI payloads are compared against the baseline
+- Database changes are compared using the captured hashes
+- Any differences are flagged—altered screens, missing data, unexpected changes
+
+### 4. Review Results
+
+After replay, you can see exactly what matched and what differed:
+
+- Which screens rendered correctly
+- Which data changes matched expectations
+- Where discrepancies occurred and why
+
+## Agent Integration
+
+Agents run these tests automatically in **headless mode** during refactoring tasks. This means:
+
+- Tests execute without manual intervention
+- Multiple tests can run in parallel
+- Results feed back into the agent's understanding of whether the refactor succeeded
+- Agents can iterate on their changes if tests fail
+
+This creates a tight feedback loop: the agent refactors, tests verify, and if something breaks, the agent knows immediately and can adjust.
+
+## Modernization and Refactoring
+
+Profound offers a combination of algorithmic and AI-based refactoring for enterprise modernization efforts, including:
+
+- **5250 to Web**: Converting terminal-based interfaces to modern web applications
+- **RPG to modern languages**: Transforming RPG code to Node.js, .NET, or Java
+- **COBOL to modern languages**: Migrating COBOL applications to contemporary platforms
+
+The algorithmic approach ensures consistent, predictable transformations for well-understood patterns, while AI handles nuanced decisions and edge cases. Profound Automated Testing validates these transformations automatically, ensuring the modernized application behaves identically to the original.
+
+## When to Use
+
+Profound Automated Testing is most valuable for:
+
+- **Code modernization**: Converting legacy code to modern languages or frameworks
+- **RPG refactoring**: Updating old RPG patterns to modern free-format RPG
+- **Platform migrations**: Moving applications between environments
+- **Large-scale changes**: Any refactoring where manual verification would be impractical
+
+For smaller changes or new features, manual testing through the Testing menu may be sufficient. Automated testing shines when you need to verify that complex, existing functionality remains unchanged.
+
+## Learn More
+
+For detailed documentation on recording tests, configuring environments, and analyzing results, see the [Profound Automated Testing documentation](https://profoundlogicsupport.atlassian.net/wiki/spaces/PUI/pages/1461092365/Automated+Testing).

package/dist/web-ui/public/docs/testing/task-visualizations.md

@@ -0,0 +1,42 @@
+# Task Visualizations
+
+As agents work on tasks, they automatically capture screenshots and screen states from applications they interact with. These visualizations show exactly what the agent saw during execution—giving you visibility into how the agent tested and verified its changes.
+
+## What Gets Captured
+
+Agents capture visualizations whenever they interact with running applications:
+
+- **5250 terminal screens**: Character-based displays from IBM i systems and legacy applications
+- **Rich Display screens**: Modern web interfaces built with Profound UI or similar frameworks
+- **Web page screenshots**: Browser-rendered pages the agent navigated to
+
+Captures happen automatically during task execution. Agents know when to capture screens automatically based on the testing context and instructions configured in the environment.
+
+## Viewing Visualizations
+
+After a task completes, you can view the captured screens:
+
+1. Open the task detail page
+2. Look for captured screens in the **Output Summary** section
+
+Each visualization shows:
+- The rendered screen as the agent saw it
+- When it was captured during execution
+- Which session or test produced it
+
+For 5250 screens, visualizations render in a terminal-style format with proper formatting and colors. For web interfaces, you see the page as it appeared in the browser.
+
+## Why Visualizations Matter
+
+Visualizations help you:
+
+- **Verify agent work**: See exactly what the agent tested, not just what it reported
+- **Debug issues**: When something goes wrong, screenshots show the application state
+- **Document changes**: Captured screens serve as visual evidence of testing
+- **Understand legacy systems**: 5250 screens are rendered in a readable format even if you're unfamiliar with terminal interfaces
+
+## Configuration
+
+Visualizations require environment-level configuration to render certain screen types (especially 5250 screens). If visualizations aren't appearing for your environment, ask your administrator to check the environment settings.
+
+See **Environments** in the Administration section for configuration details.

package/dist/web-ui/public/docs/testing/testing-menu.md

@@ -0,0 +1,118 @@
+# Testing Menu
+
+The Testing menu provides tools to verify that agent changes work correctly. Start your application server, run test commands, and interact with your running application—all from the task toolbar.
+
+## What is an Application Server?
+
+An application server is the runtime environment where your code executes. In CoderFlow, the application server:
+
+- Runs your application so you can test it interactively
+- Exposes web URLs you can click to open the running application
+- Enables manual testing and validation of code changes
+- Captures screens for visualization and documentation
+
+Application servers are configured per environment by administrators. See **Environments** in the Administration section for configuration details.
+
+## Container Mode vs Proxy Mode
+
+Environments can be configured with one of two application server modes:
+
+### Container Mode
+
+The application runs inside the task container itself. When you start the server, a command executes within the container (like `npm start` or a custom startup script), and the application begins listening for requests.
+
+This mode is fully self-contained—the application runs in the same isolated environment where the agent made its changes.
+
+### Proxy Mode
+
+Requests are forwarded to an external application server running outside the container. This is common when connecting to:
+
+- Remote IBM i systems
+- Shared development servers
+- External testing platforms
+
+In proxy mode, CoderFlow acts as an intermediary, forwarding your requests to the external server and returning responses.
+
+## Starting and Stopping
+
+### Starting the Application Server
+
+1. Open a task with an application server configured
+2. Open the **Testing** menu in the toolbar
+3. Click **Start Server** or use **Start Server & Launch** to start and open a URL in one step
+4. Wait for the server to initialize
+
+You can view server logs from the Testing menu while the server is running.
+
+### Stopping the Application Server
+
+Open the Testing menu and click **Stop Server**. The server also stops automatically when:
+
+- The task is paused or stopped
+- The container is removed
+
+## Launch URLs
+
+Launch URLs are pre-configured links that open specific pages in your running application. They appear in the Testing menu under **Launch URLs** (when the server is running) or **Start Server & Launch** (to start and open in one step).
+
+Click any launch URL to open that page in a new browser tab. Common examples include:
+
+- Application home page
+- Admin dashboards
+- Specific features or modules under development
+
+Launch URLs are defined in the environment configuration. If you need different URLs, ask your administrator to update the environment settings.
+
+## Running Tests
+
+The Testing menu also provides access to test commands configured for your environment. These can include unit tests, integration tests, linting, or any custom commands your team has set up.
+
+### Executing a Test
+
+1. Open the **Testing** menu
+2. Find your test under **Run Test Commands**
+3. Click the test name
+4. If the test has parameters, select or enter values when prompted
+5. Click **Run** to execute
+
+Test output streams in real-time. When complete, you'll see the exit code—0 means passed, non-zero means failed.
+
+### Tests with Parameters
+
+Some tests accept parameters to customize what runs. For example, a unit test might let you select which test file to run, or choose between debug and coverage modes. The UI prompts you for these values before execution.
+
+If a test supports multiple selections, you can run the same test against several files or configurations in one go.
+
+### Viewing Results
+
+Test output appears in a results panel showing:
+
+- Real-time command output
+- Pass/fail status
+- Exit code
+- Error messages and stack traces (if failed)
+
+Use test results alongside manual application testing to validate that agent changes work correctly.
+
+## Providing Feedback
+
+If you find issues while testing, you can provide feedback in two ways:
+
+**From the task detail page:** Return to CoderFlow and send follow-up instructions describing what needs to change.
+
+**From the application itself:** Use the feedback widget injected into your running application. This lets you capture context directly—take screenshots, select DOM elements, or record screen state—without leaving the application. Your feedback is sent to the agent along with the captured context.
+
+The in-app feedback widget is especially useful when issues are easier to show than describe.
+
+## Testing Workflow
+
+A typical testing workflow:
+
+1. Agent completes a task with code changes
+2. Run automated tests from the Testing menu to catch obvious issues
+3. Start the application server and open a launch URL
+4. Manually test the changes—verify the fix works, check for regressions
+5. If issues are found, provide feedback (from the app or task page)
+6. When satisfied, approve and deploy the changes
+
+Combining automated tests with hands-on verification gives you confidence that the changes are ready for production.