@tailor-platform/erp-kit 0.2.2 → 0.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/erp-kit",
-  "version": "0.2.2",
+  "version": "0.3.0",
   "description": "Opinionated ERP toolkit for building business applications on Tailor Platform",
   "license": "MIT",
   "bin": {
@@ -68,6 +68,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
@@ -40,23 +40,32 @@ 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.
 
@@ -70,6 +79,8 @@ At Tier 2, story files do not exist yet. Use `- TBD` as a placeholder to avoid b
 pnpm run app:doc:check
 ```
 
+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,18 @@ 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.**
+
 ## 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,17 @@ 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.
+
 ## 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

@@ -89,13 +89,13 @@ After approval, 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.
@@ -122,10 +122,7 @@ pnpm run app:doc:check
 
 ## 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

@@ -26,25 +26,7 @@ For each business flow step that modifies data:
 
 ### 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.
+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
 

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

@@ -38,14 +38,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`)
 

package/skills/erp-kit-app-shared/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: erp-kit-app-shared
+description: Shared references for erp-kit app skills. Not invoked directly — referenced by erp-kit-app-1 through erp-kit-app-7.
+---
+
+# erp-kit-app-shared
+
+Canonical reference files shared across app skills. Individual skills reference these instead of maintaining their own copies.
+
+## References
+
+- [Schema constraints](references/schema-constraints.md) — H1 heading rules and validation constraints enforced by `erp-kit app check`
+- [Naming conventions](references/naming-conventions.md) — File and heading naming patterns for all doc types
+- [Link format reference](references/link-format-reference.md) — Canonical doc-to-doc link formats across tiers
+- [Resolver classification](references/resolver-classification.md) — Custom vs built-in resolver decision table and operation mapping

package/skills/erp-kit-app-shared/references/link-format-reference.md

@@ -0,0 +1,13 @@
+# Link Format Reference
+
+Canonical link formats used across all documentation tiers.
+
+## Doc-to-Doc Links
+
+| 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`       |

package/skills/erp-kit-app-shared/references/naming-conventions.md

@@ -0,0 +1,21 @@
+# Naming Conventions
+
+## File Naming
+
+| Doc Type | Pattern                              | Example                          |
+| -------- | ------------------------------------ | -------------------------------- |
+| Actor    | kebab-case                           | `sales-representative.md`        |
+| Flow     | kebab-case directory                 | `employee-onboarding/README.md`  |
+| Story    | `<actor>--<story-name>.md`           | `admin--create-user.md`          |
+| Screen   | kebab-case, noun-focused             | `supplier-list.md`               |
+| Resolver | camelCase action-verb                | `createSupplierInvitation.md`    |
+
+## Heading Conventions
+
+See [schema-constraints.md](schema-constraints.md) for H1 heading rules enforced by `erp-kit app check`.
+
+Additional conventions:
+
+- Story heading: Title Case of story name after `--` prefix (e.g., `admin--create-user.md` → `# Create User`)
+- Screen heading: Title Case of filename slug
+- Resolver heading: camelCase matching filename

package/skills/erp-kit-app-shared/references/resolver-classification.md

@@ -0,0 +1,23 @@
+# Resolver Classification
+
+## Custom vs Built-in
+
+| 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.
+
+## 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) |

package/skills/erp-kit-app-shared/references/schema-constraints.md

@@ -0,0 +1,25 @@
+# Schema Constraints
+
+Rules enforced by `erp-kit app check`. **Never recommend changes that violate them.**
+
+## H1 Heading Rules
+
+| Doc Type      | H1 Rule                                              | Example                                                  |
+| ------------- | ---------------------------------------------------- | -------------------------------------------------------- |
+| README.md     | Must be `# README` (literal)                         | `# README`                                               |
+| Actor         | Slug must match filename                             | `admin.md` → `# Admin`, `sales-rep.md` → `# Sales Rep`  |
+| Business Flow | Kebab-case matching folder name (`[a-zA-Z0-9_\-]+`)  | `employee-onboarding/README.md` → `# employee-onboarding` |
+| Story         | Slug matches filename after actor prefix removal     | `admin--create-user.md` → `# Create User`               |
+
+## Requirements Structure
+
+The `## Industry Context` section contains `### Target Industry` and `### Domain Terminology` subsections. Requirements are bare list items under `### Domain Terminology` — do **not** add a separate `## Requirements` heading.
+
+## Naming Conventions
+
+- Files: kebab-case (e.g., `sales-representative.md`)
+- Business flow H1 headings are kebab-case — do **not** flag them as inconsistent with title-case actor headings. They follow different schemas.
+
+## Validation Notes
+
+- `app check` outputs "No matching files found" for doc types that don't exist yet (e.g., stories at Tier 2, screens at Tier 3). This is expected.

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

