docs(25.1): mark phase complete and update state

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: baotoq

.planning/ROADMAP.md

@@ -189,9 +189,10 @@ Plans:
 | 23. Configuration Screen | v3.0 | 1/1 | Complete | 2026-02-20 |
 | 24. Push Notifications | v3.0 | 3/3 | Complete | 2026-02-20 |
 | 25. Nuxt Deprecation | v3.0 | 1/1 | Complete | 2026-02-20 |
+| 25.1 Cross-Cutting Notification Handler Split | v3.0 | 1/1 | Complete | 2026-02-20 |
 
 ---
-*Roadmap updated: 2026-02-20 after Phase 25 completion -- v3.0 Flutter Mobile shipped*
+*Roadmap updated: 2026-02-20 after Phase 25.1 completion -- notification handler split*
 
 ### Phase 25.1: Cross-Cutting Notification Handler Split (INSERTED)
 
@@ -200,4 +201,4 @@ Plans:
 **Plans:** 1 plan
 
 Plans:
-- [ ] 25.1-01-PLAN.md — Enrich PurchaseCompletedEvent with running totals, split PurchaseCompletedHandler and PurchaseFailedHandler into per-channel INotificationHandler classes
+- [x] 25.1-01-PLAN.md — Enrich PurchaseCompletedEvent with running totals, split PurchaseCompletedHandler and PurchaseFailedHandler into per-channel INotificationHandler classes (completed 2026-02-20)

.planning/STATE.md

@@ -2,23 +2,23 @@
 
 **Project:** BTC Smart DCA Bot
 **Milestone:** v3.0 Flutter Mobile (SHIPPED)
-**Updated:** 2026-02-20 (25-01 complete -- v3.0 shipped)
+**Updated:** 2026-02-20 (25.1-01 complete -- notification handler split)
 
 ## Project Reference
 
 See: .planning/PROJECT.md (updated 2026-02-20)
 
 **Core value:** Reliably execute daily BTC spot purchases with smart dip-buying, validated by backtesting, monitored via mobile app
-**Current focus:** v3.0 complete -- all phases shipped
+**Current focus:** Phase 25.1 complete -- notification handler split
 
 ## Current Position
 
-Phase: 25 of 25 (Nuxt Deprecation)
-Plan: 01 of 01 complete (Phase 25 complete)
-Status: Complete -- v3.0 Flutter Mobile shipped
-Last activity: 2026-02-20 -- 25-01 complete: Removed Nuxt dashboard NodeApp resource from Aspire orchestration
+Phase: 25.1 (Cross-Cutting Notification Handler Split)
+Plan: 01 of 01 complete (Phase 25.1 complete)
+Status: Complete -- notification handlers split into per-channel implementations
+Last activity: 2026-02-20 -- 25.1-01 complete: Split PurchaseCompleted/PurchaseFailed handlers into Telegram and FCM, enriched PurchaseCompletedEvent with running totals
 
-Progress: [██████████] 100% (11/11 plans complete)
+Progress: [██████████] 100% (1/1 plans complete)
 
 ## Milestones Shipped
 
@@ -95,7 +95,7 @@ None.
 
 ### Roadmap Evolution
 
-- Phase 25.1 inserted after Phase 25: cross cutting concern with multiple INotificationHandler<PurchaseCompletedEvent> handlers instead, 1 handle telegram 1 handle firebase (URGENT)
+- Phase 25.1 inserted and completed after Phase 25: split monolithic notification handlers into per-channel INotificationHandler implementations
 
 ### Blockers/Concerns
 
@@ -104,8 +104,8 @@ None.
 ## Session Continuity
 
 Last session: 2026-02-20
-Stopped at: Phase 25.1 context gathered
-Next step: /gsd:plan-phase 25.1
+Stopped at: Phase 25.1 complete
+Next step: None -- all planned phases complete
 
 ---
