@elevasis/sdk 1.44.3 → 1.46.0

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

@@ -20,7 +20,7 @@ Both CLIs share the same query layer (`@repo/core/knowledge/queries`). The only
 The `knowledge:*` commands require `elevasis-sdk >= 1.4.0`. Check with:
 
 ```bash
-pnpm exec elevasis-sdk --version
+pnpm 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.
@@ -58,10 +58,10 @@ 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/
+pnpm elevasis-sdk knowledge:ls /by-system/sales.crm/
 
 # Monorepo (from monorepo root)
-pnpm exec elevasis knowledge:ls /by-system/sales.crm/
+pnpm elevasis-sdk knowledge:ls /by-system/sales.crm/
 ```
 
 Nested system ids use dots, not slashes: `sales.crm`, `sales.lead-gen`, `projects`.
@@ -72,10 +72,10 @@ 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
+pnpm elevasis-sdk knowledge:ls /by-ontology/sales.crm:object/deal
 
 # Monorepo
-pnpm exec elevasis knowledge:ls /by-ontology/sales.crm:object/deal
+pnpm elevasis-sdk 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.
@@ -86,10 +86,10 @@ List all nodes of kind `playbook`:
 
 ```bash
 # External project
-pnpm exec elevasis-sdk knowledge:ls /by-kind/playbook
+pnpm elevasis-sdk knowledge:ls /by-kind/playbook
 
 # Monorepo
-pnpm exec elevasis knowledge:ls /by-kind/playbook
+pnpm elevasis-sdk knowledge:ls /by-kind/playbook
 ```
 
 Common kinds: `playbook`, `strategy`, and `reference`. The available kinds are defined on `OrgKnowledgeNode.kind` in `@elevasis/core/knowledge`.
@@ -97,7 +97,7 @@ Common kinds: `playbook`, `strategy`, and `reference`. The available kinds are d
 Machine-readable output for piping:
 
 ```bash
-pnpm exec elevasis knowledge:ls /by-kind/playbook --ids-only
+pnpm elevasis-sdk knowledge:ls /by-kind/playbook --ids-only
 ```
 
 ### 4. List by owner (`/by-owner/<id>/`)
@@ -106,10 +106,10 @@ List all knowledge nodes owned by a specific member or team:
 
 ```bash
 # External project
-pnpm exec elevasis-sdk knowledge:ls /by-owner/operations-team
+pnpm elevasis-sdk knowledge:ls /by-owner/operations-team
 
 # Monorepo
-pnpm exec elevasis knowledge:ls /by-owner/operations-team
+pnpm elevasis-sdk knowledge:ls /by-owner/operations-team
 ```
 
 The `<id>` matches against `node.ownerIds`. Owner IDs are declared on each knowledge node in the OrganizationModel.
@@ -120,10 +120,10 @@ 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/
+pnpm elevasis-sdk knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governs/
 
 # Monorepo
-pnpm exec elevasis knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governs/
+pnpm elevasis-sdk 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,
@@ -141,10 +141,10 @@ 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/
+pnpm 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/
+pnpm elevasis-sdk knowledge:ls /graph/knowledge.new-vertical-launch-playbook/governed-by/
 ```
 
 ## Read a Node Body
@@ -153,16 +153,16 @@ pnpm exec elevasis knowledge:ls /graph/knowledge.new-vertical-launch-playbook/go
 
 ```bash
 # External project
-pnpm exec elevasis-sdk knowledge:cat knowledge.new-vertical-launch-playbook
+pnpm elevasis-sdk knowledge:cat knowledge.new-vertical-launch-playbook
 
 # Monorepo
-pnpm exec elevasis knowledge:cat knowledge.new-vertical-launch-playbook
+pnpm elevasis-sdk 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
+pnpm elevasis-sdk knowledge:cat knowledge.platform-composition-patterns | less
 ```
 
 ## Inspect a Node's Edges
@@ -171,10 +171,10 @@ pnpm exec elevasis knowledge:cat knowledge.platform-composition-patterns | less
 
 ```bash
 # External project
