VOIDERATION: CONSOLIDATED PRE-IMPLEMENTATION AUDIT
Date: 2026-10-30
Baseline: V22 + Stage 0; evidence reused from V15-V21 and local source.
Scope: Read-only. No dashboard, production API, deployment, code or revision changes.

EXECUTIVE STATUS

Overall: NOT READY for security implementation or production. READY only for
owner decisions and authorized read-only dashboard inventory. Most key risks
are confirmed in local code, but production deployment/settings are not verified.
The systems fit together only conditionally: the Photon custom-auth adapter,
PlayFab/Meta verification contracts, owner authorization and D1 persistence are
not implemented or proven. V22 is a target design, not a deployed control plane.

Status meanings: CONFIRMED = seen in local source/reports; CONDITIONAL = design
works if stated prerequisites pass; UNVERIFIED = dashboard, provider, or runtime
fact not observed; READY = safe to proceed with specified research/staging step,
not production release.

SYSTEM STATUS / GAPS

1. Identity, PlayFab roles, economy and CloudScript
- CONFIRMED: `Oculus_Login` uses Meta user ID as PlayFab Custom ID without Meta
  server proof; obtains a PlayFab Photon token separately. UserData `Moderator`
  is read by client and missing value is client-written FALSE. Client code has
  direct `AddUserVirtualCurrency` callers. V08 is explicitly a draft and includes
  weak caller/price assumptions; deployed revision is unknown. Client PlayFab
  `PurchaseItem` and custom V08 `OnPurchaseItem` are distinct paths.
- CONDITIONAL: Server-owned roles, rewards and catalog purchases are feasible
  only after every existing reward/purchase caller and product is migrated and
  idempotency/restore are tested. Disabling old client paths early breaks features.
- UNVERIFIED: PlayFab API policies, live CloudScript/Azure functions and event
  rules, moderator data source, catalog/store/currency setup, live purchase
  validation, and PlayFab account history. No dashboard read.
- Gate: inspect policies/revisions/data permissions read-only; stage role and
  economy migration before changing client permissions. Do not promote users
  from client-writable Moderator values.

2. Photon auth, RPCs, reconnects
- CONFIRMED: Unity uses PlayFabId as Photon `username` and PlayFab-issued Photon
  token as `token`. That token is NOT a PlayFab SessionTicket. The manager has a
  20-second path that clears AuthValues and connects unauthenticated. Several
  Tag/Infection RPCs lack sender checks; PUN owner/MasterClient does not make
  gameplay authoritative. A normal Worker request cannot reliably kick a live
  PUN Cloud actor.
- CONDITIONAL: Every-reconnect restriction check requires a supported Worker
  custom-auth adapter that validates the Photon token using the documented
  Photon/PlayFab contract, derives identity from validated response, and checks
  D1. PlayFab `/Server/AuthenticateSessionTicket` validates a SessionTicket, not
  the Photon token. Exact adapter wire format/provider support is not proven;
  do not implement a guessed proxy. If unsupported, defer D1 login restrictions.
- UNVERIFIED: Photon Custom Server URL/provider, anonymous admission/failure
  behavior, Realtime and Voice app association, reconnect/room-rejoin behavior,
  targeted disconnect capability. No dashboard read.
- Gate: staging app must demonstrate auth failure never downgrades to anonymous,
  normal reconnect/Voice/server-switch work, restricted new auth is rejected,
  and existing session limitation is documented. RPC checks can reduce spoofing
  but cannot prove an owner’s pose/hit/collision claim.

3. Meta User Verification, App Attestation and IAP
- CONFIRMED: No Meta proof validation or App Attestation implementation found.
  Existing client IAP handlers grant rewards from callbacks; `OWNED_IAP` is
  client-writable; reviewed paths have restore/transaction gaps. Actual product
  fulfillment/replay behavior needs staging confirmation.
- CONDITIONAL: User Verification needs app permission/eligibility, supported SDK,
  server-side nonce verification and account-link plan. App Attestation is an
  optional integrity signal, not identity or proof of cheating. IAP requires
  server entitlement verification, SKU mapping, idempotent durable fulfillment,
  restore, and consume-after-success for consumables.
