# Resolver Doc → Backend Code Parity Check

## Context

App: {{APP_NAME}}
Resolver docs: {{RESOLVER_DOCS}}
Backend resolvers: {{BACKEND_RESOLVERS}}
Backend executors: {{BACKEND_EXECUTORS}}

## Instructions

1. Read ALL resolver docs at the paths above
2. Read ALL backend resolver code files at the paths above
3. Read ALL backend executor code files at the paths above
4. For each resolver doc, check if it has a corresponding implementation
5. Return results as JSON per the Output Format section

## Method

Follow [claim-by-claim verification](../../erp-kit-shared/references/claim-verification.md) (prepended to this prompt). Claims for this template: inputs, error scenarios and their conditions, output shape, called command.

## 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 (name, type, required/optional)
- Error scenarios (error codes and conditions)
- Expected output shape

## Extraction: Backend Code

From each resolver file (`src/resolver/*.ts`), extract:

- Resolver name (from `createResolver()` call or filename)
- Module command called (import path and function name)
- Input parameter handling (`context.input.*` accesses)
- Error handling (`result.error.code` switch cases)
- Return value structure

From each executor file (`src/executor/*.ts`), extract:

- Executor name and which module event handler it re-exports

## Parity Checks

| Check ID           | Question                                                        |
| ------------------ | --------------------------------------------------------------- |
| command_reference  | Does the resolver code call the correct module command?         |
| input_coverage     | Does the resolver handle all documented input parameters?       |
| error_handling     | Does the resolver handle all documented error scenarios?        |
| return_shape       | Does the resolver return the documented output shape?           |
| behavior_parity    | Under each documented condition, does the code produce the documented outcome? |
| executor_exists    | Does an executor exist for each module that has event handlers? |
| no_direct_mutation | Does the resolver avoid directly mutating module-owned tables?  |

File existence checks (`resolver_impl_exists`) are handled by `erp-kit app sync-check` in the build verification step. This agent focuses on content parity only.

### How to Check

1. For each resolver doc that has a corresponding code file, verify the code imports and calls the documented module command
2. Check that `context.input.*` accesses match documented inputs
3. Check that error `switch` cases cover all documented error codes
4. Verify return value structure matches documentation
5. Check executors re-export module event handlers without custom logic

## Common Gap Patterns

- **Wrong command**: Code calls a different module command than documented
- **Missing input handling**: Doc specifies an input parameter not accessed in code
- **Missing error cases**: Error scenario in doc not handled in code's switch
- **Direct table mutation**: Code uses `db.insertInto()` on module-owned tables instead of module commands

## Output Format

Return a JSON object:

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

Each `gaps[]` entry includes `"evidence": "<file:line>"` for pass/fail verdicts.

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