@tailor-platform/erp-kit 0.2.1 → 0.2.2

package/skills/erp-kit-app-2-breakdown/SKILL.md

@@ -1,88 +0,0 @@
----
-name: erp-kit-app-2-breakdown
-description: Create Tier 3 documentation (stories, screens) by breaking down business flows. Use after completing Tier 1-2 documentation with erp-kit-app-1-requirements.
----
-
-# Requirements Breakdown Workflow
-
-Break down Tier 2 business flows into Tier 3 documentation: User Stories and Screens.
-
-## Prerequisites
-
-Tier 1-2 documentation must exist:
-
-- `README.md` (requirements)
-- `docs/actors/*.md` (actor definitions)
-- `docs/business-flow/*/README.md` (business workflows)
-
-## Workflow Phases
-
-```
-ANALYZE → BREAKDOWN → CREATE → VALIDATE
-```
-
-### Phase 1: Analyze
-
-Review existing Tier 2 documentation:
-
-1. **Read** all business flow files in `docs/business-flow/`
-2. **Identify** flow steps that represent user actions
-3. **Map** each step to the responsible actor
-4. **Note** data inputs/outputs for each step
-
-### Phase 2: Breakdown
-
-For each business flow, decompose into stories and screens:
-
-| Flow Element     | Maps To     |
-| ---------------- | ----------- |
-| User action step | Story       |
-| UI requirement   | Screen      |
-| Actor in flow    | Story actor |
-
-### Phase 3: Create
-
-Generate documentation using `erp-kit` CLI:
-
-```bash
-# Tier 3: Stories
-erp-kit app scaffold story <app> <flow>/<actor>--<story> --root examples
-
-# Tier 3: Screens
-erp-kit app scaffold screen <app> <screen-name> --root examples
-```
-
-**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`)
-
-**After creating stories**, replace `- TBD` placeholders in the `## Stories` section of each business flow README with actual links:
-
-```markdown
-- [Story Title](./story/<actor>--<story-name>.md)
-```
-
-### Phase 4: Validate
-
-```bash
-pnpm run app:doc:check
-```
-
-## Schema Reference
-
-| Schema       | Tier | Output Path                                          |
-| ------------ | ---- | ---------------------------------------------------- |
-| `story.yml`  | 3    | `docs/business-flow/<flow>/story/<actor>--<name>.md` |
-| `screen.yml` | 3    | `docs/screen/<name>.md`                              |
-
-## Tips
-
-- One business flow typically produces 3-8 stories
-- Stories should be completable in a single user session
-- Screens can be shared across multiple stories
-
-## Next Step
-
-After completing Tier 3, use `/erp-kit-app-3-doc-review` to validate documentation parity.

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

