VOIDERATION STAGE 0: IMPLEMENTATION PREFLIGHT
Date: 2026-10-30
Scope: Read-only source/research review. No dashboard or production access was
used; no code, settings or services changed. V22 is the proposed baseline, not
deployed. Do not send secret values; record only names/status and redacted IDs.

STATUS KEY
Known = established from reviewed source/shared records. Unverified = requires
owner dashboard inspection or staging test. “Blocks Stage 1” means do not ship
that implementation until resolved; optional items are identified.

1. PLAYFAB

Moderator UserData permissions
- Known: Unity `Oculus_Login.CreateKeyIfNot()` reads/writes ordinary UserData
  key `Moderator`; client sets missing key to FALSE and locally trusts TRUE.
  V08 draft has ReadOnlyData helper but does not consistently use it in
  `ReportPlayer`. No verified server-owned moderator source found.
- Unverified: current Title API policy, deployed role source, deployed CloudScript
  revision, external operator checks.
- Inspect: Game Manager > Title Settings > API Features/Policies (client
  `UpdateUserData` access); Player Data/UserData permissions; Automation > Cloud
  Script (deployed revision and registered handlers); any Azure Functions and
  role data access.
- Secure target: no client-writable role authority. Use server-only InternalData
  or role store; ReadOnlyData only for display. Every privileged handler derives
  caller identity server-side and checks role. Never trust ReporterId/client role.
- Blocks Stage 1 moderator migration/actions: yes. Do not bulk-promote based on
  current writable Moderator values.

CloudScript deployment
- Known: checked-in `revisions/SCREECHVR_PLAYFAB_REVISION_V08_2026-10-29.js`
  says DRAFT - NOT DEPLOYED. It contains client-supplied ReportPlayer identity,
  ServerGrantCurrency without role auth, and OnPurchaseItem using client Price.
- Unverified: whether another revision/function is live and callable; PlayStream
  event rules.
- Inspect: Automation > Cloud Script > revisions/deployments/registered
  functions; Azure Functions registrations/auth; PlayStream > Rules/event
  triggers; Title API Policies for ExecuteCloudScript/function access.
- Secure target: inventory every deployed handler and caller; server-check caller,
  validate inputs, idempotency, audit; staged revision and rollback plan.
- Blocks Stage 1 backend changes: yes.

Currency APIs
- Known: Unity has multiple direct client `AddUserVirtualCurrency` callers via
  `Oculus_Login.AddCurrency` (ore, daily reward, Meta IAP/ATM, bundle); V08
  `ServerGrantCurrency` has no role check. Source proves calls, not live policy.
- Unverified: client API restrictions, currency/catalog settings, other live
  grants, deployed server enforcement.
- Inspect: Game Manager > Title Settings > API Features/Policies for Client
  `AddUserVirtualCurrency`/economy access; Economy > Currencies; CloudScript/
  Functions deployment and access policy.
- Secure target: migrate legitimate rewards first; backend derives player and
  eligibility, bounds amount, unique request/idempotency key, server grant and
  audit. Restrict direct client grants only after staged compatibility tests.
- Blocks Stage 1 economy migration: yes.

Purchases and validation
- Known: PlayFab client `PurchaseItem` is used for catalog cosmetics/bundles;
  its Legacy API checks submitted expected price against catalog/store price.
  V08 custom OnPurchaseItem does not call that API and accepts `args.Price`.
  Meta IAP callbacks grant in Unity without source-found server verification;
  `OWNED_IAP` is ordinary client UserData.
- Unverified: deployed handlers, catalog/store/currency configuration, Meta
  product/SKU mappings and any external receipt-validation service.
- Inspect: Economy > Catalog/Stores/Virtual Currencies and purchase rules; Meta
  IAP setup separately. In PlayFab inspect deployed receipt-validation callers
  and API policies.
- Secure target: PlayFab catalog price on server; Meta S2S entitlement check,
  server SKU/reward map, durable idempotency ledger, consumable consumed after
  fulfillment, durable restore idempotently. Preserve every SKU/item/entitlement.
- Blocks Stage 1 purchase migration: yes; do not disable current paths first.

2. PHOTON

