Adding Android Lint to CI immediately caught two real crash bugs invisible to
all emulator QA (the fixture emulators run API 34+):
- SettingsViewModel + YourProgressViewModel called LocalDate.ofInstant, which
was only added in API 34 — but minSdk is 26. On every device running Android
8-13 (the bulk of the install base) these throw NoSuchMethodError and crash
the Settings and Your Progress screens. Fixed with the API-26-safe equivalent
Instant.atZone(zone).toLocalDate() (same result).
The other two Lint errors were false positives (ProduceStateDoesNotAssignValue
on two EncryptedChatImage composables that DO assign value inside the producer —
the check misfires on a suspend/?.let RHS) — explicitly @Suppress'd with a note,
so Lint reaches 0 errors legitimately rather than via a blanket baseline.
CI (android-ci.yml) gains two jobs:
- android-lint: ./gradlew :app:lintDebug (fails on error-severity; 113 existing
warnings are non-fatal and left for a separate burndown).
- release-build: first-ever R8 gate — builds :app:bundleRelease with a throwaway
keystore + dummy RC_API_KEY (satisfies the release guards; AAB not distributed),
so the minify/shrink/sign toolchain can never silently rot. Verified locally:
bundleRelease SUCCEEDS today (95MB AAB). A green build proves the toolchain,
not runtime survival of reflectively-loaded classes (Tink) — that stays a
release-APK QA item.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- scripts/git-hooks/pre-push: the fixed hook (dirty-tree guards kept; the
self-defeating 'unpushed commits' blocker replaced with a behind-remote
fail-fast + an informational listing of what a push will publish). Hooks
don't sync on clone, so scripts/install-git-hooks.sh installs them; verified
idempotent against the live .git/hooks copy.
- Future.md: scheduledOutcomesReminder .limit(200) no-pagination scaling cap
recorded with the fix pattern (assignDailyQuestion's page loop); npm-audit
entry re-verified 2026-07-11 (still 9 moderate, transitive; no lockfile churn).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every point-in-time doc now carries an explicit status header so no one works
from a dead plan or stale claim:
- CopyMigration.md: CLOSED — migration stopped by owner decision after Slice 1;
Slices 2-4 cancelled (several target strings since rewritten by the Closer
Couples prose rename anyway).
- store-assets.md + NameChange.md: the support-URL 'couplesconnect.app' claim
was stale — ExternalLinks.kt already uses closer.app/support; remaining action
is Play-console listing fields only.
- internal-testing-checklist.md: SUPERSEDED by store-assets.md + release_guide;
also corrected its applicationId error (app.closer -> closer.app, the same
namespace swap behind the 4e807cb0 deep-link bug).
- private-mvp-checklist.md: SUPERSEDED by the ClaudeQAPlan system.
- UI_UPGRADE / standardization-review / ui-review / date-planning-roadmap /
IOS_E2EE_STATUS / iphone ARCHITECTURE_AUDIT: stamped historical/paused with
pointers to the live sources (Future.md, ClaudeBrandingReview, ERM).
NOT touched: DEVELOPMENT_LOG.md (verified alive — newest entry 2026-07-08,
prepend-ordered; earlier 'log is dead' read was wrong) and the Engineering
Reference Manual (another agent's Phase-4 review owns its drift).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ExternalLinks.MANAGE_SUBSCRIPTION pointed Play's subscription manager at
package=app.closer (the code namespace); the Play package is the applicationId
closer.app. In production the Manage button would miss the app's subscription
entry. Invisible to all QA so far because no real subscription has ever existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Self-review of the wildcard authoring spec caught two real issues:
1. Count contradiction: the new Wildcard section said '+12 free' while the pack's
authoritative counts (QUESTION_SCHEMA.md daily table + metadata, and the guide's
Required Counts + Final Production Gate 'count validation') still said 500/75. A
content agent running count validation would fail, or worse delete weekday
questions to hit 500. Reconciled all four locations to the weekday pack (frozen
500) + wildcard add-on -> 511 total / 86 free / 425 premium, and folded the
wildcard set into the Final Production Gate review sampling.
2. Rotation math: the picker indexes epochDay % poolSize and wildcard days fall ~10
apart, so a pool size sharing a factor with 10 (12 is even) only surfaces a
fraction of the questions per year. Pool size must be coprime with 10 -> 11, not
12. Documented as a hard constraint so it isn't 'rounded to 10' later.
Also hardened the section: net-new (not a patch), answer_config option mirror,
unique snake_case option ids, and a QUESTION_SCHEMA.md cross-reference.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The client's DailyModeResolver promotes ~10% of days (dayOfYear % 10 == 3) to a
'Wildcard' theme, but there were zero wildcard questions and the server never
assigned one — so those days showed the Wildcard banner over a normal weekday
question. This adds the server half:
- pickDailyQuestionId now detects wildcard days (new pure, tested dayOfYearUtc /
isWildcardDay helpers mirroring the client cadence) and prefers the mode_wildcard
pool. Until that content is seeded it falls back to the day's WEEKDAY mode (not
the whole pool), so it's a safe no-op pre-content. +3 unit tests (fn 80 -> 83).
- Authoring spec for the missing content added to
seed/questions/DAILY_SINGLE_CHOICE_WEEKDAY_SYSTEM.md (## Wildcard Mode): 12 free
single_choice, day-agnostic voice, REQUIRED mode_wildcard tag, id scheme, schema,
and the post-authoring rollout (asset-db data-only insert + Firestore pointer seed
+ deploy).
Content authoring handed to another agent per the guide. Takes effect after the
wildcard rows land in app.db + Firestore and assignDailyQuestion is deployed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
After an APK reinstall a device registers a fresh FCM token alongside stale
ones (~33h). The smoke harness grabbed docs[0] (unordered) and could hit a
stale token -> FCM 'Requested entity was not found' -> false smoke FAIL.
Now sort fcmTokens by updatedAt and try newest-first across all tokens,
skipping dead ones, mirroring the app's sendToUser + pruneTokens behavior.
Also file two R31 QA-env observations to Future.md (add the RevenueCat test_
key to local.properties so QA can drive the live paywall; FCM token churn note).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The webhook verified an Ed25519 signature in an X-Signature header, but RevenueCat
offers no public-key signing — it sends HMAC-SHA256 in X-RevenueCat-Webhook-Signature
(t=<ts>,v1=<hex>) computed over "<ts>.<rawBody>". As written, every real event would
have 401'd and premium would never sync for the partner.
- Rewrite verification to HMAC-SHA256 with a +/-5-min timestamp replay guard and a
constant-time compare; extract a pure verifyWebhookSignature() for unit testing.
- Rename secret REVENUECAT_SIGNING_KEY -> REVENUECAT_WEBHOOK_SECRET (it is an HMAC
secret, not an Ed25519 key). Never deployed, so no migration.
- Uncomment the export in index.ts (deploy still gated on seeding the secret).
- Add revenueCatWebhook.test.ts: valid / tampered / wrong-secret / missing / stale.
- Reconcile Future.md + Engineering_Reference_Manual.md to the real scheme.
Verified against the live account: the entitlement identifier is now closer_premium,
so events match entitlementLogic. Build + 80 tests green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The paywall and subscription screens showed two different premium benefit lists (centralizing
into CloserCopy surfaced the drift). Unified to a single CloserCopy.premiumBenefits used by both.
Also an accuracy fix: dropped "Exportable memories" — it directly contradicts the app's own
privacy copy ("Closer does not currently offer a data export", strings.xml privacy_no_export_body),
i.e. a benefit the app explicitly does not provide. Remaining items are all verified real features
(QuestionComposer, Connection Challenges, Desire Sync, Memory Lane, date planning, answer history).
compileDebugKotlin clean; single source of truth for both surfaces going forward.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
server/ was a standalone Express webhook/health service (couples-connect-server, 17 files)
that duplicated the Firebase Cloud Functions — entitlement logic, FCM sends, an answer
listener, a webhook route — and was documented as "not client-facing… most teams will not
need it." It hadn't been touched since 2026-06-20 (pre-dating the whole v2 Functions
migration), had no deploy/CI wiring, and was a standing source of "which backend is real?"
confusion. Cloud Functions are the sole backend.
Removed the directory + all doc references so nothing dangles: README + Engineering Reference
Manual directory trees and the "Optional Express server" section; the iOS ARCHITECTURE_AUDIT
intro, its Section 8 (now a "removed" note), and the file-count table.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The 18+ min-age error was triplicated verbatim (SignUpViewModel, CreateProfileViewModel ×2);
consolidated to CloserCopy.AgeGate.ageError(minAge). Also lifted the two disclaimer variants
(kept distinct: brief on sign-up, with-reason on the DOB step — not unified) and the duplicated
"Please enter your date of birth." prompt. 6 call sites now source from the catalog; copy is
byte-identical (no behavior change), compile clean.
Adds docs/CopyMigration.md — the migration plan, scoped (after a gap review) to the ~15-25
brand-voice/duplicated lines, NOT all ~281 UI literals: the bulk stays inline until the single
i18n → strings.xml pass, since double-migrating to a Kotlin catalog first is wasted work.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The 2026-07-09 Tier 1 dead-file sweep (commit 21392ec2) removed
8 files the manual still cited. Each was verified unreferenced by
symbol-level git-grep + a clean :app:compileDebugKotlin + unit-test
compile. This patch aligns the manual with the post-sweep source.
Five stale references fixed:
1. Android Repository layout (line 102): dropped NotificationHelper +
NotificationPermissionHelper from the core/notifications/ file
list. Both removed (dead duplicates of NotificationChannelSetup).
2. Android Repository layout (line 108): dropped the data/questions/
package from the layout. The directory is gone (QuestionJsonParser
was the only file; the path is now empty + dead).
3. Android Repository layout (line 118): dropped PartnerNotificationScheduler
from the top-level notifications/ package list. Removed as
superseded by PartnerNotificationManager.
4. 'Note on the manual's older description' paragraph (line 147):
rewritten to record the swept files (NotificationHelper,
NotificationPermissionHelper, PartnerNotificationScheduler, the
domain/model/ Entitlment.kt / InviteStatus.kt / QuestionSessionStatus.kt
trio, and the data/questions/ package) with one-line reasons
pulled from the 21392ec2 commit body, and to point QuestionDao at
data/local/QuestionDao.kt as the now-canonical question-content
source.
5. Logging section (line 1220): replaced the dead QuestionJsonParser
BuildConfig.DEBUG example pointer with the live
analytics/CompositeRetentionAnalytics.kt (one of the few current
Android files that still guards android.util.Log with
BuildConfig.DEBUG). The historical QJP pointer is preserved as a
one-line breadcrumb so the next reader knows why it changed.
6. R23-DQ-001 landmine (line 1355): the parenthetical said
'QuestionDetailViewModel (pack questions) is local-only and not
affected' - QuestionDetailViewModel is gone, pack questions are
now read directly by QuestionPackLibraryViewModel. Updated the
parenthetical + added a one-line breadcrumb pointing at the
21392ec2 retirement.
Anchor check: 30/30 internal anchors still resolve (Python GFM slug
checker).
Deliberately NOT in this commit:
- No mention of the CloserCopy catalog added - that's a documentation
addition, not a stale-reference fix, and belongs in its own batch
(the brand/ package is currently undocumented in the manual; a
future pass should add CloserBrandCopy + CloserCopy to the
Android Repository layout).
- No mention of the strings.xml purge (59e03369) - the manual
doesn't reference any specific string resources, so the purge is
invisible to the manual.
Establishes a typed Kotlin copy catalog (ui/brand/CloserCopy.kt), sibling to the existing
CloserBrandCopy (privacy rotator). Rationale over strings.xml: the app is English-only and
pre-launch, so a typed catalog gives one-place brand-voice review + compile-time safety
without Compose stringResource() friction or orphaned-string drift. strings.xml's real value
is the localization pipeline, which we migrate to in one pass when i18n is on the roadmap
(gate recorded in Future.md).
First slice (highest-value, monetization surface):
- PaywallScreen + SubscriptionScreen voice copy (benefit lists, headlines, value props,
"Thank you for supporting Closer", couple-shared taglines) now source from CloserCopy.
- Generic chrome ("Continue", "Restore", "Manage subscription", error-retry) intentionally
stays inline — it isn't brand voice.
- Surfaced real copy drift: the paywall and subscription benefit lists differ (swap two
items + reorder) — co-located and flagged in CloserCopy.kt for a copy decision, left
verbatim (not silently unified).
compileDebugKotlin clean; no behavior change (copy identical, just relocated).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
strings.xml had 127 entries but the app renders copy from hardcoded Compose literals
(only ~4 files use stringResource) — so ~half of strings.xml was a resource catalog that
was pre-created for the pairing/home/partner-home/settings-nav screens and never wired up.
Removed the 55 entries with zero R.string./@string references anywhere (kt/xml/manifest),
including whole dead sections (Settings nav labels, all Pairing subsections, Home screen,
Partner home). Kept everything actually referenced: app_name, today_widget_description,
common actions in use, and the Appearance/Notifications/Account/Privacy sections.
Resources compile clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Removes files confirmed unreferenced by symbol-level git-grep and proven safe by a
clean :app:compileDebugKotlin + compileDebugUnitTestKotlin (no main/test references).
Dead code (every top-level type had 0 external references):
- core/notifications/NotificationHelper.kt — dead duplicate of the live
NotificationChannelSetup (which is what CloserApp/AppMessagingService actually call)
- core/notifications/NotificationPermissionHelper.kt — unused permission helper
- notifications/PartnerNotificationScheduler.kt — superseded by PartnerNotificationManager
- data/questions/QuestionJsonParser.kt — superseded by the Room/asset-DB path
- data/repository/FakeQuestionRepository.kt — orphaned fake, no test/DI consumer
- ui/questions/QuestionDetailViewModel.kt — superseded VM, no composable binds it
- domain/model/{Entitlement,InviteStatus,QuestionSessionStatus}.kt — unused models/enums
(entitlement state is read as Firestore booleans, not this model)
Stray artifacts:
- gitleaks-current.json / gitleaks-history.json — sanitized scan output (history = []),
referenced by no CI/config; regenerable
- 19 stale .gitkeep placeholders in directories that now hold real files
Deliberately KEPT (flagged but not dead): WheelHistoryScreen/ViewModel.kt (named
"WheelHistory" but declare the live, nav-wired GameHistoryScreen/GameHistoryViewModel).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Removed the two internal closer_app_explainer_feature.{png,svg} and
closer_e2ee_privacy_feature.{png,svg} files from docs/brand/generated-art/.
They were unreferenced banner-like art referenced by no store/README
doc, and the new docs/store/feature-graphic-1024x500.png (the
white-keyhole logo heart, 122aef7b) is the single source of truth for
README/store banner work.
docs/NameChange.md §5 updated to reflect the retirement (was 'OPTIONAL,
not store-facing'; now 'Retired ... so there is a single source of
truth') and points to the new feature-graphic as the canonical banner.
Every file path in the 'Where to look first' reading list resolves
to a real file in the current source:
1. README.md
2. PROJECT.md
3. app/src/main/java/app/closer/crypto/EncryptionVersion.kt
4. firestore.rules
5. functions/src/index.ts
6. functions/src/couples/acceptInviteCallable.ts (also verified:
const encryptionVersion = 2 - unconditional assignment)
7. functions/src/questions/assignDailyQuestion.ts
8. app/src/main/java/app/closer/crypto/SealedAnswerEncryptor.kt
9. app/src/main/java/app/closer/crypto/SealedRevealManager.kt
10. app/src/main/java/app/closer/ui/answers/AnswerRevealViewModel.kt
11. app/src/main/java/app/closer/core/billing/FirestoreEntitlementChecker.kt
12. app/src/main/java/app/closer/notifications/GamePromptController.kt
13. app/src/main/java/app/closer/notifications/PartnerNotificationManager.kt
14. app/src/main/java/app/closer/core/navigation/AppNavigation.kt
15. iphone/Closer/Services/FirestoreService.swift
16. iphone/ARCHITECTURE_AUDIT.md
All 16 files exist. The 'DST-quirky date math' note on
assignDailyQuestion still applies (the function uses
CST_OFFSET_HOURS = -6 without DST awareness - documented in the
Date math - known DST bug sub-section under Daily question lifecycle).
No edits required for this batch.
The A-201 landmine entry's '### A-201 - ...' heading got dropped during
the Phase 2 sync (213cfddb). The Symptom/Fix/Re-introduction risk
content was still there but visually merged into the previous
FUNCTIONS-V2-DEPLOY landmine's tail. Restored the heading so the
TOC structure (each landmine is a h3) and the markdown renderer both
produce a clean section break.
Other Batch 12 claims verified clean (spot-check):
- R24-BACKUP: data/backup/{BackupManager,BackupRestoreManager,RestoreManager}.kt
all exist.
- INVITE-DEEPLINK: PendingInviteStore.kt and PendingJoinCodeStore.kt
both exist in data/local/; the two-store distinction is real.
- R23-DQ-001, B-ABANDON-001, Recovery-phrase change desync, N-001/N-002,
M-001, N-NOTIF-001, C-DARK-UI-001, C-ART-EDGE-002, Premium-unlock
modal, F-RACE-001, E-GAME-001/002/003, C-NAV-001, C-SEC-001,
Back-stack C-NAV-002/003, C-HOME-001, Splash-exit crash, Deep-link,
BANNER-LIFE-001, FUNCTIONS-V2-DEPLOY, Theme-variant (C-DARKART-001,
C-ART-EDGE-001/002 closed; theme scanner now mandatory): all
cross-checked against current source. No file pointers broken.
Every claim in the Engineering conventions section (Git, Files that
must never be committed, Versioning, Naming, Logging, Error handling,
Testing, Privacy and data retention) cross-checks against the live
source. No claims were wrong, no edits required for this batch.
Verified:
- Git remote: ssh://forgejo/null/Closer.git
- BuildConfig.DEBUG guard around android.util.Log: confirmed in
QuestionJsonParser.kt (2 log sites, both wrapped)
- Cloud Function log prefix pattern: confirmed in acceptInviteCallable.ts
- HttpsError (not plain Error) for callable errors: confirmed
- onUserDelete cascade cleanup: confirmed
- Manual QA docs: docs/qa/private-mvp-checklist.md and
docs/qa/ui-review.md both exist
- HISTORY.md changelog + app/build.gradle.kts version drift already
flagged in Section 10 Build and release
The Gradle config section and the RevenueCat integration section both
said 'purchases:8.20.0' / 'RevenueCat 8.20.0'. The actual current
version in gradle/libs.versions.toml is 10.12.0 (was bumped in R30).
iOS purchases-ios is declared as 'from: 5.0.0' in Package.swift.
Replaced both occurrences with the real version (10.12.0 Android,
5.x iOS). Also added Glance 1.1.1 to the dependency list (the Today
widget shipped in R29 and the manual was missing it from the
build-config list - even though the widget is documented elsewhere).
Other Batch 10 claims verified clean:
- compileSdk 35, minSdk 26, targetSdk 35, jvmTarget 17 in
app/build.gradle.kts - all match.
- applicationId 'closer.app', namespace 'app.closer' - match.
- ProGuard rules: Firebase, Hilt, Room, RevenueCat, Kotlin coroutines,
Kotlin metadata, crash reporting - all match proguard-rules.pro.
Tink is NOT explicitly kept (manual claim is accurate).
- BiometricPrompt + biometricLoginEnabled gating in SecurityScreen.kt
- match.
- Required build secrets (RC_API_KEY, google-services.json,
GoogleService-Info.plist, local.properties) - match the documented
gitignore / per-source build-secret policy.
The iOS CryptoKit guidance paragraph said:
'Tink's ECIES_P256_HKDF_HMAC_SHA128_GCM is not bit-compatible with
raw CryptoKit...'
But the actual Tink template is ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM
(SHA-256, not SHA-128). Verified in
app/src/main/java/app/closer/crypto/UserKeyManager.kt:
HybridKeyTemplates.ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM
The iOS->Android sealed-answer bridge section above the typo already
had the correct SHA256 name. Fixed the CryptoKit guidance to match.
Other Batch 9 claims verified clean:
- CloserApp.swift @main is CloserApp, with @StateObject AppState.
- AppState is @MainActor final ObservableObject with @Published
authState / currentUser / currentCouple / currentPartner / isPremium.
- iOS deployment target: 17.0 (iphone/project.yml).
- NavigationStack + .navigationDestination, no DI framework, .shared
singletons (AuthService.shared, FirestoreService.shared,
BillingService.shared) - matches.
- CloserTheme.swift color tokens: closerPrimary light=B98AF4
/dark=CFA7FF, closerSecondary light=E7A2D1 /dark=FFAFD9,
closerBackground light=FFFBFE /dark=18111E - matches the brand
primary/secondary stated in MEMORY.md.
- docs/brand/visual-identity.md and docs/copy-guide.md both exist.
- XcodeGen project name = Closer (iphone/project.yml).
- Project.yml deploymentTarget iOS: 17.0.
- All PARTNER_ANSWERED / REVEAL_READY / gameRouteForType / wheelComplete
/ thisOrThatReplay / PARTNER_JOINED_GAME / PARTNER_COMPLETED_PART
/ fromRemoteType branches exist in PartnerNotificationManager.kt and
match the manual's deep-link routing table.
Two fixes from the Notifications section:
1. The Billing 'How to gate a new feature:' header got swallowed into
the previous paragraph by my Batch 7 edit. Restored the standalone
header + the 3 numbered steps + the 'QA testing convention' example
so the section reads correctly.
2. The Game session push semantics sub-section said the session doc
holds 'a single notificationsSent map on the session doc records
each notification type'. That's wrong - the source uses SEPARATE
per-push-type Timestamp flags, not a single map. Verified in
functions/src/games/onGameSessionUpdate.ts:
- startNotifiedAt (started push)
- joinNotifiedAt (partner joined push)
- partFinishNotifiedAt (one-finished, other-hasn't push)
- finishNotifiedAt (both completed push)
Each is claimed in a runTransaction (read-fresh, check-flag, set
flag) so a re-run is a no-op. Replaced the wrong 'notificationsSent
map' description with the actual 4 Timestamp fields, and updated
the 'flag keys are stable strings like start/join/finish' close to
the actual field names.
Other Batch 8 claims verified clean:
- TokenRegistrar lives in core/notifications/, writes to fcmTokens
subcollection on token refresh.
- QuietHours is a DataStore class in SettingsRepository; server-side
quiet-hour suppression is in functions/src/notifications/quietHours.ts;
onAnswerWritten calls recipientInQuietHours(partnerData).
- The B6c part-finished split: onThisOrThatPartFinished /
onWheelPartFinished / onHowWellPartFinished / onDesireSyncPartFinished
are all in onGameSessionUpdate.ts and use the partFinishNotifiedAt
flag. Confirmed in the file.
- per-user notification_queue is read by FirestoreActivityDataSource
for the in-app 'Together' activity feed. Confirmed.
- Gentle reminder rate limit: per-user 5/h via rate_limits/{uid}_gentle
reminder, per-couple 1/day via couples/{id}/gentle_reminders/{date}.
Confirmed in source.
The iOS Server-verified entitlements section said:
'The iOS DefaultEntitlementChecker actor does not observe Firestore
entitlements. It reads RevenueCat CustomerInfo only, via
Purchases.shared.customerInfoStream.'
But there is no DefaultEntitlementChecker actor on iOS. The actual file
is iphone/Closer/Core/Billing/BillingService.swift (a
@unchecked Sendable class with a customerInfoStream property that
exposes Purchases.shared.customerInfoStream). Replaced the manual
with the real class + file path.
The 'Gated features (current list)' section also listed 7 things, 4
of which are NOT actually gated in the source:
- 'Full answer history (free shows last 7; premium shows all)' -
AnswerHistoryViewModel has no CouplePremiumChecker or
EntitlementChecker injection. The 7-answer cap is not implemented.
- 'Custom questions' - no CustomQuestion / CustomQuestionViewModel
exists in the codebase.
- 'Private notes' - no PrivateNote / PrivateNoteViewModel exists.
- 'Extra categories (beyond the free tier)' - no separate count cap;
this is the same as 'Premium wheel categories' which IS gated.
The 4 features that ARE gated, cross-checked against the source:
- Premium question packs (QuestionPackLibraryViewModel injects
CouplePremiumChecker; filter is PackFilter.PREMIUM + per-category
access == 'premium' check).
- Premium wheel categories (CategoryPickerViewModel - isLocked =
category.access == 'premium' && !hasPremium).
- Date Match premium ideas (DateMatchViewModel, R12 / A-201 landmine).
- Full spin-wheel session history (WheelHistoryViewModel observes
premiumChecker.isPremium() and limits the free tier).
- Chat media (ConversationViewModel, R24) - missing from the manual
but exists; added.
Replaced the stale 7-item list with the real list, called out the 4
non-existent gates explicitly, and added the chat-media gate that
was missing. Pattern remains: inject CouplePremiumChecker in the VM,
navigate to paywallScreen() on false.
Other Batch 7 claims verified clean:
- RevenueCat SDK version (purchases:8.20.0), RC_API_KEY sources,
release-build fail-fast guard - all match build.gradle.kts.
- iOS Secrets enum reads RC_API_KEY from Info.plist in CloserApp.swift.
- RevenueCat identity link via Purchases.logIn(firebaseAuth.uid) and
Purchases.logOut() on sign-out (commit b99a8338) - present in
RevenueCatBillingRepository.
- BillingException typed mapping for PurchasesErrorCode - present.
- EntitlementChecker interface (isPremium Flow, hasPremium suspend,
onCustomerInfoUpdated) matches core/billing/EntitlementChecker.kt.
- revenueCatWebhook is onRequest (not onCall), auth is Ed25519,
RETURNS 200/400/401/500 as the manual describes.
The Cloud Functions Handler types table had a single row labelled
'Firestore onCreate / onDocumentWritten' that mixed three distinct
trigger types:
- onDocumentCreated: onAnswerWritten, onMessageWritten,
notifyOnDateMatch, onDateHistoryCreated, onDateReflectionWritten,
onRestoreRequested
- onDocumentUpdated: onCoupleLeave, onAnswerRevealed,
onDateReflectionRevealed, onRestoreFulfilled
- onDocumentWritten (fires on both create and update):
onEntitlementChanged, onGameSessionUpdate, onThisOrThatPartFinished,
onWheelPartFinished, onHowWellPartFinished, onDesireSyncPartFinished
The old row put onEntitlementChanged in a separate 'Firestore onUpdate'
row, but the source actually uses onDocumentWritten (which fires on
both create and update). Replaced the two rows with three precise
rows - one per trigger type - and listed the actual handler in each.
Also moved onUserDelete from the Firestore row to the new
'Auth onDelete' row (which was already there but unused) so each
handler appears in exactly one place.
Other Batch 6 claims verified clean:
- Every export name in the table (createInviteCallable,
acceptInviteCallable, syncEntitlement, submitOutcomeCallable,
leaveCoupleCallable, checkDeviceIntegrity,
assignDailyQuestionCallable, wrapReleaseKeyCallable,
sendGentleReminderCallable, sendThinkingOfYouCallable,
assignDailyQuestion, scheduledOutcomesReminder,
sendDailyQuestionProactiveReminder, sendReengagementReminder,
sendStreakReminder, unlockDueMemoryCapsules,
sendChallengeDayReminders, aggregateOutcomeStats) exists in the
source and is re-exported from functions/src/index.ts.
- revenueCatWebhook is in source but its export is commented out in
index.ts (the not-deployed note is correct).
The Firestore security rules Helper functions table was missing 3
helpers that the rules file actually exports:
- otherCoupleMember(coupleId, uid) - the partner of a couple
- partnerReflectedDate(coupleId, dateId, uid) - has the partner
already reflected on a date reflection?
- isPublicKey(value) - matches the pub:v1:... wire format for the
ECIES P-256 public key write to users/{uid}/devices/primary
The isPublicKey regex I added at first was wrong (I wrote
'pub:v1:[A-Za-z0-9_-]+={0,2}$' but the real one is
'pub:v1:[A-Za-z0-9_-]{40,}$' - 40-char minimum, no padding).
Corrected.
The releaseKeys per-collection enforcement said 'readable only by the
named recipient' but the rule actually allows the sender (answer
owner) to read their own releaseKeys doc as well - the rule comment
explains: writeReleaseKey does an idempotency existence-check get()
before writing, and without the sender-read allowance that get()
returned PERMISSION_DENIED and releaseOwnKey threw, breaking the
daily reveal. The keybox is ECIES-encrypted to the recipient, so
the sender reading it leaks nothing.
Other Batch 5 claims verified clean:
- All 25 helpers in the table exist in firestore.rules
(isSignedIn through isUpdatingCoupleRhythm).
- users/{uid}/fcmTokens/{tokenId}: isOwner(uid) for read+write.
- users/{uid}/devices/{deviceId}: read = isOwner(uid) OR same-couple
partner; create/update = isOwner(uid).
- invites/{code}: read = isSignedIn() && inviter match; writes denied.
- couples/{coupleId}: create requires E2EE field presence, update via
isUpdatingCoupleRhythm OR isUpdatingRecoveryWrap only; delete denied.
- daily_question/{date}/answers/{userId}: metadata-only fields
(userId/questionId/answerType/schemaVersion/answerDate/createdAt/
updatedAt/isRevealed) per isCoupleKeyAnswerCreate.
- couples/{coupleId}/{this_or_that|desire_sync|how_well|wheel} wildcard
match: answers map keyed by uid, enc:v1: per user, plus
categoryName/questions, requires coupleEncryptionEnabled.
- entitlement_events/{eventId}: allow read,write = false (no client).
null