Production Roadmap

Operational log. These entries record what was verified and when. They are not claims about product capability.

This roadmap tracks the work needed to move Bitcoin Risk Brief from a local validation product to a production-pilot service. The target is not a broad analytics platform. The target is one reliable public Bitcoin risk page, safe waitlist capture, daily data freshness, and an operator workflow that can be monitored and rolled back.

Target State

Production-pilot readiness means:

• the public page explains current BTC risk without implying certainty or financial advice;
• users can see whether the latest data is fresh and validation passed;
• the waitlist flow works without storing leads in browser storage;
• BTC data can be refreshed without requiring a paid CoinMarketCap API account;
• frequently requested public data loads quickly through an explicit caching strategy;
• public endpoints and the waitlist flow have bot, spam, and abuse protection at the edge and application layers;
• automated checks run before deploys and before changes enter main;
• the user interface has been checked across the target browsers, screen sizes, and devices;
• product, operations, security, testing, and data-pipeline docs are current and agree with the implemented system;
• the deployed stack can be updated, monitored, backed up, restored, and rolled back;
• launch governance is explicit: privacy/terms posture, waitlist handling, credential ownership, resource monitoring, dependency maintenance, data-source terms, accessibility, and incident response are documented;
• USB-based updates and fresh installs can be prepared reproducibly without copying local secrets, dependency caches, or stale build artifacts;
• after implementation stabilizes, the private or portfolio repository has a professional README, current docs, and accurate GitHub description/topics;
• the first traffic test can measure whether a single BTC risk signal creates waitlist, repeat-visit, source-attributed, and endpoint-usage demand without storing raw IP addresses in product analytics.

Current Baseline

Already implemented:

• React frontend with seven-locale brief copy, risk history chart, risk levels chart, and waitlist form.
• FastAPI backend with latest risk, history, levels, brief, waitlist, health, and readiness endpoints.
• TimescaleDB storage and migration script.
• Canonical BTC CSV import and CoinMarketCap API delta refresh when an API key is configured.
• Validated operator-downloaded CoinMarketCap historical CSV import without a paid API key.
• Scheduled public-download-first CoinMarketCap CSV refresh in the collector, with optional API fallback only when an API key is configured and manual CSV intake as the operator fallback.
• Server-side waitlist storage with validation and rate limiting.
• Public read endpoint caching for readiness, latest risk, history, levels, and brief responses, with validation-versioned refresh after successful imports.
• Local Dependabot configuration for monthly dependency version-update PRs across frontend npm, backend and collector pip requirements, GitHub Actions, Dockerfiles, and a root docker-compose ecosystem entry for Compose-style image references. GitHub-hosted execution, first PR evidence, and Podman-specific filename handling remain pending until merged/pushed and observed.
• Local startup and operator public-cache warmup for the standard public read payloads, tagged cache-warmup-local-complete-2026-07-05; post-deploy public smoke on 2026-07-07 recorded fast repeated Cloudflare HIT behavior after warmup.
• Latest risk payload and first-viewport display polish for explicit model_price_usd, nullable low_usd, and nullable high_usd, tagged price-model-ohlc-local-complete-2026-07-06; production visibility is verified in the 2026-07-07 public smoke evidence.
• No-store waitlist responses, backend request logging, and repo-managed Cloudflare WAF, waitlist bot-challenge, cache-rule, and edge rate-limit settings for the production pilot.
• Local compact privacy/terms/disclaimer note near the waitlist, with no-advice, no sensitive-info, implemented waitlist storage, operational-log, no recommendation, no paid-SLA, and current no product analytics/tracking-cookie source-code statements.
• Containerized local stack and Ubuntu plus Cloudflare Tunnel deployment docs.
• Server-run USB kit scripts for host bootstrap, optional cloudflared install, project deploy, service enablement, health checks, and debug reports.
• USB kit v2 workstation packaging and server-side update wrapper are implemented locally, including filtered snapshot packaging, manifest/checksums, backup-before-update, off-server/USB backup copy, .env preservation, service restart, and health/readiness checks. Local evidence is tagged usb-kit-v2-local-complete-2026-07-05; production USB deploy verification passed according to the 2026-07-07 post-deploy evidence, and a backup-gated USB production update passed on 2026-07-11 for commit 86cb2dad889baf24a7464a105bbe2224f75b14ef.
• Local backup freshness/off-server copy checker tooling is implemented and tested. Production scheduling, recurring off-server copy configuration, external alert delivery, and restore drill remain pending; the 2026-07-11 update records one copied/off-server freshness/checksum checker pass for timestamp basename 20260711T190355Z.
• Local public endpoint monitor probe tooling is implemented and tested for health/readiness/latest-risk assertions with explicit freshness policy inputs. The 2026-07-14 operator decision accepts Cloudflare Tunnel Health Alert plus an external homepage availability monitor for the small operator-watched pilot; dedicated external /api/health and /api/readiness freshness monitor proof and delivery evidence remain pending before broader launch.
• Local import provenance packet tooling is implemented and tested for sanitized manifests. A real production import provenance packet still requires operator-collected source/archive, validation/readiness, cache, and deployment evidence outside the repository.
• Local launch snapshot packet tooling is implemented and tested, tagged launch-snapshot-helper-local-evidence-2026-07-11 at e1a4dc521343b8c48060358204ff5c9cfd7e1ecf. The 2026-07-15 final launch snapshot packet was created and validated outside Git, and the watched first-traffic observation completed for the small operator-watched pilot.
• Production readiness, operations, security, testing, architecture, and data-pipeline documentation.

Current Roadmap Status

