@jskit-ai/agent-docs 0.1.19 → 0.1.21

package/guide/agent/generators/crud-generators.md

@@ -16,8 +16,8 @@ So the real order is always:
 This chapter uses three examples, in increasing complexity:
 
 - `contacts`: the baseline full CRUD walkthrough
-- `addresses`: a child CRUD with its own routed list page
-- `comments`: a child CRUD that lives inside the parent page, with only the child routes being routed
+- `addresses`: a child CRUD with its own routed list page reached from the parent record view
+- `comments`: a child CRUD that lives under the parent record host as a child page
 
 The examples assume the guide app already has the database and workspace/admin setup from the earlier chapters. That is why the route roots below live under `w/[workspaceSlug]/admin/...`.
 
@@ -350,7 +350,7 @@ That is the shape to learn first.
 
 Now move to a child CRUD with its own URL.
 
-This is the right pattern when the child collection deserves its own list page.
+This is the right pattern when the child collection deserves its own list page, but should still be reached from a specific parent record.
 
 Example route:
 
@@ -358,12 +358,23 @@ Example route:
 .../contacts/3/addresses
 ```
 
-In the guide app's real route tree, that becomes:
+In the guide app's real route tree, the visible URL becomes:
 
 ```text
 w/[workspaceSlug]/admin/contacts/[contactId]/addresses
 ```
 
+This example is intentionally **not** an in-page child list and **not** a contact subtab.
+
+The intended UX is:
+
+- `addresses` gets its own routed list page
+- the page lives under a specific contact
+- the user reaches it from an explicit link or button on the contact view
+- it does **not** appear in the global left menu
+
+That makes it different from the later `comments` example, where the child list stays inside the parent page.
+
 ### Step 1: create the child table
 
 Example:
@@ -382,12 +393,16 @@ CREATE TABLE addresses (
   created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
   updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
   KEY idx_addresses_workspace_id (workspace_id),
-  KEY idx_addresses_contact_id (contact_id)
+  KEY idx_addresses_contact_id (contact_id),
+  CONSTRAINT fk_addresses_contact_id
+    FOREIGN KEY (contact_id) REFERENCES contacts(id)
 );
 ```
 
 The important extra column here is `contact_id`. This is what makes the CRUD a child of a contact instead of a top-level resource.
 
+The foreign key is not optional in this example. It is what lets `crud-server-generator` emit `contactId` as a real lookup relation in `packages/addresses/src/shared/addressResource.js`.
+
 ### Step 2: scaffold the server package
 
 ```bash
@@ -398,17 +413,104 @@ npx jskit generate crud-server-generator scaffold \
   --table-name addresses
 ```
 
-### Step 3: scaffold the UI at the child route root
+Then install the generated local package:
+
+```bash
+npm install
+```
+
+If you are developing against a local JSKIT checkout, relink your app to the local packages before you run the UI:
+
+```bash
+npm run devlinks
+```
+
+### Step 3: refine the generated lookup metadata by hand
+
+Open `packages/addresses/src/shared/addressResource.js` and add `labelKey: "fullName"` to the generated `contactId` relation:
+
+```js
+contactId: {
+  type: "id",
+  required: true,
+  search: true,
+  relation: {
+    kind: "lookup",
+    namespace: "contacts",
+    valueKey: "id",
+    labelKey: "fullName"
+  },
+  belongsTo: "contacts",
+  as: "contact",
+  ui: { formControl: "autocomplete" },
+  ...
+}
+```
+
+This part is still manual today.
+
+The scaffold can infer the lookup **relationship** from the foreign key, but it cannot infer which contact field should be used as the human-readable label. Without `labelKey: "fullName"`, the page falls back to generic headings like `Addresses for Contact #1`.
+
+### Step 4: scaffold the UI route tree
 
 ```bash
 npx jskit generate crud-ui-generator crud \
   w/[workspaceSlug]/admin/contacts/[contactId]/addresses \
   --resource-file packages/addresses/src/shared/addressResource.js \
   --id-param addressId \
+  --parent-title contextual \
   --display-fields label,line1,postcode
 ```
 
