dryforge

A bounded-autonomy plugin harness for Claude Code and Codex.

Install and Update

Claude Code

/plugin marketplace add fn-opt/dryforge
/plugin install dryforge

Codex

codex plugin marketplace add fn-opt/dryforge
codex plugin add dryforge@dryforge

Updates

Codex checks for new releases at the start of each new session and applies them automatically.

Claude Code updates automatically when auto-update is enabled for dryforge under /plugins -> installed -> dryforge -> auto-update. Otherwise, update manually:

# Claude Code
/plugin marketplace update dryforge
/plugin update dryforge@dryforge

# Codex
codex plugin marketplace upgrade dryforge

System Definition

dryforge is not a bundle of a planner, an orchestrator, and a memory system. Those labels describe components, but they miss the system they implement.

dryforge is a bounded-autonomy plugin harness for capable coding agents. It provides an execution environment in which the model's decision authority, sources of truth, completion evidence, and persistent project context have explicit boundaries.

The model still does the reasoning. dryforge does not replace judgment with a prescribed workflow or attempt to enumerate every case the model may encounter. It defines the conditions under which judgment is safe to exercise:

This separation matters because agent failures are often authority failures disguised as reasoning failures. A model may infer an unstated product rule from a familiar pattern, treat current code as proof of intended behavior, reinterpret a specification to fit an easier implementation, or accept its own summary as evidence that the work succeeded. Each step can sound reasonable in isolation while moving the result away from the user's intent.

dryforge keeps those sources distinct and resolves conflicts deliberately. The user owns intent. The specification owns required behavior. Existing code provides implementation facts, not automatic product authority. Evidence, not confidence, owns completion.

The current specification and the project harness operate at different scopes. The specification governs one task; the harness governs durable project constraints. If a task must change an existing project constraint, neither source silently overrides the other. The user approves the change and both are brought back into agreement.

flowchart LR
    I["User intent"] --> R["ready"]
    R --> C["Executable contract"]
    C --> G["go"]
    G --> V["Verified change"]
    G --> H["Project harness"]
    H -. "context for the next cycle" .-> R
    C -. "archived after approval" .-> A["Local contract archive"]

    E["Existing codebase"] --> M["migration"]
    M --> H

The plugin exposes three explicitly invoked entry points into this operating model:

Structural Failure Model

Modern coding models are already capable of producing substantial implementations. The recurring problem is not simply insufficient model capability. It is the structure around that capability.

An ordinary session begins with an input that is necessarily incomplete. The model fills gaps from training priors and the visible codebase, implements the resulting interpretation, evaluates the work from the same perspective that produced it, and leaves important rationale in a transcript. If the interpretation was wrong, the expensive correction happens after code exists. If the implementation was accepted, the next session inherits the code but not necessarily the reasons, rejected alternatives, operating constraints, or domain rules behind it.

Several failure pressures reinforce one another:

dryforge treats these as related system problems. Clarification, specification, execution, verification, and durable context are designed around a shared authority model rather than connected as independent utilities.

Bounded Autonomy

Bounded autonomy means that the model has broad freedom inside an explicit authority boundary and no permission to silently move that boundary.

This is different from both a bare agent and a highly prescriptive harness. A bare agent has too much freedom at the point where the user's meaning is still incomplete. It can turn plausible defaults into invisible requirements. A prescriptive harness has the opposite problem: when the procedure becomes too detailed, the model can optimize for the procedure instead of the work.

dryforge uses a floor rather than a ceiling. It fixes the minimum conditions that must hold: intent must be grounded, behavior must have an authority source, dependencies must be explicit, completion must have evidence, and durable project knowledge must survive the run. Above that floor, the model remains free to reason, investigate, choose implementation techniques, and adapt to the actual codebase.

The floor is selective. Prose stays flexible where flexibility improves reasoning. Structure becomes rigid only where another process must consume it deterministically, such as the dependency graph used for execution. A requirement is recorded once at the correct authority level rather than repeated across several checklists that can drift apart.

The floor is also proportional. A small mechanical edit should not pay the coordination cost of a risky multi-part change. A thin idea, however, does not justify a thin specification: when less can be derived from the input, more intent must be established before implementation begins. Cost is reduced by removing work that does not change the outcome, not by lowering the evidence required for the outcome.

Operating Lifecycle

For new work, ready and go form one continuous cycle:

ready -> contract approval -> go -> result approval -> archive -> next cycle

The first cycle does more than describe the immediate task. It also captures the project-wide context needed to make the implementation coherent and to create the initial project harness. That context informs the work but does not expand the task's implementation scope.

On later cycles, ready begins from the existing harness and establishes authority only for the new change. After execution, go checks the completed implementation against the harness in both directions: project constraints must still be honored, and any constraint intentionally changed by the task must be updated where future agents will read it. Only the affected project context is revised.

ready and go are designed to run in the same session, but the executable contract remains the authority between them. The live conversation can help judgment; it cannot substitute for a missing or incomplete contract.

For an existing codebase, migration runs first as a separate onboarding cycle. Once the initial harness is established, the project joins the same ready -> go lifecycle as new work.

From Intent to Authority

ready converts input into implementation authority. It is not a plan formatter and does not assume that a detailed input is correct merely because it is detailed.

Every input begins as material: an idea, a requirements document, a draft plan, ge