@elevasis/sdk 1.20.2 → 1.22.0

package/reference/scaffold/recipes/gate-by-feature-or-admin.md

@@ -1,117 +1,121 @@
----
-title: Gate by Feature or Admin
-description: Decision table and recipes for gating routes, sidebar entries, and UI elements by Organization Model feature ID or admin role.
----
+---
+title: Gate by System or Admin
+description: Decision table and recipes for gating routes, sidebar entries, and UI elements by Organization Model system ID or admin role.
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-# Gate by Feature or Admin
-
-Feature visibility starts in `core/config/organization-model.ts`. Routes still enforce access with guards.
-
-## Decide the gate
-
-| Scenario | Gate to use |
-| --- | --- |
-| Surface can be enabled or disabled per organization/member | `FeatureGuard` with the feature ID |
-| Surface is always available to members but restricted to admins | `AdminGuard` plus `requiresAdmin: true` on the feature node |
-| Surface is both feature-gated and admin-only | Both guards, plus `requiresAdmin: true` on the feature node |
-
-## Feature gate in the org model
-
-Add or update the feature in `features`.
-
-```ts
-features: [
-  {
-    id: 'analytics',
-    label: 'Analytics',
-    enabled: false,
-    path: '/analytics',
-    icon: 'custom.analytics',
-    uiPosition: 'sidebar-primary'
-  }
-]
-```
-
-Set `enabled: true` to enable it for all members by default. Dotted IDs such as `analytics.reports` inherit feature state and shell placement from their ancestors unless they declare their own value.
-
-## Route-level feature gate
-
-```tsx
-import { ProtectedRoute } from '@/features/auth'
-import { FeatureGuard } from '@/features/auth/guards/FeatureGuard'
-import { createFileRoute, Outlet } from '@tanstack/react-router'
-
-export const Route = createFileRoute('/analytics')({ component: AnalyticsLayout })
-
-function AnalyticsLayout() {
-  return (
-    <ProtectedRoute>
-      <FeatureGuard featureKey="analytics">
-        <Outlet />
-      </FeatureGuard>
-    </ProtectedRoute>
-  )
-}
-```
-
-The sidebar is derived from `OrganizationModel.features`; hiding a node there is display behavior only. Keep route guards in place for direct URL access.
-
-## Admin-only route
-
-```tsx
-import { ProtectedRoute } from '@/features/auth'
-import { AdminGuard } from '@elevasis/ui/auth'
-import { createFileRoute, Outlet } from '@tanstack/react-router'
-
-export const Route = createFileRoute('/admin')({ component: AdminLayout })
-
-function AdminLayout() {
-  return (
-    <ProtectedRoute>
-      <AdminGuard>
-        <Outlet />
-      </AdminGuard>
-    </ProtectedRoute>
-  )
-}
-```
-
-Pair the route guard with the feature node:
-
-```ts
-{
-  id: 'admin',
-  label: 'Admin',
-  enabled: true,
-  path: '/admin',
-  uiPosition: 'sidebar-bottom',
-  requiresAdmin: true
-}
-```
-
-## Per-member override
-
-`MembershipFeatureConfig.features` in `org_memberships.config` overrides enabled state per member.
-
-```ts
-{
-  features: { analytics: false }
-}
-```
-
-Settings and admin-only pages should use admin checks, not per-member feature flags.
-
-## Verify
-
-Check the state matrix:
-
-| Org feature enabled | Member override | Admin | Expected result |
-| --- | --- | --- | --- |
-| true | absent | any | Route accessible, sidebar visible |
-| true | false | any | Route redirects, sidebar hidden |
-| false | absent | any | Route redirects, sidebar hidden |
-| true | absent | non-admin | Admin route redirects, admin sidebar hidden |
-| true | absent | admin | Admin route accessible, admin sidebar visible |
+
+# Gate by System or Admin
+
+System visibility starts in `core/config/organization-model.ts`. Routes still enforce access with guards.
+
+## Decide the gate
+
+| Scenario | Gate to use |
+| --- | --- |
+| Surface can be enabled or disabled per organization/member | `SystemGuard` with the system ID |
+| Surface is always available to members but restricted to admins | `AdminGuard` plus `requiresAdmin: true` on the system node |
+| Surface is both system-gated and admin-only | Both guards, plus `requiresAdmin: true` on the system node |
+
+## System gate in the org model
+
+Add or update the system in the id-keyed `systems` map.
+
+```ts
+systems: {
+  analytics: {
+    id: 'analytics',
+    order: 10,
+    label: 'Analytics',
+    enabled: false,
+    path: '/analytics',
+    icon: 'custom.analytics',
+    uiPosition: 'sidebar-primary'
+  }
+}
+```
+
+Set `enabled: true` to enable it for all members by default. Dotted IDs such as `analytics.reports` inherit system state and shell placement from their ancestors unless they declare their own value.
+
+## Route-level system gate
+
+```tsx
+import { ProtectedRoute } from '@/features/auth'
+import { SystemGuard } from '@elevasis/ui/features/auth'
+import { createFileRoute, Outlet } from '@tanstack/react-router'
+
+export const Route = createFileRoute('/analytics')({ component: AnalyticsLayout })
+
+function AnalyticsLayout() {
+  return (
+    <ProtectedRoute>
+      <SystemGuard systemKey="analytics">
+        <Outlet />
+      </SystemGuard>
+    </ProtectedRoute>
+  )
+}
+```
+
+The sidebar is derived from `OrganizationModel.systems`; hiding a node there is display behavior only. Keep route guards in place for direct URL access.
+
+## Admin-only route
+
+```tsx
+import { ProtectedRoute } from '@/features/auth'
+import { AdminGuard } from '@elevasis/ui/auth'
+import { createFileRoute, Outlet } from '@tanstack/react-router'
+
+export const Route = createFileRoute('/admin')({ component: AdminLayout })
+
+function AdminLayout() {
+  return (
+    <ProtectedRoute>
+      <AdminGuard>
+        <Outlet />
+      </AdminGuard>
+    </ProtectedRoute>
+  )
+}
+```
+
+Pair the route guard with the system node:
+
+```ts
+systems: {
+  admin: {
+    id: 'admin',
+    order: 10,
+    label: 'Admin',
+    enabled: true,
+    path: '/admin',
+    uiPosition: 'sidebar-bottom',
+    requiresAdmin: true
+  }
+}
+```
+
+## Per-member override
+
+Membership config overrides enabled state per member.
+
+```ts
+{
+  systems: { analytics: false }
+}
+```
+
+Settings and admin-only pages should use admin checks, not per-member system flags.
+
+## Verify
+
+Check the state matrix:
+
+| Org system enabled | Member override | Admin | Expected result |
+| --- | --- | --- | --- |
+| true | absent | any | Route accessible, sidebar visible |
+| true | false | any | Route redirects, sidebar hidden |
+| false | absent | any | Route redirects, sidebar hidden |
+| true | absent | non-admin | Admin route redirects, admin sidebar hidden |
+| true | absent | admin | Admin route accessible, admin sidebar visible |

