@tailor-platform/erp-kit 0.3.0 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/erp-kit",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Opinionated ERP toolkit for building business applications on Tailor Platform",
   "license": "MIT",
   "bin": {
@@ -35,12 +35,13 @@
   "devDependencies": {
     "@tailor-platform/function-kysely-tailordb": "0.1.3",
     "@tailor-platform/function-types": "0.8.2",
-    "@tailor-platform/sdk": "1.25.1",
+    "@tailor-platform/sdk": "1.25.2",
     "@types/mdast": "^4.0.4",
     "@types/node": "^25.1.0",
+    "@typescript-eslint/parser": "^8.57.0",
     "eslint": "10.0.3",
     "kysely": "0.28.11",
-    "tsdown": "0.21.2",
+    "tsdown": "0.21.3",
     "typescript": "^5.7.3",
     "vitest": "^4.0.0",
     "@tailor-platform/eslint-config": "0.0.1"
@@ -48,7 +49,7 @@
   "peerDependencies": {
     "@tailor-platform/function-kysely-tailordb": "0.1.3",
     "@tailor-platform/function-types": "0.8.2",
-    "@tailor-platform/sdk": "1.25.1",
+    "@tailor-platform/sdk": "1.25.2",
     "kysely": "0.28.11"
   },
   "engines": {

package/skills/erp-kit-app-1-requirements/SKILL.md

@@ -26,15 +26,14 @@ Focus on "what" the application should do, not "how" it will be implemented.
 
 ### Phase 2: Clarify
 
-Use AskUserQuestion to clarify undefined requirements:
+Use AskUserQuestion to clarify undefined requirements. Focus on business-level scope and workflows — not platform capabilities like authentication.
 
-| Category          | Example Questions                              |
-| ----------------- | ---------------------------------------------- |
-| Authentication    | External IdP / Password / Out of scope?        |
-| User Operations   | Direct creation / Email invitation / Both?     |
-| Roles             | Fixed roles (Admin/User) / Custom roles?       |
-| User Self-Service | View only / Profile edit / Password change?    |
-| Lifecycle         | Create only / Full lifecycle (activate/deact)? |
+| Category         | Example Questions                                                            |
+| ---------------- | ---------------------------------------------------------------------------- |
+| Scope            | Which steps are MVP-essential? Any steps that can be deferred?               |
+| Edge Cases       | How far to handle cancellation, rejection, or mid-flow abandonment?          |
+| Actor Boundaries | Are approver and executor separate? What is each actor's operational scope?  |
+| Business Rules   | Which steps are automated vs manual? What conditional branches exist?        |
 
 Ask 3-4 questions at a time using multiSelect where appropriate.
 
@@ -76,7 +75,7 @@ At Tier 2, story files do not exist yet. Use `- TBD` as a placeholder to avoid b
 ### Phase 4: Validate
 
 ```bash
-pnpm run app:doc:check
+erp-kit app check -p {APP_ROOT}
 ```
 
 See [schema-constraints.md](../erp-kit-app-shared/references/schema-constraints.md) for notes on expected "No matching files found" output.

package/skills/erp-kit-app-2-requirements-review/references/best-practices-check.md

@@ -11,6 +11,10 @@ Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
 Read [erp-kit-app-shared/references/schema-constraints.md](../../erp-kit-app-shared/references/schema-constraints.md) before evaluating. **Never recommend changes that violate the schema.**
 
+## Tier 2 Scope
+
+This review targets Tier 1-2 documentation only. Stories (`## Stories` section in business flows) are created in step 3 (`erp-kit-app-3-plan`). A `- TBD` placeholder in the Stories section is expected and correct at this stage — do **not** flag it as incomplete or missing.
+
 ## Instructions
 
 1. Read the application README at the path above

package/skills/erp-kit-app-2-requirements-review/references/boundary-consistency-check.md

@@ -11,6 +11,10 @@ Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
 Read [erp-kit-app-shared/references/schema-constraints.md](../../erp-kit-app-shared/references/schema-constraints.md) before evaluating. When checking `naming_consistency`, validate that H1 headings follow the schema rules — different doc types have different heading formats.
 
+## Tier 2 Scope
+
+This review targets Tier 1-2 documentation only. Stories (`## Stories` section in business flows) are created in step 3 (`erp-kit-app-3-plan`). A `- TBD` placeholder in the Stories section is expected and correct at this stage — do **not** flag it as a broken link, missing content, or incomplete documentation.
+
 ## Instructions
 
 1. Read the application README at the path above

package/skills/erp-kit-app-3-plan/SKILL.md

@@ -29,26 +29,36 @@ Define shared context for all agents:
 - `APP_NAME`: basename of APP_ROOT
 - `BUSINESS_FLOW_DOCS`: glob `<APP_ROOT>/docs/business-flow/*/README.md`
 - `ACTOR_DOCS`: glob `<APP_ROOT>/docs/actors/*.md`
+- `MODULE_OVERVIEW`: output of `erp-kit doc modules`
 
 Verify at least `BUSINESS_FLOW_DOCS` is non-empty. If no business flow docs exist, stop with: "No business flow docs found under <APP_ROOT>/docs/. Run erp-kit-app-1-requirements first."
 
+Collect module overview:
+
+```bash
+erp-kit doc modules
+```
+
+This returns each module's name, overview, command/query/model counts, and dependencies. Save the full output as `MODULE_OVERVIEW` — all three agents receive it.
+
 ## Step 2: Dispatch Agents (parallelize if possible)
 
 Launch 3 Agent tool calls in parallel — one per extraction concern.
-Each agent receives: APP_NAME, relevant doc file paths.
+Each agent receives: APP_NAME, relevant doc file paths, and MODULE_OVERVIEW.
 
-| Agent | Prompt Template                                                        | Inputs                                   |
-| ----- | ---------------------------------------------------------------------- | ---------------------------------------- |
-| 1     | [references/story-extraction.md](references/story-extraction.md)       | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS |
-| 2     | [references/screen-extraction.md](references/screen-extraction.md)     | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS |
-| 3     | [references/resolver-extraction.md](references/resolver-extraction.md) | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS |
+| Agent | Prompt Template                                                        | Inputs                                                    |
+| ----- | ---------------------------------------------------------------------- | --------------------------------------------------------- |
+| 1     | [references/story-extraction.md](references/story-extraction.md)       | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS, MODULE_OVERVIEW |
+| 2     | [references/screen-extraction.md](references/screen-extraction.md)     | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS, MODULE_OVERVIEW |
+| 3     | [references/resolver-extraction.md](references/resolver-extraction.md) | APP_NAME, ACTOR_DOCS, BUSINESS_FLOW_DOCS, MODULE_OVERVIEW |
 
 For each agent:
 
 1. Read the prompt template file
 2. Replace `{{APP_NAME}}` with the resolved app name
 3. Replace `{{ACTOR_DOCS}}`, `{{BUSINESS_FLOW_DOCS}}` with the actual file paths
-4. Dispatch the agent with the filled prompt
+4. Replace `{{MODULE_OVERVIEW}}` with the output from `erp-kit doc modules`
+5. Dispatch the agent with the filled prompt
 
 ## Step 3: Aggregate & Present Plan
 
@@ -59,33 +69,23 @@ After ALL agents return:
    - Stories to create (with actor, flow, scenario patterns)
    - Screens to create (with type, fields, actions)
    - Resolvers to create (with operation type, module mapping)
-3. Wait for user approval
-
-## Step 4: Check Module Dependencies
+## Step 4: Resolve Module Gaps
 
-Before creating resolver docs, verify required modules exist:
+Step 2's resolver agent mapped resolvers to erp-kit modules using `MODULE_OVERVIEW` and flagged any operations that could not be mapped as module gaps.
 
-```bash
-ls packages/erp-kit/src/modules/
-```
-
-For each resolver that references a module command, check the module and command exist:
-
-```bash
-ls packages/erp-kit/src/modules/<module-name>/docs/commands/
-```
+If there are no gaps, proceed to Step 5.
 
-**If modules don't exist:**
+**If resolvers require functionality that no erp-kit module provides:**
 
-1. Identify needed modules — group resolver operations by domain
-2. Create module docs first — use `erp-kit-module-1-requirements` skill
-3. Return to this step after modules have documented commands
+1. Group the unmapped operations by domain to identify what custom modules are needed
+2. Create each custom module using `erp-kit-module-1-requirements` skill
+3. Return to this step after the custom modules are ready
 
-**Only reference existing module commands** in resolver documentation.
+For resolvers that reference erp-kit modules, use `MODULE_OVERVIEW` as the source of truth. For resolvers that reference custom modules, use the custom module's own documentation.
 
 ## Step 5: Scaffold & Populate
 
-After approval, scaffold using `erp-kit` CLI:
+Scaffold using `erp-kit` CLI:
 
 ```bash
 # Tier 3: Stories
@@ -117,7 +117,7 @@ Read-only stories should have `None` under `## Resolvers`.
 ## Step 6: Validate
 
 ```bash
-pnpm run app:doc:check
+erp-kit app check -p {APP_ROOT}
 ```
 
 ## Naming Conventions

package/skills/erp-kit-app-3-plan/references/resolver-extraction.md

@@ -6,11 +6,23 @@ App: {{APP_NAME}}
 Actor docs: {{ACTOR_DOCS}}
 Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
+## Available Modules
+
+The following modules are available in erp-kit. Use this to map resolvers to real module commands.
+
+{{MODULE_OVERVIEW}}
+
+To inspect a specific module's commands in detail, run:
+
+```bash
+erp-kit doc module <module-name> command <command-name>
+```
+
 ## Instructions
 
 1. Read ALL actor docs at the paths above
 2. Read ALL business flow docs at the paths above
-3. Identify GraphQL resolvers needed for each business flow
+3. Identify GraphQL resolvers needed for each business flow, using the module overview and `erp-kit doc module <name> command` for detail
 4. Return results as a structured markdown report
 
 ## Extraction Rules
@@ -21,26 +33,13 @@ For each business flow step that modifies data:
 
 1. Identify the operation type (create, update, delete, approve, etc.)
 2. Map to a resolver name using camelCase action-verb convention
-3. Identify the module command the resolver will call
+3. Identify the module command the resolver will call. If no erp-kit module covers the domain, flag it as a module gap.
 4. Extract inputs, outputs, and error scenarios
 
 ### Operation → Resolver Mapping
 
 See [erp-kit-app-shared/references/resolver-classification.md](../../erp-kit-app-shared/references/resolver-classification.md) for the full operation → resolver mapping table and custom vs built-in classification.
 
-### Module Command Mapping
-
-For each resolver, identify which erp-kit module provides the command:
-
-| Resolver Operation | Typical Module        |
-| ------------------ | --------------------- |
-| User invite/roles  | `user-management`     |
-| Supplier CRUD      | `supplier-management` |
-| Document handling  | `document-management` |
-| Task workflows     | `task-management`     |
-| Item CRUD          | `item-management`     |
-| Unit/currency      | `primitives`          |
-
 ### Resolver Content
 
 For each resolver, extract:
@@ -78,12 +77,17 @@ For each resolver:
 
 List entities that only need built-in list/get queries (no custom resolver needed).
 
-### Module Dependencies
+### Module Gaps
+
+List any operations that could not be mapped to an existing erp-kit module. These will require a custom module. For each gap:
 
-Table with columns: Module, Required Commands, Status (exists/missing)
+- **Operation:** what the flow requires
+- **Suggested custom module:** proposed module name and domain
+- **Suggested command:** proposed command name
 
 ### Summary
 
 - Total custom resolvers
 - Total built-in queries
 - Resolvers per module (table)
+- Module gaps (if any)

package/skills/erp-kit-app-3-plan/references/screen-extraction.md

@@ -6,12 +6,25 @@ App: {{APP_NAME}}
 Actor docs: {{ACTOR_DOCS}}
 Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
+## Available Modules
+
+The following modules are available in erp-kit. Use this to understand which entities exist and what operations are available.
+
+{{MODULE_OVERVIEW}}
+
+To inspect a specific module's model (domain description, state transitions, invariants, commands), run:
+
+```bash
+erp-kit doc module <module-name> model <model-name>
+```
+
 ## Instructions
 
 1. Read ALL actor docs at the paths above
 2. Read ALL business flow docs at the paths above
 3. Identify screens needed for each business flow
-4. Return results as a structured markdown report
+4. For screens that display or edit module entities, use `erp-kit doc module <name> model` to understand the entity's domain
+5. Return results as a structured markdown report
 
 ## Extraction Rules
 
@@ -63,6 +76,7 @@ For each screen:
 
 - **Screen:** `<screen-name>`
 - **Type:** ListView / Form / DetailView
+- **Module source:** which module's model provides the data (if applicable)
 - **Fields/Columns:** bulleted list of fields with types
 - **Actions:** bulleted list of actions
 - **Referenced by stories:** which stories use this screen

package/skills/erp-kit-app-3-plan/references/story-extraction.md

@@ -6,6 +6,12 @@ App: {{APP_NAME}}
 Actor docs: {{ACTOR_DOCS}}
 Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
+## Available Modules
+
+The following modules are available in erp-kit. Use this to determine whether a story needs custom resolvers or can rely on built-in queries.
+
+{{MODULE_OVERVIEW}}
+
 ## Instructions
 
 1. Read ALL actor docs at the paths above
@@ -49,10 +55,10 @@ For each story, extract:
 
 ### Resolver Classification
 
-For each story, determine:
+For each story, determine using the module overview:
 
 - **Needs resolvers**: Story involves create/update/delete operations → mark as `- TBD` for resolvers
-- **Read-only**: Story only views/lists data → mark as `None` for resolvers
+- **Read-only**: Story only views/lists data and built-in queries suffice → mark as `None` for resolvers
 
 ## Naming Convention
 

package/skills/erp-kit-app-5-impl-backend/SKILL.md

@@ -27,9 +27,13 @@ All four tiers of documentation must exist:
 ## Workflow
 
 ```
-ANALYZE DOCS → MODULE WIRING → CONFIG → RESOLVERS → GENERATED FILES → VERIFY → DEPLOY
+ANALYZE DOCS → MODULE WIRING → CONFIG → RESOLVERS → GENERATED FILES → DEPLOY
 ```
 
+### Incremental Verification
+
+Run `pnpm lint` and `pnpm typecheck` after each of Phase 2, 3, and 4. Fix errors before moving on.
+
 ### Phase 1: Analyze Documentation
 
 Read all resolver and screen specs to build a complete picture:
@@ -65,10 +69,12 @@ Key points:
 
 ### Phase 4: Implement Backend Resolvers and Executors
 
-Write one file per resolver under `src/modules/<module-name>/resolvers/`, one per executor under `executors/`.
+Write one file per resolver under `src/resolvers/`, one per executor under `executors/`.
 
 **Read [resolver & executor patterns reference](references/resolver-patterns.md).**
 
+For each resolver, check whether its spec (`docs/resolver/*.md`) documents error codes. If it does, implement a `switch(result.error.code)` block — do not use generic `throw result.error`.
+
 Do not directly mutate module-owned tables via Kysely — always use module commands.
 
 ### Phase 5: Generated Files
@@ -76,15 +82,7 @@ Do not directly mutate module-owned tables via Kysely — always use module comm
 - **Kysely types** (`src/generated/kysely-tailordb.ts`) — Auto-generated by `pnpm generate` after deployment. Before deployment, create a minimal placeholder so the codebase typechecks.
 - **Seed data** (`seed/`) — `exec.mjs` runner + `data/*.jsonl` (records) and `data/*.schema.ts` (validation). Create seed records for initial data (permissions, roles, test users, etc.). Seeded users must have concrete permission keys required by the wired modules.
 
-### Phase 6: Verify
-
-```bash
-cd <app-root>/backend
-pnpm lint
-pnpm typecheck
-```
-
-### Phase 7: Deploy Backend & Next Steps
+### Phase 6: Deploy Backend & Next Steps
 
 Frontend implementation requires a deployed backend (for GraphQL schema generation). Prompt the user to:
 

package/skills/erp-kit-app-5-impl-backend/references/app-config.md

@@ -1,26 +1,6 @@
 # Application Config
 
-`tailor.config.ts` defines the Tailor application configuration. Key structure:
-
-```ts
-export default defineConfig({
-  name: "<app-name>",
-  cors: ["http://localhost:5173", website.url],
-  db: {
-    "main-db": {
-      files: [`./src/modules.ts`],
-      gqlOperations: "query",
-    },
-  },
-  resolver: {
-    "main-resolver": { files: [`./src/modules/**/resolvers/**/*.ts`] },
-  },
-  executor: { files: [`./src/modules/**/executors/**/*.ts`] },
-  auth: auth,
-  idp: [idp],
-  staticWebsites: [website],
-});
-```
+`tailor.config.ts` defines the Tailor application configuration. Refer to existing examples in the codebase for the full config structure.
 
 Key points:
 
@@ -30,7 +10,6 @@ Key points:
 
 ## Auth configuration
 
-- Define IdP (`defineIdp`), Auth (`defineAuth`), and static website (`defineStaticWebSite`) using Tailor SDK
 - Prefer stable default naming: auth `default`, IdP `default`, OAuth2 client `default`
 - `userProfile.type` must reference the `user` DB type from `modules.ts`
 - `userProfile.usernameField`: stable unique field (e.g., `email`)

package/skills/erp-kit-app-5-impl-backend/references/module-wiring.md

@@ -3,7 +3,6 @@
 `src/modules.ts` composes erp-kit modules and exports their parts for resolver use.
 
 ```ts
-import { db as field } from "@tailor-platform/sdk";
 import {
   definePrimitivesModule,
   defineUserManagementModule,

package/skills/erp-kit-app-5-impl-backend/references/resolver-patterns.md

@@ -42,18 +42,27 @@ body: async (context) => {
 
 ### Error handling
 
-When the resolver spec documents specific error codes, use `result.error.code` to switch:
+Resolver specs document error codes the command can return. When codes are documented, add a `case` for every documented code — generic `throw result.error` loses context for the frontend. The error code is a discriminated union, so TypeScript enforces exhaustive handling without a `default` branch.
+
+**Do this:**
 
 ```ts
 if (!result.ok) {
   switch (result.error.code) {
-    case "USER_NOT_FOUND":
-      throw new Error(`User ${context.input.userId} not found`);
-    // ...
+    case "INSUFFICIENT_STOCK":
+      throw new Error(`Stock insufficient for item ${context.input.itemId}`);
+    case "ORDER_ALREADY_CONFIRMED":
+      throw new Error("Cannot modify a confirmed order");
   }
 }
 ```
 
+**Not this:**
+
+```ts
+if (!result.ok) throw result.error;
+```
+
 Do not directly mutate module-owned tables via Kysely — always use module commands.
 
 ---

package/skills/erp-kit-app-6-impl-frontend/SKILL.md

@@ -43,6 +43,8 @@ Run `pnpm generate` in the frontend directory to fetch the GraphQL schema from t
 
 ### Phase 3: Implement Frontend Pages
 
+Run `pnpm lint`, `pnpm typecheck`, and `pnpm gql-tada:check` regularly during implementation. Fix errors before moving on.
+
 Create pages driven by screen spec docs. Each screen type has a standard implementation pattern.
 
 **Read [pages reference](references/pages.md) for the full pattern catalog.**
@@ -70,5 +72,8 @@ Key frontend patterns:
 cd <app-root>/frontend
 pnpm lint
 pnpm typecheck
+pnpm gql-tada:check
 pnpm build
 ```
+
+After verification passes, proceed to implementation review with `/erp-kit-app-7-impl-review`.

package/skills/erp-kit-app-6-impl-frontend/references/pages.md

@@ -31,27 +31,7 @@ Key points:
 
 - Two-column `Layout`: detail on left, actions on right
 - `useParams()` to get entity ID from route
-- `DescriptionCard` from `@tailor-platform/app-shell` for key-value fields:
-
-```tsx
-<DescriptionCard
-  data={resource}
-  title="Overview"
-  columns={3}
-  fields={[
-    { key: "name", label: "Name", meta: { copyable: true } },
-    {
-      key: "status",
-      label: "Status",
-      type: "badge",
-      meta: { badgeVariantMap: { ACTIVE: "success" } },
-    },
-    { key: "createdAt", label: "Created At", type: "date", meta: { dateFormat: "medium" } },
-  ]}
-/>
-```
-
-Field types: `"text"` (default), `"badge"`, `"money"`, `"date"`, `"link"`, `"address"`, `"reference"`, `"divider"`
+- `DescriptionCard` from `@tailor-platform/app-shell` for key-value fields. Refer to existing examples in the codebase for props and field type usage.
 
 ### Form Pattern
 
@@ -59,8 +39,11 @@ Create and edit forms share the same structure:
 
 - **React Hook Form + Zod** for validation with `zodResolver`
 - **urql `useMutation`** for GraphQL mutations
-- **Cache invalidation**: pass `additionalTypenames` to the mutation context so urql invalidates related queries (e.g., `createUser(values, { additionalTypenames: ["User"] })`)
-- **Toast notifications**: use `useToast` from `@tailor-platform/app-shell` (sonner-based, `Toaster` is built into AppShell) for success/error feedback
+- **Cache invalidation**: pass `additionalTypenames` to the mutation context so urql invalidates related queries after create/edit/delete. Without this, list pages will show stale data.
+  ```ts
+  createUser(values, { additionalTypenames: ["User"] })
+  ```
+- **Toast notifications**: `useToast` from `@/hooks/use-toast`. `toast.error()` accepts `CombinedError` directly (e.g., `toast.error(result.error)`)
 - **Navigate `".."`** to go back to list after success
 - Edit form pre-fills `defaultValues` from existing entity via fragment
 
@@ -81,6 +64,14 @@ Create and edit forms share the same structure:
 - **Required: Yes** → `.min(1, "Field is required")` (string) / `.positive()` (number)
 - **Required: No** → `.optional()`
 
+#### Empty String Handling for Optional Fields
+
+React Hook Form defaults text inputs to `""`. For optional fields (e.g., `parentId`), convert empty strings to `undefined` before submitting to avoid backend errors. Use `||` not `??` — empty string is not nullish:
+
+```ts
+parentId: values.parentId || undefined,
+```
+
 ### Shared Component Patterns
 
 #### Fragment Collocation
@@ -117,13 +108,9 @@ const UserQuery = graphql(
 
 #### App.tsx
 
-- `AuthGuard`: implement yourself, pass via `guardComponent` prop. AuthProvider shows it automatically when `!isReady || !isAuthenticated`, so the guard only needs to render a sign-in UI — no state checks needed inside it
-- `GraphQLProvider`: pass `authClient.fetch` directly to urql's `fetch` option and `authClient.getAppUri()` for the URL
-- `useAuth()` returns `{ isAuthenticated, isReady, login, logout }` directly (not nested in `authState`)
-- Built-in `me` query returns the current user's `User` record — use it instead of writing a custom resolver for profile info
+Refer to existing examples in the codebase for `AuthGuard`, `GraphQLProvider`, auth client setup, and sidebar configuration.
+
 - Required env vars: `VITE_TAILOR_APP_URL`, `VITE_TAILOR_CLIENT_ID`
-- Auth client: create once in `src/lib/auth-client.ts` using `createAuthClient({ appUri, clientId })`
-- Sidebar: use `SidebarGroup` + `SidebarItem` for custom ordering
 
 #### Module-level page.tsx (required)
 
@@ -141,20 +128,3 @@ Every page component must:
 
 1. Be the **default export** of `page.tsx`
 2. Set `appShellPageProps` with at least `meta.title`
-
-#### Common imports
-
-```tsx
-import {
-  Layout,
-  Link,
-  useParams,
-  useNavigate,
-  type AppShellPageProps,
-} from "@tailor-platform/app-shell";
-import { useQuery, useMutation } from "urql";
-import { graphql, type FragmentOf, readFragment } from "@/graphql";
-import { useForm } from "react-hook-form";
-import { zodResolver } from "@hookform/resolvers/zod";
-import { z } from "zod";
-```

package/skills/erp-kit-app-7-impl-review/SKILL.md

@@ -21,7 +21,7 @@ Define shared context for all agents:
 - `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/modules/*/resolvers/*.ts`
+- `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_CONFIG`: `<APP_ROOT>/backend/tailor.config.ts`
@@ -50,16 +50,17 @@ For agents 1-3:
 3. Replace doc/code path placeholders with the actual file paths
 4. Dispatch the agent with the filled prompt
 
-For agent 4 (build verification):
+For agent 4 (build & sync verification):
 
-Run build checks inline:
+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
+erp-kit app sync-check -p <APP_ROOT>/..
 ```
 
-Report pass/fail for each check.
+Report pass/fail for each check. `sync-check` detects missing resolver implementations and orphaned docs, so agents 1-3 can skip file-existence checks and focus on content parity.
 
 ## Step 3: Aggregate Results
 
@@ -109,13 +110,14 @@ Render the aggregated results as markdown:
 
 ---
 
-### 4. Build Verification
+### 4. Build & Sync Verification
 
-| Check | Backend | Frontend |
-| ----- | ------- | -------- |
-| Lint  |         |          |
-| Types |         |          |
-| Build | N/A     |          |
+| Check      | Backend | Frontend |
+| ---------- | ------- | -------- |
+| Lint       |         |          |
+| Types      |         |          |
+| Build      | N/A     |          |
+| Sync-check |         | N/A      |
 
 (Populated from agent 4 results)
 
@@ -158,7 +160,7 @@ Render the aggregated results as markdown:
 | Resolver Doc → Code Coverage |        | X/Y checks passed |
 | Screen Doc → Code Coverage   |        | X/Y checks passed |
 | Module Wiring Consistency    |        | X/Y checks passed |
-| Build Verification           |        | pass / fail       |
+| Build & Sync Verification    |        | pass / fail       |
 
 ### 8. Recommendations