@jskit-ai/agent-docs 0.1.131 → 0.1.133

package/guide/agent/index.md

@@ -2,41 +2,35 @@
 
 # Guide
 
-This guide is the main hands-on path through JSKIT.
+JSKIT is an AI-first framework and tested source-pattern library. It owns
+strong runtime APIs, package composition contracts, and examples an agent can
+apply or adapt. It does not prescribe an agent host or project orchestrator.
 
-It starts with a fast reproducible Quickstart, then steps back to the scaffold-first chapters that explain the default shell and runtime shape. After that, it introduces the database-backed users layer, expands into console and workspace-aware app structure, and adds a small `App extras` section for optional runtime packages such as the Android Capacitor shell, realtime, and assistant. Finally, the guide breaks out generator-specific workflows into their own section.
-
-## Table of Contents
-
-### App Setup
+## Start here
 
 - [Quickstart](/guide/app-setup/quickstart)
-- [Initial Scaffolding](/guide/app-setup/initial-scaffolding)
-- [Working With The JSKIT CLI](/guide/app-setup/working-with-the-jskit-cli)
-- [A More Interesting Shell](/guide/app-setup/a-more-interesting-shell)
+- [Application foundations](/guide/app-setup/initial-scaffolding)
+- [Migrate an existing application](/guide/app-setup/existing-application-migration)
+- [A more interesting shell](/guide/app-setup/a-more-interesting-shell)
 - [Authentication](/guide/app-setup/authentication)
-- [Database Layer](/guide/app-setup/database-layer)
+- [Database layer](/guide/app-setup/database-layer)
 - [Users](/guide/app-setup/users)
 - [Multi-homing](/guide/app-setup/multi-homing)
 - [Console](/guide/app-setup/console)
 
-### App Extras
+## Optional capabilities
 
 - [Mobile Capacitor](/guide/app-extras/mobile-capacitor)
 - [Realtime](/guide/app-extras/realtime)
 - [Assistant](/guide/app-extras/assistant)
 
-### Generators
-
-- [Intro](/guide/generators/intro)
-- [UI Generators](/guide/generators/ui-generators)
-- [CRUD Generators](/guide/generators/crud-generators)
-- [Advanced CRUDs](/guide/generators/advanced-cruds)
+## How to use the guide
 
-## How to use this guide
+Begin with the Quickstart and one application-foundation pattern. Add only the
+capabilities selected by the product. For implementation, the installed JSKIT
+skill routes the agent to package-owned `PATTERN.md` files and the smallest
+relevant public API reference.
 
