Sauci/docs/product/catalog-content-safety-plan.md

# Universal catalogue safety and store compliance implementation plan

Status: product direction confirmed for one universal iOS/Android catalogue.
The additive review metadata and conservative archive classification are live.
The legacy-client cutover uses RLS, guarded RPCs, write rejection, match hiding,
and pack-setting enforcement so installed iOS and Android clients receive the
same explicitly allowed catalogue without a platform-specific fork.

## 1. Outcome and non-negotiable invariants

Sauci keeps its core compatibility mechanic: each partner privately answers the
same preference or boundary prompt and Sauci reveals agreement. The production
catalogue on both iOS and Android must not supply explicit sexual acts, sexual
instructions, fetish content, or other developer-authored material intended for
sexual gratification.

The eligible catalogue is global, not platform-specific. Both members of a
couple must always be able to retrieve the same source question regardless of
which supported device they use. Platform, app version, premium state, intensity
preferences, or which partner answered first cannot make an archived question
visible.

The implementation is complete only when all of these are true:

1. All production clients can receive only content explicitly reviewed as allowed.
2. `unreviewed` is treated exactly like `archived` everywhere.
3. A pack, its category, and the individual question must all be allowed before
   the question can be returned.
4. `is_explicit`, intensity, premium access, and `hide_nsfw` remain product
   controls; none of them can override the catalogue safety boundary.
5. Old and unknown clients receive the same reviewed catalogue as current clients.
6. Filtering applies to catalogue browsing, swipe selection, direct links,
   pending questions, answers, matches, chat headers, progress, search, counts,
   realtime payloads, notification destinations, and write endpoints.
7. Historical responses and matches are retained. They are not disclosed in any
   customer response when their source content is archived.
8. New developer-authored content defaults to `unreviewed` and cannot reach the
   production catalogue until a recorded review allows it.
9. Cross-platform couples receive identical global content eligibility, pending
   state, match visibility, progress counts, and notification destinations.
10. Couple isolation, premium rules, role checks, and RLS remain enforced.

This is a catalogue policy, not an age gate. An 18+ confirmation or content
toggle does not make otherwise prohibited developer-authored content eligible.

## 2. Content model

### 2.1 Classification used by engineering

Each category, question pack, question, dare pack, and dare has one production
review status:

| Status | Production behaviour | Meaning |
|---|---|---|
| `unreviewed` | hidden and non-actionable | no affirmative decision exists |
| `allowed` | eligible, subject to parent visibility and access rules | manually reviewed against the Play policy |
| `archived` | hidden and non-actionable | explicit, sexual-gratification, fetish, instructional, or otherwise unsuitable |

An allowed question should describe a non-graphic preference, relationship
dynamic, comfort level, romantic interest, or boundary. It must not name or
instruct a sexual act, explicit anatomy, sex toy use, nudity as stimulation,
public sexual activity, or coercive/predatory scenario.

Examples of the intended retained mechanic:

- "Take the lead more often with your partner."
- "Let your partner surprise you with a private date idea."
- "Explore a new dynamic with your partner."
- "Share a fantasy in your own words."

The last example lets the users supply the final detail. The app must present it
as private couple communication, not solicit a named sexual act or provide an
explicit example. User-authored fields still need reporting/blocking, terms,
rate limits, and safe notification previews.

### 2.2 Initial catalogue decision

The first production review is ID-based, not keyword-based. Keyword scans can
queue content for review but must never auto-allow it.

Immediately block the exact questions shown in the rejection evidence and all
developer-authored explicit acts/instructions. Use a conservative first pass:

- Block whole packs pending line review: All Eyes On Us, Boundary Discovery,
  Dare to Play, Deep in Character, Dream Scenarios, Fantasy Scenarios, Intimate
  Games, Kink Discovery, Know Your Limits, Leveling Up Together, Pleasure
  Experiments, Position Exploration, Private Line, Pushing Limits, Role Play
  Ideas, Secret Desires, Sensory Play, Sensual Touch, Starting Out, Tease &
  Tension, The Deep End, and Total Control.
- Line-review the apparently safer relationship packs before allowing them;
  benign pack names do not prove every contained question is safe.