- UNVERIFIED: Meta DUC permissions/eligibility, SDK/API compatibility, signing,
  product setup and current SKU/entitlement mapping. No dashboard read.
- Gate: preserve existing PlayFab identities, purchases and entitlements; stage
  migration before enabling mandatory checks or disabling current fulfillment.

4. Cloudflare Worker, D1, heartbeat/replay and capacity
- CONFIRMED: local Worker has existing `/redeem`, `/motd`, Photon webhook,
  Discord interactions, export/setup/health and `/updateplayers` no-op. `/redeem`
  validates SessionTicket only for linking. No D1 binding, incident/restriction
  routes, general session auth or heartbeat was found. Existing logging helper
  swallows Discord errors; query-string secrets exist in some routes.
- CONDITIONAL: D1 incident, restriction, audit, outbox and heartbeat fit if
  atomic/idempotent updates, route compatibility, session expiry, schema limits
  and retry behavior are implemented. Heartbeat is liveness, not anti-cheat.
  Missed beats/backend outage must not punish players. Existing routes/consumers
  must be preserved; migrate URL secrets separately.
- UNVERIFIED: Deployed Worker version/routes/bindings/secrets (names only), D1
  existence, plan and aggregate usage. Never request or record secret values.
- 100 CCU: five-minute heartbeat alone is ~28,800 Worker requests and ~28,800
  D1 updates/day, before auth, incidents, reads and other Worker traffic. Free
  plan fit is CONDITIONAL on shared account quotas/actual row accounting. €0
  recurring is plausible, not established. Need staging load at 20/50/100 CCU,
  inspect Worker requests and D1 rows_read/rows_written and set alert thresholds.

5. Discord alerts and incident review
- CONFIRMED: `ADMIN_CHANNEL_ID` points to `admin-logs` in local config/notes;
  this does not prove privacy. Existing Discord logging is not a durable incident
  outbox. Prior channel audit can be stale.
- CONDITIONAL: Worker -> D1 persist -> outbox -> Discord can provide durable,
  deduplicated alerts. A private channel/bot with least privilege and retries
  must be tested. Do not put tokens, receipts, raw IPs, proof nonce or unnecessary
  evidence in alerts.
- UNVERIFIED: current destination, effective overwrites, webhook/bot mechanism,
  credential owner and successful delivery. No Discord API/dashboard read.
- Gate: verify effective private permissions and test staging delivery, dedupe,
  bounded retries and Discord outage. Alert failure must not lose incident or
  change player access.

6. Incident status, restriction and rejoin policy
- CONFIRMED: no incident or restriction implementation exists. V21/V22 proposal
  separates incident review (`PendingReview`, `Approved`, `Rejected`) from player
  access state and ban. PUN connection auth is admission-time; already connected
  restricted players may remain until disconnect.
- CONDITIONAL: rejoin enforcement works only with verified identity on every
  Photon auth, D1 check, anonymous bypass closed, and fail-closed/retryable
  behavior. Cannot reliably kick existing sessions through ordinary Worker call.
- Recommended default: all detections persist incident + owner alert. Movement,
  latency, tracking loss, hand reach, client Tag overlap and single replay-like
  noise: log/alert only, rejoin allowed. Candidate temporary PendingReview hold
  only after repeated, authenticated, server-verifiable protocol abuse; never on
  backend errors or one timeout. Owner `Approve/Clear` releases; `Reject/Confirm`
  keeps `ConfirmedRestricted` until explicit owner release or separate ban.
  Permanent ban is a distinct audited decision, never automatic from weak signal.
- Gate: owner selects per-rule restriction setting, expiry, review SLA, appeal
  and retention. D1 outage means retryable denial for new auth only if the
  restriction gate is enabled; never anonymous fallback. Existing sessions are
  not mass-kicked.