package/reference/scaffold/recipes/index.md

@@ -1,50 +1,51 @@
----
-title: Pathway Recipes
-description: Terse end-to-end walkthroughs for the three most common authoring tasks -- adding a feature, adding a resource, and gating access.
----
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-# Pathway Recipes
-
-Three sequential walkthroughs for common authoring tasks. Each recipe links into the reference docs rather than duplicating them.
-
-Before starting, read [glossary.md](../reference/glossary.md) to disambiguate overloaded terms (Feature, Resource, featureId, Settings asymmetry, Topology).
-
----
-
-## Recipes
-
-**[Add a Feature](add-a-feature.md)**
-You want a new shell feature (e.g., `analytics`) with its own nav entry, sidebar, routes, and org-model gate. Covers adding a feature object to the org model, `FeatureModule` manifest authoring, route creation, and gating.
-
-**[Add a Resource](add-a-resource.md)**
-You want a new workflow or agent deployed to the platform. Covers OM Resource descriptor authoring, descriptor-backed `WorkflowDefinition` binding, `DeploymentSpec` assembly, relationship declarations, and CLI verification.
-
-**[Gate by Feature or Admin](gate-by-feature-or-admin.md)**
-You want to restrict a route, nav item, or UI element by feature flag or admin role. Covers the decision table, `FeatureGuard`, `AdminGuard`, nav-entry visibility fields, per-member `MembershipFeatureConfig` overrides, and the settings-asymmetry gotcha.
-
-**[Build and Extend CRM](extend-crm.md)**
-You want to build on the shared CRM without forking it: add CRM routes, compose sidebars/pages, use deal/company/contact hooks, mutate CRM data from workflows, or understand which contracts and adapters form the extension surface.
-
-**[Build and Extend Lead Gen](extend-lead-gen.md)**
-You want to build on the shared lead-gen system without forking it: add lead-gen routes, compose sidebars/pages, use list/company/contact/artifact hooks, mutate list data from workflows, or understand which contracts and adapters form the extension surface.
-
-**[Customize CRM Actions](customize-crm-actions.md)**
-You want to add, hide, or replace CRM deal action buttons, configure the shared `crmActions` provider path, or call a project-owned workflow from custom UI when server-side action dispatch constraints require it. Covers `ActionDef`, `DEFAULT_CRM_ACTIONS`, provider wiring, and the current v1 boundary for custom action dispatch.
-
-**[Customize Knowledge Browser](customize-knowledge-browser.md)**
-You want to mount, extend, or replace the default Knowledge Browser. Covers the three customization tiers (default manifest mount, sidebar composition via `KnowledgeSidebarMiddle` + `KNOWLEDGE_ITEMS`, and direct query access via `@elevasis/core/knowledge`), the one-line `vite.config.ts` plugin add (`knowledgePlugin()` from `@elevasis/ui/vite-plugin-knowledge`), and the CSS import requirement.
-
+---
+title: Pathway Recipes
+description: Terse end-to-end walkthroughs for the three most common authoring tasks -- adding a system, adding a resource, and gating access.
+---
+
+# Pathway Recipes
+
+Three sequential walkthroughs for common authoring tasks. Each recipe links into the reference docs rather than duplicating them.
+
+Before starting, read [glossary.md](../reference/glossary.md) to disambiguate overloaded terms (System, Resource, systemId, Settings asymmetry, Topology).
+
+---
+
+## Recipes
+
+**[Add an OM-Backed System](add-a-feature.md)**
+You want a new system with cohesive Organization Model semantics, executable resources, and optional UI. Covers Systems, System-owned ontology and config, Resource descriptors with `resource.ontology`, `actionKey`, `codeRefs`, runtime assembly, manifests, routes, guards, tests, and compatibility notes for old `System.content` consumers.
+
+**[Add a Resource](add-a-resource.md)**
+You want a new workflow or agent deployed to the platform. Covers OM Resource descriptor authoring, descriptor-backed `WorkflowDefinition` binding, `DeploymentSpec` assembly, relationship declarations, and CLI verification.
+
+**[Gate by System or Admin](gate-by-feature-or-admin.md)**
+You want to restrict a route, nav item, or UI element by system flag or admin role. Covers the decision table, `SystemGuard`, `AdminGuard`, nav-entry visibility fields, per-member system overrides, and the settings-asymmetry gotcha.
+
+**[Build and Extend CRM](extend-crm.md)**
+You want to build on the shared CRM without forking it: add CRM routes, compose sidebars/pages, use deal/company/contact hooks, mutate CRM data from workflows, or understand which contracts and adapters form the extension surface.
+
+**[Build and Extend Lead Gen](extend-lead-gen.md)**
+You want to build on the shared lead-gen system without forking it: add lead-gen routes, compose sidebars/pages, use list/company/contact/artifact hooks, mutate list data from workflows, or understand which contracts and adapters form the extension surface.
+
+**[Customize CRM Actions](customize-crm-actions.md)**
+You want to add, hide, or replace CRM deal action buttons, configure the shared `crmActions` provider path, or call a project-owned workflow from custom UI when server-side action dispatch constraints require it. Covers `ActionDef`, `DEFAULT_CRM_ACTIONS`, provider wiring, and the current v1 boundary for custom action dispatch.
+
+**[Customize Knowledge Browser](customize-knowledge-browser.md)**
+You want to mount, extend, or replace the default Knowledge Browser. Covers the three customization tiers (default manifest mount, sidebar composition via `KnowledgeSidebarMiddle` + `KNOWLEDGE_ITEMS`, and direct query access via `@elevasis/core/knowledge`), the one-line `vite.config.ts` plugin add (`knowledgePlugin()` from `@elevasis/ui/vite-plugin-knowledge`), and the CSS import requirement.
+
 **[Query the Knowledge Graph](query-the-knowledge-graph.md)**