- Archive the mixed packs Missing You, Testing the Waters, Romantic Gestures,
  First Impressions, Body Mapping, Love Notes, Sensual Massage, and Date Night Sparks
  pending rewrite. A 2026-08-27 production audit found direct references to
  sex, sexual positions, nudity, striptease, underwear, lap dances, erotic
  touching, or strongly sexual scenarios in all eight.
- Line-review every apparently safer relationship pack before allowing it;
  benign pack names and low intensity values do not prove every
  contained question is safe.
- Treat every dare and dare pack as `unreviewed` until the dare feature is
  separately reviewed. The current coming-soon copy must also be rewritten
  to neutral relationship language.

Do not delete historical records in place. Classification removes archived source
content from both apps while preserving subscriptions, IDs, responses, matches,
messages, and the ability to audit or later rewrite content.

### 2.3 Implemented preparation checkpoint

Migration `20260827215907_add_catalog_content_review_metadata.sql` adds the
reversible `unreviewed`/`allowed`/`archived` metadata, append-only decision
history, edit-invalidates-review triggers, and the ID-based 30-pack conservative
archive set. It deliberately does **not** filter RLS, RPCs, API queries, or either mobile
app. Existing clients therefore continue to see the same catalogue until the
later universal enforcement phase is explicitly deployed and verified.

The admin content screens expose the metadata and permit review decisions only
to super-admins. Existing explicit/crude generator settings remain accepted as
legacy inputs for compatibility, but no longer relax the universal prompt safety
ceiling. Newly created database content still defaults to `unreviewed`.

This checkpoint is reversible metadata preparation, not Play remediation. The
remaining phases below are required before archived content is hidden from any
customer.

## 3. Database changes

Create one canonical Supabase migration with:

```sh
npm run db:migration:new -- add_catalog_content_policy
```

The migration lives only in `apps/supabase/migrations/`. The untracked Drizzle
work under `apps/api/drizzle/` must not become an independent schema authority;
update `apps/api/src/db/schema.ts` to mirror the canonical schema after the
Supabase migration exists.

There is a repository-level sequencing conflict to resolve in the implementation
PR: the root `AGENTS.md` makes Supabase migrations canonical, while the current
uncommitted `docs/architecture/backend-migration.md` describes API-owned
standalone PostgreSQL migrations. This plan follows the root instruction. Update
the architecture decision before changing that ownership rule; do not quietly
create the compliance schema twice with divergent migrations.

The compliance fields must exist in whichever database is authoritative at the
time of release. If the standalone-backend migration has not cut over, enforce
them in production Supabase first and carry the values through the controlled
data migration. If the standalone backend cuts over first, import and verify the
same statuses there and leave legacy Supabase fail-closed/read-only. Never let
old clients write Supabase while new clients write a standalone database; that
would split responses and matches between two sources of truth.

### 3.1 Types and columns

Add:

```sql
create type content_review_status as enum
  ('unreviewed', 'allowed', 'archived');

alter table categories add column content_status
  content_review_status not null default 'unreviewed';
alter table question_packs add column content_status
  content_review_status not null default 'unreviewed';
alter table questions add column content_status
  content_review_status not null default 'unreviewed';
alter table dare_packs add column content_status
  content_review_status not null default 'unreviewed';
alter table dares add column content_status
  content_review_status not null default 'unreviewed';
```

Add the same review metadata to all five tables:

- `content_review_reason text`
- `content_reviewed_at timestamptz`
- `content_reviewed_by uuid references auth.users(id) on delete set null`

Add `catalog_policy_revision integer not null default 1` and
`catalog_emergency_disabled boolean not null default false` to the singleton
`app_config`. Increment the revision whenever classifications or eligibility
rules change. The emergency switch disables catalogue reads and writes for all
clients; it does not expose an alternate catalogue.

Add indexes used by all disclosure paths:

```sql
create index categories_content_catalog_idx
  on categories (content_status, is_public, sort_order);
create index question_packs_content_catalog_idx
  on question_packs (content_status, is_public, category_id, sort_order);
create index questions_content_catalog_idx
  on questions (pack_id, content_status, intensity)
  where deleted_at is null;
create index dare_packs_content_catalog_idx
  on dare_packs (content_status, is_public, category_id, sort_order);
create index dares_content_catalog_idx
  on dares (pack_id, content_status, intensity);
```

