@elevasis/core 0.24.1 → 0.26.0

package/src/organization-model/content-kinds/registry.ts

@@ -1,44 +0,0 @@
-import type { ContentTypeDefinition, ContentTypeKey } from './types'
-
-// ---------------------------------------------------------------------------
-// Content-kind registry (Phase 3, Wave 1A)
-// ---------------------------------------------------------------------------
-//
-// Per D8 (locked): the registry is populated via STATIC IMPORT, not via a
-// side-effecting registration call. `content-kinds/index.ts` exports
-// CONTENT_KIND_REGISTRY as a const object; Wave 2A merges concrete kind
-// definitions into that barrel. This file stays import-free of concrete kinds.
-//
-// Per D2 (locked): unregistered (kind, type) pairs are NOT errors. They pass
-// through parse-time validation (B5 skips) and render generically in the KB UI.
-
-/**
- * Identity factory for content-type definitions.
- * Per L16: this is the canonical tenant-extension API.
- * It is a pure identity function — no side effects, no global state mutation.
- * Tenants call this in their extension package; the result merges into
- * CONTENT_KIND_REGISTRY via `content-kinds/index.ts`.
- */
-export function defineContentType<TData>(def: ContentTypeDefinition<TData>): ContentTypeDefinition<TData> {
-  return def
-}
-
-/**
- * The kind registry — keyed by `"${kind}:${type}"` composite key.
- * Initially empty; Wave 2A populates by re-exporting through `content-kinds/index.ts`.
- *
- * Consumers should use `lookupContentType` rather than indexing directly,
- * to keep the lookup logic in one place.
- */
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
-export const CONTENT_KIND_REGISTRY: Readonly<Record<ContentTypeKey, ContentTypeDefinition<any>>> = {} as const
-
-/**
- * Look up a registered content-type definition by (kind, type).
- * Returns `undefined` when the pair is not registered — per D2, this is not
- * an error; unregistered pairs render generically and skip payload validation.
- */
-export function lookupContentType(kind: string, type: string): ContentTypeDefinition | undefined {
-  const key: ContentTypeKey = `${kind}:${type}`
-  return CONTENT_KIND_REGISTRY[key]
-}

package/src/organization-model/content-kinds/status.ts

@@ -1,71 +0,0 @@
-import { z } from 'zod'
-import { defineContentType } from './registry'
-
-// ---------------------------------------------------------------------------
-// status-flow + status kinds (Phase 3, Wave 2A)
-// ---------------------------------------------------------------------------
-//
-// `schema:status-flow` — a named set of statuses for a given entity scope
-//                        (project, milestone, or task).
-// `schema:status`      — a single status within a flow; parentTypes constrains
-//                        it to live under a `schema:status-flow` sibling.
-//
-// Payload shape informed by `ProjectsDomainStateSchema` in domains/projects.ts
-// which carries `id`, `label`, and `order`. The content-kind payload carries
-// the semantic classification and optional color token; `label` and `order`
-// live on the base `ContentNodeBase` fields.
-//
-// Per L19: `schema:status` parents only under `schema:status-flow`.
-
-const StatusFlowPayloadSchema = z.object({
-  /**
-   * Which entity scope this status flow governs.
-   */
-  appliesTo: z
-    .enum(['project', 'milestone', 'task'])
-    .meta({ label: 'Applies to', hint: 'Entity scope governed by this status flow', color: 'blue' })
-})
-
-export type StatusFlowPayload = z.infer<typeof StatusFlowPayloadSchema>
-
-export const statusFlowKind = defineContentType({
-  kind: 'schema',
-  type: 'status-flow',
-  label: 'Status Flow',
-  description: 'A named set of statuses governing a project, milestone, or task entity.',
-  payloadSchema: StatusFlowPayloadSchema,
-  parentTypes: []
-})
-
-// ---------------------------------------------------------------------------
-
-const StatusPayloadSchema = z.object({
-  /**
-   * Semantic classification string for this status.
-   * Free-form to allow tenant-defined classifications (e.g. 'active', 'blocked',
-   * 'completed'). Used by UI to apply color and icon fallbacks.
-   * Optional — status nodes may omit this when the label is self-descriptive.
-   */
-  semanticClass: z
-    .string()
-    .trim()
-    .min(1)
-    .max(100)
-    .optional()
-    .meta({ label: 'Semantic class', hint: 'Semantic meaning of this status (e.g. active, blocked, completed)' }),
-  /**
-   * Optional UI color token override for this status.
-   */
-  color: z.string().trim().min(1).max(40).optional().meta({ label: 'Color', hint: 'UI color token' })
-})
-
-export type StatusPayload = z.infer<typeof StatusPayloadSchema>
-
-export const statusKind = defineContentType({
-  kind: 'schema',
-  type: 'status',
-  label: 'Status',
-  description: 'A single status within a status flow. Must be parented under a schema:status-flow content node.',
-  payloadSchema: StatusPayloadSchema,
-  parentTypes: ['schema:status-flow']
-})

