What problem does it solve? Prevents two recurring schema mistakes in the Plover Electron app's SQLite store: referencing the vestigial calendar_event_id column left over from the removed calendar-sync feature, and misusing tasks.created_at or tasks.updated_at as a "task age" signal when both are silently invalidated by bulk subtask creation and progress-increment writes. ## Core Features & Use Cases - Vestigial Column Guidance: Explains why tasks.calendar_event_id still exists in store/db.ts, why it must not be referenced, and how to drop it properly with an ALTER TABLE tasks DROP COLUMN migration (SQLite >= 3.35) when already touching the tasks schema. - Timestamp Footgun Diagnosis: Details why Planner bulk-creates all subtasks with a shared created_at and why TasksRepo.incrementProgress() bumps updated_at on every call, creating a self-refreshing loop that breaks adaptive polling cadence. - Use Case: While building an adaptive polling cadence for InferenceEngine that polls faster for newly started tasks, use this Skill to learn that task age must be tracked in memory via a Map<taskId, timestampMs> of first-seen-in-progress timestamps rather than any persisted *_at column. ## Quick Start Ask the AI to review your changes to app/src/main/store/db.ts or your InferenceEngine polling logic and check them against the Plover store schema gotchas before referencing calendar_event_id or deriving task age from created_at or updated_at.