-You want to browse, inspect, or traverse the OrganizationModel knowledge graph from the command line. Covers the three verbs (`knowledge:ls`, `knowledge:cat`, `knowledge:graph`), all five mount axes (`/by-feature/`, `/by-kind/`, `/by-owner/`, `/graph/.../governs/`, `/graph/.../governed-by/`), dual-CLI invocation patterns (`elevasis-sdk` for external projects, `elevasis` for the monorepo), and the Windows/MSYS PowerShell gotcha.
-
----
-
-## Reference docs these recipes link into
-
-- [glossary.md](../reference/glossary.md) -- term disambiguation for Feature, Resource, featureId, Topology, Settings asymmetry
-- [contracts.md](../reference/contracts.md) -- TypeScript shapes: `FeatureModule`, `FeatureNavEntry`, `OrganizationModel`, `MembershipFeatureConfig`, CRM deal types, lead-gen list/member/artifact types, `CrmToolMap`, `LeadToolMap`, `ListToolMap`, `ActionDef`
-- [feature-flags-and-gating.md](../ui/feature-flags-and-gating.md) -- full three-concept gating model
-- [workflow-recipes.md](../operations/workflow-recipes.md) -- workflow anatomy, adapters, trigger patterns
+You want to browse, inspect, or traverse the OrganizationModel knowledge graph from the command line. Covers the three verbs (`knowledge:ls`, `knowledge:cat`, `knowledge:graph`), all six mount axes (`/by-system/`, `/by-ontology/`, `/by-kind/`, `/by-owner/`, `/graph/.../governs/`, `/graph/.../governed-by/`), dual-CLI invocation patterns (`elevasis-sdk` for external projects, `elevasis` for the monorepo), JSON output shapes, and the Windows/MSYS PowerShell gotcha.
+
+---
+
+## Reference docs these recipes link into
+
+- [glossary.md](../reference/glossary.md) -- term disambiguation for System, Resource, systemId, Topology, Settings asymmetry
+- [contracts.md](../reference/contracts.md) -- TypeScript shapes: `SystemModule`, `OrganizationModel`, CRM deal types, lead-gen list/member/artifact types, `CrmToolMap`, `LeadToolMap`, `ListToolMap`, `ActionDef`
+- [feature-flags-and-gating.md](../ui/feature-flags-and-gating.md) -- full three-concept gating model
+- [workflow-recipes.md](../operations/workflow-recipes.md) -- workflow anatomy, adapters, trigger patterns
+

