@@ -47,7 +47,7 @@
 - Wallet xpub onboarding lives at `/wallet/settings`; invoices expect a configured wallet or redirect there.
 - **Data hygiene:** As of 2025-11-16 the app only holds seed/test data—no real customers yet. Remove this note (and treat production emails accordingly) once live customer data exists.
 - CryptoZing must remain watch-only: never put private keys or seed phrases into tracked repo files, app config, database seeders, fixtures, tests, or normal application flows. If local testnet funding keys are needed for developer-only scenario setup, keep them only in untracked local storage (for example under `.cybercreek/`) and outside the product boundary.
-- Email delivery currently rewrites recipients to the CryptoZing catch-all via `MAIL_ALIAS_ENABLED/MAIL_ALIAS_DOMAIN` (set to `mailer.cryptozing.app` so Mailgun routes everything to Proton). Disable the aliasing before RC or any real-customer deployment.
+- Email delivery currently rewrites recipients to the CryptoZing catch-all via `MAIL_ALIAS_ENABLED/MAIL_ALIAS_DOMAIN` (set to `mailer.cryptozing.app` so Mailgun routes everything to Proton). Disable the aliasing before open beta or any real-customer deployment.
 - `SUPPORT_AGENT_EMAILS` controls which accounts are treated as support accounts, and `SUPPORT_ACCESS_HOURS` should remain the fixed server-side expiration window for temporary owner-granted support access.
 - The CryptoZing.app domain is reserved solely for this project; feel free to provision DNS/subdomains/mail for app needs without saving it for other products.
 - Set `APP_PUBLIC_URL` to whatever domain should appear in public invoice links (localhost for dev, `https://cryptozing.app` for production) so emails never point at the wrong host.
 
@@ -208,7 +208,7 @@ docker/      Container setup
 - Backlog: [`docs/BACKLOG.md`](docs/BACKLOG.md)
 - Changelog: [`docs/CHANGELOG.log`](docs/CHANGELOG.log)
 - Quick start: [`docs/ops/get-live/QUICK_START.md`](docs/ops/get-live/QUICK_START.md)
-- RC rollout checklist: [`docs/ops/RC_ROLLOUT_CHECKLIST.md`](docs/ops/RC_ROLLOUT_CHECKLIST.md)
+- Rollout checklist: [`docs/ops/OB_ROLLOUT_CHECKLIST.md`](docs/ops/OB_ROLLOUT_CHECKLIST.md)
 - Active milestone: [`docs/milestones/16_MAILER_AND_ALERTS_POLISH_AUDIT.md`](docs/milestones/16_MAILER_AND_ALERTS_POLISH_AUDIT.md)
 - Onboarding Part 1 spec: [`docs/specs/ONBOARD_SPEC.md`](docs/specs/ONBOARD_SPEC.md)
 - Post-payment onboarding spec: [`docs/specs/POST_PAYMENT_ONBOARDING.md`](docs/specs/POST_PAYMENT_ONBOARDING.md)
 
@@ -4,7 +4,7 @@ _Last updated: 2026-04-08_
 This is the canonical post-MVP backlog.
 
 Use this file only for deferred or future work.
-Anything still in RC scope belongs in [`docs/PLAN.md`](PLAN.md) and its linked canonical docs instead.
+Anything still in open-beta scope belongs in [`docs/PLAN.md`](PLAN.md) and its linked canonical docs instead.
 
 ## Near-Term Product UX
 1. **Invoices + Clients Search and Filtering**
@@ -43,21 +43,21 @@ _Carry-forward guardrail from active roadmap scope: suppress duplicate sends for
    - Reuse `InvoicePaid` events and delivery log updates to emit notifications without polling.
 
 6. **Notification Preference Expansion**
-   - Consider allowing issuers to configure alert thresholds per profile instead of keeping the RC-wide default threshold.
+   - Consider allowing issuers to configure alert thresholds per profile instead of keeping the open-beta-wide default threshold.
 
 7. **Configurable Past-Due Reminder Cadence**
    - Expose the hardcoded day-offset schedule (day 1, 7, 14 past due) as issuer-configurable notification settings.