-- Start with `Quickstart` if you want the fastest route to a real workspace-enabled app and the first page-extension patterns.
-- Start with the rest of `App Setup` if you want to understand the base scaffold layer by layer.
-- Use `App Extras` once the base app structure is in place and you want optional runtime packages such as the Android shell, realtime, or assistant.
-- Jump into `Generators` if you already understand the runtime packages and want app-owned scaffolding workflows.
-- Inside `Generators`, read `CRUD Generators` before `Advanced CRUDs`: the first chapter teaches the workflow, and the second explains the generated anatomy and customization points.
+There are no generator or CLI chapters. Their useful source examples are
+package-owned patterns; their questionnaire, mutation, and provenance machinery
+is not part of JSKIT.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/agent-docs",
-  "version": "0.1.131",
+  "version": "0.1.133",
   "description": "Distributed JSKIT agent references, prompts, guides, and generated reference maps.",
   "type": "module",
   "files": [
@@ -11,7 +11,7 @@
     "templates"
   ],
   "scripts": {
-    "test": "node --test"
+    "test": "node --test test/*.test.js"
   },
   "engines": {
     "node": "^22.13.0 || ^24.0.0 || ^26.0.0"

package/patterns/INDEX.md

@@ -14,12 +14,12 @@ How to use it:
   - `placements.md`
 - surfaces, app/admin/home/console, "which surface", route ownership, placement visibility
   - `surfaces.md`
-- page, route page, placeholder page, screen stub, menu-linked page, `ui-generator page`, `list-placements`
+- page, route page, placeholder page, screen stub, menu-linked page, placements
   - `page-scaffolding.md`
 - child crud, nested crud, embedded list, subroute, separate page, parent/child layout
   - `child-cruds.md`
-- crud scaffold, crud server, crud ui, table creation, migrations, direct knex, weird-custom persistence, fresh minimal app order, `crud-server-generator`, `crud-ui-generator`, `--delete-confirmation`
-  - `crud-scaffolding.md`
+- crud, crud server, crud ui, resource contract, table creation, migrations, ownership, JSON API, standard screens
+  - `crud-authoring.md`
 - CRUD links, record placeholders, `paths.page()`, `resolveViewUrl`, `resolveEditUrl`, `resolveParams`
   - `crud-links.md`
 - `definePage`, redirect, child redirect, settings landing, `redirectToChild`
@@ -30,8 +30,8 @@ How to use it:
   - `client-requests.md`
 - playwright, browser test, e2e, ui verification, baseline test, authenticated ui test, test auth, dev login as, dev auth bypass
   - `ui-testing.md`
-- generated UI contract, design contract, navigation roles, density, placeholder copy, card shells, shared CRUD screens, row actions, synthetic rows, detail slots
-  - `generated-ui-contract-tracking.md`
+- UI contract, design contract, navigation roles, density, placeholder copy, card shells, shared CRUD screens, row actions, synthetic rows, detail slots
+  - `ui-contract.md`
 - filter, filters, search facets, chips, date range, enum filter, lookup filter, `useCrudListFilters`, `createCrudListFilters`
   - `filters.md`
 - `searchSchema`, `search: true`, `applyFilter`, server search, query validators, backend filters, internal JSON REST filters
@@ -47,13 +47,13 @@ How to use it:
 - [surfaces.md](./surfaces.md)
 - [page-scaffolding.md](./page-scaffolding.md)
 - [child-cruds.md](./child-cruds.md)
-- [crud-scaffolding.md](./crud-scaffolding.md)
+- [crud-authoring.md](./crud-authoring.md)
 - [crud-links.md](./crud-links.md)
 - [page-redirects.md](./page-redirects.md)
 - [live-actions.md](./live-actions.md)
 - [client-requests.md](./client-requests.md)
 - [ui-testing.md](./ui-testing.md)
-- [generated-ui-contract-tracking.md](./generated-ui-contract-tracking.md)
+- [ui-contract.md](./ui-contract.md)
 - [filters.md](./filters.md)
 - [server-search.md](./server-search.md)
 - [crud-repository-mapping.md](./crud-repository-mapping.md)

package/patterns/child-cruds.md

@@ -8,7 +8,7 @@ Use when:
 
 Rules:
 
-- Before generating a child CRUD, ask how the user wants the child records laid out.
+- Before authoring a child CRUD, ask how the user wants the child records laid out.
 - Do not assume one layout pattern by default.
 
 Clarify these options:
@@ -22,9 +22,9 @@ Clarify these options:
 
 Why this matters:
 
-- the answer changes route structure, placements, host containers, and which generator flow fits best
+- the answer changes route structure, placements, host containers, and which source pattern fits best
 - child CRUD layout mistakes are expensive to unwind later
 
 Avoid:
 
-- generating nested CRUD routes before the parent/child layout is agreed
+- authoring nested CRUD routes before the parent/child layout is agreed

package/patterns/client-requests.md

@@ -19,7 +19,7 @@ Rules:
 Choose the function like this:
 
 ```js
-// 1. Generated CRUD route screen
+// 1. Standard CRUD route screen
 const screen = useCrudListScreen({ ... });
 
 // 2. Button/toggle/small mutation
@@ -38,15 +38,15 @@ const form = useAddEdit({ ... });
 const resource = useEndpointResource({ ... });
 ```
 
-Use the shared CRUD screen wrappers when the route is a generated CRUD page:
+Use the shared CRUD screen wrappers when the route is a standard CRUD page:
 
 - `useCrudListScreen()` plus `CrudListScreen` for list route pages
 - `useCrudViewScreen()` plus `CrudViewScreen` for record view route pages
-- `useCrudAddEditScreen()` plus `CrudAddEditScreen` for generated new/edit route pages
+- `useCrudAddEditScreen()` plus `CrudAddEditScreen` for new/edit route pages
 
-Generated screen wrapper extension rules:
+Screen wrapper extension rules:
 
-- Use `useCrudListScreen({ readEnabled })` for permission-gated generated list reads instead of splitting the page or replacing the shared list screen.
+- Use `useCrudListScreen({ readEnabled })` for permission-gated list reads instead of splitting the page or replacing the shared list screen.
 - Use `useCrudListScreen({ requestQueryParams })` for list includes or other endpoint query params instead of putting query strings in `apiSuffix`.
 - Use `useCrudViewScreen({ requestQueryParams })` for detail includes instead of putting query strings in `apiUrlTemplate`.
 - Use `requestFieldsets` only when a specialised caller intentionally needs a typed JSON:API sparse fieldset. Ordinary generated reads use the complete resource output contract.
@@ -73,7 +73,7 @@ Why this is the standard JSKIT shape:
 - `httpWebClient` already handles credentials and CSRF behavior.
 - `useEndpointResource()` is the shared endpoint primitive for loading, saving, and standard load/save error handling. Higher-level runtimes add UI feedback and field-error handling on top.
 - Use `requestQueryParams` for endpoint query strings on list, view, and add/edit runtimes.
-- Generated CRUD and lookup reads use all resource-defined output fields by default. Hydrated relationships use the target resource's output contract. Generated pages and lookup controls do not repeat those definitions as request fieldsets.
+- Standard CRUD and lookup reads use all resource-defined output fields by default. Hydrated relationships use the target resource's output contract. Pages and lookup controls do not repeat those definitions as request fieldsets.
 - Put exceptional large fields in `resource.contract.response.defaultExclude`. The target resource owns that default even when it is included by another resource.
 - `requestFieldsets` remains an explicit specialised override and accepts the canonical typed shape, for example `{ jobs: ["id", "status"], contacts: ["id", "displayName"] }`. It participates in both the request and the query cache key.
 - Sparse fieldsets are a serialization boundary, not an authorization mechanism. Server resources reject unknown fields, never serialize hidden fields, and preserve the fields needed internally for relationship linkage.

package/patterns/crud-authoring.md

@@ -0,0 +1,94 @@
+# CRUD authoring
+
+Use this file for normal persisted entities, resource contracts, migrations,
+JSON API routes, and matching screens.
+
+## Start from product decisions
+
+Establish the entity, fields, relationships, ownership, access surface,
+operations, search, sorting, and destructive behavior. Ask when a material
+choice is missing. Do not turn these decisions into generator options.
+
+Read these package-owned source patterns:
+
+- `crud/resource-contract` for the shared field and ownership contract
+- `crud/json-api-resource-package` for migration and server composition
+- `crud/crud-screen-set` for routed list, view, create, edit, and delete UI
+
+## Normal implementation order
+
+1. Author a source-controlled migration in the package that owns the entity.
+2. Define the resource with `defineCrudResource()`.
+3. Bind standard server behavior with `defineCrudJsonApiFeature()`.
+4. Add only product-specific service methods, lifecycle, actions, validation,
+   policy, queries, messages, and orchestration.
+5. Declare the package provider and framework capabilities in `package.json`.
+6. Build thin route pages over JSKIT's shared CRUD screen APIs.
+7. Install the coherent package graph once.
+8. Rebuild a disposable database and run focused server, client, and browser
+   verification.
+
+The migration and resource are both authored contracts. A live schema is useful
+for understanding an imported system, but it is never the sole source of truth.
+
+## Ownership and access
+
+- `public` means every record is intentionally public. It cannot be combined
+  with user or workspace ownership.
+- `user` requires a real user ownership column and negative cross-user tests.
+- `workspace` and `workspace_user` require an explicit workspace route/action
+  scope plus named permission policy.
+- Domain relationships such as `recipient_user_id` are not ownership merely
+  because they point to a user.
+
+Normal CRUD tables use one non-null single-column primary key. Foreign keys are
+single-column and target compatible keys. Composite unique indexes may enforce
+business rules but do not become framework identities.
+
+## Schema evolution
+
+An unapplied migration may be edited normally. Once applied or released, add a
+new immutable migration for the next change. Keep resource fields and storage
+metadata aligned with the resulting schema. Do not use a field-patching command
+or rewrite a historical baseline.
+
+## Customize without copying CRUD
+
+`defineCrudJsonApiFeature()` deliberately keeps application extension points:
+
+- `decorateRepository` adds the few persistence operations unique to the
+  resource.
+- `decorateService` overrides standard methods or adds domain methods such as
+  `confirm`, `publish`, `cancel`, or `sendReminder`.
+- `operationLifecycle` wraps a standard operation with `before`, `execute`,
+  `after`, and mutation-only `afterCommit` phases. Mutation phases before commit
+  receive the same transaction and `execute` receives `standard(nextInput)`.
+- `actions` exposes non-CRUD service methods through normal validated,
+  permissioned, audited JSKIT actions and optional explicit HTTP routes.
+
+Keep database reads and writes in repositories. Services and lifecycle hooks
+orchestrate repositories; they do not issue raw database queries. Put external
+side effects after commit, or write a durable outbox record inside the
+transaction when delivery must be reliable.
+
+## When the resource abstraction does not fit
+
+Use a separate explicit Feature for a different domain, aggregate, import job,
+or command-oriented workflow that merely happens to mention the resource. A
+CRUD resource may have many custom operations; it stops fitting only when CRUD
+is no longer its principal public contract.
+
+## Verification
+
+- rebuild from zero in a fresh disposable database
+- validate accepted and rejected values at the resource boundary
+- test list/view/create/update/delete document shapes
+- test positive owner access and negative cross-owner access
+- test relationships and deletion behavior
+- verify skeletons, stable pending labels, toast mutation feedback, and no
+  horizontal overflow in compact, medium, and expanded screens
+- run current framework and application verification
+
+Avoid generator provenance, scaffold shapes, ownership receipts, workboards,
+operation ledgers, hidden file markers, live-table-only schemas, and duplicated
+route/request validators.

package/patterns/crud-links.md

@@ -2,7 +2,7 @@
 
 Use when:
 
-- customizing generated CRUD pages
+- customizing standard CRUD pages
 - wiring buttons or links on list/view/edit pages
 - building nested CRUD links
 

package/patterns/feature-package/PATTERN.md

@@ -0,0 +1,108 @@
+---
+id: server/feature-package
+title: App-local server feature package
+summary: Define a server feature through explicit capabilities and first-class actions, adding services or repositories only when its domain earns them.
+keywords: actions, feature, json-rest, knex, orchestration, package, provider, repository, routes, server
+requires: @jskit-ai/kernel
+---
+
+# App-local server feature package
+
+## Use when
+
+Use this pattern when a server capability has its own product language and
+should not grow inside `packages/main`. It shows the smallest normal shape: a
+feature declaration, named capability inputs and outputs, and first-class
+actions whose implementations capture those exact dependencies.
+
+The concrete `booking-engine` example is intentionally repository-free. The
+`variations/` directory preserves the two important escalations: a meaningful
+orchestration service and an explicit custom Knex repository for a domain that
+cannot fit the normal resource APIs.
+
+## Do not use when
+
+Do not create a package for a tiny composition callback or one route with no
+domain behavior. Use the CRUD resource patterns when ordinary resource
+operations fit. Do not select custom Knex merely because SQL is familiar; it
+is an explicit exception for persistence behavior the higher-level APIs cannot
+express.
+
+## Product decisions
+
+Decide the feature's public operations, access surface, authentication policy,
+input and output contracts, transactional boundary, and whether it truly owns
+persistence. Decide whether HTTP routes are needed or another package will call
+its actions internally. These decisions come from the product, not a JSKIT
+questionnaire.
+
+## Invariants
+
+- `packages/main` composes the application; substantial feature logic lives in
+  the feature package.
+- `defineFeature()` receives only declared capabilities and returns only
+  declared feature APIs.
+- Actions define the public operation contract and close over the feature APIs
+  they need. They never resolve arbitrary dependencies at execution time.
+- The service orchestrates the feature and does not issue SQL directly.
+- A repository owns persistence and accepts transaction/context options.
+- The normal persistence lane uses a public or documented high-level resource
+  API; custom Knex is an explicit, reviewed exception.
+- Ordinary HTTP and assistant exposure is projected from actions. Explicit
+  route code exists only for a genuinely custom transport.
+- Register routes, actions, contributors, and other catalogue entries during
+  `setup()`. Runtime catalogues may be sealed before provider `boot()` begins.
+  Reserve `boot()` for starting long-lived work such as consumers, schedulers,
+  or notification loops after the application structure is complete.
+- Application source contains no scaffold-shape, lane, provenance, receipt, or
+  authoring-history metadata.
+
+## Framework APIs
+
+The provider uses `defineFeature()` from
+`@jskit-ai/kernel/server/features`. The runtime supplies named capabilities
+and the feature publishes its actions through the dedicated action catalogue.
+The custom persistence variation uses `createWithTransaction()` from
+`@jskit-ai/database-runtime/shared`.
+
+## Example files
+
+`example/booking-engine/` is a concrete app-local package showing the preferred
+small-feature boundary. Its status query is deliberately small: product logic
+can grow inside the returned feature API without creating ceremonial layers.
+
+`example/variations/AvailabilityEngineProvider.js` and
+`example/variations/orchestratorService.js` show the repository-free lane.
+`example/variations/InvoiceRollupProvider.js` and
+`example/variations/customKnexRepository.js` show the explicit custom
+persistence lane.
+
+## Variation points
+
+Rename the package, capability id, actions, validators, and domain methods.
+Select the correct channels and surfaces in `actionDefaults`, overriding them
+only for exceptional actions. Add a service when orchestration is shared or
+stateful. Add a repository only when the feature owns persistence. Replace the
+illustrative status query with narrow product language before shipping.
+
+## Verification
+
+- Import the feature and verify its declared capability inputs and outputs.
+- Exercise actions through the action runtime, including invalid input and
+  denied access.
+- Exercise HTTP routes only when the package owns them.
+- Test service orchestration independently from persistence.
+- Test repository transaction and context forwarding.
+- Rebuild any schema from immutable migrations in a disposable database.
+- Run the app's package, server, and integration verification.
+
+## Avoid
+
+- product logic in the provider or `packages/main`
+- registering routes or action catalogue entries from `boot()`
+- direct SQL in actions, routes, or services
+- a repository for an orchestration-only feature
+- generic `execute(anything)` operations in finished product code
+- `app.make()`, `scope.make()`, container tokens, or service-location helpers
+- metadata claiming which authoring tool or pattern created the package
+- field questionnaires, overwrite switches, or durable operation records

package/patterns/feature-package/example/booking-engine/package.json

@@ -0,0 +1,48 @@
+{
+  "name": "@local/booking-engine",
+  "version": "0.1.0",
+  "description": "App-local booking orchestration package.",
+  "private": true,
+  "type": "module",
+  "dependencies": {
+    "@jskit-ai/kernel": "0.1.161",
+    "json-rest-schema": "^1.0.17"
+  },
+  "exports": {
+    "./server/actions": "./src/server/actions.js"
+  },
+  "jskit": {
+    "kind": "runtime",
+    "capabilities": {
+      "provides": [
+        "feature.booking-engine"
+      ],
+      "requires": [
+        "runtime.actions"
+      ]
+    },
+    "runtime": {
+      "server": {
+        "providers": [
+          {
+            "entrypoint": "src/server/BookingEngineProvider.js",
+            "export": "BookingEngineProvider"
+          }
+        ]
+      },
+      "client": {
+        "providers": []
+      }
+    },
+    "metadata": {
+      "apiSummary": {
+        "surfaces": [
+          {
+            "subpath": "./server/actions",
+            "summary": "Exports booking-engine action definitions."
+          }
+        ]
+      }
+    }
+  }
+}

package/patterns/feature-package/example/booking-engine/src/server/BookingEngineProvider.js

@@ -0,0 +1,33 @@
+import { defineFeature } from "@jskit-ai/kernel/server/features";
+import { createActions } from "./actions.js";
+
+const BookingEngineProvider = defineFeature({
+  id: "feature.booking-engine",
+  domain: "booking",
+  provides: {
+    bookingEngine: "feature.booking-engine"
+  },
+  actionDefaults: {
+    channels: ["api", "assistant", "internal"],
+    surfaces: ["app"]
+  },
+  setup() {
+    return {
+      bookingEngine: Object.freeze({
+        async readStatus(input = {}) {
+          return {
+            ok: true,
+            feature: "booking-engine",
+            scope: input.scope || "default",
+            verbose: input.verbose === true
+          };
+        }
+      })
+    };
+  },
+  actions({ bookingEngine }) {
+    return createActions({ bookingEngine });
+  }
+});
+
+export { BookingEngineProvider };

package/patterns/feature-package/example/booking-engine/src/server/actions.js

@@ -0,0 +1,26 @@
+import { statusQueryInputValidator } from "./inputSchemas.js";
+
+const ACTION_GET_STATUS = "feature.booking-engine.status.read";
+function createActions({ bookingEngine } = {}) {
+  if (!bookingEngine || typeof bookingEngine.readStatus !== "function") {
+    throw new TypeError("createActions requires bookingEngine.readStatus().");
+  }
+
+  return Object.freeze([
+    {
+      id: ACTION_GET_STATUS,
+      version: 1,
+      kind: "query",
+      input: statusQueryInputValidator,
+      output: null,
+      idempotency: "none",
+      audit: { actionName: ACTION_GET_STATUS },
+      observability: {},
+      async execute(input) {
+        return bookingEngine.readStatus(input);
+      }
+    }
+  ]);
+}
+
+export { ACTION_GET_STATUS, createActions };

package/patterns/feature-package/example/booking-engine/src/server/inputSchemas.js

@@ -0,0 +1,19 @@
+import { deepFreeze } from "@jskit-ai/kernel/shared/support/deepFreeze";
+import { createSchema } from "json-rest-schema";
+
+const statusQueryInputValidator = deepFreeze({
+  schema: createSchema({
+    scope: {
+      type: "string",
+      required: false,
+      minLength: 1
+    },
+    verbose: {
+      type: "boolean",
+      required: false
+    }
+  }),
+  mode: "patch"
+});
+
+export { statusQueryInputValidator };

package/patterns/feature-package/example/variations/AvailabilityEngineProvider.js

@@ -0,0 +1,31 @@
+import { defineFeature } from "@jskit-ai/kernel/server/features";
+import { emptyInputValidator } from "@jskit-ai/kernel/shared/actions/actionContributorHelpers";
+import { createService } from "./orchestratorService.js";
+
+const AvailabilityEngineProvider = defineFeature({
+  id: "feature.availability-engine",
+  domain: "availability",
+  provides: {
+    availabilityEngine: "feature.availability-engine"
+  },
+  actionDefaults: {
+    channels: ["api", "assistant", "internal"],
+    surfaces: ["app"]
+  },
+  setup() {
+    return { availabilityEngine: createService() };
+  },
+  actions({ availabilityEngine }) {
+    return [{
+      id: "availability.status.read",
+      kind: "query",
+      input: emptyInputValidator,
+      idempotency: "none",
+      async execute(input) {
+        return availabilityEngine.getStatus(input);
+      }
+    }];
+  }
+});
+
+export { AvailabilityEngineProvider };

package/patterns/feature-package/example/variations/InvoiceRollupProvider.js

@@ -0,0 +1,36 @@
+import { defineFeature } from "@jskit-ai/kernel/server/features";
+import { emptyInputValidator } from "@jskit-ai/kernel/shared/actions/actionContributorHelpers";
+import { createRepository } from "./repository.js";
+
+const InvoiceRollupProvider = defineFeature({
+  id: "feature.invoice-rollup",
+  domain: "invoices",
+  requires: {
+    database: "runtime.database"
+  },
+  provides: {
+    invoiceRollup: "feature.invoice-rollup"
+  },
+  actionDefaults: {
+    channels: ["api", "assistant", "internal"],
+    surfaces: ["admin"]
+  },
+  setup({ database }) {
+    return {
+      invoiceRollup: createRepository({ knex: database.knex })
+    };
+  },
+  actions({ invoiceRollup }) {
+    return [{
+      id: "invoices.rollup.status.read",
+      kind: "query",
+      input: emptyInputValidator,
+      idempotency: "none",
+      async execute(input, context) {
+        return invoiceRollup.getStatus(input, { context });
+      }
+    }];
+  }
+});
+
+export { InvoiceRollupProvider };

package/patterns/feature-package/example/variations/customKnexRepository.js

@@ -0,0 +1,34 @@
+import { createWithTransaction } from "@jskit-ai/database-runtime/shared";
+
+function createRepository({ knex } = {}) {
+  if (!knex) {
+    throw new TypeError("createRepository requires knex.");
+  }
+
+  return Object.freeze({
+    withTransaction: createWithTransaction(knex),
+    async getStatus(input = {}, options = {}) {
+      return {
+        ok: true,
+        feature: "invoice-rollup",
+        persistence: "custom-knex",
+        tableName: "invoice_rollups",
+        hasTransaction: Boolean(options.trx),
+        input
+      };
+    },
+    async execute(input = {}, options = {}) {
+      return {
+        accepted: false,
+        feature: "invoice-rollup",
+        persistence: "custom-knex",
+        tableName: "invoice_rollups",
+        hasTransaction: Boolean(options.trx),
+        input,
+        message: "Replace this example with the reviewed domain-specific query."
+      };
+    }
+  });
+}
+
+export { createRepository };

package/patterns/feature-package/example/variations/orchestratorService.js

@@ -0,0 +1,23 @@
+function createService() {
+  return Object.freeze({
+    async getStatus(input = {}) {
+      return {
+        ok: true,
+        feature: "availability-engine",
+        mode: "orchestrator",
+        input
+      };
+    },
+    async execute(input = {}) {
+      return {
+        accepted: false,
+        feature: "availability-engine",
+        mode: "orchestrator",
+        input,
+        message: "Replace this example with calls to the feature's injected collaborators."
+      };
+    }
+  });
+}
+
+export { createService };