tactus 0.24.0__tar.gz

tactus-0.24.0/.claude/agents.md

@@ -0,0 +1,47 @@
+# AI Agent Guidelines
+
+## Semantic Release & Versioning
+
+This project uses **semantic-release** for automated versioning and releases.
+
+### Commit Message Format (Conventional Commits)
+
+- `feat:` → MINOR version bump (0.1.0 → 0.2.0) - use sparingly
+- `fix:` → PATCH version bump (0.1.0 → 0.1.1)
+- `docs:`, `test:`, `chore:`, `refactor:`, `style:` → No version bump
+
+### Important: Version Escalation Awareness
+
+**Do NOT use `feat:` for every new feature.** Be conscious of version escalation:
+
+- Group related changes into meaningful releases
+- Use `chore:` or `refactor:` for internal improvements that don't add user-facing features
+- Reserve `feat:` for significant new capabilities that warrant a minor version bump
+- Consider if the change truly adds value that users should know about in the changelog
+
+### Examples
+
+**Good:**
+```
+feat: add AWS Bedrock provider support
+fix: handle missing config file gracefully
+chore: update dependencies
+refactor: simplify error handling logic
+```
+
+**Avoid:**
+```
+feat: add helper function           # Use chore:
+feat: improve internal logic        # Use refactor:
+feat: add logging statement         # Use chore:
+```
+
+### Release Process
+
+Releases happen automatically on push to main. The CI runs:
+1. Linting (ruff), formatting (black)
+2. Tests (pytest + behave, excluding integration tests)
+3. Semantic-release (if tests pass)
+4. Publishes to PyPI
+
+Monitor with: `gh run watch`

tactus-0.24.0/.github/workflows/desktop-release.yml