- Known: Unity obtains PlayFab Photon token and passes PlayFab ID as username,
  token as Photon `token`; this is distinct from PlayFab SessionTicket.
  `PhotonVRManager` falls back after 20 seconds by clearing AuthValues and
  connecting unauthenticated. No dashboard read was performed.
- Unverified: Custom Server provider/URL, anonymous-client admission, failure
  policy, Realtime/Voice app ID mapping, current PUN/Voice versions, reconnect
  behavior and any targeted disconnect capability.
- Inspect: Photon Dashboard > Realtime App > Manage/Authentication (Custom
  Server URL/provider, “Allow anonymous clients…” and failure behavior); confirm
  PlayFab Photon add-on association and app ID. Inspect Voice app/auth separately.
  In Unity project settings/package list, record the configured app IDs and PUN/
  Voice versions without publishing full IDs.
- Secure target: supported PlayFab custom auth, anonymous clients disabled,
  auth failure never downgraded; Unity retries without anonymous fallback.
  Restriction enforcement needs a staging-proven Worker adapter that validates
  Photon’s token contract and checks D1. Never send a Photon token to
  AuthenticateSessionTicket. Exact Worker-to-PlayFab proxy request/response
  contract is unverified and must not be guessed.
- Blocks Stage 1 auth/rejoin enforcement: yes. Capture settings first; staging
  proof of provider contract and Voice/reconnect required before release.

3. META

User Verification
- Known: current client reads Meta user ID and uses it as PlayFab Custom ID;
  no server-side proof validation in inspected flow. V15 docs describe one-use
  GetUserProof nonce verified by trusted server-to-server call.
- Unverified: app eligibility, User ID DUC permission, API credentials access,
  Unity Platform SDK method availability/build compatibility with Unity 2021.3.32f1,
  account-link migration choice.
- Inspect: Meta Developer Dashboard > app > Requirements/Data Use Checkup (User
  ID permission/status); API/app settings and product/platform eligibility. Do
  not copy app secret into report or client.
- Secure target: backend validates proof nonce/user ID via Meta S2S, replay-safe,
  binds verified identity to existing PlayFab account. Proof does not attest
  hardware and does not replace entitlement check.
- Blocks: blocks using Meta proof as Stage 1 identity factor; does not block
  staging other auth tests if the fallback is not represented as verified.

App Attestation
- Known: no source implementation found; V22 makes it optional.
- Unverified: app/product eligibility, signing/package setup, SDK/API/build
  support and server verification access.
- Inspect: Meta Developer Dashboard > app integrity/attestation features and
  Unity Platform SDK package/API reference.
- Secure target: optional integrity signal, backend-verifiable fresh challenge;
  service outage = unknown, never automatic ban.
- Blocks Stage 1: no, unless owner explicitly makes it a release requirement.

4. CLOUDFLARE

- Known: local Worker has `/redeem`, `/motd`, Photon webhook, Discord interaction,
  export/setup/health routes; `/updateplayers` is a no-op. `/redeem` validates
  PlayFab tickets for linking only. No D1 binding, heartbeat or incident routes
  found in reviewed Worker. Secrets are environment-bound in source conventions;
  actual deployed values were not read.
- Unverified: deployed Worker/version, routes/hostnames, bindings, secret names
  and rotation status, account plan and aggregate requests/rows, D1 existence,
  quota headroom. Query-string keys are present in some routes in source.
- Inspect: Cloudflare Dashboard > Workers & Pages > Worker > Deployments, Routes,
  Settings/Bindings (names only); Workers & Pages > D1 databases/bindings; account
  plan and Analytics/Metrics > Workers and D1 row metrics. Inspect secrets without
  revealing or copying values. Verify domains/route consumers.
- Secure target: server secrets only in Worker secret bindings, never Unity/source;
  avoid URL secrets; D1-backed incidents/restrictions/audit with conditional
  atomic updates; no KV writes per heartbeat; per-route auth and redacted logs.
- Capacity: V19 model at 100 players/5-minute heartbeat is 28,800 Worker requests
  and about 28,800 D1 row updates/day before other traffic. Free quotas are shared;
  measure current account headroom. €0 recurring is plausible, not guaranteed.
