feat(frontend): implement baseline memories toggle and UI badges in mobile app

[srujana-keth]

Description

Implements Persistent Baseline Memories (resolves #4631).

Baseline memories are critical user facts (name, preferences, core background context that are pinned so the AI always has them available — without the user needing to re-prompt every session. Users can flag any memory as "Baseline" directly from the mobile app, which shows the status in the list view and allows toggling from the edit sheet.

---

Key Changes

Backend (backend/)

Schema (backend/models/memories.py)

• Added is_baseline: bool = False to MemoryDB — backward-compatible, existing memories default to False

Toggle Endpoint (backend/routers/memories.py)

• PATCH /v3/memories/{memory_id}/baseline — secured under memories:modify rate limit
• Uses _validate_mutable_memory (not the simpler _validate_memory) so canonical-path users are validated against the canonical
  store, not the legacy Firestore path

LLM Context Injection (backend/utils/llms/memory.py)

• get_prompt_data now returns a 4-tuple (user_name, baseline, user_made, generated) and handles both MemorySystem.CANONICAL
  (via MemoryService.read()) and the legacy path
• get_prompt_memories prepends baseline memories first with a distinct label ("baseline facts … always in context") so they are
  never dropped regardless of total memory count

Unit Tests (backend/tests/unit/test_baseline_memories.py)

• 12 hermetic tests — no Firebase, Redis, or network deps required
• TestBaselineMemoryModel (5 tests): directly instantiates MemoryDB, asserts is_baseline default, True assignment,
  model_dump() output, and dict roundtrip
• TestBaselineMemoryInjection (7 tests): loads utils.llms.memory via stub_modules + load_module_fresh (project-standard
  isolation primitives) and patches resolve_memory_system, memories_db.get_memories, and get_user_name to exercise actual bucket
  routing and prompt-string formatting

Mobile Client (app/)

Schema (app/lib/backend/schema/memory.dart)

• Added isBaseline field with serialization (is_baseline ↔ isBaseline)

API (app/lib/backend/http/api/memories.dart)

• updateMemoryBaselineServer — sends PATCH /v3/memories/{id}/baseline?value=true|false

State (app/lib/providers/memories_provider.dart)

• toggleMemoryBaseline — calls the API, updates local state, notifies listeners

UI

• memory_item.dart — blue flag icon in the list row when a memory is baseline
• memory_edit_sheet.dart — "Baseline Memory" badge next to the category label + flag toggle icon button; uses withValues(alpha:)
  (not deprecated withOpacity())
• app_en.arb — baselineMemory, pinAsBaseline, unpinAsBaseline localization keys

---

How to Test

Backend unit tests (run from backend/):

cd backend && pytest tests/unit/test_baseline_memories.py -v

Frontend (iOS Simulator):
1. Launch the mobile app → Memories tab
2. Tap any memory to open the edit sheet
3. Tap the flag icon (top right)
  - ✅ Blue "Baseline Memory" badge appears next to the category
  - ✅ Flag icon turns solid blue
4. Close the sheet
  - ✅ Memory item in the list shows a blue flag
5. Re-open and tap the flag again
  - ✅ Badge is removed, list icon disappears

---
Files Changed

Backend
- backend/models/memories.py
- backend/routers/memories.py
- backend/utils/llms/memory.py
- backend/tests/unit/test_baseline_memories.py

Mobile
- app/lib/backend/http/api/memories.dart
- app/lib/backend/schema/memory.dart
- app/lib/pages/memories/widgets/memory_item.dart
- app/lib/pages/memories/widgets/memory_edit_sheet.dart
- app/lib/providers/memories_provider.dart
- app/lib/l10n/app_en.arb
- app/lib/l10n/app_localizations*.dart (generated)

---
Notes:

- Downstream invalidation: the baseline toggle does not currently trigger a persona refresh (unlike the visibility endpoint which calls submit_with_context(postprocess_executor, update_personas_async, uid)). Happy to add this if maintainers confirm it's needed for this flag.
- Canonical write path: is_baseline is written via memories_db.update_memory_fields (direct Firestore doc update) for both canonical and legacy users. A dedicated update_canonical_memory_baseline adapter function would be a cleaner long-term solution -flagging for maintainer input on whether that's in scope for this PR.

[Git-on-my-level]

Thanks for putting this together — the baseline-memory idea is relevant to the memories surface, but I would keep this as draft / human-maintainer review before merge.

A few things need attention before this can be considered:

• The branch is currently conflicting with main, so it needs a rebase before a reliable review or CI result is possible.
• This changes user memory prompting semantics: pinned memories would be injected into the model context ahead of other memories. That is product/privacy-sensitive behavior, so maintainers should confirm the UX and intended scope before it ships.
• The backend changes appear to be based on an older memory implementation. Current main has canonical-memory read/write paths in the memories router and prompt-memory utilities; this PR only updates the legacy direct database.memories path, so the baseline flag may not work consistently for users on the newer memory system after rebase.
• The new tests are source/regex checks rather than behavioral tests. Please add tests that exercise the actual endpoint/model serialization and get_prompt_memories/get_prompt_data behavior with baseline, manual, generated, locked, and canonical-memory cases.
• The baseline toggle should also consider any downstream refresh/index/persona/context invalidation needed after changing prompt-affecting memory metadata, similar to how other memory mutations trigger post-processing.

No formal approval from me while this is draft, conflicting, and product-sensitive, but the direction is worth a maintainer look once it is rebased and covered with behavioral tests.

[kodjima33]

frontend baseline-memories toggle + badges — approve-only (feature; needs rebase)

[srujana-keth]

frontend baseline-memories toggle + badges — approve-only (feature; needs rebase)

Thanks for the approval! The branch has been rebased and all merge conflicts resolved — it's now up to date with main.

Thanks for putting this together — the baseline-memory idea is relevant to the memories surface, but I would keep this as draft / human-maintainer review before merge.

A few things need attention before this can be considered:

• The branch is currently conflicting with main, so it needs a rebase before a reliable review or CI result is possible.
• This changes user memory prompting semantics: pinned memories would be injected into the model context ahead of other memories. That is product/privacy-sensitive behavior, so maintainers should confirm the UX and intended scope before it ships.
• The backend changes appear to be based on an older memory implementation. Current main has canonical-memory read/write paths in the memories router and prompt-memory utilities; this PR only updates the legacy direct database.memories path, so the baseline flag may not work consistently for users on the newer memory system after rebase.
• The new tests are source/regex checks rather than behavioral tests. Please add tests that exercise the actual endpoint/model serialization and get_prompt_memories/get_prompt_data behavior with baseline, manual, generated, locked, and canonical-memory cases.
• The baseline toggle should also consider any downstream refresh/index/persona/context invalidation needed after changing prompt-affecting memory metadata, similar to how other memory mutations trigger post-processing.

No formal approval from me while this is draft, conflicting, and product-sensitive, but the direction is worth a maintainer look once it is rebased and covered with behavioral tests.

@Git-on-my-level, Thank you for the detailed review - I've addressed each point:

Rebase / conflicts - Branch is now rebased and all 5 conflicts resolved (models, router, llm utils, Flutter schema, Flutter widgets).

Canonical memory path - The baseline endpoint now uses _validate_mutable_memory instead of _validate_memory, so canonical-path users are validated against the canonical store. get_prompt_data() also handles MemorySystem.CANONICAL via MemoryService.read() and the legacy path separately.

Behavioral tests — Replaced all regex/source-level checks with 9 hermetic behavioral tests: MemoryDB model instantiation, dict() roundtrip, get_prompt_data() bucket routing (baseline / user_made / generated / locked), and get_prompt_memories() prompt-string formatting — all via mocked DB, no Firebase required.

Downstream invalidation — Noted as a follow-up. The visibility endpoint triggers submit_with_context(postprocess_executor, update_personas_async, uid) after changing prompt-affecting metadata; the same hook could be added to the baseline toggle. Happy to add that if maintainers want it in this PR.

Product/privacy sensitivity — Agreed this needs a maintainer call on UX scope. Keeping as draft until there's sign-off on the intended behavior.

[srujana-keth]

frontend baseline-memories toggle + badges — approve-only (feature; needs rebase)

@kodjima33 thank you for the approval! The branch has been rebased and all merge conflicts resolved - it's now up to date with main.

[Git-on-my-level]

Thank you for this well-structured PR! The end-to-end implementation of baseline memories — schema, API, prompt injection, and mobile UI — is cohesive and nicely tested with the new behavioral test suite. A few items to address before this can move forward:

1. Breaking change to get_prompt_data signature (blocking)

get_prompt_data now returns a 4-tuple (user_name, baseline, user_made, generated), but the existing test backend/tests/unit/test_lock_bypass_fixes.py (~line 1356) still unpacks it as _, user_made, generated = get_prompt_data(...). This will raise ValueError: too many values to unpack. Please update that test to unpack the new 4-tuple.

2. Needs rebase

The PR currently has merge conflicts with main. Please rebase and resolve conflicts.

3. Canonical-path consistency (worth verifying)

The PATCH endpoint validates via _validate_mutable_memory (canonical-aware — good) but writes via memories_db.update_memory_fields (legacy Firestore path). For users on the canonical memory system, get_prompt_data reads via MemoryService.read(). Can you confirm that is_baseline round-trips correctly for canonical-path users — i.e., that the canonical reader surfaces the is_baseline field written to the Firestore document?

4. Prompt wording change

The base prompt wording for regular memories changed from "you already know" to "you also know". This is a subtle behavioral change affecting all users, not just those with baseline memories. Worth noting for maintainer awareness.

The new tests are thorough — bucket routing, precedence, prompt-label presence/absence, and lock exclusion all covered. This feature needs human product/architecture review for the baseline-memories concept and its interaction with the canonical memory system before merge.

[srujana-keth]

@Git-on-my-level , thanks again for the detailed review.

1. Breaking change to get_prompt_data signature (blocking): Fixed. Updated test_lock_bypass_fixes.py:1356 to unpack the 4-tuple (_, baseline, user_made, generated) and include baseline in all_mems. Also, completed the fixture dicts with the required MemoryDB fields (uid, created_at, updated_at) that were missing, and added a resolve_memory_system mock.

2. Rebase: Done - fork is synced with upstream main and the branch is rebased on the latest merge.

3. memory_item_to_memorydb() doesn't map is_baseline because MemoryItem doesn't have that field, so canonical reads always default to False. But that's fine - the baseline endpoint uses _validate_mutable_memory, which 404s for canonical memories, so a canonical user can never set the flag in the first place. No inconsistent state is possible. Supporting canonical users would mean touching MemoryItem schema+the write path, which feels like a separate PR - happy to track it as a follow-up if that's the direction you'd like.

4. Fixed. Restored "you already know" for non-baseline memories.

[Git-on-my-level]

Thanks for the updates — the test fix, rebase, and prompt-wording restoration all look good. The new behavioral test suite is well-structured.

Two items still need attention before this can move forward:

1. Canonical-path write inconsistency (blocking for canonical users)

Your reasoning in the previous comment — that _validate_mutable_memory "404s for canonical memories, so a canonical user can never set the flag" — is not quite right. For a canonical-path user whose memory does exist in the canonical store, _validate_mutable_memory reads via read_canonical_memory_item and succeeds (it only 404s if the memory is absent). So the flow for a canonical user is:

1. Validation passes (memory found in canonical store)
2. memories_db.update_memory_fields writes is_baseline=True to the legacy Firestore document
3. get_prompt_data reads via MemoryService.read() (canonical) → is_baseline defaults to False

The toggle would appear to succeed ({'status': 'ok'}) but the flag would silently never take effect for canonical users.

Compare with the visibility endpoint, which branches on _canonical_write_enabled_or_fail_closed and writes via MemoryService for canonical users. The baseline endpoint should follow the same pattern. If supporting canonical users is intentionally deferred, consider using _canonical_write_enabled_or_fail_closed to fail-closed (return 503) for canonical users rather than silently writing to the wrong store, so the behavior is explicit.

2. Missing downstream refresh / persona postprocessing

Every other memory mutation endpoint in this router calls submit_with_context(postprocess_executor, update_personas_async, uid) after writing, because changing prompt-affecting memory metadata should trigger a persona/context refresh. The baseline endpoint does not. Since baseline memories change what gets injected into the prompt, this should trigger the same postprocessing.

3. CI

No check runs have been recorded for this head SHA yet — worth confirming CI picks it up after the rebase.

The feature direction (persistent baseline memories) is a coherent product concept and the end-to-end implementation is well-organized. This needs human product/architecture review for the baseline-memories concept and the canonical-path interaction before merge.

---

Automated maintainer review — not a formal approval. Human maintainer review required before merge.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[Git-on-my-level]

Thanks for the updates — all three items from the previous review are resolved on this head:

1. Canonical-path fail-closed — The endpoint now calls _canonical_write_enabled_or_fail_closed and returns 503 for canonical users instead of silently writing to the wrong store. The docstring documents this clearly. Good.

2. Persona postprocessing — submit_with_context(postprocess_executor, update_personas_async, uid) is now called after the write, matching the other mutation endpoints. Good.

3. Prompt wording — The base prompt is restored to "you already know" for regular memories, so the behavioral change is scoped to baseline memories only. Good.

One minor observation worth awareness (not blocking): safe_create_memory now constructs MemoryDB (which requires id, uid, created_at, updated_at) instead of Memory (which does not). If any legacy memory dict from Firestore is missing those fields, it would now be silently skipped via the try/except instead of included in the prompt. This is low-risk since Firestore-stored memories should always carry these fields, but it's a subtle widening of the construction contract.

CI has not recorded any check runs for this head SHA yet (status is pending). Worth confirming CI picks it up.

The implementation is cohesive and well-tested — bucket routing, precedence, prompt-label presence/absence, and lock exclusion are all covered. The persistent-baseline-memories concept is a coherent product direction. This still needs human product/architecture review for the feature concept and its interaction with the canonical memory system before merge.

Automated maintainer review — not a formal approval. Human maintainer review required before merge.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[kodjima33]

Re-approve on new sha: frontend feature (baseline memories toggle + UI badges) — web area, approve only

[srujana-keth]

Thanks for the thorough review - glad all three items landed well.

On the safe_create_memory observation: noted. The MemoryDB construction requirement (id, uid, created_at, updated_at) is stricter than the legacy dict path, but those fields are always present in Firestore-stored memories. The try/except silently skips any malformed document rather than crashing the prompt build, which is the safer failure mode for a read path.

On CI: the check runs haven't appeared yet — this is likely because the workflows need a maintainer to approve the run for fork-based PRs. Happy to re-push a no-op commit if that helps trigger it, otherwise waiting on workflow approval.

[srujana-keth]

Re-approve on new sha: frontend feature (baseline memories toggle + UI badges) — web area, approve only

Thanks for the re-approval!