null
/
Closer
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(manual): Batch 2 — correct auth providers and couples model (no anonymous, no migration field, Google SDK not Credential Manager)

This commit is contained in:
null 2026-06-28 11:04:15 -05:00
parent be710a0c9d
commit a6aa23eee2
2 changed files with 8 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Engineering_Reference_Manual_Plan.md
View File

@ -75,8 +75,8 @@ collection name, and architectural fact. Never assume.
| Batch | Status | Findings | Changes made |
|---|---|---|---|
| 1 | todo | | |
| 2 | todo | | |
| 1 | ✅ done | `core/feature/` note inaccurate (dir doesn't exist); `data/questions/` listed `QuestionDao` but it's in `data/local/` | Corrected `core/feature/` note; moved `QuestionDao` to `data/local/`; kept `QuestionJsonParser` in `data/questions/`; updated older-description note. |
| 2 | in progress | | |
| 3 | todo | | |
| 4 | todo | | |
| 5 | todo | | |

14
docs/Engineering_Reference_Manual.md
View File

@ -236,13 +236,12 @@ docs/ # This manual, QA notes, release prep, store assets
### Auth providers
Firebase Auth supports three sign-in paths:
Firebase Auth supports two sign-in paths:
1. **Anonymous** — used for the trial onboarding flow. The user can use the app without an account and is prompted to upgrade before any irreversible action.
2. **Email/password** — standard sign-up and login.
3. **Google Sign-In** — via Credential Manager on Android, the Google Sign-In SDK on iOS.
1. **Email/password** — standard sign-up and login.
2. **Google Sign-In** — via the legacy Google Sign-In SDK on Android (the app receives an `idToken` and calls `GoogleAuthProvider.getCredential(idToken, null)`), and the Google Sign-In SDK on iOS.
The Android `FirebaseAuthDataSource` exposes the standard Firebase upgrade paths; iOS uses the same Firebase Auth APIs through `AuthService.swift`. Anonymous accounts are linked to email/Google credentials when the user upgrades. If linking fails because the credential already exists, the app signs into the existing account.
The Android `FirebaseAuthDataSource` exposes the standard Firebase paths for email/password and Google credential sign-in; iOS uses the same Firebase Auth APIs through `AuthService.swift`. There is **no anonymous sign-in or account-linking flow** in the current Android or iOS source. Users sign in directly with email/password or Google.
### Pairing flow
@ -282,14 +281,13 @@ The `couples` document is **never** written by clients. Even legitimate field up
lastAnsweredAt: timestamp | null
currentQuestionId: string | null # server-controlled, read by clients
activePackId: string | null # server-controlled, read by clients
encryptionVersion: int # 0 plaintext, 1 migrating, 2 strict
encryptionVersion: int # 2 strict (all current couples)
wrappedCoupleKey: string | null
kdfSalt: string | null
kdfParams: string | null
encryptionMigrationUsers: map<string, bool>
```
`currentQuestionId` and `activePackId` exist as fields and are read by clients to display "today's question" state, but they are server-controlled — clients cannot write them.
`encryptionVersion` is stamped at `2` (`EncryptionVersion.STRICT`) on creation; there is no migration state in the current source. `encryptionMigrationUsers` is **not** a current field.
### Rate limiting on accept