Skip to main content

​
March 6th, 2026

Waivers, Offline Parity, and Surgical Deletion Following yesterday’s architectural work, today we focused on expanding waiver configuration, ensuring offline DB parity, and refining how tasks are deleted.

​
1. Penalty Waiver Capabilities

We expanded the “escape hatch” mechanisms for commitments:
  • Waiver Options: Implemented waiver deadlines configurations (5h, 10h, 24h, 2d).
  • Early Waivers: Added an “Allow Early Waiver” toggle, permitting users to attempt the assigned “survival challenge” (e.g., CAPTCHA) prior to actually failing the commitment.
  • Schema Parity: Synchronized the TaskDraft store to match the backend PenaltyWaiverSchema, standardizing discriminators (captcha | paragraph).

​
2. Comprehensive SQLite Synchronization

We pushed the accountability data down into the local cache to ensure offline resilience and accurate native scheduler calculations:
  • Migration 7 -> 8: Added penalty_json and conditions_json columns to the local SQLite database. Wrapped legacy schema mutations in try-catches to squash “duplicate column” bugs on fresh installs.
  • 1:1 Parity: The local repository now faithfully mirrors Convex penalty snapshots, guaranteeing the app knows the exact consequences even offline.

​
3. Surgical Task Deletion (The “Orphan” Instance)

We refined how task series are deleted to protect user history and completed habits:
  • Targeted Removal: Refactored the deleteTask logic. We now use a temporary Foreign Key bypass (PRAGMA foreign_keys = OFF) to destroy the parent task definition while orphaning and preserving any manually edited/completed instances underneath it.
  • Migration 8 -> 9: Synced is_manual_edit status to local storage across bulk sync and individual update paths.
  • DB Debug UI: Built specific visual treatments in our internal DB Inspector to detect and display these “Preserved Instances” accurately.