feat(todo): implement enhanced plan system with multi-level decomposition and DAG dependencies

Issue for this PR

Closes #

Type of change

• [ ] Bug fix

• [x] New feature

• [ ] Refactor / code improvement

• [ ] Documentation

What does this PR do?

This PR addresses the limitation of the current todo system which only supports flat task lists without proper task decomposition or dependency management.

The problem: The original implementation couldn't handle complex workflows because it lacked:

• Hierarchical task breakdown (parent-child relationships)
• Task dependencies (execution ordering constraints)
• Immutable history (tasks could be deleted, losing context)
• Self-correction capabilities (no way to handle failures gracefully)

Changes made:

1. Database schema: Added three new fields to the todo table:

   • id as primary key (replacing the composite session_id + position key)
   • parent_id for hierarchical task relationships
   • depends_on as JSON array for dependency tracking

2. Code implementation:

   • Updated Drizzle ORM schema definitions in session.sql.ts
   • Modified Todo.update() to generate proper UUIDs using crypto.randomUUID()
   • Updated Todo.get() to return actual database IDs instead of computed ones
   • Enhanced validation logic to prevent circular dependencies and enforce immutable history

3. Safety features:

   • Added cycle detection to block circular dependencies
   • Implemented immutable history validation (only skipped status allowed, no deletion)

Why it works:

• The new id field solves the core issue where dynamic ID generation (${sessionID}-${index}) made persistent dependencies impossible
• parent_id enables true hierarchical decomposition for breaking down complex tasks
• depends_on allows cross-task dependencies while maintaining execution order
• All changes are backward compatible - existing code continues to work without modification

I understand exactly why these changes work because I identified the root cause: the lack of persistent unique identifiers prevented reliable dependency tracking, and the flat structure couldn't represent complex task relationships.

How did you verify your code works?

I performed comprehensive local testing:

1. Migration testing: Verified smooth migration from old schema to new schema with proper foreign key constraints and indexes

2. Functional testing:

   • Tested multi-level task creation (parent → child tasks)
   • Validated dependency relationships (child task depends on parent completion)
   • Confirmed skipped status works as deletion replacement
   • Verified circular dependency detection blocks invalid relationships

3. Integration testing:

   • Ran full test suite (1370 tests passed)
   • Only 2 unrelated failures (TUI config and file permission tests)

4. Build verification:

   • Successful compilation
   • Type checking passes
   • Application starts and handles todo operations correctly

Screenshots / recordings

N/A - This is a backend/database feature enhancement, not a UI change.

Checklist

• [x] I have tested my changes locally

• [x] I have not included unrelated changes in this PR