docs: add the single product roadmap — purpose, eras, exit criteria

GOVERNANCE.md

@@ -85,3 +85,5 @@ semantics, or the public/private boundary must:
 ## Documents
 
 - [QUALITY.md](QUALITY.md) — quality charter: stage invariants, regression policy, reference-platform aim.
+
+- [ROADMAP.md](ROADMAP.md) — the single product roadmap: purpose, eras, exit criteria.

QUALITY.md

@@ -1,13 +1,13 @@
 # CloudRING Quality Charter
 
 This charter is the repository-owned statement of product quality requirements. It binds
-every contribution, release, and milestone: CloudRING must be a stable, production-ready
+every contribution, release, and milestone: CloudRING must be a stable, production-grade
 product at every stage of its evolution — not only at major releases — and it must deploy,
 operate, and update reliably from code alone.
 
 ## Invariants (enforced at every stage)
 
-1. **Production-ready at every stage.** Every merge leaves the platform stable and
+1. **Production-grade at every stage.** Every merge leaves the platform stable and
    operable. Intermediate states that degrade availability, installability, or
    upgradeability are defects, not milestones. Acceptance of any stage includes a clean
    install and a clean upgrade from the previous accepted state.
@@ -47,3 +47,5 @@ acceptance records, not by intent.
 
 This charter is maintained like code: changes arrive by pull request with review, and the
 charter is binding for all CloudRING repositories.
+
+The stage invariants of this charter are enforced through the roadmap in [ROADMAP.md](ROADMAP.md).

README.md

@@ -11,7 +11,7 @@ services without hard-wiring them into one provider, one platform
 implementation, or one technology stack.
 
 > [!WARNING]
-> **CloudRING is in early development and is not ready for production or pilot
+> **CloudRING is in early development and is not yet production-grade or pilot
 > use.** Do not use it to operate real workloads, customer data, or critical
 > infrastructure. Passing repository tests proves only the code and contracts
 > present in that commit. Pilot readiness will be announced separately after

ROADMAP.md

