Risks & dependencies

PMs in the wild work from a RAID log (Risks, Assumptions, Issues, Dependencies). sprintrr has the two pieces that pay back fastest: a risk register with a standard 5×5 matrix, and task dependencies so the plan can express what blocks what.

Risk register

Open a project, switch to the Risks tab.

• 5×5 matrix — severity (1 trivial → 5 catastrophic) × probability (1 rare → 5 almost certain). Standard PRINCE2 / PMI shape. Each cell counts the open risks with that score (severity × probability, 1–25). Exposure is low (≤ 6), medium (7–14) or high (≥ 15), and each has its own mark — a dot, a diamond, a red square — so it reads without colour; the score is always printed. Click a cell to filter the list to it.
• Exposure summary — beside the matrix: how many open risks are high, medium and low (each one filters the list), plus the three with the highest exposure. Click one to open it.
• Status — open / mitigated / accepted / closed. Each row has Mark closed (undo from the toast); edit and delete sit behind the ⋯ menu.
• Owner + mitigation plan — assign a team member, write down what you'll do. Both optional but encouraged.
• Source provenance — every risk records where it came from (manual, status_update, transcript, ai_detected). Auto-flagged risks are clearly labelled so editors know they need a human pass.

Auto-flagging from status updates

A status update with blockers shows a small + Track N blockers as risks button under its blockers section, on the draft and after you publish. One click drops them into the register with source='status_update' and a link back to the source update. Tune severity / probability after.

Auto-flagging from transcripts

The Paste a call transcript window shows the risks it heard in a separate Risks flagged list. Click Track N risks in the register to add them with source='transcript'. The AI sets severity/probability to 3/3 (medium); adjust afterwards.

Task dependencies

Open a task and scroll to Dependencies:

• Blocked by… — tasks that must finish before this one can start.
• Blocks… — tasks that wait on this one.

v1 supports finish_to_start (the most common type). The schema stores a type field that accepts start_to_start, finish_to_finish, and start_to_finish too — those will surface in the UI in a later polish pass.

Guard rails

• A task cannot depend on itself (DB CHECK).
• The trivial 2-cycle (A blocks B AND B blocks A) is rejected at insert time by a trigger.
• Longer cycles are caught before saving: sprintrr walks the dependency graph (up to 200 tasks) and refuses an edge that would close a loop.
• Cross-project dependencies are rejected — both tasks must live in the same project.

Gantt visibility

The Gantt view shows one line at the top: "N dependencies · N tasks wait on another. Open a task to see what blocks it and what it blocks." Arrows between the Gantt bars are on the roadmap.

MCP usage

Both risks and dependencies are exposed via the MCP server for Claude Desktop / Cursor:

# List risks for a project
GET /api/mcp/projects/<id>/risks

# Create a single risk
POST /api/mcp/projects/<id>/risks
{ "title": "...", "severity": 4, "probability": 3, "source": "manual" }

# Bulk create (e.g. from an AI batch)
POST /api/mcp/projects/<id>/risks
{ "source": "ai_detected", "risks": [{"title": "..."}, ...] }

# Update / close
PUT /api/mcp/risks/<id>
{ "status": "closed" }

# Delete
DELETE /api/mcp/risks/<id>

# Dependencies (per task)
GET /api/mcp/tasks/<id>/dependencies
POST /api/mcp/tasks/<id>/dependencies
{ "direction": "blocks", "otherTaskId": "<uuid>", "type": "finish_to_start" }

# Remove an edge
DELETE /api/mcp/dependencies/<id>

Requires read:risks / write:risks for risks, and read:tasks / write:tasks for dependencies. Both scopes are in the default key permissions for new MCP keys.

Compliance

• Risks and dependencies are visible only to people who can see the project — its owner, or the team it belongs to.
• Every risk and dependency change is recorded in the activity feed (risk_created, risk_closed, dependency_added, …) and the audit log (RISK_CREATED, DEPENDENCY_REMOVED, …).

Roadmap

• Arrows on the Gantt between dependent task bars.
• Critical-path highlight based on dependencies + estimated hours.
• Date-cascade respects dependencies — extending the shift_project_dates RPC so cascading a milestone date forward propagates through dependency edges, not just calendar order.
• Assumptions + Issues entities to round out the full RAID log.