@jskit-ai/agent-docs 0.1.283 → 0.1.284

package/guide/agent/app-setup/multi-homing.md

@@ -110,14 +110,25 @@ The package migrations create and own these tables:
 | `workspace_invites` | `workspace_id`, `email`, `role_sid`, `status`, `token_hash`, `invited_by_user_id`, `expires_at`, `accepted_at`, `revoked_at` |
 
 Application records that belong to a workspace use a non-null `workspace_id`
-foreign key to `workspaces.id`. Read and change these tables through the
-`workspaces.core` repositories and services, not directly.
+foreign key to `workspaces.id`. Read and change these tables through their
+owners' capabilities (`workspaces`, `workspaces.memberships` and
+`workspaces.core`, below), not directly.
 
 ## Server composition
 
 Use `workspaces/workspace-server` for role vocabulary, creation policy,
 invitations, settings, and app-owned invitation email rendering.
 
+Two server settings are required, and the server refuses to start without
+them: whether new workspaces accept invitations, and how long an invitation
+lasts.
+
+```js
+// config/server.js
+config.workspaceSettings = { defaults: { invitesEnabled: true } };
+config.workspaceMembers = { defaults: { inviteExpiresInMs: 7 * 24 * 60 * 60 * 1000 } };
+```
+
 Workspace scope must reach repository queries. Parsing a workspace slug or
 hiding an admin link is not authorization. Membership and role checks happen
 before an operation discloses records or record existence.
@@ -125,14 +136,12 @@ before an operation discloses records or record existence.
 ### Workspace-scoped features and routes
 
 For a standard CRUD resource owned by a workspace, give its table the
-`workspace_id` column, set the resource's `autofilter: "workspace"`, and bind
-`defineCrudJsonApiFeature()` with `ownershipFilter: "workspace"` and `scope:
-WORKSPACE_CRUD_SCOPE` (from `@jskit-ai/workspaces-core/server/support/workspaceCrud`)
-on a workspace surface. JSKIT then filters `workspaceId` by the workspace in the
-route. A repository method you add reads the workspace id with
-`resolveWorkspaceScopeValue(options.context)`
-(`@jskit-ai/json-rest-api-core/server/jsonRestApiHost`), which throws when the
-context names two workspaces.
+`workspace_id` column, set its table resource's `ownership: "workspace"`, and bind
+`defineCrudFeature()` with `scope: WORKSPACE_CRUD_SCOPE` (from
+`@jskit-ai/workspaces-core/server/support/workspaceCrud`) on a workspace
+surface. JSKIT then filters `workspaceId` by the workspace in the route. A
+repository method you add passes the call's `options` on to the table's handle,
+which scopes every read and write to the context's workspace.
 `workspace_user` also filters by the signed-in user. See the CRUD operations
 guide.
 
@@ -175,9 +184,29 @@ capability provides:
 | `workspaces.services.members` | Members, roles and invitations |
 | `workspaces.services.pendingInvitations` | Invitation resolution, redemption and acceptance participants |
 | `workspaces.services.settings` | Workspace settings |
-| `workspaces.repositories.workspaces`, `.workspaceMemberships`, `.workspaceSettings`, `.workspaceInvites` | Repository access inside the application's own transactions |
+| `workspaces.repositories.workspaceSettings`, `.workspaceInvites` | Settings and invitation records inside the application's own transactions |
 | `workspaces.tenancyProfile` | The resolved tenancy mode and workspace policy |
 
