@tailor-platform/erp-kit 0.2.2 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/erp-kit",
-  "version": "0.2.2",
+  "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": {
@@ -68,6 +69,7 @@
     "mock:start": "node dist/cli.mjs mock start",
     "mock:validate": "node dist/cli.mjs mock validate",
     "doc:gen": "POLITTY_DOCS_UPDATE=true vitest run src/cli.doc.test.ts",
-    "doc:check": "vitest run src/cli.doc.test.ts"
+    "doc:check": "vitest run src/cli.doc.test.ts",
+    "reset:module": "tsx scripts/reset-module.ts"
   }
 }

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

@@ -1,6 +1,6 @@
 ---
 name: erp-kit-app-1-requirements
-description: Create Tier 1-2 documentation (requirements, actors, business-flow) for examples/. Use when starting a new application or documenting high-level requirements and workflows.
+description: Create Tier 1-2 documentation (requirements, actors, business-flow) for an application. Use when starting a new application or documenting high-level requirements and workflows.
 ---
 
 # Application Requirement Analysis Workflow
@@ -26,37 +26,45 @@ 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.
 
 ### Phase 3: Create
 
-Generate documentation using `erp-kit` CLI:
+Generate documentation using `erp-kit` CLI. `{APP_ROOT}` is the parent directory where the app will live:
 
 ```bash
 # Tier 1: Requirements + project structure
-erp-kit app scaffold app <app-name> --root examples
+# Creates {APP_ROOT}/{APP_NAME}/README.md
+erp-kit app init {APP_NAME} {APP_ROOT}
 
 # Tier 2: Actors
-erp-kit app scaffold actors <app-name> <actor-name> --root examples
+erp-kit app generate doc actors {ACTOR_NAME} -p {APP_ROOT}/{APP_NAME}
 
 # Tier 2: Business Flows
-erp-kit app scaffold business-flow <app-name> <flow-name> --root examples
+erp-kit app generate doc business-flow {FLOW_NAME} -p {APP_ROOT}/{APP_NAME}
 ```
 
-**Naming conventions:**
+**Directory structure after init + generate:**
 
-- Files: kebab-case (e.g., `sales-representative.md`)
-- H1 heading slug must match filename slug
+```
+{APP_ROOT}/
+  {APP_NAME}/
+    README.md                                ← Tier 1 (from app init)
+    docs/
+      actors/{actor-name}.md                 ← Tier 2 (from generate doc actors)
+      business-flow/{flow-name}/README.md    ← Tier 2 (from generate doc business-flow)
+```
+
+**Schema constraints:** See [erp-kit-app-shared/references/schema-constraints.md](../erp-kit-app-shared/references/schema-constraints.md) for H1 heading rules, naming conventions, and requirements structure.
 
 **Business flow diagram:** Use `sequenceDiagram` with actors from "Actors Involved" as participants. Show who initiates each step and the system responses.
 
@@ -67,9 +75,11 @@ 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.
+
 ## Schema Reference
 
 | Schema              | Tier | Output Path                           |

package/skills/erp-kit-app-2-requirements-review/SKILL.md

@@ -17,7 +17,7 @@ Review **requirements quality** and **documentation consistency** for an app-com
 
 Define shared context for all agents:
 
-- `APP_ROOT`: from argument or current working directory. Must contain a `docs/` directory.
+- `APP_ROOT`: the app directory (e.g., `{APP_ROOT}/{APP_NAME}`). Must contain `README.md` and a `docs/` directory.
 - `APP_NAME`: basename of APP_ROOT
 - `APP_README`: `<APP_ROOT>/README.md`
 - `BUSINESS_FLOW_DOCS`: glob `<APP_ROOT>/docs/business-flow/*/README.md`
@@ -43,15 +43,16 @@ For each agent:
 3. Replace `{{APP_README}}`, `{{ACTOR_DOCS}}`, `{{BUSINESS_FLOW_DOCS}}` with the actual file paths
 4. Dispatch the agent with the filled prompt
 
-## Step 3: Aggregate Results
+## Step 3: Aggregate & Validate
 
 After ALL agents return:
 
 1. Collect the markdown results from each agent
 2. Merge all `issues[]` arrays into a single list
 3. Merge all `recommendations[]` arrays into a single list
-4. Calculate totals across all summaries
-5. Render the final report below
+4. **Filter out** any recommendation that would violate `erp-kit app check` schema constraints (e.g., title-casing business flow H1 headings)
+5. Calculate totals across all summaries
+6. Render the final report below
 
 ## Report Format
 

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

@@ -7,13 +7,22 @@ App README: {{APP_README}}
 Actor docs: {{ACTOR_DOCS}}
 Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
+## Schema Constraints
+
+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
 2. Read ALL actor docs and business flow docs at the paths above
 3. **Web search** app-compose and ERP application best practices (actor modeling, business flow design, user journey patterns)
 4. Evaluate whether the Tier 1-2 documentation follows best practices
-5. Return results as markdown per the Output Format section
+5. **Verify** that none of your recommendations would violate the schema constraints above
+6. Return results as markdown per the Output Format section
 
 ## Application Design Checks
 

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

