One-Box — describe work, inspect a plan, follow the evidence

New: actual computer-work evidence. Run the supplier-desk lab to watch an isolated browser compare quotes, export deliverables, and have a separate rule-based reviewer accept or reject the recommendation. Then follow the OpenClaw / Codex Computer Use integration guide for an explicitly admitted live worker. A guided AGI Jobs workspace for learning the job lifecycle and operating a configured deployment. Start with the offline preview: no wallet, API key, Docker or blockchain is needed. Move to connected mode only after checking your deployment.

Try the browser preview · Demo observatory · Static console source · One-Box CI

Choose your path

The preview is a teaching model. It produces no real work, independent review, funds transfer, blockchain receipt, maintainer signature or production approval. The current connected service supports post job and finalize, plus status and governance previews. Assignment, submission, review and disputes in the preview demonstrate the wider lifecycle; they are not claims that those connected API actions are implemented here.

Start in three commands

From a checked-out repository root, select the version in .nvmrc (currently Node.js 22.23.3), then:

nvm use
npm ci
npm run demo:onebox:launch -- --demo

Open the printed local URL if the browser does not open automatically. The console binds to 127.0.0.1:4173. Use --no-browser on remote terminals, or --ui-port 4174 if that port is occupied. Press Ctrl+C to stop. --help lists supported options; unknown options and malformed ports fail with an explanation.

After installation, the preview uses local assets only. Its server enforces connect-src 'none': API, RPC and provider requests are disabled even if an old endpoint is saved in your browser. Jobs and approvals reset on reload. Export evidence before leaving.

Your first complete mission

Choose Review mission plan in the prominent guided mission. Each action opens an accessible confirmation dialog with the exact plan; cancelling or pressing Escape changes no job state. After confirmation, the mission explains the next step and returns keyboard focus to its action button.

The mission asks: Can this fictional release ship? Its three bundled sources cover regression tests, a recovery rehearsal and an independent security review that is still pending. No actual repository or deployment is assessed.

Try a failure and recovery: after assignment, open Mission evidence and choose Remove a citation. Submit and validate: the missing citation produces a rejected review and named failed checks. Choose Restore sample, resubmit, validate and finalize. Both submissions and both reviews remain in the exported history. Editing is locked while confirmation or review is pending. A cancelled submission preserves your draft.

The checks execute locally over synthetic sources. They check structure, citation coverage, exact result matching, the hold recommendation, explanation presence and a next action. They do not independently verify the explanation's truth, audit code, sign a release or settle funds. An accepted report correctly continues to recommend HOLD until the fictional independent review is complete.

Start another guided mission after completion; a selector lets you revisit earlier missions without deleting their evidence. Everything is session-local and resets on reload. Pending preview approvals expire after 15 minutes; sessions are bounded to 200 jobs, 2,000 events and 1,000 outstanding plans.

Explore a custom mission

The original suggested prompts above the composer run this example. Send each request, inspect the plan and choose Confirm plan or Cancel. Typing YES or NO also works in the command-box flow. Preview commands start with Post/Create, Apply, Submit, Validate/Review, Finalize, Status/Check or Dispute; lifecycle actions include a positive whole job number. Unrecognized commands are rejected instead of silently creating jobs.

Explore a failure: finalize immediately after step 1. The console rejects it and leaves the job unchanged. Continue with steps 2–5. Alternatively, use Validate job 1 reject after submission, followed by Dispute job 1. Check any job with Status job 1. A cancelled plan changes no job state. Each confirmation is usable only once.

Find your way around: the status board follows your jobs; Advanced shows the plan, response and endpoint configuration; the expandable Owner governance controls retain the parameter and proposal tools without crowding the first-run experience. Use keyboard Tab/Enter for controls and focus the conversation to scroll it. On small screens the controls stack vertically.

Preview accepts text only and disables file selection. Its hosted Advanced settings explain why no credentials are needed and keep connection controls disabled. Attachment-aware connected ICS plans retain the IPFS upload flow. A job-intent response cannot silently accept an unsupported attachment: the console explains the limitation, keeps the files queued, and Clear attachments lets you continue without uploading them.

Connect a local or test deployment

1. Copy .env.example to .env inside this directory, then replace every placeholder. The launcher reads root .env, then this demo's .env, then exported shell values; explicit CLI options win. Do not commit credentials.
2. Configure RPC_URL, CHAIN_ID, JOB_REGISTRY_ADDRESS, STAKE_MANAGER_ADDRESS, SYSTEM_PAUSE_ADDRESS, ONEBOX_RELAYER_PRIVATE_KEY and ONEBOX_API_TOKEN. Generate a private API token with node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))". Use a dedicated, limited local/test relayer and verify its funding and contract permissions.
3. Configure ALPHA_ORCHESTRATOR_URL / ALPHA_ORCHESTRATOR_TOKEN for the planner and a reachable IPFS_API_URL or the pinning credentials supported by the execution service. Without a remote planner endpoint, PlannerClient uses limited local heuristics and labels that source. This is not a real provider integration. Pinning and chain operations still require actual services.
4. Run the read-only doctor before starting the servers:

