# Command Doc → Command Code Parity Check

## Context

Module: {{MODULE_NAME}}
Command docs: {{COMMAND_DOCS}}
Command code: {{COMMAND_CODE}}

## Instructions

1. Read ALL command docs at the paths above
2. Read ALL command code files at the paths above
3. For each command doc, extract business rules, process flow branches, input/output types
4. For each command code file, extract validation logic, branching paths, input interface, return type
5. Run every parity check below against each command
6. 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: each business rule, each flowchart branch, each input field, output shape, each state transition.

## Extraction: Command Docs

From each command doc, extract:

- **Business rules**: numbered validation rules
- **Process flow**: branches from mermaid flowchart (decision nodes and their paths)
- **Input fields**: documented input parameters
- **Output type**: documented return structure
- **State transitions**: any status changes performed

## Extraction: Command Code

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

- **Validation logic**: if/guard checks that enforce business rules
- **Branching paths**: if/else, early returns, switch statements
- **Input interface**: exported `interface ...Input` fields
- **Return type**: `ok(...)` / `err(...)` structure
- **Generated shell**: existence of corresponding `.generated.ts` file

## Implementation Pattern Reference

See [commands.md](commands.md) for the canonical implementation patterns:

- `run` function + generated shell pattern
- Custom fields (generic CF) usage rules
- State transition `from` parameter pattern
- Return format conventions

## Parity Checks

For each command:

| Check ID                | Question                                                |
| ----------------------- | ------------------------------------------------------- |
| business_rule_impl      | Is each documented business rule implemented in code?   |
| process_flow_alignment  | Do code branches match documented process flow?         |
| input_type_coverage     | Does input interface include all documented inputs?     |
| return_type_accuracy    | Does return type match documented output?               |
| generated_shell_pattern | Does command export `run` with a `.generated.ts` shell? |
| input_interface_export  | Is the input interface exported?                        |
| jsdoc_present           | Does the `run` function have a JSDoc comment?           |

### How to Check

1. List all business rules from command doc
2. Find corresponding validation/guard in command code
3. Trace each process flow branch to a code path
4. Compare input interface fields with doc input fields
5. Verify `.generated.ts` file exists and imports `run`
6. Check return type wraps result in object (`{ entity }`)

## Common Gap Patterns

- **Unimplemented business rules**: Rule in doc but no validation code
- **Missing process branches**: Flowchart branch not in code logic
- **Missing generated shell**: No `.generated.ts` file for command
- **Input mismatch**: Doc input fields not in interface
- **Return format mismatch**: Code returns raw entity instead of `{ entity }`

## Output Format

Return a JSON object:

```json
{
  "check_type": "command-doc-code-parity",
  "module": "{{MODULE_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.