@@ -7,12 +7,21 @@ App README: {{APP_README}}
 Actor docs: {{ACTOR_DOCS}}
 Business flow docs: {{BUSINESS_FLOW_DOCS}}
 
+## Schema Constraints
+
+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
 2. Read ALL actor docs and business flow docs at the paths above
 3. Cross-reference actors, flows, and requirements for internal consistency
-4. Return results as markdown per the Output Format section
+4. **Verify** that none of your recommendations would violate the schema constraints above
+5. Return results as markdown per the Output Format section
 
 ## Consistency Checks
 

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,43 +69,33 @@ 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
-erp-kit app scaffold story <app> <flow>/<actor>--<story> --root examples
+erp-kit app generate doc story <flow>/<actor>--<story> -p {APP_ROOT}/{APP_NAME}
 
 # Tier 3: Screens
-erp-kit app scaffold screen <app> <screen-name> --root examples
+erp-kit app generate doc screen <screen-name> -p {APP_ROOT}/{APP_NAME}
 
 # Tier 4: Resolvers
-erp-kit scaffold --app-root examples resolver <app> <resolver-name>
+erp-kit app generate doc resolver <resolver-name> -p {APP_ROOT}/{APP_NAME}
 ```
 
 Fill scaffolded docs with details from agent extraction results.
@@ -117,15 +117,12 @@ 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
 
-- Story filename: `<actor>--<story-name>.md` (double-dash separator)
-- Story heading: Title Case of story name (after `--`)
-- Screen filename: kebab-case, noun-focused (e.g., `supplier-list.md`)
-- Resolver filename: camelCase action-verb (e.g., `createSupplierInvitation.md`)
+See [erp-kit-app-shared/references/naming-conventions.md](../erp-kit-app-shared/references/naming-conventions.md).
 
 ## Schema Reference
 

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,43 +33,12 @@ 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
 
-| Flow Operation       | Resolver Type | Naming Pattern         |
-| -------------------- | ------------- | ---------------------- |
-| Create/Add entity    | Mutation      | `create<Entity>`       |
-| Update/Modify entity | Mutation      | `update<Entity>`       |
-| Delete/Remove entity | Mutation      | `delete<Entity>`       |
-| Activate entity      | Mutation      | `activate<Entity>`     |
-| Deactivate entity    | Mutation      | `deactivate<Entity>`   |
-| Assign X to Y        | Mutation      | `assign<X>To<Y>`       |
-| Submit/Approve       | Mutation      | `submit<Entity>` etc.  |
-| View/List/Get        | Query         | Built-in (no resolver) |
-
-### Built-in vs Custom
-
-| Category             | Description                              | Implementation       |
-| -------------------- | ---------------------------------------- | -------------------- |
-| **Custom resolvers** | Mutations that call module commands      | Write resolver files |
-| **Built-in queries** | List and get operations for reading data | Automatic, no code   |
-
-Prefer built-in queries over custom resolvers for list/get operations.
-
-### 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`          |
+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.
 
 ### Resolver Content
 
@@ -96,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-4-plan-review/SKILL.md

@@ -160,18 +160,9 @@ Numbered list of actionable fixes, grouped by priority:
 2. Fix broken links
 3. Remove or link orphans
 
-## Link Format Reference
-
-| From          | To            | Format                              |
-| ------------- | ------------- | ----------------------------------- |
-| Business Flow | Story         | `./story/<actor>--<name>.md`        |
-| Business Flow | Actor         | `../../actors/<actor>.md`           |
-| Actor         | Business Flow | `../business-flow/<flow>/README.md` |
-| Story         | Screen        | `../../../screen/<screen>.md`       |
-| Story         | Resolver      | `../../../resolver/<name>.md`       |
-
 ## References
 
+- [Link format reference](../erp-kit-app-shared/references/link-format-reference.md)
 - [Parity report format](references/parity-report-format.md)
 - For plan creation, see erp-kit-app-3-plan
 - For implementation, see erp-kit-app-5-impl-backend

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:
@@ -38,14 +42,7 @@ Read all resolver and screen specs to build a complete picture:
 2. **Screen docs** (`docs/screen/*.md`) — Identify screen types (ListView, Form, DetailView) and their fields/columns/actions
 3. **Command source types** — For each module command the resolver calls, read the input type at `node_modules/@tailor-platform/erp-kit/src/modules/<module>/command/<commandName>.ts`. Do not invent fields that don't exist in the command, and preserve the required/optional distinction.
 
-Classify resolvers into two categories:
-
-| Category             | Description                                                                        | Implementation                                                               |
-| -------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| **Custom resolvers** | Mutations that call module commands (create, update, activate, deactivate, assign) | Write `createResolver()` files                                               |
-| **Built-in queries** | List and get operations for reading data                                           | Handled automatically by `gqlOperations: "query"` in config — no code needed |
-
-Prefer built-in queries over custom resolvers for list/get operations where possible.
+Classify resolvers per [erp-kit-app-shared/references/resolver-classification.md](../erp-kit-app-shared/references/resolver-classification.md).
 
 ### Phase 2: Wire Modules (`src/modules.ts`)
 
@@ -72,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
@@ -83,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`.