A green preview is not a release checklist

A working preview answers one useful question: can this version render in the builder's current environment? It does not tell you whether a second user can read the first user's data, whether a clean machine can reproduce the build, or what happens after a production request fails.

Mythos has a deterministic completion gate. The Builder must return builder_done, after which the host checks protected paths, dependencies, syntax, imports, expected scaffold structure, TypeScript, the Vite production build, and bounded desktop and mobile renders. Deterministic diagnostics can return to the same Builder for a limited correction attempt. A run that reaches its time or turn limit without an accepted completion result fails; partial staged files are not delivered. Those checks catch incomplete scaffolds. They are deliberately not a security certificate or a release decision.

Use the delivered commit as the starting point for a normal release review. Everything in the right-hand column stays on the release checklist.

Connect GitHub and let Mythos create a new private repository you own. Before running an install, inspect package.json, its scripts, and any lifecycle hooks. Project or dependency lifecycle scripts can execute during installation, so use a disposable container, virtual machine, or CI runner with no cloud credentials, production secrets, or mounted personal directories.

Start from an empty checkout:

REPO_URL="https://github.com/your-org/your-project.git"
git clone "$REPO_URL" release-check
cd release-check
npm install

For a Vite project, run TypeScript and the production build separately:

npm exec -- tsc --noEmit
npm run build

Before preparing independent release changes, verify that the selected active branch matches the Mythos source. Work on a separate unselected branch or fork, or disconnect GitHub first. Mythos does not force-push or silently overwrite divergent selected-branch history; it surfaces a sync conflict for review.

Use npm ci when the independent repository has a reviewed lockfile. At the time of publication, Mythos projects do not generate one. Record the Node major you intend to support, generate and review the candidate lockfile, and commit both decisions. Then prove repeatability in a second disposable checkout with npm ci; the first npm install is only the candidate, not the evidence.

Test the deployment mode you will actually ship. Mythos projects use Vite publishing with an immutable static build, so inspect dist and verify direct-route refreshes through the target host's SPA rewrite rules. Vite's deployment guide is explicit that vite preview is a local preview tool, not a production server.

List the roles and states your product actually has. If the app has no accounts, do not invent an auth test. If it stores user data, testing only one signed-in account is not enough.

In a non-production environment, use request interception, a stub, or a controlled dependency failure to exercise at least one rejected and one timed-out request; restore the dependency after the test. A loading state that never settles is a blocker. So is an error that exposes a stack trace, credential, internal identifier, database detail, or raw upstream response.

Keep the review risk-based. You do not need to read every generated line in order. Start where identity, money, private data, external APIs, and irreversible actions cross a boundary.

Authentication answers who the user is. Authorization answers what that user may do. A protected layout or hidden button does not protect a database row or a server route.

For a Supabase-backed app, enable Row Level Security on every table exposed through the Data API and test every applicable create, read, update, and delete operation through the API as anonymous, user A, and user B. Supabase's production checklist calls out RLS, the Security Advisor, indexes, load testing, backups, and account protections because no single switch covers the whole boundary.

Then inspect every backend or API endpoint that performs a sensitive operation. Treat those actions like public-facing API endpoints: validate input and verify authorization inside the action itself.

Use OWASP ASVS when the app carries meaningful risk. It gives the review testable requirements instead of the vague instruction to “check security.” RLS is one control within that review, not a substitute for server-side authorization or business rules.

A variable is not secret because it lives in an env file. Values prefixed with VITE_ are exposed to browser code by design, as the Vite env guide documents.

Mythos connects a user's own Supabase project with a public project URL and anon key in the generated frontend. Those values are expected in the browser; safe access still depends on least-privilege grants and correct RLS. A Supabase service-role or secret key is different: it bypasses RLS. Supply it only through server-side secret storage—never commit it, prefix it with VITE_, or let it reach a client bundle.

Before release:

• write down every required variable and whether it is public or server-only;
• show safe user copy when required configuration is absent and keep sensitive detail in access-controlled server logs;
• run secret scanning over source and build output, and use synthetic canary values to test whether a server-only variable reaches the client bundle;
• after removing a leak and inventorying its consumers, rotate exposed server-only secrets and tokens;
• keep safe placeholders in documentation, never working credentials.

This is also where you catch a common handoff failure: the preview depended on environment values the connected repository did not document. Vite public variables are embedded into the browser bundle at build time, so changing the host environment later does not replace an already-built artifact.

Build output is only one part of a release. Check the deployed URL with the same direct routes, roles, and controlled failures used locally. Define the header policy the app needs, add server or API rate limits where an action is expensive or abuse-prone, verify useful 404 and error pages, and keep logs correlated without recording secrets.

For Mythos-hosted publishing, the release is tied to an exact Git revision. An external deployment needs its own record of the source commit and immutable artifact. Neither one restores application data. For a stateful app, define backup frequency and acceptable data loss and recovery time, then complete a restore drill in staging. A last known-good Git SHA cannot undo a destructive database change.

Run the declared unit, integration, and end-to-end tests. Review dependency advisories and licenses without applying blind automatic upgrades. Lighthouse is a useful lab pass; privacy-conscious field metrics from sampled sessions can reveal behavior that lab tests miss. Assign an owner to review errors and field performance during the first release window.

Record the release decision in a four-column table and keep it with the exact source revision.

• Ship: the repeatable build and declared test suites pass, all applicable authorization checks pass, configuration is documented, recovery evidence exists for stateful data, and first-window observation has an owner.
• Block: a cross-user access test fails, a secret reached the client, the build depends on hidden state, or a critical failure has no recovery path.
• Not applicable: the check does not apply to this product, with the reason recorded instead of silently skipped.
• Accepted risk: a non-critical gap has a severity, approver, owner, and expiry or due date. Critical blockers are not deferred this way.

The evidence pack can be small: the clean-build job, a recorded cross-user authorization result, the deployed commit or artifact SHA, and a screenshot of the controlled failure state. That is enough to reconstruct what was tested without turning the release into a paperwork exercise.