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).
The server-authoritative mode-aware deterministic selection sub-section
listed the DOW -> mode map as:
Monday mode_soft_monday, Tuesday mode_snack_mission, ..., Sunday
mode_tiny_date_night
But the source-of-truth WEEKDAY_MODE_TAGS table in
functions/src/questions/assignDailyQuestion.ts has 7 entries, one per
weekday:
0 Sunday mode_tiny_date_night (Slow Burn Sunday)
1 Monday mode_soft_monday (Mood Check Monday)
2 Tuesday mode_snack_mission (Tiny Win Tuesday)
3 Wednesday mode_no_phone_moment (Real One Wednesday)
4 Thursday mode_laugh_reset (Laugh It Off Thursday)
5 Friday mode_flirty_friday (Flirty Friday)
6 Saturday mode_weekend_side_quest (Side Quest Saturday)
Saturday was missing. Replaced the partial listing with the full
7-entry table, the constant name, and a note that the map is also
unit-tested (assignDailyQuestion.test.ts). Future reader can now grep
the mode tag against both files at once.
Other Batch 4 claims verified clean:
- Schedule '0 23 * * *' America/Chicago, memory 512MiB, timeoutSeconds 300
in assignDailyQuestion source - all match.
- Document shape: questionId, date, assignedAt, expiresAt - all match the
create() payload (assignedAt is serverTimestamp, expiresAt is
timestampAt6PmCst(nextDay)).
- PAGE_SIZE = 300, ordered by __name__, startAfter pagination - matches.
- The daily_question allow create rule uses isCoupleKeyAnswerCreate OR
isSealedAnswerCreate - matches the manual's 'must match one of two
shapes' claim.
- The secure/{doc} read rule uses the partner-has-also-answered exists()
check - matches the Reveal flow claim.
- isSealedThreadAnswerCreate / Update have NO answerDate and NO
isRevealed field - matches the Thread questions claim.
The Argon2id parameter block said:
- memory: 46 MiB (46080 KiB)
- iterations: 3
- parallelism: 1
But the source constant in RecoveryKeyManager.kt is:
private const val ARGON2_MEMORY_KB = 46 * 1024
46 * 1024 = 47104, not 46080 (a slipped digit). 46080 KiB would be
45 MiB. The iOS-side docstring in CoupleEncryptionManager.swift
already says 46 MiB = 47104 KiB, so this is the Android-side drift.
Replaced the parameter block with the source-of-truth constant names
(ARGON2_MEMORY_KB, ARGON2_ITERATIONS, ARGON2_PARALLELISM) and the
correct KiB value (47104) so the next reader can grep the code.
Other Batch 3 claims verified clean:
- Encryption version table: EncryptionVersion.STRICT=2, acceptInviteCallable
hardcodes 2, throws if any of wrappedCoupleKey/kdfSalt/kdfParams is null.
- Tink AEAD wire formats: enc:v1:base64, sealed:v1:urlsafe-base64-no-padding,
keybox:v1:urlsafe-base64-no-padding, pub:v1:urlsafe-base64-no-padding,
sha256:urlsafe-base64-no-padding (43 chars). All match the source constants.
- AAD: FieldEncryptor uses coupleId; SealedAnswerEncryptor uses
coupleId|questionId|userId; both match.
- ECIES P-256: UserKeyManager uses
HybridKeyTemplates.ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM;
ReleaseKeyEncryptor contextInfo is coupleId|questionId|senderUserId|recipientUserId.
- All 5 firestore.rules regex helpers match the manual's reference table.
- wrapReleaseKeyCallable reads the recipient public key from
users/{uid}/devices/primary (verified in function source).
- CoupleKeyStore persists Tink keyset handles in EncryptedSharedPreferences
(Keystore-backed) via SecurePreferencesFactory.
The Recovery phrase flow said RecoveryKeyManager.generateRecoveryPhrase()
draws from a 256-word list. Verified the actual list size in
RecoveryKeyManager.kt: the hard-coded WORDLIST array has 248 entries
(python re.findall over the array literal), and the iOS wordlist file
iphone/Closer/Crypto/Resources/wordlist.txt is 247 lines (last word
'real' with no trailing newline, so 248 entries). The '256' is also
wrong in the inline comment in RecoveryKeyManager.kt - a pre-existing
comment bug from before the R24 iOS port (IOS_E2EE_STATUS.md notes the
iOS SPEC.md originally said 256 too, corrected in 922364f). The Android
side never got the same comment fix.
Manual now says 248 with the source-of-truth pointers, and computes
the entropy as 248^10 (a quick sanity check) so the next reader doesn't
trust the wrong number on either side.
Other Batch 2 claims verified clean:
- All 5 Android files in the 'Key Android files' list exist.
- All 2 Cloud Functions files in the 'Key Cloud Functions' list exist.
- Rate limit: 1h window, 10 max, 25h TTL on invite_attempts - all match
ACCEPT_RATE_LIMIT_WINDOW_MS / ACCEPT_RATE_LIMIT_MAX / ACCEPT_ATTEMPT_TTL_MS
in acceptInviteCallable.ts and the fieldOverrides entry in
firestore.indexes.json.
- Couples doc model fields (id, userIds, inviteCode, createdAt,
streakCount, lastAnsweredAt, currentQuestionId, activePackId,
encryptionVersion, wrappedCoupleKey, kdfSalt, kdfParams) all match
the create() payload in acceptInviteCallable.ts. createdAt uses
FieldValue.serverTimestamp() (manual says 'server-side' - correct).
- EncryptionVersion.STRICT = 2 in EncryptionVersion.kt.
The Three platform split table at the top of the manual said iOS
'E2EE cross-compatibility not yet implemented' even though the iOS
E2EE section below it (and IOS_E2EE_STATUS.md) clearly state it is
code-complete for the schemaVersion 2 (couple-key) daily-answer path.
The schemaVersion 3 sealed-answer path is the part that is
infrastructure-gated (paired-CI vector run + macOS end-to-end).
Replaced the row text with a one-liner that points to the existing
iOS E2EE gap sub-section so future readers don't get the wrong first
impression from the overview.
Batch 1 of the Phase 3 plan (Engineering_Reference_Manual_Plan.md).
Repository layout Android/iOS/Cloud Functions all verified against
the live source - no other drift in this batch.
After pushing the Phase 2 sync, evidence-first review against the live
repo caught:
- Repository layout (Android) was missing directories that have shipped
since v0.2.1: widget/ (Glance Today, R29), core/firebase/, core/media/,
data/backup/ (R24 E2EE backup + partner-assist), data/local/{converters,
entity,mapper} subdirs, data/security/, domain/usecase/ (resolver +
GameSessionManager + SoloAnswerMigrator), top-level notifications/
package, and ui/{recap,messages,questions}/ + components/ subdirs.
- Repository layout (iOS) was missing Crypto/Resources/ (wordlist) and
the Crypto/ design notes (SCHEMA_VERSION_DECISION.md, SPEC.md).
- User doc field list + per-collection enforcement were missing the 3
R20 notif preferences: notifDailyReminder, notifStreakReminder,
notifPromotional. Verified all 5 are mirrored by
FirestoreUserDataSource.updateNotificationPrefs() and listed in the
firestore.rules user-doc allowlist.
- One copy fix: 'The B6d split of onGameSessionUpdate' -> 'The B6c
split' (B6c did the part-finished split; B6d was the logger finish).
Anchors verified clean (30/30). DEVELOPMENT_LOG.md is gitignored so
the local review notes stay on this box.
- Cloud Functions: rewrite the module tree for the v2 migration (B0-B6d,
2026-07-08); add options.ts (global v2 setGlobalOptions, Cloud Run CPU
quota workaround), log.ts, the shared push/quietHours/idempotency/
pruneTokens/time infra under notifications/, releaseKey/, backup/,
the dates/onDate* triggers, couples/aggregateOutcomes, and the new
sendStreakReminder + sendThinkingOfYouCallable. Replace the single
onGamePartFinished with the four per-game part-finished triggers
shipped in B6c. Note the webhook is not deployed (RevenueCat project
not yet created; export commented out in functions/src/index.ts).
- Daily question lifecycle: replace the 'picks a random' description
with the new server-authoritative, mode-aware, deterministic picker
that mirrors the client's DailyModeResolver; add a Server-authoritative
sub-section with the frozen DOW -> mode map and the daily_fun_mc
exclusion. Note the couple-scan pagination + unseeded-pool skip.
- Billing: add the Purchases.logIn(firebaseAuth.currentUser!!.uid)
identity link (commit b99a8338) and the typed BillingException mapping.
Cross-link to the Webhook reliability section for the not-deployed state.
- iOS: fix the Repository layout iOS Crypto/ block (R24 E2EE code ships
in it; no longer 'intentionally empty'); correct the 'pairing from iOS
fails' claim (works for schemaVersion 2 path; schemaVersion 3 is
infrastructure-gated per IOS_E2EE_STATUS.md); correct the 'iOS couples
have no recovery path' claim (R24 batch 2 added iOS recovery phrase).
- TOC + anchors: add the new sub-anchors; fix three pre-existing broken
anchors (r10, ios-android-sealed-answer-bridge, recovery-phrase-change
desync). 30/30 anchors verified clean with a GFM slug checker.
- New landmines: BANNER-LIFE-001 (R30 game banner lifecycle; the B6c
per-game split means a new game also needs a per-game monitor hook)
and FUNCTIONS-V2-DEPLOY (2nd-gen deploy / CPU-quota / Eventarc
propagation pattern, the 'Changing from an HTTPS function to a
background triggered function' error and the launch-time quota
increase to restore 1 vCPU + concurrency 80).
- Engineering_Reference_Manual_Plan.md: add Phase 2 status entry.
- New PremiumUnlockOverlay.kt — one-time 'Premium unlocked' celebration for both partners on couple-shared Premium activation. Driven off CouplePremiumChecker (not the push) so it surfaces for both wherever they are. Gated by persisted premiumUnlockCelebrated flag, auto-reset on lapse.
- New illustration_premium_unlock.png asset for the overlay.
- AppNavigation hosts the overlay at root alongside MessageBubbleOverlay.
- SettingsDataStore: new premiumUnlockCelebrated flag + setter.
- ThisOrThatScreen: theme-token fixes for A/B options, mood chips, versus badge, progress, ChoicePromptBackdrop — all read from MaterialTheme.colorScheme. Bumps dark-mode legibility.
- ConversationScreen: bump PendingMediaChip retry/dismiss IconButtons to 48dp touch targets.
- PlayHubScreen / ActivityScreen / HomeScreen / SubscriptionScreen / OnboardingScreen / PairPromptScreen / PaywallScreen / LocalQuestionContent / OutcomeCheckInDialog / ChatComponents: assorted R13 polish.
- firestore.rules (n/a this batch), SettingsRepository, manual: doc + flag wiring.
- Manual: new C-DARK-UI-001 + C-ART-EDGE-002 landmines, Premium-unlock-modal pattern note.
null