package/src/organization-model/content-kinds/template.ts

@@ -1,83 +0,0 @@
-import { z } from 'zod'
-import { defineContentType } from './registry'
-
-// ---------------------------------------------------------------------------
-// template + template-step kinds (Phase 3, Wave 2A)
-// ---------------------------------------------------------------------------
-//
-// `schema:template`      — a named build template (e.g. prospecting pipeline).
-// `schema:template-step` — a step within a template; parentTypes constrains it
-//                          to live under a `schema:template` sibling.
-//
-// Payload shape informed by `ProspectingBuildTemplateSchema` /
-// `ProspectingBuildTemplateStepSchema` in domains/prospecting.ts.
-// The content-kind payload is a lightweight descriptor — full step config
-// (batch sizes, credential requirements, record columns) lives in the
-// typed domain schema during Phase 3; this payload carries only the
-// identity fields needed by the KB renderer.
-//
-// Per L19: `schema:template-step` parents only under `schema:template`.
-
-const TemplatePayloadSchema = z.object({
-  /**
-   * Optional description surfaced in the KB describe view and tooling.
-   */
-  description: z
-    .string()
-    .trim()
-    .min(1)
-    .max(2000)
-    .optional()
-    .meta({ label: 'Description', hint: 'What this template is used for' })
-})
-
-export type TemplatePayload = z.infer<typeof TemplatePayloadSchema>
-
-export const templateKind = defineContentType({
-  kind: 'schema',
-  type: 'template',
-  label: 'Template',
-  description: 'A named build template (e.g. a prospecting pipeline sequence).',
-  payloadSchema: TemplatePayloadSchema,
-  parentTypes: []
-})
-
-// ---------------------------------------------------------------------------
-
-const TemplateStepPayloadSchema = z.object({
-  /**
-   * Which entity type this step primarily operates on.
-   */
-  primaryEntity: z
-    .enum(['company', 'contact'])
-    .meta({ label: 'Primary entity', hint: 'Entity type this step processes', color: 'blue' }),
-  /**
-   * Action key identifying the workflow action executed by this step.
-   * `.meta({ ref: 'action' })` enables SchemaDrivenFieldList to render a
-   * clickable graph link.
-   */
-  actionKey: z
-    .string()
-    .trim()
-    .min(1)
-    .max(200)
-    .meta({ label: 'Action', ref: 'action', hint: 'Workflow action executed by this step' }),
-  /**
-   * IDs of sibling step local NodeIds this step depends on.
-   */
-  dependsOn: z
-    .array(z.string().trim().min(1).max(200))
-    .optional()
-    .meta({ label: 'Depends on', hint: 'Local NodeIds of prerequisite steps' })
-})
-
-export type TemplateStepPayload = z.infer<typeof TemplateStepPayloadSchema>
-
-export const templateStepKind = defineContentType({
-  kind: 'schema',
-  type: 'template-step',
-  label: 'Template Step',
-  description: 'A step within a build template. Must be parented under a schema:template content node.',
-  payloadSchema: TemplateStepPayloadSchema,
-  parentTypes: ['schema:template']
-})

package/src/organization-model/content-kinds/types.ts