### 3.2 Durable review audit

Add an append-only `content_reviews` table:

- `id uuid primary key default gen_random_uuid()`
- `entity_type text` checked to the five supported table types
- `entity_id uuid not null`
- `previous_status content_review_status not null`
- `new_status content_review_status not null`
- `reason text not null`
- `reviewed_by uuid references auth.users(id) on delete set null`
- `created_at timestamptz not null default now()`

Only super admins can read it. Clients cannot insert, update, or delete it.
Use database triggers on the five content tables to:

- reject a status change without a non-blank reason;
- set `reviewed_at` and `reviewed_by` from database time and `auth.uid()`;
- append the old/new decision to `content_reviews`;
- increment `app_config.catalog_policy_revision` after a real status change.

This replaces reliance on the admin's current best-effort, client-side audit
call for compliance decisions. Existing `audit_logs` remain useful for normal
CRUD history.

### 3.3 Eligibility helpers

Add stable SQL helpers used consistently by RPCs and tests:

- `is_category_content_allowed(category_id uuid)`
- `is_pack_content_allowed(pack_id uuid)`
- `is_question_content_allowed(question_id uuid)`
- dare equivalents

A question is eligible only when it is active, its own status is `allowed`, its
pack is public and `allowed`, and its optional category is public and `allowed`.
Premium and couple-pack rules are applied in addition to this predicate. When
`catalog_emergency_disabled` is true, every customer eligibility helper returns
false; privileged admin review remains available.

Recommendation order can still vary by a user's intensity preference, gender
targeting, answer history, and which inverse wording applies. Once either partner
answers an allowed question, however, the other partner must be able to retrieve
the corresponding pending question even when it would not have appeared in
their ordinary recommendation queue. No user preference may orphan that pending
interaction.

### 3.4 Legacy-client fail-closed boundary

Old builds query the public Supabase tables and RPCs directly. Change
public/authenticated SELECT policies so non-admin direct access exposes only
globally allowed rows. Preserve the existing admin policy as a separate
permissive policy.

Specifically drop every overlapping non-admin visibility policy (including the
current public-pack and premium-pack policies) and replace the broad policies
for `categories`, `question_packs`, `questions`, `dare_packs`, and `dares`. The
question policy must include
`deleted_at is null`, question status, parent pack status/public access, category
status/public access, premium access, and existing gender rules where relevant.

Recreate every SECURITY DEFINER content RPC with the same fail-closed predicate,
including at minimum:

- `get_recommended_questions`
- `get_answer_gap_status`
- `get_daily_response_limit_status` if its counts are presented as catalogue progress
- pack statistics/progress functions
- dare catalogue and statistics functions

`get_recommended_questions(target_pack_id)` must reject an archived/unreviewed
target pack rather than trusting the supplied UUID. It must also filter
the individual question and exclude soft-deleted questions.

This makes legacy iOS and Android builds consistent immediately. Neither app has
a broader fallback catalogue, so a partner cannot create a pending question or
match that the other partner's platform is forbidden to retrieve.

### 3.5 Write enforcement

Reads alone are insufficient. A user who retained an old question UUID must not
be able to submit or change a response to it from any client.

Move submission/update into the API and enforce content eligibility before
writing. During the legacy window, update `submit-response` and
`update-response` edge functions to apply the same universal check. Archived IDs
return `404 content_not_available` without text or policy details.

The same rule applies to:

- enabling a pack in `couple_packs`;
- creating a sent dare from a developer-authored dare;
- retrieving or mutating a historical response;
- opening a match/chat tied to archived developer content.

Keep existing rows. Do not cascade-delete responses, matches, messages, or media.

### 3.6 Device records for notification safety

Replace the single `profiles.push_token` as the long-term delivery model with
`user_devices`:

