---
name: erp-kit-app-7-impl-review
description: Review implementation parity between documentation and code for applications. Use after frontend implementation (step 6) to validate code matches documentation.
metadata:
  erp-kit-version: "0.23.0"
---

# Implementation Parity Review

Review **implementation consistency** between Tier 3-4 documentation and actual backend/frontend code.

## Version Check

Run `npx erp-kit --version` and compare against this skill's `metadata.erp-kit-version`. If they differ, the local skills are outdated — tell the user to run `pnpm erp-kit update skills` and stop.

## Progress Logging

Run `npx erp-kit app progress schema` once to load the schema before your first log. Log at every step boundary marked with **Log:** below using `npx erp-kit app progress log --json '<payload>'`. Every payload requires: `v` (always `1`), `sessionId`, `prompt` (user's original request), `event`, `data`, and `conversation` (array of `{role, message}` since last log). See [progress-protocol.md](../erp-kit-shared/references/progress-protocol.md) for the full schema reference.

## When to Use

- After backend and frontend implementation, verify code matches documentation
- Before merging feature branches
- Quality check during code review

## Step 1: Setup

Define shared context for all agents:

- `APP_ROOT`: from argument or current working directory. Must contain a `docs/` directory.
- `APP_NAME`: basename of APP_ROOT
- `RESOLVER_DOCS`: glob `<APP_ROOT>/docs/resolver/*.md`
- `SCREEN_DOCS`: glob `<APP_ROOT>/docs/screen/*.md`
- `BACKEND_RESOLVERS`: glob `<APP_ROOT>/backend/src/resolvers/*.ts`
- `BACKEND_EXECUTORS`: glob `<APP_ROOT>/backend/executors/*.ts`
- `BACKEND_MODULES`: `<APP_ROOT>/backend/src/modules.ts`
- `BACKEND_MODULES_DB`: `<APP_ROOT>/backend/src/modules-db.ts`
- `BACKEND_CONFIG`: `<APP_ROOT>/backend/tailor.config.ts`
- `FRONTEND_PAGES`: glob `<APP_ROOT>/frontend/src/app/(main)/**/*.tsx`

Verify at least `RESOLVER_DOCS` or `SCREEN_DOCS` is non-empty. If no docs exist, stop with: "No docs found for app <APP_NAME>."

> **Log:** `step.start` with `data: { skill: "erp-kit-app-7-impl-review", context: { app: APP_NAME, resolvers: count, screens: count } }`

## Step 2: Dispatch Agents (parallelize if possible)

Dispatch agents in parallel — one per item in each group. All groups are dispatched simultaneously.
Each agent receives: APP_NAME, relevant doc/code file paths.
Each agent returns: structured JSON per [references/impl-parity-report-format.md](references/impl-parity-report-format.md).
If a doc or code directory is empty, the agent reports "no files found" and skips.
All review agents are read-only — no shared-file conflict risk.

| Group | Prompt Template                                                                  | Per-item scope     | Inputs per agent                                             |
| ----- | -------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------ |
| A     | [references/resolver-doc-code-parity.md](references/resolver-doc-code-parity.md) | One per resolver   | Single RESOLVER_DOC + matching BACKEND_RESOLVER + BACKEND_EXECUTOR |
| B     | [references/screen-doc-code-parity.md](references/screen-doc-code-parity.md)     | One per screen     | Single SCREEN_DOC + matching FRONTEND_PAGE directory         |
| C     | [references/module-wiring-parity.md](references/module-wiring-parity.md)         | One per resolver   | Single RESOLVER_DOC + BACKEND_MODULES + BACKEND_MODULES_DB + BACKEND_CONFIG |
| D     | Build verification (inline)                                                      | One global agent   | All source paths                                             |

With R resolvers and S screens, this produces R + S + R + 1 parallel agents.

For groups A-C:

1. Read the prompt template file
2. Replace `{{APP_NAME}}` with the resolved app name
3. Replace doc/code path placeholders with the actual file paths for that single item
4. Dispatch one agent per item with the filled prompt

For group D (build & sync verification):

Run build checks and source-doc sync check inline:

```bash
cd <APP_ROOT>/backend && pnpm lint && pnpm typecheck
cd <APP_ROOT>/frontend && pnpm lint && pnpm typecheck && pnpm build
npx erp-kit app sync-check -p <APP_ROOT>
```

Report pass/fail for each check. `sync-check` detects missing resolver implementations, orphaned docs, and story doc ↔ integration test case mismatches, so groups A-C agents can skip file-existence checks and focus on content parity.

## Step 3: Aggregate Results

After ALL agents return:

1. Collect the JSON results from each agent
2. Merge all `gaps[]` arrays into a single list
3. Merge all `inconsistencies[]` arrays into a single list
4. Deduplicate: if two gaps share the same `source + target + check`, keep only one
5. Deduplicate findings: if agents from groups A and C report the same resolver issue, keep only one
6. Calculate totals across all summaries
7. Render the final report below

## Report Format

Render the aggregated results as markdown:

### Implementation Parity Review Report

**Application:** <APP_NAME>

---

### 1. Resolver Doc → Backend Code Coverage

| Resolver Doc | Module Command | Implemented | Error Handling | Gap |
| ------------ | -------------- | ----------- | -------------- | --- |

(Populated from agent 1 gaps)

---

### 2. Screen Doc → Frontend Code Coverage

| Screen Doc | Screen Type | Page Exists | Fields Match | Gap |
| ---------- | ----------- | ----------- | ------------ | --- |

(Populated from agent 2 gaps)

---

### 3. Module Wiring Consistency

| Resolver | Required Module | Wired in modules.ts / modules-db.ts | Config Reference | Gap |
| -------- | --------------- | ------------------- | ---------------- | --- |

(Populated from agent 3 gaps)

---

### 4. Build & Sync Verification

| Check      | Backend | Frontend |
| ---------- | ------- | -------- |
| Lint       |         |          |
| Types      |         |          |
| Build      | N/A     |          |
| Sync-check |         | N/A      |

(Populated from agent 4 results)

---

### 5. Missing Implementation

#### Missing Backend Resolvers

| Resolver Doc | Expected File | Purpose |
| ------------ | ------------- | ------- |

#### Missing Frontend Pages

| Screen Doc | Expected Path | Screen Type |
| ---------- | ------------- | ----------- |

#### Missing Module Wiring

| Module | Referenced by Resolver | Status |
| ------ | ---------------------- | ------ |

(Populated from all agents' gaps where status is `fail`)

---

### 6. Inconsistencies

| Type | Location | Issue |
| ---- | -------- | ----- |

(Populated from all agents' `inconsistencies[]`)

---

### 7. Summary

| Aspect                       | Status | Details           |
| ---------------------------- | ------ | ----------------- |
| Resolver Doc → Code Coverage |        | X/Y checks passed |
| Screen Doc → Code Coverage   |        | X/Y checks passed |
| Module Wiring Consistency    |        | X/Y checks passed |
| Build & Sync Verification    |        | pass / fail       |

### 8. Recommendations

Numbered list of actionable fixes, grouped by priority:

1. Implement missing resolvers/pages (highest priority)
2. Fix module wiring gaps
3. Resolve field/type mismatches
4. Fix build errors

> **Log:** `step.complete` with `data: { status: "pass"|"fail"|"blocked", summary: "<one-line verdict with gap/inconsistency counts>", artifacts: [] }`

## References

- [Implementation parity report format](references/impl-parity-report-format.md)
- For backend patterns, see erp-kit-app-5-impl-backend
- For frontend patterns, see erp-kit-app-6-impl-frontend
