@tailor-platform/erp-kit 0.2.0 → 0.2.2

package/skills/erp-kit-app-5-design-review/references/screen-listview.md

@@ -1,153 +0,0 @@
-# ListView Screen Implementation
-
-Implementation pattern for screens with `Screen Type: ListView`.
-Assumes `page.md` and `component.md` rules.
-
-## File Structure
-
-```
-{screen-path}/
-├── components/
-│   └── {screen-name}-table.tsx     # Table component with fragments
-└── page.tsx
-```
-
-## Page Component (page.tsx)
-
-Data fetching and `Layout` must be co-located in the same page component.
-Do NOT split into an inner Content component — `Layout` requires `Layout.Column` as direct children.
-
-```tsx
-const ResourcesQuery = graphql(
-  `
-    query Resources {
-      resources {
-        ...ResourceTable
-      }
-    }
-  `,
-  [ResourceTableFragment],
-);
-
-const ResourcesPage = () => {
-  const [{ data, error, fetching }, reexecuteQuery] = useQuery({
-    query: ResourcesQuery,
-  });
-
-  if (fetching) return <Loading />;
-
-  if (error || !data) {
-    return (
-      <ErrorFallback
-        title="Failed to load resources"
-        message="An error occurred while fetching the list."
-        onReset={() => reexecuteQuery({ requestPolicy: "network-only" })}
-      />
-    );
-  }
-
-  return (
-    <Layout
-      columns={1}
-      title="Resources"
-      actions={[
-        <Button key="create" asChild>
-          <Link to="create">Create</Link>
-        </Button>,
-      ]}
-    >
-      <Layout.Column>
-        <ResourceTable data={data.resources} />
-      </Layout.Column>
-    </Layout>
-  );
-};
-```
-
-## Table Component (components/{screen-name}-table.tsx)
-
-### Fragment Collocation
-
-Define a row fragment and a table fragment wrapping the Connection type.
-
-```tsx
-const ResourceRowFragment = graphql(`
-  fragment ResourceRow on Resource {
-    id
-    title
-    status
-    createdAt
-  }
-`);
-
-export const ResourceTableFragment = graphql(
-  `
-    fragment ResourceTable on ResourceConnection {
-      edges {
-        node {
-          ...ResourceRow
-        }
-      }
-    }
-  `,
-  [ResourceRowFragment],
-);
-```
-
-### Row Component
-
-```tsx
-const ResourceRow = ({ resource: resourceFragment }: ResourceRowProps) => {
-  const resource = readFragment(ResourceRowFragment, resourceFragment);
-  return (
-    <TableRow>
-      <TableCell>{resource.title}</TableCell>
-      <TableCell>
-        <Badge variant={resource.status === "ACTIVE" ? "default" : "secondary"}>
-          {resource.status}
-        </Badge>
-      </TableCell>
-      <TableCell>
-        <Button variant="ghost" size="sm" asChild>
-          <Link to={resource.id}>View</Link>
-        </Button>
-      </TableCell>
-    </TableRow>
-  );
-};
-```
-
-### Empty State
-
-```tsx
-if (connection.edges.length === 0) {
-  return (
-    <EmptyState
-      title="No resources"
-      message="Get started by creating a new resource."
-      action={
-        <Button asChild>
-          <Link to="create">Create</Link>
-        </Button>
-      }
-    />
-  );
-}
-```
-
-## Column Property Mapping
-
-| Property        | Implementation                                              |
-| --------------- | ----------------------------------------------------------- |
-| Hideable: Yes   | Column visibility state to toggle show/hide                 |
-| Sortable: Yes   | Sort icon on `<TableHead>` + onClick to toggle query vars   |
-| Filterable: Yes | Filter UI above table (`<Select />`)                        |
-| Searchable: Yes | Search input above table (`<Input placeholder="Search" />`) |
-
-## Key Points
-
-- Use `<Badge />` for status columns
-- Format dates with `toLocaleDateString()`
-- Use `<EmptyState />` with Create action for empty lists
-- Add a View button per row to navigate to the detail page
-- Iterate data using Connection type `edges.node` pattern

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

