Define Vibe Deploy proof chain for open Runtime

README.md

@@ -249,6 +249,8 @@ flowchart LR
   reconciliation, certification, receipt, evidence, metrics, and audit packets.
 - Package release assets with checksums.
 - Deploy the paper runtime on Railway or Docker.
+- Connect an operator-owned Runtime to the ZERO control plane through the
+  optional Vibe Deploy proof chain.
 - Generate public-safe Proof profile, replay, and contract artifacts.
 
 The self-evolving loop that makes ZERO adaptive operating intelligence is now
@@ -267,20 +269,22 @@ exist. Protected live-code evolution remains human-reviewed. See
 ZERO should earn trust through behavior that another engineer can verify:
 
 1. Run paper mode locally or on Railway.
-2. Run `just public-proof` to verify the demo proof pack, Proof chain,
+2. If using Vibe Deploy, claim the Runtime and verify the first heartbeat before
+   treating it as an owned deployment.
+3. Run `just public-proof` to verify the demo proof pack, Proof chain,
    redacted live trading evidence, read-only MCP server, and committed MCP
    transcript together.
-3. Verify `docs/proof/network/network-proof-pack.json` against its profile,
+4. Verify `docs/proof/network/network-proof-pack.json` against its profile,
    leaderboard, deployment identity, and ingestion artifacts.
-4. Generate a signed journal root from local JSONL streams with
+5. Generate a signed journal root from local JSONL streams with
    `zero-journal-root`, attach anchor metadata with `zero-journal-anchor`, and
    export a redacted proof pack with `zero-journal-proof`.
-5. Inspect runtime, risk, Runtime control, immune, account, and reconciliation
+6. Inspect runtime, risk, Runtime control, immune, account, and reconciliation
    packets through the CLI/API.
-6. Rehearse a live canary in fail-closed mode.
-7. Attach public-safe exchange-side evidence when an operator-owned live canary
+7. Rehearse a live canary in fail-closed mode.
+8. Attach public-safe exchange-side evidence when an operator-owned live canary
    is ready.
-8. Verify the bundle, recursive checksums, privacy flags, live canary policy,
+9. Verify the bundle, recursive checksums, privacy flags, live canary policy,
    and report with local scripts before publishing anything.
 
 That flow is implemented for refusal-mode rehearsal and redacted live-evidence
@@ -591,6 +595,7 @@ deployment project, secrets, exchange credentials, and runtime state.
 - [docs/local-development.md](docs/local-development.md)
 - [docs/railway-template.md](docs/railway-template.md)
 - [docs/railway-deploy.md](docs/railway-deploy.md)
+- [docs/vibe-deploy.md](docs/vibe-deploy.md)
 - [docs/distribution.md](docs/distribution.md)
 - [docs/release.md](docs/release.md)
 - [docs/release-verification.md](docs/release-verification.md)
@@ -685,6 +690,7 @@ Machine-readable entrypoints:
 - [Incident Postmortems](docs/incident-postmortems/README.md)
 - [Operator Context](docs/operator-context.md)
 - [Deployment Identity](docs/deployment-identity.md)
+- [Vibe Deploy Proof Chain](docs/vibe-deploy.md)
 - [Live Evidence](docs/live-evidence.md)
 - [Live Canary Operator](docs/live-canary-operator.md)
 - [Operator Isolation](docs/operator-isolation.md)

docs/autonomous-os-plan.md

@@ -1,17 +1,17 @@
-# ZERO Autonomous OS Completion Plan
+# ZERO Runtime Completion Plan
 
 Status: historical publicization roadmap. The canonical public repo surfaces
 are ZERO Runtime, ZERO Protocol, ZERO Proof, and Developers. Hosted Studio,
 Control, Registry, founder-admin, and doctrine surfaces live outside this
 repository.
 