+The workspaces and their memberships are their own capabilities, for code that
+reads or changes them inside its own transactions, typed `Workspaces` and
+`WorkspacesMemberships` in `@jskit-ai/workspaces-core/server/types`. Every
+method takes the call's `options` last and joins the transaction of the
+`txOptions` it is given.
+
+| Capability | Methods |
+| --- | --- |
+| `workspaces` | `findById(id, options)`, `findBySlug(slug, options)` (a deleted workspace is not found, though its slug stays taken), `listSlugsIn`, `findPersonalByOwnerUserId`, `listForUserId(userId, options)`, `insert`, `updateById`, `lock(workspaceId, options)` |
+| `workspaces.memberships` | `findByWorkspaceIdAndUserId`, `ensureOwnerMembership`, `upsertMembership(workspaceId, userId, patch, options)`, `addMember({ workspaceId, userId, roleSid }, options)`, `activeMemberIds(workspaceId, options)`, `listActiveByWorkspaceId`, `findActiveByWorkspaceIdAndUserId`, `listActiveWorkspaceIdsByUserId`, `listActiveWorkspaceIdsByUserIds` |
+
+`addMember` makes the user an active member with the role (`member` when none
+is given), adding the membership or reactivating it. `activeMemberIds` answers
+the active members' user ids at the same cost however many members there
+are, without including their profiles. `lock` takes
+the workspace's row lock until the caller's transaction ends, so work that must
+not interleave for one workspace takes turns; it runs only inside a
+transaction, given its `txOptions`, and answers `{ id }`, or `null` when there
+is no such workspace.
+
 To check one person's membership, for example a notification recipient, call
 `workspaces.services.members.getMember(workspace, userId, options)`. It answers
 that member's `listMembers` entry, or `null` for a removed or unknown member,
@@ -225,8 +254,8 @@ workspace routes, `workspaces-web` switches Vuetify to the `workspace-light` or
 colours. Other routes use the application's themes.
 
 New workspaces start from JSKIT's blue palette unless `config/server.js` sets