Current status reflects public/operator evidence through 2026-07-15 from public hostname checks, the backup-gated USB production update, the fresh backup/off-server copy evidence, and the post-deploy/evidence notes in Production Readiness. Repository-local bundled CSV and helper evidence recorded on 2026-07-11 comes from repository files and local tags only. Local tags, helper scripts, Dependabot configuration, accessibility and dependency/license notes, and bundled CSV commits remain local repository evidence only; production status depends on the recorded operator/public-host evidence.

As of the 2026-07-11 local pre-deployment reconciliation, the repo has local helpers for backup freshness/off-server checks, import provenance manifests, public endpoint monitor probes, and launch snapshot packets. The later 2026-07-15 evidence closes the final snapshot and first-traffic gates for the small operator-watched pilot only. The same helper evidence does not close production backup scheduling, broader direct import provenance, broader-launch API readiness/freshness monitoring and alert delivery, restore drill, or commercial/broader-launch readiness.

Phase	Status	Repository evidence
Phase 1: Public Trust Layer	Complete	ca85ad4, frontend/src/App.tsx, frontend/src/App.test.tsx
Phase 2: Data Source Resilience And Documentation Hygiene	Complete	9fe25cd, 7f7b8c4, collector/collector/main.py, collector/tests/test_downloaded_csv_import.py, collector/tests/test_public_cmc_download.py
Phase 3: CI And Quality Gates	Complete	1b162a5, .github/workflows/ci.yml, docs/engineering/testing-and-quality.md
Phase 4: Frontend Production Quality	Complete	22793fb, frontend/e2e/frontend-quality.spec.ts, frontend/src/Chart.tsx, docs/engineering/frontend-qa.md
Phase 5: Performance, Caching, And Abuse Protection	Complete in repository; post-deploy Cloudflare HIT/fast repeat behavior verified for public smoke	3c66df9, 5bb179d, cache-warmup-local-complete-2026-07-05, 2026-07-07 repeated public cache requests about 0.14s to 0.22s with Cloudflare cf-cache-status: HIT, backend/app/public_cache.py, backend/app/main.py, scripts/cloudflare_edge_rules.py, backend/tests/test_cloudflare_edge_rules.py
Phase 6: Production Environment And Deployment	Verified for USB deploy/update and public freshness; closed as stale-data blocker	2026-07-11 backup-gated USB update passed for commit 86cb2dad889baf24a7464a105bbe2224f75b14ef with server-reported exit code 0; public readiness/latest checks passed with latest_date=2026-07-10, row_count=5842, data_fresh=True, and required cache headers present.
Phase 7: Backups, Restore, And Monitoring	Partially verified; small-pilot monitoring accepted with limitation	One checksum-verified off-server USB backup copy is recorded for 2026-07-07, the 2026-07-11 backup-gated USB update records copied/off-server freshness/checksum checker status valid and fresh for 20260711T190355Z, and the 2026-07-15 fresh manual backup/off-server copy records timestamp basename 20260715T082457Z with PostgreSQL dump, BTC CSV, manifest, and checksum categories present plus copied-backup SHA-256 verification passed. The local backup freshness/off-server copy checker and public endpoint probe are implemented and tested, and the latest public readiness/latest-risk checks were healthy and fresh through latest_date=2026-07-14. The 2026-07-14 operator decision accepts Cloudflare Tunnel Health Alert plus public homepage availability monitoring for the small operator-watched pilot. Restore drill remains deferred because the current setup has only the live production server and no separate restore target; recurring production backup scheduling/off-server-copy evidence, dedicated external /api/health and /api/readiness monitoring, alert delivery, backup freshness alert, collector failure alert, direct production validation/import metadata, and exact import source path/category remain pending for broader launch or later operations.
Phase 8: Launch Checklist And First Traffic Test	Completed for the small operator-watched pilot	2026-07-15 evidence records public readiness/latest fresh for 2026-07-14, row_count=5846, risk_state=low, readiness no-store, latest-risk cache/version headers present, final launch snapshot packet basename launch-snapshot-20260715T121952Z.json, operator approval from the continuation request, and watched first-traffic evidence with no waitlist POST or production mutation. The 2026-07-15 fresh backup/off-server copy, manual/native browser QA, and assistive-tech proxy QA support the small-pilot run. Broader direct import provenance, dedicated API monitoring, alert delivery, restore drill, true manual assistive-tech pass, full WCAG/legal accessibility, and commercial/broader-launch readiness remain broader-launch work.
Phase 9: Post-Launch Learning Loop	Active for small pilot	Starts from the completed 2026-07-15 watched first-traffic observation; collect sanitized feedback, repeat-use, source, endpoint-demand, and waitlist signals without raw contacts or private analytics.
Phase 10: Risk Methodology Research	Pending	Starts only after launch evidence justifies method work; current production metric remains crypto-scout-canonical-v1.1
Phase 11: Distribution Channel Research	Pending	Evaluates PWA, Telegram Mini App, browser extension, and other channel packaging after launch evidence

Current production-pilot progress after Phase 1-5:

• public hostname bitcoinriskbrief.minihub.app is connected through Cloudflare and returned 200 for /api/health and /api/risk/latest on 2026-07-05, post-deploy public checks returned fresh readiness on 2026-07-07, a 2026-07-08 evidence pass returned HTTP 200 for /api/health, /api/readiness, and /api/risk/latest, a 2026-07-10 monitoring evidence pass again returned HTTP 200 for those same public paths, the 2026-07-11 backup-gated update probe again passed public readiness/latest checks, and the 2026-07-15 public GET-only evidence passed health/readiness/latest-risk checks;
• public readiness/latest evidence on 2026-07-15 recorded latest_date=2026-07-14, covered_end=2026-07-14, data_age_days=1, max_age_days=2, source=coinmarketcap_csv, row_count=5846, latest risk 0.2694028326125623, risk_state=low, readiness no-store, latest-risk cache headers present, and Cloudflare HIT on the cacheable latest-risk response; the prior stale-data launch blocker is closed;
• repository-local bundled canonical CSV evidence now includes rows through 2026-07-14; commit e204acc is tagged btc-csv-through-2026-07-14-evidence-2026-07-15. This is local repository data evidence only and does not prove deployment, production database import, public-host freshness after that commit, or direct production source/archive provenance;
• public read caching is observable through Cache-Control, validation-versioned ETag, X-Cache, and X-Cache-Version; post-deploy repeated public cache requests after warmup were fast with Cloudflare cf-cache-status: HIT, while the cached origin X-Cache header may still show MISS;
• browser-capable public-hostname QA passed on 2026-07-07 with Playwright desktop/mobile smoke, fresh data, visible Current risk 28%, Low, latest date 2026-07-06, Model price $63,289, Low $61,276, High $64,598, and no mobile horizontal overflow at a 390px viewport; the 2026-07-11 desktop/mobile public smoke verified H1/readiness/latest date visibility, nonblank charts, EN/RU toggle behavior, no horizontal overflow, the privacy/disclaimer note, and no waitlist POSTs; the 2026-07-15 manual/native browser QA evidence completes the small-pilot manual keyboard/native desktop and mobile browser blocker, and the 2026-07-15 assistive-tech proxy QA evidence completes the AI-doable proxy check while leaving a true screen-reader/manual assistive-tech pass as an accepted small-pilot limitation;
• Cloudflare Rulesets API apply succeeded for the custom waitlist bot challenge, one waitlist rate-limit rule, waitlist cache bypass, and public-read origin-cache rules;
• the active Cloudflare plan did not entitle the zone to execute the managed WAF ruleset, more than one rate-limit rule, a rate-limit period other than 10 seconds, or a mitigation timeout other than 10 seconds, so the current public edge config intentionally uses the Free-plan-compatible subset.

Remaining production-pilot and broader-launch gaps:

• keep the production host runbook, .env, service path, and data-refresh workflow aligned with the verified USB deploy path;
• keep scheduled public CoinMarketCap refresh verification current on the production host without a COINMARKETCAP_API_KEY; the 2026-07-15 public evidence proves first-traffic-window freshness, not future scheduled runs;
• continue cache-miss/edge-hit latency measurement for any endpoint not covered by the 2026-07-07 post-deploy smoke; add precomputed expensive payloads only if future users would still pay visible database/build cost after startup or nightly import;
• keep the current Cloudflare Free-plan-compatible subset limited to a small operator-watched pilot; managed WAF, bot protection upgrades, and broader API burst-rate-limit controls are deferred until broader traffic or observed abuse risk;
• keep the 2026-07-15 fresh manual backup plus off-server copy evidence available with the final launch snapshot and first-traffic evidence; recurring daily backups, recurring off-server copies, production backup freshness monitoring, and backup freshness alerts are deferred until after the initial operator-watched pilot; the restore drill is explicitly deferred until a staging or intentionally empty restore target exists;
• collect post-traffic learning evidence from waitlist/source/locale/repeat-use/request signals without raw contacts, private analytics, or private messages;
• keep broader browser/device and accessibility evidence pending beyond the small-pilot manual/native pass and local assistive-tech proxy evidence; a true manual screen-reader/assistive-tech pass and full WCAG/legal approval remain unclaimed;
• tracked repository documentation and portfolio presentation work is locally complete as of 2026-07-06, but this does not close restore drill, backup freshness monitoring, broader-launch dedicated API monitoring and alert delivery, direct import source/archive proof, browser/device/manual accessibility, GitHub settings, or sibling product-ideas evidence;
• keep direct production import source/archive proof and production refresh/import verification pending for broader launch; the local scripts/import_provenance_packet.py helper is implemented/tested for future sanitized manifests, but repository CSV commit/tag evidence is supporting local evidence only, not a broader production import packet;
• use the local scripts/launch_snapshot_packet.py helper for future sanitized launch/update packets when needed, while keeping the 2026-07-15 final snapshot separate from the completed first-traffic observation.

Roadmap Phases

Phase 1: Public Trust Layer

Status: Complete. Verified by commit ca85ad4, frontend/src/App.tsx, and frontend/src/App.test.tsx.

Goal: make the public page honest enough for first external users.

Deliverables:

• Fetch /api/readiness from the frontend.
• Render a compact freshness and validation badge near the latest data date.
• Show methodology version, latest date, covered end, and data age.
• Add a concise disclaimer: risk levels are scenario outputs, not financial advice or trading instructions.
• Add a public methodology link or compact methodology section that references crypto-scout-canonical-v1.1.
• Derive and render next-band price callouts for the nearest 0.30 and 0.70 risk thresholds.

Acceptance criteria:

• A user can tell whether the latest import passed validation before trusting the chart.
• A user can find the methodology reference from the product page.
• The page states that risk levels are not buy/sell instructions.
• Tests cover readiness rendering, degraded state copy, methodology/disclaimer copy, and next-band callouts.

Phase 2: Data Source Resilience And Documentation Hygiene

Status: Complete. Verified by commits 9fe25cd and 7f7b8c4, collector CLI support in collector/collector/main.py, and CSV intake tests in collector/tests/test_downloaded_csv_import.py and collector/tests/test_public_cmc_download.py.

Goal: keep BTC data fresh without depending on a paid CoinMarketCap API account and keep documentation aligned with the actual system.

Deliverables:

• Add an operator workflow for downloading BTC historical CSV data from https://coinmarketcap.com/currencies/bitcoin/historical-data/.
• Add a validated import path that stages the downloaded CSV, normalizes it to the canonical local CSV shape, checks daily continuity, and atomically replaces the canonical CSV only after validation passes.
• Keep the official CoinMarketCap API delta refresh as an optional path, not as a production-pilot requirement.
• Document how operators verify the CSV tail date, run import/backfill, and confirm /api/readiness.
• Clean up project documentation so current behavior, planned work, and historical implementation notes are clearly separated.
• Remove or revise stale documentation that still describes older data-source, deployment, or launch assumptions.

Acceptance criteria:

• A production operator can refresh BTC data from a downloaded CoinMarketCap historical CSV without a paid API key.
• Invalid, partial, non-contiguous, or schema-incompatible CSV downloads do not replace the canonical CSV.
• docs/engineering/data-pipeline.md, docs/operations/operations.md, and docs/operations/production-readiness.md agree on the supported refresh paths.
• docs/README.md clearly identifies the current operational docs and the historical design/spec archive.

Phase 3: CI And Quality Gates

Status: Complete. Verified by commit 1b162a5, .github/workflows/ci.yml, and docs/engineering/testing-and-quality.md.

Goal: protect main and make future changes cheap to verify.

Deliverables:

• Add GitHub Actions for backend tests, collector tests, frontend tests, and frontend build.
• Include python3 -m compileall backend collector.
• Add a compose/build validation job if runner time is acceptable.
• Document required checks and branch protection expectations.

Acceptance criteria:

• Every push to main runs the automated checks.
• A failing backend, collector, frontend test, or frontend build blocks promotion.
• The CI workflow is documented in docs/engineering/testing-and-quality.md.

Phase 4: Frontend Production Quality

Status: Complete. Verified by commit 22793fb, frontend/e2e/frontend-quality.spec.ts, frontend/src/Chart.tsx, and docs/engineering/frontend-qa.md. Repeat a short manual pass on the public hostname for future broader-launch or promotion windows when needed.

Goal: reduce avoidable frontend and product-experience risk before pilot and broader public use.

Deliverables:

• Split or lazy-load the ECharts bundle so the main chunk warning is removed or explicitly accepted.
• Add a smoke or e2e check for desktop and mobile layout.
• Verify that chart canvases render non-empty and occupy the expected container width.
• Exercise loading, empty, degraded readiness, and API error states.
• Check the interface in the launch browser/device matrix, including current Chrome, Safari, Firefox, mobile Safari, and mobile Chrome.
• Improve visual styling, spacing, responsive behavior, and chart readability while keeping the page focused on one BTC risk product.
• Keep the page focused on the BTC risk product, not a broad dashboard.

Acceptance criteria:

• npm run build --prefix frontend completes without unexpected warnings, or the remaining warning is documented and accepted.
• Automated smoke checks detect blank charts or obvious mobile layout breakage.
• Error and degraded-data states are usable and do not look like successful fresh data.
• Manual or automated browser/device QA results are documented before public launch.
• The public page looks production-ready on desktop and mobile without adding unrelated dashboard scope.

Phase 5: Performance, Caching, And Abuse Protection

Status: Complete in repository and partially applied at the public edge; post-deploy public smoke on 2026-07-07 verified Cloudflare HIT/fast repeat behavior after warmup, while broader endpoint MISS measurement remains an external launch gate. Verified by commits 3c66df9 and 5bb179d, local tag cache-warmup-local-complete-2026-07-05, backend/app/public_cache.py, backend/app/main.py, scripts/cloudflare_edge_rules.py, and backend/tests/test_cloudflare_edge_rules.py. On 2026-07-01, bitcoinriskbrief.minihub.app returned 200 for public GET smoke checks and 304 for conditional /api/risk/latest revalidation with X-Cache: HIT.