-That gives you a proper child CRUD with its own list, view, new, and edit pages under the contact route.
+That gives you a normal child route tree:
+
+- `w/[workspaceSlug]/admin/contacts/[contactId]/addresses/index.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/addresses/new.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/addresses/[addressId]/index.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/addresses/[addressId]/edit.vue`
+- shared `_components` files under the same route root
+
+### Step 5: remove the generated shell placement by hand
+
+`crud-ui-generator` currently generates a list-page placement block in `src/placement.js`.
+
+For this example, that block is **not** what you want.
+
+Delete the generated `addresses` placement block from `src/placement.js`.
+
+It will be the block added for the `w/[workspaceSlug]/admin/contacts/[contactId]/addresses` page link.
+
+Depending on what outlets already exist in the app, that block may try to place `Addresses` in the shell menu or in the contact subpages outlet. For this example, remove it either way and keep navigation manual from the contact view.
+
+This is an intentional manual cleanup for now:
+
+- keep the routed pages
+- remove the auto menu link
+- navigate to the page from the contact view instead
+
+### Step 6: add a manual link from the contact view
+
+Open `src/pages/w/[workspaceSlug]/admin/contacts/[contactId]/index.vue` and add a button that links to `./addresses`.
+
+The simplest version is:
+
+```vue
+<v-btn
+  color="primary"
+  variant="tonal"
+  :to="{ path: view.resolveParams(UI_ADDRESSES_URL), query: $route.query }"
+>
+  Addresses
+</v-btn>
+```
+
+Then define the URL template in the script:
+
+```js
+const UI_ADDRESSES_URL = "./addresses";
+```
+
+That gives you a standalone child page with a clear entry point from the parent contact view, without mixing record-scoped pages into the global shell menu.
 
 ### The important refinement: parent title handling
 
@@ -416,8 +518,8 @@ This is where nested CRUD starts to feel real.
 
 An addresses list page should not show a generic heading like `Addresses`. It should usually show whose addresses these are, for example:
 
-- `Jane Smith's addresses`
-- `Acme Pty Ltd's addresses`
+- `Addresses for Jane Smith`
+- `Addresses for Acme Pty Ltd`
 
 The awkward case is when there are **no child rows yet**. If the list is empty, you cannot derive the parent title from the first address record.
 
@@ -433,37 +535,36 @@ const parentTitle = useCrudListParentTitle({
 });
 ```
 
-That helper does the nice thing automatically:
+That helper does the right thing automatically:
 
-- if the child list already has rows, it derives the parent title from the first child record
+- if the child list already has rows, it derives the parent title from the first child record when lookup data is available
 - if the child list is empty, it loads the parent record directly
 
-This is exactly the pattern used in the real app codebase for nested CRUD lists like a contact's pets. It avoids the common broken state where an empty child list loses all context about the parent it belongs to.
-
-So the `addresses` example is important because it teaches the first truly practical nested-CRUD problem:
+So the `addresses` example is important because it teaches the first truly practical child-page problem:
 
 - the route is child-scoped
 - the data is child-scoped
-- but the page still needs a reliable parent identity even when the child list is empty
+- the page is reached from a parent action, not from the main shell menu
+- the page still needs a reliable parent identity even when the child list is empty
 
-## Example 3: `comments` in-page
+## Example 3: `comments` under the contact host
 
 This is the advanced example.
 
-Sometimes a child resource is real enough to deserve its own CRUD operations, but **not** important enough to deserve its own full-screen list page.
+Sometimes a child resource should stay attached to the parent record, but still deserves its own routed child page.
 
 Comments are a good example:
 
 - they matter
 - they need persistence
-- they may need `view`, `new`, or `edit` routes
-- but the main screen is still the contact view page
+- they benefit from their own list, `new`, `view`, and `edit` routes
+- but they still belong inside the contact experience rather than as a top-level destination
 
 So the pattern is:
 
 - keep the contact page as the real host
-- render the comments list inside that page
-- route only the child operations underneath it
+- keep the child route tree under that host
+- let the generated placement surface the comments page as a contact child page
 
 ### Step 1: create the table
 
@@ -474,12 +575,13 @@ CREATE TABLE comments (
   id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
   workspace_id BIGINT UNSIGNED NOT NULL,
   contact_id BIGINT UNSIGNED NOT NULL,
-  author_user_id BIGINT UNSIGNED NULL,
   body TEXT NOT NULL,
   created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
   updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
   KEY idx_comments_workspace_id (workspace_id),
-  KEY idx_comments_contact_id (contact_id)
+  KEY idx_comments_contact_id (contact_id),
+  CONSTRAINT fk_comments_contact_id
+    FOREIGN KEY (contact_id) REFERENCES contacts(id)
 );
 ```
 