- Blocks Stage 1 incident/rejoin enforcement: yes, until deployed bindings,
  capacity and exact Photon adapter are validated in staging.

5. DISCORD

- Known: shared records name `admin-logs` as current admin log channel. Prior
  audit (2026-10-20/21) noted `#mod-logs` Staff-view/send and `#audit-logs`
  staff-view-only with a Dyno webhook; status may be stale. No verified private
  Voideration alert destination or delivery test.
- Unverified: current channel existence/effective permissions, bot/webhook path,
  secret owner, who can view incident evidence, rate/alert behavior.
- Inspect: Discord channel/category permission overwrites for @everyone, member,
  staff and bot roles; channel View/Send/History/Embed permissions; Integrations
  > Webhooks (names/owner/destination, never reveal URL/token); bot role/channel
  permissions. Check moderation/AutoMod alert destinations only if reused.
- Secure target: dedicated owner/staff-only channel; narrow bot identity with
  send/view/history/embed only; webhook/bot credentials server-side; redacted,
  deduplicated alerts after incident persistence. Confirm access with effective
  permissions and a staging test.
- Blocks Stage 1 alert delivery: yes until private destination and posting
  mechanism are verified. Do not create/change it during preflight.

6. VOIDERATION OWNER REVIEW / LOCAL DASHBOARD

- Known: no dashboard, incident store, owner approval API, restriction store or
  D1 implementation found. V22 is a design only. Existing Worker Discord
  interactions have signature validation and OWNER_ID checks for commands.
- Unverified: owner identity binding, local host/device, authentication and
  recovery, browser security, review SLA, expiry/appeal/retention policy.
- Inspect/decide: owner-controlled account/identity source; machine/OS where
  dashboard will run; loopback bind/firewall; secret storage. No cloud dashboard
  settings exist to verify today.
- Secure target: dashboard binds 127.0.0.1 only; owner-authenticated, CSRF-safe
  actions call Worker APIs, never direct browser-to-D1; server verifies owner on
  every transition. Every attempt/action audited. Incident review state is
  separate from player restriction; only owner clears/restricts/bans.
- Blocks Stage 1 incident/review deployment: yes. Decide account method, review
  policy, evidence access/retention and restriction expiry before implementation.

STAGE 1 ENTRY: DECISIONS / APPROVALS REQUIRED FROM OWNER

1. Approve the V22 architecture for staging only; production remains unchanged.
2. Authorize read-only inspection of the listed PlayFab, Photon, Meta, Cloudflare
   and Discord dashboard settings; provide access through the relevant dashboard,
   never by sending secrets in chat. Approve redacted settings inventory.
3. Choose whether Meta User Verification is mandatory, optional, or deferred;
   approve identity migration/linking policy that preserves current PlayFab IDs.
4. Approve a staging Photon Realtime/Voice app and test accounts. Decide whether
   to investigate the Worker custom-auth proxy contract; no adapter implementation
   until the official wire contract is proven.
5. Approve disabling the anonymous fallback only after staging confirms normal
   login, room join, reconnect, server switch and Voice; production change requires
   separate explicit approval.
6. Approve secure migration of Moderator roles, currency grants, PlayFab purchases
   and Meta IAP; confirm product/entitlement preservation and staging test scope.
7. Decide incident severity/rules that may trigger temporary rejoin restriction;
   approve PendingReview/Approved/Rejected semantics, confirmed restriction,
   expiry/release, separate ban authority, appeals and review SLA. Weak movement,
   latency or tracking signals do not auto-restrict or auto-ban.
8. Approve private Discord alert channel/identity after reviewing its effective
   permissions. Approve local dashboard device, owner auth, recovery and retention.
9. Confirm €0 additional recurring target is a constraint, and authorize checking
   aggregate Cloudflare Workers/D1 quotas; acknowledge a paid tier or authoritative
   game server may be needed if quotas/security requirements exceed Free/PUN.
10. Approve Stage 1 scope and release gates; implementation and any production
    deployment/settings change require separate explicit approval.

No secret values requested or exposed. No dashboard setting was changed or
verified in this preflight. V22 remains a proposed baseline.

END OF REPORT