- `id uuid primary key`
- `user_id uuid not null references profiles(id) on delete cascade`
- `expo_push_token text not null unique`
- `platform text` checked to `ios` or `android`
- `app_version text`, `build_number integer`
- `catalog_policy_revision integer not null`
- `last_seen_at`, `created_at`, `updated_at`
- `disabled_at timestamptz`

RLS permits a user to manage only their own device rows. Backend workers read
them privately. Every device gets the same eligible counts and destinations.
Keep `profiles.push_token` during one release as a compatibility fallback, then stop
writing it and remove it in a later migration after delivery metrics confirm the
cutover.

## 4. API changes

The new API is the only long-term product-data boundary. The current pack-domain
work is incomplete and not registered by `apps/api/src/app.ts`; extend that work
rather than creating another parallel path.

### 4.1 Request context and catalogue revision

Update `apps/mobile/src/lib/apiClient.ts` to send:

- `X-Sauci-Platform: ios|android` for diagnostics and release support only
- `X-Sauci-App-Version`
- `X-Sauci-Build-Number`
- `X-Sauci-Catalog-Policy-Revision`

Use Expo Constants and `Platform.OS`, not environment-specific user choices.
Add typed API middleware/request context in `apps/api/src/app.ts` that parses the
version headers once. Platform metadata must never alter content eligibility.
Include the current policy revision in every catalogue response.

### 4.2 Required API surface

Implement and register authenticated routes for every product-content path:

| Route | Required behaviour |
|---|---|
| `GET /v1/catalog` | eligible categories and packs; question counts count only eligible questions |
| `GET /v1/packs/:id` | eligible metadata and preview questions; archived IDs return 404 |
| `GET /v1/me/enabled-packs` | omit archived pack IDs without deleting couple settings |
| `PUT /v1/me/enabled-packs/:id` | reject an ineligible pack |
| `GET /v1/me/pack-progress` | denominator and answered count use only eligible questions |
| `GET /v1/questions/recommended` | preserve partner/gender/intensity/premium logic plus policy filter |
| `GET /v1/questions/pending` | filter both partner response and joined question |
| `POST /v1/responses` | validate eligibility in the same transaction as the write/match calculation |
| `PATCH /v1/responses/:id` | validate ownership and current eligibility |
| `GET /v1/me/responses` | omit archived history and its question/pack text |
| `GET /v1/matches` | omit archived matches and exclude them from badges/counts |
| `GET /v1/matches/:id` | archived IDs return 404 before returning question, summary, messages, or media URLs |
| dare routes | same parent/item/read/write enforcement; do not expose until reviewed |
| `PUT/DELETE /v1/me/devices/:token` | register/disable device metadata |

All customer-facing repository queries use one centralized eligibility
predicate. Do not accept a boolean such as `showAdult`, a platform argument, or
a hidden full-catalogue option. Separate privileged admin repositories may read
all statuses after role checks. Customer repository tests must fail if the
eligibility predicate is omitted.

Do not return hidden text in error bodies, logs, analytics, or tracing tags.

### 4.3 Transaction and isolation rules

- Derive `user_id` from the verified JWT, never request JSON.
- Derive `couple_id` from the authenticated profile.
- On submission, lock/read the eligible question and existing responses inside
  one transaction, then upsert the response and match.
- Every match/message query checks the authenticated user's current couple.
- Pack toggles use the authenticated couple and an eligible pack in one query.
- Preserve current premium, answer-gap, daily-limit, gender-targeting, inverse,
  and question-type behaviour while adding the content predicate.

## 5. Mobile changes

### 5.1 Remove content reads from `legacyDataClient`

Migrate these exact surfaces to typed API methods:

- `src/store/packsStore.ts`: catalogue, enabled packs, toggles, progress.
- `src/features/swipe/services/swipeService.ts`: pack context, recommended and
  pending questions, status checks, and response submission.
- `app/pack/[id].tsx`: pack/question preview and direct-link handling.
- `src/store/matchStore.ts`: all match, pending, their-turn, response, and nudge
  context queries.
- `src/store/responsesStore.ts`: My Answers, pagination, counts, edits.
- `src/features/chat/ChatScreen.tsx`: match/question header and initial access.
- `app/(app)/_layout.tsx`: realtime match hydration and toast copy.
- future dare stores/screens and all content search surfaces.

