VOIDERATION V26: PRE-SCENE INTEGRITY GATE + ENFORCEMENT
Date: 2026-10-30
Scope: Research/planning only. No code, Unity, revision, API, dashboard or
production changes. Reuses V22/V23/V25 and local source bundle.

RECOMMENDED ARCHITECTURE

Use two layers, with distinct security roles:
1. Unity bootstrap for user experience and accidental-failure detection. A
   `RuntimeInitializeOnLoadMethod(BeforeSceneLoad)` entry creates a persistent
   bootstrap/guard before first-scene objects. It checks required local
   components/config, initializes Voideration, and holds a loading overlay until
   trusted verification completes. A first build scene can be a dedicated
   bootstrap, but changing current startup/build order is a separate compatibility
   decision. `DontDestroyOnLoad` singleton and scene-load callbacks detect
   duplicates/transitions and report missing components.
2. Trusted backend admission/enforcement. Worker validates a trusted session,
   checks PlayFab ban, Voideration D1 ban and PendingReview restriction, and
   Photon custom authentication denies admission unless allowed. This is the
   actual security boundary. A modified client can remove local guard, patch
   callbacks, forge local component checks, alter scenes or ignore `Application.Quit`.
   Client bootstrap is not proof of integrity and cannot securely prevent a
   modified client from reaching Photon on its own.

Project inspection confirms Unity 2021.3.32f1; enabled build scenes currently
start with `YesNewTut`, followed by TOS, Menu and Game. No BadGuyScene or
PendingReview enforcement was found in searched local scenes/source. Oculus XR
packages are present; cold-start ordering on Quest has not been runtime-tested.
Prefer integrating with existing login/XR init and avoid changing build order
until device tests preserve first launch and tutorials.

STARTUP / SCENE FLOW

1. App launch: before first normal scene, initialize a single persistent
   Voideration bootstrap; validate local required configuration/components and
   show a non-interactive loading gate. Local checks catch missing/accidental
   components only; no client-side hash alone proves code integrity.
2. Obtain normal PlayFab login/session (and Meta proof only if the chosen
   verified identity flow is available). Worker validates server credential,
   creates a short-lived startup/session challenge, checks one-use nonce,
   expiry, app/build/rule version and session sequence/idempotency. Never trust
   client PlayFabId, client result, local approval, or replayed startup response.
3. Backend returns minimal signed/opaque session result: verification success,
   canonical identity, policy/version and access disposition. Client keeps
   session credential protected as feasible and does not persist an allow result
   across fresh auth. Exact Meta attestation capability and secure Quest device
   attestation are UNVERIFIED; startup handshake is protocol verification, not
   proof that binary is unmodified.
4. Outcomes: Approved/no active restriction -> continue existing TOS/tutorial/
   menu flow. PendingReview restriction -> `BadGuyScene` with pending status and
   review instructions; backend also denies Photon auth. Active PlayFab or
   Voideration ban -> `BadGuyScene` with issuing system, reason, expiry/permanent
   display; Photon gate independently denies. Hard-fail rule -> durable incident
   submission/receipt first, then request `Application.Quit()`.
5. Scene changes: persistent bootstrap observes `SceneManager` load callbacks,
   rechecks required local components/state, prevents accidental progression in
   normal client flow and confirms singleton remains alive. Reverify short-lived
   backend session on re-authentication/expiry; do not request a full startup
   attestation for every scene. Backend admission is checked on every Photon
   connect/reconnect/quick rejoin, not inferred from current scene.

HARD-FAIL DETECTION POLICY / INCIDENT DELIVERY

- Hard-fail is opt-in per named, versioned rule and owner-configured. Restrict to
  high-confidence server-verifiable violations (for example repeated invalid
  authenticated challenge/sequence replay after identity/session is established).
  Do not hard-fail on lag, tracking loss, frame spikes, normal movement variance,
  weak behavior suspicion, missing heartbeat, ordinary timeout or backend outage.
- On trigger, client/backend submits bounded schema and evidence reference using
  a short-lived Worker session capability; backend derives identity, validates
  size/rate/rule and writes incident plus alert-outbox row to D1 atomically. Owner
  dashboard polling sees durable incident immediately. Optional Discord alert
  is asynchronous and secondary. Unity waits only for a bounded deadline and
  treats only an explicit durable receipt/incident ID as accepted.
- Retry a small bounded number with backoff/idempotency key while app remains
  alive. Do not block quit forever. If Worker/D1 unavailable or deadline expires,
  no durable receipt exists: show/record “submission unconfirmed”, optionally
  retain a minimal encrypted local retry item for next launch (best effort only;
  user can delete/modify it), then call `Application.Quit()` because hard-fail
  policy explicitly selected that response. Never claim the owner was alerted or
  apply a ban because delivery failed. On next launch retry idempotently after
  backend authentication; do not let local queue determine access.
- Reliable delivery cannot be guaranteed offline or during Worker/D1 outage.
  Durable backend receipt guarantees incident persistence, not immediate Discord
  delivery. Outbox retries/deduplicates notification; dashboard remains primary.
  Existing Worker lacks D1 incident intake/outbox; `/updateplayers` is a no-op
  and is not a safe reporting route.