7. Local owner dashboard
- CONFIRMED: no dashboard, D1 owner API or review workflow exists. Existing
  Worker Discord interactions have signature/owner checks, but this is not a
  dashboard authorization system.
- CONDITIONAL: local-only requires loopback bind (`127.0.0.1`), owner auth,
  CSRF-safe mutations, short sessions and Worker-side authorization on every
  action; browser must not connect directly to D1 or contain backend secrets.
- UNVERIFIED: owner identity/recovery, host machine, secure credential storage,
  privacy/retention and approval policy. No existing dashboard settings to inspect.
- Gate: choose owner auth and recovery method; audit successes and denials.

8. Movement, behavior and gameplay authority
- CONFIRMED: V20 and source show client-influenced movement and PUN gameplay;
  there are no validated numeric thresholds. Identified values (arm length 1.5,
  Tag touchRadius 0.15, boost speeds 6.5/15) are implementation parameters, not
  universal cheat thresholds.
- CONDITIONAL: calibrated telemetry can flag anomalies, with confidence reduced
  for lag, frame spikes, tracking loss, stale samples, boosts and transitions.
  PUN RPC sender/ownership/state/rate/sequence checks can reject invalid messages,
  not make malicious owner state authoritative. Authoritative simulation requires
  separate server architecture/cost.
- Gate: baseline clean play per mode/scene/boost and test false positives before
  any restriction policy; no numeric enforcement threshold is READY today.

9. Feature preservation / regression surface
- CONFIRMED: existing features include PlayFab identity/economy, Meta checkout,
  Photon rooms and Voice, reconnect/server switching, Tag/Infection, PVP,
  movement, welding/Sandbox, horror hub and LVL1-7, items/cosmetics, `/link`,
  MOTD and CCU. Worker and Unity changes cross multiple callers.
- READY: define release matrix now; no feature is approved for removal. Run
  two-account and late-join tests, master/owner migration, room switching, Voice,
  purchase/recovery and backend outage tests. Include duplicate manager/session
  and retry/idempotency checks.
- Gate: staging feature parity and rollback plan before production rollout.

REMAINING DASHBOARD QUESTIONS (READ-ONLY INVENTORY)

1. PlayFab: deployed CloudScript/Azure Functions and PlayStream rules; Client API
   policies; UserData/InternalData permissions; currencies/catalog/stores and
   purchase/receipt controls.
2. Photon: Realtime Custom Server/provider URL, anonymous-client setting, auth
   failure policy, PlayFab association, app IDs; Voice app/auth and reconnect.
3. Meta: User ID DUC/verification eligibility, attestation availability and
   current product/SKU eligibility.
4. Cloudflare: deployed Worker/version/routes, binding names, D1 binding/schema,
   plan and aggregate requests/rows. Do not expose secret values.
5. Discord: private channel effective permissions, bot/webhook identity and
   delivery path; never reveal webhook URL/token.

IMPLEMENTATION DEPENDENCIES AND ORDER

0. Owner approves staging scope and read-only inventory; record redacted
   settings, live revisions, app association and product mappings. Resolve
   policies before touching behavior.
1. Identity/auth proof: decide Meta proof scope and account preservation; prove
   Photon -> Worker -> PlayFab custom-auth contract in a staging app, including
   Voice/reconnect and anonymous rejection. If proxy cannot be proven, defer
   D1-gated Photon restrictions rather than guess.
2. Economy/moderation: server-owned roles, secure report/moderator operations,
   currency rewards, PlayFab purchases and Meta IAP. Migrate all callers and
   restore paths; verify grants exactly once before disabling client routes.
3. Worker/D1 foundation: schema, owner API, audit, durable alert outbox, limits,
   secrets and route-compatibility tests. Preserve `/redeem`, `/motd`, Photon
   webhooks, Discord commands, `/export`, `/setup`, `/health`; plan old query
   secret migration separately.
4. Incident/manual review: trusted identity/provenance, every detection persisted
   and alerted, owner-only audited transitions, loopback dashboard, per-rule
   policy. Movement heuristics default non-restricting.