Auth may continue to use `authClient`. Realtime can temporarily use Supabase only
as an invalidation signal containing IDs; the app must refetch the visible DTO
from the API before rendering it. Never render embedded realtime question text.

### 5.2 Typed DTOs and safe UI states

Add shared types and Zod schemas in `packages/shared`, exported through
`src/index.ts`, for request context, catalogue, questions, responses, matches,
device registration, `content_not_available`, and policy revision.

Archived/stale deep links should navigate to a neutral screen: "This item is no
longer available in Sauci." Do not display the old title or
question. The same neutral state is used when an item becomes archived while the
app is open.

On policy revision change or app resume:

- cancel in-flight catalogue requests;
- clear packs, swipe queue, pending, matches, response-history, and chat-header
  stores;
- clear React Query content keys;
- discard any current card before refetching;
- retain only IDs needed for locally skipped questions; no question text is
  persisted.

Add a response interceptor for `404 content_not_available` and policy revision
mismatch so every screen gets the same clearing behaviour.

### 5.3 Copy and settings

- Remove the promise of explicit content from both apps' onboarding,
  settings, subscription paywalls, empty states, analytics screen names, and the
  dares coming-soon page.
- Remove `hide_nsfw` and any setting that implies archived adult content can be
  unlocked. Retain intensity only as ordering/pacing inside the allowed catalogue
  and review whether its user-facing labels also need neutral wording.
- Describe Sauci's value as private compatibility, curiosity, boundaries,
  relationship dynamics, and user-led conversation.
- Never seed an explicit example or placeholder into a free-text field.

### 5.4 Private user-authored content

If Sauci adds "write your own" prompts to preserve the final jump:

- it is a separate question type and database record, visibly labelled as
  written by the partner rather than Sauci;
- content is private to the couple and not discoverable, searchable, or reused;
- notifications say only that a partner shared a private prompt;
- provide report, delete, block-partner/leave-couple, and safety help actions;
- rate-limit creation and validate length/media type;
- do not generate, complete, recommend, categorize, or provide explicit starter
  text;
- include UGC moderation and enforcement terms before enabling it in either app.

This feature should be a later submission, not mixed into the remediation build.

## 6. Admin changes

Update Categories, Packs, Questions, Dare Packs, and Dares pages/services to add:

- catalogue status badge and reason;
- filters for unreviewed/allowed/archived and "parent archives child";
- single and bulk review actions available only to `super_admin`;
- required reason and confirmation showing affected question counts;
- a queue sorted with rejection-evidence items first;
- a read-only review history panel from `content_reviews`;
- dashboard counts and a hard warning when any public item is unreviewed;
- CSV export/import by immutable ID for offline line review, with dry-run diff;
- publish/scheduled-release validation that does not imply Play eligibility.

Review inverse question pairs together. A transaction-backed admin API/RPC must
change both sides atomically and reject mismatched pair status. Do not add a hard
constraint until the existing inverse data has been audited and repaired, since
legacy pairs may not currently be reciprocal.

Creating or materially editing text resets that item to `unreviewed`, clears its
review metadata, and increments the policy revision. Editing pack/category text
also resets that parent. Reordering, icon/color changes, and pricing changes do
not reset status unless visible copy changes.

Update `AUDITED_TABLES` to include dare tables and the new review table, while
keeping the database review-event trigger as the authoritative compliance log.

## 7. Notifications, jobs, and cached disclosure

Update all notification workers and scheduled functions:

- `send-notification`
- `send-message-notification`
- `send-match-notification-digest`
- `send-partner-activity-notification`
- `send-catchup-reminder`
- `send-weekly-summary`
- future dare notification functions

Counts for every device include only eligible source questions.
Never include question, pack, dare, response, or message text in a push preview.
A tap may carry an opaque match ID, but the target route must re-authorize and
re-evaluate eligibility. Suppress a push when its only destination would be a
archived item.

Realtime payloads are invalidations, not renderable content. Clear current
content on sign-out, relationship deletion, and policy revision. Verify
SecureStore/AsyncStorage migrations do not contain prompt text.