@@ -493,7 +595,45 @@ npx jskit generate crud-server-generator scaffold \
   --table-name comments
 ```
 
-### Step 3: make the parent page able to host routed children
+Then install the generated local package:
+
+```bash
+npm install
+```
+
+If you are developing against a local JSKIT checkout, relink the app before you run the UI:
+
+```bash
+npm run devlinks
+```
+
+### Step 3: refine the generated lookup metadata by hand
+
+Open `packages/comments/src/shared/commentResource.js` and add `labelKey: "fullName"` to the generated `contactId` relation:
+
+```js
+contactId: {
+  type: "id",
+  required: true,
+  search: true,
+  relation: {
+    kind: "lookup",
+    namespace: "contacts",
+    valueKey: "id",
+    labelKey: "fullName"
+  },
+  belongsTo: "contacts",
+  as: "contact",
+  ui: { formControl: "autocomplete" },
+  ...
+}
+```
+
+This is the same manual refinement used in the `addresses` example: the scaffold can infer the lookup relationship from the foreign key, but it cannot infer which parent field should be used as the display label.
+
+The next command also makes the parent-title mode explicit on purpose. That way changing the heading behavior later is just changing the value and rerunning with `--force`, not adding a new flag.
+
+### Step 4: make the parent page able to host routed children
 
 If the contact view page should stay visible while child comment routes render underneath it, first upgrade it into a routed host:
 
@@ -509,63 +649,71 @@ That is the point where the comments example deliberately overlaps with the `ui-
 - CRUD scaffolding for the comments resource
 - a routed host in the parent contact page
 
-### Step 4: generate only the routed child operations
+### Step 4.5: make `comments` the default child page
 
-Now generate the comments UI without a list page:
+This is a very common next step.
 
