@tailor-platform/erp-kit 0.2.1 → 0.3.0

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

@@ -1,111 +0,0 @@
----
-name: erp-kit-module-1-docs
-description: Create ERP module documentation following framework schemas. Use when starting a new module, documenting an existing module, or when user asks to create module docs, feature docs, or design module features. Guides collaborative research, scoping, and iterative feature breakdown.
----
-
-# Module Documentation Workflow
-
-Collaborative workflow for creating ERP module documentation. Human and AI work together through research, scoping, design validation, and iterative refinement.
-
-## Workflow Phases
-
-```
-RESEARCH → SCOPE → DESIGN → CREATE → REVIEW
-```
-
-### Phase 1: Research
-
-Study established ERP solutions for the module domain:
-
-1. **Web search** Odoo, Oracle ERP Cloud, SAP for the domain (e.g., "Odoo inventory management features")
-2. **Fetch documentation** from official sources when available
-3. **Identify** common features, models, workflows, compliance requirements
-4. **Summarize** findings before proceeding
-
-Key ERP references:
-
-- Odoo: https://www.odoo.com/documentation/19.0/applications.html
-- Oracle: https://docs.oracle.com/en/cloud/saas/index.html
-- SAP: Search SAP Docs
-
-### Phase 2: Scope
-
-Present scope options to user. Use AskUserQuestion:
-
-| Option                 | Description                                                             |
-| ---------------------- | ----------------------------------------------------------------------- |
-| **Minimal**            | Core entities only, basic CRUD, no workflows                            |
-| **Core (Recommended)** | Essential features for production use, foundational for other modules   |
-| **Comprehensive**      | Full feature set including advanced workflows, compliance, integrations |
-
-Wait for user selection before proceeding.
-
-### Phase 3: Design
-
-Present features incrementally for validation:
-
-1. **List proposed features** as a table (feature name, purpose)
-2. **Wait for user approval** of feature list
-3. For each feature, briefly describe:
-   - What it does
-   - Key scenarios
-4. **Ask**: "Does this feature breakdown look right?"
-
-Keep descriptions concise (~100-200 words per section). Do not present all details at once.
-
-### Phase 4: Create
-
-Generate documentation following framework schemas.
-
-**File structure:**
-
-```
-modules/<module-name>/
-├── README.md                           # module.yml schema
-└── docs/
-    └── features/
-        └── <feature-name>.md           # feature.yml schema
-```
-
-**Naming conventions:**
-
-- Feature files: kebab-case (e.g., `role-based-access-control.md`)
-- Headings: Title Case
-
-Create with `erp-kit` CLI:
-
-```bash
-erp-kit scaffold --modules-root modules module <module-name>
-erp-kit scaffold --modules-root modules feature <module-name> <feature-name>
-```
-
-### Phase 5: Review
-
-After creating docs, user reviews and may request changes:
-
-**Split detection**: If a feature covers multiple distinct workflows, split into separate feature files.
-
-**Iteration pattern:**
-
-1. User identifies issue (e.g., "X is too broad, split it")
-2. Create new feature file for split-out content
-3. Remove split content from original file
-4. Update README.md feature list if needed
-
-Continue iterating until user approves.
-
-# Framework Schemas Reference
-
-Schemas are bundled in `@tailor-platform/erp-kit`.
-
-## Validation
-
-Always run before completing:
-
-```bash
-pnpm run module:doc:check
-```
-
-## References
-
-- [Module structure](../erp-kit-module-shared/references/structure.md)

package/skills/erp-kit-module-2-feature-breakdown/SKILL.md