@@ -1,112 +0,0 @@
----
-name: erp-kit-app-3-doc-review
-description: Review documentation parity between Tier 2 (business flows, actors) and Tier 3 (stories, screens). Use when validating that all business flow steps have corresponding stories, and that screens are properly linked.
----
-
-# Documentation Parity Review Workflow
-
-Review **documentation consistency** between Tier 2 and Tier 3 documentation.
-
-## Purpose
-
-```
-Business Flow (Tier 2)  →  Stories (Tier 3)  →  Screens (Tier 3)
-        ↓                        ↓                     ↓
-   Flow Steps              User Actions           UI Components
-   Actors Involved         Scenario Patterns      Screen Types
-```
-
-## When to Use
-
-- After writing Tier 3 documentation, check for gaps
-- Before proceeding to Tier 4 (implementation spec)
-- Quality check during documentation review
-
-## Workflow
-
-```
-READ DOCS → PARITY CHECKS → REPORT
-```
-
-### Step 1: Read All Documentation
-
-```
-examples/<app-name>/docs/business-flow/*/README.md    # Flows
-examples/<app-name>/docs/business-flow/*/story/*.md   # Stories
-examples/<app-name>/docs/screen/*.md                  # Screens
-examples/<app-name>/docs/actors/*.md                  # Actors
-```
-
-### Step 2: Parity Checks
-
-#### Business Flow → Story
-
-| Check           | Question                                        |
-| --------------- | ----------------------------------------------- |
-| Story existence | Does each flow step have a corresponding story? |
-| Actor coverage  | Are all actors in flow represented in stories?  |
-| Link validity   | Do story links in flow README resolve?          |
-
-#### Actor → Business Flow
-
-| Check          | Question                                  |
-| -------------- | ----------------------------------------- |
-| Flow existence | Do all flows in "Authorized Flows" exist? |
-| Link validity  | Do flow links resolve correctly?          |
-
-#### Story → Screen
-
-| Check            | Question                           |
-| ---------------- | ---------------------------------- |
-| Screen existence | Do all screens in story exist?     |
-| Link validity    | Do screen links resolve correctly? |
-
-#### Orphan Detection
-
-| Check          | Question                                   |
-| -------------- | ------------------------------------------ |
-| Orphan stories | Stories not linked from any business flow? |
-| Orphan screens | Screens not referenced by any story?       |
-| Orphan actors  | Actors not participating in any flow?      |
-
-### Step 3: Report
-
-```markdown
-## Documentation Parity Review Report
-
-**Application:** <app-name>
-
-### Summary
-
-| Aspect                | Status   | Details           |
-| --------------------- | -------- | ----------------- |
-| Business Flow → Story | ✅/⚠️/❌ | X/Y flows covered |
-| Actor → Flow          | ✅/⚠️/❌ | All links valid   |
-| Story → Screen        | ✅/⚠️/❌ | X missing screens |
-| Orphan Detection      | ✅/⚠️/❌ | N orphans found   |
-
-### Gaps Found
-
-- [ ] Missing: <item>
-- [ ] Broken link: <source> → <target>
-- [ ] Orphan: <file>
-
-### Recommendations
-
-1. Create missing: ...
-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`       |
-
-## Next Step
-
-After fixing all issues, use `/erp-kit-app-4-impl-spec` to create implementation specifications from screen and story documentation.

package/skills/erp-kit-app-4-impl-spec/SKILL.md

@@ -1,116 +0,0 @@
----
-name: erp-kit-app-4-impl-spec
-description: Create Tier 4 documentation (resolvers) for GraphQL operations. Use after completing documentation review with erp-kit-app-3-doc-review.
----
-
-# Implementation Spec Workflow
-
-Create Tier 4 documentation: GraphQL Resolvers (mutations and queries).
-
-## Prerequisites
-
-Tier 1-3 documentation must exist:
-
-- `README.md` (requirements)
-- `docs/actors/*.md` (actors)
-- `docs/business-flow/*/README.md` (flows)
-- `docs/business-flow/*/story/*.md` (stories)
-- `docs/screen/*.md` (screens)
-
-## Workflow Phases
-
-```
-ANALYZE → IDENTIFY → CHECK MODULES → CREATE → VALIDATE
-```
-
-### Phase 1: Analyze
-
-Read all story files and identify:
-
-1. **Operations** that modify data → mutations
-2. **Operations** that retrieve data → queries
-3. **Error scenarios** for each operation
-
-### Phase 2: Identify
-
-Map stories to resolvers:
-
-| Story Element        | Resolver Type |
-| -------------------- | ------------- |
-| Create/Update/Delete | Mutation      |
-| View/List/Search     | Query         |
-| Real-time updates    | Subscription  |
-
-**Naming:** Use camelCase action-verb names: `create`, `update`, `delete`, `submit`, `approve`
-
-### Phase 3: Check Module Dependencies
-
-Resolvers reference module commands. Before creating resolver docs, verify required modules exist.
-
-**Check existing modules:**
-
-```bash
-ls packages/erp-kit/src/modules/
-```
-
-**Check module commands:**
-
-```bash
-ls packages/erp-kit/src/modules/<module-name>/docs/commands/
-```
-
-**Map resolvers to modules:**
-
-| Resolver Operation | Typical Module        |
-| ------------------ | --------------------- |
-| User invite/roles  | `user-management`     |
-| Supplier CRUD      | `supplier-management` |
-| Document handling  | `document-management` |
-| Task workflows     | `task-management`     |
-
-**If modules don't exist:**
-
-1. **Identify needed modules** - Group resolver operations by domain
-2. **Create module docs first** - Use `erp-kit-module-1-docs` skill
-3. **Return to Tier 4** - After modules have documented commands
-
-```
-Tier 4 blocked → Create modules → Return to Tier 4
-```
-
-**Only reference existing module commands** in resolver documentation. Never reference modules or commands that don't exist.
-
-### Phase 4: Create
-
-Generate documentation using `erp-kit` CLI:
-
-```bash
-erp-kit scaffold --app-root examples resolver <app> <resolver-name>
-```
-
-**Naming conventions:**
-
-- Filename must match H1 heading exactly (camelCase)
-- Action-focused names: `createSupplierInvitation.md`
-
-### Phase 5: Validate
-
-```bash
-pnpm run app:doc:check
-```
-
-## Schema Reference
-
-| Schema         | Tier | Output Path               |
-| -------------- | ---- | ------------------------- |
-| `resolver.yml` | 4    | `docs/resolver/<name>.md` |
-
-## Tips
-
-- One story may require 1-3 resolvers
-- Group related operations logically
-- Document all error scenarios
-
-## Next Step
-
-After completing Tier 4, use `/erp-kit-app-5-implementation` to implement backend resolvers and frontend pages.

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

