feat(release): five-minute container quickstart via GHCR image

[tang-vu]

Summary

A maintainer can now evaluate ContribAI end-to-end in ~5 minutes with only a container runtime — no Rust toolchain, no config file, no GitHub token, no LLM key, and zero writes:

docker run --rm ghcr.io/tang-vu/contribai:latest demo
docker run --rm ghcr.io/tang-vu/contribai:latest demo --json

The demo command exercises the real production pipeline offline (consent → permit → admission → evidence → protected-path fail-closed probe → human-review gate → no submission), so the 5-minute path demos the safety model, not a stripped-down toy.

What changed

• .github/workflows/release.yml — new image job after release: builds the existing locked Dockerfile, smoke-tests the exact pushed image with the same --version and demo --json assertions the release binaries get (external_writes_enabled==false, submission=="not_attempted", candidate.evidence_valid, protected_path_probe.admission_allowed==false), pushes :<tag> + :latest to ghcr.io/tang-vu/contribai, and attests the pushed digest via the already-pinned actions/attest. Least-privilege job permissions (contents: read, packages: write, id-token, attestations); plain docker CLI so no new third-party actions.
• README.md / docs/QUICKSTART.md / docs/RELEASING.md / docs/deployment-guide.md — the quickstart now leads with the docker run path; RELEASING documents the new job and the one-time owner step (see below).
• .dockerignore (new) — build context trimmed to the locked workspace inputs the Dockerfile actually COPYs.
• _typos.toml (new) — allowlists ratatui; the existing typos hook otherwise rewrites the crate name to "Ratatouille" in any commit touching the README.
• crates/contribai-rs/src/cli/mod.rs — three tests pinning the read-only CLI defaults: contribute has submit:false, patrol has respond:false, --dry-run parses without --submit.
• crates/contribai-rs/src/exec/runner.rs — spawned workspace commands run with PYTHONDONTWRITEBYTECODE=1; the env allowlist now matches case-insensitively.
• crates/contribai-rs/src/core/admission.rs — repository_path_error now rejects drive-letter paths (C:/..., d:...).
• .github/workflows/ci.yml — the Test job installs pytest into the runner's python before cargo test (--user, with --break-system-packages as the PEP 668 fallback for the ubuntu image).
• Cargo.lock — rustls 0.23.43→0.23.45, rustls-webpki 0.103.13→0.103.15 (RUSTSEC-2026-0285).

Pre-existing issues fixed along the way (main CI was red)

Every CI run on main has been failing: all three Test jobs plus RustSec audit. Root causes found while verifying this branch — all fixed here, and this PR's CI is fully green:

1. Missing pytest on GH runners — the v7 e2e fixtures drive a real python -m pytest red-to-green leg, but runner images don't ship the module, so the run ended failed on all three OSes. The new ci.yml step installs it.
2. Stale-bytecode validation flake — a solver rewrite landing in the same mtime second with the same byte length left a __pycache__ that CPython's timestamp+size invalidation treats as valid, so a later check could observe pre-fix code. It failed closed (spurious repair — not a safety bypass). BoundedRunner now sets PYTHONDONTWRITEBYTECODE=1 for every spawned command; a regression test asserts pytest runs leave no __pycache__.
3. Windows env scrub dropped PATH — scrub_environment matched the allowlist case-sensitively, but Windows reports Path, so spawned commands got no PATH on Windows. The allowlist match is now case-insensitive and inserts the canonical spelling.
4. Drive-letter paths accepted on Unix — repository_path_error let C:/evil.rs through because Path::components sees normal components on non-Windows hosts — silent acceptance in the shared validator used by admission scope, evidence v3, solver paths, and RunWorkspace::resolve. Now rejected; the existing traversal test that asserted this passes on Linux.
5. RUSTSEC-2026-0285 — rustls 0.23.43 in the lockfile; bumped to 0.23.45 so cargo audit / the RustSec job pass.

What I did NOT change

• No safety gate was removed or weakened: manifest consent, capability flags (--submit/--respond), permit binding, protected paths, fail-closed checks, human review, draft-PR-only, MCP read-only — all untouched.
• No new release machinery: the image job extends the existing release workflow; the Dockerfile itself is unchanged.
• No new network surface for the CLI path — demo stays offline.

Owner action required (one-time)

After the next tagged release, the first GHCR push creates a private package. Set the contribai package visibility to public once (Package settings under the owner's GitHub profile → ghcr.io/tang-vu/contribai → Package settings → Change visibility), or external users can't pull. The Dockerfile's org.opencontainers.image.source label already links the package to this repo.

Verification

• cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings: clean
• cargo test --workspace --locked: 839 passed, 0 failed
• cargo build --workspace --release: clean
• node scripts/check-installers.mjs, node scripts/check-site.mjs, node --check site/app.js: pass
• docker build + docker run ... --version + demo --json assertions + full demo output: PASS locally
• PR CI: all 14 checks green (was: 3× Test + RustSec red on main)

AI-assisted (Devin); the reviewer should confirm the workflow permissions and the GHCR visibility step.

Link to Devin session: https://app.devin.ai/sessions/868648d1623d4933b5da68d5ee560e02
Open in Devin Desktop: https://app.devin.ai/desktop/session/868648d1623d4933b5da68d5ee560e02?variant=devin
Requested by: @tang-vu

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
contribai	Ready	Preview	Oct 3, 2026 4:43pm UTC