{"slug": "show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running", "title": "Show HN: Coding agent that compiles intent into deterministic DAG before running", "summary": "Rigorix, a new open-source coding agent runtime, compiles natural-language development tasks into deterministic Directed Acyclic Graphs (DAGs) before execution, separating planning from execution to enable repeatable, auditable, and governable AI-assisted software engineering for CI/CD environments.", "body_md": "**A deterministic coding-agent runtime for repeatable, auditable AI software engineering.**\n\nRigorix compiles natural-language development tasks into executable Directed Acyclic Graphs (DAGs). Instead of relying on an open-ended agent loop, it separates planning from execution: the execution plan is generated, validated, and then executed within configurable policy, permission, and budget constraints. The result is AI-assisted software engineering that is repeatable, inspectable, and suitable for automated environments such as CI/CD.\n\nThe LLM generates code; Rigorix governs execution.\n\nRigorix operates through three modes:\n\n**CLI**(`rigorix`\n\n) — Interactive TUI + flag-based scripting for local development**GitHub Action**(`rigorix-action`\n\n) — PR governance and automated code generation in CI/CD**Engine**— The core library powering both\n\nRigorix is built with the [Guardian Framework](https://github.com/arman-jalili/guardian-framework) — **an architecture enforcement framework for AI-assisted development.** Guardian ensures every change is traceable to canonical architecture specs, validated by proof scripts, and governed by frozen module contracts.\n\nModern coding agents are remarkably capable. They can write code, edit projects, execute commands, and iterate on failures. But they share a fundamental problem: **they are unpredictable, unauditable, and difficult to govern in automated contexts.**\n\nEvery agent loop today works the same way: an LLM decides what to do, does it, checks the result, and loops. That loop is powerful — but it has no structure. There's no distinction between planning and execution. There's no audit trail beyond conversation history. There's no way to say \"execute this plan but only if it stays within these boundaries.\"\n\nThis works fine when a human is watching every step. It breaks down when you want to:\n\n**Run in CI/CD**— without a human to approve every tool call** Audit what happened**— when conversation history isn't enough for compliance** Enforce policies**— \"deny any change that touches the auth module\" or \"flag diffs that modify payment processing\"** Budget costs**— cap LLM spending per run so a runaway agent doesn't burn your API key\n\nRigorix is opinionated: it intentionally gives up some **flexibility** in exchange for **repeatability, governance, and deterministic execution.**\n\nThe core idea is simple: instead of an LLM deciding what to do at each step, you compile the intent into a DAG first — a deterministic, reviewable plan. The DAG says: *read these files, generate this patch, run these tests, verify these conditions.* The LLM fills in the content; the DAG controls the flow. This is the same pattern that made build systems (Make, Bazel) and data pipelines (Airflow, Dagster) reliable: separate *what* from *how*, validate the plan before running it, and record every execution.\n\nThis approach makes tradeoffs. Rigorix is not as flexible as a free-form agent loop. It can't have a \"conversation\" with you or improvise mid-execution. If you want a coding assistant that chats, Rigorix is the wrong tool. But if you want a CI/CD pipeline that generates code, enforces policies, produces auditable records, and can run without supervision — Rigorix exists for that.\n\n**Rigorix achieves this through bounded autonomy:** every execution is constrained by configurable risk policies, permission rules, execution budgets, and quality gates. The model is intentionally restrictive: the LLM decides what to generate within the execution graph, while Rigorix determines what is allowed to happen.\n\n```\n Natural language task\n        ↓\n Classifier — maps intent to a template\n        ↓\n Template — defines the execution structure\n        ↓\n Parameters — extracted from the task\n        ↓\n DAG — deterministic execution graph\n        ↓\n Execution — tools, retry, recovery\n        ↓\n Validation — quality gates, policies\n        ↓\n Audit — signed, timestamped record\n```\n\nTemplates encode repeatable engineering workflows. Instead of asking the model to rediscover how to perform a common task each time, Rigorix selects an appropriate template, extracts parameters, builds an execution graph, and lets the LLM focus on generating code within that structure.\n\nRepeatable means the same intent produces the same execution structure under the same templates and policies. The generated code may differ, but the workflow, validation steps, and governance remain consistent.\n\nA template defines:\n\n**What** files to read and what to generate from them**Which** commands to run for verification (type-check, test, lint)**How** to handle dependencies between steps**Where** the output goes (new files, patches, test results)\n\nHere is a minimal template — it reads a file, runs a regex filter, and writes the result:\n\n```\nname: extract-function-docs\ndescription: Extract JSDoc comments from a TypeScript file\nparameters:\n  - name: file_path\n    type: string\n    description: Path to the TypeScript file\nnodes:\n  - id: read_file\n    action: file_read\n    params:\n      path: \"{{ file_path }}\"\n  - id: extract_docs\n    action: llm_generate\n    depends_on: [read_file]\n    params:\n      prompt: >-\n        Extract all JSDoc comments from the file below.\n        Return them as a markdown list.\n      input: \"{{ read_file.output }}\"\n  - id: write_output\n    action: file_write\n    depends_on: [extract_docs]\n    params:\n      path: \"docs/{{ file_path | basename }}.md\"\n      content: \"{{ extract_docs.output }}\"\n```\n\nWhen a user runs `rigorix plan \"Extract docs from src/api.ts\"`\n\n, Rigorix classifies the intent, maps it to this template, prompts the LLM to fill `file_path`\n\n, and builds the 3-node DAG. **The LLM generates the doc content; the template controls the flow.**\n\nWhen no existing template matches the intent — or confidence is low — Rigorix prompts the LLM to generate a new template dynamically. Generated templates can be cached and reused for future executions, reducing the need to regenerate common workflows.\n\n| Dimension | Rigorix | Claude Code | Copilot / Cursor | Aider | SWE-Agent |\n|---|---|---|---|---|---|\nExecution |\nTemplate-driven DAG | Agent loop | Agent loop | Agent loop | Agent loop |\nSafety |\nRisk gating, budgets, permissions | Permission prompts | Permission prompts (Cursor) | Git auto-commit | Docker sandbox |\nPR governance |\nBuilt-in policy.toml | External CI | ✗ | ✗ | ✗ |\nAudit |\nHMAC-signed envelopes | Conversation history | Conversation history | Git log | Ephemeral containers |\nQuality gates |\nPost-execution validation | ✗ | ✗ | ✗ | ✗ |\nSelf-correcting |\nValidate loop (plan → verify → fix) | Retry loop | ✗ | Lint-then-fix loop | Retry loop |\n\nRigorix is designed for **deterministic, auditable, safely-bounded automation** — not open-ended agent loops. If you need a code assistant that chats with you, use Claude Code or Aider. If you need a CI/CD pipeline that enforces policies and generates auditable code changes, use Rigorix.\n\nThe example below shows the generated execution graph before anything is modified. The user can inspect the plan and choose whether to execute it.\n\n*🎥 Demo: Rigorix planning and executing a TypeScript refactor — reading code, generating a patch, type-checking, and running tests.*\n\nCLI output from the same DAG shown in the TUI above:\n\n``` bash\n$ rigorix-cli plan  \"Add a method to TaskList class in src/task.ts that returns only active tasks\"\nPlan: Add a method to TaskList class in src/task.ts that returns only active tasks (confidence 100%)\n  Template: add-get-active-tasks-method | LLM: 2 calls, 1141 tokens\n  Parameters:\n    ├── file_path: \"src/task.ts\"\n  Graph: 5 node(s), sealed=true\n    · Read current task.ts file (root)\n    · Insert getActiveTasks method after activeCount ← [Read current task.ts file]\n    · Write extended task list test file ← [Read current task.ts file]\n    · Type-check with tsc ← [Insert getActiveTasks method after activeCount, Write extended task list test file]\n    · Run extended task list tests ← [Type-check with tsc, Write extended task list test file]\n\nRun this plan now? [y/N]: y\n2026-06-28T16:40:38.139935Z  INFO run: rigorix_engine::orchestrator::application::orchestrator_impl: Starting orchestrator run execution_id=019f0f1a-bbfb-7722-8c43-e3232eb88f9b\n2026-06-28T16:40:46.026763Z  INFO run: rigorix_engine::orchestrator::application::orchestrator_impl: Orchestrator run completed execution_id=019f0f1a-bbfb-7722-8c43-e3232eb88f9b status=Completed\nRun: Completed — 0 failed, 5 passed, 0 skipped (5 total)\n  Template: add-get-active-tasks-method | LLM: 2 calls, 1210 tokens\n\n  ✓ Read current task.ts file — Success\n  ✓ Insert getActiveTasks method after activeCount — Success\n  ✓ Write extended task list test file — Success\n  ✓ Type-check with tsc — Success\n  ✓ Run extended task list tests — Success\n```\n\nRigorix currently supports Rust, TypeScript, Python, and Go as target codebases. TypeScript is the most mature integration today (it has a working failure-compiler step); the others are functional but earlier-stage.\n\n```\n# From source\ncargo install --git https://github.com/arman-jalili/rigorix-oss rigorix-cli\n\n# Or build locally\ngit clone https://github.com/arman-jalili/rigorix-oss\ncd rigorix-oss && cargo build --release -p rigorix-cli\n./target/release/rigorix --help\nexport RIGORIX__LLM__API_KEY=\"sk-ant-...\"   # Anthropic\n# or: export ANTHROPIC_API_KEY=\"sk-ant-...\"\ncd my-project\nrigorix init\nrigorix run \"Explain how the main module works\"\n```\n\nRigorix will: classify the intent → extract parameters → generate a DAG → execute nodes (file reads, edits, bash commands) → validate results.\n\n```\nrigorix plan \"Add a new endpoint to the API\"   # Review the DAG, then:\nrigorix run \"Add a new endpoint to the API\"\n```\n\nOr just plan and confirm in one flow:\n\n```\nrigorix plan \"Add error handling to the parser\"\n# Shows plan, then prompts:\n# Run this plan now? [y/N]: y\n┌─────────────────────────────────────────────────────────────┐\n│                   User (Developer)                           │\n│            (CLI / TUI / GitHub Action)                       │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n┌──────────────────────────▼──────────────────────────────────┐\n│                     Planning Phase                           │\n│                                                              │\n│  Intent → Classify → Extract → Generate TaskGraph → Validate │\n│                  ↕ (low-confidence fallback)                 │\n│        Template System + LLM Template Generator              │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n┌──────────────────────────▼──────────────────────────────────┐\n│                     Execution Phase                          │\n│                                                              │\n│  DAG Engine (topo sort) → ParallelExecutor (tokio JoinSet)   │\n│       → Tool System (file/git/command/LSP)                   │\n│       → Retry/Recovery/Fallback                               │\n│       → Cancellation (graceful/immediate)                    │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n┌──────────────────────────▼──────────────────────────────────┐\n│                  Observability & Persistence                  │\n│                                                              │\n│  Event Bus → State Persistence → Audit (HMAC-signed)         │\n│         + Prometheus Metrics + Tracing                       │\n└─────────────────────────────────────────────────────────────┘\nrigorix-oss/\n├── engine/              # Core library — all business logic\n│   ├── src/             # Core engine (planning, execution, tools, governance)\n│   └── .pi/             # Architecture docs, ADRs, diagrams\n├── cli/                 # CLI binary — thin wrapper over engine\n│   ├── src/cli_boundary/# Flag-based CLI (Clap, dispatch, config)\n│   ├── src/tui/         # Interactive TUI (ratatui)\n│   └── .pi/             # Architecture docs\n├── actions/             # GitHub Action — thin adapter over engine\n│   ├── src/             # 9 bounded-context modules\n│   └── .pi/             # Architecture docs\n├── Cargo.toml           # Workspace root\n└── .pi/                 # Root-level architecture docs, prompts, scripts\n```\n\n- Rust 2024 edition (stable toolchain)\n- LLM API key (set\n`ANTHROPIC_API_KEY`\n\nor`OPENAI_API_KEY`\n\n)\n\nRigorix treats CI as continuous verification rather than compilation and testing. Beyond formatting, linting, unit tests, and security scanning, every architectural capability is validated through proofing scripts that verify contracts, architecture readiness, documentation consistency, policy enforcement, and execution guarantees.\n\n```\n📦 86 automated verification steps\n\n  Lint (12)     — formatting, clippy, CI validation × 3 crates\n  Build (9)     — release build, static analysis, package × 3 crates\n  Test (53)     — cargo test, unit/integration stages, 30 module proofing scripts\n  Security (7)  — cargo audit, secret scan, stage security, security validation\n  Docs (13)     — canonical, architecture, readiness, ubiquitous language × all crates\n  Integration (2) — integration and operations validation\n# Run the full CI suite (86 steps, ~2 min)\nbash .pi/scripts/local-ci.sh\n\n# Run a specific stage\nbash .pi/scripts/local-ci.sh --stage=lint      # lint only\nbash .pi/scripts/local-ci.sh --stage=build     # build only\nbash .pi/scripts/local-ci.sh --stage=test      # test only\nbash .pi/scripts/local-ci.sh --stage=security  # security only\nbash .pi/scripts/local-ci.sh --stage=docs      # documentation only\nbash .pi/scripts/local-ci.sh --stage=integration  # integration only\n\n# Run a specific crate\nbash .pi/scripts/local-ci.sh --crate=engine\nbash .pi/scripts/local-ci.sh --crate=cli\nbash .pi/scripts/local-ci.sh --crate=actions\n\n# Quick mode — skip release builds, use cargo check instead\nbash .pi/scripts/local-ci.sh --quick\n\n# Save report to a file (auto-gitignored under .pi/output/)\nbash .pi/scripts/local-ci.sh --save\n\n# List all available CI validation scripts\nbash .pi/scripts/local-ci.sh --list\n\n# On failure, the report ends with a summary of exactly which steps failed\n# and why — no scrolling through 2 minutes of output to find the error.\n```\n\nEach crate has its own `.pi/architecture/`\n\ndirectory with:\n\n**Module specs**— Detailed interface contracts for each bounded context** ADRs**— Architecture Decision Records explaining key design choices** Diagrams**— System context, data flow, deployment\n\nWe welcome contributions! Please read [CONTRIBUTING.md](/arman-jalili/rigorix-oss/blob/main/CONTRIBUTING.md) for our development process, coding standards, and pull request workflow.\n\nKey guidelines:\n\n- Every edit must pass\n`cargo clippy --workspace`\n\nand`cargo fmt --check`\n\n- All modules follow Clean Architecture with frozen contracts (see\n`.pi/architecture/`\n\n) - Run\n`cargo test --workspace`\n\nbefore submitting - New features require architecture documentation (see\n`.pi/prompts/feature-development.md`\n\n)\n\nLicensed under either of:\n\n- MIT license (\n[LICENSE-MIT](/arman-jalili/rigorix-oss/blob/main/LICENSE-MIT)) - Apache License, Version 2.0 (\n[LICENSE-APACHE](/arman-jalili/rigorix-oss/blob/main/LICENSE-APACHE))\n\nat your option.", "url": "https://wpnews.pro/news/show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running", "canonical_source": "https://github.com/arman-jalili/rigorix-oss", "published_at": "2026-07-01 01:17:41+00:00", "updated_at": "2026-07-01 01:49:42.300643+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models", "ai-safety", "ai-tools"], "entities": ["Rigorix", "Guardian Framework", "GitHub", "CI/CD"], "alternates": {"html": "https://wpnews.pro/news/show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running", "markdown": "https://wpnews.pro/news/show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running.md", "text": "https://wpnews.pro/news/show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running.txt", "jsonld": "https://wpnews.pro/news/show-hn-coding-agent-that-compiles-intent-into-deterministic-dag-before-running.jsonld"}}