-pnpm exec elevasis-sdk knowledge:graph knowledge.new-vertical-launch-playbook
+pnpm elevasis-sdk knowledge:graph knowledge.new-vertical-launch-playbook
 
 # Monorepo
-pnpm exec elevasis knowledge:graph knowledge.new-vertical-launch-playbook
+pnpm elevasis-sdk 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.
@@ -207,7 +207,7 @@ This is the format consumed by the `/knowledge` agent skill. Use it when scripti
 ```
 
 ```bash
-pnpm exec elevasis knowledge:ls /by-kind/playbook --json | jq '.results[].id'
+pnpm elevasis-sdk knowledge:ls /by-kind/playbook --json | jq '.results[].id'
 ```
 
 ## Windows Note
@@ -216,10 +216,10 @@ On Windows, MSYS Bash rewrites path arguments starting with `/` to Windows files
 
 ```powershell
 # Correct on Windows -- PowerShell leaves the path arg intact
-pnpm exec elevasis knowledge:ls /by-kind/playbook
+pnpm elevasis-sdk 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"
+bash -c "pnpm elevasis-sdk knowledge:ls /by-kind/playbook"
 ```
 
 All other `elevasis` and `elevasis-sdk` commands are unaffected; this gotcha is specific to path arguments that start with `/`.
@@ -228,4 +228,4 @@ All other `elevasis` and `elevasis-sdk` commands are unaffected; this gotcha is
 
 - [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
+- [Knowledge Browser](../../../../apps/docs/content/docs/in-progress/active-development/_pipeline/knowledge/index.mdx) -- task doc for the full Knowledge Map bundle

package/reference/scaffold/reference/contracts.md

@@ -402,13 +402,6 @@ export type OrganizationModelSystemApiInterface = z.infer<typeof SystemApiInterf
 export type OrganizationModelSystemInterfaceRef = z.infer<typeof SystemInterfaceRefSchema>
 ```
 
-### `OrganizationModelSystemStatus`
-
-```typescript
-/** @deprecated Use OrganizationModelSystemLifecycle. Accepted for one publish cycle. */
-export type OrganizationModelSystemStatus = z.infer<typeof SystemStatusSchema>
-```
-
 ### `OrganizationModelResources`
 
 ```typescript
@@ -651,48 +644,6 @@ export type OrganizationModelEntity = z.infer<typeof EntitySchema>
 export type OrganizationModelEntities = z.infer<typeof EntitiesDomainSchema>
 ```
 
-### `OrganizationModelPolicies`
-
-```typescript
-export type OrganizationModelPolicies = z.infer<typeof PoliciesDomainSchema>
-```
-
-### `OrganizationModelPolicy`
-
-```typescript
-export type OrganizationModelPolicy = z.infer<typeof PolicySchema>
-```
-
-### `OrganizationModelPolicyId`
-
-```typescript
-export type OrganizationModelPolicyId = z.infer<typeof PolicyIdSchema>
-```
-
-### `OrganizationModelPolicyApplicability`
-
-```typescript
-export type OrganizationModelPolicyApplicability = z.infer<typeof PolicyApplicabilitySchema>
-```
-
-### `OrganizationModelPolicyTrigger`
-
-```typescript
-export type OrganizationModelPolicyTrigger = z.infer<typeof PolicyTriggerSchema>
-```
-
-### `OrganizationModelPolicyPredicate`
-
-```typescript
-export type OrganizationModelPolicyPredicate = z.infer<typeof PolicyPredicateSchema>
-```
-
-### `OrganizationModelPolicyEffect`
-
-```typescript
-export type OrganizationModelPolicyEffect = z.infer<typeof PolicyEffectSchema>
-```
-
 ### `OrganizationModelKnowledge`
 
 ```typescript
@@ -852,7 +803,6 @@ export interface ResolvedShellModel {
   ancestorsOf: (id: string) => ResolvedShellSystem[]
   parentOf: (id: string) => ResolvedShellSystem | undefined
   topLevel: () => ResolvedShellSystem[]
-  requiresAdminFor: (id: string) => boolean
   devOnlyFor: (id: string) => boolean
 }
 ```
