7.1 — Plan & sprints: step-by-step user guide

A walk-through-while-you-do-it guide for using VibeMap's sprint planner end-to-end. No prior experience assumed. If you're more interested in the technical reference (object shapes, API endpoints, gating logic), read 7.2 — API reference instead.

Audience: anyone using VibeMap to ship a project — solo builders, small teams, founders working with an AI coding assistant. Time to read end-to-end: 15 minutes. Time to do everything in here: 20–30 minutes for first-time setup, then 2 minutes per re-plan.

---

Table of contents

1. What this feature does
2. Before you start — the prerequisites checklist
3. The Development tab — orientation
4. Step-by-step: planning your first sprint set
5. Reading your sprint plan
6. Re-planning vs Re-analyzing — when to use each
7. The Track tab in sprint mode
8. The Dependency Badge & Side Sheet
9. How the AI agent picks work after planning
10. Common situations and how to handle them
11. Troubleshooting
12. FAQ
13. v1 limitations
14. Where to go next

---

1. What this feature does

Imagine you've just generated 60 acceptance criteria for your project — each one a small, shippable unit of work like "User can sign up via email" or "User can edit their profile."

Without sprints, those 60 ACs would all sit in one pile. Your AI coding agent would pick them in roughly the order they were created, which leads to two problems:

1. Out-of-order work. The agent might try "User can edit profile" before "User can sign up" exists. There's no User to edit, so the work fails and the AC ends up flagged blocked for an artificial reason.
2. No structural narrative. You can't see "OK we're 80% through Sprint 1 (auth) and Sprint 2 (billing) is queued next." It's just one undifferentiated mass.

This feature solves both:

• It runs an LLM over your ACs to derive dependency edges (e.g. "edit profile depends on sign up — needs the User entity").
• It then topologically sorts them and asks an LLM to bucket them into 3–15 thematic sprints (e.g. "Sprint 1: Auth & Sign-up", "Sprint 2: Sessions & Profile", "Sprint 3: Billing").
• The Track tab becomes sprint-aware — only the active sprint is expanded; past sprints collapse to a one-line summary; future sprints show as queued.
• The AI agent's MCP next-ready endpoint gates on: Bootstrap (Sprint 0) → active sprint → all hard dependencies satisfied. The agent literally cannot pick an out-of-order AC.

In a sentence: the planner gives you a meaningful project narrative AND prevents the agent from getting stuck on un-buildable work.

📸 Screenshot 1 — A fully-planned project's Plan tab. Capture the Plan tab on a project with 4-6 sprints + Backlog. Save as: screenshots/01-plan-tab-overview.png.

---

2. Before you start — the prerequisites checklist

Tick these in order. If any are missing, fix that one first — the rest won't work.

• A VibeMap Pro+ account. The dependency analyzer and sprint planner are Pro-only features (they call reasoning-tier LLMs). On free or starter plans, the "Plan Sprints" button returns a 403. Upgrade at Account → Billing if needed.
• A VibeMap project with features and acceptance criteria.
  • You should have at least one feature (and ideally several) generated, each with user stories under it, each with acceptance criteria under those.
  • If you haven't generated features yet, do that first — see Section 3.2 of the Getting Started guide.
  • Minimum recommended for a useful sprint plan: ~10 ACs across 2+ features. Below that, the plan is just one or two sprints with little structure.
• (Recommended) Bootstrap done first. If you want a Foundation step (sets up your codebase scaffold, applies overlays for auth/payments/etc.), do that before planning sprints. The Plan tab works without it, but the Track tab's "Sprint 0" slot won't be populated. See the Bootstrap docs.
• Acceptance criteria don't all need to be ready. The planner uses ACs in any status (draft, ready, passed, etc.) — it cares about which ACs exist, not which are approved. You'll approve them as you go after the plan exists.

If you're brand new and want the absolute minimum path: VibeMap Pro account → generate 2 features with 5 ACs each → upgrade to Pro → skip bootstrap → follow §4.

---

3. The Development tab — orientation

Open your project and click Development in the left sidebar. You'll see a tab strip near the top with four tabs:

┌─────────┬────────┬──────┬───────┐
│ Prepare │ Review │ Plan │ Track │
└─────────┴────────┴──────┴───────┘

Below that, a four-step progress strip mirrors the tabs and shows their state at a glance: "Prepare ● 4 pipelines · Review ● N pending · Plan ● N sprints · Track ● N items in progress."

Here's what each tab is for:

The relationship: Prepare runs first (optional), Review handles flagged items (optional), Plan is where you create/manage sprints, Track is where you watch the agent work. You don't have to do them in strict order — you can plan sprints without ever touching Prepare.

📸 Screenshot 2 — The four-tab strip and progress strip. Save as: screenshots/02-tab-strip.png.

---

4. Step-by-step: planning your first sprint set

Step 4.1 — Open the Plan tab

Click Plan in the tab strip. Or navigate directly to:

https://vibemap.ai/project/<your-project-id>/development?tab=plan

What you should see (first time, before any planning):

A centred card with:

• A heading "Plan your sprints"
• An explainer paragraph: "VibeMap analyses dependencies between your ACs and groups them into thematic sprints. The agent will then implement them in dependency-respecting order."
• A primary button: "Plan Sprints"

If instead you see a card saying "Generate features and approve acceptance criteria first", you're missing the AC prerequisites — go back to the Features tab and generate them.

📸 Screenshot 3 — The Plan tab empty state. Save as: screenshots/03-plan-empty-state.png.

Step 4.2 — Click "Plan Sprints"

Click the button. Two things happen behind the scenes:

1. The Dependency Graph Analyzer runs first. It fetches all your feature ACs, sends them to a reasoning-tier LLM (Gemini 3 Pro by default), and asks for pairwise dependency edges.
2. The Sprint Planner runs second. It topo-sorts the ACs using the hard edges, then asks a faster LLM (Gemini 3 Flash by default) to bucket the sorted list into 3–15 thematic sprints.

Expected duration:

• Small project (~10 ACs): 15-30 seconds.
• Medium project (~50 ACs): 60-90 seconds.
• Large project (~150 ACs): 2-3 minutes.

What you should see while it runs: the Plan Sprints button changes text to "Planning…" and is disabled. (The page does not show a progress bar in v1 — be patient.)

Step 4.3 — When it finishes

The page refreshes itself once the planner returns. You should now see:

• The empty-state card is gone.
• A status line near the top: "4 sprints · 0/47 ACs done" (numbers match your project).
• Two action buttons in the top right: "Re-plan" (primary outline) and "Re-analyze deps" (smaller, ghost-style).
• A vertical list of sprint sections, each showing:
  • A chevron (▸ or ▾) for collapse/expand
  • The label Sprint N: <Title> or Backlog: Backlog
  • On the right: <passed>/<total> done (or <count> unscheduled for Backlog)
  • The active sprint shows a blue header with an "ACTIVE" badge

📸 Screenshot 4 — Right after the first plan completes. Save as: screenshots/04-plan-complete.png.

By default, all sprint sections are collapsed. Click any chevron to expand it.

Step 4.4 — Verify the plan looks reasonable

A quick sanity check before moving on:

• The number of sprints is between 3 and 15. (Below ~25 ACs you usually get 3-4; above ~120 you hit the 15 cap and sprints get larger.)
• The first sprint's theme starts with the most foundational work (auth, accounts, core entities) — not something downstream like billing.
• The Backlog appears at the bottom (always positioned last). On a freshly planned project it's empty (0 ACs).
• Each sprint title is a short noun phrase (e.g. "Auth & Sign-up", "Billing & Subscriptions") — not a sentence, not generic ("Sprint 1").

If something looks off, jump to §6 to re-plan or re-analyze.

---

5. Reading your sprint plan

Expand a sprint by clicking its chevron. You'll see:

• A theme line under the title: a one-sentence rationale generated by the LLM (e.g. "Sign-up, sign-in, and password reset flows").
• A list of AC rows, each showing:
  • A status icon: ✓ (passed) or ◯ (any other status)
  • The AC title
  • On the right, possibly a dependency badge — a small ⊕ N · ⊖ M block:
    • ⊕ N = this AC has N prerequisites (things it depends on)
    • ⊖ M = this AC has M dependents (things that depend on it)
    • If neither is non-zero, no badge appears.
  • If the badge is red with ⚠ Blocked by N unpassed prereqs, this AC is currently un-pickable by the agent because at least one of its hard prereqs is not yet passed.

📸 Screenshot 5 — A sprint expanded with AC rows and dependency badges. Save as: screenshots/05-sprint-expanded.png.

What "active sprint" means

The active sprint is computed automatically — it's the first sprint by position that has at least one AC not yet passed. This is the sprint the AI agent will draw work from when it calls next-ready.

When you finish all ACs in the active sprint (mark them all passed), the next sprint becomes active automatically on your next page load. No manual flip needed.

