Automation readiness contract

The privacy-safe product, release, reliability, and Foundry evidence contracts for CodeVetter.

Automation readiness contract

This page is the canonical inventory + contract matrix for CodeVetter’s automation readiness. It is the durable answer to “what evidence proves CodeVetter is releasable and diagnosable without centralizing reviewed code, repositories, prompts, or user API keys.”

It is the single home for:

• The surface inventory (landing, desktop, Rust, SQLite, MCP, benchmark, release/updater, docs, weekly canary).
• The privacy-safe product funnel contract (acquisition, download intent, activation, return) and the explicit not-applicable decisions.
• The release, reliability, and Foundry evidence contracts.
• The current baseline evidence (revisions, live landing, updater manifest, canary freshness).

Do not duplicate this matrix elsewhere — link here.

Surface inventory

Privacy-safe product funnel

CodeVetter’s product contract is local-first, no telemetry (see the “No telemetry” badge on the landing hero). The funnel is therefore defined as evidence that can be collected without transmitting reviewed code, repository content or identity, prompts, findings, file paths, user API keys, or local database contents.

Not-applicable decisions

Desktop activation/return tracking (2.2): Not applicable. The landing page explicitly markets “No telemetry” as a product feature. Adding centralized activation or return tracking would violate the product contract and the CSP (connect-src 'self' https://api.codevetter.com https://api.github.com — and api.codevetter.com is unused by the desktop app, reserved for landing proxy concerns). Local aggregate evidence stays in SQLite; the user owns it.

Privacy-safe crash/failure evidence (2.3): Not applicable for central transmission. local_reviews.error_message, repo_unpacked_reports.status, and the get_agent_observability command already record version/build + aggregate failure class locally. Transmitting failure classes centrally would require a new egress path and a new analytics surface, which is out of scope and against the product stance. The Foundry receipt (below) carries only sanitized aggregate counts, never error text or paths.

Release contract

Every release candidate MUST pass before release approval:

Release approval remains explicit. Automation prepares evidence and MAY open a corrective PR, but MUST NOT publish a release or alter product direction without explicit approval. See runbooks/cut-a-release.md.

Updater manifest validation

scripts/verify-release-manifest.mjs validates that the live latest.json manifest references a resolvable artifact with a present signature — without publishing a release. It is safe to run from any branch. It checks:

1. latest.json downloads from the updater endpoint.
2. The version field is non-empty and semver-shaped.
3. Each platform entry’s url resolves (HTTP 200) to a real release asset.
4. Each platform entry’s signature is non-empty.

It does NOT download the full artifact, verify the signature against the pubkey, or touch the release pipeline. Those are release-time concerns.

Scheduled canary freshness contract

weekly.yml runs every Monday 09:00 UTC and on manual dispatch. It MUST expose:

The canary is not a release gate and not a deploy trigger. It is a coarse “is anything obviously broken” signal. If it misses its freshness window (no successful run within 8 days of the cron interval), Foundry reports it stale and does not infer desktop health.

Foundry handoff contract

scripts/emit-foundry-receipt.mjs produces a sanitized aggregate receipt for Foundry. The receipt contains ONLY:

• project_slug (from foundry.json)
• generated_at (ISO timestamp)
• git_revision (main HEAD short SHA)
• desktop_version (from tauri.conf.json)
• ci_green (boolean — latest ci.yml conclusion on main)
• weekly_canary (object — last run timestamp, conclusion, freshness days)
• latest_release (object — tag, published_at, asset count, manifest valid)
• landing_live (boolean — https://codevetter.com returns 200)

The receipt MUST NOT contain: reviewed code, diffs, file paths, repository identity, prompts, findings, API keys, error message text, local database contents, or any user-identifiable information. The emitter loads only public metadata (git revision, tauri version, GitHub Actions status via gh, live landing HTTP status). A unit test (scripts/emit-foundry-receipt.test.mjs) proves that sensitive fixture inputs cannot appear in the receipt output.

Production release and production deploy remain explicit-approval actions; the receipt reports readiness, it does not trigger anything.

Current baseline (2026-07-19)

Out of scope

• No new analytics vendor.
• No server-side review pipeline.
• No automatic production release.
• No user-code collection, credential handling, or product feature work.
• No change to review behavior, CSP, or the “No telemetry” product stance.