Planning pipeline

Overview

The planning pipeline converts raw source context into an operator-reviewable plan before any code execution begins. Each stage is invoked separately — the operator can inspect and edit output between stages.

Stage 1: from-issue

Derives a structured problem definition from the GitHub issue linked to the Work item. No LLM call — this is a template-based transform.

POST /api/cases/:id/planning/from-issue

Reads: issue.md, acceptance-criteria.md, reproduction-steps.md
Writes: problem-definition.md

# Problem Definition

## Overview
Case: <id>
GitHub Issue: owner/repo#<n>

## Issue Body
...

## Acceptance Criteria
...

## Reproduction Steps
...

If no GitHub issue is linked, this endpoint returns 422. For manual Work items, write problem-definition.md directly.

Stage 2: hypotheses

Reads problem-definition.md and uses an LLM to generate a ranked list of hypotheses about the root cause.

POST /api/cases/:id/planning/hypotheses-file

Reads: problem-definition.md
Writes: hypotheses.md

# Hypotheses

## H1 — Most likely: JWT expiry boundary condition
...

## H2 — Possible: Connection pool saturation
...

Stage 3: tasks

Reads both hypotheses.md and problem-definition.md and generates a task list the session will execute in Work mode.

POST /api/cases/:id/planning/generate-tasks

Reads: hypotheses.md, problem-definition.md
Writes: tasks.md

# Tasks

- [ ] Trace JWT expiry check in auth/jwt.rs
- [ ] Verify boundary condition: < vs <=
- [ ] Run cargo test auth suite
- [ ] Attach diff as proof

The session reads tasks.md at Work mode start. It requires at least 1 task — generate-tasks returns 422 if the output file is empty.

Between stages

After each stage, the operator can edit the output file before running the next stage. The pipeline is not a black box — every intermediate artifact is a plain Markdown file in the Work item's memory directory and can be modified directly.

API reference