docs(adr): specify slashing and economic penalties

AGENTS.md

@@ -14,6 +14,10 @@ OpenInfra Network is a decentralized provider-cloud prototype. The MVP must join
 
 Do not change a language, framework, database, or component boundary without an accepted ADR. Components must not take over another component’s responsibilities. The Provider Agent never talks directly to the blockchain in the MVP.
 
+## Staged Architecture
+
+The architecture above is frozen for the current stage, not forever. [ADR-012](docs/adr/012-decentralization-roadmap-and-trust-boundaries.md) defines the decentralization roadmap, the trust and threat model for every role, the per-class data classification, and the staged migration from today's single Control Plane to a decentralized network. Its §6 names the specific follow-up ADR that each later stage requires. A prohibition below is lifted only by accepting the ADR named there — never by an implementation deciding the change is small.
+
 ## Integration and Contract Rules
 
 Generated Go and Rust types must derive from Protobuf; do not add manual copies. Before changing a `.proto`, identify every consumer, preserve wire compatibility, run breaking-change checks, regenerate both languages, and update tests and docs. PostgreSQL is authoritative off-chain; Redis contains only reconstructible state. Never report `RUNNING`, a successful deployment, or an on-chain transition before receiving authoritative confirmation.
@@ -32,4 +36,8 @@ Use `make fmt`, `make lint`, `make test`, or component targets documented by `ma
 
 ## Prohibited Changes
 
-Do not introduce Kubernetes, another database, direct Agent-to-chain access, runtime orchestration, detailed on-chain metrics, hard-coded secrets, or contract changes without consumer analysis. Every production feature requires tests and every architecture change requires an ADR.
+Every production feature requires tests and every architecture change requires an ADR.
+
+**Permanent — no ADR lifts these.** Never hard-code secrets. Never change a contract without consumer analysis. Never put detailed metrics on-chain. Never put tenant payloads, logs, secrets, or any personal data on-chain: consensus state cannot be erased, so only hashes and commitments may cross that line (ADR-012 §3).
+
+**Prohibited until the ADR gate named in ADR-012 §6 is accepted.** Do not introduce another database (ADR-013, ADR-018), direct Agent-to-chain access (ADR-017), runtime orchestration (ADR-016), decentralized storage (ADR-018), a TEE trust root (ADR-019), or a replacement for `EnsureRoot` governance (ADR-020). Kubernetes remains prohibited under ADR-006, which fixes Docker as the runtime; adopting it needs its own accepted ADR.

ROADMAP.md

@@ -1,5 +1,14 @@
 # Roadmap
 
+This file and the GitHub milestones are the authoritative roadmap. `architecture.md` and
+`architecture_review.md` §7 contain an older, conflicting version numbering and are aspirational
+documents, not a record of what is planned or implemented.
+
+Milestones v3.0 and later are staged and gated by
+[ADR-012](docs/adr/012-decentralization-roadmap-and-trust-boundaries.md), which defines the trust
+boundaries, the data classification, and the follow-up ADR each stage requires. No implementation
+in those milestones starts before its gate ADR is accepted.
+
 ## v0.1 — Provider Join and First Workload
 
 Deliver the MVP in this dependency order:
@@ -18,10 +27,63 @@ The detailed entry conditions, exit criteria, and failure rules are documented i
 
 Add bounded Proof of Availability, heartbeat expiry, vector reputation updates, metrics summaries, failure handling, and integration tests across Agent, Control Plane, and chain.
 
-## v0.3 — Leases and Rewards End-to-End
+## v0.3 — Leases and Rewards E2E
 
 Complete authorized lease transitions, controlled reward arithmetic, event correlation, idempotent orchestration, recovery from partial failures, and multi-component observability.
 
 ## v1.0 — Stable Multi-Provider Network
 
 Harden multi-provider operation, upgrades, migrations, security, performance, reliability, compatibility, and operational documentation. Production readiness requires independent security review and measurable SLOs.
+
+## v1.1 — Metering and Settlement
+
+Add auditable usage metering, billing, escrow, settlement, and provider payouts after the stable MVP. Issues: #19 (metering and settlement architecture), #20 (usage metering and invoice ledger), #21 (on-chain escrow and provider settlement). #19 also gates streaming payments (#51) in v3.0.
+
+## v2.0 — OpenStack Compatibility
+
+Expose an OpenStack-compatible cloud surface backed by OpenInfra providers, including VM, identity, networking, storage, images, and Kubernetes integration. Issues: #22 (service mapping), #23 (Keystone identity), #24 (Nova/Placement), #25 (Neutron networking), #26 (Glance/Cinder), #27 (Kubernetes).
+
+This is an API-surface track, orthogonal to the decentralization stages below: it is neither blocked by them nor a prerequisite for them, provided it introduces no new central authority. Kubernetes (#27) needs its own ADR — ADR-006 currently fixes Docker as the runtime.
+
+## v3.0 — Decentralized Control Plane and Data
+
+Progressively remove centralized frontend, database, scheduler, and operational trust assumptions while preserving privacy, consistency, and recoverability. This is Stage 1 of ADR-012 §5: decentralize *authority*, while the data plane stays as it is.
+
+| Issue | Gate |
+|---|---|
+| #32 — decentralization roadmap and trust boundaries | ADR-012 (accepted) |
+| #33 — replicated off-chain data plane | ADR-013 |
+| #34 — multiple Control Planes and scheduling relays | ADR-014 |
+| #35 — content-addressed frontend distribution | ADR-018 |
+| #36 — decentralized identity, governance, validator operations | ADR-020 |
+| #50 — orchestration in smart contracts | ADR-016 |
+| #51 — streaming payments | #19 (v1.1), no new ADR |
+| #52 — slashing for availability guarantees | ADR-015 (accepted); also depends on #36, and requires provider bonding first |
+
+## v4.0 — P2P Mesh & Global Fabric
+
+Full P2P WireGuard mesh, DHT discovery, Virtual VPC and decentralized ingress/DNS. Stage 2 of ADR-012 §5: remove the Control Plane from the packet path. Depends on #36, because peer authentication cannot rest on a Control-Plane-issued allowlist once the Control Plane is no longer in the path.
+
+Issues #53 (P2P mesh), #54 (gateway nodes), #55 (decentralized DNS) — all gated by ADR-017.
+
+## v5.0 — Geo-Distributed Economy & Storage
+
+Geo-discovery, Proof of Resource (PoR), and decentralized S3/block storage. Stage 3 of ADR-012 §5: remove the Control Plane from discovery and make storage a first-class verified resource.
+
+| Issue | Gate |
+|---|---|
+| #56 — DHT geo-discovery | ADR-017 |
+| #57 — Proof of Resource | none; extends ADR-007 and ADR-011 §3 |
+| #58 — S3-compatible object storage | ADR-018 |
+| #59 — replicated block volumes | ADR-018 |
+
+## v6.0 — Confidential Cloud & Auto-Healing
+
+TEE support, distributed attestation, auto-migration and P2P IaC. Stage 4 of ADR-012 §5: close the operator-collusion gap and remove human intervention from failure recovery.
+
+| Issue | Gate |
+|---|---|
+| #60 — TEE support (Intel SGX / AMD SEV) | ADR-019 |
+| #61 — distributed enclave attestation | ADR-019 |
+| #62 — auto-healing and workload migration | ADR-016 |
+| #63 — infrastructure topology DSL | none while evaluated off-chain; ADR-016 if evaluated on-chain |