Fixes #0: add TFT coach mode with manual patch snapshot

[peterw]

1. Group chat announcement
   We added a new TFT Coach mode in Clicky. Before this, Clicky answered in a general way and did not carry a dedicated TFT patch snapshot. Now, when users switch to TFT Coach, Clicky uses a maintained TFT patch/meta snapshot in every reply so in-game advice is more relevant and less generic.

2. Customer message
   We shipped a TFT Coach mode in Clicky. You can switch to it in the panel and ask for board/shop/item help directly. It now uses a maintained TFT patch snapshot for more relevant coaching, while still prioritizing what’s on your live screen.

3. QA checklist

• Open panel and confirm Mode toggle shows General and TFT Coach.
• Switch to TFT Coach and confirm snapshot status text appears.
• Hold Control+Option, ask a TFT question, and confirm response uses TFT framing + still includes [POINT:...] behavior when relevant.
• Switch back to General and confirm normal non-TFT behavior.
• Run python3 scripts/update_tft_meta_snapshot.py and confirm TFTMetaContext.swift snapshot block updates.

4. QA links

• https://www.clicky.so/
• https://teamfighttactics.leagueoflegends.com/en-ph/news/game-updates/teamfight-tactics-patch-16-8/

4.5) BLAST RADIUS

• Main blast radius is response quality in companion mode prompts.
• If broken, users still can talk to Clicky, but TFT advice could be stale or too generic.
• No auth/payment/data migration surface changed.

5. Why this works
   Before: the app had one generic prompt path. It had no TFT mode and no dedicated patch context, so TFT guidance was generic.
   Now: a user-selectable assistant mode injects TFT-specific instructions and a hardcoded patch snapshot into the Claude system prompt. The model gets explicit TFT context every request and stays anchored to current screen state.
   Root cause: missing domain mode + missing TFT context source.

6. Key concepts

• Prompt conditioning: behavior changes via system prompt append based on selected mode.
• Manual snapshot strategy: patch/meta context is intentionally local and updated by script, avoiding runtime dependency on live endpoints.
• UX visibility: mode + snapshot status is visible in panel to reduce ambiguity.

7. Old vs new response
   Old (general mode behavior):

• “looks like you can roll a bit and stabilize. [POINT:... ]”

New (TFT Coach mode behavior):

• “given this patch snapshot and your current board, prioritize stabilizing with strongest board now, then push levels on tempo; slam immediate frontline value here. [POINT:... ]”

8. Prompts used

• “can we make this into a helper for tft?”
• “how do we have info about the most up to date meta of tft (league) ?”
• “lets try it get it working”
• “we dont need worker endpoint just hard code it all for now and we'll manually run script ot update when new patch comes out”

9. Restate the issue
   Clicky lacked a TFT-specific coaching mode with patch-aware context; this PR adds one with a manual snapshot workflow.

10. UI simplification note
    UI stayed minimal: one segmented Mode control and one status line. No additional complex settings were added.

11. Live page proof

• Production surface: macOS menu bar panel (not a web route).
• Files changed on live surface: CompanionPanelView.swift, CompanionManager.swift, TFTMetaContext.swift.
• Code path: app launch -> MenuBarPanelManager -> CompanionPanelView -> mode selection -> prompt assembly in CompanionManager.

12. safe to ship? what's the worst thing that could happen?
    Safe to ship for a controlled feature increment.
    Worst case: stale/manual snapshot leads to suboptimal TFT advice quality, but core app behavior remains functional and reversible by switching back to General mode.

[qodo-ai-reviewer]

Hi, Switching between General and TFT Coach does not clear or segment conversationHistory, so subsequent calls to Claude include prior exchanges from a different mode, producing inconsistent behavior (e.g., TFT Coach influenced by prior General chat).

Severity: remediation recommended | Category: correctness

How to fix: Reset or segment history per mode

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

Switching selectedAssistantMode keeps using the same conversationHistory, so Claude requests in a new mode include previous-mode turns.

Issue Context

historyForAPI is always built from conversationHistory, and setSelectedAssistantMode does not clear or segregate it.

Fix Focus Areas

• leanring-buddy/CompanionManager.swift[143-150]
• leanring-buddy/CompanionManager.swift[653-688]

Suggested approaches (pick one)

• Clear history on mode change: in setSelectedAssistantMode, if mode != selectedAssistantMode (old value), conversationHistory.removeAll().
• Per-mode history: store history as [(mode: CompanionAssistantMode, userTranscript: String, assistantResponse: String)] and filter historyForAPI by current mode.
• Separate histories: maintain conversationHistoryByMode: [CompanionAssistantMode: [(...)]] and use current mode key.

Also consider skipping analytics capture when re-selecting the already-selected mode.

---

Found by Qodo code review