-   - RC ships a sane fixed default; this item adds issuer control post-RC.
+   - The open beta ships a sane fixed default; this item adds issuer control post-open-beta.
 
 8. **Custom Outbound Mail Logo Uploads**
    - Allow issuers to upload a custom logo for outbound mail instead of only showing or hiding the default CryptoZing logo.
    - Include storage, validation, replacement/removal, and email-client-safe fallback behavior.
-   - Keep this separate from the RC KISS mail-branding controls, which are limited to brand-shell text fields plus a default-logo on/off toggle.
+   - Keep this separate from the open-beta KISS mail-branding controls, which are limited to brand-shell text fields plus a default-logo on/off toggle.
 
 ## Support & Admin Roles
 
 20. **Support agent / maintainer role separation**
-   - For RC, the support agent role doubles as the operational maintainer: one email allowlist, one dashboard, full visibility into both issuer grants and service health monitoring.
+   - For the open beta, the support agent role doubles as the operational maintainer: one email allowlist, one dashboard, full visibility into both issuer grants and service health monitoring.
    - Post-MVP, split these into distinct roles if the team grows:
      - A **maintainer** role that has access to the monitoring panel (queue depth, delivery failures, watcher health) but not to issuer grant browsing.
      - A **support agent** role that has access to issuer grant browsing but not to the monitoring panel, if a dedicated support function separate from engineering is needed.
@@ -96,7 +96,7 @@ _Carry-forward guardrail from active roadmap scope: suppress duplicate sends for
 
 ## Product UX
 16. **Multi-wallet selection + additional wallets UI**
-   - Core wallet-key lineage and cursor safety is now tracked in active RC roadmap scope; this post-MVP item builds on that foundation.
+   - Core wallet-key lineage and cursor safety is now tracked in active open-beta roadmap scope; this post-MVP item builds on that foundation.
    - Re-enable the Additional wallets UI in `/wallet/settings` once multi-wallet selection is in scope.
    - Add an invoice-level wallet selector and migration guidance for existing invoices.
 
@@ -113,7 +113,7 @@ _Carry-forward guardrail from active roadmap scope: suppress duplicate sends for
    - Surface an issuer-facing ledger so credit issuance, application, reversal, and remaining credit are auditable over time.
 
 19. **Spending-only companion wallet ecosystem idea**
-   - Separate product idea, not RC scope for CryptoZing itself.
+   - Separate product idea, not open-beta scope for CryptoZing itself.
    - Explore a companion wallet app that can spend/send but does not receive, and only shares public derivation material with CryptoZing.
    - Goal: reduce accidental outside receive activity on the same account namespace while keeping CryptoZing watch-only.
    - Future direction to evaluate later: whether a tighter CryptoZing + companion-wallet pairing should be encouraged or even required in a future product generation.
@@ -1,6 +1,6 @@
 # Content Promises Catalog
 
-A living catalog of promises and expectations that customer-facing content sets about CryptoZing — both directly and implicitly. Maintained as content is written so the product can be trued up to it before RC (see MS19).
+A living catalog of promises and expectations that customer-facing content sets about CryptoZing — both directly and implicitly. Maintained as content is written so the product can be trued up to it ahead of the open beta (see MS19).
 
 ## Why this exists
 