@@ -1,76 +0,0 @@
----
-name: erp-kit-module-2-feature-breakdown
-description: Use when breaking down a feature spec into model, command, and query documentation. Triggers on feature implementation planning, creating model docs, creating command docs, creating query docs, or when user references model.yml/command.yml schemas.
----
-
-# Feature Breakdown to Model/Command/Query Docs
-
-Convert feature specifications into structured model, command, and query documentation following framework schemas.
-
-## When to Use
-
-- User has a feature spec (e.g., `docs/features/*.md`) and wants implementation docs
-- User asks to create model, command, or query documentation
-- User references `model.yml` or `command.yml` schemas
-
-## Workflow
-
-```
-ANALYZE → SCAFFOLD → POPULATE → VALIDATE
-```
-
-### 1. Analyze
-
-Read the feature spec and identify:
-
-- **Models**: Entities with state, fields, relationships
-- **Commands**: Operations that change state (look for verbs in state diagrams)
-- **Queries**: Read-only operations for external consumers — lookups, conversions, aggregations. See [CQRS read rule](../erp-kit-module-shared/references/commands.md#command-side-reads-cqrs-separation)
-
-### 2. Scaffold
-
-For each model, command, and query, scaffold the documentation files using `erp-kit` CLI:
-
-```bash
-erp-kit scaffold --modules-root modules model <module-name> <model-name>
-erp-kit scaffold --modules-root modules command <module-name> <command-name>
-erp-kit scaffold --modules-root modules query <module-name> <query-name>
-```
-
-### 3. Populate
-
-Fill in the scaffolded docs with details analyzed from Step 1.
-
-### 4. Validate
-
-Run `pnpm run module:doc:check` and fix any violations.
-
-## Schema Quick Reference
-
-Schemas are bundled in `@tailor-platform/erp-kit` (model.yml, command.yml).
-
-## Common Patterns
-
-| Feature Element       | Documentation Type               |
-| --------------------- | -------------------------------- |
-| Entity with fields    | Model doc                        |
-| State machine         | Model doc with State Transitions |
-| Verb in state diagram | Command doc                      |
-| CRUD operation        | Command doc                      |
-| Validation logic      | Command doc Business Rules       |
-| Data lookup           | Query doc                        |
-| Unit/currency convert | Query doc                        |
-| Computed aggregation  | Query doc                        |
-
-## Validation
-
-Always run before completing:
-
-```bash
-pnpm run module:doc:check
-```
-
-## References
-
-- [Command naming convention](references/naming.md)
-- [Module structure](../erp-kit-module-shared/references/structure.md)

package/skills/erp-kit-module-3-doc-review/SKILL.md

@@ -1,294 +0,0 @@
----
-name: erp-kit-module-3-doc-review
-description: Review feature parity between feature documentation and command/model/query documentation. Use when validating that all feature scenarios are covered by command docs, all read operations have query docs, and that all required models exist.
----
-
-# Feature Parity Review Workflow
-
-Review **documentation consistency** between feature specs and command/model/query docs.
-
-## Purpose
-
-Verify that feature documentation (high-level business requirements) is properly covered by command documentation (write operations), query documentation (read operations), and model documentation (data structures).
-
-```
-Feature Docs (What)  →  Command Docs (How)  →  Model Docs (With What)
-     ↓                        ↓                       ↓
-  Scenarios              Business Rules          Data Structures
-  Process Flows          Error Scenarios         Relationships
-  Test Cases             Process Flows           Constraints
-                         Query Docs (Read)
-                             ↓
-                         Lookups, Conversions
-                         Aggregations
-```
-
-## When to Use
-
-- After writing feature documentation, check for gaps in command/model/query documentation
-- After writing command/model/query documentation, verify consistency with features
-- Quality check during documentation review
-
-## Workflow
-
-```
-FEATURE DOCS → COMMAND DOCS → QUERY DOCS → MODEL DOCS → COMPARE → REPORT
-```
-
-## Step-by-Step
-
-### 1. Read Feature Documentation
-
-Read ALL feature docs:
-
-```
-modules/<module-name>/docs/features/*.md
-```
-
-### 2. Read Command Documentation
-
-Read ALL command docs:
-
-```
-modules/<module-name>/docs/commands/*.md
-```
-
-### 3. Read Query Documentation
-
-Read ALL query docs:
-
-```
-modules/<module-name>/docs/queries/*.md
-```
-
-### 4. Read Model Documentation
-
-Read ALL model docs:
-
-```
-modules/<module-name>/docs/models/*.md
-```
-
-### 5. Feature → Command Parity Check
-
-For each feature's scenarios and test cases:
-
-| Check Item             | Question                                                                   |
-| ---------------------- | -------------------------------------------------------------------------- |
-| Command existence      | Does a command doc exist to implement the scenario?                        |
-| Business rule coverage | Are feature test cases covered by command business rules?                  |
-| Error handling         | Are expected error cases from feature included in command error scenarios? |
-| Process flow alignment | Does feature process flow match command process flow?                      |
-
-#### How to Check
-
-1. List all scenario patterns from feature
-2. Identify required operations (verbs) for each scenario: "Add", "Update", "Delete", "Set default", etc.
-3. Verify corresponding command doc exists
-4. Map feature test cases to command business rules / error scenarios
-
-### 6. Feature → Query Parity Check
-
-For each read operation implied by the feature:
-
-| Check Item      | Question                                                              |
-| --------------- | --------------------------------------------------------------------- |
-| Query existence | Does a query doc exist for lookups, conversions, or aggregations?     |
-| Input coverage  | Are all lookup dimensions documented (by id, by unique field, by FK)? |
-| Error handling  | Are error scenarios for missing data documented?                      |
-
-#### How to Check
-
-1. Identify read-only operations in the feature: "look up", "get", "list", "convert", "calculate"
-2. Verify corresponding query doc exists in `docs/queries/`
-3. Check that query docs have error scenarios where applicable
-
-### 7. Feature → Model Parity Check
-
-For each entity mentioned in feature:
-
-| Check Item       | Question                                                           |
-| ---------------- | ------------------------------------------------------------------ |
-| Model existence  | Does a model doc exist for entities mentioned in feature?          |
-| State management | Do feature state transitions match model state transitions?        |
-| Relationships    | Are relationships shown in feature defined in model relationships? |
-
-### 8. Command → Model Consistency Check
-
-For each command doc:
-
-| Check Item                 | Question                                                       |
-| -------------------------- | -------------------------------------------------------------- |
-| Target model               | Does a model doc exist for the model that command operates on? |
-| State transition alignment | Do state changes by command match model state transitions?     |
-
-### 9. Report Findings
-
-```markdown
-## Feature Parity Review Report
-
-**Module:** <module-name>
-
----
-
-### 1. Feature → Command Coverage
-
-| Feature     | Scenarios   | Required Commands                  | Documented Commands       | Gap                |
-| ----------- | ----------- | ---------------------------------- | ------------------------- | ------------------ |
-| <feature-1> | N scenarios | <cmd-a>, <cmd-b>, <cmd-c>, <cmd-d> | <cmd-a>, <cmd-b>, <cmd-c> | ❌ <cmd-d> missing |
-| <feature-2> | N scenarios | <cmd-e>, <cmd-f>, <cmd-g>          | -                         | ❌ No command docs |
-
----
-
-### 2. Feature → Model Coverage
-
-| Feature     | Required Models      | Documented Models    | Gap |
-| ----------- | -------------------- | -------------------- | --- |
-| <feature-1> | <Model-A>            | <Model-A>            | ✅  |
-| <feature-2> | <Model-B>, <Model-A> | <Model-B>, <Model-A> | ✅  |
-| <feature-3> | <Model-C>, <Model-A> | <Model-C>, <Model-A> | ✅  |
-
----
-
-### 3. Test Case → Business Rule Mapping
-
-| Feature     | Test Case                                  | Covered by Command      | Status            |
-| ----------- | ------------------------------------------ | ----------------------- | ----------------- |
-| <feature-1> | "<test case description from feature doc>" | <cmd-a> (business rule) | ✅                |
-| <feature-1> | "<test case description from feature doc>" | <cmd-c> (business rule) | ✅                |
-| <feature-2> | "<test case description from feature doc>" | -                       | ❌ No command doc |
-
----
-
-### 4. Missing Documentation
-
-#### Missing Command Docs
-
-| Feature     | Expected Command | Purpose               |
-| ----------- | ---------------- | --------------------- |
-| <feature-2> | <cmd-e>          | <purpose description> |
-| <feature-2> | <cmd-f>          | <purpose description> |
-| <feature-2> | <cmd-g>          | <purpose description> |
-
-#### Missing Query Docs
-
-| Feature     | Expected Query | Purpose               |
-| ----------- | -------------- | --------------------- |
-| <feature-1> | <query-a>      | <purpose description> |
-
-#### Missing Model Docs
-
-(none found)
-
----
-
-### 5. Inconsistencies
-
-| Type                      | Location                               | Issue                                                             |
-| ------------------------- | -------------------------------------- | ----------------------------------------------------------------- |
-| State transition mismatch | <feature-1> feature vs <Model-A> model | Feature shows "<cmd-x>" but no command doc exists                 |
-| Missing error scenario    | <feature-2> feature                    | "<error case from test cases>" has no corresponding command error |
-
----
-
-### 6. Summary
-
-| Aspect                     | Status | Details                                     |
-| -------------------------- | ------ | ------------------------------------------- |
-| Feature → Command Coverage | ⚠️     | X/Y features have complete command coverage |
-| Feature → Query Coverage   | ⚠️     | X/Y read operations have query docs         |
-| Feature → Model Coverage   | ✅     | All required models documented              |
-| Test Case Coverage         | ⚠️     | X/Y test cases mapped to business rules     |
-| Documentation Consistency  | ⚠️     | N inconsistencies found                     |
-
-### 7. Recommendations
-
-1. **Create missing command docs:**
-   - List all missing commands grouped by feature
-
-2. **Add missing business rules to existing command docs:**
-   - Feature test cases not yet mapped to command business rules
-3. **Resolve inconsistencies:**
-   - Align state transitions between feature and model docs
-```
-
-## Common Gaps
-
-### Feature → Command
-
-- **Orphaned scenarios**: Feature describes operation but no command doc exists
-- **Missing CRUD**: Feature implies create/update/delete but only some are documented
-- **Implicit commands**: Feature scenario requires helper command not documented
-- **Default handling**: Feature mentions "default" selection but no setDefault command
-
-### Feature → Query
-
-- **Missing query docs**: Feature implies read operation but no query doc exists
-- **Missing conversions**: Feature mentions unit/currency conversion but no query doc
-- **Missing lookups**: Feature requires data retrieval not covered by a query doc
-
-### Feature → Model
-
-- **Missing models**: Feature references entity with no model doc
-- **State mismatch**: Feature shows states not in model's state diagram
-- **Relationship gaps**: Feature implies relationship not in model doc
-
-### Test Case → Business Rule
-
-- **Uncovered test cases**: Feature test case has no corresponding business rule
-- **Missing error scenarios**: Feature error case not in command's error scenarios
-- **Validation gaps**: Feature constraint not enforced by any command
-
-## Quick Reference: Extraction Patterns
-
-### From Feature Docs
-
-```markdown
-## Scenario Patterns
-
-- **Add <entity>**: ... → Command: add<Entity> / create<Entity>
-- **Change default <entity>**: ... → Command: setDefault<Entity>
-
-## Test Cases
-
-- Adding a <entity> with valid data creates it in active status
-  → Business rule in add<Entity>
-- Only one <entity> can be default per <parent> at a time
-  → Business rule in setDefault<Entity>
-```
-
-### Expected Command Docs for Feature
-
-See [command naming convention](../erp-kit-module-2-feature-breakdown/references/naming.md) for the full rule, disambiguation guide, and banned verbs.
-
-| Feature Operation    | Expected Command Doc | Notes                          |
-| -------------------- | -------------------- | ------------------------------ |
-| "Create X" / "Add X" | `createX`            | Never `addX`                   |
-| "Update X"           | `updateX`            |                                |
-| "Delete X"           | `deleteX`            | Hard delete only               |
-| "Deactivate X"       | `deactivateX`        | Soft-disable (reversible)      |
-| "Activate X"         | `activateX`          | Enable entity                  |
-| "Reactivate X"       | `reactivateX`        | Re-enable after deactivation   |
-| "Set default X"      | `setDefaultX`        | Singular value/reference       |
-| "Assign X to Y"      | `assignXToY`         | Never `addXToY`                |
-| "Remove X from Y"    | `removeXFromY`       | Generic relationship unlinking |
-| "Revoke X from Y"    | `revokeXFromY`       | RBAC/security domain only      |
-| "Move X"             | `moveX`              | Hierarchy position change      |
-| "Log X"              | `logX`               | Append-only audit/event        |
-
-**Banned verbs** — flag as naming violation if found:
-`archive`, `unarchive`, `disable`, `enable`, `add...To...`, `unlink`
-
-### Expected Query Docs for Feature
-
-| Feature Operation | Expected Query Doc  |
-| ----------------- | ------------------- |
-| "Get X"           | GetX                |
-| "Look up X by Y"  | GetX (with Y input) |
-| "List X by Y"     | ListXsByY           |
-| "Convert X"       | ConvertX            |
-| "Calculate X"     | CalculateX          |
-
-## References
-
-For implementation patterns (models, commands, testing), see erp-kit-module-4-tdd.

package/skills/erp-kit-module-4-tdd/SKILL.md

@@ -1,94 +0,0 @@
----
-name: erp-kit-module-4-tdd
-description: Use when implementing features in any module under modules/. Triggers on TDD workflow, domain command implementation, adding new database models, creating test fixtures, or implementing business logic commands.
----
-
-# TDD Implementation for Module Development
-
-Guide for implementing features in modules using Test-Driven Development.
-
-## When to Use
-
-- Implementing new domain commands in any module
-- Implementing read-only queries in any module
-- Adding database models with `@tailor-platform/sdk`
-- Creating tests with `@tailor-platform/erp-kit` testing utilities
-- Implementing business logic (CRUD, state transitions, relationships)
-
-## Workflow
-
-```
-DOCS → MODELS → GENERATE → FIXTURES → TESTS → IMPLEMENT → EXPORT → VERIFY
-```
-
-## Step-by-Step
-
-### 1. Write Command/Query Docs
-
-Write markdown specs under `docs/commands/*.md` and `docs/queries/*.md`. These are the source of truth for error scenarios, permissions, and generated code. See erp-kit-module-1-docs, erp-kit-module-2-feature-breakdown, and erp-kit-module-3-doc-review for documentation workflow.
-
-### 2. Database Models (`db/`)
-
-**Read [models rules](references/models.md) and [db-relations rules](references/db-relations.md) before writing any model.**
-
-Key patterns: factory function, `db.fields.timestamps()`, `.description()` on fields, `.relation()` for foreign keys.
-
-### 3. Generate Code
-
-**Read [generated code rules](references/generated-code.md) for what gets generated and what you write by hand.**
-
-```bash
-# Generate kysely types from models
-pnpm generate
-
-# Generate errors, permissions, and command/query shells from docs
-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.
-
-### 4. Test Fixtures (`testing/fixtures.ts`)
-
-**Read [testing rules](../erp-kit-module-shared/references/testing.md) before writing fixtures or tests.**
-
-### 5. Write Tests First (`command/*.test.ts`)
-
-Same reference: [testing rules](../erp-kit-module-shared/references/testing.md).
-
-Key patterns: `createMockDb<DB>()`, fixed IDs `"entity-1"`, cover all doc branches.
-
-### 6. Implement Commands (`command/*.ts`)
-
-**Read [commands rules](../erp-kit-module-shared/references/commands.md) before implementing.**
-
-Key patterns: export `run` function, generated shell wraps with `defineCommand(permissions.xxx, run)`, generic `CF` for custom fields, validate → query → mutate.
-
-### 7. Implement Queries (`query/*.ts`)
-
-**Read [queries rules](../erp-kit-module-shared/references/queries.md) before implementing.**
-
-Key patterns: `defineQuery`, `ReadonlyDB<DB>`, `QueryContext`. Generated queries handle simple lookups; write custom queries for joins, aggregations, complex filters.
-
-### 8. Export (`index.ts`)
-
-**Read [exports rules](references/exports.md) for export order.**
-
-### 9. Verify
-
-```bash
-pnpm generate   # Regenerate types if models changed
-pnpm lint       # Check code style
-pnpm typecheck  # Verify TypeScript types
-pnpm test       # Run all tests
-```
-
-## References
-
-- [Module structure](../erp-kit-module-shared/references/structure.md)
-- [Model patterns](references/models.md)
-- [Database relations](references/db-relations.md)
-- [Command patterns](../erp-kit-module-shared/references/commands.md)
-- [Query patterns](../erp-kit-module-shared/references/queries.md)
-- [Generated code](references/generated-code.md)
-- [Testing patterns](../erp-kit-module-shared/references/testing.md)
-- [Export order](references/exports.md)

package/skills/erp-kit-module-4-tdd/references/exports.md

@@ -1,8 +0,0 @@
-# Module Exports
-
-Export order:
-
-1. `defineModule` from module.ts
-2. Generated types (enum values + types separately)
-3. Error classes from `lib/errors.generated` (for typed catch blocks)
-4. Domain functions with input types