hz/step3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add freemium access economy and token store

Browse Source
This commit is contained in:
hz
2026-07-27 22:20:21 -05:00
parent 1d5d03a4f6
commit 4bbac27b84
40 changed files with 1807 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/STEAM_ALPHA_RELEASE_CHECKLIST.md
+275
View File
@@ -0,0 +1,275 @@
# Steam alpha release checklist
Use this as the go/no-go record for the first external Windows alpha of
**RanaZe: Step 3 Trainer**. Put the owner, completion date, and a link to the
evidence beside each checked item. An unchecked **BLOCKER** means do not admit
testers.
## Release decision
- [x] **BLOCKER — Choose the release vehicle.** **Decision: release the app
free on Steam and keep the existing public web client available. Both clients
use the same account access model. QBank passes and study tokens are optional
in-app purchases; Steam purchases remain disabled until Steamworks
Microtransactions are configured.**
- [ ] Record the decision, target date, tester count, supported countries,
tester-selection method, feedback channel, and person with final go/no-go
authority.
- [ ] Define alpha success and stop conditions: minimum completed sessions,
acceptable crash/error rate, critical defect threshold, support response
time, server-capacity ceiling, and the date results will be reviewed.
- [ ] Define the advertised alpha scope. List working features, known
limitations, expected resets or breaking changes, and features explicitly
excluded from this test.
Decision: Free Steam alpha plus the existing public web client; shared freemium access model
Target date/time and time zone: ____________________
Release owner: ____________________
Build commit SHA: ____________________
Steam base AppID: ____________________
Steam Playtest AppID (if used): ____________________
## Steamworks account and application
- [ ] **BLOCKER — Complete Steamworks onboarding.** Verify the legal business
name, bank and tax details, identity verification, Steam Distribution
Agreement, and team permissions.
- [ ] Pay and activate the Steam Direct app credit for the base application
(currently USD 100 per product, subject to tax).
- [ ] Create the base application and save its AppID above.
- [ ] For a Playtest, create the child Playtest app from **Associated Packages
& DLC**, choose its public name carefully, and save its AppID above. The
public Playtest name cannot be changed after release.
- [ ] Restrict Steamworks permissions to the people who need them; require
Steam Guard and make sure at least two trusted people can handle a release.
- [ ] Decide whether the main store page will be public. A Playtest can instead
use keys without making signups or the store page public, but testers should
not be promised confidentiality merely because access is limited.
## Content, legal, and privacy clearance
- [ ] **BLOCKER — Complete the repository's outstanding originality review for
every released question and explanation.** Retain reviewer, date, sources,
revisions, and disposition.
- [ ] **BLOCKER — Complete the outstanding copyright/license audit for every
image-bearing question.** Remove or replace anything whose reuse rights
cannot be established.
- [ ] **BLOCKER — Complete the duplicate-question review and authoritative
reference verification described in `README.md`.** Release only published,
unflagged, cleared content.
- [ ] Review all other shipped assets—branding, fonts, icons, audio, code,
screenshots, trailer footage, and third-party notices—and retain a license
inventory.
- [ ] Have qualified counsel/ownership review the Terms of Service, Privacy
Policy, educational/medical disclaimer, trademark claims, refund/customer
terms, and the handling of study notes or other user-entered data.
- [ ] Confirm the Steam store description and screenshots never imply medical
advice, clinical certification, guaranteed exam performance, or affiliation
with USMLE, NBME, FSMB, or a licensing authority.
- [ ] Complete Steam's Content Survey honestly and make its answers consistent
with both the build and store page.
- [ ] Verify `[email protected]` is monitored and that account data export,
permanent deletion, provider unlinking, and privacy requests work end to end.
- [ ] Publish and test the production legal pages:
`https://step3.ranaze.com/terms.html` and
`https://step3.ranaze.com/privacy.html`.
## Production service readiness
- [ ] **BLOCKER — Complete the initial PRD launch and question promotion in
`ENVIRONMENTS.md`, including dry run, approval, apply, and post-promotion
verification.**
- [ ] Confirm PRD uses a unique JWT key, PRD Mongo database, production host
names, production legal versions, and production secrets; no UAT data or
credentials may be present.
- [ ] Configure and test the live Steam callbacks, including:
`https://s3q.ranaze.com/api/Auth/steam/callback` and
`https://s3q.ranaze.com/api/Auth/external/steam/callback`.
- [ ] From a clean Steam account, test create-account, link-existing-account,
sign-out/sign-in, expired/cancelled authentication, unlinking, and account
deletion. Confirm the app never asks for or receives a Steam password.
- [ ] **BLOCKER — Configure and test Stripe access purchases on the web** at
both `https://us3q.ranaze.com/api/access/stripe-webhook` in test mode and
`https://s3q.ranaze.com/api/access/stripe-webhook` in live mode. Use distinct
signing secrets, subscribe the required Checkout events, and test all five
fixed-price products. Keep the separate contribution flow only if wanted.
- [ ] **BLOCKER — Keep Stripe checkout unavailable in the Steam build.** Before
enabling purchases there, configure Steamworks Microtransactions, product
IDs, callbacks, reconciliation, refunds, and sandbox tests. Confirm the
desktop export carries the `steam` feature flag.
- [ ] Exercise production readiness endpoints and dashboards, and configure
alerts for API unavailability, elevated 5xx responses, authentication
failures, database capacity, and certificate expiry.
- [ ] Load-test the API at the planned tester count plus headroom. Document a
tester-admission cap and who can stop new admissions.
- [ ] Take and restore-test a production database backup. Record retention,
rollback, incident-response, and credential-rotation procedures.
## Windows release build
- [ ] Install the required Godot 4.6.x release export templates and confirm the
pinned engine version used for the release.
- [ ] Update all visible versions from `pre-alpha`/`0.1.0` to the approved alpha
version in `project.godot`, `export_presets.cfg`, the UI, and release notes.
- [ ] Decide whether to disable the Windows console wrapper
(`debug/export_console_wrapper=1`) for tester-facing builds.
- [ ] Decide whether to Authenticode-sign `RanaZe.exe`; if signing, protect the
certificate, timestamp the executable, and verify the signature.
- [ ] Export only from the reviewed release commit, with a clean working tree,
using Git Bash:
```bash
GODOT_BIN=/absolute/path/to/Godot_v4.6.x-stable_win64_console.exe \
./tools/export_steam_release.sh build/windows/RanaZe.exe
```
- [ ] **BLOCKER — Verify the export reports `deployment_environment="prd"`,
the exact release commit in `build_revision`, and only `s3q.ranaze.com`
production API endpoints.**
- [ ] Confirm the upload directory contains `RanaZe.exe`, `RanaZe.pck`, and all
runtime dependencies, but no source, secrets, `.env` files, export backup,
debug symbols not intended for testers, or test data.
- [ ] Virus-scan the staged files and archive a manifest containing SHA-256
hashes, build command, Godot version, commit SHA, build time, and builder.
## SteamPipe and Steam configuration
- [ ] Download the current Steamworks SDK. The SDK is required to upload with
SteamPipe; integrating the Steamworks runtime API is optional for this app's
existing browser-based Steam OpenID flow.
- [ ] Create the Windows depot and default package for the selected AppID.
- [ ] Create version-controlled SteamPipe app/depot VDF templates with AppIDs
but no Steam credentials. Point the depot content root at the staged Windows
directory.
- [ ] Upload through `steamcmd`, add a human-readable build description with
the alpha version and commit SHA, and first assign it to a password-protected
`alpha` branch.
- [ ] Configure the Windows launch option to run `RanaZe.exe` from the depot
root. Verify OS is Windows and architecture is 64-bit.
- [ ] Set supported language(s) to match what is actually available in the
build. Do not claim interface, audio, or subtitle support that has not been
tested.
- [ ] Configure install/uninstall behavior and required redistributables, if
any. Confirm uninstall does not remove cloud/server account data and that
locally generated sensitive files are understood.
- [ ] If using a Playtest, upload and configure the build on the **Playtest
AppID**, not merely the base game's depot.
- [ ] Test installation, launch, update, rollback, file verification, uninstall,
and reinstall entirely through the Steam client—never only by running the
local export.
## Store and tester communication
- [ ] Prepare truthful short and long descriptions, developer/publisher names,
tags, platform/language support, system requirements, support contact, and
privacy-policy URL.
- [ ] Create required store, library, community, and client graphical assets at
Steam's current dimensions. Use actual alpha screenshots and clearly label
footage or features that are not representative of the current build.
- [ ] Check all asset rights and Steam's graphical asset rules. Localize text
appearing in graphical assets for every language the game claims to support.
- [ ] For Early Access only, complete the Early Access questionnaire, describe
the current state and update plan without promises the team cannot guarantee,
set a price justified by the current build, and use required Early Access
branding wherever keys are sold.
- [ ] Draft tester instructions covering scope, known issues, medical
disclaimer, feedback/bug-report format, log/screenshot handling, privacy,
support hours, update/reset expectations, and test end date.
- [ ] Draft the launch announcement, first patch notes, outage message, and
alpha-ending message before admitting testers.
## Release-candidate acceptance
- [ ] Promote the exact uploaded build to the protected `alpha` branch and have
at least two people test it independently on clean Windows 10 and Windows 11
user profiles.
- [ ] Test at 1920×1080 plus a smaller supported resolution and at 100%, 125%,
and 150% Windows scaling. Check keyboard/mouse navigation, text clipping,
external browser transitions, focus return, and readable error states.
- [ ] Run the complete learning journey: registration and legal consent,
practice question, randomized choices, answer/explanation/reference,
dashboard, review queue, notes/bookmarks, flashcards, CCS, feedback/report,
data export, and account deletion.
- [ ] Run the access journey on web: questions 1–20, rolling-window exhaustion,
one credit per eligible first attempt, no credit for skips/repeats, the
20-credit earning cap, 100-credit redemption, purchase and manual activation
of each pass, exam-token consumption, reset confirmation, and retained
bookmarks/notes after reset.
- [ ] Test offline start, connection loss during a session, API timeout, expired
token, server maintenance, malformed response, and recovery without corrupting
learner progress.
- [ ] Run automated API/Godot tests and the production-equivalent smoke suite;
attach results to the release record. Do not rely only on the web UAT smoke
suite for the Windows Steam build.
- [ ] Verify every feature and claim shown on the store page exists in the
submitted build.
- [ ] Triage all findings. Zero unresolved critical issues; every accepted
non-critical issue has an owner, rationale, workaround, and target release.
- [ ] Obtain written sign-off from engineering, content/medical review, legal/
privacy, operations, and the release owner.
## Valve review and scheduling
- [ ] Complete the selected app's Steamworks store-presence checklist and submit
it for review. Valve advises allowing at least seven business days even though
reviews commonly take three to five business days.
- [ ] After store presence is submitted, complete the game-build checklist,
place a mostly final build on the default branch for Valve, and submit the
build for review.
- [ ] Resolve every Valve review note and repeat the relevant acceptance tests
against any changed build or store material.
- [ ] If publishing the main Coming Soon page, allow at least the current
Steam-required visibility period before an Early Access/full release. Confirm
the exact eligible release date shown in Steamworks rather than calculating
it from memory.
- [ ] For a Playtest, choose limited or open signup, batch size/countries, or
key distribution. Never charge for Playtest access or sell Playtest keys.
- [ ] Schedule the release while the release owner, backend operator, and
support contact are available for the initial monitoring window.
## Launch day
- [ ] Freeze unrelated PRD and client changes; confirm the approved commit,
Steam build ID, depot manifest, store copy, tester count, and rollback build.
- [ ] Re-run public health/readiness checks, login, one question flow, feedback,
legal links, database backup status, alerts, and Steam callback.
- [ ] Set the approved build live on the intended Steam branch.
- [ ] For a Playtest, set the app **Playable**, then admit only the planned
first batch or enable the approved signup mode.
- [ ] Install and launch from a tester account with no developer permissions.
Verify download size, executable, version/SHA, production environment, and
end-to-end authentication.
- [ ] Publish tester instructions/announcement and open the staffed feedback
channel.
- [ ] Record release time, Steam build ID, admitted tester count, incidents,
decisions, and changes in the release log.
## Monitoring, rollback, and alpha close
- [ ] Monitor API/error/auth rates, capacity, reports, support inbox, Steam
discussions, and content-safety feedback at the defined cadence.
- [ ] Acknowledge critical medical-accuracy or copyright reports immediately;
unpublish affected content while it is reviewed.
- [ ] Stop admissions for capacity or support overload. Set the Playtest to
**Not Playable** or roll back its live branch when a stop condition is met,
and communicate the impact to testers.
- [ ] Patch from a reviewed commit, repeat affected acceptance tests, upload to
the protected branch, test through Steam, then promote the exact build.
- [ ] At alpha end, announce the deadline, stop signups, communicate account/
progress retention, and set the Playtest to **Not Playable** when appropriate.
- [ ] Export metrics without exposing personal data; triage feedback into owned
work; hold a retrospective; document the next test's entry criteria.
- [ ] Retain build manifests, approvals, test evidence, incidents, content
review records, and the final release log according to the team's policy.
## Official Steam references
- [Steam Playtest](https://partner.steamgames.com/doc/features/playtest)
- [Steam release process](https://partner.steamgames.com/doc/store/releasing)
- [Steam review process](https://partner.steamgames.com/doc/store/review_process)
- [Uploading to Steam / SteamPipe](https://partner.steamgames.com/doc/sdk/uploading)
- [Steam Direct fee](https://partner.steamgames.com/doc/gettingstarted/appfee)
- [Steamworks onboarding](https://partner.steamgames.com/doc/gettingstarted/onboarding)
- [Content Survey](https://partner.steamgames.com/doc/gettingstarted/contentsurvey)
- [Early Access](https://partner.steamgames.com/doc/store/earlyaccess)
- [Store graphical assets](https://partner.steamgames.com/doc/store/assets/standard)