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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B

1 files changed, 10 insertions, 18 deletions

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
 }