5. Heartbeat/replay and rejoin: five-minute challenge/sequence/expiry; no per-beat
   KV; D1 restriction lookup at every auth; remove anonymous fallback only after
   staging proves all login/reconnect/Voice paths. No reliable existing-session
   kick claim.
6. RPC hardening + movement calibration; then staged rollout with rollback,
   alert/quota monitoring and owner runbook. A dedicated authoritative game server
   is a separate architecture and cost decision.

OWNER DECISIONS / RECOMMENDED DEFAULTS

- Approve staging-only implementation after redacted settings inventory; approve
  production separately. Recommended: no production changes in Stage 1.
- Meta User Verification: optional until eligibility and existing-account binding
  work; then decide whether to require. App Attestation: optional signal only.
- Confirmed moderator/role source: server-only. Do not trust existing UserData.
- Preserve every product/entitlement and current game mode; migrate before cutoff.
- Incident defaults: every signal gets incident + alert; movement/latency/tracking
  never auto-restrict; only repeated verified protocol abuse may request temporary
  hold; no automatic permanent ban.
- Review semantics: Approve/Clear releases; Reject/Confirm leaves confirmed
  restriction until explicit release or separate ban. Require owner reason and
  audit. Choose hold expiry, review SLA, appeal and evidence-retention period.
- Auth outage: retryable denial for new sessions if restriction enforcement is
  enabled; never anonymous. Heartbeat outage is telemetry unavailable, not guilt.
- Discord: dedicated private owner/staff channel, least-privilege bot, bounded
  retries and deduplicated alerts.
- Dashboard: owner-only local loopback, CSRF-safe server actions, no public host.
- Costs: target €0 additional recurring, but approve a quota threshold/traffic
  alert and accept that capacity or authoritative-server needs may change cost.

TEST / RELEASE GATES

- Auth: valid/invalid/expired credentials; exact Photon token vs SessionTicket
  separation; proxy contract; no anonymous downgrade; room rejoin, fresh login,
  Voice, server switch, restricted denial and owner release. Simulate Worker,
  PlayFab and D1 timeouts.
- Permissions/economy: forged moderator/target IDs denied; client cannot grant
  currency or set role; every legacy reward and purchase maps correctly; duplicate
  callbacks/retries grant once; catalog prices, Meta entitlement, consume/restore
  and existing balances/items preserved.
- Incidents: every test detection persisted once with provenance/time/rule; alert
  sent privately; Discord outage retries without loss/duplicate; non-owner/forged
  dashboard actions denied; approve/reject/release/ban separately audited.
- Replay: duplicate/stale heartbeat, challenge reuse, sequence rollback, expiry,
  lost response and retry; no restriction from missed beat or service outage.
- Gameplay: RPC sender/ownership/legal state/rate tests; Tag/Infection,
  movement/boosts, PVP, welding/Sandbox, horror LVL1-7, levels/transitions, late
  join, owner/master migration, items, room/Voice and duplicate manager checks.
- False positives/privacy: lag, tracking loss, frame spikes, normal movement and
  tag proximity do not restrict; alert/logs exclude credentials and unnecessary
  sensitive data; verify retention/deletion.
- Capacity: 20/50/100 CCU heartbeat plus expected incident/auth traffic; measure
  actual Worker request and D1 row/read limits with existing routes. Set rollback
  thresholds and confirm feature parity before rollout.

READINESS CONCLUSION

READY: owner review of this checklist and read-only dashboard inventory.
CONDITIONAL: staging implementation after decisions and provider/auth prerequisites.
UNVERIFIED: all production dashboard settings, deployments, quotas, alert privacy,
Meta eligibility and Photon proxy support.
NOT READY: production changes, D1-enforced Photon admission, automatic movement
restrictions, or any claim that existing PUN sessions can be reliably kicked.

Evidence reused: V15-V21 reports, V22, Stage 0, local `Oculus_Login.cs`,
`PhotonVRManager.cs`, IAP/economy scripts, `discord-bot/worker.js`, and V08 draft.
No dashboard access or production calls were made.

END OF REPORT