Option A: Install a CLI tool

<p align="center">
  <img src="https://raw.githubusercontent.com/openexec/.github/main/profile/logo.svg" alt="OpenExec Logo" width="160"/>
</p>

<h1 align="center">OpenExec</h1>

<p align="center">
  <strong>Executable engineering judgment for AI coding tools</strong>
</p>

<p align="center">
  <img src="https://img.shields.io/github/v/release/openexec/openexec?style=flat-square&color=orange" alt="Version"/>
  <img src="https://img.shields.io/github/actions/workflow/status/openexec/openexec/go.yml?style=flat-square" alt="Build Status"/>
  <img src="https://img.shields.io/badge/go-%2300ADD8.svg?style=flat-square&logo=go&logoColor=white" alt="Go"/>
  <img src="https://img.shields.io/badge/license-MIT-blue.svg?style=flat-square" alt="License"/>
</p>

---

## What Is OpenExec?

Can expert engineering judgment become executable?

Most engineering expertise is tacit. It lives in senior engineers' heads: where to look first, which files not to touch, which tests actually matter, when a shortcut is acceptable, and when a change must stop for human review.

AI coding tools can generate code, but they do not automatically inherit that judgment. Left alone, an agent can read too much, touch the wrong surface, retry unpredictably, skip implicit checks, or leave behind a confident summary instead of evidence.

OpenExec is a deterministic runtime for AI coding tools. It wraps Claude Code, Codex, Gemini CLI, or any OpenAI-compatible API in executable structure: blueprints, scoped tools, quality gates, checkpoints, memory, policy, approvals, and audit trails.

The model still reasons. OpenExec governs the run.

In practice, you give OpenExec a scoped task or a higher-level intent, and it plans the change, builds it through a blueprint (gather context → implement → lint → test → review), runs your quality gates, and leaves you on a branch with a recorded audit trail to open a pull request from. The bottleneck was never coding speed; it was trusting what a change actually did — so OpenExec optimizes for evidence, not just output. The same engine scales from a single task to an entire greenfield project.

Turning tracked GitHub (and, on the roadmap, Jira) issues into PRs *automatically* — issue intake, unattended triage, opening the pull request for you, per-PR risk and operability review, and release-governance sign-off — is a **separate commercial product built on this core**, not part of the open-source engine. This repository is the engine; it pushes branches and records PR metadata, but it does not connect to your issue tracker or open PRs on its own.

## The Thesis

OpenExec treats AI work as an engineering process, not a chat session.

Documentation can explain expert judgment. Checklists can remind people to apply it. OpenExec tries to encode more of that judgment as reusable runtime behavior:

- **Blueprints** capture repeatable workflows.
- **Tool policies** limit what an agent can see or change.
- **Quality gates** make tests, linting, formatting, and review explicit.
- **Checkpoints** preserve intermediate state for recovery and inspection.
- **Memory and skills** carry lessons from previous work into future runs.
- **Audit trails** record what happened, not just what the agent said happened.

That is the product boundary: OpenExec is not the agent. It is the control plane around the agent.

## Current Scope

OpenExec is intentionally factual about what exists today and what remains architectural direction.

**Shipped or implemented in the repository:**
- Single-binary Go runtime with CLI, TUI, embedded web UI, and MCP server surfaces.
- Blueprint execution for staged work such as gather context, implement, lint, test, and review.
- Provider adapters for local AI CLIs and OpenAI-compatible HTTP APIs.
- Context assembly, pruning, skills loading, memory, caching, checkpointing, and predictive loading packages.
- SQLite-backed state, audit, approval, budget, telemetry, and PII scrubbing components.
- SRE-oriented safety primitives including allowlisted infra tools, Terraform plan inspection, and approval gates.

**Still maturing:**
- End-to-end replay and durable recovery UX.
- Production polish for the web console and operator workflows.
- Organization-wide policy distribution.
- Large-scale distributed agent and backlog coordination.

The direction is ambitious, but the core idea is narrow: make AI execution inspectable, bounded, repeatable, and easier to improve.

## How It Works

```
openexec init          # Configure project (model, settings)
openexec run           # Execute tasks via blueprint pipeline

Execution Flow:
  CLI -> Manager -> Pipeline -> Blueprint Engine -> AI CLI or API Provider
                                    |
                      gather_context -> implement -> lint -> test -> review
```

### Three Execution Modes

| Mode | Description | Side Effects |
|------|-------------|--------------|
| **Chat** | Conversational, no side effects | None |
| **Task** | Scoped action, produces artifacts |

... (truncated)