npm run demo:onebox:doctor -- --strict
npm run demo:onebox:launch -- --no-browser

The launcher builds the static UI and packaged server, checks RPC chain identity and configured contract bytecode, then waits for health and authenticated job status before announcing readiness. Failed startup stops its child process; unexpected backend exit stops the UI. The strict doctor also checks gas balance, owner/pause reads and port availability. Unresolved reads and unmet prerequisites fail the strict check; passing is not a security audit or target-network commissioning.

In the browser, open Advanced → Set API token and enter the same backend token into the masked, keyboard-accessible dialog. It stays in page memory and clears on reload or endpoint changes. Launch links and public runtime assets never contain the token. Older saved API tokens are removed. The UI endpoint/prefix preferences can persist; bearer credentials do not.

To prepare calldata without submitting it, launch with --mode expert. The destination, chain and calldata appear in Advanced; the UI explicitly says no transaction was sent. Review and submit through your wallet separately. Guest mode can submit through the configured relayer after confirmation.

Connected approvals bind the complete intent, expire after 15 minutes and are consumed before execution begins. A repeated, changed, expired or unknown approval fails closed. One-Box keeps at most 1,000 outstanding approvals in a single server process; restarting invalidates them. Interrupted execution, empty responses and HTTP 5xx responses display Execution outcome is unknown, rather than reporting success or prompting a blind retry. After any ambiguous network/provider failure, inspect status, receipts and the chain before creating another plan. This prevents blind retries; it does not provide distributed, exactly-once settlement across replicas.

Both local servers bind to loopback by default. CORS permits the configured UI origin. For deliberate remote access, use authenticated HTTPS infrastructure and an explicit ONEBOX_CORS_ALLOW allowlist; do not expose a funded relayer as an unauthenticated public demo.

Docker path

Compose 2.24+ supports the optional environment files used here. From the repository root:

docker compose -f demo/One-Box/docker-compose.yaml up --build --wait

Open http://127.0.0.1:4173. This starts only the offline UI, running as an unprivileged user with a read-only filesystem. No secrets are written into browser assets. The UI image supports PORT at runtime.

For the disposable local connected stack, first review your local deployment configuration. make -f demo/One-Box/Makefile bootstrap starts the pinned Anvil image and invokes the existing local deployment wizard. Configure the resulting addresses, planner, pinning, API token and funded relayer; inspect pause state and owner permissions. Generated deployment-config/oneclick.env values are loaded before the demo .env; JOB_REGISTRY and STAKE_MANAGER aliases are accepted by the backend. Bootstrap is an operator deployment step, not a substitute for reviewing these prerequisites.

Set ONEBOX_PUBLIC_ORCHESTRATOR_URL=http://127.0.0.1:8080 in the demo .env, then:

docker compose --env-file demo/One-Box/.env -f demo/One-Box/docker-compose.yaml --profile connected up --build --wait

The browser uses the host API URL; container-to-container RPC uses http://anvil:8545. Published ports remain bound to loopback. Anvil state is disposable: restarting/recreating it can invalidate deployed addresses. Re-deploy and re-check before use. down keeps the orchestrator volume; make ... clean explicitly deletes demo volumes while retaining .env.

Troubleshooting

Systems Map

flowchart LR
    Operators((Mission Owners)) --> demo_One_Box[[Demo → One Box]]
    demo_One_Box --> Core[[AGI Jobs v0 (v2) Core Intelligence]]
    Core --> Observability[[Unified CI / CD & Observability]]
    Core --> Governance[[Owner Control Plane]]

The original systems map is retained. The concrete demonstration connects operator intent, an inspectable plan, execution outcomes and owner oversight. Real-world readiness additionally requires authentic maintainer signing, configured providers, independent security review, operational monitoring and target-network commissioning; the preview and automated fixtures do not certify those milestones.

Directory guide and verification

npm run demo:onebox:test
npm run build:orchestrator
node --test apps/orchestrator/dist/apps/orchestrator/__tests__/{oneboxRouter,planApprovals}.test.js
npm run onebox:static:build
npm run verify:sri
npx playwright install chromium
npm run demo:onebox:qa

The browser check exercises cancellation, lifecycle ordering, guided report editing, failed-check recovery, immutable submission history, Markdown/JSON exports, confirmation/token dialogs, denied browser storage, ambiguous execution outcomes, reload behavior, mobile overflow, WCAG AA checks and the actual packaged HTTP router with synthetic provider/chain service results. Reports and screenshots go to reports/onebox/. CI additionally builds and starts the read-only Docker UI and verifies the connected container startup. These checks are scoped evidence, not an independent audit.

Changes should land through a reviewed pull request with required checks green. Consult RUNBOOK.md and OperatorRunbook.md for operational ownership and escalation. Keep secrets outside source control, preserve diagrams and useful operator materials, and link release evidence through the repository's existing release-manifest process.