@@ -1626,7 +1576,18 @@ export interface AcqContact {
 ### `DealStage`
 
 ```typescript
-export type DealStage = 'interested' | 'proposal' | 'closing' | 'closed_won' | 'closed_lost' | 'nurturing'
+/**
+ * Deal stage key. Intentionally an open string, not a closed union — stage
+ * vocabulary is tenant-owned content (see the `CrmStageKeySchema` comment in
+ * api-schemas.ts: "CRM stage/state catalogs are model-owned... The published
+ * core schema validates only the transport shape; closed-catalog membership
+ * is enforced by the caller/API layer via model-injected validators"). A
+ * closed union here would bake Elevasis's specific pipeline
+ * (`interested`/`proposal`/`closing`/`closed_won`/`closed_lost`/`nurturing`)
+ * into every tenant's type surface. `DealStageSchema` in api-schemas.ts is
+ * already `z.string()` for the same reason; this type now matches it.
+ */
+export type DealStage = string
 ```
 
 ### `DealPriorityBucketKey`
@@ -2914,7 +2875,7 @@ export const AcqContactListResponseSchema = z.object({
 ### `AcqArtifactOwnerKindSchema`
 
 ```typescript
-export const AcqArtifactOwnerKindSchema = z.enum(['company', 'contact', 'deal', 'list', 'list_member'])
+export const AcqArtifactOwnerKindSchema = z.enum(['company', 'contact', 'deal', 'list', 'list_member', 'organization'])
 ```
 
 ### `ListArtifactsQuerySchema`
@@ -2923,7 +2884,7 @@ export const AcqArtifactOwnerKindSchema = z.enum(['company', 'contact', 'deal',
 export const ListArtifactsQuerySchema = z
   .object({
     ownerKind: AcqArtifactOwnerKindSchema,
-    ownerId: UuidSchema
+    ownerId: UuidSchema.optional()
   })
   .strict()
 ```
@@ -2934,10 +2895,17 @@ export const ListArtifactsQuerySchema = z
 export const CreateArtifactRequestSchema = z
   .object({
     ownerKind: AcqArtifactOwnerKindSchema,
-    ownerId: UuidSchema,
+    // Nullable + optional: an org-owned artifact (ownerKind: 'organization') has no
+    // single owning entity row. See the comment on AcqArtifactOwnerKindSchema above.
+    ownerId: UuidSchema.nullable().optional(),
     kind: z.string().trim().min(1).max(255),
     content: z.record(z.string(), z.unknown()),
-    sourceExecutionId: UuidSchema.optional()
+    sourceExecutionId: UuidSchema.optional(),
+    // Nullable + optional: acquisition's own artifacts (audits, proposals, ICP docs) predate the
+    // pipeline concept and have none. `getActiveArtifact` filters on it, so any artifact meant to
+    // be resolvable as "the active document for pipeline X" MUST supply it -- artifacts-platform-tool
+    // .mdx Step 3 defect 1.
+    pipelineId: PipelineIdSchema.nullable().optional()
   })
   .strict()
 ```
@@ -2949,12 +2917,18 @@ export const AcqArtifactResponseSchema = z.object({
   id: z.string(),
   organizationId: z.string(),
   ownerKind: z.string(),
-  ownerId: z.string(),
+  // Nullable as of content-pipeline-foundation D14: an org-owned artifact has no owning entity row.
+  // CreateArtifactRequestSchema already accepted a null ownerId; this response schema not doing so
+  // was Step 3 defect 2 -- an org-owned artifact inserted fine and then failed serialization.
+  ownerId: z.string().nullable(),
   kind: z.string(),
+  pipelineId: z.string().nullable(),
   content: z.record(z.string(), z.unknown()),
   sourceExecutionId: z.string().nullable(),
   createdBy: z.string().nullable(),
   createdAt: z.string(),
+  updatedAt: z.string(),
+  isActive: z.boolean(),
   version: z.number().int()
 })
 ```

package/reference/scaffold/reference/feature-registry.md

@@ -14,6 +14,8 @@ description: Auto-generated catalog of registered system manifests. Do not edit
 
 | System Key | System ID | Nav Label | Domains | Routes |
 | --- | --- | --- | --- | --- |
+| `clients` | `client-management` | — | — | — |
+| `content` | `content` | — | — | — |
 | `crm` | `sales.crm` | — | — | — |
 | `delivery` | `platform.projects` | — | — | — |
 | `knowledge` | `—` | — | — | — |
@@ -22,5 +24,6 @@ description: Auto-generated catalog of registered system manifests. Do not edit
 | `operations` | `—` | — | — | — |
 | `seo` | `seo` | — | — | — |
 | `settings` | `—` | — | — | — |
+| `submitted-requests` | `—` | — | — | — |
 
 > **Note:** `auth` and `dashboard` are not in the registry — they are app-shell concerns, not gated systems.

package/reference/scaffold/reference/glossary.md

@@ -42,9 +42,9 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **MembershipFeatureConfig** -- retired per-member feature override config. The migration is complete: access is resolved through the unified Access Model using Organization Model System lifecycle, role permissions, diagnostic allowlists, membership scope, and platform-admin bypass.
 
-**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `version`, `domainMetadata`, `branding`, `navigation`, `ontology`, `systems`, `resources`, `topology`, `identity`, `customers`, `offerings`, `roles`, `goals`, `policies`, `statuses`, and `knowledge`. Legacy domain keys such as `sales`, `prospecting`, `projects`, `actions`, and `entities` remain compatibility inputs while projects migrate to System-owned ontology/config/resource contracts.
+**OrganizationModel** -- top-level semantic contract for an organization. Current primary fields include `version`, `snapshotHash`, `domainMetadata`, `branding`, `navigation`, `ontology`, `systems`, `resources`, `topology`, `identity`, `clients`, `customers`, `offerings`, `roles`, `goals`, `policies`, and `knowledge`. `sales`, `prospecting`, `projects`, and `statuses` were removed from the top-level contract in the Phase 4 schema cut; do not author against them. `actions` and `entities` remain current schema fields but are compatibility-oriented -- new authoring prefers System-owned ontology/config/resource contracts.
 
-**OrganizationModelSystemEntry** -- System node in `OrganizationModel.systems`. Primary authoring fields include `id`, `label`, `description`, `parentSystemId`, `systems`, `lifecycle`, `ui`, `requiresAdmin`, `devOnly`, `responsibleRoleId`, `governedByKnowledge`, `drivesGoals`, `actions`, `policies`, `ontology`, `config`, and `order`. `subsystems` and `content` are retained compatibility inputs for older projects and should not be used for new recursive Systems, schemas, catalogs, or config.
+**OrganizationModelSystemEntry** -- System node in `OrganizationModel.systems`. Primary authoring fields include `id`, `label`, `description`, `parentSystemId`, `systems`, `lifecycle`, `ui`, `requiresAdmin`, `devOnly`, `responsibleRoleId`, `governedByKnowledge`, `drivesGoals`, `actions`, `policies`, `ontology`, `config`, and `order`. `subsystems` is a retained compatibility input for older projects and should not be used for new recursive Systems. `content` is **retired** — the System schema is strict and rejects it. Author schemas and catalogs in `ontology`, and system-local settings in `config`.
 
 **Provider / ElevasisSystemsProvider** -- runtime that registers System modules, resolves System lifecycle against the org model, projects sidebar navigation, and exposes shell helpers through `useElevasisSystems()`.
 
@@ -56,7 +56,7 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **System Interface** -- flat `System.apiInterface` marker that adopts a platform-provided API capability for a System. It declares intent through lifecycle, a closed `readinessProfile`, and optional scoped resource IDs; readiness is derived. Custom tenant Systems should not add custom `apiInterface` profiles. They extend behavior through workflows/operations plus ontology, resources, catalogs, topology, and navigation.
 
-**System Interface profile** -- platform-owned readiness profile from `SYSTEM_INTERFACE_PROFILES`, such as `sales.lead-gen.api`, `sales.crm.api`, or `sales.lead-gen.crm-handoff`. Profiles are a closed literal union tied to platform API consumers and readiness checkers, not tenant-defined extension strings.
+**System Interface profile** -- readiness profile id referenced by `system.apiInterface.readinessProfile`. The schema field itself is an open, non-empty string, not a closed literal union. Built-in platform presets (`sales.lead-gen.api`, `sales.crm.api`, `sales.lead-gen.crm-handoff` -- from `SYSTEM_INTERFACE_PROFILES`) are looked up through the profile registry and derive their requirements from platform code. A custom (non-built-in) profile id is validated structurally instead: the System must declare a `readinessContract` (`requiredObjects`, `requiredCatalogs`) so readiness can be checked without platform hardcoding.
 
 **ResourceCategory** -- resource metadata category: `production`, `diagnostic`, `internal`, or `testing`.
 
@@ -64,7 +64,7 @@ description: Terminology disambiguation for Organization OS concepts used in the
 
 **Settings asymmetry** -- Settings is a navigation/app surface whose individual pages are normally governed by admin checks rather than user-facing System toggles.
 
-**Shell model** -- provider output used by sidebars and breadcrumbs. Includes `systems`, `childrenOf`, `ancestorsOf`, `parentOf`, `topLevel`, `findByPath`, `requiresAdminFor`, and `devOnlyFor`.
+**Shell model** -- provider output used by sidebars and breadcrumbs. Includes `systems`, `childrenOf`, `ancestorsOf`, `parentOf`, `topLevel`, `findByPath`, and `devOnlyFor`.
 
 **Subshell / Sidebar** -- System- or route-prefix-scoped UI region rendered when the current route matches a module whose manifest supplies a sidebar.
 

package/reference/scaffold/reference/system-interface-capabilities.md

@@ -6,7 +6,7 @@
 
 # System Interface Capabilities
 
-This catalog is generated from `SYSTEM_INTERFACE_PROFILES` and the derived-readiness checks in `packages/core/src/business/acquisition/ontology-validation.ts`.
+This catalog is generated from `SYSTEM_INTERFACE_PROFILES` and the derived-readiness checks in `packages/core/src/organization-model/readiness/` (built-in lead-gen/CRM profiles are registered from `packages/core/src/business/acquisition/ontology-validation.ts`).
 
 System Interface profiles are a closed platform adoption handshake. Tenant custom Systems should extend behavior through workflows/operations plus ontology, resources, and topology instead of declaring custom `apiInterface.readinessProfile` values.
 
@@ -24,9 +24,10 @@ System Interface profiles are a closed platform adoption handshake. Tenant custo
   - System Interface marker must be active and scope at least one active `sales.lead-gen` Resource.
   - Object types: `sales.lead-gen:object/list`, `sales.lead-gen:object/company`, `sales.lead-gen:object/contact`.
   - Scoped Resource `ontology.reads` bindings for each required object type.
-  - Catalog types with entries: `sales.lead-gen:catalog/build-template`, `sales.lead-gen:catalog/company-stage`, `sales.lead-gen:catalog/contact-stage`, and derived `sales.lead-gen:catalog/lead-gen.stage-catalog`.
+  - Catalog types with entries: `sales.lead-gen:catalog/build-template`, `sales.lead-gen:catalog/company-stage`, `sales.lead-gen:catalog/contact-stage`.
   - Scoped Resource `ontology.usesCatalogs` bindings for each required catalog.
   - A lead-gen template-step catalog owned by `sales.lead-gen` whose `appliesTo` value is `sales.lead-gen:object/list`, plus a scoped `ontology.usesCatalogs` binding for it.
+  - Derived catalog `sales.lead-gen:catalog/lead-gen.stage-catalog` must exist and be non-empty; it carries no scoped-binding requirement.
 
 ## `sales.crm.api`
 
@@ -34,8 +35,8 @@ System Interface profiles are a closed platform adoption handshake. Tenant custo
 - Interface key: `api`
 - Derived-readiness requirements:
   - System Interface marker must be active and scope at least one active `sales.crm` Resource.
-  - Catalog type with entries: `sales.crm:catalog/crm.pipeline`.
-  - Scoped Resource `ontology.usesCatalogs` binding for `sales.crm:catalog/crm.pipeline`.
+  - Catalog types with entries: `sales.crm:catalog/crm.pipeline`.
+  - Scoped Resource `ontology.usesCatalogs` bindings for each required catalog.
 
 ## `sales.lead-gen.crm-handoff`