@@ -0,0 +1,111 @@
+# CloudRING Roadmap
+
+Status: accepted working plan (discussed with the owner; refines with each era).
+Scope: from the current state to the full purpose of the platform. One roadmap per
+repository — this file. Companion documents: QUALITY.md (quality charter),
+docs/rfc/ (design records). Previous internal plans are superseded by this roadmap.
+
+## Purpose
+
+A lifelong cloud: a provider of one's own, free from vendor lock-in and jurisdiction
+dependence, developed and operated by a single engineer with a team of AI agents; full
+self-service for users; third parties extend the platform through the Open Cloud Standard
+(OCS) without modifying the core. Strategic horizon: a decentralized, unkillable network
+of clouds. Personally: the owner's company, number-one engineering quality, and the right
+to stop.
+
+**The purpose is achieved when all of the following hold:**
+
+| # | Dimension | Verifiable criterion |
+|---|---|---|
+| P1 | Freedom | an installation ports across substrates (second adapter passes the same acceptance) and providers in different jurisdictions; user export leaves no residue |
+| P2 | One engineer + agents | ≤30 min/day × 14 days of upkeep; install ≤2 h of attention; a second person repeats operations from public docs |
+| P3 | Self-service | the full user and administrator journey (login, programmatic control, zero-residue lifecycle) proven on every release |
+| P4 | Unkillability | ≥3 independent owners/jurisdictions at the network level; the federation runs with no central point |
+| P5 | OCS is alive | ≥2 independent implementations of the contract (CNCF Sandbox will expect 3+); a third-party product runs without core changes |
+| P6 | Quality #1 | comparable to or better than the leaders on every dimension; stage invariants enforced on every release |
+| P7 | The company | a working commercial entity of the owner with the first paid event |
+| P8 | A decade | the domain core carries no substrate types (substrate rotation every 5–10 years); standard stewardship institutionalized |
+
+## Stage invariants (enforced on every release; see QUALITY.md)
+
+I1 production-grade at every stage · I2 code is the complete source of truth · I3
+reliable updates (pinned artifacts, rollback, deprecation policy) · I4 no operator IT
+competence required · I5 modern architecture and process.
+
+Strategic mandates: the core is Rust; the UI is Rust with an extension host from day one;
+OCS fully implemented including the SDK — the foundation of the product; OCS never
+restricts the language of connected services; docs and licenses stay current; the runtime
+substrate is swappable on a ten-year horizon.
+
+## Eras
+
+### Era 0 — Foundation (~6–9 months; in progress)
+Deliver from code alone (parity), enforce process gates (CI tiers, regression gate,
+coverage floor, e2e and upgrade tests, SLSA L2), land OCS 1.0 + Rust SDK + conformance,
+the first Rust vertical slice under the M1 behavioral acceptance, the Rust UI with an
+extension host, finish M2/M3, the GUI installer, and the second substrate adapter.
+**Exit:** the platform deploys and updates from code alone on a clean cluster with zero
+manual steps; the behavioral acceptance is green; an external user lives on it.
+
+### Era I — The 1.0 product (~9–18 months after Era 0)
+The full mandatory catalog (Network, Volume, Image, Compute, Kubernetes, S3, Backup,
+Access, Support — each proven on a real backend including failures). A second
+independently managed site; a second engineer repeats operations from the docs; the 1.0
+measurements (regional RPO 0 / RTO ≤5 min; off-cell RPO ≤15 min / RTO ≤60 min; ≥99.95%
+availability over 24 h). A release train with n-2 support, canaries, and rollback. One
+license policy.
+**Exit:** 1.0 released; entry into Era II at ≥3 external independent installations
+(proposed threshold — the owner confirms or sets their own).
+
+### Era II — The OCS ecosystem (~1–2 years, overlapping growth)
+The standard lives outside one repository: specification separate from implementation;
+≥3 independent implementations (including ≥1 not ours); a conformance program with a
+public registry (CNCF model); a marketplace with mandatory signing. First third-party
+products in production at external users. Stewardship: a technical committee, a public
+standard roadmap, an RFC process.
+**Exit:** OCS is a language ≥3 independent teams speak without our participation.
+
+### Era III — World adoption (~2–4 years)
+The public cloud + partner installations; the community machine (good-first-issues,
+mentorship programs, multi-organization maintainers — the strongest survival predictor);
+CNCF Sandbox (once 2–3 independent implementations exist) → Incubating (CNCF criterion:
+3+ independent dev/test adopters; our bar: production adopters) → Graduated (maintainers
+from ≥2 organizations). "Thousands of companies" follows the Kubernetes adoption curve
+(83% production share four years from announcement under the foundation model).
+**Exit:** the platform is a top-3 choice for a new private/sovereign cloud; the standard
+is de facto.
+
+### Era IV — The unkillable network (~3–5 years, overlapping III)
+Provider federation: the P2P bus, cross-cloud connect, settlement (per the transformation
+plan, its 18–36-month horizon); ≥3 jurisdictions at the network level; no jurisdiction,
+company, or single operator can switch the network off (P4). Decentralized governance of
+the standard (foundation/association).
+**Exit:** purpose dimensions P1–P8 are met and confirmed by external audits.
+
+## Stewardship and economics (cross-cutting; owner decisions)
+
+- Era 0: IP held by the founder's entity; a dedicated vehicle is the intended future owner
+  ("ethereum foundation" model) — transfer not yet executed; stewardship form is an
+  Era II decision.
+- Monetization per the transformation ladder: the OSS core is free; the Business tier
+  (licenses/support/maintenance) from Era I; marketplace revenue sharing from Era II+.
+  Thresholds are the owner's decision (no thresholds exist in the sources).
+- The team: one engineer + an agent team; "one engineer" is an operating invariant, not
+  an organizational cap; the hiring trigger (proposed: when P2 genuinely breaks) is the
+  owner's call — the sources do not set one.
+
+## Progress control (cross-cutting)
+
+- Every era has entry/exit criteria above; invariants I1–I5 hold on every release.
+- Track life metrics (cores, installations, external products), not hype metrics
+  (stars, summits) — the OpenStack lesson.
+- Stop-losses: N iterations without progress → stop, re-plan, escalate to the owner.
+
+## Honest limits
+
+Era durations are orientation from precedents (Linux 26 years; Kubernetes 4 years from
+announcement; the OpenStack hype/life divergence). No public case exists of an agent team
+running a production OSS platform for years — our compass is behavioral acceptance plus
+gates, not trust. Public clouds die in 2–6 years against hyperscalers: the speed of Eras
+0–II is survival, not a race.

contracts/backup-proof/README.md

@@ -68,7 +68,7 @@ no numeric request fields. The repository-owned conformance vectors are
 normative and deliberately include Unicode plus characters that Go's default
 JSON encoder HTML-escapes.
 
-These contracts do not claim production readiness. They also do not define
+These contracts do not claim production-grade readiness. They also do not define
 credentials, object-store configuration, or a deployment topology. Live
 receipts and baselines are deployment-private artifacts and must not be
 committed here.

contracts/evidence/README.md

@@ -3,7 +3,7 @@
 This directory owns the public evidence freshness and blocked-state boundary for
 CloudRING.
 
-The contract is not a production readiness claim. It defines how a release
+The contract is not a production-grade readiness claim. It defines how a release
 reviewer treats accepted, stale, blocked, absent, synthetic, and redacted
 evidence before any downstream live promotion claim is evaluated.
 

contracts/release/README.md

@@ -3,7 +3,7 @@
 This directory owns the public release and BOM compatibility boundary for
 CloudRING.
 