- `Application.Quit()` requests app exit; on Quest/mobile it is best-effort and
  not an enforcement boundary. Do not wait for Discord acknowledgement. Server
  must independently deny subsequent Photon admission if the rule also imposes
  a backend restriction/ban.

PENDING REVIEW, DUAL BANS AND PHOTON

- Keep independent state: incident review (`PendingReview`, `Approved`,
  `Rejected/Dismissed`); temporary PendingReview restriction; PlayFab ban;
  Voideration D1 ban; hard-fail incident. Approval clears only PendingReview
  restriction and allows rejoin after authoritative backend confirms. Dismissal
  closes false-positive incident without ban. Bans remain until expiry/revocation.
- Backend is authoritative for all access states. On each new Photon auth,
  validate Photon credential using supported PlayFab/Photon contract, derive
  canonical PlayFabId, check PlayFab effective bans, D1 bans and active review
  restriction; deny if any apply. Never trust client scene selection or cached
  approval. Close anonymous Photon access and every Unity unauthenticated
  fallback before claiming enforcement. Exact Worker-to-PlayFab Photon proxy
  contract and dashboard settings are still staging blockers (V22/V25).
- If either ban/restriction service is unavailable, fail closed for new Photon
  admission with retryable service error, not a ban verdict. Do not fall back to
  anonymous auth. Existing Photon sessions may remain connected: ordinary Worker
  request / connection-time custom auth does not reliably kick an actor already
  in PUN Cloud. Client self-quit/disconnect is cooperative only. Never disrupt an
  entire room or claim kicked without observing it.

FAILURE / FALSE-POSITIVE HANDLING

- Local component missing/corrupt, build mismatch or failed startup handshake:
  show recovery/service error and hold normal progression until required online
  verification succeeds. Distinguish backend unavailable from confirmed ban or
  anti-cheat detection. Use bounded retry/backoff and visible retry state; no
  hard-fail quit for infrastructure failure.
- If offline play is supported, owner must decide whether it can enter a limited
  non-Photon mode. Default for protected multiplayer is fail closed; no offline
  or cached admission to Photon. Do not break local tutorial solely due to an
  optional backend outage unless that is explicitly the product policy.
- Sensor/tracking/latency uncertainty lowers confidence and routes to incident
  review only. Hard-fail requires corroborated high-confidence server evidence;
  no permanent ban from client-only movement or tracking signals.
- Duplicate/replayed startup requests use session ID, monotonic sequence, short
  expiry, nonce and idempotency key. Repeated identical submission returns same
  incident receipt, not duplicate alert/ban. Reject stale challenges; outages are
  not replay evidence.

SECURITY LIMITS / DEPENDENCIES

- Unity early init, scene callback and component-presence checks improve startup
  integrity/UX but a modified Quest build can bypass them. If a stronger hardware/
  binary signal is required, verify Meta App Attestation/entitlement availability
  and server verification for this app; it is not established and still does not
  replace trusted backend authorization. Do not label a local checksum as secure.
- Required before implementation: prove Worker/PlayFab Photon auth adapter;
  implement authenticated incident intake and D1/outbox; define build/rule policy,
  nonce/session expiration and evidence retention; decide offline tutorial policy;
  validate Meta proof/attestation eligibility; choose BadGuyScene flow and preserve
  current scene/build ordering; remove anonymous fallback only after staging.
- Existing `BadGuyScene`, PendingReview route and global bootstrap are not present
  in inspected local project. V24-V25 ban display and dual-ban checks remain
  designs, not implemented controls.

REGRESSION TESTS

1. Quest cold start through current first scene/TOS/tutorial/menu; verify XR
   initialization order, no blank/frozen screen, resume/suspend, and normal login.
2. Missing component/config, duplicate bootstrap, scene load/unload, Game/PVP
   return, level transitions and attempts to bypass local scene guard. Confirm
   backend still denies a modified/bypassed client at Photon auth.
3. Valid Approved user proceeds; PendingReview routes to BadGuyScene and cannot
   reconnect; PlayFab-only and D1-only bans show correct source/reason/expiry and
   are denied; expired/revoked status restores access only after backend confirms.
4. Startup nonce replay, duplicate request, stale session, wrong credential,
   forged PlayFabId, build/version mismatch, malformed response and Worker/D1/
   PlayFab outage; no false ban label or silent multiplayer allow.
5. Hard-fail triggers only for configured rule; incident receipt appears in
   dashboard before quit; timeout/offline shows unconfirmed, boundedly retries,
   exits best-effort and never reports false success. Discord outage does not
   lose durable incident.
6. `Application.Quit()` behavior on Quest and editor/device; verify no reliance
   on it for server enforcement and no lost receipt due to immediate process exit.
7. Preserve Oculus/PCDEBUG login, Photon rooms/Voice/reconnect, inventory,
   currency/purchases, `/link`, MOTD, CCU, Tag/Infection, PVP, locomotion,
   Sandbox/welding, horror hub/LVL1-7 and all existing transitions.

Evidence reused: `research/VOIDERATION_FINAL_ARCHITECTURE_V22_2026-10-30.txt`,
`research/VOIDERATION_DASHBOARD_DESIGN_V23.txt`,
`research/VOIDERATION_DUAL_BAN_V25.txt`, V19/V21/V24, local Unity build settings,
`PhotonVRManager.cs` and `worker.js`. No implementation or production changes.

END OF REPORT