Increase max goals from 3 to 4

[kodjima33]

Summary

• Increases the maximum allowed goals from 3 to 4 across all layers
• Flutter mobile: GoalsWidget, ActionItemsPage
• Desktop Swift: GoalsWidget.swift
• Rust backend: fetch limit + auto-deactivation threshold
• Python backend: fetch limit + creation max
• Desktop layout uses flexible VStack — no sizing issues with 4 goals

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR bumps the maximum number of active goals from 3 to 4 across all layers of the Omi stack — Flutter mobile (UI guards and constant), Python backend (router limit and database default), Rust desktop backend (fetch limit and auto-deactivation threshold), and Swift desktop UI (button visibility conditions). The change is straightforward and well-propagated, with two minor oversights: a stale inline comment in GoalsWidget.swift and a missed default-parameter update in the Python database layer.

Key changes:

• Flutter _maxGoals constant and action_items_page.dart guard updated from 3 → 4
• Python router explicitly passes limit=4 and create_goal default updated, but get_user_goals default still reads limit: int = 3
• Rust firestore.rs auto-deactivation threshold and route fetch limit both updated to 4
• Swift GoalsWidget button-visibility conditions updated, but the accompanying inline comment was not

Issues found:

• backend/database/goals.py line 41: get_user_goals default parameter remains limit=3; any caller that omits the argument will silently receive at most 3 goals instead of 4
• desktop/Desktop/Sources/MainWindow/Components/GoalsWidget.swift line 42: comment still reads "only if less than 3 goals" after the condition was changed to < 4

Confidence Score: 4/5

• Safe to merge — the main code paths work correctly; the missed default parameter is a minor inconsistency that only affects callers that don't pass an explicit limit.
• All explicit call sites pass the correct limit of 4, so the user-facing functionality is correct end-to-end. The only real risk is a latent inconsistency in get_user_goals's default parameter, which could trip up future callers or background jobs. The stale comment is purely cosmetic.
• backend/database/goals.py — default limit parameter on get_user_goals should be updated to 4 to stay consistent with all other changes in this PR.

Important Files Changed

Filename	Overview
backend/database/goals.py	Updated create_goal default max to 4, but get_user_goals still defaults to limit=3 — any caller without an explicit limit will silently cap at 3 goals.
desktop/Desktop/Sources/MainWindow/Components/GoalsWidget.swift	Both < 4 conditions updated correctly; stale inline comment on line 42 still reads "only if less than 3 goals".
backend/routers/goals.py	Docstring and explicit limit=4 argument both updated; endpoint correctly fetches up to 4 goals.
desktop/Backend-Rust/src/services/firestore.rs	Auto-deactivation threshold bumped from >= 3 to >= 4; logic remains sound — a 5th creation deactivates the oldest and keeps the total at 4.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["User taps Add/Generate Goal\n(Flutter/Swift UI)"] --> B{"goals.length < 4?"}
    B -- No --> C["Button hidden — limit reached"]
    B -- Yes --> D["Show Add/AI Goal Button"]
    D --> E["POST /v1/goals (Python or Rust backend)"]
    E --> F{"Active goal count >= 4?"}
    F -- Yes --> G["Deactivate oldest goal"]
    G --> H["Create new goal in Firestore"]
    F -- No --> H
    H --> I["GET /v1/goals/all (limit=4)"]
    I --> J["Return up to 4 active goals"]
    J --> K["UI refreshes — displays ≤ 4 goals"]

Loading

Comments Outside Diff (1)

1. backend/database/goals.py, line 41 (link)

   Default limit parameter not updated to 4

   The get_user_goals function still defaults to limit: int = 3, while every other part of this PR was updated to 4. The router explicitly passes limit=4, so the main endpoint works correctly — but any other caller that invokes get_user_goals(uid) without an explicit limit will silently receive at most 3 goals, which would be an off-by-one inconsistency after this change. For example, an LLM processing pipeline or a background job that calls this function without an explicit limit would still cap at 3.

_{Last reviewed commit: "Increase Python back..."}

[greptile-apps]

Stale comment still references old limit of 3

The comment on line 42 says only if less than 3 goals but the condition was updated to goals.count < 4. The comment is now misleading.

Suggested change

	// Add goal button (only if less than 3 goals)
	// Add goal button (only if less than 4 goals)