-the application's own. Missing fields keep JSKIT's values; an invalid colour
-stops the server at startup:
+the application's own beside the required `invitesEnabled`. Missing colours
+keep JSKIT's values; an invalid colour stops the server at startup:
 
 ```js
 // config/server.js
@@ -301,11 +330,11 @@ authorization and role checks. Do not pass arbitrary HTTP input as options.
 
 | Capability method | Contract |
 | --- | --- |
-| `workspaces.repositories.workspaceInvites.withTransaction(work)` | Delegates to the same JSON REST API's managed `transaction(work)`; awaits commit and completion hooks before resolving. Runs `work` again when the database aborts it as a deadlock victim (see [Database layer](https://mobily-enterprises.github.io/jskit-ai/guide/app-setup/database-layer#deadlock-retries)). |
-| `workspaces.repositories.workspaceInvites.lockWorkspaceForInvitations(workspaceId, { trx })` | Locks the workspace before application receipt/draft rows when composing preparation. Requires an active transaction. |
-| `workspaces.services.members.prepareInvite(workspace, actor, payload, options)` | Requires a managed `options.trx`. Validates the invitation role, replaces pending invitations for that workspace/email, and returns `{ createdInviteId, inviteTokenPreview }`. Never sends. |
-| `workspaces.services.members.sendInvite(workspace, actor, prepared, options)` | Requires no `options.trx`. Reloads the committed pending invitation and workspace display data, validates expiry and token correspondence, and sends that invitation without replacement. |
-| `workspaces.services.members.createInvite(workspace, actor, payload, options)` | Owns preparation and commit, then calls `sendInvite`, and answers with `sendInvite`'s result as JSON:API data (`returnJsonApiData`, read it from `.value`), as the invite action sends it. Rejects `options.trx`. |
+| `workspaces.repositories.workspaceInvites.withTransaction(options, (txOptions) => …)` | The invitations handle's `withTransaction`: joins the caller's transaction or opens one and hands `work` the `txOptions` to pass on; awaits commit and completion hooks before resolving. Runs `work` again when the database aborts it as a deadlock victim (see [data access](https://mobily-enterprises.github.io/jskit-ai/guide/framework/data-access#transactions)). `{ ...options, outermost: true }` refuses a call that already runs inside one. |
+| `workspaces.lock(workspaceId, txOptions)` (capability `workspaces`) | Locks the workspace before application receipt/draft rows when composing preparation. Requires an active transaction. |
+| `workspaces.services.members.prepareInvite(workspace, actor, payload, txOptions)` | Runs only inside a transaction, given its `txOptions`. Validates the invitation role, replaces pending invitations for that workspace/email, and returns `{ createdInviteId, inviteTokenPreview }`. Never sends. |
+| `workspaces.services.members.sendInvite(workspace, actor, prepared, options)` | Refuses to run inside a transaction: it delivers after the preparation's transaction commits. Reloads the committed pending invitation and workspace display data, validates expiry and token correspondence, and sends that invitation without replacement. |
+| `workspaces.services.members.createInvite(workspace, actor, payload, options)` | Owns preparation and commit, then calls `sendInvite`, and answers with `sendInvite`'s result as JSON:API data (`returnJsonApiData`, read it from `.value`), as the invite action sends it. Refuses to run inside a transaction. |
 | `workspaces.invite-acceptance-participant` (optional capability) | One application function receiving `({ invite, user }, options)` inside the acceptance transaction. Without it, acceptance activates the membership only. |
 
 `sendInvite` accepts `{ createdInviteId, inviteTokenPreview }` from preparation or
@@ -344,21 +373,20 @@ setup: ({ reviewedPeople, people, scopes, audit }) => ({
 })
 
 // Inside an authorized application command, in a feature that requires
-// workspaces: "workspaces.core":
+// workspaces: "workspaces.core" and workspaceRecords: "workspaces":
 const { members } = workspaces.services;
 const invites = workspaces.repositories.workspaceInvites;
-const prepared = await invites.withTransaction(async (trx) => {
-  const options = { trx, context };
+const prepared = await invites.withTransaction({ context }, async (txOptions) => {
   // Match acceptance's order: workspace, then application draft/receipt rows.
-  await invites.lockWorkspaceForInvitations(workspace.id, options);
-  const reviewed = await reviewedPeople.lockAuthorizedDraft(draftId, workspace.id, actor, options);
-  const receipt = await reviewedPeople.findMatchingReceipt(reviewed, requestId, options);
+  await workspaceRecords.lock(workspace.id, txOptions);
+  const reviewed = await reviewedPeople.lockAuthorizedDraft(draftId, workspace.id, actor, txOptions);
+  const receipt = await reviewedPeople.findMatchingReceipt(reviewed, requestId, txOptions);
   if (receipt) return { createdInviteId: receipt.inviteId };
   const created = await members.prepareInvite(workspace, actor, {
     email: reviewed.email,
     roleSid: reviewed.roleSid
-  }, options);
-  await reviewedPeople.associateInvitationAndSaveReceipt(reviewed, requestId, created.createdInviteId, options);
+  }, txOptions);
+  await reviewedPeople.associateInvitationAndSaveReceipt(reviewed, requestId, created.createdInviteId, txOptions);
   return { createdInviteId: created.createdInviteId };
 });
 
@@ -401,8 +429,8 @@ exactly once. Revocation after sending starts cannot recall a message.
 Register one callback during feature setup to call the required application
 services. Non-functions throw `TypeError`; duplicate registration throws, and
 registration closes when acceptance/refusal first begins. The callback's invite,
-user and options are shallow frozen. JSKIT owns the transaction and passes its
-`trx` and request `context` to the callback.
+user and options are shallow frozen. JSKIT owns the transaction and passes the
+callback the `txOptions` that carry it and the request's `context`.
 
 Acceptance checks authentication, recipient email, pending state and expiry under
 workspace/invitation locks. Before calling the participant, it activates membership
@@ -420,8 +448,8 @@ callback must not commit, roll back, create transactions/savepoints or perform
 external effects. Participant and later invitation-status failures roll back
 membership (including its previous role/status), person/training links, scopes,
 audit and accepted status. Invalid invitations and refusals do not call the
-participant. Acceptance/refusal reject borrowed `options.trx`; revocation can
-join a managed transaction or create one.
+participant. Acceptance and refusal refuse to run inside the caller's
+transaction; revocation can join one or open its own.
 
 Acceptance/refusal return 401 for unauthenticated access, 403 for a recipient
 email mismatch and 404 for a missing or handled invitation. A matching recipient's
@@ -435,7 +463,7 @@ Preserve `error.transactionOutcome` and `error.cause`: `rolledBack` confirms
 rollback, `committed` can accompany a failed completion hook, and `unknown`
 requires resolving the outcome before retrying. Errors after commit cannot undo
 persistence. See
-[managed transaction guidance](./existing-application-migration.md#json-rest-v2-integration).
+[managed transaction guidance](./existing-application-migration.md#data-access-on-table-resources-json-rest-api-3).
 
 Invitation mutations lock workspace before invitation rows. A losing acceptance,
 refusal, revocation or replacement cannot overwrite accepted/revoked state.
@@ -494,7 +522,41 @@ Workspace surfaces put the slug in their pages root, such as
 `w/[workspaceSlug]/admin` for administration. Keep the default surface
 (`surfaceDefaultId`, usually `home`) free of a workspace requirement: `/`,
 invitation links and other unscoped pages belong to it. With
-`webRootAllowed: "no"`, `/` opens that surface's root.
+`webRootAllowed: "no"`, `/` opens that surface's root. The foundation
+defines `home` and its `public` access policy, and the `auth/auth-surface`
+pattern the `auth` surface; the workspace surfaces add a policy and two
+definitions:
+
+```js
+// config/surfaceAccessPolicies.js
+surfaceAccessPolicies.workspace_member = { requireAuth: true, requireWorkspaceMembership: true };
+
+// config/public.js
+config.surfaceDefinitions.app = {
+  id: "app",
+  label: "App",
+  pagesRoot: "w/[workspaceSlug]",
+  requiresAuth: true,
+  requiresWorkspace: true,
+  accessPolicyId: "workspace_member"
+};
+config.surfaceDefinitions.admin = {
+  id: "admin",
+  label: "Admin",
+  pagesRoot: "w/[workspaceSlug]/admin",
+  requiresAuth: true,
+  requiresWorkspace: true,
+  accessPolicyId: "workspace_member"
+};
+```
+
+An access policy takes `requireAuth`, `requireWorkspaceMembership`,
+`requireAnyPermissions` and `requireAllPermissions` (permission lists), and
+`requireFlagsAny` and `requireFlagsAll` (flags the server's bootstrap sets in
+`surfaceAccess`). Without `requireAuth` or `requireWorkspaceMembership` it
+takes the surface's `requiresAuth` or `requiresWorkspace`. The browser applies
+the whole policy; the server reads only `requireWorkspaceMembership: false`
+from it, and a route's own `auth` and `permission` authorize it there.
 
 `workspaces-web` remembers the last workspace each person opened in this
 browser. The **Your workspaces** page, `WorkspacesClientElement` from

package/guide/agent/app-setup/quickstart.md

@@ -58,7 +58,7 @@ questions and must not be copied into committed source.
 ## Build the first product operation
 
 Use the narrow relevant pattern and public APIs. For database CRUD, author an
-immutable migration and a normal shared resource contract; use framework APIs
+immutable migration, its table resource and, for screens, a CRUD contract; use framework APIs
 for standard mechanics and app code for product-specific behavior. Do not
 invoke a source generator or reconstruct one as prompt options.
 

package/guide/agent/app-setup/run-an-accounts-hub.md

@@ -9,7 +9,7 @@ hub shows its sign-in page, the app receives an ID token, and the app keeps its
 own session.
 
 ```bash