## 8. Migration and release sequence

### Phase A - content freeze and evidence

1. Freeze developer-authored pack/question/dare publishing.
2. Export immutable IDs, visible copy, pack/category, intensity, inverse ID,
   public/premium flags, and response/match counts from production.
3. Save the exact rejection screenshots and map every shown card to its question
   ID. Do not store subscriber answers or message content in the review file.
4. Produce an allow/block CSV reviewed by a human; unresolved rows remain
   `unreviewed`.
5. Capture before-state counts by status, pack, responses, and matches.

### Phase B - schema and API locally

1. Create the canonical migration and seed the reviewed ID decisions in the same
   migration or a separate explicit data migration. Never classify by mutable
   pack name in production SQL.
2. Update generated Supabase types and the Drizzle schema mirror.
3. Implement API request context, repositories, routes, device registration,
   and policy-aware notification queries.
4. Update edge functions and legacy RPCs for fail-closed compatibility.
5. Reset local Supabase and run SQL/RLS/function tests.

### Phase C - mobile and admin

1. Move all listed mobile content paths to the API.
2. Add revision-driven cache clearing and neutral unavailable states.
3. Build admin review queue, atomic bulk review, audit view, and release guards.
4. Rewrite sexualized marketing/UI copy consistently in both apps.
5. Complete content review; no public production item remains `unreviewed`.

### Phase D - controlled production cutover

1. Declare and record the one authoritative product database for this release.
   If the standalone migration is incomplete, do not mix its writes with live
   Supabase writes; perform the compliance cutover on the current source first.
2. Deploy the additive schema and API. Keep
   `catalog_emergency_disabled=false` unless the catalogue must be stopped
   completely during cutover.
3. Read back schema, seeded decisions, RLS definitions, status counts, and a
   sample of each endpoint. Do not expose text in deployment logs.
4. Enable the legacy RLS/RPC boundary so every old iOS and Android build receives
   only allowed content, then independently test production with both legacy
   clients.
5. Ship API-based iOS and Android builds from the same catalogue-policy revision.
   Verify a cross-platform couple in both answer directions.
6. Deploy Android version code greater than 45 to internal testing. Verify a new
   user and an existing production-like user with historical adult responses.
7. Keep the universal allowlist unchanged during the first Play review.

### Phase E - Play submission

1. Deactivate superseded non-compliant bundles from every active testing track
   that is included in review.
2. Complete the content-rating questionnaire from the remediated binary and
   catalogue, not the previous app. Do not under-declare remaining content.
3. Provide working reviewer credentials and deterministic navigation notes.
4. In the submission note, state that the cited Fantasy Scenarios, Sensual
   Touch, and Pushing Limits content has been removed from Sauci's production
   catalogue on both platforms and that new content is manually allowlisted.
5. Attach concise evidence from the exhaustive Android crawl. Do not argue that
   competitor apps prove compliance.
6. Submit one clean remediation build; do not repeatedly test policy boundaries
   with incremental explicit variants.

## 9. Verification matrix

### Database

- Fresh local reset applies every migration.
- New content defaults to `unreviewed`.
- Non-admin direct SELECT cannot see unreviewed/archived child or parent rows.
- Admin can see all rows without weakening couple/user RLS.
- Direct target-pack RPC calls cannot retrieve an archived pack.
- Soft-deleted questions never appear.
- Status changes require a reason, record actor/time, append one audit event,
  and increment policy revision.
- Content-text edits reset status; metadata-only edits behave as specified.
- Existing response/match/message row counts are unchanged by classification.

### API

- iOS, Android, missing headers, invalid headers, old builds, and unknown future
  builds all get exactly the same allowlist.
- Every catalogue count equals its filtered children.
- A known archived UUID returns 404 on pack, question, response, match, chat,
  toggle, and dare endpoints.
- Pending, answer gap, daily limit, badges, and progress exclude archived items.
- Couple A cannot infer IDs, counts, responses, matches, or devices for Couple B.
- Premium cannot bypass content status.
- Logs/errors never contain text from archived content.

### Mobile clients

