Code repair — fixing supported defects in your own Rust code

EARL diagnoses, constructs and verifies supported repairs in the Rust code you designate, and applies them only when you approve. No external LLM writes the patch: the engine's own decision logic locates the defect and constructs the change from taught operator meanings plus the requirement you supply.

This is a developer preview. Read the limits at the bottom before you rely on it.

Supported repair classes

kind	what it repairs
`operator_substitution`	a wrong comparison or arithmetic operator in a designated function
`guard_construction`	a missing leading guard, `if <left> <op> <right> { return <value>; }`

Anything else returns a clear non-repair result. The platform never emits a patch outside these classes, and a candidate that fails your acceptance tests is not adoptable.

What you provide

A project. A .tar.gz of the crate, uploaded to the workflow (repair/connect).
A designation. The target file and function, the files EARL may change (designated_files), the command that runs your acceptance tests, and the requirement:
for operator_substitution, a contract: for each structural role, the meaning it must realize, e.g. [{"role":"filter_predicate","kind":"comparison","required_meaning":"strictly_less_than"}, {"role":"combine","kind":"arithmetic","required_meaning":"product"}]
for guard_construction, the guard spec: left, cond_meaning, right, return_value.
Your approval, before anything is applied.

Supplying the requirement is deliberate: it is your statement of intent. Inferring it from prose or from the code is a different capability and is not part of this preview.

The workflow

In the UI: Build → Code Repair. Through the API, on an application's bound workflow:

POST /api/v1/workflows/{id}/repair/connect     {"archive_b64": "<base64 .tar.gz>"}
POST /api/v1/workflows/{id}/repair/designate   {target_file, target_function, repair_kind,
                                                designated_files, acceptance_test_cmd, contract|guard}
POST /api/v1/workflows/{id}/repair/diagnose    {}            # proposes; adopts nothing
GET  /api/v1/workflows/{id}/repair/proposals
POST /api/v1/workflows/{id}/repair/adopt       {"proposal_record_id": "...", "confirm": true}
POST /api/v1/workflows/{id}/repair/rollback    {}
GET  /api/v1/workflows/{id}/repair/status

Through the packaged Python SDK (platform/sdk/python), which is the documented path for repeating this on your own defects:

from earl_sdk import EarlClient

wf = EarlClient("https://platform.jou-labs.com", token).workflow(WORKFLOW_ID)

wf.repair_connect("./my-crate")                     # packs the directory, excluding target/ and .git
wf.repair_designate(
    target_file="src/lib.rs", target_function="scaled_below",
    repair_kind="operator_substitution",
    designated_files=["src/lib.rs"],
    acceptance_test_cmd=["cargo", "test", "--quiet"],
    contract=[{"role": "filter_predicate", "kind": "comparison", "required_meaning": "strictly_less_than"},
              {"role": "combine", "kind": "arithmetic", "required_meaning": "product"}])

proposal = wf.repair_diagnose()                     # proposes; adopts nothing
print(proposal.result["outcome"], proposal.result["diff"])

if proposal.result["outcome"] == "repair_proposed":
    wf.repair_adopt(proposal.record_id, confirm=True)   # your approval; snapshots first
    wf.repair_rollback()                                # byte-identical restore of YOUR source

wf.repair_status() reports what is connected, designated and adopted. Every call returns the signed record, and EarlClient.verify_offline(...) (or deploy/verify_signed_record.py) checks it without trusting the platform. Workflow.REPAIR_CONTRACT states in one place what the capability does and does not do.

Diagnose runs over a contained copy of your project: the parser enumerates candidate expressions, the engine locates the defective one and constructs the patch, and your acceptance tests are compiled and run against the patched copy. Your live project is untouched, and the result is a reviewable proposal with the unified diff.
Adopt requires confirm: true. Preservation is re-checked on a copy first and recorded separately; then the project is snapshotted byte for byte; then the patch is applied.
Rollback restores that snapshot byte-identically.

Every step is an append-only, Ed25519-signed workflow record — connect, designation, each diagnose, preservation, adopt, rollback. The signature establishes integrity and attribution, not that a verdict is true.

Reading the outcome

outcome	meaning
`repair_proposed`	a candidate was constructed and verified against your tests; adoptable
`candidate_rejected`	a candidate was built and checked, and it failed your acceptance/preservation tests; not adoptable
`non_repair: no_defect_detected`	your acceptance tests already pass; nothing proposed
`non_repair: unsupported_repair_kind`	outside the supported classes
`non_repair: target_not_designated`	the target file is not in `designated_files`
`non_repair: verification_infrastructure_unavailable`	the platform could not build or run your tests. This is a platform build-toolchain fault — not a failing candidate and not a defect in your code. Nothing is adoptable until verification works again.

That last row matters: a verifier that cannot run is reported as a platform fault, never as a rejected repair.

Isolation of your build

Verifying a candidate means compiling and running your code — your build.rs, your test bodies. So the build does not run on the platform. It runs in a disposable container created for that one verification:

Nothing of the platform is in it. A copy of your contained project is placed inside with docker cp. There is no bind mount and no volume, so the platform's filesystem — the evidence signing key, the platform database, other tenants' storage — is not present in that container at all.
No network (--network none). Your build cannot reach the internet, the platform, or any other container. This means dependencies are not downloaded: a crate that needs to fetch from crates.io will fail to build. Vendor your dependencies, or use a dependency-free crate, for this preview.
No capabilities, no privilege escalation (--cap-drop ALL, --security-opt no-new-privileges), with memory, CPU, PID and wall-clock ceilings.
Removed afterwards, pass or fail.

The properties actually in force are recorded in the isolation block of every verification, so you can read them off the evidence rather than taking this page's word for it.

If the sandbox cannot be started, verification reports non_repair: verification_infrastructure_unavailable and nothing becomes adoptable. It does not fall back to running your code anywhere else.

History, stated plainly. Before 25 September 2026 this preview compiled and ran customer code inside the platform's backend container, where the evidence signing key, the platform database and other tenants' storage were readable by it. Scrubbing environment variables — which is what the guide then described — did not address that. It was found in evaluation before any customer connected a project, and the build was moved into the sandbox above. Operators running their own instance must be on a build dated 25 September 2026 or later, with EARL_REPAIR_BUILD_SANDBOX=docker (the default). The value none runs customer code in-process and exists only for local development; the evidence it produces says so in its isolation block.

Limits of this preview

Autonomous initiation is not available. Repairs are initiated by you, through the UI or the API. EARL does not start them on its own. That is a separate, unfinished capability.
Human-approved adoption is by design, not a placeholder — adoption stays behind your confirmation.
Only the two classes above. Broader repair shapes are added explicitly, class by class.
The requirement (contract or guard spec) is supplied by you; it is not inferred.
Demonstrated on operator substitution and guard construction over small, single-crate Rust projects with the target function in a designated file. It is not a general program-repair system.