@@ -1,117 +0,0 @@
-import { z } from 'zod'
-import type { ZodType } from 'zod'
-
-// ---------------------------------------------------------------------------
-// ContentNode primitives (Phase 3, Wave 1A)
-// ---------------------------------------------------------------------------
-//
-// Per L11a: content NodeIds are local strings within a system. The key in
-// `system.content` is the local id; the qualified id (`<system-path>:<local-id>`)
-// is computed by graph projection — it is never stored on the value itself.
-//
-// Per L14: TWO-LEVEL discrimination — every ContentNode carries both `kind`
-// (meta-category) and `type` (specific family). Symmetric across all meta-kinds.
-//
-// Per D2 (locked): unregistered (kind, type) pairs render generically and pass
-// through parse-time validation (B5 skips validation for unknown pairs).
-
-/**
- * Base fields common to every ContentNode, regardless of (kind, type).
- * Per L11a, `label` is the only required field — the local id is the map key.
- */
-export const ContentNodeBaseSchema = z.object({
-  /** Human-readable label for the content node. */
-  label: z.string().trim().min(1).max(120).meta({ label: 'Label' }),
-  /** Optional one-paragraph description. */
-  description: z.string().trim().min(1).max(2000).optional().meta({ label: 'Description' }),
-  /** Optional display order within the system content map. */
-  order: z.number().int().optional().meta({ label: 'Order' }),
-  /**
-   * Local NodeId of the parent content node within the SAME system.
-   * Per B4/L9: MUST resolve to a sibling in the same `system.content` map.
-   * Per L19: parent and child MUST share the same `kind` (meta-category).
-   */
-  parentContentId: z.string().trim().min(1).max(200).optional().meta({ label: 'Parent content id' })
-})
-
-export type ContentNodeBase = z.infer<typeof ContentNodeBaseSchema>
-
-/**
- * Placeholder discriminated union for ContentNode (Wave 1A).
- * Wave 2A wires concrete (kind, type) pairs via the registry.
- *
- * Per D2: unregistered (kind, type) pairs are allowed and pass through validation.
- * Per L14: every node carries BOTH `kind` and `type`.
- */
-export const ContentNodeSchema = ContentNodeBaseSchema.extend({
-  /** Meta-category (e.g. 'schema', 'config', 'knowledge', tenant-defined). */
-  kind: z.string().trim().min(1).max(100).meta({ label: 'Kind' }),
-  /** Specific family within the meta-category (e.g. 'pipeline', 'kv'). */
-  type: z.string().trim().min(1).max(100).meta({ label: 'Type' }),
-  /** Payload data; validated against registered payloadSchema when (kind, type) is known. */
-  data: z.record(z.string(), z.unknown()).optional().meta({ label: 'Data' })
-})
-
-export type ContentNode = z.infer<typeof ContentNodeSchema>
-
-/**
- * Org-level extension node for tenant-defined business-model concepts.
- * Per L6: tenants add "Partners", "Audiences", etc. via `org.extensions`.
- * Unlike ContentNode, ExtensionNode is not system-scoped and has no parentContentId.
- */
-export const ExtensionNodeSchema = z.object({
-  /** Meta-category (tenant-defined or registry-shipped). */
-  kind: z.string().trim().min(1).max(100).meta({ label: 'Kind' }),
-  /** Specific family within the meta-category. */
-  type: z.string().trim().min(1).max(100).meta({ label: 'Type' }),
-  /** Human-readable label shown in the KB tree and describe views. */
-  label: z.string().trim().min(1).max(120).meta({ label: 'Label' }),
-  /** Optional description. */
-  description: z.string().trim().min(1).max(2000).optional().meta({ label: 'Description' }),
-  /**
-   * Which KB tree group this extension renders in.
-   * Per L6: 'business-model' places it alongside Customers / Offerings / Goals.
-   */
-  treeGroup: z
-    .union([z.enum(['profile', 'business-model', 'systems', 'graph', 'governance-wiring']), z.string().min(1).max(100)])
-    .meta({ label: 'Tree group' }),
-  /** Untyped payload; shape governed by the registered payloadSchema when available. */
-  data: z.record(z.string(), z.unknown()).optional().meta({ label: 'Data' })
-})
-
-export type ExtensionNode = z.infer<typeof ExtensionNodeSchema>
-
-// ---------------------------------------------------------------------------
-// Kind registry types
-// ---------------------------------------------------------------------------
-
-/**
- * Canonical key for the content-kind registry.
- * Format: `<kind>:<type>`, e.g. `'schema:pipeline'`, `'config:kv'`.
- * Per L4, D8: keyed by this composite key in CONTENT_KIND_REGISTRY.
- */
-export type ContentTypeKey = `${string}:${string}`
-
-/**
- * A registered content-type definition.
- * Per L16: `defineContentType` is the canonical tenant-extension API.
- * Per D8: registry is populated via static import, not side-effecting registration.
- */
-export interface ContentTypeDefinition<TData = unknown> {
-  /** Meta-category (e.g. 'schema', 'config', tenant-defined). */
-  kind: string
-  /** Specific family within the meta-category (e.g. 'pipeline', 'kv'). */
-  type: string
-  /** Zod schema for the `data` field; validated at OM parse time per B5. */
-  payloadSchema: ZodType<TData>
-  /**
-   * Valid parent (kind, type) pairs for `parentContentId`.
-   * Per L19: child and parent MUST share the same `kind`.
-   * Empty array means this type is top-level (no parent allowed or required).
-   */
-  parentTypes?: ContentTypeKey[]
-  /** Optional display label for this content type. */
-  label?: string
-  /** Optional description for tooling and docs. */
-  description?: string
-}