# Command Error Implementation Parity Check

## Context

Module: {{MODULE_NAME}}
Command docs: {{COMMAND_DOCS}}
Error definitions: {{ERROR_DEFS}}
Command code: {{COMMAND_CODE}}
Test code: {{COMMAND_TEST_CODE}}

## Instructions

1. Read ALL command docs at the paths above
2. Read the error definitions file at the path above
3. Read ALL command code files at the paths above
4. Read ALL test code files at the paths above
5. For each documented error scenario, trace through generated class → command return → test assertion
6. Run every parity check below
7. Return results as JSON per the Output Format section

## Extraction: Command Docs

From each command doc's Error Scenarios section, extract:

- **Error code**: e.g. `ENTITY_NOT_FOUND`
- **Condition**: when this error is returned
- **Expected class name**: derived from error code (PascalCase + `Error` suffix)

## Extraction: Error Definitions

From `lib/errors.generated.ts`, extract:

- **Error class names**: exported error classes
- **Error codes**: the code constant in each class
- **Error message patterns**: message templates

See [errors.md](errors.md) for error generation patterns.

## Extraction: Command Code

From each command file (`command/*.ts`, excluding `*.test.ts` and `*.generated.ts`), extract:

- **Error imports**: which error classes are imported from `../lib/errors.generated`
- **Error returns**: `return err(new XError(...))` statements
- **Error codes used**: which error codes appear in the code

## Extraction: Test Code

From each test file (`command/*.test.ts`), extract:

- **Error assertions**: tests that check for specific error types or codes
- **Error test descriptions**: test names that reference error scenarios

## Parity Checks

For each error scenario documented in command docs:

| Check ID              | Question                                                                                                                                     |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| error_class_generated | Does the error class exist in `errors.generated.ts`?                                                                                         |
| error_code_accuracy   | Does the generated error code equal `{MODULE_PREFIX}_{DOC_CODE}`? The generator prefixes doc codes with the module name in UPPER_SNAKE_CASE. |
| error_returned        | Does the command code return this error via `err(new XError(...))`?                                                                          |
| error_import          | Does the command code import the error class from `errors.generated`?                                                                        |
| error_test_exists     | Does a test case assert this error scenario?                                                                                                 |

### How to Check

1. List all error codes from command docs
2. Verify each has a generated class in `errors.generated.ts`
3. Check command code imports and returns the error
4. Check test file has an assertion for this error

## Common Gap Patterns

- **Missing error class**: Error code in doc but no generated class (re-run `erp-kit module generate code -p <path>`)
- **Error not returned**: Generated class exists but command code doesn't return it
- **Error not imported**: Command uses inline error instead of generated class
- **Missing error test**: Error is returned in code but no test asserts it
- **Error code mismatch**: Doc code differs from generated/code code

## Output Format

Return a JSON object:

```json
{
  "check_type": "command-error-implementation-parity",
  "module": "{{MODULE_NAME}}",
  "gaps": [...],
  "inconsistencies": [...],
  "summary": { "total_checks": N, "passed": N, "failed": N, "skipped": N }
}
```

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