-```bash
-npx jskit generate crud-ui-generator crud \
-  w/[workspaceSlug]/admin/contacts/[contactId]/index/comments \
-  --resource-file packages/comments/src/shared/commentResource.js \
-  --operations view,new,edit \
-  --id-param commentId
+If the contact page should open directly on `Comments`, add an explicit redirect to the contact host page:
+
+```vue
+<script setup>
+import { redirectToChild } from "@jskit-ai/kernel/client/pageRedirects";
+
+definePage({
+  redirect: redirectToChild("comments")
+});
+</script>
 ```
 
-This is the key move.
+In this example, that edit belongs in:
 
-By leaving `list` out:
+```text
+src/pages/w/[workspaceSlug]/admin/contacts/[contactId]/index.vue
+```
 
-- you do **not** generate a standalone comments list page
-- the host contact page stays responsible for showing the comment list
-- the generated child routes still handle things like `new`, `view`, and `edit`
+This is the recommended pattern. Do **not** try to infer the default child page from placement order or "the first tab". Keep it explicit.
 
-### What the host page does
+When this redirect is present:
 
-The host page then renders the comment list directly, usually with lower-level CRUD composables such as:
+- opening `/w/<workspaceSlug>/admin/contacts/<contactId>` lands on `/w/<workspaceSlug>/admin/contacts/<contactId>/comments`
+- the parent contact page still stays visible
+- the child page renders underneath it
 
-- `useCrudList()`
-- `useCrudAddEdit()`
-- `useCrudView()` when needed
+That last point matters. The contact page is still the host page. The redirect only changes which child route becomes the default landing destination.
 
-There is one more runtime worth knowing about early:
+### Step 5: generate the full child CRUD page
 
-- `useCommand()`
+Now generate the comments UI under the contact host:
 
-Use it for live actions that are **not** full forms, such as:
+```bash
+npx jskit generate crud-ui-generator crud \
+  w/[workspaceSlug]/admin/contacts/[contactId]/index/comments \
+  --resource-file packages/comments/src/shared/commentResource.js \
+  --id-param commentId \
+  --parent-title none \
+  --display-fields body
+```
 
-- checkbox toggles
-- archive / reopen buttons
-- quick PATCH / POST / DELETE actions on one record
+Do **not** pass `--operations view,new,edit` here. That would omit the list page and leave you with only child operation routes.
 
-So the practical split is:
+`--parent-title none` is the important difference from `addresses`.
 
-- `useCrudList()` / `useCrudView()`
-  - routed list/view loading
-- `useCrudAddEdit()`
-  - real create/edit forms
-- `useCommand()`
-  - live actions inside the page
+The contact host page already shows the parent identity, so a generated heading like `Comments for Tony Mobily` is redundant. If you later decide you do want that heading, rerun the same command with `--parent-title contextual --force`.
 
-The `todo` app uses that last pattern for "mark item done" checkboxes. The deeper best-practices explanation is in [Advanced CRUDs](/guide/generators/advanced-cruds).
+This command gives you:
 
-That is the same general pattern already used in the real app for embedded child records like pet notes: the record list lives inside the main view page, while routed child pages handle the operations that still deserve their own URLs.
+- `w/[workspaceSlug]/admin/contacts/[contactId]/index/comments/index.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/index/comments/new.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/index/comments/[commentId]/index.vue`
+- `w/[workspaceSlug]/admin/contacts/[contactId]/index/comments/[commentId]/edit.vue`
 
-This pattern is useful when the child records are supporting detail rather than a destination in their own right.
+Because this route root lives under `.../[contactId]/index/comments`, the generated placement is the desired one here: `Comments` appears as a child page under the contact host.
 
 That is the real lesson of the `comments` example:
 
-- a child CRUD does **not** have to mean "make another full-screen list page"
-- you can keep the parent page as the main experience and route only the child operations that benefit from their own URLs
+- the contact page stays the routed host
+- the child CRUD gets its own list page
+- the route still stays under the parent record experience
 
 ## When `scaffold-field` matters
 
@@ -597,8 +745,8 @@ It patches the canonical `schema` inside the shared resource file. That matters
 The important thing is not memorizing commands. It is learning the three shapes:
 
 - `contacts`: a normal top-level CRUD
-- `addresses`: a child CRUD with its own routed list page
-- `comments`: a child CRUD that lives inside the parent page, with only the child operations routed
+- `addresses`: a child CRUD with its own routed list page reached from the parent record view
+- `comments`: a child CRUD that lives under the parent record host as a child page
 
 Once you understand those three shapes, the two generator packages stop feeling like separate tools.
 

package/guide/agent/generators/ui-generators.md

@@ -257,6 +257,37 @@ The route page is still a normal page file. What changes is the inferred placeme
 
 So JSKIT is not switching to a different generator. It is switching the inferred placement behavior because the route tree now has a routed host above the new page.
 
+### Making a child page the default landing route
+
+This is important enough to state explicitly: if a routed host has child pages, and you want the bare parent URL to open one child immediately, use an explicit redirect.
+
+Do **not** try to make the app "guess the first tab". Do **not** infer it from placement order. Keep the target explicit.
+
+The standard pattern is:
+
+```vue
+<script setup>
+import { redirectToChild } from "@jskit-ai/kernel/client/pageRedirects";
+
+definePage({
+  redirect: redirectToChild("exports")
+});
+</script>
+```
+
+If this is placed on the host page, opening `/reports` lands on `/reports/exports`.
+
+This is also the right pattern when the host page still renders shared content such as a title, tabs, summary panel, or `RouterView`. The parent route remains the host, and the child page simply becomes the default destination under it.
+
+Why this is the recommended pattern:
+
+- the destination is explicit and stable
+- it survives later placement reordering
+- it does not depend on which child link happens to render first
+- it is easy to change later by editing one child segment
+
+This is one of the most common things people want once they start using child-page hosts. Treat it as normal JSKIT routing, not a special hack.
+
 ## Nested pages under an `index.vue` host
 
 Once `Reports` is a host, create a child page under it:

package/guide/agent/index.md

@@ -4,12 +4,13 @@
 
 This guide is the main hands-on path through JSKIT.
 
-It starts with the smallest scaffold, then explains how to work with the JSKIT CLI itself before adding the shell and authentication. 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 realtime and assistant. Finally, the guide breaks out generator-specific workflows into their own section.
+It now starts with a fast reproducible Quickstart, then steps back to the smaller scaffold-first chapters that explain how the app is assembled piece by piece. 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 realtime and assistant. Finally, the guide breaks out generator-specific workflows into their own section.
 
 ## Table of Contents
 
 ### App Setup
 
+- [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)
@@ -33,7 +34,8 @@ It starts with the smallest scaffold, then explains how to work with the JSKIT C
 
 ## How to use this guide
 
-- Start with `App Setup` if you are building up a JSKIT app from scratch.
+- 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.
 - 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.

package/package.json

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

package/patterns/page-redirects.md

@@ -6,16 +6,18 @@ Use when:
 - writing `definePage({ redirect: ... })`
 - seeding settings landing pages such as `/home/settings`
 - wiring a section shell that should land on a real child page first
+- making a routed host page open a default child tab such as `comments`
 
 Check first:
 
-- whether the page is only a landing route for child pages
+- whether the page is only a landing route for child pages or a host page that should always land on one child first
 - whether the destination child route is explicit and stable
 - whether the redirect should preserve incoming query and hash
 
 Rules:
 
 - For “index page lands on child page” redirects, use `redirectToChild()` from `@jskit-ai/kernel/client/pageRedirects`.
+- The same helper is also the explicit pattern for “this host page should open child X by default”.
 - Do not hand-build child redirects with string surgery such as `` `${String(to.path || "").replace(/\\/$/, "")}/general` ``.
 - Keep the destination explicit. Do not infer it from placements, menu order, or “first child page wins” behavior.
 - If the redirect is just “go to this child page”, prefer:
@@ -28,6 +30,8 @@ definePage({
 });
 ```
 