@@ -72,7 +72,7 @@ The final feature set becomes the union of all `Include` features. Iterate until
 First, scaffold the module if it doesn't exist:
 
 ```bash
-erp-kit scaffold --modules-root <MODULES_ROOT> module <module-name>
+erp-kit module init <module-name> <MODULES_ROOT>/<module-name>
 ```
 
 Then, for each `Include` feature, launch an Agent:

package/skills/erp-kit-module-1-requirements/references/feature-doc.md

@@ -14,7 +14,7 @@ Write a feature documentation file for the {{FEATURE_NAME}} feature.
 1. Read existing feature docs in `{{MODULES_ROOT}}/{{MODULE_NAME}}/docs/features/` for style reference
 2. Scaffold the file:
    ```bash
-   erp-kit scaffold --modules-root {{MODULES_ROOT}} feature {{MODULE_NAME}} {{FEATURE_SLUG}}
+   erp-kit module generate doc feature {{FEATURE_SLUG}} -p {{MODULES_ROOT}}/{{MODULE_NAME}}
    ```
 3. Fill in the scaffolded file following the structure below
 

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

@@ -43,12 +43,12 @@ Wait for user approval.
 
 ## Step 3: Scaffold & Populate
 
-After approval, scaffold using `erp-kit` CLI:
+After approval, scaffold using `erp-kit` CLI. **Names must be PascalCase** (see [naming convention](references/naming.md)):
 
 ```bash
-erp-kit scaffold --modules-root <MODULES_ROOT> model <module-name> <model-name>
-erp-kit scaffold --modules-root <MODULES_ROOT> command <module-name> <command-name>
-erp-kit scaffold --modules-root <MODULES_ROOT> query <module-name> <query-name>
+erp-kit module generate doc model ModelName -p <MODULES_ROOT>/<module-name>
+erp-kit module generate doc command CommandName -p <MODULES_ROOT>/<module-name>
+erp-kit module generate doc query QueryName -p <MODULES_ROOT>/<module-name>
 ```
 
 Fill in the scaffolded docs with details from the extraction in Step 2.
@@ -103,5 +103,5 @@ pnpm run module:doc:check
 
 ## References
 
-- [Command naming convention](references/naming.md)
+- [Naming convention (PascalCase files + command verbs)](references/naming.md)
 - [Module structure](../erp-kit-module-shared/references/structure.md)

package/skills/erp-kit-module-3-plan/references/naming.md

@@ -1,4 +1,18 @@
-# Command Naming Convention
+# Naming Convention
+
+## Doc File Names — PascalCase
+
+Documentation files under `docs/models/`, `docs/commands/`, and `docs/queries/` **must** use PascalCase. The code generator derives the camelCase command/query name by lowercasing the first character of the file name.
+
+| Doc type | File name format  | Example file       | Derived name    |
+| -------- | ----------------- | ------------------ | --------------- |
+| Model    | `{Entity}.md`     | `Product.md`       | —               |
+| Command  | `{VerbEntity}.md` | `CreateProduct.md` | `createProduct` |
+| Query    | `{VerbEntity}.md` | `GetProduct.md`    | `getProduct`    |
+
+**Never use kebab-case** (`create-product.md`) — the generator will produce a broken name (`create-product`).
+
+## Command Naming Convention
 
 Commands use imperative `{verb}{Entity}` format. Use this canonical verb vocabulary when scaffolding commands.
 

package/skills/erp-kit-module-5-impl/SKILL.md

@@ -17,7 +17,7 @@ Implement features in modules using Test-Driven Development with per-item agent
 ## Workflow
 
 ```
-SETUP → DB MODELS (agents) → GENERATE → COMMANDS (agents) → QUERIES (agents) → EXPORT → VERIFY
+SETUP → GENERATE → DB MODELS (agents) → COMMANDS (agents) → QUERIES (agents) → EXPORT → VERIFY
 ```
 
 ## Step 1: Setup
@@ -32,7 +32,17 @@ Define shared context:
 
 Verify at least one doc type exists. If none, stop with: "No docs found for module <MODULE_NAME>. Run steps 1-4 first."
 
-## Step 2: DB Models — Agent per model
+## Step 2: Generate Code from Docs
+
+Run generation first to create `.generated.ts` files (error classes, permission definitions, command/query shells) before implementing any code:
+
+```bash
+erp-kit module generate code -p <MODULES_ROOT>/<module>
+```
+
+Never edit these generated files.
+
+## Step 3: DB Models — Agent per model
 
 **Read [models rules](references/models.md) and [db-relations rules](references/db-relations.md) before dispatching.**
 
