docs: FEAT-13 — flush uploaded tracking rows from local DB (idea)

FEATURES.md

@@ -32,6 +32,7 @@ dedicated PLAN.md phase (or fold it into the relevant existing work) and mark it
 | FEAT-10 | `IDEA` | Home Assistant integration | unassigned |
 | FEAT-11 | `SHIPPED` | Hotspot SSID/password settings + 5GHz WiFi role swap | Phase 27 |
 | FEAT-12 | `SHIPPED` | Log OBD speed before GPS fix (rolling-start capture) | Phase 27 |
+| FEAT-13 | `IDEA` | Flush uploaded tracking rows from local DB | unassigned |
 
 ---
 
@@ -237,3 +238,21 @@ dedicated PLAN.md phase (or fold it into the relevant existing work) and mark it
   recomputed trips don't yet include the speed-only leading motion (follow-up if needed).
 
 
+### FEAT-13 — Flush uploaded tracking rows from local DB
+- **Status**: `IDEA`
+- **Area**: `modules/app_sql.py` (`tracking` table), `modules/app_upload.py`
+- **Phase**: unassigned
+- **What**: The local SQLite `tracking` table keeps every raw row forever — rows are only
+  marked `UPLOADED=1`, never deleted. Once rows are confirmed uploaded to the server, provide
+  a way to flush them locally (e.g. a settings toggle + retention window) so the local DB stays
+  bounded over years of driving.
+- **Considerations**:
+  - Trip summaries (`trips` table) are derived and can be kept independently; but the local
+    route-replay polyline is built from raw `tracking` rows, so purging rows removes local route
+    detail. The server keeps full `tracking_points`, so replay stays available on the portal.
+  - Must be opt-in and only delete rows that are `UPLOADED=1` (and older than a grace window)
+    so a failed upload or re-send never loses data.
+  - Tracking data is small (~90 B/row, ~a few MB/month) so this is long-term hygiene, not
+    urgent — imported dashcam videos are the real disk consumer.
+
+