What happens to the Backlog

The Backlog is always there, even if empty. It exists at position = 99999 (a sentinel — practically last forever). Its purpose:

• Catch new ACs added after sprint planning. If you go back to Features and approve another AC, it lands in Backlog by default until you re-plan or move it manually.
• Hold ACs you explicitly want to defer (manual move — see §13 for why this isn't UI-driven yet).

The Backlog can't be renamed, reordered, or deleted.

---

6. Re-planning vs Re-analyzing — when to use each

After a plan exists, you have two action buttons. Their behavior is different:

"Re-plan" (primary button)

Use when: sprint titles, themes, or groupings feel off but the underlying dependency graph looks fine.

Click flow:

1. Modal appears: "Re-plan sprints? This will replace your current sprint plan. Sprint titles, manual reordering, and theme assignments will be regenerated. AC statuses (passed/in_progress/etc.) and the dependency graph itself are preserved. Manual edits to sprint structure will be lost. [Cancel] [Re-plan]"
2. Click Re-plan. Only the Sprint Planner pipeline runs (~30s). The Dependency Graph Analyzer does not re-run.
3. Page refreshes; you have a new set of sprints with the same underlying edges.

Why this is faster: skipping the analyzer (the slow Gemini Pro call) cuts re-planning to ~30 seconds even on large projects.

"Re-analyze deps" (smaller ghost button)

Use when: you've added/edited/deleted ACs since the last plan, OR the dependency badges look wrong (e.g. an AC has ⊕ 0 prereqs but should clearly have one).

Click flow:

1. Modal appears: "Re-analyze dependencies? Re-analyzing dependencies regenerates the full dep graph by re-running the LLM analyzer. This invalidates the current sprint plan because edges may change. After re-analysis, sprints will be re-planned automatically. [Cancel] [Re-analyze]"

   Note: in v1, this button currently runs the same flow as Re-plan (planner-only). The full Re-analyze flow will land in a future iteration. If you need fresh edges, use the POST /api/projects/<id>/sprints/plan API directly for now, or click Re-plan after manually wiping ac_dependencies.

2. Re-analyzing takes longer (~60-180s) because it's both pipelines back to back.

What's preserved across re-plans

Practical advice: re-plan freely (cheap, safe). Re-analyze only when you've genuinely changed the AC set — every re-analyze costs more LLM tokens.

---

7. The Track tab in sprint mode

Click the Track tab. If you have a sprint plan, the layout changes from a flat 4-column kanban (the legacy view) to a Focus + Collapse layout identical in concept to the Plan tab — but each expanded sprint contains the full 4-column kanban filtered to just that sprint's ACs.

┌─────────────────────────────────────────────────────────────┐
│ TRACKER · 47 CRITERIA · ● Live                              │
├─────────────────────────────────────────────────────────────┤
│ ▸ ✓ Sprint 0 · Foundation — 9/9 done                        │  ← collapsed bootstrap
│ ▸ ✓ Sprint 1 · Auth & Sign-up — 5/5 done                    │
│ ▸ ✓ Sprint 2 · Sessions & Profile — 4/4 done                │
│ ▾ Sprint 3 · Billing — 3/6 done · ACTIVE                    │  ← expanded
│   ┌─────────┐ ┌────────────┐ ┌───────────┐ ┌──────────┐    │
│   │ Ready 1 │ │ In Prog 2  │ │ In Rev 0  │ │ Done 3   │    │
│   │  card   │ │  card card │ │           │ │ cards... │    │
│   └─────────┘ └────────────┘ └───────────┘ └──────────┘    │
│ ▸ Sprint 4 · Workspaces — 0/8 (8 queued)                    │
│ ▸ Sprint 5 · Settings — 0/4                                 │
│ ▸ Backlog — 3 unscheduled                                   │
└─────────────────────────────────────────────────────────────┘

Default expansion behavior

When you load the Track tab:

• The active sprint is expanded.
• The Foundation section (Sprint 0) is expanded if any bootstrap AC is non-passed, collapsed otherwise.
• All other sprints are collapsed (one-line summary only).

Click any chevron to override.

About the synthetic "Sprint 0"

Bootstrap ACs (the Foundation feature, marked kind = 'bootstrap') never receive a sprint_id in the database — they remain governed by the existing bootstrap gate. But for visual consistency, the Track tab renders them as a synthetic Sprint 0 section when sprints exist. The label shows "Foundation," the count tracks the bootstrap ACs' progress, and clicking expands the standard 4-column kanban filtered to those ACs.

If you don't have a bootstrap (you skipped it, or no overlays were proposed), this section simply doesn't appear.

KanbanCard with dependency indicator

Inside any expanded sprint section, each kanban card shows the same ⊕ N · ⊖ M dependency badge near the AC title. Click it to open the DependencySideSheet (see §8) — this works from both the Plan tab and the Track tab.

Backwards-compat — projects without a sprint plan

If you haven't planned sprints yet, the Track tab renders the legacy flat board (no sprint sections), with the original Foundation banner above it. Nothing changes for those projects. Once you plan sprints for the first time, the Focus + Collapse layout activates.

📸 Screenshot 6 — Track tab in sprint mode with active sprint expanded. Save as: screenshots/06-track-sprint-mode.png.

URL persistence

The expanded sprint state is reflected in the URL via ?sprint=<sprint_id>. If you bookmark or share a link with that param, the receiver lands on the same expanded sprint. Without the param, the URL defaults to active.

Composes with the dev tab params: ?tab=track&sprint=<id> works as expected.

---

8. The Dependency Badge & Side Sheet

Two small UI primitives surface dependencies inline.

The badge

Renders on every AC card (Plan tab list AND Track tab kanban cards) when dependencies exist:

Click the badge to open the DependencySideSheet.

The side sheet

A right-side drawer that opens when you click any badge. Two sections:

Prerequisites (depends on):

Required by (dependents):

Hard vs soft indicator: soft prereqs are tagged · soft next to their status. Hard prereqs have no extra tag (they're the default).

Reason text: appears on the Prerequisites side only — that's where the "why" is most useful (you're typically asking "why am I blocked?" not "why are they blocked by me?").

📸 Screenshot 7 — Dependency Side Sheet open on a blocked AC. Save as: screenshots/07-dep-side-sheet.png.

---

9. How the AI agent picks work after planning

This is the most important part for your day-to-day workflow. Once a sprint plan exists, the MCP next-ready endpoint (the function your AI agent calls when it wants more work) follows this logic:

1. Is there an unpassed bootstrap AC?
     → Yes: return the next bootstrap AC. Sprints don't matter yet.
     → No: continue.

2. Does this project have sprints?
     → No (legacy/un-planned): return the oldest ready feature AC. (Backwards compat.)
     → Yes: continue.

3. Compute the active sprint.
     → No active sprint (everything's passed): return null. The agent will tell you the project is complete.
     → Active sprint exists: continue.

4. Look at all `ready` ACs in the active sprint, ordered by (position, created_at).

5. For each candidate IN ORDER, check: are all its hard prereqs `passed`?
     → First candidate that passes all checks is returned to the agent.
     → If NO candidate passes, return null. (The agent gets nothing — see §10 for what that means.)

What this means in practice

When you're working with your AI agent, this gating becomes invisible — the agent just picks the right work, in the right order, every time. You'll never see "agent tried to implement X but it depends on Y" anymore.

When the active sprint completes, the agent will start receiving ACs from the next sprint automatically (no manual switch).

Realtime behavior

The agent calls next-ready once per work cycle (typically when starting a new piece of work). If you mark an AC as passed while the agent is working, the next next-ready call after that picks up the change. There's no realtime push — it's pull-based.

Bootstrap interaction

Bootstrap ACs continue to be served first (gated by the existing hasUnpassedBootstrapAC check). Sprints become relevant only after every bootstrap AC has reached passed. This means a fresh project with bootstrap will always run through Foundation → then Sprint 1 → Sprint 2 → ... in that order, regardless of how the planner organized the sprints.

📸 Screenshot 8 — Live agent working through a sprint, showing AC moving across kanban columns. Save as: screenshots/08-agent-working-sprint.png.

---

10. Common situations and how to handle them

"I clicked Plan Sprints but it just sits at 'Planning…'"

The pipelines run synchronously and can take 30s-3min depending on AC count. If it's been more than 5 minutes with no change, something likely failed silently. Check the browser console for errors and the server logs (Vercel function logs in production, dev server stdout locally) for "plan_failed" responses. Refresh the page — if the previous plan is gone but no new one exists, you can safely click Plan Sprints again.

"All my ACs are in the Backlog after planning"

This can happen if the analyzer returned no edges (so topo-sort produces a flat list and the planner has nothing to chunk meaningfully). It can also happen if your AC titles are too generic to derive dependencies from. Try:

• Make sure your AC titles include nouns (entity names) and verbs (actions) — "User can sign in" not "Authentication step 1."
• Click Re-plan (cheap retry).
• If still flat, click Re-analyze deps — sometimes the LLM produces a more useful graph on a second pass.

"The active sprint is wrong — it should be Sprint 3 but it's showing Sprint 1"

The active sprint = first sprint by position with any non-passed AC. If Sprint 1 still has ACs in draft or ready status, it's still active. To advance:

• Mark all of Sprint 1's ACs as passed (or move them to a later sprint via the API — UI for this isn't shipped in v1).
• The active sprint will recompute on next page load.

"I added a new AC to the project but it's not in any sprint"

Expected. New ACs land in the Backlog (sprint at position 99999) by default. To fold them into a real sprint, click Re-plan — the planner will redistribute them across sprints. Caveat: re-planning regenerates all sprint titles + themes (you'll lose any manual renames if you've added them via the API).

"The agent says 'no work available' but I have ready ACs"

Two likely causes:

1. All your ready ACs are in the Backlog (not in the active sprint). The Backlog is excluded from next-ready. Move them to an active sprint or re-plan.
2. All your ready ACs in the active sprint are blocked by unpassed prereqs. Check the Plan tab — any AC with a red ⚠ Blocked by N unpassed prereqs badge is in this state. Mark the prereqs as passed (or manually move the blocked AC to a sprint where its prereqs land earlier).

"I want to cancel a long-running plan"

Not currently supported in the UI. The pipeline runs synchronously in the route handler — if you close the browser tab, the LLM call still completes server-side and writes the result. To "cancel," let it finish, then click Re-plan to discard.

"I edited an AC's title — does the dep graph need re-analyzing?"

Yes if the title change materially changes its meaning (e.g. "User can sign in" → "Admin can audit logs"). The analyzer derives edges from titles + given/when/then text, so renaming only affects edges if the LLM would reach a different conclusion on re-read. For minor copy edits, the existing graph is fine.

---

11. Troubleshooting

"Plan Sprints" button returns 403

You're on free or starter. Upgrade to Pro at Account → Billing. The error JSON will say {"error": "plan_required", "required": "pro"}.

"Plan Sprints" button returns 404 (project_not_found)

The project ID in the URL doesn't belong to your account. Check you're on the right project, or sign in with the owning account.

Plan tab shows "Loading…" forever

The GET /api/projects/<id>/sprints call is failing or hanging. Open browser DevTools → Network → look for the request. If it's 401, your session expired (sign out + back in). If it's 500, check server logs for the underlying Postgres error.

Track tab shows the OLD flat board even though I have sprints

Hard-refresh (Cmd+Shift+R / Ctrl+Shift+R). The branched render reads summary.sprints.total > 0 from the development summary; a stale client bundle may not include the branch yet.

Dependency badges show on the Plan tab but not the Track tab

The Track tab's KanbanCard fetches dep counts via getTrackerInitialData (server action). If that fails silently, badges go missing. Check the Network tab for the page load — the development summary should include a sprints block with non-null counts.

"Cannot move 'Sprint 3: Billing' before 'Sprint 1: Auth' — depends on AC 'sign in'..."

You attempted a sprint reorder via API that violates a hard dependency. The API correctly rejects this. To do the move, first move the depended-on AC into a sprint with position <= the new position you want.

Agent gets stuck claiming the same AC repeatedly

This shouldn't happen — claim_criterion is atomic and the system has a 24-hour stuck-claim auto-revert. If you're seeing this, file a bug; it's not a sprint-feature issue.

---

12. FAQ

Q: Can I create a sprint manually? A: Not in v1. Only the planner creates sprints. To add structure, generate more ACs and re-plan.

Q: Can I delete a sprint? A: Yes via the API (DELETE /api/projects/<id>/sprints/<sprintId>), but only if it's empty. Move all its ACs out (or to Backlog) first. The Backlog itself can't be deleted.

Q: Can I rename a sprint? A: Yes via the API (PATCH /api/projects/<id>/sprints/<sprintId> with {title: "new name"}). UI for this isn't shipped in v1.

Q: Can I drag an AC between sprints? A: The move-ac API route exists and validates correctly, but no drag-and-drop UI invokes it in v1. To move an AC, hit the API directly: POST /api/projects/<id>/sprints/<destSprintId>/move-ac with body {ac_id: "..."}. The route enforces hard-dep constraints both directions.

Q: How does the planner decide sprint count? A: target = max(3, min(15, ceil(N / 8))) where N is your feature AC count. So 8 ACs = 3 sprints minimum, 80 ACs = 10 sprints, 200 ACs = 15 sprints (cap). Change the AC count to influence the sprint count.

Q: Can I make the planner give me 5 sprints when it wants 8? A: No per-project sizing config in v1. Workaround: delete or re-merge ACs to change N, then re-plan.

Q: What model does each pipeline use? A: Analyzer = MODEL_IDS.GEMINI_3_PRO (reasoning-tier). Planner = MODEL_IDS.GEMINI_3_FLASH (auto-tier). Pinned constants in lib/constants/ai-models.ts. Pro+ users can theoretically override per-call but no UI for that yet.

Q: How are bootstrap ACs handled? A: They're filtered out of both pipelines (features.kind = 'bootstrap' excluded). They never get a sprint_id. The Track tab renders them as a synthetic "Sprint 0" for visual consistency. The MCP next-ready endpoint serves them first via the existing bootstrap gate.

Q: What happens if the LLM produces a circular dependency? A: The cycle resolver runs after the analyzer LLM returns. It detects cycles via DFS and drops one edge per cycle deterministically (soft edges first; latest dependsOnAcCreatedAt as tiebreaker). The dropped edges are logged via console.warn server-side. No DB audit trail in v1.

Q: Does the planner respect existing AC order within a sprint? A: Yes — the planner cannot reorder ACs within a sprint relative to topo-sort. The LLM only chooses where to draw boundaries in the pre-ordered list. AC position within a sprint matches their topo-sort order.

Q: I deleted an AC after planning. What happens? A: The sprint count for that sprint decreases. The dep graph still references the deleted AC in any rows where it was the prereq or dependent (until you re-analyze). The MCP next-ready gate is unaffected because deleted ACs can't be in ready status.

Q: Can I see which ACs are in a specific sprint via the API? A: Yes, GET /api/projects/<id>/sprints returns both the sprint list and AC list bundled. Each AC carries sprint_id, dependency counts, and blockedByUnpassed flag.

Q: Does this work with my Kanban Tracker setup from §9? A: Yes — the Tracker is unchanged conceptually. The board layout adapts when sprints exist (Focus + Collapse), but every individual card behaves identically. Your IDE's MCP tools (claim, submit_for_review, block, etc.) need zero changes.

---

13. v1 limitations

Things this feature doesn't do today (by design — deferred to a future cycle):

• No drag-and-drop UI. Moving ACs between sprints, reordering sprints, or bulk-moving are API-only operations. The validation logic is correct on the backend; the frontend just doesn't expose it. (See §12 FAQ for the API endpoints.)
• No per-project sprint sizing config. Sprint count is formula-driven (max(3, min(15, ceil(N/8)))). No user override.
• No epics (two-level hierarchy). For projects above ~120 ACs, sprints get larger rather than more numerous.
• No ReactFlow DAG view of the dependency graph. Inline <DependencyBadge> and <DependencySideSheet> only. (You can fetch the full edge set via DB queries if you really need a graph view.)
• No user-authored dependency edges. Schema supports it (derivation_source = 'user_added'), but no UI to create them.
• No active-sprint manual override. The active sprint is computed (first non-passed). Pin-to-sprint isn't supported yet.
• No sprint dates / deadlines / capacity. Sprints are ordered, not time-bound.
• No PostHog telemetry for the analyzer/planner pipelines (deferred — the spec calls for dependency_graph.analyzed, sprint_planner.planned, dependency_graph.cycle_resolved events).
• No "true" Re-analyze button. The button shipped, but currently runs the same flow as Re-plan (planner-only). Full re-analyze flow is queued.
• derive-from-pages-subagent shape bug — unrelated to sprints; this is the issue that sometimes leaves pages.ui_states.<slot>.ac_ids = [] ACs surfaced in the Review tab. Not blocking; tracked in the dev-loop completeness backlog.

Most are small (button + route + LLM call); a few (DnD UI, graphical DAG view) are real product work and will land in future releases.

---

14. Where to go next

• Technical reference (object shapes, API, gating logic) → 7.2 — API reference
• Kanban tracker user guide → 6.1 — Step-by-step user guide
• Kanban tracker reference → 6.2 — API reference
• MCP server setup (so your AI agent can actually call next-ready) → 5.1 — MCP server overview
• Tips for better output → 8 — Tips and best practices