-This plan defines the path from the current open-source launch repository to a
-complete ZERO autonomous operating system for self-custodial onchain
-operations.
+This plan defines the historical path from the open-source launch repository to
+the current open ZERO Runtime, ZERO Protocol, and ZERO Proof substrate for
+self-custodial capital operations.
 
-The current public repo is strong as an open-source product page, contributor
-surface, CLI, paper runtime, and safety-first launch artifact. It is not yet a
-complete autonomous real-capital operating system. The remaining work is
+The current public repo is strong as an open Runtime, Protocol, and Proof
+surface, contributor surface, CLI, paper runtime, and safety-first launch
+artifact. It is not a hosted real-capital product surface. The remaining work is
 runtime truth, live exchange evidence, multi-operator isolation, public Network
 ingestion, growth-mode Intelligence infrastructure, future commercial scale
 packaging, and the public self-evolution loop: memory, research, genesis,

docs/llms-full.txt

@@ -21,6 +21,7 @@ Use this bundle for retrieval and coding agents. It is not evidence of live trad
 - `docs/cli-quickstart.md`
 - `docs/cli-doctor-troubleshooting.md`
 - `docs/railway-template.md`
+- `docs/vibe-deploy.md`
 - `docs/api.md`
 - `docs/memory-core.md`
 - `docs/genesis.md`
@@ -313,6 +314,8 @@ flowchart LR
   reconciliation, certification, receipt, evidence, metrics, and audit packets.
 - Package release assets with checksums.
 - Deploy the paper runtime on Railway or Docker.
+- Connect an operator-owned Runtime to the ZERO control plane through the
+  optional Vibe Deploy proof chain.
 - Generate public-safe Proof profile, replay, and contract artifacts.
 
 The self-evolving loop that makes ZERO adaptive operating intelligence is now
@@ -331,20 +334,22 @@ exist. Protected live-code evolution remains human-reviewed. See
 ZERO should earn trust through behavior that another engineer can verify:
 
 1. Run paper mode locally or on Railway.
-2. Run `just public-proof` to verify the demo proof pack, Proof chain,
+2. If using Vibe Deploy, claim the Runtime and verify the first heartbeat before
+   treating it as an owned deployment.
+3. Run `just public-proof` to verify the demo proof pack, Proof chain,
    redacted live trading evidence, read-only MCP server, and committed MCP
    transcript together.
-3. Verify `docs/proof/network/network-proof-pack.json` against its profile,
+4. Verify `docs/proof/network/network-proof-pack.json` against its profile,
    leaderboard, deployment identity, and ingestion artifacts.
-4. Generate a signed journal root from local JSONL streams with
+5. Generate a signed journal root from local JSONL streams with
    `zero-journal-root`, attach anchor metadata with `zero-journal-anchor`, and
    export a redacted proof pack with `zero-journal-proof`.
-5. Inspect runtime, risk, Runtime control, immune, account, and reconciliation
+6. Inspect runtime, risk, Runtime control, immune, account, and reconciliation
    packets through the CLI/API.
-6. Rehearse a live canary in fail-closed mode.
-7. Attach public-safe exchange-side evidence when an operator-owned live canary
+7. Rehearse a live canary in fail-closed mode.
+8. Attach public-safe exchange-side evidence when an operator-owned live canary
    is ready.
-8. Verify the bundle, recursive checksums, privacy flags, live canary policy,
+9. Verify the bundle, recursive checksums, privacy flags, live canary policy,
    and report with local scripts before publishing anything.
 
 That flow is implemented for refusal-mode rehearsal and redacted live-evidence
@@ -655,6 +660,7 @@ deployment project, secrets, exchange credentials, and runtime state.
 - [docs/local-development.md](docs/local-development.md)
 - [docs/railway-template.md](docs/railway-template.md)
 - [docs/railway-deploy.md](docs/railway-deploy.md)
+- [docs/vibe-deploy.md](docs/vibe-deploy.md)
 - [docs/distribution.md](docs/distribution.md)
 - [docs/release.md](docs/release.md)
 - [docs/release-verification.md](docs/release-verification.md)