The active Cloudflare plan is using the Free-plan-compatible subset: custom waitlist bot challenge, one waitlist rate-limit rule with period=10 and mitigation_timeout=10, waitlist cache bypass, and origin-header-respecting cache rules for public read endpoints. The 2026-07-12 operator decision pass accepts this subset only for a small operator-watched pilot; managed WAF execution and the broader /api/* burst limit remain deferred until broader traffic or observed abuse risk.

Goal: make the public page fast enough for first traffic and resistant to simple bot or abuse traffic.

Deliverables:

• Define cache headers or an application cache for public read endpoints: latest risk, history, levels, brief, and readiness.
• Invalidate or refresh cached data after a successful collector/import run so users do not see stale risk data after the canonical CSV changes.
• As a pre-traffic hardening follow-up, deploy and verify startup/operator warmup for standard public payloads, then precompute expensive payloads only if the first request after startup or nightly import is still slow.
• Document which endpoints must not be cached, especially POST /api/waitlist.
• Configure Cloudflare WAF managed rules, bot protections appropriate for a public pilot, and edge rate limits for /api/waitlist and /api/*.
• Keep backend waitlist rate limiting as an application-level fallback.
• Add request logging or operational checks that help distinguish real users from abusive traffic.

Acceptance criteria:

• Repeated public page loads do not require unnecessary database work for unchanged daily data.
• Cache behavior is observable and has a clear invalidation path after data refresh.
• If first cache misses are slow, standard public payloads are warmed for the current validation version before active traffic reaches the public hostname.
• Waitlist submissions cannot be cached and still store server-side only.
• Standard public payload warmup has local evidence and is verified in production before active traffic.
• Basic bot, spam, and burst-traffic tests are blocked or rate-limited without breaking normal page use.
• Security and caching expectations are documented in docs/engineering/security-and-privacy.md and docs/operations/production-readiness.md.

Phase 6: Production Environment And Deployment

Status: Verified for the USB deploy/update path and current public freshness as of the 2026-07-11 backup-gated update evidence. The update targeted commit 86cb2dad889baf24a7464a105bbe2224f75b14ef, completed with server-reported exit code 0, and public readiness/latest checks passed with latest_date=2026-07-10, row_count=5842, data_fresh=True, and required cache headers present. The selected deployment path remains the USB-based local-server deployment path. Keep future update evidence current, and keep production .env ownership and scheduled-refresh operation aligned with the runbook.

Goal: run the full stack on the intended production-pilot host.

Deliverables:

• Create production .env from .env.production.example.
• Set production values for APP_ENV, DB_PASSWORD, CORS_ORIGINS, freshness limit, waitlist rate limit, and either the optional COINMARKETCAP_API_KEY or the documented CSV download/import workflow.
• Configure the scheduled refresh strategy so production defaults to public CoinMarketCap download first, optional official API fallback when a key is configured, and manual downloaded CSV import as the last fallback.
• Deploy the repository through the selected production path: direct Git workflow under /opt/bitcoin-risk-brief or local USB deployment under /srv/projects/bitcoin-risk-brief.
• If using the local USB deployment path, prepare the deployment USB from a reproducible kit that contains only the filtered project snapshot, scripts, docs, manifest, and checksums. Do not include local .env, .git, backups, dependency caches, build output, browser artifacts, container images, or offline package mirrors.
• Run validate, start, migrate, and one live run-now.
• Configure Cloudflare Tunnel for the public hostname.
• Keep the frontend bound to localhost when Cloudflare Tunnel is the only ingress.
• Enable baseline Cloudflare HTTPS, WAF, and edge rate limiting for /api/waitlist and /api/*.

Acceptance criteria:

• curl -fsS http://127.0.0.1:3001/api/health succeeds.
• curl -fsS http://127.0.0.1:3001/api/readiness succeeds.
• curl -fsS https://risk.example.com/api/health succeeds for the configured public hostname. Current pilot hostname: https://bitcoinriskbrief.minihub.app/api/health.
• curl -fsS https://risk.example.com/api/readiness succeeds for the configured public hostname. Current pilot hostname: https://bitcoinriskbrief.minihub.app/api/readiness.
• The public frontend loads, API calls use the intended HTTPS origin, and the selected data-refresh path is documented.
• A production deployment with an empty COINMARKETCAP_API_KEY can refresh through the last completed UTC day via the scheduled public CoinMarketCap download path without manual operator action.
• If USB deployment is used, the operator can identify the project revision on the USB and verify that no local secrets were staged.

Phase 7: Backups, Restore, And Monitoring

Status: Partially verified; small-pilot monitoring accepted with limitation. The runbooks and policies are documented, one checksum-verified off-server USB backup copy was recorded on 2026-07-07, the 2026-07-11 backup-gated USB update recorded copied/off-server freshness/checksum checker status valid and fresh for timestamp basename 20260711T190355Z, and the 2026-07-15 fresh manual backup/off-server copy recorded timestamp basename 20260715T082457Z with PostgreSQL dump, BTC CSV, manifest, and checksum categories present plus copied-backup SHA-256 verification passed. Local backup freshness/off-server copy checker tooling plus local public endpoint probe tooling are implemented and tested. Public readiness and latest-risk checks are healthy and fresh in the latest update evidence, and the 2026-07-14 operator decision accepts Cloudflare Tunnel Health Alert plus public homepage availability monitoring for the small operator-watched pilot. Dedicated external /api/health and /api/readiness monitoring, alert delivery, recurring production backup freshness monitoring, and collector failure alerts remain pending before broader launch or later operations. The current setup has only the live production server, so the restore drill remains an accepted limitation/deferred until a separate staging or empty restore target exists.

Goal: make production operations recoverable.

Deliverables:

• Schedule scripts/backup.sh daily on the production host.
• Copy backups off the server.
• Require a fresh backup before USB-based production updates and copy that backup off the server before promotion.
• Track backup age and backup command failures; use scripts/check_backup_freshness.py for the local freshness and checksum-validity check once the production freshness window and off-server root are chosen.
• Run a restore drill into a staging or intentionally empty restore target when one exists; do not run the drill against the live production database.
• Before broader launch, configure public uptime monitoring on /api/health.
• Before broader launch, configure production gate monitoring on /api/readiness.
• Before broader launch, alert on collector refresh failures and readiness degradation after the daily collector window.
• Alert when the scheduled public CoinMarketCap refresh fails, when optional API fallback is used after a public-download failure, or when /api/readiness is stale after the nightly update window.
• Keep the accepted Cloudflare Tunnel Health Alert active for the small pilot, and expand connector-health evidence before broader launch if needed.
• Document credential/account ownership and recovery paths for GitHub, Cloudflare, domain, production .env, backups, server access, and optional CoinMarketCap API credentials.
• Define a dependency and security maintenance cadence for container images, Python packages, npm packages, GitHub Actions, and vulnerability or secret scans.
• Track disk usage, database volume growth, backup directory growth, container restart loops, domain ownership, and infrastructure cost/resource limits.
• Create a short incident response runbook for readiness degradation, data refresh failures, waitlist failures, Cloudflare Tunnel issues, stale cache, backup failures, and disk pressure.
• Define a data correction and service-target policy for bad CSV/import/risk incidents, correction notes, cache safety, freshness, RPO/RTO, and pilot downtime boundaries.
• Define an import provenance and source archive policy for production data imports: source snapshot, sha256, retrieval method, row count, covered range, expected tail, validation/readiness output, and cache evidence.

Acceptance criteria:

• A recent PostgreSQL dump and BTC CSV backup exist off-server.
• A production update runbook includes the backup-before-update gate for USB-based deployments.
• A restore drill has been completed and documented.
• Readiness failures produce an alert before broader launch; the small pilot currently accepts homepage/Tunnel monitoring with operator watching instead of dedicated API readiness/freshness alerts.
• Scheduled no-key refresh failures are visible in collector logs during future pilot windows and in alerts before broader launch, and failed downloads do not rewrite the canonical CSV.
• Operators know how to inspect collector, backend, frontend, and database logs.
• Operators know who owns production credentials and what to do in the first 15 minutes of common incidents.
• Operators know how to classify and correct a published bad-data or wrong-risk incident without silently serving a known-wrong risk value.
• Operators can identify which source file or download produced a production validation version and where its sanitized evidence is stored.

Phase 8: Launch Checklist And First Traffic Test

Status: Completed for the small operator-watched pilot. The 2026-07-15 evidence recorded public readiness/latest fresh for 2026-07-14, row_count=5846, risk_state=low, readiness no-store, latest-risk cache/version headers present, fresh manual backup/off-server copy evidence, manual/native browser QA, assistive-tech proxy QA, a final launch snapshot packet created and validated outside Git, operator approval from the continuation request, and watched first-traffic evidence with no production waitlist POST or production mutation from this workspace.

This phase is complete only for the small pilot. Broader production-host accessibility evidence, a true screen-reader/manual assistive-tech pass, full WCAG/legal accessibility approval, broader direct import provenance, dedicated external API monitoring, alert delivery evidence, restore drill evidence, and commercial/source-terms readiness remain pending broader-launch work.

Goal: launch deliberately and measure product demand.

Small-pilot deliverables completed or accepted with limitation:

• Final launch snapshot packet created and validated outside Git before traffic.
• Public GET /api/health, GET /api/readiness, and GET /api/risk/latest checked for the first-traffic window.
• Public homepage observed in a browser-only watched pass.
• Fresh manual backup/off-server copy evidence recorded for the first-traffic evidence set.
• Browser-like waitlist smoke retained from 2026-07-08; no waitlist POST was performed during the first-traffic run.
• Manual/native browser QA and local assistive-tech proxy QA recorded, with the missing dedicated assistive-tech pass accepted only as a small-pilot limitation.
• Small-pilot monitoring coverage accepted as Cloudflare Tunnel Health Alert plus public homepage availability monitoring.
• Small first-traffic observation completed and recorded as first_traffic_status=completed for this pilot only.

Progress recorded on 2026-07-01:

• GET https://bitcoinriskbrief.minihub.app/api/health returned 200 with {"status":"ok"}.
• GET https://bitcoinriskbrief.minihub.app/api/readiness returned 200 with status: ready, source: coinmarketcap_csv, latest_date: 2026-06-30, covered_end: 2026-06-30, and row_count: 5832.
• GET https://bitcoinriskbrief.minihub.app/api/risk/latest returned 200 with X-Cache: HIT.
• Conditional GET https://bitcoinriskbrief.minihub.app/api/risk/latest with If-None-Match returned 304 with X-Cache: HIT.

Launch snapshot recorded on 2026-07-05:

• GET https://bitcoinriskbrief.minihub.app/api/health returned 200 with status: ok.
• GET https://bitcoinriskbrief.minihub.app/api/readiness returned HTTP 503 with status: degraded, data_fresh: false, latest_date: 2026-06-30, data_age_days: 4, and max_age_days: 2.
• GET https://bitcoinriskbrief.minihub.app/api/risk/latest returned 200 for 2026-06-30T00:00:00+00:00 with a low risk state and expected public cache headers.
• Browser-capable public-hostname QA passed with accepted limitations, but the public page visibly showed stale data.

Post-deploy snapshot recorded on 2026-07-07:

• USB deploy verification passed.
• GET https://bitcoinriskbrief.minihub.app/api/readiness returned HTTP 200 with data_fresh: true, latest_date: 2026-07-06, covered_end: 2026-07-06, and data_age_days: 1.
• GET https://bitcoinriskbrief.minihub.app/api/risk/latest returned HTTP 200 for 2026-07-06T00:00:00+00:00 with risk_state: low, price_usd: 63289.47099956666, model_price_usd: 63289.47099956666, low_usd: 61275.826328, and high_usd: 64597.5707661.
• Public Playwright smoke passed on desktop and mobile: Current risk 28%, Low, latest date 2026-07-06, Model price $63,289, Low $61,276, and High $64,598.
• Mobile overflow passed with viewport width 390 and scroll width 390.
• Repeated public cache requests after warmup were about 0.14s to 0.22s with Cloudflare cf-cache-status: HIT and age around 33 to 35. App-level X-Cache may still show MISS from a cached origin response, so that header alone is not a public-latency blocker.

Broader-launch follow-ups after Phase 8: broader production-host accessibility evidence and a true screen-reader/manual assistive-tech pass before broader launch or broader accessibility claims, localization add-on if accepted for broader exposure, post-traffic feedback/evidence review, GitHub-hosted Dependabot execution and first PR evidence, external/manual dependency-license confirmation, data-correction/service-target evidence, direct import-provenance source archive and production validation/import metadata proof, external GitHub settings or sibling product-ideas updates if separately requested, and any remaining endpoint cache-miss latency measurement not covered by the post-deploy smoke. The tracked repository documentation and portfolio presentation pass is locally complete as of 2026-07-06. Do not expand the completed small-pilot first-traffic evidence into broader launch claims.

Acceptance criteria:

• The public page is usable on desktop and mobile.
• Waitlist submission works and respects rate limiting.
• The readiness endpoint is 200 at launch.
• Cached public data remains consistent with the latest successful import.
• First public page load after backend startup or nightly import does not expose users to slow database-backed cache misses for the standard public payloads.
• The first-viewport price input labels the HLC3 value as Model price if daily Low and High are shown alongside it.
• The root README, core docs, and sibling product-ideas brief describe current behavior and future ideas without stale claims, and the private/portfolio GitHub description plus topics are ready.
• The product can measure waitlist conversion, repeat visits, source attribution, and endpoint demand without storing raw IP addresses or waitlist contact values in analytics events.
• Enabled locales pass desktop and mobile QA without clipped text, overlapping UI, inconsistent no-advice framing, or broken waitlist locale attribution.
• Public-host privacy/terms/disclaimer and metadata verification stay current after future updates, and waitlist handling, account ownership, dependency maintenance, accessibility, data-source terms, and incident-response expectations are documented before broad external exposure.
• Release notes, key product decisions, support/contact path, dependency-license review plus external/manual confirmation, first-user feedback review, and launch/backup/restore evidence are documented before broader external exposure.
• Bad-data correction flow, correction-note rules, cache safety, freshness target, RPO/RTO boundaries, and pilot downtime tolerance are documented before broader external exposure.
• Production import evidence links source snapshots, hashes, retrieval metadata, validation/readiness output, and cache evidence without storing secrets or PII in the repository.

Phase 9: Post-Launch Learning Loop

Status: Active for the small operator-watched pilot.

Goal: decide whether the single BTC risk signal is worth extending.

Operator runbook and first evidence-packet template: Pilot Learning Loop.

Founder-led acquisition test, campaign assets, and decision scorecard: Marketing and Growth.

Deliverables:

• Review waitlist conversion, repeat visits, and direct user questions through sanitized aggregate counts and themes only.
• Track requests for alerts, daily notifications, and personal plan comparisons.
• Run an Agent Access And Risk-Signal Licensing Demand Test if the small-pilot traffic evidence creates enough attention to justify a small integration experiment.
• Publish a lightweight Agent Access Pack for HTTP-capable agents that uses the existing public endpoints, requires a readiness-first flow, and keeps the risk output framed as analytics rather than financial advice.
• Track source=agent_access waitlist leads and direct integration requests for API keys, webhooks, MCP, SDKs, embeds, alerts, or commercial reuse.
• If professionals or agent builders ask to reuse only the BTC risk metric, test a low-friction EUR 9-19/month early license before designing enterprise pricing. This test should cover one product or AI agent, clear attribution, current methodology/freshness metadata, and modest usage; it must exclude redistribution, white-label, SLA, high-volume limits, and custom methodology work.
• If agent or professional-product demand appears, design client-level API usage tracking with API client identities, key identifiers or hashes, daily request counts, endpoint groups, methodology version, status counts, and usage limits. Do not use raw IP addresses as the billing or licensing identity.
• Avoid broad feature expansion until demand signals justify it.
• If demand is positive, design the next validation increment: alerts, daily email/Telegram, paid beta, or paid API access for integrations.
• Before recurring email or Telegram delivery, complete the email/outreach readiness gate: sender identity, platform ownership, opt-in source, unsubscribe or stop handling, provider recovery, no-advice framing, and privacy copy.
• Before accepting the first paid-beta payment or paid risk-signal license, complete the paid-beta/licensing readiness gate: payment or invoice path, owner, currency, tax assumptions, refund/cancel policy, entitlement, attribution, support/contact path, usage limits, and separation from anonymous analytics.
• Before broader professional exposure, review account recovery paths, synthetic journey monitoring needs, and a small trust artifact covering methodology version, data source, freshness expectation, and accepted limitations.
• Before adding analytics tables, API keys, paid API access, widgets, agent-specific contracts, or methodology-v2 behavior, complete the API/DB change-management gate: classify additive/risky/breaking changes, preserve endpoint compatibility where practical, document migrations, run focused contract tests, and define rollback.

Acceptance criteria:

• Product decisions are based on usage and waitlist evidence, not feature appetite.
• Pilot evidence packets record public readiness, aggregate waitlist/source/locale/contact-type counts, sanitized support themes, decision criteria, and explicit no-raw-data safety checks.
• Agent access is judged by waitlist leads and integration requests, not raw API traffic alone.
• The first agent-access experiment does not add new API, auth, billing, SDK, MCP, or SLA scope before demand is proven.
• The EUR 9-19/month risk-signal license is treated as an early paid-intent test, not as a complete commercial API plan or redistribution license.
• Professional product or agent usage is judged by explicit source values or future client/API keys, not by raw IP traffic alone.
• The next scope is a small validation step, not a general crypto dashboard.
• Recurring notifications, paid beta access, paid risk-signal licenses, and broader trust claims are gated by explicit readiness checks rather than added opportunistically.
• Future API clients, agents, paid integrations, analytics schema, and methodology-version changes are protected by explicit API compatibility, migration, backup, verification, and rollback rules.

Phase 10: Risk Methodology Research

Status: Pending.

Goal: evaluate whether the BTC risk metric can become more accurate, robust, or explainable without destabilizing the public product.

Deliverables:

• Keep crypto-scout-canonical-v1.1 stable through the production pilot and initial demand test.
• Define what "more accurate" means before changing any formula.
• Compare the current methodology against candidate inputs only after launch evidence justifies research work.
• Treat the Fear and Greed Index as external context or a confirmation signal, not as a default core-score component.
• Research on-chain data as a possible future crypto-scout-canonical-v2 input, starting with one durable valuation-family candidate instead of a broad indicator basket.
• Start with open or free data sources and document access, licensing, attribution, history depth, and update behavior before considering paid data or node-backed infrastructure.
• Treat a self-hosted Bitcoin node as unnecessary for the first research pass because MVRV, realized cap, NUPL, and SOPR-style metrics require an indexer, historical prices, and a separate calculation pipeline beyond raw node data.
• Require any candidate data source to have historical coverage, licensing clarity, reproducible backfill, stable daily updates, documented revision behavior, and operational failure behavior that does not break readiness.
• If a new methodology wins, design it as a versioned v2 with side-by-side comparison, updated docs, API metadata, and interpretation limits.
• If methodology v2 changes endpoint fields, cached payload assumptions, or database schema, apply the API/DB change-management gate before production exposure.

Acceptance criteria:

• No production metric change happens before there is launch usage evidence and a written research comparison.
• Methodology decisions are based on defined quality criteria, not a general desire for a more complex formula.
• Fear and Greed does not enter the core score unless later evidence overrides the current context-only recommendation.
• On-chain candidates are evaluated for data quality and operational reliability before any production integration.
• The first research pass does not require paid data or a self-hosted node unless the source review justifies that infrastructure.
• If evidence is weak, the product keeps crypto-scout-canonical-v1.1 and avoids methodology churn.

Phase 11: Distribution Channel Research

Status: Pending.

Goal: evaluate whether additional packaging and platform channels can improve discovery, repeat use, and paid-intent signals without turning the product into a multi-platform maintenance burden.

Deliverables:

• Create a channel scorecard for PWA, Telegram Mini App, browser extensions, VK Mini Apps, WeChat Mini Programs, and Discord Activities.
• Evaluate PWA/installable web app first because it reuses the current web product with the lowest packaging overhead.
• Evaluate Telegram Mini App as the first social-platform experiment for crypto-native distribution and future notification or subscription tests.
• Treat browser extensions as later candidates that need a real daily utility, such as a BTC risk badge, popup, quick link, or validated alert workflow.
• Keep VK Mini Apps, WeChat Mini Programs, and Discord Activities conditional until audience, partner, or community evidence justifies platform-specific work.
• Track channel demand through explicit waitlist or analytics source values such as source=pwa, source=telegram_mini_app, and source=browser_extension.
• Preserve readiness/freshness display, API error handling, degraded-data states, and no-financial-advice framing in every channel experiment.

Acceptance criteria:

• No more than one new distribution channel is implemented at a time.
• The first experiment has defined source tracking and success metrics before implementation.
• Platform wrappers do not introduce new backend scope unless a separate design justifies it.
• Browser extensions are not published as simple website launchers.
• WeChat, VK, and Discord remain out of scope until channel-specific demand exists.
• Distribution work supports retention and demand validation; monetization remains tied to alerts, recurring briefs, paid API/agent access, or premium context.

Working Order

Recommended implementation order:

1. Public Trust Layer.
2. Data Source Resilience And Documentation Hygiene.
3. CI And Quality Gates.
4. Frontend Production Quality.
5. Performance, Caching, And Abuse Protection.
6. Production Environment And Deployment.
7. Backups, Restore, And Monitoring.
8. Launch Checklist And First Traffic Test.
9. Post-Launch Learning Loop.
10. Risk Methodology Research.
11. Distribution Channel Research.

Current active phase: Phase 9, post-launch learning loop for the small operator-watched pilot. Phase 8 is complete only for that small pilot; broader-launch limitations remain tracked in Production Readiness.

Production-Pilot Gate

The project met the small operator-watched production-pilot gate for the 2026-07-15 first-traffic window when:

• Phase 1 is complete;
• BTC data refresh works through the documented CSV download/import path or an explicitly configured CoinMarketCap API key;
• scheduled production refresh can run without a CoinMarketCap API key by using the public CoinMarketCap download path;
• CI passes on main;
• the production host returns 200 from public /api/health and /api/readiness;
• the first live data refresh/import has completed on the production host;
• public read endpoints have an accepted caching strategy;
• bot and abuse protection has been configured and smoke-tested;
• a fresh manual backup and off-server copy are recorded for the first-traffic window;
• the accepted small-pilot monitoring coverage remains active: Cloudflare Tunnel Health Alert plus public homepage availability monitoring;
• browser/device QA has been completed for the launch matrix;
• project documentation has been cleaned up and matches the launch configuration;
• the private or portfolio repository presentation has been reviewed if the project will be shown to external reviewers;
• launch operations and governance checklist items are completed except for the recorded accepted limitations;
• a rollback path has been verified or rehearsed.

For future pilot windows, keep the public readiness/latest-risk evidence, selected production revision, backup/update evidence, and accepted limitations current before promoting new traffic.

Before broader public launch, recurring daily backup/off-server-copy automation, dedicated external /api/health and /api/readiness freshness monitoring, readiness-failure alerting, and explicit alert delivery evidence must be recorded.

Related Docs

• Product Spec and Alignment Review, archived
• Production Readiness
• Production Evidence Log
• Operations
• Ubuntu and Cloudflare Tunnel Deployment
• Testing and Quality
• Security and Privacy
• Agent Access And Risk-Signal Licensing Demand Test Design: docs/superpowers/specs/2026-06-30-agent-access-demand-test-design.md
• Product Analytics And Usage Attribution Design: docs/superpowers/specs/2026-07-01-product-analytics-usage-attribution-design.md
• Public Payload Cache Warmup And Precompute Design: docs/superpowers/specs/2026-07-01-public-payload-cache-warmup-precompute-design.md
• Launch Operations And Governance Checklist Design: docs/superpowers/specs/2026-07-01-launch-operations-governance-checklist-design.md
• Documentation And Portfolio Presentation Design: docs/superpowers/specs/2026-07-01-documentation-portfolio-presentation-design.md
• Localization Quality And Language Expansion Design: docs/superpowers/specs/2026-07-01-localization-quality-language-expansion-design.md
• Scheduled Public CoinMarketCap Refresh Design: docs/superpowers/specs/2026-07-01-scheduled-public-cmc-refresh-design.md
• Risk Methodology Research Design: docs/superpowers/specs/2026-07-01-risk-methodology-research-design.md
• Distribution Channel Research Design: docs/superpowers/specs/2026-07-01-distribution-channel-research-design.md