TaskBlocker plumbing — model + cycle prevention + cascade-on-trash + computed cleared

[capo-the-ai-bot]

Parent: #181 (domain-modelling synthesis). See docs/proposals/blockers-and-contexts.md.

Status

Out of v1. Removed from Phase 1 milestone. The design below is captured; building it waits for more lived-experience signal — either the user hitting the use case in actual workflow, or external feedback that clarifies the right shape. Not blocked on engineering; blocked on requirements clarity.

When picked up, revisit the design against whatever new signal exists. The shape below is the starting point, not the locked-in answer.

Designed shape

v1-style plumbing for TaskBlocker — Task A blocks Task B until A is done.

• TaskBlocker entity: Task → Task FK pair (blocking_task_id, blocked_task_id).
• Cleared semantics is a live predicate, NOT a stored event:
  • cleared = blocking_task.done_at IS NOT NULL
  • Re-engages automatically if blocking task is un-done (done_at cleared).
  • No cleared_at column.
• Cycle prevention: enforced at create-time. Reject "A blocks B" if a path "B blocks ... blocks A" already exists. (Direct cycle and transitive — both rejected.)
• Cascade on trash:
  • When a blocking Task transitions to trashed, every dependent Task gets flagged for re-clarification (NOT auto-cleared — outcome may also be destined for trash; user decides per dependent).
  • Cascade does NOT fire on `someday` transition (outcome still wanted, dependents stay blocked as-is).
  • Cascade fires only on `trashed`.

Open questions to resolve before building

• Blocker-vs-Project framing. TaskBlocker chains can substitute for a Project entity. Until the user has dogfooded enough to settle which framing is right, the UX shape is uncertain — and the model should follow the UX, not the other way around.
• What's the consumer? Plumbing without a UX surface is dead weight. Need to know the surfacing story (status row chip? dependency graph view? something else?) before committing to schema.
• Re-clarification cascade integration. If/when this lands after Re-clarification surface — last_clarified_at predicate + Daily Planning review step #237 ships, cascade-on-trash needs to feed last_clarified_at on dependents — coordinate the wiring.

Out of scope (this issue)

• Backfill from legacy `blocked_by_todo_id` field — already removed in migration 0012.
• UI for visualising the dependency graph.

[capo-the-ai-bot]

Punting TaskBlocker entirely until a real driver emerges (someone hits the use case in actual usage and wants it). Reasoning:

• The Blocker concept is load-bearing for v1 via PersonBlocker, and PersonBlocker collapsed all the way down to TodoTag(type='person') with no separate entity (PersonBlocker (as TodoTag(type='person')) — schema + status row + Waiting List #235). Adding TaskBlocker as a separate table for a use case nobody is currently asking for is YAGNI.
• The TaskBlocker UX was already deferred from v1 (plumbing-only). Without a UX surface, the plumbing has no consumer — re-clarification surface (Re-clarification surface — last_clarified_at predicate + Daily Planning review step #237) can be specified without it.
• Cycle prevention, cascade-on-trash, computed-cleared semantics are all real design but only worth implementing when there's a user pulling.
• If someone (me or otherwise) eventually hits a workflow where 'Task A blocks Task B' is the right shape — and not better served by editing Task B's outcome description or NextAction cursor — we revisit then.

Proposal and #181 will be updated to reflect TaskBlocker is punted, not deferred.

[capo-the-ai-bot]

Reopening — I closed this in error. The intent is: TaskBlocker is out of v1 (removed from Phase 1 milestone), but it is planned. Holding for more user feedback and/or clarity on the requirements before refining and building. Not a 'never,' just 'not yet.'

The earlier closure comment overstated the case ('until someone really needs it' / 'YAGNI'). The actual position is: the design exists, the use case is real, but specifying it well needs more lived-experience signal first.