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 --- internal/store/chains.go | 28 ++++++++++------------------ 1 file changed, 10 insertions(+), 18 deletions(-) (limited to 'internal/store/chains.go') diff --git a/internal/store/chains.go b/internal/store/chains.go index f854678..423d7f3 100644 --- a/internal/store/chains.go +++ b/internal/store/chains.go @@ -3,7 +3,6 @@ package store import ( "database/sql" "fmt" - "time" "task-dashboard/internal/config" "task-dashboard/internal/models" @@ -17,7 +16,8 @@ const defaultChainProjectColor = "#8B5CF6" // CreateChain creates a backing project (per the design's "a chain is // effectively a project with strict sequential unlocking"), a task_chains // row, and one native_tasks row per entry in tasks. Position 0 is created -// unlocked with due_date = now; the rest are locked with no due date. All +// unlocked; the rest are locked. No step carries a due date -- a chain step is +// a milestone, not a deadline (see migration 031). All // in one transaction so a partial chain never exists. func (s *Store) CreateChain(name string, tasks []models.ChainTaskInput) (*models.Chain, error) { if len(tasks) == 0 { @@ -46,18 +46,14 @@ func (s *Store) CreateChain(name string, tasks []models.ChainTaskInput) (*models for i, t := range tasks { unlocked := i == 0 - var dueDate *time.Time - if unlocked { - dueDate = &now - } priority := t.Priority if priority == 0 { priority = 1 } if _, err := tx.Exec(` - INSERT INTO native_tasks (id, content, description, project_name, project_id, priority, due_date, chain_id, chain_position, chain_unlocked, created_at, updated_at) - VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) - `, newTaskID(), t.Content, t.Description, project.Name, project.ID, priority, dueDate, chainID, i, unlocked, now, now); err != nil { + INSERT INTO native_tasks (id, content, description, project_name, project_id, priority, chain_id, chain_position, chain_unlocked, created_at, updated_at) + VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) + `, newTaskID(), t.Content, t.Description, project.Name, project.ID, priority, chainID, i, unlocked, now, now); err != nil { return nil, err } } @@ -113,10 +109,7 @@ func (s *Store) GetChains() ([]models.Chain, error) { // ordered by chain_position -- the full checklist view. func (s *Store) GetChainTasks(chainID string) ([]models.Task, error) { rows, err := s.db.Query(` - SELECT id, content, description, project_name, project_id, due_date, priority, completed, labels, created_at, - recurrence_freq, recurrence_interval, recurrence_weekdays, recurrence_series_id, next_occurrence_override, estimated_minutes, - chain_id, chain_position, chain_unlocked, - bucket_id, bucket_state, bucket_last_active_at + SELECT `+nativeTaskColumns+` FROM native_tasks WHERE chain_id = ? ORDER BY chain_position ASC @@ -185,8 +178,8 @@ func (s *Store) maxCompletedChainPosition(chainID string) (*int, error) { // task has a chain_id set and the chain isn't paused) and from // SetChainStatus's resume catch-up. Idempotent: if the successor position // is already unlocked, it's left untouched (so a resume catch-up run -// against a chain that was never actually stuck is a no-op, not a -// due_date-resetting re-unlock). Completing/catching-up-to the last +// against a chain that was never actually stuck is a no-op rather than a +// redundant re-unlock). Completing/catching-up-to the last // position marks the chain completed instead of unlocking a successor. func (s *Store) advanceChain(chainID string, completedPosition int) error { var successorID string @@ -205,9 +198,8 @@ func (s *Store) advanceChain(chainID string, completedPosition int) error { return nil } - now := config.Now() _, err = s.db.Exec(` - UPDATE native_tasks SET chain_unlocked = 1, due_date = ?, updated_at = ? WHERE id = ? - `, now, now, successorID) + UPDATE native_tasks SET chain_unlocked = 1, updated_at = ? WHERE id = ? + `, config.Now(), successorID) return err } -- cgit v1.2.3