Repository navigation
Prove authenticated saved-game continuity on isolated staging #175
Description
Why now
The protected default branch already uses one canonical placement authority: blockStore serializes replacement snapshots through blocksApi.placeMembers, and Flask validates block ownership, roster ownership/status, canonical Block DNA cells, passability, occupancy, and monotonic health before its trusted adapter writes block_placements.
Cursor PR #174 correctly identified that migration 007 is still source-only, but incorrectly treated the unused legacy persistPlacements() helper as an active browser writer and proposed a second SECURITY DEFINER placement command. That RPC is not required for the live path and would duplicate authority.
The real P0 is operational proof: apply the already-reviewed migration 007 only to the named isolated staging project, verify its RLS/grant behavior, then prove the existing authenticated Flask path survives reload and a second session.
Outcome
A clean authenticated player can claim a fictional block, place fictional crew through the canonical Flask command, collect/play one connected loop, reload, and restore the same authoritative state in a second session—without direct browser placement writes, duplicate receipts, or cross-user visibility.
Scope
In scope
- Correct the saved-game readiness inventory so it names Flask as the sole runtime placement writer.
- Re-run the manifest validator and materialize the approved six-migration non-production workdir.
- Confirm the target identity is
dealt-world-proof-staging(zfgclgnyqlabttymxwuw) and record a dry-run showing migration 007 as the only new migration. - After the separately required operator confirmation, apply migration 007 to that staging target only.
- Re-run database security/performance advisors and two-user RLS/grant checks.
- Prove desktop and 375×812 sign-in → fictional claim/place → one connected consequence → reload → same-account second-session restore.
- Record non-secret evidence and any blocked production-release implications.
Out of scope
- No production Supabase mutation, Vercel promotion, environment/secret change, Edge Function deployment, scheduler, payments, or release tag.
- No new placement RPC, duplicate state store, alternate board, or parallel writer.
- No real people, real gangs, or real-player criminal activity data.
Current file reservation
Integration repair for PR #174 owns only:
docs/SAVED_GAME_READINESS_2026-09-25.md- PR docs(auth): preserve one saved-game placement authority #174 title/body/labels
Runtime, migration, manifest, store, service, hook, and backend files remain unreserved and unchanged by the repair.
Acceptance criteria
- PR docs(auth): preserve one saved-game placement authority #174 contains documentation only and explicitly rejects a second placement authority.
-
python3 backend/supabase/scripts/prepare_nonprod_world_proof.py --validate-onlypasses for the canonical six-migration manifest. - Full frontend validation/build and backend pytest pass on the documentation repair.
- An authorized operator verifies the named staging target and records a
supabase db push --dry-runwith only expected manifest migrations. - A separate explicit operator confirmation is recorded before applying migration 007.
- Two fictional users prove RLS isolation and denied direct writes after migration 007.
- The canonical authenticated loop restores placements, economy, heat/morale, and encounter receipts after reload and a same-account second session.
- Demo mode remains isolated and production remains unchanged.
Dependencies and sequencing
This issue blocks any external-beta or production-release claim in #171. It should complete before expanding visual identity in #169 or treating release-plan PR #173 as promotable evidence.
Activity
BrandDead commentedon Sep 25, 2026
Integration-owner repair is now in progress after a current-base audit.
Root cause: PR #174 inferred an active browser placement writer from the unused legacy
persistPlacements()helper. The live path is already singular:blockStoreserializes placement snapshots throughblocksApi.placeMembersto the owner-checked Flask route, whose trusted service-role adapter writesblock_placements.useBlockSyncdoes not callpersistPlacements(), and its regression test explicitly requires destructive placement persistence to remain with Flask.Reserved files for this repair:
docs/SAVED_GAME_READINESS_2026-09-25.mddocs/PROJECT_LOG.mdThe repair will restore
frontend/src/services/blockPersistence.service.ts, its test,backend/supabase/world-proof-manifest.json, and the proposed migration 008 to the protected-main state; remove the generated rootPR_DESCRIPTION.md; preserve the useful readiness inventory as a corrected documentation-only decision record; and run the full required frontend/backend gates plus the manifest validator.No Supabase target, migration history, RLS policy, Vercel deployment, secret, production data, scheduler, or protected branch will be changed by this repair. Any staging application of migration 007 remains a separate, exact-payload operator confirmation under issue #175.
docs(auth): preserve canonical placement authority
fix(auth): remove duplicate placement writer
BrandDead commentedon Sep 25, 2026
PR #174 merged through protected
main-tL2525as documentation-only commit0d956dacfb11995e81689eaba45b59c564c01676.The duplicate migration 008, browser RPC writer, manifest change, tests, and generated PR-description file were removed. The merged decision preserves the existing serialized Flask placement authority and documents the exact staging-only proof protocol.
Verification completed before and after merge: 946 frontend tests passed with 4 intentional lazy-route skips, the Node 24 production build passed, 95 backend tests passed, the six-migration manifest validator passed, GitHub's required Frontend/Backend checks passed, and the default-branch Vercel deployment record reached
Preview / success. Production remained unchanged.This issue remains open. The next remote step is still gated: verify the exact isolated staging target, record the manifest
db push --dry-run, present the exact migration/rollback payload for a separate operator confirmation, then apply migration 007 to staging only and run the two-user plus reload/second-session proof. No such remote database action was performed during the PR repair.BrandDead commentedon Sep 25, 2026
Reopened after final repository audit. PR #174 corrected the architecture decision and runbook only; it did not execute the isolated-staging dry-run, apply migration 007, run the two-user RLS/grant proof, or verify reload and same-account second-session continuity.
Those acceptance criteria remain outstanding and still block production-release issue #171. Keep this issue open until the exact staging evidence is recorded. No production action is authorized by the merged documentation.
BrandDead commentedon Sep 25, 2026
Live read-only staging reconciliation found a material correction to the current runbook.
Do not apply migration 007 again. The Supabase project list independently confirms
dealt-world-proof-staging(zfgclgnyqlabttymxwuw) isACTIVE_HEALTHY, distinct from production, and the remote migration history already contains:20260925060458 / staging_saved_game_security_hardening_007The stored migration statement matches
backend/supabase/migrations/007_staging_saved_game_security_hardening.sqlafter comment/whitespace normalization: length9960, MD58f9225b99fe04fd70e0f2d16cf0aeee8. Read-only catalog checks also confirm the expected migration effects: queried game tables have RLS enabled;block_placementsis browser-SELECT-only; service-only ledger/map tables have no browser grants; ownership policies are present; search paths are fixed;apply_ghost_world_tickis service-only; andget_leaderboardis not executable byanonorauthenticated.The source preflight still passes: 7/7 migration-contract tests, manifest validation, and an exact six-file disposable workdir with legacy 001/002 excluded.
History warning: the generated CLI files use versions
20260905000000–20260905000500, while the live migration history uses later application versions. A CLI dry-run may therefore list already-applied schema under different version IDs. Treat that as a stop condition—do not rundb push, replay 007, use SQL Editor, or runmigration repairby guesswork.Revised next action:
handle_new_user()execution should be observed during the two-user auth smoke before any separate grant decision.375×812continuity.The old issue/document statement that migration 007 is source-only is now stale and should be corrected in a separately reviewed documentation change after this reconciliation is accepted.
BrandDead commentedon Sep 25, 2026
Documentation reconciliation is starting from protected
main-tL2525at7e5598511097f69622f4a9b8dcd34866dfa100f9.Reason: live read-only staging evidence and the recorded Grokbot/Supabase work confirm migration 007 is already applied to isolated
dealt-world-proof-staging(zfgclgnyqlabttymxwuw). Current canonical docs still say it is unapplied, which creates a replay risk.Reserved files for this docs-only correction:
docs/AI_CONTRIBUTOR_START_HERE.mddocs/SAVED_GAME_READINESS_2026-09-25.mddocs/PROJECT_LOG.md(new append-only entry only)The change will mark the old dry-run/apply gate as completed/superseded, add an explicit do not run
db push, replay 007, use SQL Editor, or repair migration history stop rule, and name the remaining P0 accurately: two-synthetic-user Auth/RLS/direct-write proof plus the canonical Flask claim/place/consequence and reload/same-account second-session checks on desktop and 375×812.No SQL, migration, Auth configuration, secret, production, Vercel, Edge Function, scheduler, payment, gameplay, or release change is part of this branch.
BrandDead commentedon Sep 25, 2026
Documentation reconciliation is complete on protected
main-tL2525.PR #178 merged as
3eda24a3cec2a362fd0446297267b3de8cf08068. The canonical contributor guide, saved-game runbook, and append-only project log now record that migration 007 is already applied to isolateddealt-world-proof-staging(zfgclgnyqlabttymxwuw) as20260925060458 / staging_saved_game_security_hardening_007. They explicitly prohibitdb push, replay, SQL Editor recreation, or migration-history repair for this issue.Verification passed before and after merge: 946 frontend tests with 4 intentional skips, Node 24 production build, 95 backend tests on Python 3.11, 7/7 migration security-contract tests, manifest validation, required GitHub checks, and Vercel status. No SQL, migration, Auth configuration, secret, production, scheduler, payment, Edge Function, gameplay, or release change was made.
Issue #175 remains open. Its sole remaining P0 is the two-synthetic-user Auth/RLS/direct-write proof plus the canonical Flask claim/place/consequence, exact-once receipt, reload, sign-out/in, same-account second-session, desktop, and 375×812 continuity run. If it passes, record redacted evidence here; if it fails, stop and repair only the failed contract in a separate source-reviewed change.
fix(crew): reconcile reviewed stack and retain visible backstory
BrandDead commentedon Sep 30, 2026
2026-09-30 launch-integration handoff: The five single-player PRs through #185 are merged and default-branch CI is green, but this issue remains the P0 outside-beta gate. The external Fable session did not post an authenticated two-user result; a limited read-only count on isolated dealt-world-proof-staging found zero new Auth users since today’s assignment. I have not run or claimed the Auth/RLS/denied-direct-write, canonical Flask claim/place/consequence, exact-once retry, reload/sign-out/in, same-account second-session, or 375×812 proof. No production project or schema was changed, and migration 007 must not be replayed. Next owner: establish staging-only client/service test credentials and execute the existing runbook with two fictional synthetic users; record redacted per-step pass/fail here. If credentials/permission are absent, stop and surface that precise blocker. Demo/QA browser evidence on #188 is separate and cannot close this gate.
BrandDead commentedon Oct 1, 2026
2026-10-01 coordination only: Manus reissued the staging-only two-fictional-user proof to the existing Claude task under manual approvals. The external task is currently paused on an explicit read-only Supabase project-log query approval for isolated dealt-world-proof-staging (
zfgclgnyqlabttymxwuw); Manus did not approve or run that query through Claude. No new synthetic-user Auth/RLS, direct-write denial, Flask claim/place/consequence, exact-once retry, reload, second-session, or 375×812 evidence was posted. P0 remains OPEN and no migration, production, deployment, or schema change occurred. Next: the user must review the exact approval card in Claude; if the external task still cannot continue, runbook execution must be reassigned rather than claiming a demo passed.BrandDead commentedon Oct 15, 2026
2026-10-15 read-only integration audit: PR #206 has an unresolved existing P1 review conversation (#206 (comment)). Hold integration until its author repairs and regression-tests the reviewed failure path. PR #207 has green required checks and no posted material findings but still needs combined-candidate validation and normal merge approval. I have not executed the authenticated two-user saved-game proof; demo/offline validation cannot close #175. Migration 007 must not be replayed. No Supabase/Auth configuration, migration, production, deployment, scheduler, payment or contributor branch changed. I am taking a separately reserved local inventory/Trap repair outside those runtime files.