# Resolver Extraction

## Context

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

## Available Modules

The following modules are available in erp-kit. Use this to map resolvers to real module commands.

{{MODULE_OVERVIEW}}

To list a module's available commands, queries, and models, run:

```bash
npx erp-kit doc module <module-name>
```

To inspect a specific module's model (state transitions, invariants, command definitions), run:

```bash
npx erp-kit doc module <module-name> model <model-name>
```

To inspect a specific module's command in detail, run:

```bash
npx erp-kit doc module <module-name> command <command-name>
```

## Instructions

1. Read ALL actor docs at the paths above
2. Read ALL business flow docs at the paths above
3. Read ALL story docs at the paths above
4. For each module referenced in the stories, run `npx erp-kit doc module <module-name>` to get the full list of available commands, queries, and models
5. For modules with stateful entities, run `npx erp-kit doc module <module-name> model <model-name>` to understand state transitions — each resolver must respect the module's status lifecycle (e.g., DRAFT → SUBMITTED → APPROVED) and map to exactly one status transition command
6. Identify GraphQL resolvers needed for each business flow and story, mapping each operation to a real module command from the lists obtained in step 4 — do NOT guess or invent command names
7. Return results as a structured markdown report

## Extraction Rules

### Resolver Identification

For each business flow step that modifies data:

1. Identify the operation type (create, update, delete, approve, etc.)
2. Determine if the operation needs a resolver:
   - If the operation is a **scheduled job, cron task, webhook handler, or system-triggered process** that doesn't expose a GraphQL endpoint → mark the story's Resolvers section as `N/A — <reason>` (e.g., `N/A — background job`). No resolver doc is needed.
   - Otherwise, continue to step 3.
3. Map to a resolver name using camelCase action-verb convention
4. Identify the module command the resolver will call. If no erp-kit module covers the domain, flag it as a module gap.
5. Extract inputs, outputs, and error scenarios

### Operation → Resolver Mapping

See [erp-kit-shared/references/resolver-classification.md](../../erp-kit-shared/references/resolver-classification.md) for the full operation → resolver mapping table and custom vs built-in classification.

### Resolver Content

For each resolver, extract:

- **Name**: camelCase action-verb (e.g., `createSupplierInvitation`)
- **Type**: Mutation or Query
- **Module**: which erp-kit module provides the command
- **Command**: which module command it calls
- **Inputs**: parameters from the flow step
- **Outputs**: expected return data
- **Error scenarios**: what can go wrong
- **Overview**: one concise, self-contained sentence describing what the resolver does. Its first paragraph becomes the generated resolver's `description` (surfaced to AI tooling), so avoid implementation detail and keep it under ~1 sentence.

## Naming Convention

- Resolver filename: camelCase matching the operation name
- Action-focused: `createSupplierInvitation.md`, `updateItem.md`

## Output Format

Return your findings as a structured markdown report:

### Resolvers

For each resolver:

- **Resolver:** `<resolverName>`
- **Type:** Mutation / Query
- **Module:** module name
- **Command:** command name
- **Flow steps:** which flow steps this resolver supports
- **Inputs:** bulleted list of input fields
- **Error scenarios:** bulleted list of error cases

### Built-in Queries

List entities that only need built-in list/get queries (no custom resolver needed).

### Module Gaps

List any operations that could not be mapped to an existing erp-kit module. These will require a custom module. For each gap:

- **Operation:** what the flow requires
- **Suggested custom module:** proposed module name and domain
- **Suggested command:** proposed command name

### Summary

- Total custom resolvers
- Total built-in queries
- Resolvers per module (table)
- Module gaps (if any)