package/reference/scaffold/recipes/query-the-knowledge-graph.md

@@ -0,0 +1,227 @@
+<!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
+<!-- Regenerate: pnpm scaffold:sync -->
+
+---
+title: Query the Knowledge Graph
+description: Use the `knowledge:*` CLI subcommands on `elevasis-sdk` (external projects) and `elevasis` (monorepo) to browse, inspect, and traverse the OrganizationModel knowledge graph via six mount axes.
+---
+
+# Query the Knowledge Graph
+
+The `knowledge:*` subcommands expose the OrganizationModel as a virtual filesystem. Paths are query strings -- `/by-system/sales/crm/` dispatches to a graph query, not a directory on disk. Three verbs cover all access patterns: `ls` (list), `cat` (read a node body), and `graph` (traverse edges).
+
+Both CLIs share the same query layer (`@repo/core/knowledge/queries`). The only difference is which OrganizationModel they load:
+
+- `elevasis-sdk` -- runs from inside `external/<project>/`, walks up to `.elevasis`, loads the project's `core/config/organization-model.ts`.
+- `elevasis` -- runs from the monorepo root, loads `canonicalOrganizationModel` from `@repo/elevasis-core`.
+
+## Before you start
+
+The `knowledge:*` commands require `elevasis-sdk >= 1.4.0`. Check with:
+
+```bash
+pnpm exec elevasis-sdk --version
+```
+
+If you are running on Windows, **use PowerShell** for all `knowledge:*` commands. MSYS Bash rewrites the leading `/by-system/...` path argument to a Windows filesystem path, mangling the query. PowerShell passes the argument through verbatim.
+
+## Three Verbs
+
+| Verb                   | Behavior                                                                                                                    |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| `knowledge:ls <path>`  | List nodes or edges for the mount. Default: id + summary table. `--json` for the wrapped envelope. `--ids-only` for piping. |
+| `knowledge:cat <id>`   | Print a node's raw MDX `body` to stdout.                                                                                    |
+| `knowledge:graph <id>` | Show outgoing and incoming edges for a node, grouped by edge kind.                                                          |
+
+All three accept `--json` for machine-readable output. `knowledge:ls` additionally accepts `--ids-only` to print one node ID per line.
+
+## Six Mount Axes
+
+The path argument to `knowledge:ls` determines the query. Six axes are available:
+
+| Path prefix                    | Query                         | Returns                                             |
+| ------------------------------ | ----------------------------- | --------------------------------------------------- |
+| `/by-system/<dotted-id>/`     | `bySystem(graph, systemId)` | nodes with incoming `governs` edges to this system |
+| `/by-ontology/<ontology-id>/` | `byOntology(graph, ontologyId)` | nodes with incoming `governs` edges to this ontology record |
+| `/by-kind/<kind>/`             | `byKind(graph, kind)`         | nodes where `node.kind === kind`                    |
+| `/by-owner/<id>/`              | `byOwner(graph, ownerId)`     | nodes where `node.ownerIds.includes(id)`            |
+| `/graph/<nodeId>/governs/`     | `governs(graph, nodeId)`      | outgoing `governs` edges from `nodeId`              |
+| `/graph/<nodeId>/governed-by/` | `governedBy(graph, nodeId)`   | incoming `governs` edges to `nodeId`                |
+
+## Examples
+
+Each example is shown for both CLIs.
+
+### 1. List by system (`/by-system/<dotted-id>/`)
+
+List all knowledge nodes that govern the `sales.crm` system:
+
+```bash
+# External project (from inside external/<project>/)
+pnpm exec elevasis-sdk knowledge:ls /by-system/sales.crm/
+
+# Monorepo (from monorepo root)
+pnpm exec elevasis knowledge:ls /by-system/sales.crm/
+```
+
+Nested system ids use dots, not slashes: `sales.crm`, `sales.lead-gen`, `projects`.
+
+### 2. List by ontology (`/by-ontology/<ontology-id>/`)
+
+List all knowledge nodes that govern the CRM deal ontology record:
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:ls /by-ontology/sales.crm:object/deal
+
+# Monorepo
+pnpm exec elevasis knowledge:ls /by-ontology/sales.crm:object/deal
+```
+
+Ontology IDs use `system.path:kind/local-id` or `global:kind/local-id`. Slash-containing ontology IDs are part of the query path; use PowerShell on Windows so the leading `/by-ontology/...` path is not rewritten by MSYS Bash.
+
+### 3. List by kind (`/by-kind/<kind>/`)
+
+List all nodes of kind `playbook`:
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:ls /by-kind/playbook
+
+# Monorepo
+pnpm exec elevasis knowledge:ls /by-kind/playbook
+```
+
+Common kinds: `playbook`, `strategy`, and `reference`. The available kinds are defined on `OrgKnowledgeNode.kind` in `@elevasis/core/knowledge`.
+
+Machine-readable output for piping:
+
+```bash
+pnpm exec elevasis knowledge:ls /by-kind/playbook --ids-only
+```
+
+### 4. List by owner (`/by-owner/<id>/`)
+
+List all knowledge nodes owned by a specific member or team:
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:ls /by-owner/operations-team
+
+# Monorepo
+pnpm exec elevasis knowledge:ls /by-owner/operations-team
+```
+
+The `<id>` matches against `node.ownerIds`. Owner IDs are declared on each knowledge node in the OrganizationModel.
+
+### 5. Traverse outgoing edges (`/graph/<nodeId>/governs/`)
+
+List what a specific node governs (outgoing `governs` edges):
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governs/
+
+# Monorepo
+pnpm exec elevasis knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governs/
+```
+
+Knowledge node IDs use the `knowledge.<slug>` source id. Graph node IDs may be kind-prefixed,
+such as `knowledge:knowledge.new-vertical-launch-playbook` or `system:sales.crm`, when traversing
+graph edges.
+
+### 6. Traverse incoming edges (`/graph/<nodeId>/governed-by/`)
+
+List what governs a specific node (incoming `governs` edges):
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governed-by/
+
+# Monorepo
+pnpm exec elevasis knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governed-by/
+```
+
+## Read a Node Body
+
+`knowledge:cat` prints the raw MDX `body` string for a node. The body is not rendered -- it is the source MDX as stored in the OrganizationModel.
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:cat knowledge.new-vertical-launch-playbook
+
+# Monorepo
+pnpm exec elevasis knowledge:cat knowledge.new-vertical-launch-playbook
+```
+
+Pipe to a pager for long bodies:
+
+```bash
+pnpm exec elevasis knowledge:cat knowledge.platform-composition-patterns | less
+```
+
+## Inspect a Node's Edges
+
+`knowledge:graph` shows all edges for a node grouped by kind:
+
+```bash
+# External project
+pnpm exec elevasis-sdk knowledge:graph knowledge.new-vertical-launch-playbook
+
+# Monorepo
+pnpm exec elevasis knowledge:graph knowledge.new-vertical-launch-playbook
+```
+
+This combines the `governs` and `governed-by` views in one output, useful for understanding a node's full graph position.
+
+## JSON Output
+
+All three verbs accept `--json`. `knowledge:ls --json` uses the wrapped envelope format:
+
+```json
+{
+  "path": "/by-system/sales.crm",
+  "mount": "by-system",
+  "args": ["sales.crm"],
+  "results": [...]
+}
+```
+
+This is the format consumed by the `/knowledge` agent skill. Use it when scripting or building tooling that reads knowledge graph data programmatically.
+
+`knowledge:cat --json` returns the full knowledge node object, including the MDX `body`, links, owners, timestamps, and generated `sourceFilePath` when present.
+
+`knowledge:graph --json` returns the same shape in both CLIs:
+
+```json
+{
+  "nodeId": "knowledge.new-vertical-launch-playbook",
+  "outgoing": [],
+  "incoming": []
+}
+```
+
+```bash
+pnpm exec elevasis knowledge:ls /by-kind/playbook --json | jq '.results[].id'
+```
+
+## Windows Note
+
+On Windows, MSYS Bash rewrites path arguments starting with `/` to Windows filesystem paths before the CLI sees them. Use PowerShell:
+
+```powershell
+# Correct on Windows -- PowerShell leaves the path arg intact
+pnpm exec elevasis knowledge:ls /by-kind/playbook
+
+# Wrong on Windows -- MSYS Bash mangles to C:\by-kind\playbook or similar
+bash -c "pnpm exec elevasis knowledge:ls /by-kind/playbook"
+```
+
+All other `elevasis` and `elevasis-sdk` commands are unaffected; this gotcha is specific to path arguments that start with `/`.
+
+## See Also
+
+- [Query functions API](../reference/contracts.md) -- `bySystem`, `byOntology`, `byKind`, `byOwner`, `governs`, `governedBy` TypeScript signatures
+- [Glossary](../reference/glossary.md) -- `systemId`, `nodeId`, `kind`, `ownerIds`
+- [Knowledge Browser](../../../../apps/docs/content/docs/in-progress/active-development/sdk-changes/knowledge/index.mdx) -- task doc for the full Knowledge Map bundle
+