@jskit-ai/agent-docs 0.1.193 → 0.1.194

package/guide/agent/app-setup/database-layer.md

@@ -111,8 +111,67 @@ package's metadata:
 }
 ```
 
-Names must remain unique across the effective migration directories. Keep
-constraints in a later migration when ordering matters.
+Names must remain unique across the effective migration directories. Preserve
+the basename when relocating a migration: Knex records that name in its ledger.
+Do not rename it to force execution or edit an already-applied migration's body;
+changed schema behavior requires a new migration.
+
+### Directory order comes before filenames
+
+`createKnexMigrationConfigFromApp()` sets `sortDirsSeparately: true` and runs
+pending migrations in this order, using the default `migrationsDirectory`:
+
+1. Application `migrations/`.
+2. Discovered package migration directories, sorted by their absolute paths
+   using `localeCompare`.
+3. Application `migrations/constraints/`.
+
+Knex sorts filenames within each directory, not across the whole graph; see
+its [`sortDirsSeparately` option](https://knexjs.org/guide/migrations.html#migration-api).
+Package discovery does not topologically order tables or foreign keys. A newer
+timestamp in an earlier package still runs before every file in a later package.
+Inspect the effective `knexfile.js` configuration if the app customizes it.
+
+Keep table and column creation with the owning package. Put cross-package
+foreign keys and other constraints that need the complete package schema in
+application `migrations/constraints/`. An ordinary root `migrations/` file runs
+too early for this purpose. For example, a `pet_notes.product_id` column can be
+added by the pet-notes package, but its foreign key to the products package's
+`products.id` belongs in the final constraints phase. Do not rely on today's
+package-directory order to make a cross-package reference work.
+
+Before adding the key, check that both tables and columns exist, the referenced
+key is indexed appropriately, column types match (including integer signedness),
+existing values have valid parents, and `ON DELETE SET NULL` uses a nullable
+column. An incorrectly formed foreign key is not always an ordering failure.
+Do not suppress the failure, skip a missing parent, or disable foreign-key
+checks to make preparation appear successful.
+
+### MySQL and MariaDB failures can leave partial schema
+
+MySQL and MariaDB DDL can commit implicitly. If adding a column succeeds and a
+later statement adding its foreign key fails, the column can remain even though
+Knex has not recorded that migration as completed. A Knex transaction does not
+make a multi-statement DDL migration atomic. See the
+[MySQL implicit-commit rules](https://dev.mysql.com/doc/refman/8.4/en/implicit-commit.html)
+and [MariaDB implicit-commit rules](https://mariadb.com/docs/server/reference/sql-statements/transactions/sql-statements-that-cause-an-implicit-commit).
+
+Design new multi-step DDL migrations for their concrete partial states. Inspect
+the column and foreign key independently; `hasColumn()` alone cannot prove the
+constraint exists. Verify the definition of an existing object before skipping
+its creation, complete only missing work, and fail clearly on incompatible
+schema. Do not catch arbitrary SQL errors as success or mark incomplete work
+as applied. Keep recovery local to the affected migration or an explicit repair;
+do not add schema repair to request handlers or normal server startup.
+
+For an existing failure, inspect the ledger and actual schema read-only first.
+Preserve applied migration bodies and use a new corrective migration for
+databases that already recorded them. If an earlier pending migration prevents
+that correction from running, describe the required backed-up, explicit repair
+before retrying; a later file alone cannot repair a blocked earlier step. Any
+relocation must retain its basename and be checked against both fresh and
+existing ledgers. Never drop valuable data or delete ledger entries to force
+a replay.
 
 ## Seed data is not a migration
 
@@ -151,12 +210,22 @@ not merely because a useful resource has behavior beyond list and save.
 
 ## Verification
 
-- Rebuild a disposable database from the complete migration graph.
-- Run `npm run db:migrate:status` after migration.
+- For every schema change, run the normal preparation entrypoint against a
+  fresh disposable database on the selected engine with the complete package
+  graph. An existing development database can hide ordering failures.
+- In a separate disposable fixture at the previous schema and ledger, apply
+  the upgrade and prove representative existing rows survive.
+- For multi-step MySQL or MariaDB DDL, reproduce partial completion (for
+  example, column present, foreign key absent, migration still pending), retry
+  preparation, and verify the final column and constraint definitions.
+- Run preparation again and `npm run db:migrate:status`; require no pending
+  migrations. Prove invalid references are rejected and the declared delete
+  behavior works. A stubbed Knex test or successful process exit is insufficient.
 - Exercise a real transaction and one invalid-connection case.
 - When a seed operation exists, run it twice and require the second run to be
   safe.
-- Test MySQL and PostgreSQL patterns independently.
+- Use the application's selected engine; exercise each supported engine when
+  changing a shared pattern. Report unavailable database verification explicitly.
 
 Do not add migration receipts, sync ledgers, generator provenance, or dialect
 questionnaires. The installed graph, migration source, environment, and

package/guide/agent/app-setup/existing-application-migration.md

@@ -224,33 +224,28 @@ or unresolved write.
 
 ### Workspace invitation transaction compatibility (workspaces-core 0.1.198)
 
-Workspace invitation creation, acceptance and refusal now own managed
-transactions. Existing calls to `members.createInvite(..., { trx })` must become
-`members.prepareInvite(..., { trx })`, application association/receipt writes,
-confirmed commit, then `members.sendInvite(...)` without `trx`. Move writes that
-must accompany built-in acceptance into
-`pendingInvitations.registerAcceptanceParticipant(fn)` during feature setup.
-Acceptance/refusal reject borrowed transactions; revocation can still participate
-in a managed transaction. Ordinary invitation actions retain their IDs and
-response shapes. Terminal repository transitions now reject instead of
-rewriting already accepted/revoked invitations. Mailer exceptions return a fixed
-message to avoid leaking invitation tokens from provider diagnostics.
-
-Required participant writes roll back together. Preserve transaction outcomes:
-a failure after commit is not rollback, and an unresolved commit must not be
-blindly replayed. Matching-recipient expiry revocation deliberately commits
-before its 409 rejection. Review the
-[workspace invitation contract and example](./multi-homing.md#transactional-invitation-participation)
-when migrating. No schema migration is required for these framework APIs.
-
-The first coordinated release containing this contract includes
+Invitation creation, acceptance and refusal now own their managed transactions:
+
+- Replace `members.createInvite(..., { trx })` with
+  `members.prepareInvite(..., { trx })`, save the application association/receipt,
+  commit, then call `members.sendInvite(...)` without `trx`.
+- Move related acceptance writes into
+  `pendingInvitations.registerAcceptanceParticipant(fn)` during feature setup.
+  Acceptance/refusal reject borrowed transactions; revocation can still join one.
+- Terminal repository transitions reject accepted/revoked invitations. Mailer
+  exceptions return a fixed message to keep tokens out of provider diagnostics.
+
+Participant writes roll back together. Preserve transaction outcomes when handling
+errors: completion-hook failures cannot undo a commit, and expiry revocation
+commits before returning 409. See the
+[workspace invitation contract and example](./multi-homing.md#transactional-invitation-participation).
+Action IDs, response shapes and schema are unchanged.
+
+The first coordinated release includes
 `@jskit-ai/workspaces-core@0.1.198`, `@jskit-ai/jskit-catalog@0.1.245` and
-`@jskit-ai/agent-docs@0.1.192`. Once that release is published, use
-`npm run jskit:update` in the application to upgrade the coordinated graph,
-restart the backend, check the actual installed versions, and assert
-that `prepareInvite`, `sendInvite` and `registerAcceptanceParticipant` are present
-on the resolved capability. Application domain integration and real email
-activation remain separate work.
+`@jskit-ai/agent-docs@0.1.192`. Run `npm run jskit:update`, restart the backend,
+and check the installed versions and methods on `workspaces.core`. Application
+integration and real email activation remain separate work.
 
 ## 4. Adopt migrations without breaking either database history
 
@@ -261,9 +256,15 @@ historical migration when moving it so the existing Knex ledger continues to
 recognize it. Basenames must be unique across the effective graph.
 
 Keep cross-package foreign keys and other dependency-sensitive constraints in
-later application-owned migrations when package ordering requires it. Seeds
-are not migrations: run one explicit application-owned, idempotent seed after
-the complete graph has migrated.
+application `migrations/constraints/`, the final phase of
+`createKnexMigrationConfigFromApp()`. It uses `sortDirsSeparately: true`: root
+`migrations/` runs before the sorted package directories, and filenames only
+order work within their own directory. A later timestamp in a package does not
+defer its foreign key until another package has created the parent table.
+Follow the [database ordering and partial-failure recovery rules](https://mobily-enterprises.github.io/jskit-ai/guide/app-setup/database-layer#directory-order-comes-before-filenames),
+including independent checks for columns and constraints after MySQL or MariaDB
+DDL fails. Seeds are not migrations: run one explicit application-owned,
+idempotent seed after the complete graph has migrated.
 
 Prove both histories:
 
@@ -274,6 +275,10 @@ Prove both histories:
    with the intended schema.
 3. Run the normal migrate-then-seed entry point twice. The second run must have
    no pending migration and the seed must be safe and stable.
+4. In disposable fixtures, prove upgrade from the previous schema preserves
+   rows, and multi-step MySQL or MariaDB DDL resumes from partial completion
+   with the intended foreign keys enforced. Read-only ledger inspection alone
+   does not prove an upgrade or recovery.
 
 A managed editor allocates one isolated mutable development database per
 session. It owns creation, credentials, lifetime, and environment injection;

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

@@ -41,23 +41,20 @@ a policy/runtime mismatch.
 
 ## Transactional invitation participation
 
-Use the existing `workspaces.core` capability when accepting an invitation must
-also connect an application-owned identity, training history, access scopes or
-required audit records. JSKIT owns tokens, invitation state and membership; the
-application owns its reviewed association and domain policy. The built-in
-`workspace.invite.redeem` action runs the participant. No replacement route,
-client follow-up save or after-action event is needed.
+Use `workspaces.core` to connect application records during the built-in
+`workspace.invite.redeem` action. JSKIT owns tokens, invitation state and
+membership. The application owns its reviewed person association, training,
+access scopes and audit records.
 
-Saving intended access without sending remains an application draft. Do not call
-preparation until an administrator deliberately issues an invitation: preparation
-creates a real token and pending invitation, but does not activate membership.
+Keep intended access in an application draft until an administrator issues an
+invitation. Preparation creates a token and pending invitation without activating
+membership or sending mail.
 
 ### Public server methods
 
-These methods are trusted server composition APIs, not new public actions. The
-caller must authorize creation, delivery and revocation in the requested workspace.
-The ordinary invitation routes retain their existing authorization and role
-validation. Do not forward arbitrary HTTP input as server composition options.
+These server APIs require the caller to authorize creation, delivery and
+revocation in the requested workspace. Ordinary invitation routes retain their
+authorization and role checks. Do not pass arbitrary HTTP input as options.
 
 | Capability method | Contract |
 | --- | --- |
@@ -70,20 +67,18 @@ validation. Do not forward arbitrary HTTP input as server composition options.
 
 `sendInvite` accepts `{ createdInviteId, inviteTokenPreview }` from preparation or
 only `{ createdInviteId }` for a later attempt. The latter uses JSKIT's existing
-opaque token-hash encoding without rotating the token. Supplying an empty or
-mismatched token rejects. Email, role, expiry and workspace display fields come
-from the stored invitation/workspace, not replacement input. Its response keeps
+opaque token-hash encoding without rotating the token. Empty or mismatched tokens
+reject. Email, role, expiry and workspace display fields come from stored records.
+The response includes
 `createdInviteId`, `inviteTokenPreview`, `inviteUrl` and `inviteDelivery` alongside
-the ordinary workspace/invitation-list payload. Treat tokens and URLs as secrets;
-do not log them or put them in diagnostic messages or administrative receipts.
-A receipt normally needs only the exact invitation ID.
+the ordinary workspace/invitation-list payload. Keep tokens and URLs out of logs,
+diagnostics and administrative receipts; save the invitation ID in the receipt.
 
 ### Preparation, association, commit and controlled delivery
 
-Inside application feature setup, declare `workspaces: "workspaces.core"` in
-`requires`, then use that capability. The `reviewedPeople`, `people`, `scopes`
-and `audit` names below represent application-owned services, not JSKIT APIs.
-Their writes must forward the provided transaction to their repositories.
+Declare `workspaces: "workspaces.core"` in the application's feature `requires`.
+In this example, `reviewedPeople`, `people`, `scopes` and `audit` are application
+services. Each forwards the supplied transaction to its repositories.
 
 ```js
 // During application Feature.setup, before serving requests:
@@ -118,25 +113,22 @@ const prepared = await invites.withTransaction(async (trx) => {
   }, options);
   await reviewedPeople.associateInvitationAndSaveReceipt(reviewed, requestId, created.createdInviteId, options);
   return { createdInviteId: created.createdInviteId };
-}); // Confirmed commit; a rejection here must not fall through to delivery.
+});
 
 const result = await members.sendInvite(workspace, actor, prepared, { context });
-// Persist delivery feedback through the application owner. Avoid logging result:
-// it contains a secret token and URL as well as the nonsecret delivery outcome.
+// Store the delivery outcome, not the token or URL in result.
 await reviewedPeople.recordDeliveryOutcome(prepared.createdInviteId, result.inviteDelivery, { context });
 ```
 
-The application must lock its reviewed draft/receipt, enforce request identity,
-and reject changed input on a reused request ID. A retry after losing the
-preparation response reads that receipt instead of preparing another invitation.
-Association failure rolls back the new invitation, replacement of an older
-invitation, receipt and application writes. This is not generic framework
-idempotency, and does not imply exactly-once email.
+Lock the reviewed draft/receipt and reject changed input on a reused request ID.
+After a lost preparation response, read the receipt instead of preparing another
+invitation. Association failure rolls back the new invitation, replacement of
+the previous invitation, receipt and application writes. Send only after the
+transaction resolves successfully.
 
-Real SMTP is unnecessary for implementation and verification. With no
-`workspaceInviteMailer`, delivery returns `status: "mailer_unconfigured"`, an
-explanatory `message` and an empty `providerMessageId`; the invitation remains
-committed. A test application can configure a controlled mailer:
+With no `workspaceInviteMailer`, delivery returns `status: "mailer_unconfigured"`,
+an explanatory `message` and an empty `providerMessageId`; the invitation remains
+committed. Use a controlled mailer in tests; SMTP is unnecessary:
 
 ```js
 workspaceInviteMailer: {
@@ -147,86 +139,75 @@ workspaceInviteMailer: {
 }
 ```
 
-A thrown renderer/mailer error returns `inviteDelivery.status: "failed"` and a
-fixed message, avoiding accidental token leakage through provider exceptions.
-It does not delete the invitation/association or activate membership. Mailer
-results retain their normalized status, message and provider message ID; a
-successful default is `sent`. A provider exception or interrupted response may
-occur after a provider accepted the message: `failed` is not proof of nondelivery.
-There is no exactly-once delivery guarantee. Applications own durable delivery
-attempts and safe retry policy. Validation checks committed invitation state
-before sending; revocation after sending starts cannot recall the message.
+Renderer/mailer exceptions return `inviteDelivery.status: "failed"` with a fixed
+message to keep provider errors from exposing tokens. Persistence is unchanged.
+Successful mailer results retain their normalized status, message and provider
+message ID; the default status is `sent`.
+
+A provider may accept a message before throwing or losing its response. The
+application must track delivery attempts and decide when to retry; email is not
+exactly once. Revocation after sending starts cannot recall a message.
 
 ### Acceptance and failure semantics
 
-Register one callback during feature setup. It composes any application domain
-owners explicitly. Non-functions throw `TypeError`; a second registration
-throws, and registration closes when acceptance/refusal first begins. The
-callback's invite, user and options envelope are shallow frozen. It receives the
-same managed `trx` and request `context`; transaction ownership stays with JSKIT.
-
-Acceptance authenticates the user, checks email, pending state and expiry, then
-revalidates the invitation under workspace/invitation locks. Membership is
-available as active inside that transaction before the callback runs. Existing
-role-upsert semantics remain: the stored invitation role becomes the membership
-role, including for an existing membership. The callback cannot authorize role
-or scope overrides from client input. It must recheck the reviewed version,
-workspace, current inviter authority, person eligibility, existing account link,
-and scope eligibility using application-owned data.
-
-An ordinary invitation with no application association may pass through. A
-stale, revoked, conflicting or expected-but-missing association must fail closed.
-The application needs enough durable association/review state to distinguish
-these cases; absence alone cannot identify a deleted reviewed association.
-
-Await every owner write and forward the same transaction. Do not commit,
-roll back, use savepoints, start a new transaction, or perform external side
-effects in the callback. Do not swallow failures. Participant exceptions and
-later invitation-status failures roll back membership (including its prior role
-and status), person/training links, scopes, required audit and accepted status.
-The callback is not invoked for an invalid invitation or on refusal. Acceptance
-and refusal reject borrowed `options.trx`; revocation can join a managed
-transaction or own one when none is supplied.
-
-A missing/already-handled invitation rejects with 404; mismatched authenticated
-email with 403; unauthenticated access with 401. An expired invitation for its
-matching recipient is revoked in a committed transaction and then rejects with
-409 and `transactionOutcome: "committed"`. It never activates membership or
-runs the participant. A failure to commit that revocation preserves the managed
-transaction error instead. Delivery rejects missing/foreign/handled invitations
-with 404, expired invitations with 409, and mismatched tokens with 400.
-
-Keep `error.transactionOutcome` and `error.cause` when translating failures.
-`rolledBack` confirms rollback; `committed` can indicate a completion-hook error
-after successful persistence; `unknown` leaves the outcome unresolved. A thrown
-error alone does not prove rollback. After-commit failures and external effects
-cannot be included in the atomic guarantee. See
+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.
+
+Acceptance checks authentication, recipient email, pending state and expiry under
+workspace/invitation locks. Before calling the participant, it activates membership
+with the stored invitation role, including when updating an existing membership.
+The participant must use application data to check the review version, workspace,
+current inviter authority, person eligibility, existing account link and scope
+eligibility. Client input cannot authorize role or scope overrides.
+
+An ordinary invitation without an application association may pass through.
+Reject stale, revoked, conflicting or unexpectedly missing associations. Retain
+enough review history to distinguish ordinary invitations from deleted associations.
+
+Await every write with the same transaction and let failures propagate. The
+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.
+
+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
+expired invitation is revoked and committed before returning 409 with
+`transactionOutcome: "committed"`, without activating membership or calling the
+participant. A failed revocation commit retains its transaction error. Delivery
+returns 404 for missing, foreign or handled invitations, 409 for expiry and 400
+for a token mismatch.
+
+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).
 
-Invitation mutations lock workspace before invitation rows, and use current
-locking reads before terminal transitions. Accepted/revoked state cannot be
-overwritten by a losing acceptance, refusal, revocation or replacement. A
-replacement after acceptance may create a new pending invitation while retaining
-the older accepted invitation. Keep callbacks short: invitation changes in the
-same workspace serialize. Database deadlocks/serialization failures remain
-transaction errors; callbacks are not automatically replayed.
+Invitation mutations lock workspace before invitation rows. A losing acceptance,
+refusal, revocation or replacement cannot overwrite accepted/revoked state.
+Replacement can create a new pending invitation after acceptance while retaining
+the accepted invitation. Keep callbacks short: invitation changes in one workspace
+serialize. Deadlocks/serialization failures propagate without replaying callbacks.
 
 ### Compatibility and verification
 
-This server-composition contract starts with `@jskit-ai/workspaces-core@0.1.198`.
-Transactional callers of
-`createInvite` must migrate to preparation plus post-commit delivery. Related
-acceptance writes must move into the participant. `markAcceptedById` and
-`revokeById` now reject terminal/missing invitations rather than overwriting their
-state. No route/action ID, package export, table or migration is added.
-
-Verify ordinary invitations, rollback after each domain write, late framework
-failure, existing membership restoration, recipient checks, stale associations,
-controlled delivery failures and lost-response receipts. Run the normal redeem
-action in tests. Use independent connections to race acceptance against acceptance,
-refusal, revocation and replacement in both winning orders. The package fixture
-runs these races on native MySQL/MariaDB and PostgreSQL; SQLite skips those races
-and is not evidence of native locking correctness.
+Since `@jskit-ai/workspaces-core@0.1.198`, transactional `createInvite` callers
+must use preparation followed by delivery after commit. Move related acceptance
+writes into the participant. `markAcceptedById` and `revokeById` reject missing
+or handled invitations. Route/action IDs, package exports and schema are unchanged.
+
+Test through the normal redeem action: ordinary invitations, rollback after
+application and final status writes, existing membership restoration, invalid
+recipients/associations, controlled delivery failures and lost-response receipts.
+The package fixture tests competing acceptance, refusal, revocation and replacement
+in both winning orders on independent MySQL/MariaDB and PostgreSQL connections.
+SQLite skips those races.
 
 Use only a verified empty disposable database named
 `jskit_repository_test_*` for native tests. The runner verifies the actual target,
@@ -239,17 +220,13 @@ node --test packages/workspaces-core/test/repositories.integration.test.js
 npm run verify
 ```
 
-A passing framework fixture does not complete the application's People, training,
-permissions, privacy or browser integration. Publication remains a separate
-maintainer operation. After a coordinated release is published, run the
-application's `npm run jskit:update`, restart its backend and verify that
+Run the application's `npm run jskit:update`, restart its backend and verify that
 `members.prepareInvite`, `members.sendInvite` and
 `pendingInvitations.registerAcceptanceParticipant` are functions on the installed
-`workspaces.core` capability. Check the installed package/catalogue versions
-against that release. The first coordinated release containing this contract pairs
+`workspaces.core` capability. The first release containing this contract pairs
 `@jskit-ai/workspaces-core@0.1.198`, `@jskit-ai/jskit-catalog@0.1.245` and
-`@jskit-ai/agent-docs@0.1.192`. Upgrade the coordinated dependency graph rather
-than pinning only `workspaces-core`. Do not patch installed `node_modules`.
+`@jskit-ai/agent-docs@0.1.192`. Upgrade the coordinated dependency graph, then run
+the application's identity, training, permission, privacy and browser tests.
 
 ## Browser composition
 

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

@@ -75,7 +75,21 @@ Migrations are immutable application source owned with their resource. Never
 make a live table or a generator the sole source of truth. Inspect schemas for
 adoption and diagnosis; inspection is optional.
 
-Before sign-off, rebuild in a fresh disposable database, compare schemas,
-test ownership boundaries and failures, and run current-state verification.
+Read [ordering and recovery](https://mobily-enterprises.github.io/jskit-ai/guide/app-setup/database-layer#directory-order-comes-before-filenames)
+before schema work; check Knex configuration and ledger.
+`createKnexMigrationConfigFromApp()` uses `sortDirsSeparately: true`: root
+`migrations/`, sorted package directories, then `migrations/constraints/`.
+Timestamps order only within directories. Keep tables/columns with their package;
+put cross-package foreign keys in the final phase.
+
+MySQL/MariaDB can leave committed DDL without a ledger entry. Check columns and
+keys separately; `hasColumn()` is insufficient. Validate existing definitions,
+complete missing work, and plan recovery for blocked steps. Preserve applied
+bodies and relocated basenames. Never disable foreign-key checks or skip parents.
+
+On the selected engine, prove fresh preparation, upgrades preserving rows,
+partial-DDL retries, and a second preparation with no pending migrations.
+Inspect constraints and test rejected references and delete behavior.
+
 Do not create a workboard entry, ownership receipt, generation record, or
 historical proof that tooling ran.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/agent-docs",
-  "version": "0.1.193",
+  "version": "0.1.194",
   "description": "Distributed JSKIT agent references, prompts, guides, and generated reference maps.",
   "type": "module",
   "files": [

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

@@ -5,7 +5,7 @@
   "private": true,
   "type": "module",
   "dependencies": {
-    "@jskit-ai/kernel": "0.1.221",
+    "@jskit-ai/kernel": "0.1.222",
     "json-rest-schema": "^1.0.17"
   },
   "exports": {

package/patterns/minimal-foundation/example/package.json

@@ -34,7 +34,7 @@
   "dependencies": {
     "@local/main": "0.1.0",
     "@fastify/static": "^10.1.3",
-    "@jskit-ai/kernel": "0.1.221",
+    "@jskit-ai/kernel": "0.1.222",
     "@tanstack/vue-query": "^5.101.0",
     "fastify": "^5.8.5",
     "json-rest-schema": "^1.0.17",
@@ -42,13 +42,13 @@
     "vue": "^3.5.43",
     "vue-router": "^5.3.1",
     "vuetify": "^4.1.2",
-    "@jskit-ai/http-runtime": "0.1.219",
+    "@jskit-ai/http-runtime": "0.1.220",
     "@fastify/fast-json-stringify-compiler": "^5.1.0",
     "@vue/devtools-api": "^8.2.1"
   },
   "devDependencies": {
-    "@jskit-ai/config-eslint": "0.1.218",
-    "@jskit-ai/jskit-catalog": "0.1.246",
+    "@jskit-ai/config-eslint": "0.1.219",
+    "@jskit-ai/jskit-catalog": "0.1.247",
     "@playwright/test": "1.61.1",
     "@vitejs/plugin-vue": "^6.0.7",
     "eslint": "^10.8.0",

package/patterns/shell-foundation/example/package.json

@@ -34,7 +34,7 @@
   "dependencies": {
     "@local/main": "0.1.0",
     "@fastify/static": "^10.1.3",
-    "@jskit-ai/kernel": "0.1.221",
+    "@jskit-ai/kernel": "0.1.222",
     "@tanstack/vue-query": "^5.101.0",
     "fastify": "^5.8.5",
     "json-rest-schema": "^1.0.17",
@@ -42,15 +42,15 @@
     "vue": "^3.5.43",
     "vue-router": "^5.3.1",
     "vuetify": "^4.1.2",
-    "@jskit-ai/http-runtime": "0.1.219",
+    "@jskit-ai/http-runtime": "0.1.220",
     "@mdi/js": "^7.4.47",
-    "@jskit-ai/shell-web": "0.1.225",
+    "@jskit-ai/shell-web": "0.1.226",
     "@fastify/fast-json-stringify-compiler": "^5.1.0",
     "@vue/devtools-api": "^8.2.1"
   },
   "devDependencies": {
-    "@jskit-ai/config-eslint": "0.1.218",
-    "@jskit-ai/jskit-catalog": "0.1.246",
+    "@jskit-ai/config-eslint": "0.1.219",
+    "@jskit-ai/jskit-catalog": "0.1.247",
     "@playwright/test": "1.61.1",
     "@vitejs/plugin-vue": "^6.0.7",
     "eslint": "^10.8.0",

package/patterns/shell-foundation/example/packages/main/package.json

@@ -9,7 +9,7 @@
   },
   "description": "App-local runtime composition and lightweight glue.",
   "dependencies": {
-    "@jskit-ai/kernel": "0.1.221"
+    "@jskit-ai/kernel": "0.1.222"
   },
   "jskit": {
     "kind": "runtime",