From 1477ee531045388de9e7e797200e5cd14e4a6d0e Mon Sep 17 00:00:00 2001 From: Peter Stone Date: Thu, 3 Sep 2026 02:34:25 +0000 Subject: Make the day's list a pull of committed work, not a push of everything unblocked due_date had been carrying two incompatible meanings: "this has a real deadline" (Bills, meds, a signup cutoff) and "this is when I intend to work on it." Chains leaned entirely on the second -- every step was stamped due_date = now the moment it unlocked -- so a five-minute call and a six-month certification both arrived looking overdue, and the only way to quiet them was to hand-reschedule. The list therefore always contained work that could not be finished that day, which made ending a day at zero impossible by construction rather than by effort. Splits the two apart: - due_date keeps only its real meaning: an externally-imposed deadline. - committed_date (new, migration 031) means "I chose this for today." Chain steps no longer get a due date on unlock (CreateChain, advanceChain, and the delete-promotion path), and are excluded from the undated list so they don't simply fall through to it instead. They reach the day only by being committed, via a "+ today" control on the chain card. Bucket-active items get the same control. BuildTimeline pulls in committed tasks, deduped against tasks already present for a different reason (committed and due-today are two reasons for one row, not two rows). Migration 031 also clears the auto-stamped due dates from open chain steps; completed steps keep theirs as historical record. Two supporting changes made while in here: - Extracted the native_tasks SELECT list into nativeTaskColumns. It had been copy-pasted into nine queries that must each agree exactly with scanNativeTasks' field order; adding committed_date meant editing all nine correctly or silently breaking whichever was missed. - Extracted templateFuncMap() and added TestTemplates_AllParse. New() only logs a warning when template parsing fails, so a malformed template shipped silently and surfaced as a broken page at runtime. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B --- migrations/031_task_commitment.sql | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 migrations/031_task_commitment.sql (limited to 'migrations') diff --git a/migrations/031_task_commitment.sql b/migrations/031_task_commitment.sql new file mode 100644 index 0000000..383695b --- /dev/null +++ b/migrations/031_task_commitment.sql @@ -0,0 +1,23 @@ +-- Splits the two jobs `due_date` had been doing at once. +-- +-- `due_date` had meant both "this has an externally-imposed deadline" (Bills, +-- meds, a signup cutoff) and "this is when I intend to work on it." Chains +-- leaned entirely on the second reading: every step was stamped due_date = now +-- the moment it unlocked, so a five-minute phone call and a six-month +-- certification both arrived looking overdue, and the only way to quiet them was +-- to hand-reschedule -- which is what had been happening. +-- +-- After this, due_date keeps only its first meaning, and committed_date carries +-- the second: "I chose to do this today." The day's list is then a pull of what +-- was committed plus genuine deadlines, rather than a push of everything not +-- blocked -- which is what makes finishing a day at zero possible at all. +ALTER TABLE native_tasks ADD COLUMN committed_date DATE; + +-- Chain steps were given their due date by the machinery described above, not by +-- any real deadline, so clear it on open steps. Completed steps keep theirs as +-- historical record. +UPDATE native_tasks +SET due_date = NULL +WHERE completed = 0 + AND chain_id IS NOT NULL + AND chain_id != ''; -- cgit v1.2.3