-*State updated: 2026-02-20 after 25-01 completion -- v3.0 shipped*
+*State updated: 2026-02-20 after 25.1-01 completion -- notification handler split*

.planning/phases/25.1-cross-cutting-concern-with-multiple-inotificationhandler-purchasecompletedevent-handlers-1-handle-telegram-1-handle-firebase/.gitkeep

@@ -0,0 +1,50 @@
+# Phase 25.1, Plan 01: Summary
+
+**Completed:** 2026-02-20
+
+## What Changed
+
+Split monolithic PurchaseCompletedHandler and PurchaseFailedHandler into separate per-channel INotificationHandler implementations (Telegram and FCM), and enriched PurchaseCompletedEvent with pre-computed running totals so notification handlers no longer need database access for aggregate stats.
+
+## Files Modified
+
+| File | Change |
+|------|--------|
+| `TradingBot.ApiService/Application/Events/PurchaseCompletedEvent.cs` | Added Multiplier, IsDryRun, TotalBtc, TotalCost, PurchaseCount fields to the record |
+| `TradingBot.ApiService/Models/Purchase.cs` | Updated RecordFill and RecordDryRunFill to accept and forward running total parameters |
+| `TradingBot.ApiService/Application/Services/DcaExecutionService.cs` | Computes running totals from DB before calling RecordFill/RecordDryRunFill; adds current purchase values for non-dry-run fills |
+| `TradingBot.ApiService/Application/Handlers/PurchaseCompletedHandler.cs` | Replaced monolithic PurchaseCompletedHandler with TelegramPurchaseCompletedEventHandler + FcmPurchaseCompletedEventHandler |
+| `TradingBot.ApiService/Application/Handlers/PurchaseFailedHandler.cs` | Replaced monolithic PurchaseFailedHandler with TelegramPurchaseFailedEventHandler + FcmPurchaseFailedEventHandler |
+| `TradingBot.ApiService/Infrastructure/Telegram/ServiceCollectionExtensions.cs` | Updated MediatR assembly reference from deleted PurchaseCompletedHandler to TelegramPurchaseCompletedEventHandler |
+| `tests/.../PurchaseSpecsTests.cs` | Updated RecordFill/RecordDryRunFill call sites with running total parameters |
+
+## Architecture After
+
+```
+PurchaseCompletedEvent (enriched with running totals + Multiplier + IsDryRun)
+  -> TelegramPurchaseCompletedEventHandler  (DB + HyperliquidClient for verbose message)
+  -> FcmPurchaseCompletedEventHandler       (event data only, no DB access)
+
+PurchaseFailedEvent (unchanged)
+  -> TelegramPurchaseFailedEventHandler     (DB for verbose message)
+  -> FcmPurchaseFailedEventHandler          (event data only, no DB access)
+
+PurchaseSkippedEvent (unchanged, out of scope)
+  -> PurchaseSkippedHandler                 (Telegram-only, unchanged)
+```
+
+## Key Decisions
+
+- **Option A chosen for FCM handler data:** Added Multiplier and IsDryRun to PurchaseCompletedEvent so FcmPurchaseCompletedEventHandler needs zero DB access
+- **Running totals computed in DcaExecutionService:** Queried from DB before aggregate method calls; for non-dry-run fills, current purchase values are added to DB totals since the purchase is not yet committed
+- **Dry-run totals convention preserved:** Dry-run purchases pass through DB-only totals (not adding themselves) since they are excluded from running totals by convention
+- **BuildMultiplierReasoning stays as private static method** on TelegramPurchaseCompletedEventHandler -- only Telegram needs it
+- **Independent error isolation:** Each handler has its own try-catch; Telegram failure never blocks FCM and vice versa
+
+## Verification
+
+- Build: 0 errors
+- Tests: 62 passed, 0 failed
+- Old class names (PurchaseCompletedHandler, PurchaseFailedHandler): confirmed deleted
+- New class names: 4 handlers confirmed (1 definition each)
+- PurchaseSkippedHandler: unchanged