# Story → Resolver Parity Check

## Context

App: {{APP_NAME}}
Story docs: {{STORY_DOCS}}
Resolver docs: {{RESOLVER_DOCS}}
Module metadata (JSON): {{MODULE_METADATA}}

## Instructions

1. Read ALL story docs at the paths above
2. Read ALL resolver docs at the paths above
3. For each story, check resolver coverage
4. Return results as JSON per the Output Format section

## Extraction: Story Docs

From each story doc, extract:

- Story name (from filename or heading)
- Resolver section content:
  - `None` → read-only story, skip resolver checks
  - `N/A` (with optional reason, e.g., `N/A — background job`) → story intentionally has no resolver (skip checks). Common for scheduled jobs, cron tasks, webhook handlers, and system-triggered processes that don't expose a GraphQL endpoint.
  - `- TBD` → story needs resolvers but none documented yet (fail)
  - Resolver links (format: `../../../resolver/<name>.md`) → verify they exist
- Operations described that imply mutations (create, update, delete, submit, approve, etc.)

## Extraction: Module Metadata

Parse the MODULE_METADATA JSON array. Build a lookup map:
- Key: module name (e.g., `"business-partner"`)
- Value: `{ commands: string[], queries: string[] }` from `docs.command` and `docs.query` arrays

This is the authoritative source for which modules, commands, and queries exist.

## Extraction: Resolver Docs

From each resolver doc, extract:

- Resolver name (from filename or heading)
- Type: Mutation or Query
- Module and command it calls
- Input parameters and error scenarios

## Parity Checks

For each story:

| Check ID           | Question                                                                 |
| ------------------ | ------------------------------------------------------------------------ |
| resolver_existence | Do all resolver links in the story resolve to existing docs?             |
| resolver_coverage  | Does every non-read-only story have at least one resolver?               |
| resolver_tbd       | Are there stories still showing `- TBD` for resolvers?                   |
| link_validity      | Do resolver links in the story resolve to real files?                    |
| operation_coverage | Do story operations (create/update/delete) have matching resolver types? |
| module_command_existence | Does the module and command/query referenced in each resolver exist in installed modules? |

### How to Check

1. Read each story's `## Resolvers` section
2. If `None` → skip (read-only story)
3. If `N/A` (with or without reason) → skip (intentionally no resolver, e.g., background job)
4. If `- TBD` → fail: resolver docs not yet created
5. If links present → verify each link resolves to a file in RESOLVER_DOCS
6. Cross-check story operations against resolver types (mutation for writes, query for reads)
7. For each resolver that references a module and command/query, verify against MODULE_METADATA:
   - The module name must exist as an entry in the metadata array
   - The command name must appear in that module's `docs.command` array, or the query name in `docs.query`
   - If either is missing, report as `module_command_existence` gap

## Link Format Reference

| From  | To       | Format                        |
| ----- | -------- | ----------------------------- |
| Story | Resolver | `../../../resolver/<name>.md` |

## Common Gap Patterns

- **TBD resolvers**: Story still has placeholder `- TBD` instead of resolver links
- **Missing resolver docs**: Story links to a resolver that has no doc
- **Operation mismatch**: Story describes a create operation but no create resolver exists
- **Orphaned resolvers**: Resolver doc exists but no story links to it (covered by orphan detection)
- **Non-existent module**: Resolver references a module that isn't installed (not in MODULE_METADATA)
- **Non-existent command/query**: Resolver references a command or query that doesn't exist in the referenced module

## Output Format

Return a JSON object:

```json
{
  "check_type": "story-resolver-parity",
  "app": "{{APP_NAME}}",
  "gaps": [...],
  "inconsistencies": [...],
  "summary": { "total_checks": N, "passed": N, "failed": N, "skipped": N }
}
```

See [parity-report-format.md](parity-report-format.md) for field definitions.
