---
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.
disable-model-invocation: true
metadata:
  erp-kit-version: "0.59.0"
---

# Implementation Parity Review

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

## Version Check

Run `npx erp-kit internal measure versions` from the repo root. If `status` is `"violations"`, relay the findings (each states its own fix) and stop; otherwise proceed.

## 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/resolver/*.ts`
- `BACKEND_EXECUTORS`: glob `<APP_ROOT>/backend/src/executor/*.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/pages/**/page.tsx`
- `BUSINESS_FLOW_DOCS`: glob `<APP_ROOT>/docs/business-flow/*/README.md`
- `E2E_SPECS`: glob `<APP_ROOT>/frontend/e2e/tests/*.spec.ts`

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     | [references/frontend-page-doc-parity.md](references/frontend-page-doc-parity.md) | One global agent   | All FRONTEND_PAGES + all SCREEN_DOCS                        |
| E     | Build verification (inline)                                                      | One global agent   | All source paths                                             |
| F     | [references/e2e-journey-coverage-check.md](references/e2e-journey-coverage-check.md) | One per business flow | Single BUSINESS_FLOW_DOC + matching E2E_SPEC (`frontend/e2e/tests/<flow>.spec.ts`) |
| G     | [references/flow-diagram-implementation-parity.md](references/flow-diagram-implementation-parity.md) | One per business flow | Single BUSINESS_FLOW_DOC + BACKEND_RESOLVERS + BACKEND_EXECUTORS + BACKEND_MODULES |

With R resolvers, S screens, and F business flows, this produces R + S + R + 1 + 1 + 2F parallel agents (groups A-C are per-item; D and E are one global agent each; F and G are one per business flow).

For groups A-C:

1. Read [claim-verification.md](../erp-kit-shared/references/claim-verification.md) and the prompt template file; prepend the former to the template
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 (page → doc reverse check):

Dispatch one global agent with the filled `frontend-page-doc-parity.md` prompt. It receives ALL FRONTEND_PAGES and ALL SCREEN_DOCS and reports pages that have no corresponding screen doc. This is the reverse of group B: `sync-check` only flags screen docs missing a page object, not implemented pages missing a doc, so this agent is the only check that catches undocumented pages.

For group E (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.

For groups F and G (one agent per business flow):

1. Read the prompt template file
2. Replace `{{APP_NAME}}` and `{{BUSINESS_FLOW_DOC}}` with the flow's `README.md` path
3. For F, replace `{{E2E_SPEC}}` with the flow's `frontend/e2e/tests/<flow>.spec.ts`; for G, replace `{{BACKEND_RESOLVERS}}`, `{{BACKEND_EXECUTORS}}`, and `{{BACKEND_MODULES}}` as defined in Step 1
4. Dispatch one agent per flow with the filled prompt

## Step 3: Aggregate Results

After ALL agents return:

1. Collect the JSON results from each agent
2. **Validate claim accounting** (groups A-C): if a result has no `claims_total`, or `total_checks < claims_total`, or contains a `pass` without `evidence`, re-run that agent once; on second failure treat its unevidenced passes as `fail`
3. Merge all `gaps[]` arrays into a single list
4. Merge all `inconsistencies[]` arrays into a single list
5. Deduplicate: if two gaps share the same `source + target + check`, keep only one
6. Deduplicate findings: if agents from groups A and C report the same resolver issue, keep only one
7. Calculate totals across all summaries
8. 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 group A gaps)

---

### 2. Screen Doc → Frontend Code Coverage

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

(Populated from group B gaps)

---

### 3. Module Wiring Consistency

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

(Populated from group C gaps)

---

### 4. Build & Sync Verification

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

(Populated from group E results)

---

### 5. E2E Journey Coverage

| Business Flow | Journey Walks the Main Path | Gap |
| ------------- | --------------------------- | --- |

(Populated from group F gaps)

---

### 6. Flow Diagram ↔ Implementation

| Business Flow | Diagram Claim | Implemented | Gap |
| ------------- | ------------- | ----------- | --- |

(Populated from group G gaps)

---

### 7. Missing Implementation

#### Missing Backend Resolvers

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

(Populated from group E sync-check `orphaned-doc` findings)

#### Missing Resolver Docs (resolver exists, no doc)

| Resolver File | Derived Resolver Name | Suggested Doc Path |
| ------------- | --------------------- | ------------------ |

(Populated from group E sync-check `missing-doc` findings)

#### Missing Frontend Pages

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

(Populated from group B gaps where status is `fail`)

#### Missing Screen Docs (page exists, no doc)

| Page Path | Derived Screen Name | Suggested Doc Path |
| --------- | ------------------- | ------------------ |

(Populated from group D gaps where status is `fail`)

#### Missing Module Wiring

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

(Populated from group C gaps where status is `fail`)

---

### 8. Inconsistencies

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

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

---

### 9. 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   |
| Page → Doc Coverage          |        | X/Y pages documented |
| Build & Sync Verification    |        | pass / fail         |
| E2E Journey Coverage         |        | X/Y flows covered   |
| Flow Diagram ↔ Implementation |       | X/Y claims verified |

### 10. 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