Open questions

Genuinely undecided items. If you are about to assume an answer, stop and write an ADR instead of guessing.

The long-form list in spec §29 is filtered here: items closed by spec §33 or ADRs 0011-0032 are in the resolved section at the bottom.

Production hardening (not a product pick)

1. Production IAM lock-in still waits on the remaining spec §23.2 proofs. Local/dev is ZITADEL (ADR 0021). Keycloak remains the fallback if those proofs fail. Do not pick a third vendor without a new ADR.

   Already demonstrated in this POC:

   • Passkey-only Account create without player email (ADR 0024).
   • Social start requests openid only; Nest keeps iss + sub and drops IdP rawInformation (ADR 0012).
   • Linking is an explicit intent, not email match (ADR 0017, 0019).
   • Player and staff portals are URL-isolated (ADR 0018). Staff still uses MACHINE_API_KEY, not workforce SSO.
   • Players can revoke portal sessions.

   Still required before production IAM lock-in:

   • Live capture that Google + ZITADEL do not leave email/name/phone in PlayerPal cookies, DB, API logs, or traces (code filtering is in place; the live hop is not).
   • Enterprise admin SAML/OIDC.
   • Machine clients using private_key_jwt (POC ingest still uses MACHINE_API_KEY).
   • Export/migration of authentication mappings.
   • IAM key rotation.

Resolved. Do not re-open without an ADR

• Keycloak vs ZITADEL for local POC → ADR 0021 (ZITADEL + NestJS control plane)
• Partner aliases are pp_plr_... → ADR 0013
• No extra operator×provider scope → ADR 0014
• JWT at operator login for the widget → ADR 0015, ADR 0016
• Token lifetime unknown → machine tokens 5-15 minutes; player BFF cookies; no widget refresh tokens (ADR 0016)
• Richer profile may use email → ADR 0012
• Link UX / consent surface → ADR 0017
• Sign in as existing account → ADR 0019
• Points before registration / retrospective claim → spec §33: no shadow profiles, no historical points by default (ADR 0009)
• Never store vs never receive email → never receive or store (ADR 0012)
• PostgreSQL-first then Redpanda → ADR 0005
• Batch orchestrator → Dagster initially (spec §35.1)
• Random pairwise vs HMAC / Base32(UUID) → ADR 0002
• Portal role picker → ADR 0018
• Custom / branded portal login UI path → Login V2 fork available (ADR 0022); Nest owns player password/passkey + social for the local portal (ADR 0024)
• Whether PlayerPal ID + password is offered → yes on player signup, provisional A0, pre-minted pp_plr_... as IAM loginname (ADR 0020, ADR 0024)
• Nest data access / DDL ownership → TypeORM (ADR 0023)
• Permitted cross-operator analytics (item 6) → partners get cohort and per-alias numeric enrichment; they never get another Audience’s identifier. Legal joint-controller contracts remain a product-permission assumption, not an identifier rule (ADR 0026)
• Retention after Unlink or Delete Account (item 7) → Unlink revokes one Audience (spec §36.6); Delete Account erases the identity graph and retains gameplay facts without identity keys (ADR 0026)
• Google claim behaviour in PlayerPal-controlled systems (item 2) → openid only; Nest persists iss + sub; IdP rawInformation is dropped before return (ADR 0012). Live hop capture remains under production hardening above.
• Recovery beyond recovery codes (item 3) → codes, extra passkeys, linked social, remaining-device session revoke. Operator-assisted recovery is out of v1 (ADR 0028).
• Eager vs on-demand provider aliases (item 4) → mint listed integrations at link complete; later integrations via resolve; never on ingest (ADR 0027).
• Which providers get a provider-global alias exception (item 5) → none. Exceptions need a new ADR plus a named contract (ADR 0014).
• Authorization implementation (item 8) → application-native Nest checks until a second service shares the same permissions (ADR 0029).
• Redpanda date (item 9) → no date. Phase 2 starts when a spec §35.4 condition is measured (ADR 0005).
• How Bucks learns PlayerPal Unlink → async notice plus rare alias reconcile; Unlink does not wait (ADR 0032).