@@ -1,232 +0,0 @@
-# Backend Implementation Patterns
-
-## Table of Contents
-
-- [Backend Scaffold](#backend-scaffold)
-- [Module Wiring](#module-wiring)
-- [Application Config](#application-config)
-- [Resolver Patterns](#resolver-patterns)
-- [Executor Patterns](#executor-pattern)
-
----
-
-## Backend Scaffold
-
-```
-backend/
-├── src/
-│   ├── modules.ts                          # Module wiring
-│   ├── generated/kysely-tailordb.ts        # Auto-generated (placeholder until deploy)
-│   └── modules/<module-name>/
-│       ├── resolvers/<name>.ts
-│       └── executors/<name>.ts
-├── seed/                                   # Seed data scripts
-├── package.json
-├── tsconfig.json
-├── eslint.config.js
-└── tailor.config.ts
-```
-
-`package.json` key dependencies and scripts:
-
-```json
-{
-  "type": "module",
-  "scripts": {
-    "generate": "tailor-sdk generate",
-    "deploy": "tailor-sdk apply --env-file-if-exists .env",
-    "lint": "eslint --cache .",
-    "typecheck": "tsc --noEmit",
-    "seed": "node --env-file-if-exists=.env seed/exec.mjs"
-  },
-  "dependencies": {
-    "@tailor-platform/erp-kit": "...",
-    "@tailor-platform/function-kysely-tailordb": "...",
-    "kysely": "..."
-  },
-  "devDependencies": {
-    "@tailor-platform/sdk": "...",
-    "@tailor-platform/function-types": "...",
-    "typescript": "..."
-  }
-}
-```
-
-`tsconfig.json` — requires `@/*` path alias and `@tailor-platform/function-types` in types:
-
-```json
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "ESNext",
-    "moduleResolution": "bundler",
-    "strict": true,
-    "noEmit": true,
-    "skipLibCheck": true,
-    "types": ["node", "@tailor-platform/function-types"],
-    "paths": { "@/*": ["./src/*"] }
-  },
-  "include": ["**/*.ts"]
-}
-```
-
----
-
-## Module Wiring
-
-`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,
-  defineItemManagementModule,
-} from "@tailor-platform/erp-kit/module";
-
-const primitivesModules = definePrimitivesModule({});
-
-const umModules = defineUserManagementModule({
-  dbNamespace: "main-db",
-  user: {
-    fields: {
-      /* custom fields */
-    },
-    additionalStatuses: ["SUSPENDED"],
-  },
-});
-
-// Pass inter-module dependencies explicitly
-const imModules = defineItemManagementModule({
-  primitives: {
-    db: { unit: primitivesModules.db.unit },
-    queries: { getUnit: primitivesModules.queries.getUnit },
-  },
-});
-
-// Destructure db into individual table exports (required for DB scanner)
-export const { db: primitivesDb, commands: primitivesCommands } = primitivesModules;
-export const { uomCategory, unit, currency, exchangeRate } = primitivesDb;
-
-export const { db: umDb, executors: umExecutors, commands: umCommands } = umModules;
-export const { user, permission, role, userRole, rolePermission, auditEvent } = umDb;
-
-export const { db: imDb, commands: imCommands } = imModules;
-export const { item, taxonomyNode, itemTaxonomyAssignment } = imDb;
-```
-
-Key conventions:
-
-- Prefix exports to avoid collisions (`umCommands`, `imCommands`, `primitivesCommands`)
-- Every module's `db` must be destructured into individual table exports — the DB scanner only picks up named exports
-- Extract individual executors for re-export in executor files
-
----
-
-## 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],
-});
-```
-
-Key points:
-
-- `gqlOperations: "query"` — Auto-generates list/get GraphQL queries for all DB types
-- Glob patterns for resolver/executor discovery
-- See [SDK configuration docs](https://raw.githubusercontent.com/tailor-platform/sdk/refs/heads/main/packages/sdk/docs/configuration.md) for full config options
-
-### 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`)
-- Include static website URL and localhost in CORS: `cors: ["http://localhost:5173", website.url]`
-- Frontend `VITE_TAILOR_CLIENT_ID` must come from `tailor-sdk oauth2client get default --json` — do not hardcode
-
----
-
-## Resolver Patterns
-
-All resolvers export a default `createResolver()` from `@tailor-platform/sdk`.
-
-### Verify command input types
-
-Before implementing a resolver, read the command's type definition:
-
-```
-node_modules/@tailor-platform/erp-kit/src/modules/<module>/command/<commandName>.ts
-```
-
-The command source is the ground truth. Do not invent fields that don't exist, and preserve the required/optional distinction.
-
-### SDK type system
-
-See [Resolver docs](https://raw.githubusercontent.com/tailor-platform/sdk/refs/heads/main/packages/sdk/docs/services/resolver.md) for the `t` namespace.
-
-`t.array()` and `t.boolean()` do **not exist**. Never attempt to use them.
-
-### Command-based mutation
-
-The most common pattern. Key points:
-
-```ts
-import { createContext } from "@tailor-platform/erp-kit/app";
-
-body: async (context) => {
-  const db = getDB("main-db");
-  const result = await imCommands.createItem(db, { ...context.input }, createContext(context));
-  if (!result.ok) throw result.error;
-  return { id: result.value.item.id, ... };
-},
-```
-
-- `context.input.optionalField ?? undefined` — Convert null to undefined for command inputs
-- `result.value.entity.nullableField ?? ""` — Handle nullable return values
-- `createContext(context)` wraps the resolver context for erp-kit commands
-- `getDB("main-db")` — Namespace must match `tailor.config.ts`
-
-### Error handling
-
-When the resolver spec documents specific error codes, use `result.error.code` to switch:
-
-```ts
-if (!result.ok) {
-  switch (result.error.code) {
-    case "USER_NOT_FOUND":
-      throw new Error(`User ${context.input.userId} not found`);
-    // ...
-  }
-}
-```
-
-Do not directly mutate module-owned tables via Kysely — always use module commands.
-
----
-
-## Executor Patterns
-
-Executors re-export module-provided event handlers. One file per executor, no custom logic:
-
-```ts
-import { rolePermissionCreated } from "@/modules";
-export default rolePermissionCreated;
-```

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)