-npm install @jskit-ai/oidc-issuer-core @jskit-ai/database-runtime-mysql
+npm install @jskit-ai/oidc-issuer-core @jskit-ai/database-runtime @jskit-ai/database-runtime-mysql
 ```
 
 Start from the "JSKIT · Accounts hub" template (seed-jskit branch

package/guide/agent/app-setup/upgrading-jskit.md

@@ -62,7 +62,10 @@ npm run jskit:update
 ```
 
 The updater rejects unknown JSKIT packages and private JSKIT overrides during
-preflight, before changing any manifest.
+preflight, before changing any manifest. It removes a package a release retired
+(`@jskit-ai/json-rest-api-core`, replaced by `@jskit-ai/resource-runtime`) and
+says what replaced it; while the application's code still imports a retired
+package, it refuses and names the import to use instead.
 
 `jskit:update` reads the latest published catalog, discovers the root manifest
 and npm workspaces, and preflights every declared `@jskit-ai/*` package. It then
@@ -210,8 +213,10 @@ application:
    `defineConfig(browserTestConfig({ testDir: "./tests/e2e", prepare: "tests/e2e/databases.js" }))`
    from `@jskit-ai/jskit-catalog/browser-tests`, with `server`, `build`, `env`
    or `port` only where its own differ from `node ./bin/server.js`,