@@ -749,6 +755,7 @@ Machine-readable entrypoints:
 - [Incident Postmortems](docs/incident-postmortems/README.md)
 - [Operator Context](docs/operator-context.md)
 - [Deployment Identity](docs/deployment-identity.md)
+- [Vibe Deploy Proof Chain](docs/vibe-deploy.md)
 - [Live Evidence](docs/live-evidence.md)
 - [Live Canary Operator](docs/live-canary-operator.md)
 - [Operator Isolation](docs/operator-isolation.md)
@@ -2274,6 +2281,11 @@ custody funds and does not need exchange keys. The deployment is useful for
 operator onboarding, public demos, proof capture, Railway doctor checks, and
 agentic contribution work against a real HTTP runtime.
 
+When an operator wants the ZERO app/control plane to recognize this Runtime,
+the next step is the [Vibe Deploy proof chain](vibe-deploy.md): claim the
+Runtime, observe the first heartbeat, run paper acceptance, and only then move
+toward authority or Builder Code approvals.
+
 Current verified public demo:
 [https://zero-production-5214.up.railway.app](https://zero-production-5214.up.railway.app)
 
@@ -2351,6 +2363,10 @@ custody funds and does not need exchange private keys. Use it for operator
 onboarding, public proof capture, agentic development, and first-run demos
 against a real HTTP runtime.
 
+For app-connected deployments, use Vibe Deploy after the template is running:
+claim the Runtime, prove liveness with a heartbeat, and record paper acceptance
+before any live authority ceremony.
+
 ## Common Use Cases
 
 - Paper-mode operator demos with live read-only Hyperliquid mids.
@@ -2458,6 +2474,98 @@ inspectable, interruptible, and paper-first by default.
 ````
 
 
+## Source: `docs/vibe-deploy.md`
+
+````markdown
+# Vibe Deploy Proof Chain
+
+Vibe Deploy is the optional trust ceremony that connects an operator-owned ZERO
+Runtime to the ZERO control plane. It is not custody and it is not required to
+run the public paper Runtime locally, in Docker, or on Railway.
+
+The public Runtime remains useful by itself:
+
+- paper mode is the default;
+- live Hyperliquid prices are read-only unless the operator configures more;
+- live-risk endpoints fail closed by default;
+- journals, audit export, proof packs, and MCP inspection work without a ZERO
+  hosted account.
+
+Vibe Deploy adds a receipt-backed chain of evidence so the app/control plane can
+distinguish a genuine Runtime from someone clicking a button.
+
+## Proof Chain
+
+| Step | Runtime/control-plane proof |
+| --- | --- |
+| `claim_runtime` | Deployment ownership proof. The Runtime consumes a single-use claim token and receives scoped control-plane credentials. |
+| `observe_first_heartbeat` | Runtime liveness proof. The claimed Runtime sends signed heartbeat evidence with replay protection. |
+| `run_paper_acceptance` | Paper capability proof. The Runtime executes a paper acceptance path and writes local journal/audit evidence. |
+| `record_paper_acceptance` | Control-plane acceptance proof. The Runtime posts a signed paper acceptance event for the deployment. |
+| `approveAgent` | Authority proof. The operator's main wallet approves the Hyperliquid API/agent wallet; the public Runtime does not do this by default. |
+| `grant_short_live_lease` | Execution authority proof. The control plane grants bounded live authority only after ownership, liveness, paper capability, and agent approval are present. |
+| `approveBuilderFee` | Revenue authority proof. Optional for paid/live use; signed by the main wallet, never by the API/agent wallet. |
+
+## Public Runtime Boundary
+
+The public repository supports the Runtime side of the ceremony:
+
+- deployment claim and heartbeat packets;
+- local/Railway paper Runtime evidence;
+- audit and proof export;
+- fail-closed live readiness and canary rehearsal;
+- read-only MCP inspection.
+
+The ZERO control plane owns the app-side ceremony:
+
+- deployment creation;
+- claim token minting and redemption;
+- receipt storage;
+- live lease gating;
+- Privy/API-wallet signing where configured;
+- proof-chain projection into user/admin product surfaces.
+
+## Safety Rules
+
+- The Runtime can run paper mode without connecting to the ZERO control plane.
+- A claim token is single-use and should be stored hash-only server-side.
+- Heartbeats must be signed, nonce-protected, and clock-bounded when posted to
+  the control plane.
+- Paper acceptance must come from Runtime evidence, not from UI state.
+- Live execution must remain refused until explicit operator authority gates are
+  complete.
+- Builder Codes must never be hidden. The public Runtime does not apply ZERO
+  builder fees by default.
+
+## Verification Commands
+
+For a local or Railway Runtime:
+
+```bash
+curl -fsS "$ZERO_RUNTIME_URL/health"
+curl -fsS "$ZERO_RUNTIME_URL/deployment/heartbeat"
+curl -fsS "$ZERO_RUNTIME_URL/audit/export?limit=1"
+curl -fsS "$ZERO_RUNTIME_URL/live/preflight"
+```
+
+Run `/deployment/claim` only once through the dedicated claim ceremony flow
+with a single-use token. It is stateful and must not be part of repeatable
+health verification.
+
+For the public repository gates:
+
+```bash
+just public-proof
+just railway-smoke
+just docs-check
+```
+
+`/live/preflight` should report refused/not-ready in the default public Runtime.
+That is the expected posture until an operator completes the separate authority
+ceremony.
+````
+
+
 ## Source: `docs/api.md`
 
 ````markdown
@@ -4800,6 +4908,9 @@ operation.
 - Public docs must not reference private infrastructure, direct host details, or
   private legal material.
 - Public code must not require a ZERO-hosted app to run paper mode.
+- Vibe Deploy may connect an operator-owned Runtime to the ZERO control plane,
+  but it must be optional and receipt-backed: ownership, liveness, paper
+  capability, authority, and execution lease are separate proof steps.
 - Railway deployment must be optional, reproducible, and self-custodial.
 - Runtime telemetry and profile publication must be opt-in.
 - Public profiles and leaderboards are part of the public product surface.
@@ -4813,6 +4924,8 @@ operation.
   runtime operation.
 - Future paid features must be based on scale, history, reliability,
   redistribution, or support, not on basic runtime use or early operator access.
+- Builder Codes must be explicit operator-approved revenue authority, never a
+  hidden default in the open Runtime.
 - A public contributor must be able to run the default test suite from a clean
   checkout.
 
@@ -5513,20 +5626,20 @@ infrastructure remain separate product work.
 ## Source: `docs/autonomous-os-plan.md`
 
 ````markdown
-# ZERO Autonomous OS Completion Plan
+# ZERO Runtime Completion Plan
 
 Status: historical publicization roadmap. The canonical public repo surfaces
 are ZERO Runtime, ZERO Protocol, ZERO Proof, and Developers. Hosted Studio,
 Control, Registry, founder-admin, and doctrine surfaces live outside this
 repository.
 
-This plan defines the path from the current open-source launch repository to a
-complete ZERO autonomous operating system for self-custodial onchain
-operations.
+This plan defines the historical path from the open-source launch repository to
+the current open ZERO Runtime, ZERO Protocol, and ZERO Proof substrate for
+self-custodial capital operations.
 
-The current public repo is strong as an open-source product page, contributor
-surface, CLI, paper runtime, and safety-first launch artifact. It is not yet a
-complete autonomous real-capital operating system. The remaining work is
+The current public repo is strong as an open Runtime, Protocol, and Proof
+surface, contributor surface, CLI, paper runtime, and safety-first launch
+artifact. It is not a hosted real-capital product surface. The remaining work is
 runtime truth, live exchange evidence, multi-operator isolation, public Network
 ingestion, growth-mode Intelligence infrastructure, future commercial scale
 packaging, and the public self-evolution loop: memory, research, genesis,
@@ -6225,16 +6338,16 @@ operator identifiers, strategy thresholds, proprietary datasets, or commercial
 operations data.
 
 The important conclusion is direct: the public repository is excellent as an
-open-source launch artifact, but the complete ZERO autonomous operating system
-also needs the adaptive intelligence loop that already exists internally:
+open Runtime, Protocol, and Proof launch artifact, but ZERO also needs the
+adaptive intelligence loop that already exists internally:
 
 ```text
 operate -> journal -> memory -> genesis -> guardian -> build -> red-team
         -> paper canary -> calibration -> promote or rollback -> evolve
 ```
 
-That loop is not a sidecar. It is the difference between an autonomous runtime
-and an autonomous operating system that improves under review.
+That loop is not a sidecar. It is the difference between a static runtime and an
+operating-intelligence runtime that improves under review.
 
 ## Internal Capability Classes
 
@@ -6282,7 +6395,7 @@ local genesis, or the operator terminal as proprietary features.
 | Area | Internal capability | Public state | Gap |
 | --- | --- | --- | --- |
 | Self-evolution | Memory extracts rules, research explains what to study, genesis proposes/builds changes, red-team attacks diffs, canary/calibration gates promotion. | Memory core, research command chain, genesis proposal classification, production-parity OODA reports, paper-first evolve gates, sandbox candidate mutation, promotion plans, exact-phrase local apply, rollback receipts, and promotion verification are now present as public subsystems. | Protected live-code evolution remains human-reviewed until external operator evidence and review exist. |
-| Research command chain | Hunt, edge, convergence, thesis, score, meta, and sharpen form a learning/research loop. | Public docs mention autonomous OS, but not the full command chain. | Add public command contracts and deterministic fixture-backed reports. |
+| Research command chain | Hunt, edge, convergence, thesis, score, meta, and sharpen form a learning/research loop. | Public docs mention Runtime, Protocol, and Proof boundaries, but not the full command chain. | Add public command contracts and deterministic fixture-backed reports. |
 | Real decision engine | Multi-lens evaluation, layered signals, risk gates, sizing modifiers, and rejection learning. | Public runtime now exposes a paper-only lens/layer/modifier decision stack plus `zero.runtime.production_parity.v1` live-shadow fail-closed parity over API, MCP, OpenAPI, docs, and tests. | Add richer regime/correlation gates and real exchange execution-quality feedback after operator-owned canary evidence. |
 | MCP surface | Internal MCP can inspect and operate many engine surfaces. | Public MCP exposes expanded read-only local/operator surfaces with explicit safety classes. | Add risk-reducing local controls only after the operator policy and friction contract are public. |
 | Live canary lifecycle | Readiness, policy, launch, evidence, report, qualification, shadow review, follow-through. | Public has rehearsal, evidence, verification, policy qualification, cockpit-drill policy capture, and operator report flows. | Attach real operator-owned exchange evidence from an accepted canary. |

docs/open-core-boundary.md

@@ -54,6 +54,9 @@ operation.
 - Public docs must not reference private infrastructure, direct host details, or
   private legal material.
 - Public code must not require a ZERO-hosted app to run paper mode.
+- Vibe Deploy may connect an operator-owned Runtime to the ZERO control plane,
+  but it must be optional and receipt-backed: ownership, liveness, paper
+  capability, authority, and execution lease are separate proof steps.
 - Railway deployment must be optional, reproducible, and self-custodial.
 - Runtime telemetry and profile publication must be opt-in.
 - Public profiles and leaderboards are part of the public product surface.
@@ -67,6 +70,8 @@ operation.
   runtime operation.
 - Future paid features must be based on scale, history, reliability,
   redistribution, or support, not on basic runtime use or early operator access.
+- Builder Codes must be explicit operator-approved revenue authority, never a
+  hidden default in the open Runtime.
 - A public contributor must be able to run the default test suite from a clean
   checkout.