@@ -1,127 +0,0 @@
----
-name: erp-kit-app-6-impl-spec
-description: Create Tier 4 documentation (resolvers) for GraphQL operations. Use after completing design review with erp-kit-app-5-design-review.
----
-
-# Implementation Spec Workflow
-
-Create Tier 4 documentation: GraphQL Resolvers (mutations and queries).
-
-## Prerequisites
-
-Tier 1-3 documentation and design mockups 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)
-- `docs/design.pen` (UI mockups)
-
-## 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 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 modules/
-```
-
-**Check module commands:**
-
-```bash
-ls 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 (kebab-case)
-- Action-focused names: `create-supplier-invitation.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
-
-## Completion
-
-After Tier 4, the application specification is complete:
-
-- **Tier 1**: Application overview
-- **Tier 2**: Actors and business workflows
-- **Tier 3**: User stories and screens
-- **Tier 4**: Implementation specifications
-
-## References
-
-- [Application structure](references/structure.md)
-- [Backend auth](references/auth.md)

package/skills/erp-kit-app-6-impl-spec/references/auth.md

@@ -1,72 +0,0 @@
-# Backend Auth Configuration
-
-Use Tailor SDK auth resources as the default pattern for backend authentication setup.
-
-## Standard Auth Shape
-
-In `tailor.config.ts`:
-
-- Define IdP with `defineIdp(...)`
-- Define Auth with `defineAuth(...)`
-- Define static website with `defineStaticWebSite(...)` when frontend is deployed as static hosting
-- Wire `idProvider` via `idp.provider(...)`
-- Set exactly one OAuth2 client for frontend login (default client name: `default`)
-- Export config with `auth: auth` and `idp: [idp]`
-- Include static website URL in CORS when using deployed frontend (for example, `cors: ["http://localhost:5173", website.url]`)
-
-Prefer this stable naming unless there is a clear reason to change:
-
-- Auth name: `default`
-- IdP name: `default`
-- OAuth2 client name: `default`
-
-## User Mapping
-
-Use `userProfile` to map authenticated identities to the application user type.
-
-- `type`: module-provided user type
-- `usernameField`: stable unique field (for example, `email`)
-- `attributes`: explicitly list required attributes
-
-Avoid implicit attribute assumptions.
-
-## CORS for Static Website Login
-
-When frontend is deployed via `staticWebsites`, OAuth metadata and query calls are cross-origin from `https://<name>-<workspace>.web.erp.dev` to app backend.
-
-- Always include the deployed static website origin via `website.url` in backend `cors`
-- Keep local development origin in `cors` as well (for example, `http://localhost:5173`)
-- If your template uses IP allow lists, set `allowedIpAddresses` appropriately for Tailor internal access
-
-If `website.url` is missing from `cors`, login may fail with browser CORS errors before authentication starts.
-
-## Seed Permission Alignment
-
-Seeded login users in `seed/data/User.jsonl` must receive module permissions required by guarded commands/resolvers.
-
-- Do not assume `ADMIN` is automatically privileged unless your permission evaluator explicitly supports it
-- Grant concrete permission keys defined by the module (for example, `user-management:createUser`)
-- Keep `User.jsonl` permissions aligned with the module currently wired in `src/modules.ts`
-
-## Workspace and CLI Inputs
-
-Use `TAILOR_PLATFORM_WORKSPACE_ID` in backend `.env` for CLI operations.
-
-Required for non-interactive resource lookup and automation:
-
-- `tailor-sdk oauth2client list`
-- `tailor-sdk oauth2client get <name>`
-
-Use `--env-file <backend/.env>` for deterministic command execution in local/dev scripts.
-
-## OAuth Client ID Source of Truth
-
-Frontend `VITE_TAILOR_CLIENT_ID` must come from backend-managed OAuth2 client data.
-
-Canonical retrieval flow:
-
-1. `tailor-sdk oauth2client get default --json`
-2. Copy `clientId` from command output
-3. Set it in frontend env
-
-Do not hardcode OAuth client IDs in source code.

package/skills/erp-kit-app-6-impl-spec/references/structure.md

@@ -1,27 +0,0 @@
-# Application Directory Structure
-
-```
-{app_name}/
-├── backend/
-│   ├── src/
-│   │   ├── modules.ts              # Declaring module usage
-│   │   ├── modules/
-│   │   │   └── {module-name}/      # Module-specific directory
-│   │   │       ├── resolvers/      # API Definition to expose graphql apis
-│   │   │       └── executors/      # PubSub Automation (one file per declaration)
-│   │   └── generated/              # Auto-generated code (do not edit)
-│   └── tailor.config.ts            # tailor application config
-│
-└── frontend/
-    └── src/
-        ├── pages/                  # File-based routing (auto-discovered by Vite plugin)
-        │   └── {page-path}/
-        │       ├── page.tsx
-        │       └── {page-path}/
-        │           ├── components/
-        │           └── page.tsx
-        ├── components/
-        │   └── ui/                 # Generic UI components
-        ├── graphql/                # gql.tada settings
-        └── providers/              # react providers
-```

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)