-   `npm run build` and 4173, and `globalTimeout` only for a suite measured to
-   need more than 20 minutes. Settings a config adds (projects, a globalSetup
+   `npm run build` and 4173, `globalTimeout` only for a suite measured to
+   need more than 20 minutes, and `actionTimeout` or `navigationTimeout` only
+   for an action or page measured to need more than 15 or 30 seconds (a stale
+   locator should fail in seconds, not minutes). Settings a config adds (projects, a globalSetup
    that proves the server's identity, `timezoneId`) spread over the result:
    `defineConfig({ ...base, projects, use: { ...base.use, timezoneId } })`. A
    second local Playwright config and any `npm run develop` or `vite`

package/guide/agent/app-setup/users.md

@@ -44,11 +44,14 @@ in-page banner that moves the form.
 
 Use `users/user-administration-server` only when the product needs global or
 workspace-scoped administration beyond self-service settings. It demonstrates
-an app-owned feature package built with `defineCrudJsonApiFeature()` while
-keeping profile persistence in `users-core`.
-
-Do not expose password hashes, provider credentials, or session data through a
-user resource. Apply permission and workspace scope before repository access so
+an app-owned feature package built with `defineCrudFeature()` on a CRUD
+contract over users-core's `userProfileTableResource`, while keeping profile
+persistence, and the `users` table's one table resource, in `users-core`: the
+feature names `ownerRepository: "users.profiles"` and serves the table through
+users-core's repository instead of owning it.
+
+Do not expose password hashes, provider credentials, or session data through
+the CRUD contract. Apply permission and workspace scope before repository access so
 record existence is not leaked.
 
 ## Verification

package/guide/agent/framework/application-operations.md

@@ -101,7 +101,7 @@ normal order is:
 
 1. confirm the product resource, ownership, operations, and fields
 2. author a migration as normal application source
-3. author the shared resource contract through `resource-crud-core`
+3. define the table resource (`defineTableResource`) and, for screens, its CRUD contract (`defineCrudContract`)
 4. use framework APIs for standard repository/service/action/route mechanics
 5. author product-specific screens from the relevant UI pattern
 6. run migrations and direct verification

package/guide/agent/framework/crud-operations.md

@@ -13,10 +13,15 @@ Take database, surface, access, ownership, operations, and fields from product
 intent and current source. Ask when a material choice is missing. Do not
 translate the work into generator options.
 
-Read the narrow package-owned pattern in the [source pattern
-library](/patterns/): `crud/resource-contract` for the resource,
-`crud/json-api-resource-package` for the server, and `crud/crud-screen-set`
-for routed UI. Child-resource and row-policy patterns own those variations.
+Read the package-owned pattern in the [source pattern
+library](/patterns/): `database/table-resource` for the table,
+`crud/crud-contract` for its HTTP surface,
+`crud/crud-feature-package` for the server, and `crud/crud-screen-set`
+for routed UI; the [row
+policies](https://github.com/mobily-enterprises/jskit-ai/blob/main/packages/agent-docs/heuristics/row-policies.md)
+and [child
+CRUDs](https://github.com/mobily-enterprises/jskit-ai/blob/main/packages/agent-docs/heuristics/child-cruds.md)
+heuristics cover those variations.
 
 Normal CRUD tables use one non-null integer primary key. Foreign keys are
 single-column; composite unique indexes are business constraints, not
@@ -26,26 +31,38 @@ Match visibility to real ownership and test allowed plus cross-owner cases.
 ## Author the resource normally
 
 1. Write an immutable app-owned migration.
-2. Define the shared resource contract through `defineCrudResource()`.
-3. Use `defineCrudJsonApiFeature()` for standard repository, service, action,
-   permission, resource-host, and route mechanics.
+2. Define the table resource with `defineTableResource()` and its HTTP surface
+   with `defineCrudContract()`, which names its `namespace`: the routes',
+   messages' and events' public name, never taken from the resource.
+3. Use `defineCrudFeature()` for standard table ownership, service, action,
+   permission, and route mechanics.
 4. Customize through `decorateRepository`, `decorateService`,
    `operationLifecycle`, and named `actions`; do not copy the standard CRUD
    repository/action/route stack.
 5. Build routed screens from the matching `http-web`/CRUD UI pattern.
 
-The resource is canonical for fields, operations, validation, transport,
-messages, and route parameters. Do not duplicate its schema or serializers.
+The table resource is canonical for fields, columns, ownership and search; the
+CRUD contract for operations, validation, transport, messages and route
+parameters. A contract shows and accepts only the fields its `fields` names (stored
+`createdAt` and `updatedAt` show without an entry; `createdAt: { output:
+false }` hides one), so a column added later stays out of every API until a
+contract names it. A CRUD feature's answers follow the same rule: an unnamed
+relationship is left out, and an included record shows only its id, its
+relation's `labelKey` and the fields the including contract lists in that
+field's `output.includeFields` (`{ breed: ["name"] }` in the list shows a
+record it links to, as deep as listed), never another contract's output.
+A package with a CRUD feature lists `crud.contracts` in its descriptor's
+`capabilities.requires`. Do not duplicate their schema or serializers.
 Prefer `useCrudListScreen()`, `useCrudViewScreen()`, and
 `useCrudAddEditScreen()`; use `useCommand()` or `useEndpointResource()` for
 non-standard operations.
 
 Add resource service methods with `decorateService`; expose commands such as
-`confirm`, `publish`, or `cancel` through named `actions`. With `operationLifecycle`, mutation `before`,
-`execute`, and `after` share one repository transaction, `execute` receives
-`standard(nextInput)`, and `afterCommit` follows commit. Repositories persist;
-services and hooks orchestrate. Use a transactional outbox for durable
-external work.
+`confirm` or `cancel` through named `actions`. With `operationLifecycle`, mutation `before`,
+`execute`, and `after` share one transaction, rerun on deadlock, so they touch
+only the database; `execute` receives `standard(nextInput)`. Outside effects go
+in `afterCommit`, run once after commit, or an outbox when durable.
+Repositories persist; services and hooks orchestrate.
 
 ## Choose ownership, API access and client access independently
 
@@ -53,37 +70,31 @@ These controls answer different questions:
 
 | Control | Purpose | Public records | Owner-scoped records |
 | --- | --- | --- | --- |
-| Resource `autofilter` | Which rows belong to the request scope | `"public"`; no ownership column | `"user"`; real non-null `userId` column |
-| Resource `apiAccess` | Who may call the API | `"public"` | `"authenticated"` |
-| Feature `ownershipFilter` | Server route/action ownership scope | `"public"` | `"user"` |
+| Table resource `ownership` | Which rows belong to the request scope | `"public"`; no ownership column | `"user"`; real non-null `userId` column |
+| CRUD contract `apiAccess` | Who may call the API | `"public"` | `"authenticated"` |
+| Feature route visibility | Server route/action scope: the table's `ownership` unless the feature names `visibility` | `"public"` | `"user"` |
 | Client `access` | Whether to require bootstrap permissions | Default `"auto"` with no permission requirements | Default `"auto"`; declare permissions when required |
 
-`access` accepts `auto`, `always`, or `never`, not `public`. With `auto`, a
-screen with no permission requirements does not require a permissions bootstrap.
-`always` does require it. Do not add authentication or workspace machinery to
-compensate for an unnecessary `always` override. Server access and ownership
+`access` accepts `auto`, `always`, or `never`, not `public`. `auto` requires a
+permissions bootstrap only for a screen with permission requirements; `always`
+always does. Do not add authentication or workspace machinery to
+make up for an unneeded `always` override. Server access and ownership
 remain authoritative.
 
-The Books source patterns demonstrate user ownership. For an intentionally
-public create/list resource, use the same patterns with this resource contract:
+The Books source patterns show user ownership. For a public create/list
+resource, use them with this table resource and CRUD contract:
 
 ```js
-const bookResource = defineCrudResource({
-  namespace: "books",
+const bookResource = defineTableResource({
+  name: "books",
   tableName: "books",
-  apiAccess: "public",
-  autofilter: "public",
-  crudOperations: ["list", "view", "create"],
+  ownership: "public",
   schema: {
     title: {
       type: "string",
       required: true,
       minLength: 1,
-      maxLength: 255,
-      operations: {
-        output: { required: true },
-        create: { required: true }
-      }
+      maxLength: 255
     }
   },
   searchSchema: {
@@ -96,20 +107,27 @@ const bookResource = defineCrudResource({
     }
   }
 });
+
+const bookCrud = defineCrudContract(bookResource, {
+  namespace: "books",
+  apiAccess: "public",
+  operations: ["list", "view", "create"],
+  fields: { title: { output: "required", create: "required" } }
+});
 ```
 
-Import `defineCrudResource` from
-`@jskit-ai/resource-crud-core/shared/crudResource`. Its app-owned migration
-creates `books` with an integer primary key `id` and non-null `title`; omit
-`userId` and its foreign key for this public variant. `list` requires `view`
-in the shared resource contract, even when the UI has no detail page. A create
-response uses the resource output contract. Keep operation names such as
-`list`, `view` and `create`; do not invent output-operation aliases.
-
-Bind `defineCrudJsonApiFeature()` with this resource, `ownershipFilter:
-"public"`, `relativePath: "/books"` and the application's configured public
-surface. Keep the existing package/provider and migration registration from
-`crud/json-api-resource-package`.
+Import `defineTableResource` from `@jskit-ai/resource-core/shared/tableResource`
+and `defineCrudContract` from `@jskit-ai/resource-crud-core/shared/crudContract`.
+Its migration creates `books` with an integer `id` and non-null `title`; omit
+`userId` and its foreign key.
+`list` requires `view` in the CRUD contract, even when the UI has no detail
+page. A create response uses the CRUD contract's output. Keep operation names
+such as `list`, `view` and `create`; do not invent output-operation aliases.
+
+Bind `defineCrudFeature()` with `crud: bookCrud`, `relativePath: "/books"`
+and the application's configured public surface; the table's `"public"`
+ownership makes its routes public. Keep the existing package/provider and migration registration from
+`crud/crud-feature-package`.
 
 For the list, keep `BookListPage.vue` thin: use `resourceNamespace: "books"`
 in `useCrudListScreen()` on the configured public surface, remove unsupported