[auth 9] Complete Store-ready account lifecycle and validation

[artiphishle]

Roadmap: #188

Respect the [auth] roadmap first and the AGENTS.md file of every repository touched.

Previous roadmap step

[auth 8] (#196) adds optional native Google and Apple transports behind the same adapter-neutral Auth/account architecture. This final roadmap issue turns the complete account lifecycle, deployment configuration and validation matrix into Store-ready product behavior.

Repository impact

Likely:

• ankhorage/contracts
• ankhorage/studio
• ankhorage/supabase-auth
• ankhorage/infra
• ankhorage/ankh
• ankhorage/expo-runtime / native module packages
• generated Web deployment/template ownership for external account-deletion resources

Store policies evolve. Implementation must re-check current official Apple and Google requirements before final acceptance and update tests/Doctor rules rather than relying only on this issue's snapshot.

Goal

Provide a complete, capability-driven account lifecycle and actionable Store-readiness validation for generated Web, iOS and Android apps.

This issue is not merely a checklist. Required account actions and external resources must be generated, wired to the neutral Auth adapter and validated per enabled target/environment.

Current policy baseline to verify during implementation

As of roadmap creation:

• Apple requires apps that support account creation to let users initiate account deletion within the app and remove associated data not legally required to be retained.
• Google Play requires apps that allow account creation to provide a discoverable in-app deletion path and an external Web resource where account/data deletion can be requested.
• Apple App Review Guideline 4.8 requires an equivalent privacy-preserving login option when a third-party/social login authenticates the user's primary account, unless an exception applies. Sign in with Apple is the expected default solution in many ordinary consumer-app configurations, but readiness validation should model the actual guideline/capabilities rather than a brittle provider-name rule.

Official references:

• https://developer.apple.com/app-store/review/guidelines/
• https://developer.apple.com/support/offering-account-deletion-in-your-app/
• https://support.google.com/googleplay/android-developer/answer/13327111

Requirements

Account deletion

Provide a neutral deletion lifecycle, including:

• capability check;
• recent-auth/re-authentication requirement where applicable;
• explicit destructive confirmation;
• clear explanation of deleted data and documented retained-data exceptions;
• deletion of Auth identity and configured app-owned associated data;
• deletion/cleanup across configured provider/service boundaries where owned;
• deterministic success/pending/failure results;
• post-deletion local session/cache cleanup;
• no silent fallback to mere deactivation.

Generated profile/account UI from [auth 7] must expose the in-app path when account creation is enabled and the adapter supports deletion.

External deletion resource

Generate/configure a stable Web deletion-request resource suitable for Store metadata:

• publicly reachable without requiring the mobile app to remain installed;
• clearly identifies the app/developer;
• allows the user to request deletion or complete the supported secure flow;
• supports authentication/identity verification without exposing administrative credentials;
• explains expected timing and retention exceptions;
• has a stable production URL surfaced for Play Console/Store configuration;
• is not a fake informational page with no deletion-request path.

The resource may be generated as part of the app's Web deployment or a reusable hosted account service, but ownership and multi-app isolation must be explicit.

Social credential revocation and unlinking

Provide capability-driven behavior for:

• revoking/disconnecting social provider access where required/supported;
• unlinking an identity without orphaning the account or removing the last viable login accidentally;
• linking another identity where supported;
• clear distinction between revoking provider access, signing out, unlinking and deleting the app account;
• no raw provider token persistence beyond what the backend adapter requires.

Re-authentication and sensitive actions

Model recent-auth requirements for:

• change password;
• change primary email/identifier;
• delete account;
• unlink final/critical identity;
• other adapter-declared sensitive operations.

The UI/runtime must handle challenge-required outcomes generically rather than hardcoding Supabase error strings.

Apple login policy readiness

For iOS targets with third-party/social primary-account login:

• evaluate whether an equivalent login option is configured or a documented exception applies;
• surface a blocking Doctor/Store-readiness diagnostic when required capability is missing;
• validate Sign in with Apple entitlement/identifier/key configuration when selected;
• preserve equivalent prominence/usability in generated sign-in UI;
• handle private relay email and first-login profile semantics from [auth 6]/[auth 8].

Do not assume every enterprise/education/client app requires Apple login; model explicit exception evidence/configuration where valid and require review notes/documentation.

Build/signing/provider readiness

Validate by target/environment:

• stable iOS bundle identifier;
• stable Android application ID;
• app schemes/deep links/universal/app links where required;
• Google Android signing fingerprints for debug/preview/production/Play App Signing as applicable;
• Apple capabilities/entitlements;
• provider callback allowlists;
• production domains and HTTPS requirements;
• OAuth consent/branding readiness fields where Ankhorage can validate them;
• development credentials are not accidentally used for production.

Store/privacy artifacts

Generate or validate the inputs needed for:

• Apple review notes/demo-access instructions for account-based apps;
• Google Play Data safety account-deletion URL;
• privacy-policy and data-retention/deletion disclosures;
• supported login/deletion behavior descriptions;
• explicit unsupported/manual responsibilities that cannot be automated.

Ankhorage must not claim Store approval. It should provide deterministic technical/policy-readiness diagnostics and clearly identify remaining human/vendor-console steps.

Test matrix

Define one canonical release-readiness matrix across:

Web local / preview / production
iOS development / preview / production
Android debug / preview / production / Play signing

Auth methods:
  email/password where enabled
  brokered Google
  brokered/native Apple where enabled
  optional native Google

Lifecycle:
  sign up/sign in
  refresh/restart
  sign out
  change profile
  change email/password
  link/unlink/revoke
  delete account
  external deletion request

Automate controlled/fake backend/provider paths in CI and require explicit real-console/device verification steps for behavior that cannot be safely automated.

Likely files

Contracts/Supabase Auth, non-exhaustive:

src/auth.ts
src/accountLifecycle*.ts
src/createSupabaseAuthAdapter.ts
src/*delete* tests

Studio/Generator:

src/host/layout/templates/auth/*
src/ui/admin/pages/AuthAdminPage.tsx
src/ui/admin/pages/*Readiness*.tsx
src/host/*deletion* or deployment templates

Ankh/Infra/Expo Runtime paths must be identified from current Doctor, deployment, native signing and Web resource ownership.

Phases

Phase 1 — deletion/re-auth/revocation contracts and adapter implementation

Complete neutral lifecycle results/capabilities and implement Supabase behavior with associated-data ownership.

Phase 2 — generated in-app and external deletion UX

Wire profile/account UI and deploy a stable secure Web deletion-request path.

Phase 3 — Store policy/readiness rules

Implement current official Apple/Google checks, exception configuration and actionable diagnostics.

Phase 4 — signing/deployment/provider validation

Validate target/environment callbacks, identifiers, entitlements, fingerprints and production isolation.

Phase 5 — complete release test matrix and documentation

Add automated coverage, required real-device/provider-console checks and generated submission guidance.

Tests

Cover at minimum:

• account deletion capability and re-auth challenge;
• deletion removes Auth identity plus configured associated data according to policy;
• retained-data exception is explicit and reported;
• local session/profile caches clear after deletion;
• deletion failure/pending states remain recoverable;
• external deletion resource is resolvable and can submit a verified request;
• unlink cannot remove the last viable login without an explicit safe transition;
• revoke/sign-out/unlink/delete semantics remain distinct;
• iOS social-login readiness detects missing equivalent login option and configured exceptions;
• Apple entitlement/provider readiness;
• Google Play in-app plus external deletion readiness;
• debug/preview/production signing/callback isolation;
• Doctor never exposes secrets;
• fake second Auth adapter can implement lifecycle capabilities without Supabase types;
• generated Store guidance distinguishes automated readiness from manual console/review work.

Acceptance criteria

1. Account creation implies a generated, discoverable in-app deletion path where required.
2. A stable external deletion-request resource is available/configurable for Google Play and users without the app.
3. Deletion removes the account and associated data according to explicit ownership/retention rules; deactivation alone is not treated as deletion.
4. Re-authentication, revocation, linking and unlinking are capability-driven and safe.
5. iOS third-party-login readiness checks current equivalent-login requirements/exceptions and Apple configuration.
6. Signing identifiers, fingerprints, callbacks, entitlements and environments are validated.
7. Store/privacy metadata inputs and remaining manual steps are surfaced accurately.
8. A complete Web/iOS/Android account lifecycle matrix exists.
9. Ankhorage reports readiness without claiming guaranteed Store approval.
10. Official policy references are re-verified at implementation/release time.
11. Behavior-focused tests, package releases/changesets and full validation pass.
12. [auth 1] through [auth 9] together satisfy the roadmap Definition of Done.