@tailor-platform/erp-kit 0.6.0 → 0.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/erp-kit",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "description": "Opinionated ERP toolkit for building business applications on Tailor Platform",
   "license": "MIT",
   "bin": {

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

@@ -7,6 +7,18 @@ description: Create Tier 1-2 documentation (requirements, actors, business-flow)
 
 Create Tier 1-2 documentation: Requirements, Actors, and Business Flows.
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## Workflow Phases
 
 ```
@@ -28,12 +40,12 @@ Focus on "what" the application should do, not "how" it will be implemented.
 
 Use AskUserQuestion to clarify undefined requirements. Focus on business-level scope and workflows — not platform capabilities like authentication.
 
-| 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?        |
+| 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.
 
@@ -44,13 +56,13 @@ Generate documentation using `erp-kit` CLI. `{APP_ROOT}` is the parent directory
 ```bash
 # Tier 1: Requirements + project structure
 # Creates {APP_ROOT}/{APP_NAME}/README.md
-erp-kit app init {APP_NAME} {APP_ROOT}
+npx erp-kit app init {APP_NAME} {APP_ROOT}
 
 # Tier 2: Actors
-erp-kit app generate doc actors {ACTOR_NAME} -p {APP_ROOT}/{APP_NAME}
+npx erp-kit app generate doc actors {ACTOR_NAME} -p {APP_ROOT}/{APP_NAME}
 
 # Tier 2: Business Flows
-erp-kit app generate doc business-flow {FLOW_NAME} -p {APP_ROOT}/{APP_NAME}
+npx erp-kit app generate doc business-flow {FLOW_NAME} -p {APP_ROOT}/{APP_NAME}
 ```
 
 **Directory structure after init + generate:**
@@ -80,6 +92,7 @@ After creating business flows, extract and create story documentation.
 
 1. **Collect** all business flow docs: glob `<APP_ROOT>/docs/business-flow/*/README.md`
 2. **Dispatch story extraction agents** — one Agent per business flow (parallelize if possible). Each agent:
+
    - Reads the prompt template from [references/story-extraction.md](references/story-extraction.md)
    - Replace `{{APP_NAME}}` with the resolved app name
    - Replace `{{ACTOR_DOCS}}` with the actor doc file paths
@@ -90,7 +103,7 @@ After creating business flows, extract and create story documentation.
 
 ```bash
 # For each story identified
-erp-kit app generate doc story <flow>/<actor>--<story> -p {APP_ROOT}/{APP_NAME}
+npx erp-kit app generate doc story <flow>/<actor>--<story> -p {APP_ROOT}/{APP_NAME}
 ```
 
 4. **Link stories** in business flow READMEs: replace `- TBD` placeholders in each flow's `## Stories` section with actual links:
@@ -102,18 +115,21 @@ erp-kit app generate doc story <flow>/<actor>--<story> -p {APP_ROOT}/{APP_NAME}
 ### Phase 4: Validate
 
 ```bash
-erp-kit app check -p {APP_ROOT}
+# NOTE: -p takes {APP_ROOT} (parent directory), NOT {APP_ROOT}/{APP_NAME}.
+# generate doc uses -p {APP_ROOT}/{APP_NAME}, but check uses -p {APP_ROOT}.
+# Example: if app is at apps/user-management, use -p apps
+npx 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.
+**Expected passing output:** `✓ No violations found` for each doc type that has files. "No matching files found" appears for doc types not yet created (e.g., screens and resolvers at Tier 1-2) — this is normal and not an error.
 
 ## Schema Reference
 
-| Schema              | Tier | Output Path                           |
-| ------------------- | ---- | ------------------------------------- |
-| `requirements.yml`  | 1    | `README.md`                           |
-| `actors.yml`        | 2    | `docs/actors/<name>.md`               |
-| `business-flow.yml` | 2    | `docs/business-flow/<flow>/README.md` |
+| Schema              | Tier | Output Path                                          |
+| ------------------- | ---- | ---------------------------------------------------- |
+| `requirements.yml`  | 1    | `README.md`                                          |
+| `actors.yml`        | 2    | `docs/actors/<name>.md`                              |
+| `business-flow.yml` | 2    | `docs/business-flow/<flow>/README.md`                |
 | `story.yml`         | 2    | `docs/business-flow/<flow>/story/<actor>--<name>.md` |
 
 ## Next Step

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

@@ -7,6 +7,18 @@ description: Review requirements quality and documentation consistency for appli
 
 Review **requirements quality** and **documentation consistency** for an application's Tier 1-2 documentation.
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## When to Use
 
 - After writing application requirements and business flows (step 1)

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

@@ -7,6 +7,18 @@ description: Create Tier 3-4 documentation (screens, resolvers) by breaking down
 
 Convert Tier 2 business flows and stories into Tier 3 (screens) and Tier 4 (resolvers) documentation using parallel extraction agents.
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## When to Use
 
 - User has Tier 1-2 documentation and wants to plan Tier 3-4
@@ -40,7 +52,7 @@ Verify at least `STORY_DOCS` is non-empty. If no story docs exist, stop with: "N
 Collect module overview:
 
 ```bash
-erp-kit doc modules
+npx erp-kit doc modules
 ```
 
 This returns each module's name, overview, command/query/model counts, and dependencies. Save the full output as `MODULE_OVERVIEW` — both agents receive it.
@@ -100,10 +112,10 @@ Scaffold using `erp-kit` CLI:
 
 ```bash
 # Tier 3: Screens
-erp-kit app generate doc screen <screen-name> -p {APP_ROOT}/{APP_NAME}
+npx erp-kit app generate doc screen <screen-name> -p {APP_ROOT}/{APP_NAME}
 
 # Tier 4: Resolvers
-erp-kit app generate doc resolver <resolver-name> -p {APP_ROOT}/{APP_NAME}
+npx erp-kit app generate doc resolver <resolver-name> -p {APP_ROOT}/{APP_NAME}
 ```
 
 Fill scaffolded docs with details from agent extraction results.
@@ -119,7 +131,9 @@ Read-only stories should have `None` under `## Resolvers`.
 ## Step 6: Validate
 
 ```bash
-erp-kit app check -p {APP_ROOT}
+# NOTE: -p takes {APP_ROOT} (parent directory), NOT {APP_ROOT}/{APP_NAME}.
+# generate doc uses -p {APP_ROOT}/{APP_NAME}, but check uses -p {APP_ROOT}.
+npx erp-kit app check -p {APP_ROOT}
 ```
 
 ## Naming Conventions

package/skills/erp-kit-app-3-plan/references/resolver-extraction.md

@@ -16,7 +16,7 @@ The following modules are available in erp-kit. Use this to map resolvers to rea
 To inspect a specific module's commands in detail, run:
 
 ```bash
-erp-kit doc module <module-name> command <command-name>
+npx erp-kit doc module <module-name> command <command-name>
 ```
 
 ## Instructions

package/skills/erp-kit-app-3-plan/references/screen-extraction.md

@@ -16,7 +16,7 @@ The following modules are available in erp-kit. Use this to understand which ent
 To inspect a specific module's model (domain description, state transitions, invariants, commands), run:
 
 ```bash
-erp-kit doc module <module-name> model <model-name>
+npx erp-kit doc module <module-name> model <model-name>
 ```
 
 ## Instructions

package/skills/erp-kit-app-4-plan-review/SKILL.md

@@ -7,6 +7,18 @@ description: Review parity between Tier 2 (business flows, actors, stories) and
 
 Review **documentation consistency** across Tier 2 (business flows, actors, stories), Tier 3 (screens), and Tier 4 (resolvers) documentation.
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## When to Use
 
 - After writing Tier 3-4 documentation, check for gaps

package/skills/erp-kit-app-5-impl-backend/SKILL.md

@@ -7,6 +7,18 @@ description: Implement backend code for applications using erp-kit modules. Use
 
 Implement backend resolvers and application configuration for an application, driven by Tier 1-4 documentation (actors, business flows, stories, screens, resolvers).
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## When to Use
 
 - Implementing backend resolvers from resolver spec docs
@@ -55,17 +67,17 @@ Classify resolvers per [erp-kit-app-shared/references/resolver-classification.md
 
 When implementing in Phase 4, follow the patterns from the reference examples. Once all actual resolvers are implemented, delete the reference files that aren't needed by your app.
 
-### Phase 2: Wire Modules (`src/modules.ts`)
+### Phase 2: Wire Modules (`src/modules.ts` + `src/modules-db.ts`)
 
-Create the module wiring file that composes all required erp-kit modules.
+Create the module wiring files that compose all required erp-kit modules.
 
 **Read [module wiring reference](references/module-wiring.md) for the composition pattern.**
 
 Key points:
 
-- Use `defineXxxModule()` functions from `@tailor-platform/erp-kit/module`
+- `modules.ts` — Use `defineXxxModule()` functions from `@tailor-platform/erp-kit/module` and export module objects for resolver use
+- `modules-db.ts` — Destructure DB types into individual named exports for the DB scanner. This file must NOT be imported by resolvers.
 - Pass inter-module dependencies explicitly (e.g., item-management needs primitives' unit type and query)
-- Export `db`, `commands`, and `executors` for use in resolvers
 
 ### Phase 3: Configure Application (`tailor.config.ts`)
 
@@ -97,7 +109,7 @@ After resolvers are done, implement the story integration test stubs generated i
 > - `src/resolvers/<resolverName>.ts`
 > - `src/executors/<resolverName>.ts`
 >
-> **Shared-file guard:** `src/modules.ts` and `tailor.config.ts` are written in the sync barrier phase above. Resolver agents must NOT modify these files.
+> **Shared-file guard:** `src/modules.ts`, `src/modules-db.ts`, and `tailor.config.ts` are written in the sync barrier phase above. Resolver agents must NOT modify these files.
 
 ### Phase 5: Generated Files
 

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

@@ -11,7 +11,7 @@ Key points:
 ## Auth configuration
 
 - Prefer stable default naming: auth `default`, IdP `default`, OAuth2 client `default`
-- `userProfile.type` must reference the `user` DB type from `modules.ts`
+- `userProfile.type` must reference the `user` DB type from `modules-db`
 - `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

package/skills/erp-kit-app-5-impl-backend/references/module-wiring.md

@@ -1,17 +1,23 @@
 # Module Wiring
 
-`src/modules.ts` composes erp-kit modules and exports their parts for resolver use.
+Module wiring is split across two files:
+
+- `src/modules.ts` — composes erp-kit modules and exports module objects for resolver use
+- `src/modules-db.ts` — destructures DB types into individual named exports for the DB scanner (`tailor.config.ts` db.files)
+
+### `src/modules.ts`
 
 ```ts
 import {
   definePrimitivesModule,
   defineUserManagementModule,
   defineItemManagementModule,
+  defineAuditModule,
 } from "@tailor-platform/erp-kit/module";
 
 const primitivesModules = definePrimitivesModule({});
 
-const umModules = defineUserManagementModule({
+export const umModules = defineUserManagementModule({
   dbNamespace: "main-db",
   user: {
     fields: {
@@ -22,26 +28,45 @@ const umModules = defineUserManagementModule({
 });
 
 // Pass inter-module dependencies explicitly
-const imModules = defineItemManagementModule({
+export 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 auditModules = defineAuditModule();
+
+export const primitivesModulesExport = primitivesModules;
+```
+
+### `src/modules-db.ts`
+
+```ts
+import { auditCompanyStub } from "@tailor-platform/erp-kit/module";
+import { umModules, imModules, primitivesModulesExport, auditModules } from "./modules";
+
+// Destructured for DB scanner (tailor.config.ts db.files).
+// This file must NOT be imported by resolvers — property access prevents tree-shaking.
+
+// user-management
+export const { user, permission, role, userRole, rolePermission } = umModules.db;
+
+// primitives
+export const { uomCategory, unit, currency, exchangeRate } = primitivesModulesExport.db;
 
-export const { db: umDb, executors: umExecutors, commands: umCommands } = umModules;
-export const { user, permission, role, userRole, rolePermission, auditEvent } = umDb;
+// item-management
+export const { item, taxonomyNode, itemTaxonomyAssignment } = imModules.db;
 
-export const { db: imDb, commands: imCommands } = imModules;
-export const { item, taxonomyNode, itemTaxonomyAssignment } = imDb;
+// audit
+export const { auditableEntity, auditPolicy, policyFieldRule, auditEntry, changeDetail } =
+  auditModules.db;
+export { auditCompanyStub as company };
 ```
 
 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
+- Prefix exports to avoid collisions (`umModules`, `imModules`, `auditModules`)
+- `modules-db.ts` must NOT be imported by resolvers — it exists solely for the DB scanner
+- Every module's `db` must be destructured into individual table exports in `modules-db.ts` — the DB scanner only picks up named exports
 - Extract individual executors for re-export in executor files

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

@@ -7,6 +7,18 @@ description: Implement frontend code for applications. Use after deploying the b
 
 Implement frontend pages for an application, driven by screen spec documentation and a deployed backend.
 
+## Progress Logging
+
+Log to the audit trail at every checkpoint. See [erp-kit-app-shared/references/progress-protocol.md](../erp-kit-app-shared/references/progress-protocol.md) for the full protocol.
+
+```bash
+npx erp-kit app progress log --json '<ProgressInput JSON>'
+```
+
+Required checkpoints: `step.start` (on invocation), `decision` (on user choices), `agent.dispatch`/`agent.result` (on subagent lifecycle), `artifact.create` (on file writes), `validation` (on `erp-kit app check` or build commands), `step.complete` (on finish), `error` (on failures).
+
+Bundle all conversation since the last checkpoint into the `conversation` array. Use your session ID as `sessionId`. Use the user's original prompt as `prompt`.
+
 ## When to Use
 
 - Implementing frontend pages from screen spec docs
@@ -64,6 +76,8 @@ Create pages driven by screen spec docs. Each screen type has a standard impleme
 
 **Read [pages reference](references/pages.md) for the full pattern catalog.**
 
+**Read [app-shell UI cheat sheet](references/component.md)** for `@tailor-platform/app-shell` primitives (Layout, Button, Table, dialogs, Menu, Select, Combobox, Autocomplete, etc.).
+
 Page types and their file structure:
 
 | Screen Type   | Files                                                                                            |
@@ -79,7 +93,7 @@ Key frontend patterns:
 - **gql.tada** — Type-safe GraphQL via `graphql()` from `@/graphql`
 - **React Hook Form + Zod** — Form validation with `zodResolver`
 - **urql** — `useQuery` for reads, `useMutation` for writes
-- **app-shell routing** — `Layout`, `Link`, `useParams`, `useNavigate` from `@tailor-platform/app-shell`
+- **app-shell** — Routing: `Layout`, `Link`, `useParams`, `useNavigate`. UI: see [references/component.md](references/component.md) for primitives (`Button`, `Input`, `Table`, dialogs, menus, selects, etc.)
 
 ### Phase 4: Verify
 

package/skills/erp-kit-app-6-impl-frontend/references/component.md

@@ -0,0 +1,90 @@
+# @tailor-platform/app-shell — UI cheat sheet
+
+Import from `@tailor-platform/app-shell` instead of duplicating shadcn-style `components/ui` when possible. Details: [app-shell docs/components](https://raw.github.com/tailor-platform/app-shell/tree/main/docs/components).
+
+## Layout
+
+- **`Layout`** — `title` / `actions` / `columns` still work; prefer **`Layout.Header`** (`title`, `actions`, children e.g. tabs) + **`Layout.Column`**.
+- **`Layout.Column` `area`** — `"left" | "main" | "right"` for sidebar + main + rail; use `className` on `Layout` for gap (`columns` / `gap` deprecated).
+
+## ActionPanel
+
+`actions={[{ key, label, icon, onClick, disabled?, loading? }]}` — icon + label rows; use `useNavigate` inside `onClick` for routing.
+
+## Routing helpers
+
+`Link`, `useNavigate`, `useParams` — same package.
+
+## DescriptionCard
+
+Detail screens: **`data`** + **`fields`** render a responsive key/value grid.
+
+| Prop                  | Notes                                                                  |
+| --------------------- | ---------------------------------------------------------------------- |
+| `data`                | `Record<string, unknown>` — values (dot keys OK, e.g. `customer.name`) |
+| `fields`              | `FieldConfig[]` — each field or `{ type: "divider" }`                  |
+| `columns`             | `2` \| `3` (default) \| `4`                                            |
+| `className` / `style` | Card container                                                         |
+
+**Field config** — `key`, `label`, optional `type`, `meta`, `emptyBehavior` (`"dash"` \| `"hide"`).
+
+| `type` (default `text`) | Role / typical `meta`                                         |
+| ----------------------- | ------------------------------------------------------------- |
+| **text**                | `copyable`, `truncateLines`                                   |
+| **badge**               | `badgeVariantMap: { [value]: variant }`                       |
+| **money**               | `currencyKey` — key in `data` for ISO currency code           |
+| **date**                | `dateFormat`: `short` \| `medium` \| `long` \| `relative`     |
+| **link**                | `hrefKey`, `external?`                                        |
+| **address**             | Value = `{ street, city, state, zip, … }` object              |
+| **reference**           | `referenceIdKey`, `referenceUrlPattern` e.g. `/invoices/{id}` |
+
+## Button / Link
+
+Use **`render`**, not Radix `asChild`:
+
+```tsx
+<Button render={<Link to="create" />}>Create</Button>
+```
+
+Variants: `default` | `destructive` | `outline` | `secondary` | `ghost` | `link`. Sizes: `default` | `sm` | `lg` | `icon`.
+
+## Input
+
+Native input props; works with RHF `FormControl` + spread `field`.
+
+## Table
+
+```tsx
+<Table.Root>
+  <Table.Header>
+    <Table.Row>
+      <Table.Head />
+    </Table.Row>
+  </Table.Header>
+  <Table.Body>
+    <Table.Row>
+      <Table.Cell />
+    </Table.Row>
+  </Table.Body>
+</Table.Root>
+```
+
+Also `Footer`, `Caption`. Wrapper: `containerClassName`; inner table: `className`.
+
+## Dialog / Sheet / Tooltip
+
+Compound `*.Root`, `*.Content`, etc. Triggers: **`render={<Button />}`** (or `Link` pattern as needed).
+
+## Menu
+
+`Menu.Root` → `Trigger` → `Content` → `Item` / `Separator` / checkbox & radio items; nested: `SubmenuRoot` / `SubmenuTrigger`.
+
+## Select / Combobox / Autocomplete
+
+| Component        | Use case                                  | Extras                           |
+| ---------------- | ----------------------------------------- | -------------------------------- |
+| **Select**       | `items`, `placeholder`, `onValueChange`   | `Select.Async`                   |
+| **Combobox**     | Searchable; `items`; multi / creatable    | `Combobox.Async`, `onCreateItem` |
+| **Autocomplete** | Typed string + suggestions (value = text) | `Autocomplete.Async`             |
+
+**`.Parts`** on each — low-level `Root`, `Trigger`, `Content`, …; hooks `useFilter`, `useAsync`, `useCreatable` for custom UIs.