Skip to content

Accountability infrastructure for autonomous engineering

DoneState documentation

Guides, concepts, complete references, security boundaries, and operating help.

Hosted liveSource

DoneState docs / Reference

Contracts and versioning

DoneState has multiple public surfaces with different release cadences. A hosted MCP version, npm CLI version, verifier contract, repository schema, and distribution listing are related but not the same version.

Hosted MCP 0.3.0CLI 0.2.0 publishedVerification contract v2

Versioned surfaces

Hosted MCP

The remote service protocol and tool metadata. The current public server identifies as DoneState 0.3.0 and exposes 20 tools.

CLI package

The installable npm command-line surface. Version 0.2.0 is published with 20 documented commands and the portable capability-parity surface.

Verification contract

The cross-product DoneState ↔ independent-verifier response contract. New hosted objectives use donestate.verification-contract.v2.

Distribution listing

OpenAI and GitHub Marketplace provider state. Listing review or publication does not redefine the running owned-service version.

Hosted MCP contract

Tool names, input schemas, annotations, OAuth scope, and semantic behaviour form the public hosted MCP contract. The authoritative user-facing list is the MCP tool index.

Provider submissions can freeze a snapshot of that metadata. The owned service may continue operating independently, but changing a submitted tool contract must be handled as an explicit compatibility and distribution decision rather than silently pretending nothing changed.

Canonical endpoint
https://donestate.proofandstate.com/mcp

Verification contract v2

New hosted objectives and newly published local CLI subjects that use independent verification bind to donestate.verification-contract.v2. The response contains a machine-readable verification report plus a signed v2 attestation.

The report binds the run ID, base and expected head, verification nonce, handoff digest, requirement results, evidence references, and incomplete consequential actions. The attestation binds the signer, response digests, and final verifier decision.

Machine-checkable verification requirements

A verification requirement belongs to an acceptance criterion and describes an observation the verifier can make against the sealed repository subject.

path_exists

A bounded repository path must exist.

path_absent

A bounded repository path must not exist.

file_contains

A file must contain the specified bounded values.

json_equals

A JSON Pointer must resolve to the expected JSON value.

changed_files

The changed-file set must fit the specified path and count constraints.

github_checks_pass

Named GitHub checks must pass on the exact observed head.

Repository schemas and source reference

The DoneState source repository publishes JSON schemas, compatibility vectors, and contract documentation for local objective, execution policy, verification handoff, and verifier material. These are useful when you are building tooling around DoneState rather than driving it interactively.

Public schemas are designed to make boundaries inspectable. They do not contain live customer secrets or production credentials.

Compatibility rules

Do not assume transport-specific infrastructure belongs on both surfaces; portable consequence capabilities should remain equivalent while hosted identity/runtime services stay hosted-only.
Do not infer provider-directory publication from a live owned-domain deployment.
Do not rewrite historical run or verifier outcomes after a later successor succeeds.
Do not treat a schema-compatible verifier response as trusted unless signer identity and subject binding also validate.
Do not silently widen consequence authority when a new feature or integration becomes available.

Related reference