Repository guide · 0 diagrams

View source on GitHub ↗
Original documentation, preserved from the repository. Historical projections and scenario ambitions are not evidence of live performance. See the current readiness record for deployment requirements.

Current production readiness

This is the stable entry point for deployment status. Dated reports describe the exact checks and limitations observed at the time; they are not perpetual production certifications.

What can be used now

The public website provides the complete preserved demo collection, guided experiences, original diagrams, browser workbenches and a local job planner. The repository supplies executable local-chain workflows and an operator-admitted OpenClaw computer-work adapter. These capabilities require their documented environments and have distinct evidence boundaries.

The local evidence reviewer checks delivered artifact integrity against the original task and records an unsigned reviewer assessment. It does not authenticate provider provenance or satisfy independent acceptance by itself. The adapter rejects malformed UTF-8, invalid Unicode strings and text artifacts exceeding 128,000 UTF-8 bytes.

What a live deployment still needs

Gate Evidence needed
Release trust Authorized maintainer signing identities and verified release artifacts
Merge enforcement Active repository rules requiring the intended checks and review policy, verified against GitHub configuration
Security Independent review, current dependency findings resolved or explicitly assessed, and validated provider configuration
Worker commissioning An isolated real runtime with verified permissions, account selection, action/network policy, spending limits, stop behavior and representative success/rejection cases
Independent acceptance Reviewers qualified for the work category, conflict disclosures, reproducible checks and actual buyer acceptance
Network commissioning Correct token/chain/addresses, deployment and ownership verification, identity/tax/stake prerequisites, monitored settlement and tested recovery
Recovery Reconciled uncertain actions, durable dispatch/settlement journals and a validated procedure for lost validator reveal secrets

The agent:validator rehearsal example now persists private, deployment-scoped reveal secrets before broadcasting and reconciles retained records after restart. Its explicit fixed decision is a rehearsal input, not an independent content assessment; see the validator quickstart. Other validator paths require separate recovery commissioning: apps/orchestrator/service.ts retains an in-memory commit map, gateway validators use a separate persisted-record format, and apps/validator/index.ts records secrets after broadcast without an automatic restart scan. The service/gateway protocol corrections and this example's journal do not certify those recovery paths. Computer-work evidence requires independent acceptance and is not automatically approved by structural validation. Legacy Web3.Storage publishing routes also remain dependent on a retired provider API until migrated and commissioned. The static GitHub Pages site does not use that API.

The current contract commit entry point accepts an opaque hash without an expected-round argument. Client-side scope checks protect saved secrets and refuse inconsistent reveals, but they do not provide contract-level isolation for a transaction that mines across an administrative round reset. Reconcile in-flight transactions before reset/reselection; complete epoch-bound transaction rejection requires a separately versioned protocol change and deployment review. This update does not certify that mempool boundary.

The production release workflow enforces npm run release:audit-dependencies before publishing release artifacts. It audits all tracked npm and pnpm production lockfiles, preserves raw registry responses and exact input hashes, and fails on critical/high findings, malformed responses or unavailable audit evidence. A passing website deployment does not bypass this release gate. The current root findings require supported upstream fixes or a tested migration; forcing incompatible dependency versions is not remediation.

Verification records

Use current CI results for the exact candidate commit and rerun the documented checks when dependencies or deployment settings change. Do not infer production authorization from local simulation receipts, self-signed fixture evidence or a successful website deployment.

← Back to the collection