@@ -58,7 +58,7 @@ When an entry is a **critical omission** about a future product decision (for ex
 
 ## Reconciliation
 
-Every major entry needs individual reconciliation before RC. Minor entries get a bulk verification pass. MS19 will include a phase to walk this catalog and either confirm the product honors each entry or trigger a content revision. New entries added after MS19 reconciliation will need to be caught in the next pre-release pass.
+Every major entry needs individual reconciliation before the open beta. Minor entries get a bulk verification pass. MS19 will include a phase to walk this catalog and either confirm the product honors each entry or trigger a content revision. New entries added after MS19 reconciliation will need to be caught in the next pre-release pass.
 
 ---
 
 
@@ -4,7 +4,7 @@ Canonical reference for what each tracked doc is for, and the rules about how th
 
 ## Canonical docs (top-level scope authority)
 
-- [`docs/PLAN.md`](PLAN.md) — RC milestone order, status, current focus, and the primary next doc.
+- [`docs/PLAN.md`](PLAN.md) — open-beta milestone order, status, current focus, and the primary next doc.
 - [`docs/PRODUCT_SPEC.md`](PRODUCT_SPEC.md) — global product behavior and invariants.
 - [`docs/BACKLOG.md`](BACKLOG.md) — post-MVP and deferred work only.
 - [`docs/UX_GUARDRAILS.md`](UX_GUARDRAILS.md) — global UX, accessibility, and interaction rules.
 
@@ -16,21 +16,21 @@ Use [`docs/BACKLOG.md`](BACKLOG.md) for post-MVP work only.
 
 ## Current
 - Active milestone:
-  - **MS19 - RC Hardening & Ops** — in progress; Phase 1 (notification coverage audit & verification) underway, later phases pre-flight.
+  - **MS19 - Open Beta Hardening & Ops** — in progress; Phase 1 (notification coverage audit & verification) underway, later phases pre-flight.
 - Status: `active`
 - Next action: MS19 Phase 1 — notification coverage verification (Claude).
-- Primary next doc: [`docs/milestones/19_RC_HARDENING_OPS.md`](milestones/19_RC_HARDENING_OPS.md)
+- Primary next doc: [`docs/milestones/19_OB_HARDENING_OPS.md`](milestones/19_OB_HARDENING_OPS.md)
 - Most recently completed milestone doc: [`docs/milestones/x18_PRERELEASE_CONTENT_SEO.md`](milestones/x18_PRERELEASE_CONTENT_SEO.md)
 
 ## Published Release Target
-- **First public release: mid-to-late 2027.** The RC milestone timeline (MS21, targeting 2026-08-11) covers the release candidate. The published release target accounts for post-RC work needed before an official first release.
+- **First public release: mid-to-late 2027.** The open beta milestone timeline (MS21, targeting 2026-08-11) covers the open beta. The published release target accounts for post-open-beta work needed before an official first release.
 
 ## Active and Upcoming Milestones
 | Status | ID | Milestone | Short intent | Target | Primary doc |
 |---|---|---|---|---|---|
-| [ ] | 19 | RC Hardening & Ops | RC hardening before mainnet cutover: notification coverage audit; auth/password policy hardening (419-to-login redirect, session expiry logout); LLC formation (entity, EIN, bank account, operating agreement); legal layer (ToS, Privacy Policy, disclaimers, monetization-neutral copy review, UI placement); content promises reconciliation; contributor docs refresh; 2FA (email baseline, opportunistic TOTP). | 2026-07-18 | [`docs/milestones/19_RC_HARDENING_OPS.md`](milestones/19_RC_HARDENING_OPS.md) |
+| [ ] | 19 | Open Beta Hardening & Ops | Open beta hardening before mainnet cutover: notification coverage audit; auth/password policy hardening (419-to-login redirect, session expiry logout); LLC formation (entity, EIN, bank account, operating agreement); legal layer (ToS, Privacy Policy, disclaimers, monetization-neutral copy review, UI placement); content promises reconciliation; contributor docs refresh; 2FA (email baseline, opportunistic TOTP). | 2026-07-18 | [`docs/milestones/19_OB_HARDENING_OPS.md`](milestones/19_OB_HARDENING_OPS.md) |
 | [ ] | 20 | Mainnet Cutover Preparation | Define and rehearse env flips, wallet validation, mail sanity checks, and backout steps for mainnet cutover. | 2026-07-30 | [`docs/milestones/20_MAINNET_CUTOVER_PREP.md`](milestones/20_MAINNET_CUTOVER_PREP.md) |
-| [ ] | 21 | CryptoZing.app Deployment (RC) | Deploy the RC under `cryptozing.app`, replace the GitHub Pages placeholder at `/` with the live app landing page without breaking the SEO baseline established in MS15, remove temporary mail aliasing, and complete rollout verification. | 2026-08-11 | [`docs/milestones/21_RC_DEPLOYMENT.md`](milestones/21_RC_DEPLOYMENT.md) |
+| [ ] | 21 | CryptoZing.app Deployment (Open Beta) | Deploy the open beta under `cryptozing.app`, replace the GitHub Pages placeholder at `/` with the live app landing page without breaking the SEO baseline established in MS15, remove temporary mail aliasing, and complete rollout verification. | 2026-08-11 | [`docs/milestones/21_OB_DEPLOYMENT.md`](milestones/21_OB_DEPLOYMENT.md) |
 
 ## Completed Milestones
 | Status | ID | Milestone | Short intent | Primary doc |
 
@@ -8,7 +8,7 @@ Use [`docs/PLAN.md`](PLAN.md) for milestone order, current focus, and the primar
 Use detailed docs under `docs/specs/` and `docs/milestones/` for local scope, acceptance criteria, and implementation-impacting notes.
 
 ## Canonical Doc Roles
-- [`docs/PLAN.md`](PLAN.md): human-facing execution dashboard for RC milestone order, current focus, and the primary next doc.
+- [`docs/PLAN.md`](PLAN.md): human-facing execution dashboard for open-beta milestone order, current focus, and the primary next doc.
 - [`docs/BACKLOG.md`](BACKLOG.md): post-MVP and deferred work only.
 - [`docs/UX_GUARDRAILS.md`](UX_GUARDRAILS.md): global UX, accessibility, and interaction rules.
 - `docs/milestones/**`: milestone execution docs when a milestone is active or large enough to need detailed checklist tracking.
@@ -89,7 +89,7 @@ Issuers create invoices in USD, derive a unique Bitcoin receive address per invo
 ### Public links, print output, and outbound communication
 - Public-share and email links must use `APP_PUBLIC_URL`.
 - Public and print surfaces must honor public-safe boundaries and status-specific behavior defined in [`docs/specs/PRINT_PUBLIC_POLISH.md`](specs/PRINT_PUBLIC_POLISH.md) and [`docs/milestones/x13_UX_OVERHAUL.md`](milestones/x13_UX_OVERHAUL.md).
-- Outbound mail in pre-production may be recipient-aliased via `MAIL_ALIAS_ENABLED` and `MAIL_ALIAS_DOMAIN`; this aliasing must be disabled before RC or real-customer use.
+- Outbound mail in pre-production may be recipient-aliased via `MAIL_ALIAS_ENABLED` and `MAIL_ALIAS_DOMAIN`; this aliasing must be disabled before open-beta launch or real-customer use.
 - Invoice send, receipt delivery, notification triggers, and delivery logging must remain auditable.
 
 ### Background processing and timing
@@ -100,8 +100,8 @@ Issuers create invoices in USD, derive a unique Bitcoin receive address per invo
 ### Active plan-linked requirements
 - Automatic attribution hardening must make derivation state key-aware, preserve invoice key identity for auditability, detect and flag unsupported wallet reuse without hard-blocking the issuer, snapshot unsupported state onto newly created invoices while avoiding blanket retroactive invoice flagging, distinguish unsupported shared-wallet evidence from stale-address wrong-invoice reuse, reinforce the dedicated-account requirement in wallet and onboarding UX, and provide an auditable correction path for wrongly attributed on-chain payments.
 - Mailer and alerts hardening must prevent duplicate outbound mail, support issuer-editable templates with safe variables and preview/reset flows, and keep payment-triggered outbound communication truthful and reviewable, including low-information payment acknowledgments plus issuer-reviewed client receipts; the detailed outbound-mail rules live in [`docs/specs/NOTIFICATIONS.md`](specs/NOTIFICATIONS.md).
-- Post-payment onboarding should remain lightweight in RC: Part 1 still gets issuers to first invoice delivery, while Part 2 should activate only once a first paid invoice is receipt-eligible, suspend when ignore/reattribution review would make a receipt untruthful, and complete when the issuer sends the first reviewed client receipt.
-- Mainnet cutover and RC deployment must preserve invoice integrity while switching environments, include a backout path, and verify alias-off mail behavior plus public-link correctness before real-customer rollout.
+- Post-payment onboarding should remain lightweight for the open beta: Part 1 still gets issuers to first invoice delivery, while Part 2 should activate only once a first paid invoice is receipt-eligible, suspend when ignore/reattribution review would make a receipt untruthful, and complete when the issuer sends the first reviewed client receipt.
+- Mainnet cutover and open-beta deployment must preserve invoice integrity while switching environments, include a backout path, and verify alias-off mail behavior plus public-link correctness before real-customer rollout.
 
 ## Canonical Spec Map
 - Rates and BTC/USD behavior: [`docs/specs/RATES.md`](specs/RATES.md)
@@ -116,7 +116,7 @@ Issuers create invoices in USD, derive a unique Bitcoin receive address per invo
 - Support access: [`docs/specs/SUPPORT_ACCESS.md`](specs/SUPPORT_ACCESS.md)
 - Cross-cutting UX and accessibility rules: [`docs/UX_GUARDRAILS.md`](UX_GUARDRAILS.md)
 - Docs and contributor-experience scope: [`docs/ops/DOCS_DX.md`](ops/DOCS_DX.md)
-- Rollout verification: [`docs/ops/RC_ROLLOUT_CHECKLIST.md`](ops/RC_ROLLOUT_CHECKLIST.md)
+- Rollout verification: [`docs/ops/OB_ROLLOUT_CHECKLIST.md`](ops/OB_ROLLOUT_CHECKLIST.md)
 
 ## Current Cross-Feature Constraints
 - Additional wallet storage exists, but invoice-level multi-wallet selection remains deferred to post-MVP and is tracked in [`docs/BACKLOG.md`](BACKLOG.md).
 
@@ -14,8 +14,8 @@ END:VEVENT
 BEGIN:VEVENT
 DTSTART;VALUE=DATE:20260508
 DTEND;VALUE=DATE:20260718
-SUMMARY:MS19 — RC Hardening & Ops
-DESCRIPTION:RC hardening: notification coverage, auth/password policy, LLC formation, legal layer (ToS, Privacy Policy, disclaimers, monetization-neutral copy), content promises reconciliation, contributor docs, 2FA (email baseline, optional TOTP).
+SUMMARY:MS19 — Open Beta Hardening & Ops
+DESCRIPTION:Open beta hardening: notification coverage, auth/password policy, LLC formation, legal layer (ToS, Privacy Policy, disclaimers, monetization-neutral copy), content promises reconciliation, contributor docs, 2FA (email baseline, optional TOTP).
 UID:cz-ms19@cryptozing.app
 END:VEVENT
 BEGIN:VEVENT
@@ -28,8 +28,8 @@ END:VEVENT
 BEGIN:VEVENT
 DTSTART;VALUE=DATE:20260729
 DTEND;VALUE=DATE:20260811
-SUMMARY:MS21 — CryptoZing.app Deployment (RC)
-DESCRIPTION:Deploy the RC under cryptozing.app, replace GitHub Pages placeholder, remove temporary mail aliasing, complete rollout verification.
+SUMMARY:MS21 — CryptoZing.app Deployment (Open Beta)
+DESCRIPTION:Deploy the open beta under cryptozing.app, replace GitHub Pages placeholder, remove temporary mail aliasing, complete rollout verification.
 UID:cz-ms21@cryptozing.app
 END:VEVENT
 END:VCALENDAR