# Story Extraction

## Context

App: {{APP_NAME}}
Actor docs: {{ACTOR_DOCS}}
Business flow docs: {{BUSINESS_FLOW_DOCS}}

## Instructions

1. Read ALL actor docs at the paths above
2. Read ALL business flow docs at the paths above
3. For each business flow, decompose into user stories
4. Return results as a structured markdown report

## Extraction Rules

### Flow Step → Story Mapping

For each business flow:

1. Identify each numbered step or substep that represents a user action
2. Map each step to the responsible actor (from "Actors Involved" or sequence diagram)
3. Group related steps into stories (a story = a cohesive user action completable in one session)

| Flow Element     | Maps To     |
| ---------------- | ----------- |
| User action step | Story       |
| UI requirement   | Screen ref  |
| Actor in flow    | Story actor |

### Story Granularity

- Aim for 3-8 stories per business flow
- Each story should be completable in a single user session
- If a flow step is too large (multiple UI interactions), split into separate stories
- If a flow step is too small (a single click), merge with related steps

### Story Content

For each story, extract:

- **Actor**: which actor performs this action (from filename convention `<actor>--<name>.md`)
- **Scenario patterns**: business-meaningful patterns — distinct outcomes the user can reach within this story. Don't write UI steps (clicks, fills, navigates), validation errors, or screen behavior. If removing a pattern leaves a gap in the business scope of the story, keep it. Otherwise, leave it to test code.
- **Preconditions**: what must be true before this story
- **Postconditions**: what changes after this story completes
- **Screen references**: which screens the user interacts with
- **Resolver needs**: whether this story needs mutations (non-read-only) or is read-only

### Resolver Classification

For each story, determine:

- **Needs resolvers**: Story involves create/update/delete operations → mark as `TBD` for resolvers
- **Read-only**: Story only views/lists data → mark as `None` for resolvers

## Naming Convention

- Story filename: `<actor>--<story-name>.md` (double-dash separator between actor and story)
- Story heading: Title Case of the story name portion
- Actor slug: kebab-case of actor name

## Output Format

Return your findings as a structured markdown report:

### Stories by Business Flow

For each business flow:

#### <flow-name>

For each story:

- **Story:** `<actor>--<story-name>`
- **Actor:** actor name
- **Flow steps covered:** which steps this story implements
- **Scenario patterns:** bulleted list of business-meaningful outcomes (no UI steps or validation errors)
- **Screen references:** which screens are needed
- **Resolvers:** `TBD` (needs mutations) or `None` (read-only)

### Summary

- Total stories extracted
- Stories per flow (table)
- Stories per actor (table)
