# Plan Detail
Open any plan and you get the complete picture: what needs to happen, why it matters, what risks were identified, and how requirements connect to tasks. No more hunting through wikis or asking "where's the spec?" **One URL, complete planning context.**

{{< thumbcard src="/images/ui/plans/plan-detail-summary.png" alt="Plan detail page showing Summary tab" caption="Metrics, design rationale, constraints, and success criteria—all visible without scrolling" position="0 -120px" >}}

## What this page covers

- Plan header and navigation
- Five detail tabs: Summary, Document, Requirements, Tasks, Metadata
- Understanding plan structure
- Tracing requirements to tasks

## Plan header: instant orientation

Every plan detail page starts with the essentials:

- **Breadcrumb** — One click back to the plan list
- **Plan title** — What this plan accomplishes
- **Project badge** — Which project this plan belongs to
- **Requirements count** — Total requirements defined
- **Tasks count** — Total tasks generated

You always know where you are and how to get back.

## Summary tab: the executive view

This is your at-a-glance dashboard for the plan. Everything a stakeholder needs to understand scope and progress lives here.

### Metrics cards

Four cards summarize plan health:

| Card | What it shows |
|------|---------------|
| **Requirements** | Total requirements in the plan |
| **Tasks** | Total tasks generated from requirements |
| **Acceptance Criteria** | Total acceptance criteria across all tasks |
| **Completion %** | Circular progress showing how much is done |

Spot coverage gaps instantly. If Requirements > Tasks, some requirements may not have associated work.

### Plan description

The plan's **Idea** section rendered prominently—what this plan is trying to accomplish in clear prose.

### Design section

The structured thinking behind the plan:

- **Problem** — What pain point or gap this plan addresses
- **Approach** — How the plan proposes to solve it
- **Risks** — Identified risks with mitigations (e.g., `[R1] Risk description — Mitigation strategy`)

This is where the "why" lives. When someone asks "why did we do it this way?" the answer is here.

### Constraints and Success

Side-by-side sections that define boundaries and outcomes:

- **Constraints** — What must NOT change or be violated
- **Success** — What must be TRUE when the plan is complete

These become the acceptance criteria for the plan itself.

## Document tab: the full spec

{{< thumbcard src="/images/ui/plans/plan-detail-document.png" alt="Document tab showing rendered Markdown" caption="The complete plan as structured Markdown—copy, share, or reference" >}}

The Document tab renders the complete plan as Markdown:

- **Full structure** — Idea, Constraints, Success, Design, Requirements, Tasks
- **Copy button** — One click to copy the entire document
- **Shareable format** — Use for stakeholder reviews or external documentation

This is your **living specification**. When the plan is the source of truth, everyone reads the same document.

> [!TIP]
> **Export for reviews:** Click the copy button and paste into your team's review tool. The structured format makes async review efficient.

## Requirements tab: the spec decomposed

{{< thumbcard src="/images/ui/plans/plan-detail-requirements.png" alt="Requirements tab showing structured requirements" caption="Each requirement with ID, type, task count, and testable scenario" >}}

Requirements are the atomic units of your spec. Each requirement includes:

- **ID** — Unique identifier (`REQ-1`, `REQ-2`, etc.)
- **Type badge** — `functional` or `non-functional`
- **Task count** — How many tasks address this requirement
- **Title** — What must be true
- **Description** — Detailed explanation
- **Scenario** — Testable Given/When/Then format

### Why scenarios matter

Scenarios turn vague requirements into testable statements:

```
Scenario: Doc-Health-Functions
— GIVEN an exported function
— WHEN reviewing the source
— THEN a JSDoc block exists.
```

This format makes requirements **verifiable**. When the task is done, you can check if the scenario passes.

### Traceability

Each requirement shows how many tasks link to it. Click through to see which tasks are fulfilling which requirements—complete forward and backward traceability.

## Tasks tab: execution visibility

{{< thumbcard src="/images/ui/plans/plan-detail-tasks.png" alt="Tasks tab showing linked tasks with acceptance criteria" caption="Tasks with status, acceptance criteria progress, and linked requirements" >}}

The Tasks tab shows every task generated from this plan:

### Task cards

Each task displays:

- **Task key** — Click to open the full task detail
- **Type badge** — Task, Story, Bug, etc.
- **Title** — What needs to be done
- **Status badge** — Current workflow stage
- **Summary** — Brief description of the work

### Acceptance Criteria

Expandable section showing:

- Checklist items with completion state (green checks = done)
- Progress indicator (e.g., "5/5")
- Each criterion maps to plan success criteria

### Linked Requirements

Expandable section showing which requirements this task addresses:

- Requirement IDs as clickable chips
- Hover to see requirement titles
- Complete traceability from task back to spec

> [!NOTE]
> **Two-way linking:** Requirements link to tasks, and tasks link back to requirements. You can navigate the relationship from either direction.

## Metadata tab: plan properties

{{< thumbcard src="/images/ui/plans/plan-detail-metadata.png" alt="Metadata tab showing plan properties and danger zone" caption="Plan key, status, timestamps, and deletion controls" >}}

When you need plan properties at a glance:

### Plan Information

- **Plan Key** — Unique identifier for the plan
- **Status** — Draft, Approved, or Archived
- **Created** — When the plan was created
- **Updated** — Last modification timestamp
- **Schema Version** — Plan format version (for compatibility)

### Danger Zone

Plan deletion with clear warning:

> Deleting this plan will permanently remove it along with all associated tasks. This action cannot be undone.

The **Delete plan** button requires confirmation. Use this for cleanup or when a plan is superseded.

> [!NOTE]
> **Data retention (local-first):** Valdr stores plans, requirements, and linked tasks locally on your machine. Plans are retained as long as the underlying data exists. You can delete plans at any time to reduce workspace bloat or archive completed work.

## The result: plans that actually guide work

With Valdr plan details, you get:

- **Complete specification** — Idea, constraints, design, and requirements in one place
- **Requirements traceability** — Every requirement links to tasks; every task links to requirements
- **Living documentation** — The Document tab is always current, always shareable
- **Execution visibility** — See which tasks exist and their completion status

This is the difference between "planning documents" and **connected planning**.

## Next steps

- **[Plan List](../plan-list/)** — Browse all plans
- **[Planner](../../planner/)** — Create new plans with structured guidance
- **[Tasks](../../tasks/)** — See task execution in detail

**Open a plan now** and trace a requirement to its task. See how the spec stays connected to execution—no more "where's the doc for this?" questions.