-The contract is not a production readiness claim. It describes which release
+The contract is not a production-grade readiness claim. It describes which release
 records, BOM rows, evidence gates, stale states, and blocked states a downstream
 release reviewer must evaluate before any live promotion claim is considered.
 
@@ -21,4 +21,4 @@ convert a release record into a live claim.
 
 This directory does not include live infrastructure evidence, provider details,
 tenant data, private endpoints, credentials, or deployment receipts. It also
-does not authorize general availability.
+makes no GA release claim.

docs/architecture.md

@@ -37,4 +37,4 @@ stay in the downstream provider repository.
 6. Readiness and support evidence are recorded.
 7. Denied, degraded, blocked, retryable, and ready states are visible.
 
-No production readiness claim is valid without current evidence.
+No production-grade readiness claim is valid without current evidence.

docs/billing-connector-authoring.md

@@ -37,4 +37,4 @@ go run ./cmd/ocsctl validate ./examples/synthetic-service-module/connector-packa
 Do not embed payment credentials, customer records, settlement results, invoice
 truth, or private billing-system schemas in CloudRING. The public connector
 records the contract and evidence refs only. This document does not claim
-production readiness or billing settlement correctness.
+production-grade readiness or billing settlement correctness.

docs/ci-checks.md

@@ -49,7 +49,7 @@ a provider database or its backup and failover have been verified live.
 This contract does not require live provider credentials, secret environment
 variables, network mutation, or live Kubernetes access. Passing it only means
 the CloudRING public tree is locally safe to publish and validate; it is not a
-production readiness claim.
+production-grade readiness claim.
 
 Reviewed content exceptions remain bound to their exact repository path and
 whole-file digest. A recursive gitlink scan may add exactly one canonical

docs/evidence-authoring.md

@@ -39,7 +39,7 @@ example.
 
 ## Non-Claims
 
-Example evidence in CloudRING does not claim production readiness, a running
+Example evidence in CloudRING does not claim production-grade readiness, a running
 deployment, billing settlement, data migration, support operation, or recovery
 success. It proves that the package has the metadata and evidence refs needed
 for service-team, platform-operator, security-reviewer, and

docs/package-ownership.md

@@ -85,5 +85,5 @@ contract, policy, and validation pieces move into CloudRING. Concrete
 installation values and private product extensions stay downstream.
 
 Evidence paths remain evidence. A passing ownership manifest does not claim
-production readiness, deployment readiness, tenant data durability, backup
+production-grade readiness, deployment-grade readiness, tenant data durability, backup
 coverage, or single-point-of-failure readiness.

docs/provider-site-installation.md

@@ -140,4 +140,4 @@ effective on-wire destinations must be verified on the target site.
 This slice provides profile preflight, deterministic planning, kubeadm
 rendering, and captured-state verification contracts. It is not an installer,
 does not prove that any provider site is reachable, and does not claim
-production readiness.
+production-grade readiness.

roadmap/CURRENT_STATE.md

@@ -28,7 +28,7 @@ advance a goal.
 | Provider adapters and site profiles | `experimental` | Public schemas, validation, and synthetic inputs exist. Concrete provider accounts and inventory are outside the public boundary. |
 | kubeadm rendering and Kubernetes deployment profiles | `blocked` for independent installation | Public issues document missing executable substitution/join paths, schema integration, topology validation, and storage dependencies. A complete supported installer is not available. |
 | Backup, proof signing, restore collection, and resilience observers | `reference` / `experimental` | Reusable collectors and protocols exist. Integrated off-site recovery and promotion-grade failure campaigns are not publicly proved. |
-| Three-node and one-server-loss material | `reference` | It tests one declared single-failure topology. It is not a universal HA topology or production availability promise. |
+| Three-node and one-server-loss material | `reference` | It tests one declared single-failure topology. It is not a universal HA topology or production-grade availability promise. |
 | Provider control plane, organization model, inventory reconciliation, durable operations, and portal | `planned` | Owned by G03-G11 and the provider-control-plane public issues; no complete runtime exists. |
 | Network, volume, image, compute, Kubernetes, object storage, backup, access, support, and external products | `planned` | Goal contracts exist, but the products are not complete public runtime capabilities. |
 | Multi-cell, multi-region, marketplace economics, and sovereign federation | `planned` | Explicit later roadmap work. No current implementation or availability claim. |
@@ -62,6 +62,6 @@ document should be read as implementing it.
 - inspect and exercise public validators and reference contracts;
 - contribute provider-neutral code, documentation, tests, adapters, and modules.
 
-The current repository is not ready for production use. A fresh reader should
+The current repository is not yet production-grade. A fresh reader should
 not treat a reference profile, green CI run, fixture, or roadmap document as a
 release or deployment claim.