+- This can live on a host page that still renders its own shell and `RouterView`. The parent route remains matched and the child route renders underneath it.
+
 Why:
 
 - the helper centralizes slash handling

package/patterns/ui-testing.md

@@ -12,6 +12,8 @@ Rules:
 - Any chunk that adds or changes user-facing UI must include a Playwright flow that exercises the changed behavior before the chunk is done.
 - Record that Playwright run with `jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>`.
 - `jskit doctor` expects `.jskit/verification/ui.json` to match the current dirty UI file set when UI files are changed.
+- For local pre-merge review, follow the recorded Playwright run with `jskit doctor --against <base-ref>` so `doctor` compares against the branch delta instead of only the local dirty worktree.
+- Advanced CI setups may also use `--against <base-ref>`, but JSKIT does not scaffold hosted browser/auth/database verification by default.
 - Do not rely on a live external auth provider for Playwright verification of normal app features.
 - For authenticated UI in the standard JSKIT auth stack, use the development-only dev auth bypass route instead.
 - The standard route is `POST /api/dev-auth/login-as`.
@@ -31,6 +33,12 @@ npx jskit app verify-ui \
   --auth-mode dev-auth-login-as
 ```
 
+Local pre-merge follow-up:
+
+```bash
+npx jskit doctor --against origin/main
+```
+
 The Playwright command itself should follow this setup shape when login is needed:
 
 ```ts

package/reference/autogen/README.md

@@ -22,6 +22,7 @@ Startup navigation stays in `KERNEL_MAP.md`.
 - [database-runtime](/packages/agent-docs/reference/autogen/packages/database-runtime.md)
 - [database-runtime-mysql](/packages/agent-docs/reference/autogen/packages/database-runtime-mysql.md)
 - [database-runtime-postgres](/packages/agent-docs/reference/autogen/packages/database-runtime-postgres.md)
+- [feature-server-generator](/packages/agent-docs/reference/autogen/packages/feature-server-generator.md)
 - [http-runtime](/packages/agent-docs/reference/autogen/packages/http-runtime.md)
 - [json-rest-api-core](/packages/agent-docs/reference/autogen/packages/json-rest-api-core.md)
 - [kernel](/packages/agent-docs/reference/autogen/packages/kernel.md)

package/reference/autogen/packages/assistant-core.md

@@ -216,6 +216,7 @@ Exports
 - `MAX_INPUT_CHARS`
 - `MAX_HISTORY_MESSAGES`
 - `assistantResource`
+- `assistantConversationOutputValidator`
 
 ### `src/shared/assistantSettingsResource.js`
 Exports
@@ -245,14 +246,26 @@ Exports
 - `MAX_INPUT_CHARS`
 - `MAX_HISTORY_MESSAGES`
 - `assistantResource`
+- `assistantConversationOutputValidator`
 - `MAX_SYSTEM_PROMPT_CHARS`
 - `assistantConfigResource`