- Android fresh install/upgrade from version 45 and iOS fresh install/upgrade;
  existing subscriber, non-subscriber, paired/unpaired, and user with historical
  adult matches.
- Browse every category/pack/card; test direct links and notification taps.
- Test Matches tabs, My Answers, chat header, realtime toasts, search, empty
  states, settings, onboarding, subscription screens, and dare interest page.
- Change policy revision while an archived card is on screen; it disappears before
  any further render/action.
- Attempt traffic replay with an archived UUID; UI shows only the neutral state.
- Automated screenshot/text crawls on both apps contain none of the rejection
  evidence or disallowed developer-authored acts.
- An iOS user answers first and an Android partner can retrieve and answer the
  same question; repeat with Android first, then verify matching progress,
  badges, match creation, chat header, history, and notification destination.
- Archived historical records remain stored but are hidden consistently from both
  partners on both platforms.

Run the repository gates in order: focused unit/integration tests,
`npm run verify:fast`, local database reset/RLS tests, API E2E, native iOS and
Android verification, then `npm run verify:full`. A missing simulator, database,
or credential is reported as an environment limitation, not a pass.

## 10. Observability and rollback

Emit metrics without content text:

- catalogue responses by policy revision/build/platform;
- count of allowed/archived/unreviewed entities;
- archived-ID read/write attempts by route;
- policy revision adoption by active device;
- notification suppressions by reason;
- legacy direct-client usage and API migration percentage.

Add a nightly invariant check that fails if any customer API response could join
a non-allowed entity, if an allowed child has an archived parent, if two members of
a couple can receive different eligibility for the same question, or if an
allowed inverse pair is inconsistent. Alert rather than auto-classifying.

Rollback is configuration-first: set `catalog_emergency_disabled=true`,
invalidate caches by incrementing the policy revision, and disable affected API routes. Do
not roll back the additive schema or restore broad direct-table RLS. Content
decisions can be reverted only through a new audited review event.

## 11. Concrete file checklist

Database and functions:

- `apps/supabase/migrations/20260827215907_add_catalog_content_review_metadata.sql`
- `apps/supabase/functions/submit-response/index.ts`
- `apps/supabase/functions/update-response/index.ts`
- all notification/catch-up/summary functions listed above
- regenerated `packages/shared/src/types/supabase.ts`
- regenerated `apps/mobile/src/types/supabase.ts` if it remains during migration

API and shared contracts:

- `apps/api/src/app.ts`
- new request-context/content-policy modules
- `apps/api/src/db/schema.ts`
- `apps/api/src/domains/packs/{repository,routes,schema}.ts`
- new questions, responses, matches, devices, notifications, and dares domains
- route/repository/integration tests for every domain
- `packages/shared/src/types/index.ts` plus domain-specific schema/type modules

Mobile:

- `apps/mobile/src/lib/apiClient.ts`
- stores/services/screens listed in section 5.1
- `apps/mobile/src/lib/notifications.ts`
- `apps/mobile/app/_layout.tsx` and `apps/mobile/app/(app)/_layout.tsx`
- new content-policy/cache reset module and tests
- iOS and Android onboarding/settings/paywall/dare copy

Admin:

- content pages and services for categories, packs, questions, dare packs, dares
- `apps/admin/src/hooks/useAuditedSupabase.ts`
- new review queue/history/bulk-confirmation components and tests
- dashboard compliance counts

Documentation:

- `docs/architecture/system.md` for the enforced API boundary
- `docs/question-selection.md` for universal eligibility-aware selection
- `docs/match-notifications.md` for device-aware safe delivery
- `docs/schema.md` for review/device tables
- `docs/releasing.md` for the cross-platform catalogue and Android compliance gates
- `docs/testing/strategy.md` for the cross-platform matrix
- `docs/index.md` linking this maintained plan while remediation is active

## 12. Definition of done

The remediation is not done when the three cited packs disappear from the pack
screen. It is done when legacy and new iOS/Android clients, direct Supabase
requests, guessed IDs, history, matches, chat, realtime, and push paths all fail
closed; the audited allowlist is complete; historical data is preserved; both
partners observe the same eligibility; and the end-to-end crawls prove no
disallowed developer-authored content can be reached.