@@ -0,0 +1,83 @@
+name: Desktop Release
+
+on:
+  push:
+    tags:
+      - 'desktop-v*'
+
+jobs:
+  build:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [macos-latest, windows-latest, ubuntu-latest]
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: '18'
+
+      - name: Setup Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+
+      - name: Install Python dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install pyinstaller
+          pip install -e .
+
+      - name: Install Node dependencies (Desktop)
+        working-directory: ./tactus-desktop
+        run: npm install
+
+      - name: Build Frontend
+        working-directory: ./tactus-desktop
+        run: npm run build:frontend
+
+      - name: Build Backend
+        working-directory: ./tactus-desktop
+        run: npm run build:backend
+
+      - name: Build Electron
+        working-directory: ./tactus-desktop
+        run: npm run build
+
+      - name: Package Application (macOS)
+        if: matrix.os == 'macos-latest'
+        working-directory: ./tactus-desktop
+        run: npm run package:mac
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Package Application (Windows)
+        if: matrix.os == 'windows-latest'
+        working-directory: ./tactus-desktop
+        run: npm run package:win
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Package Application (Linux)
+        if: matrix.os == 'ubuntu-latest'
+        working-directory: ./tactus-desktop
+        run: npm run package:linux
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Upload artifacts
+        uses: actions/upload-artifact@v3
+        with:
+          name: ${{ matrix.os }}-build
+          path: tactus-desktop/dist-electron/*
+
+      - name: Release
+        uses: softprops/action-gh-release@v1
+        with:
+          files: tactus-desktop/dist-electron/*
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

tactus-0.24.0/.github/workflows/release.yml

@@ -0,0 +1,86 @@
+name: Release
+
+on:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: write
+  id-token: write
+
+jobs:
+  quality-checks:
+    name: Quality Checks
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+          cache: 'pip'
+
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install -e ".[dev]"
+
+      - name: Run ruff linting
+        run: ruff check tactus/ tests/ features/steps/
+
+      - name: Run black formatting check
+        run: black --check tactus/ tests/ features/steps/
+
+      - name: Run pytest tests
+        run: pytest tests/ -v --tb=short -m "not integration"
+
+      - name: Run behave BDD tests
+        run: behave
+
+  release:
+    name: Semantic Release
+    runs-on: ubuntu-latest
+    needs: quality-checks
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.GH_TOKEN }}
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+          cache: 'pip'
+
+      - name: Install python-semantic-release
+        run: |
+          python -m pip install --upgrade pip
+          pip install python-semantic-release
+
+      - name: Python Semantic Release
+        env:
+          GH_TOKEN: ${{ secrets.GH_TOKEN }}
+          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+          semantic-release version
+          semantic-release publish
+
+      - name: Publish to PyPI
+        if: success() && hashFiles('dist/*') != ''
+        env:
+          TWINE_USERNAME: __token__
+          TWINE_PASSWORD: ${{ secrets.PYPI_TOKEN }}
+        run: |
+          pip install twine
+          twine upload --skip-existing dist/*

tactus-0.24.0/.gitignore

@@ -0,0 +1,44 @@
+# Python
+__pycache__/
+*.pyc
+*.pyo
+*.pyd
+.Python
+env/
+venv/
+.env
+.venv
+pip-log.txt
+pip-delete-this-directory.txt
+.tox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.log
+.pytest_cache/
+.ruff_cache/
+
+# Distribution / packaging
+dist/
+build/
+*.egg-info/
+
+# Node / frontend
+node_modules/
+.vite/
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Tactus specific
+.tactus/config.yml
+progress.output
+.tac/
+tmp/
+examples/output/
+
+*storybook.log
+storybook-static

tactus-0.24.0/.tactus/config.yml.example

@@ -0,0 +1,41 @@
+# Tactus Configuration File
+# Copy this file to config.yml and add your actual API keys
+
+# OpenAI Configuration
+openai_api_key: "your-openai-api-key-here"
+
+# AWS Bedrock Configuration
+aws_access_key_id: "your-aws-access-key-id-here"
+aws_secret_access_key: "your-aws-secret-access-key-here"
+aws_region: "us-east-1"  # or your preferred region
+
+# MCP Servers Configuration
+# Define Model Context Protocol servers that provide tools to your agents
+mcp_servers:
+  # Example: Test MCP Server (for testing)
+  # test_server:
+  #   command: "python"
+  #   args:
+  #     - "-m"
+  #     - "tests.fixtures.test_mcp_server"
+  
+  # Example: Plexus MCP Server
+  # plexus:
+  #   command: "python"
+  #   args:
+  #     - "-m"
+  #     - "plexus.mcp"
+  #   env:
+  #     PLEXUS_ACCOUNT_KEY: "${PLEXUS_ACCOUNT_KEY}"
+  #     PLEXUS_API_KEY: "${PLEXUS_API_KEY}"
+  
+  # Example: Filesystem MCP Server
+  # filesystem:
+  #   command: "npx"
+  #   args:
+  #     - "-y"
+  #     - "@modelcontextprotocol/server-filesystem"
+  #     - "/workspace"
+
+# Note: Tools from MCP servers are automatically prefixed with the server name
+# Example: "test_server_add_numbers", "plexus_score_info", "filesystem_read_file"

tactus-0.24.0/AGENTS.md

@@ -0,0 +1,406 @@
+# Instructions for Coding Agents
+
+This document provides guidelines for AI coding agents working on the Tactus project.
+
+## Pre-Commit Checklist
+
+**CRITICAL**: Before committing any changes, you MUST:
+
+1. **Wait for human approval** - DO NOT COMMIT until the human user has tested and approved your changes
+2. **Run the complete test and linting suite**:
+
+```bash
+# 1. Run unit tests
+pytest tests/ -x -k "not test_real_execution"
+
+# 2. Run BDD behavior tests
+behave --summary
+
+# 3. Check code style with ruff (no uncommitted code should have ruff errors)
+ruff check .
+
+# 4. Format code with black
+black tactus tactus-ide/backend features/steps tests
+
+# 5. Verify all checks pass again
+ruff check .
+black tactus tactus-ide/backend features/steps tests --check
+```
+
+Only commit when:
+- The human user has explicitly approved the changes
+- ALL of the above checks pass
+
+Do not skip this step or commit before getting approval and running these checks.
+
+## Reference Documentation
+
+- **[SPECIFICATION.md](SPECIFICATION.md)**: The official specification for the Tactus domain-specific language. Refer to this document for the definitive guide on DSL syntax, semantics, and behavior.
+- **[IMPLEMENTATION.md](IMPLEMENTATION.md)**: Maps the specification to the actual codebase implementation. Shows where each feature is implemented, what's complete, and what's missing relative to the specification. Use this to understand the current implementation status when working on features.
+
+## Multi-Model and Multi-Provider Support
+
+**IMPORTANT**: Tactus now supports multiple LLM providers and models:
+
+- **Providers**: `openai` and `bedrock` are supported
+- **Provider is REQUIRED**: Every agent must specify `provider:` (either directly or via `default_provider:` at procedure level)
+- **Multiple models**: Different agents can use different models (e.g., GPT-4o, GPT-4o-mini, Claude 3.5 Sonnet)
+- **Model parameters**: Supports model-specific parameters like `temperature`, `max_tokens`, `openai_reasoning_effort`
+
+Example:
+```lua
+-- Tool definition
+Tool "done" { use = "tactus.done" }
+
+-- OpenAI agent
+Agent "openai_agent" {
+    provider = "openai",
+    model = {
+        name = "gpt-4o",
+        temperature = 0.7
+    },
+    system_prompt = "...",
+    toolsets = {"done"}
+}
+
+-- Bedrock agent
+Agent "bedrock_agent" {
+    provider = "bedrock",
+    model = "anthropic.claude-3-5-sonnet-20240620-v1:0",
+    system_prompt = "...",
+    toolsets = {"done"}
+}
+```
+
+## Production Readiness
+
+**IMPORTANT**: Tactus is **NOT** ready for production. It is in early development (Alpha status).
+
+### Do NOT:
+- Declare that Tactus is "ready for production"
+- Claim that features are "production-ready"
+- State that the project is "complete" or "finished"
+- Use phrases like "ready to use in production" or "production-ready"
+
+### Do:
+- Focus on testing and verification
+- Run existing tests before declaring changes complete
+- Verify that implementations actually work as intended
+- Acknowledge limitations and incomplete features
+- Suggest improvements and note areas that need work
+
+## Semantic Release and Changelog
+
+**IMPORTANT**: This project uses Semantic Release to automatically manage versioning and the changelog.
+
+- **Do NOT manually edit `CHANGELOG.md`**. It is generated and updated automatically by the release workflow.
+- **Do NOT add `CHANGELOG.md` to `.gitignore`**. It must be tracked in the repository so the release bot can commit updates to it.
+- **Do NOT delete or truncate `CHANGELOG.md`**.
+- Ensure your commit messages follow the [Angular Commit Message Convention](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) (e.g., `feat: ...`, `fix: ...`, `docs: ...`) so that Semantic Release can correctly generate the changelog.
+
+## Commit Message Guidelines
+
+When writing commit messages:
+
+- **Do NOT use code blocks** (backticks or triple backticks) in commit messages
+- Use plain text with proper formatting (bullet points, indentation)
+- Keep commit subject lines concise (50-72 characters)
+- Use the imperative mood ("fix bug" not "fixed bug")
+- Include detailed explanations in the commit body when necessary
+- Follow the Angular Commit Message Convention for the subject line
+
+## Parser Generation Requirements
+
+**IMPORTANT**: Tactus uses ANTLR4 to generate parsers from the Lua grammar for both Python and TypeScript.
+
+### Requirements for Parser Generation
+
+**Docker is REQUIRED** for generating parsers:
+- Parser generation uses ANTLR4 which requires Java
+- We use Docker to avoid requiring Java installation on developer machines
+- Docker image: `eclipse-temurin:17-jre`
+
+**When to regenerate parsers:**
+- Only when modifying the Lua grammar files
+- Generated parsers are committed to version control
+- End users don't need Docker or Java
+
+**How to regenerate parsers:**
+```bash
+# Ensure Docker is running
+make generate-parsers
+
+# Or generate individually:
+make generate-python-parser
+make generate-typescript-parser
+```
+
+**Generated files (committed to repo):**
+- `tactus/validation/generated/*.py` - Python parser
+- `tactus-ide/frontend/src/validation/generated/*.ts` - TypeScript parser
+
+## Tactus IDE Development
+
+When working on the Tactus IDE:
+
+### Architecture: Hybrid Validation
+
+The IDE uses a two-layer validation approach for optimal performance and user experience:
+
+**Layer 1: TypeScript Parser (Client-Side)**
+- Location: `tactus-ide/frontend/src/validation/`
+- ANTLR-generated from same `LuaLexer.g4` and `LuaParser.g4` grammars as Python parser
+- Purpose: Instant syntax validation (< 10ms)
+- Runs in browser, no backend needed
+- Provides immediate feedback as user types
+- Works offline
+
+**Layer 2: Python LSP (Backend)**
+- Location: `tactus-ide/backend/`
+- Uses existing `TactusValidator` from `tactus/validation/`
+- Purpose: Semantic validation and intelligence
+- Debounced (300ms) to reduce load
+- Provides completions, hover, signature help
+- Cross-reference validation
+
+### Why Hybrid?
+
+1. **Performance**: Syntax errors appear instantly (no network delay)
+2. **Offline**: Basic editing works without backend
+3. **Intelligence**: LSP adds semantic features when available
+4. **Scalability**: Reduces backend load (syntax is client-side)
+5. **User Experience**: No lag, no waiting for validation
+
+### Backend (Python LSP Server)
+- Location: `tactus-ide/backend/`
+- Uses existing `TactusValidator` from `tactus/validation/`
+- Implements LSP protocol for language intelligence
+- Flask server provides HTTP and WebSocket endpoints
+- Focus on semantic validation, not syntax (handled client-side)
+
+### Frontend (React + Monaco)
+- Location: `tactus-ide/frontend/`
+- Monaco Editor for code editing (same as VS Code)
+- TypeScript parser for instant syntax validation
+- LSP client communicates with Python backend via WebSocket
+- Can be packaged as Electron app
+
+### Testing IDE Features
+- TypeScript parser: `cd tactus-ide/frontend && npm test`
+- Backend LSP: `pytest tactus-ide/backend/` (when tests are added)
+- Integration: Test with example `.tac` files
+- Verify both layers work independently and together
+
+### Running the IDE
+
+```bash
+# Terminal 1: Backend
+cd tactus-ide/backend
+pip install -r requirements.txt
+python app.py
+
+# Terminal 2: Frontend
+cd tactus-ide/frontend
+npm install
+npm run dev
+```
+
+### Electron Packaging
+The IDE is designed to run as a desktop application:
+- Backend runs as subprocess or separate service
+- Frontend uses Electron's IPC for file operations
+- No dependency on browser-specific APIs
+- Hybrid validation works in Electron environment
+
+### UI/UX Standards
+
+When working on the Tactus IDE frontend:
+
+- **UI Framework**: Use [Shadcn UI](https://ui.shadcn.com/) components for all UI elements
+- **Icons**: Always use [Lucide React](https://lucide.dev/) icons - **NEVER use emojis**
+- **Styling**: Use Tailwind CSS with the existing design system
+- **Theme**: Support both light and dark modes (colors are defined in CSS variables)
+- **Accessibility**: Ensure proper ARIA labels and keyboard navigation
+
+Example icon usage:
+```tsx
+import { Bot, CircleCheck, ChevronDown } from 'lucide-react';
+
+<Bot className="h-5 w-5 text-muted-foreground stroke-[2]" />
+```
+
+### CLI and Logging Standards
+
+When working on CLI output, logging, or documentation:
+
+- **NEVER use emojis** - Always use Unicode symbols instead
+- **CLI Output**: Use box-drawing characters (│ ─ ├ └), arrows (→ ←), bullets (•), checkmarks (✓ ✗)
+- **Logging**: Use plain text or Unicode symbols for status indicators
+- **Documentation**: Use Unicode symbols or standard markdown formatting
+
+Example symbols:
+```python
+# Good - Unicode symbols
+print("✓ Test passed")
+print("✗ Test failed")
+print("→ Processing...")
+print("• Item 1")
+
+# Bad - Emojis
+print("✅ Test passed")  # ❌ Don't use
+print("🔥 Error")       # ❌ Don't use
+```
+
+## Testing Requirements
+
+Before declaring any change complete:
+
+1. **Run existing tests**: Use `pytest` to verify no regressions
+2. **Test the specific feature**: Create or update tests for new functionality
+3. **Verify imports**: Ensure all imports resolve correctly
+4. **Check for errors**: Run linters and fix any issues
+5. **Test parser changes**: If grammar modified, run `make test-parsers`
+
+### Understanding Testing vs. Evaluation
+
+Tactus has two distinct testing mechanisms that serve different purposes:
+
+**Behavior Specifications (`specifications`):**
+- Test the **Lua orchestration logic** (control flow, state management, coordination)
+- Use Gherkin syntax (Given/When/Then)
+- Run with `tactus test`
+- Can use mocks to isolate logic from LLM behavior
+- Fast and deterministic
+- Example: Testing that a multi-agent workflow delegates correctly
+
+**Evaluations (`evaluations`):**
+- Test the **LLM's output quality** (accuracy, consistency, helpfulness)
+- Use Pydantic AI Evals framework
+- Run with `tactus eval`
+- Use real API calls (not mocked)
+- Slower and probabilistic
+- Example: Testing that an agent generates high-quality greetings
+
+**When to use which:**
+- **Complex orchestration** → Use `specifications` to test the logic
+- **Simple LLM wrapper** → Use `evaluations` to test the output
+- **Both** → Use specifications for fast feedback on logic, evaluations for quality metrics
+
+**Key principle:** Don't mock LLMs in evaluations—you're testing the model's actual behavior. Do mock them in specifications when you're testing orchestration logic, not intelligence.
+
+## Code Quality
+
+- Follow existing code patterns and style
+- Add appropriate logging for debugging
+- Include docstrings for public APIs
+- Handle errors gracefully with proper exception types
+- Keep implementations simple and maintainable
+
+## Using the CLI for Development
+
+The Tactus CLI provides powerful tools for developing and debugging agents.
+
+### Running and Debugging Procedures
+
+When you run a procedure with `tactus run`, you get real-time visibility into what's happening:
+
+```bash
+tactus run examples/04-basics-simple-agent.tac
+```
+
+Output shows:
+- **Agent activity**: See when agents start processing and complete
+- **Tool calls**: See what tools agents call with full arguments and results
+- **Agent responses**: See the actual text/reasoning from the LLM
+- **Cost tracking**: Monitor tokens and costs for each LLM call
+- **Summary**: Final iteration count, tools used, total cost
+
+Example output:
+```
+Running procedure: 04-basics-simple-agent.tac (lua format)
+
+→ Agent greeter: Waiting for response...
+Hello! I'll help you with that task.
+✓ Agent greeter: Completed 1204ms
+→ Tool done
+  Args: {
+  "reason": "Hello there! I hope you're having a wonderful day."
+}
+  Result: Done
+$ Cost greeter: $0.001267 (354 tokens, openai:gpt-4o, 1204ms)
+
+✓ Procedure completed: 1 iterations, 1 tools used
+
+$ Cost Summary
+  Total Cost: $0.001267
+  Total Tokens: 354
+```
+
+### Inspecting Procedure Structure
+
+Use `tactus info` to view procedure metadata without running it:
+
+```bash
+tactus info examples/04-basics-simple-agent.tac
+```
+
+This shows:
+- **Parameters**: What inputs the procedure expects
+- **Outputs**: What results it returns
+- **Agents**: Configuration for each agent (provider, model, tools, prompt preview)
+- **Specifications**: Count of BDD test scenarios
+
+This is useful for:
+- Understanding what a procedure does before running it
+- Checking agent configurations
+- Verifying tool availability
+- Documentation and code review
+
+### Debugging Agent Issues
+
+If an agent doesn't work as expected, the CLI output helps you diagnose:
+
+1. **Agent never calls done tool**: Look for tool call events (→ Tool). If you don't see any, check:
+   - Does the agent definition include `tools = {"done"}`?
+   - Does the system prompt mention calling the done tool?
+
+2. **Agent calls wrong tool**: Tool call events show arguments. Check:
+   - Are tool names correct in the agent config?
+   - Does the system prompt clearly explain which tools to use?
+
+3. **High costs/token usage**: Cost events show per-call breakdown. Look for:
+   - Agents making too many turns (increase max_turns or improve prompts)
+   - Large context windows (check message history filtering)
+   - Repeated tool calls (agent might be stuck in a loop)
+
+4. **Slow execution**: Timing information shows where delays occur:
+   - Agent turns show duration (e.g., "1204ms")
+   - Multiple slow turns indicate LLM performance issues
+   - Consider using faster models for simple tasks
+
+### CLI Output Format
+
+The CLI uses Unicode symbols (not emojis) for compatibility:
+
+- `→` Agent or tool activity starting
+- `✓` Successful completion
+- `✗` Error or failure
+- `$` Cost information
+- `•` List items
+
+All output is plain text with optional ANSI colors for readability in terminals.
+
+## Project Status
+
+Tactus is a standalone workflow engine extracted from a larger project. It is:
+- In active development
+- Missing some features (noted in code with TODO comments)
+- Subject to API changes
+- Not yet suitable for production use
+
+When working on Tactus, focus on:
+- Making incremental improvements
+- Fixing bugs and issues
+- Adding missing functionality
+- Improving documentation
+- Writing and maintaining tests