+- `ASSISTANT_SETTINGS_TRANSPORT`
+- `ASSISTANT_SETTINGS_UPDATE_TRANSPORT`
+- `ASSISTANT_CONVERSATIONS_TRANSPORT`
+- `ASSISTANT_CONVERSATION_MESSAGES_TRANSPORT`
 - `assistantSettingsEvents`
 - `ASSISTANT_CONVERSATION_STATUSES`
 - `normalizeConversationStatus`
 - `parseJsonObject`
 - `toPositiveInteger`
 
+### `src/shared/jsonApiTransports.js`
+Exports
+- `ASSISTANT_SETTINGS_TRANSPORT`
+- `ASSISTANT_SETTINGS_UPDATE_TRANSPORT`
+- `ASSISTANT_CONVERSATIONS_TRANSPORT`
+- `ASSISTANT_CONVERSATION_MESSAGES_TRANSPORT`
+
 ### `src/shared/queryKeys.js`
 Exports
 - `ASSISTANT_QUERY_KEY_PREFIX`

package/reference/autogen/packages/assistant-runtime.md

@@ -100,6 +100,8 @@ Local functions
 - `sendPreStreamErrorResponse(reply, error)`
 - `resolveRouteRequestState(request, { resolveCurrentAppConfig = () => ({}), kind = "runtime", requiresWorkspace = false, workspaceScopeSupport = null } = {})`
 - `buildChatStreamActionInput(routeInput = {}, requestBody = {})`
+- `resolveAssistantSettingsRecordId(record = {})`
+- `resolveAssistantConversationMessagesRecordId(record = {})`
 - `registerSettingsRoutes(router, resolveCurrentAppConfig, { requiresWorkspace = false, workspaceScopeSupport = null } = {})`
 - `registerRuntimeRoutes(router, resolveCurrentAppConfig, { requiresWorkspace = false, workspaceScopeSupport = null } = {})`
 

package/reference/autogen/packages/auth-provider-supabase-core.md

@@ -190,6 +190,12 @@ Local functions
 - `cloneProfile(profile)`
 - `createEmailConflictError()`
 
+### `src/server/lib/supabaseClientOptions.js`
+Exports
+- `buildSupabaseServerClientOptions(options = {})`
+Local functions
+- `resolveRealtimeTransport({ nativeWebSocket = globalThis.WebSocket, fallbackTransport = WebSocket } = {})`
+
 ### `src/server/lib/test-utils.js`
 Exports
 - `createAccountFlows`

package/reference/autogen/packages/console-core.md

@@ -31,6 +31,8 @@ Exports
 ### `src/server/consoleSettings/bootConsoleSettingsRoutes.js`
 Exports
 - `bootConsoleSettingsRoutes(app)`
+Local functions
+- `resolveConsoleSettingsRecordId()`
 
 ### `src/server/consoleSettings/consoleService.js`
 Exports

package/reference/autogen/packages/crud-core.md

@@ -304,6 +304,10 @@ Local functions
 - `createRecordRelationshipsResolver(definition = null)`
 - `createRequestRelationshipMapper(definition = null)`
 - `resolveOutputAttributeExcludeKeys(resource = {})`
+- `resolveLookupContainerKey(resource = {})`
+- `normalizeLookupId(value)`
+- `normalizeIncludedLookupRecord(source = null, fallbackId = null)`
+- `createLookupIncludedResolver(definition = null, { lookupContainerKey = "" } = {})`
 
 ### `src/server/serviceEvents.js`
 Exports

package/reference/autogen/packages/crud-ui-generator.md

@@ -30,6 +30,7 @@ Local functions
 - `resolveListTargetFile(targetRoot = "")`
 - `parseOperationsOption(options)`
 - `parseDisplayFieldsOption(options)`
+- `parseParentTitleOption(options)`
 - `validateDisplayFieldsForOperation(selectedFieldKeys, fields, operationName)`
 - `filterDisplayFields(selectedFieldKeys, fields)`
 - `rewriteGeneratedBlockIndent(source = "", { trimPrefix = "", addPrefix = "" } = {})`
@@ -46,6 +47,8 @@ Local functions
 - `resolveTargetRootRelativeRoutePath(pageTarget = {})`
 - `resolveMenuToPropLine(linkTo = "")`
 - `resolveCrudRelativePath(namespace = "")`
+- `buildListParentTitleImportLine(parentTitleMode = "contextual")`
+- `buildListHeadingTitleSetup({ parentTitleMode = "contextual", resourceNamespace = "", routeTitle = "Records" } = {})`
 
 ### `src/server/resourceSupport.js`
 Exports