diff options
Diffstat (limited to 'migrations')
| -rw-r--r-- | migrations/031_task_commitment.sql | 23 |
1 files changed, 23 insertions, 0 deletions
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 != ''; |