[P0.13] `cf tasks delete` must not permanently strand dependents (implement cascade)

[frankbria]

Severity: high | Category: data-integrity | Phase: P0.13

Problem

Verified: tasks.delete does not remove the deleted id from other tasks' depends_on, and the delete_cascade() it points users to does not exist anywhere. A dependent keeps a depends_on entry pointing at a deleted task; get_ready_tasks requires deps.issubset(completed_tasks), so the dependent can never become ready — deleting a task silently and permanently strands its dependents.

Evidence

codeframe/cli/app.py:2262, codeframe/core/tasks.py:739 (dangling delete_cascade() reference)

Acceptance criteria

• Deleting a task strips its id from all dependents' depends_on (default or via --cascade), OR deletion is blocked/prompted when dependents exist.
• The dangling delete_cascade() docstring reference is resolved (implemented or removed).
• Test: after deleting a dependency, the former dependent is reachable/ready.

Dependencies

None

---

_{Filed from the SaaS launch-readiness audit. Atomic: one developer, one session. Work order: strictly P0.1 → P3.12 (no forward dependencies).}

[coderabbitai]

🔗 Related PRs

#688 - fix(core): release tasks.py DB connections on exception + retain fire-and-forget auto-close task (#650) [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!