Developers

Run the public fixture or try BigBoss

Run a small public example of source correction, stale-work refusal and restored history. Then inspect what the recorded checks actually establish.

Run the Consumption fixture Review its results

Consumption Engine: public synthetic fixture

Run one correction and inspect the record.

Use Git and Python 3.11 or newer. No third-party Python packages or model account are required; the run needs no network after cloning. This separate demonstration package does not distribute the private product runtime or reproduce its studies.

Run the fixture and its checker

git clone https://github.com/thisisntjon/ce-stranger-replay-v1.git
cd ce-stranger-replay-v1
git checkout 8374bb6ee93edef37f57f284532d9487d5fd2e2d
python examples/public_demo/run_public_demo.py --output .tmp/public-demo-run
python examples/public_demo/verify_receipt.py .tmp/public-demo-run/RECEIPT.json --output .tmp/public-demo-run/ORACLE-DECISION.json

What to expect

The runner should report passed: true. The receipt checker should report accepted_automated_oracle. Keep the generated report and receipts, and choose a new output directory for a second run.

The lifecycle executes the correction and stale-snapshot checks, then checks an archive restored on the same machine. Other expected states, including UNKNOWN, are manually specified. Passing the receipt checker does not establish a fresh query for every case.

Full run instructions and scope. Current product and implementation.

For research collaborators

Review one public correction-and-restore contract.

A bounded first task is to run the released synthetic fixture twice from a fresh clone, using separate output directories, and inspect whether both receipts support the same declared outcomes.

Use the corrected review checklist, which keeps the released execution pin separate from newer guidance. Record the package commit, Python version and environment; no private runtime or model provider is required.
Check the fixture manifest and input hashes against the frozen oracles. Inspect the recorded change from 3 retries to 2, stale-snapshot refusal, separately checked successor. Distinguish those executed checks from the manually specified unsupported-question expectation.
Check the source-root-unavailable restore guard and compare both oracle projections. This guard does not establish physical clean-machine recovery.
Return a scoped decision or discrepancy report with the exact receipt and oracle hashes, reviewer context and commands. A passing verifier alone is an automated integrity result, not human acceptance or semantic truth.

Use the existing replay instructions, then discuss your findings or a follow-up. This task covers the public fixture only; it cannot reproduce the private paper-based studies.

Supporting software: BigBoss setup and integration

BigBoss: public supporting component

Local approvals with one human reviewer.

The instructions below run the public BigBoss approval tool on your computer. It is available separately from Consumption Engine.

The dashboard and SQLite store run on your machine. The default listener is local; phone access over your LAN is opt-in. A hosted service and multi-user administration are outside the current BigBoss implementation.

Approval sample

Requires Git, Python 3.12 or newer, uv, and a browser. The approval sample needs no model-provider keys. The Python application has no runtime package dependencies.

Live agent workflow

Requires a configured coding agent and a connector, called an adapter, that sends its actions to BigBoss for approval. Check which actions it covers before relying on it. Phone alerts require the browser page or installed web app to remain open.

BigBoss public repository, Runtime requirements, Deployment limitations

BigBoss sample: Windows PowerShell

Create a request, then inspect the decision.

These BigBoss commands use the source revision inspected for this site. Open two terminals; the server keeps running in the first. For macOS or Linux, replace the PowerShell environment assignment with export PYTHONPATH=src.

Start the dashboard

In the first terminal, clone the repository and start the server. It opens and pairs your local browser. The two interval settings disable optional background project scans and model-health checks for this sample.

git clone https://github.com/thisisntjon/bigboss-approval-plane.git
cd bigboss-approval-plane
git checkout 5615b729126cb829e3e5eedc209b71016eb231e2
$env:PYTHONPATH = 'src'
uv run python -m bigboss serve --port 8787 --intel-interval-hours 0 --squire-health-interval 0

Submit the sample
Open a second terminal in the parent folder where you ran the clone command. Then enter the repository and submit its built-in sample.
```
cd bigboss-approval-plane
$env:PYTHONPATH = 'src'
uv run python -m bigboss demo-request
```
Review the card
The sample proposes uv sync. Review the proposed action and make a decision in the dashboard. The sample creates an approval request; it does not install dependencies or execute the proposed command.

Repository quickstart, Sample proposal source, Sample command behavior

BigBoss: integration paths

Check which actions your integration covers.

An adapter connects a coding agent to BigBoss. The interfaces below support different workflows; review which actions they send for approval before choosing one.

HTTP, MCP, and hooks

Submit approval requests, wait for decisions, and send status updates. The Model Context Protocol (MCP) interface has no approve or reject tool. The hook adapter converts common agent event fields into the format BigBoss expects.

Adapter contract

Codex app-server

An experimental bridge handles command, file-change, and permission approval requests. The repository documents this as its enforced Codex path; project hooks do not provide that path under codex exec.

Bridge implementation

Claude permission prompts

A documented MCP permission-prompt route connects to BigBoss. The repository notes that headless mode can allow some actions without calling that route, so workflow coverage needs checking.

Setup and coverage notes

The repository lists no Cursor, Antigravity, OpenHands, or ACP adapter. Additional agent integrations would need to be built and tested.

BigBoss: security boundary

What an approval record can establish.

What the record establishes

A request carries a hash of its action, workspace, and policy version. The stored decision identifies the request and enrolled device. The adapter must match execution to the approved proposal.

The decision history alone does not prove execution or successful completion, and the SQLite store is not a tamper-evident ledger.

What the operator must provide

Keep the coding agent isolated from the approval API. Current source restricts JSON pairing-code access, but a local process that can spoof browser-navigation headers, read the admin token, or share the operator's OS user can still enroll.

The approval workflow does not provide host isolation.

Security model for this version, Repository security guidance

BigBoss: versions and checks

Keep the source and its results together.

The tagged BigBoss release covered here is v0.1.0, at 10acc53. This guide uses later source 5615b72 from September 19, 2026. That commit is an inspected revision, not a new release.

To run the BigBoss test suite from either revision, check it out, set PYTHONPATH as above, then run:

uv run --with pytest python -m pytest -q

Versioned test evidence, Public change history, Report your results