@@ -51,14 +61,6 @@ After all model agents complete, run:
 pnpm generate
 ```
 
-## Step 3: Generate Code from Docs
-
-```bash
-erp-kit module generate code --root <root> <module>
-```
-
-Generated `.generated.ts` files provide: error classes, permission definitions, and command/query shells. Never edit these files.
-
 ## Step 4: Commands — Agent per command
 
 **Read [commands rules](../erp-kit-module-shared/references/commands.md) and [testing rules](../erp-kit-module-shared/references/testing.md) before dispatching.**

package/skills/erp-kit-module-5-impl/references/generated-code.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Run `erp-kit module generate code --root <modules-dir> <module-name>` to generate deterministic `.generated.ts` files from command and query documentation.
+Run `erp-kit module generate code -p <modules-dir>/<module-name>` to generate deterministic `.generated.ts` files from command and query documentation.
 
 ## What gets generated
 
@@ -21,7 +21,7 @@ Run `erp-kit module generate code --root <modules-dir> <module-name>` to generat
 1. Write command/query docs (skills 1-3)
 2. Write db models (skill 4, step 2)
 3. Run `pnpm generate` for kysely types
-4. Run `erp-kit module generate code --root <root> <module>`
+4. Run `erp-kit module generate code -p <root>/<module>`
 5. Implement business logic in `.ts` files importing from `.generated.ts`
 
 ## What you still write by hand

package/skills/erp-kit-module-6-impl-review/SKILL.md

@@ -175,7 +175,7 @@ Numbered list of actionable fixes, grouped by priority:
 
 1. Add missing model fields/states (highest priority)
 2. Implement missing business rules
-3. Define missing error classes (re-run `erp-kit module generate code`)
+3. Define missing error classes (re-run `erp-kit module generate code -p <path>`)
 4. Add missing test cases
 5. Fix inconsistencies
 

package/skills/erp-kit-module-6-impl-review/references/error-implementation-parity.md

@@ -72,7 +72,7 @@ For each error scenario documented in command docs:
 
 ## Common Gap Patterns
 
-- **Missing error class**: Error code in doc but no generated class (re-run `erp-kit module generate code`)
+- **Missing error class**: Error code in doc but no generated class (re-run `erp-kit module generate code -p <path>`)
 - **Error not returned**: Generated class exists but command code doesn't return it
 - **Error not imported**: Command uses inline error instead of generated class
 - **Missing error test**: Error is returned in code but no test asserts it

package/skills/erp-kit-module-6-impl-review/references/errors.md

@@ -7,4 +7,4 @@ Errors are **generated** from command/query documentation into `lib/errors.gener
 - Every error code in `docs/commands/*.md` has a corresponding class in `lib/errors.generated.ts`
 - Command implementations import errors from `../lib/errors.generated`
 - Generated error codes are prefixed with the module name (e.g., doc code `UNIT_NOT_FOUND` becomes `PRIMITIVES_UNIT_NOT_FOUND`)
-- If errors are missing, re-run `erp-kit module generate code`
+- If errors are missing, re-run `erp-kit module generate code -p <path>`

package/skills/erp-kit-module-shared/references/errors.md

@@ -5,7 +5,7 @@ Errors are **generated** from command/query documentation. Do not write `lib/err
 ## How it works
 
 1. Write error scenarios in `docs/commands/*.md` as `CODE: Description` pairs
-2. Run `erp-kit module generate code` to produce `lib/errors.generated.ts`
+2. Run `erp-kit module generate code -p <path>` to produce `lib/errors.generated.ts`
 3. Import generated errors in your command implementations
 
 ## Naming convention (in docs)

package/skills/erp-kit-module-shared/references/queries.md

@@ -2,7 +2,7 @@
 
 ## Generated Query Shells
 
-Run `erp-kit module generate code` to generate query shells from `docs/queries/*.md`. Each generated shell wraps your `run` function with `defineQuery`.
+Run `erp-kit module generate code -p <path>` to generate query shells from `docs/queries/*.md`. Each generated shell wraps your `run` function with `defineQuery`.
 
 ### Generated shell example
 

package/skills/erp-kit-module-shared/references/structure.md

@@ -1,6 +1,6 @@
 # Module Directory Structure
 
-This structure is automatically scaffolded by `erp-kit module scaffold module <name>`.
+This structure is automatically scaffolded by `erp-kit module init <name> <dir>`.
 
 ```
 {module}/

package/skills/erp-kit-update/SKILL.md

@@ -19,8 +19,8 @@ Ask the user:
 
 1. **What changed?** (free-text description of the change)
 2. **Where?** Determine domain from the target:
-   - `examples/<app>/` → **App workflow** (skills matching `erp-kit-app-*`)
-   - `modules/<module>/` → **Module workflow** (skills matching `erp-kit-module-*`)
+   - App directory (e.g., `{APP_ROOT}/{APP_NAME}/`) → **App workflow** (skills matching `erp-kit-app-*`)
+   - Module directory (e.g., `{MODULE_ROOT}/{MODULE_NAME}/`) → **Module workflow** (skills matching `erp-kit-module-*`)
 
 If the user names a specific app or module, confirm the path. If ambiguous, check both directories.