CritiqueCode 2.0: The Harness Decides What Is True

Take a requirement such as “users with expired sessions must be redirected.” A normal coding agent edits a file, runs a test, and reports success. CritiqueCode assigns the requirement an identity. The check request gets its own identity. The controller resolves the executable and policy, captures the repository state, runs the check, parses the observation, and decides whether that observation actually bears on the requirement. A passing command with no semantic edge stays supporting context. It does not become proof by enthusiasm.

The model proposes. The controller establishes.

The central change is separation of authority. Pi remains the inference and session layer. It can explore, plan, write, and request checks. It cannot choose an executable for a controlled check, mint a valid proof receipt, declare a stale result current, or turn its own review prose into Evidence. Those decisions live in CritiqueCode.

Requirements carry proof policies. Behavioral work needs behavioral evidence. Compatibility work cannot be certified by a focused test for the new feature alone. Type checking can support structural claims without being promoted into proof of runtime behavior. A green result from the wrong request, wrong workspace digest, weak evidence class, or unrelated target is rejected by the binder.

A real author state machine

CritiqueCode now tracks the work through Intake, Explore, Plan, Implement, Validate, Replan, Review, Repair, and Final Verify. The phases are controller records with guarded transitions. Review cannot jump over missing requirement evidence. Repair returns to validation. A workspace change makes prior requirement proof stale. A quiet review is necessary context, not a completion shortcut.

The task compiler keeps explicit acceptance criteria as the blocking contract and turns uncertain repository implications into exploration hypotheses. The plan binds each requirement to expected paths, symbols, tests, and validation capabilities. Scope drift produces a controller risk signal before the write is accepted. This gives the author freedom inside a phase while keeping correctness boundaries outside the model.

The workspace is observed, not assumed

Every CAS write, structured TypeScript edit, approved command, repair application, undo, and external edit crosses a shared workspace boundary. CritiqueCode captures before and after state, calculates the real path delta, and records mutation ownership. If a tool throws after changing a file, the change is still observed. If the user edits the same file before rollback, compare-and-swap protection reports a conflict instead of overwriting the user.

Structured edits add a narrower path for TypeScript renames, expression replacement, and class-member insertion. They preview against an exact content digest and reject ambiguity. General commands remain approval-gated and are wrapped in workspace reconciliation because a model’s claim that a command is read-only is not an enforcement mechanism.

When code changes, proof has to be scoped again

A source edit does not justify rerunning every test by reflex, and it does not justify trusting yesterday’s green run. CritiqueCode begins with the requirement, changed paths, planned symbols, relevant tests, public callers, and risk signals. It runs the focused proof first; compatibility, public API, configuration, workflow, migration, security-boundary, and elevated-risk changes add a required project regression tier. High-risk work also requires managed coverage or mutation evidence. If a required capability is unavailable, the run is unverified rather than quietly green.

A qualifying author check creates a deterministic Evidence record in the canonical registry and links it back to the requirement validation. The record includes the task revision, request and check identities, repository state, relevant paths, output digest, tool version, and implementation surfaces. Replaying the same receipt is idempotent. If the workspace changes, the registry reconciles against the new state; a receipt survives only when its Evidence, confirmed claim, task revision, requirement identity, proof policy, and live digest still agree.

Headless without a second agent

critique-code author --headless --task task.json --result result.json drives the same local author loop used by the interactive product. The artifact carries the compiled requirements, phase history, plan, checks, validations, review and repair records, patch summary, provider generations, costs, termination class, and limitations. Infrastructure failure, timeout, budget exhaustion, and incomplete verification remain distinct outcomes.

That adapter also makes CritiqueCode measurable as a coding agent. The Mercury harness integration consumes native controller artifacts and authoritative provider-generation identities instead of reconstructing an agent run from terminal text. Cost is marked complete only when every generation has a reconciled provider receipt.

Review gets better because authoring gets stricter

The independent reviewer still receives the repository and task, with the author transcript withheld. The difference is what surrounds that review. Repository Intelligence maps relevant symbols, callers, tests, and unresolved edges. Scheduled validation runs focused requirement checks and risk-triggered project checks. Differential validation can compare baseline and candidate behavior. A promoted repair candidate must pass its verification portfolio before it can touch the author workspace.

Evidence is a floor, not a substitute for domain controls

For high-frequency trading, payments, healthcare, or any system where a subtle defect is expensive, general software checks are necessary and insufficient. The task contract needs domain invariants: latency bounds, order-lifecycle rules, limits, reconciliation properties, and the historical or simulated data that can challenge them. CritiqueCode can bind and preserve those checks as evidence; it cannot invent the invariants or claim that a generic test suite makes a domain-safe system.

What the 2.0 label commits us to

The 2.0 name should mean more than a large diff. The transaction journal restores arbitrary bytes, modes, and links. Evidence survives restart only with replayable provenance. Required unavailable checks block verification. Headless artifacts preserve distinct initial and final workspace states. The remaining release work is contract amendments, structured reproduction replay, and a locally verifiable completion certificate. This is CritiqueCode 2.0, with those final trust surfaces still being built in public.

That standard is deliberate. CritiqueCode is built around the claim that a harness should catch mistakes a smarter model still makes. The release itself has to live by the same rule.