@elevasis/core 0.23.0 → 0.24.1

package/src/organization-model/catalogs/lead-gen.ts

@@ -1,144 +1,144 @@
-// ============================================================================
-// Lead-Gen Stage Catalog (OM Spine processing-state model)
-//
-// Canonical set of processing stage keys for acq_companies.processing_state and
-// acq_contacts.processing_state. These keys coordinate build templates, workflow
-// factory validation, API filters, and UI progress projections.
-//
-// State is sparse: absent keys mean "not attempted"; present keys hold terminal
-// status entries such as success, no_result, skipped, or error.
-//
-// Historical sources:
-//   ACQ_LIST_MEMBERS_LEAD_GEN_PIPELINE   -> personalized, uploaded, interested,
-//                                          discovered, verified
-//   ACQ_LIST_COMPANIES_LEAD_GEN_PIPELINE -> populated, extracted, qualified
-//   Design plan hint (lead-gen-domain-cleanup.mdx section 4) -> scraped, enriched
-//
-// ============================================================================
-
-/** One entry in the lead-gen stage catalog. */
-export interface LeadGenStageCatalogEntry {
-  /** Matches the status key written into processing_state jsonb (e.g. 'scraped'). */
-  key: string
-  /** Human-readable label for UI display. */
-  label: string
-  /** Short description of what this stage represents. */
-  description: string
-  /** Canonical pipeline order for UI sorting. Lower = earlier in the funnel. */
-  order: number
-  /** Which entity's processing_state jsonb carries this stage status. */
-  entity: 'company' | 'contact'
-  /** Additional entities allowed to write/read this processing_state key. */
-  additionalEntities?: Array<'company' | 'contact'>
-  /**
-   * Optional read-side override for Records views when a company-scoped step
-   * produces records on a different entity.
-   */
-  recordEntity?: 'company' | 'contact'
-  /** Stage key to read from recordEntity.processing_state for Records views. */
-  recordStageKey?: string
-}
-
-/**
- * Canonical lead-gen processing stage catalog.
- * Keys are the stage names written by workflow steps into processing_state jsonb.
- *
- * Ordered roughly by pipeline progression (prospecting -> outreach -> qualification).
- */
-export const LEAD_GEN_STAGE_CATALOG: Record<string, LeadGenStageCatalogEntry> = {
-  // Prospecting - company population
-  scraped: {
-    key: 'scraped',
-    label: 'Scraped',
-    description: 'Company was scraped from a source directory (Apify actor run).',
-    order: 1,
-    entity: 'company'
-  },
-  populated: {
-    key: 'populated',
-    label: 'Companies found',
-    description: 'Companies have been found and added to the lead-gen list.',
-    order: 2,
-    entity: 'company'
-  },
-  crawled: {
-    key: 'crawled',
-    label: 'Websites crawled',
-    description:
-      'Company websites have been crawled (e.g. via Apify) and raw page content stored for downstream LLM analysis.',
-    order: 2.5,
-    entity: 'company'
-  },
-  extracted: {
-    key: 'extracted',
-    label: 'Websites analyzed',
-    description: 'Company websites have been analyzed for business signals.',
-    order: 3,
-    entity: 'company'
-  },
-  enriched: {
-    key: 'enriched',
-    label: 'Enriched',
-    description: 'Company or contact enriched with third-party data (e.g. Tomba, Anymailfinder).',
-    order: 4,
-    entity: 'company'
-  },
-  'decision-makers-enriched': {
-    key: 'decision-makers-enriched',
-    label: 'Decision-makers found',
-    description: 'Decision-maker contacts discovered and attached to a qualified company.',
-    order: 6,
-    entity: 'company',
-    recordEntity: 'contact',
-    recordStageKey: 'discovered'
-  },
-
-  // Prospecting - contact discovery
-  discovered: {
-    key: 'discovered',
-    label: 'Decision-makers found',
-    description: 'Decision-maker contact details have been found.',
-    order: 5,
-    entity: 'contact'
-  },
-  verified: {
-    key: 'verified',
-    label: 'Emails verified',
-    description: 'Contact email addresses have been checked for deliverability.',
-    order: 7,
-    entity: 'contact'
-  },
-
-  // Qualification
-  qualified: {
-    key: 'qualified',
-    label: 'Companies qualified',
-    description: 'Companies have been scored against the qualification criteria.',
-    order: 8,
-    entity: 'company'
-  },
-
-  // Outreach
-  personalized: {
-    key: 'personalized',
-    label: 'Personalized',
-    description: 'Outreach message personalized for the contact (Instantly personalization workflow).',
-    order: 9,
-    entity: 'contact'
-  },
-  uploaded: {
-    key: 'uploaded',
-    label: 'Reviewed and exported',
-    description: 'Approved records have been reviewed and exported for handoff.',
-    order: 10,
-    entity: 'company',
-    additionalEntities: ['contact']
-  },
-  interested: {
-    key: 'interested',
-    label: 'Interested',
-    description: 'Contact replied with a positive signal (Instantly reply-handler transition).',
-    order: 11,
-    entity: 'contact'
-  }
-}
+// ============================================================================
+// Lead-Gen Stage Catalog (OM Spine processing-state model)
+//
+// Canonical set of processing stage keys for acq_companies.processing_state and
+// acq_contacts.processing_state. These keys coordinate build templates, workflow
+// factory validation, API filters, and UI progress projections.
+//
+// State is sparse: absent keys mean "not attempted"; present keys hold terminal
+// status entries such as success, no_result, skipped, or error.
+//
+// Historical sources:
+//   ACQ_LIST_MEMBERS_LEAD_GEN_PIPELINE   -> personalized, uploaded, interested,
+//                                          discovered, verified
+//   ACQ_LIST_COMPANIES_LEAD_GEN_PIPELINE -> populated, extracted, qualified
+//   Design plan hint (lead-gen-domain-cleanup.mdx section 4) -> scraped, enriched
+//
+// ============================================================================
+
+/** One entry in the lead-gen stage catalog. */
+export interface LeadGenStageCatalogEntry {
+  /** Matches the status key written into processing_state jsonb (e.g. 'scraped'). */
+  key: string
+  /** Human-readable label for UI display. */
+  label: string
+  /** Short description of what this stage represents. */
+  description: string
+  /** Canonical pipeline order for UI sorting. Lower = earlier in the funnel. */
+  order: number
+  /** Which entity's processing_state jsonb carries this stage status. */
+  entity: 'company' | 'contact'
+  /** Additional entities allowed to write/read this processing_state key. */
+  additionalEntities?: Array<'company' | 'contact'>
+  /**
+   * Optional read-side override for Records views when a company-scoped step
+   * produces records on a different entity.
+   */
+  recordEntity?: 'company' | 'contact'
+  /** Stage key to read from recordEntity.processing_state for Records views. */
+  recordStageKey?: string
+}
+
+/**
+ * Canonical lead-gen processing stage catalog.
+ * Keys are the stage names written by workflow steps into processing_state jsonb.
+ *
+ * Ordered roughly by pipeline progression (prospecting -> outreach -> qualification).
+ */
+export const LEAD_GEN_STAGE_CATALOG: Record<string, LeadGenStageCatalogEntry> = {
+  // Prospecting - company population
+  scraped: {
+    key: 'scraped',
+    label: 'Scraped',
+    description: 'Company was scraped from a source directory (Apify actor run).',
+    order: 1,
+    entity: 'company'
+  },
+  populated: {
+    key: 'populated',
+    label: 'Companies found',
+    description: 'Companies have been found and added to the lead-gen list.',
+    order: 2,
+    entity: 'company'
+  },
+  crawled: {
+    key: 'crawled',
+    label: 'Websites crawled',
+    description:
+      'Company websites have been crawled (e.g. via Apify) and raw page content stored for downstream LLM analysis.',
+    order: 2.5,
+    entity: 'company'
+  },
+  extracted: {
+    key: 'extracted',
+    label: 'Websites analyzed',
+    description: 'Company websites have been analyzed for business signals.',
+    order: 3,
+    entity: 'company'
+  },
+  enriched: {
+    key: 'enriched',
+    label: 'Enriched',
+    description: 'Company or contact enriched with third-party data (e.g. Tomba, Anymailfinder).',
+    order: 4,
+    entity: 'company'
+  },
+  'decision-makers-enriched': {
+    key: 'decision-makers-enriched',
+    label: 'Decision-makers found',
+    description: 'Decision-maker contacts discovered and attached to a qualified company.',
+    order: 6,
+    entity: 'company',
+    recordEntity: 'contact',
+    recordStageKey: 'discovered'
+  },
+
+  // Prospecting - contact discovery
+  discovered: {
+    key: 'discovered',
+    label: 'Decision-makers found',
+    description: 'Decision-maker contact details have been found.',
+    order: 5,
+    entity: 'contact'
+  },
+  verified: {
+    key: 'verified',
+    label: 'Emails verified',
+    description: 'Contact email addresses have been checked for deliverability.',
+    order: 7,
+    entity: 'contact'
+  },
+
+  // Qualification
+  qualified: {
+    key: 'qualified',
+    label: 'Companies qualified',
+    description: 'Companies have been scored against the qualification criteria.',
+    order: 8,
+    entity: 'company'
+  },
+
+  // Outreach
+  personalized: {
+    key: 'personalized',
+    label: 'Personalized',
+    description: 'Outreach message personalized for the contact (Instantly personalization workflow).',
+    order: 9,
+    entity: 'contact'
+  },
+  uploaded: {
+    key: 'uploaded',
+    label: 'Reviewed and exported',
+    description: 'Approved records have been reviewed and exported for handoff.',
+    order: 10,
+    entity: 'company',
+    additionalEntities: ['contact']
+  },
+  interested: {
+    key: 'interested',
+    label: 'Interested',
+    description: 'Contact replied with a positive signal (Instantly reply-handler transition).',
+    order: 11,
+    entity: 'contact'
+  }
+}

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

@@ -1,36 +1,36 @@
-import { z } from 'zod'
-import { defineContentType } from './registry'
-
-// ---------------------------------------------------------------------------
-// config kinds (Phase 3, Wave 2A)
-// ---------------------------------------------------------------------------
-//
-// `config:kv` — a flat key-value configuration store co-located with a system.
-//               Per L15: single starter config type; feature-flag semantics are
-//               a usage pattern over kv, not a separate type.
-//
-// Per L15: `config` is a first-class registered meta-kind. Scope: NEW
-// tenant-defined settings co-located with a system. Strongly-typed platform
-// fields (system.ui.devOnly, system.ui.requiresAdmin, etc.) stay where they
-// are and are NOT hoisting destinations for existing typed fields.
-
-const ConfigKvPayloadSchema = z.object({
-  /**
-   * Flat key-value entries. Values are JSON primitives.
-   * Keys are short identifiers (e.g. 'maxBatchSize', 'featureEnabled').
-   */
-  entries: z
-    .record(z.string().trim().min(1).max(200), z.union([z.string(), z.number(), z.boolean(), z.null()]))
-    .meta({ label: 'Entries', hint: 'Key-value configuration entries (string, number, boolean, or null values)' })
-})
-
-export type ConfigKvPayload = z.infer<typeof ConfigKvPayloadSchema>
-
-export const configKvKind = defineContentType({
-  kind: 'config',
-  type: 'kv',
-  label: 'Key-Value Config',
-  description: 'A flat key-value configuration store co-located with a system. Values are JSON primitives.',
-  payloadSchema: ConfigKvPayloadSchema,
-  parentTypes: []
-})
+import { z } from 'zod'
+import { defineContentType } from './registry'
+
+// ---------------------------------------------------------------------------
+// config kinds (Phase 3, Wave 2A)
+// ---------------------------------------------------------------------------
+//
+// `config:kv` — a flat key-value configuration store co-located with a system.
+//               Per L15: single starter config type; feature-flag semantics are
+//               a usage pattern over kv, not a separate type.
+//
+// Per L15: `config` is a first-class registered meta-kind. Scope: NEW
+// tenant-defined settings co-located with a system. Strongly-typed platform
+// fields (system.ui.devOnly, system.ui.requiresAdmin, etc.) stay where they
+// are and are NOT hoisting destinations for existing typed fields.
+
+const ConfigKvPayloadSchema = z.object({
+  /**
+   * Flat key-value entries. Values are JSON primitives.
+   * Keys are short identifiers (e.g. 'maxBatchSize', 'featureEnabled').
+   */
+  entries: z
+    .record(z.string().trim().min(1).max(200), z.union([z.string(), z.number(), z.boolean(), z.null()]))
+    .meta({ label: 'Entries', hint: 'Key-value configuration entries (string, number, boolean, or null values)' })
+})
+
+export type ConfigKvPayload = z.infer<typeof ConfigKvPayloadSchema>
+
+export const configKvKind = defineContentType({
+  kind: 'config',
+  type: 'kv',
+  label: 'Key-Value Config',
+  description: 'A flat key-value configuration store co-located with a system. Values are JSON primitives.',
+  payloadSchema: ConfigKvPayloadSchema,
+  parentTypes: []
+})

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

@@ -1,74 +1,78 @@
-// ---------------------------------------------------------------------------
-// content-kinds barrel (Phase 3, Wave 2A)
-// ---------------------------------------------------------------------------
-//
-// Per D8 (locked): CONTENT_KIND_REGISTRY is populated via static import, not
-// side-effecting registration. This file is the single source of truth for
-// the populated registry. `registry.ts` exports the EMPTY registry constant
-// (kept for historical/import-chain reasons) — consumers MUST import from
-// this barrel, not from `registry.ts` directly, to get the populated registry.
-//
-// Registry keys follow the `<kind>:<type>` ContentTypeKey format (per L4, D8).
-
-export { defineContentType } from './registry'
-export type { ContentTypeKey, ContentTypeDefinition } from './types'
-export { ContentNodeBaseSchema, ContentNodeSchema, ExtensionNodeSchema } from './types'
-export type { ContentNodeBase, ContentNode, ExtensionNode } from './types'
-
-export { pipelineKind, stageKind } from './pipeline'
-export type { PipelinePayload, StagePayload } from './pipeline'
-
-export { templateKind, templateStepKind } from './template'
-export type { TemplatePayload, TemplateStepPayload } from './template'
-
-export { statusFlowKind, statusKind } from './status'
-export type { StatusFlowPayload, StatusPayload } from './status'
-
-export { configKvKind } from './config'
-export type { ConfigKvPayload } from './config'
-
-import { pipelineKind, stageKind } from './pipeline'
-import { templateKind, templateStepKind } from './template'
-import { statusFlowKind, statusKind } from './status'
-import { configKvKind } from './config'
-import type { ContentTypeDefinition, ContentTypeKey } from './types'
-
-/**
- * The populated content-kind registry for all platform-shipped kinds.
- * Per D8: static const object keyed by `'<kind>:<type>'` composite key.
+// ---------------------------------------------------------------------------
+// content-kinds barrel (Phase 3, Wave 2A)
+// ---------------------------------------------------------------------------
+//
+// Per D8 (locked): CONTENT_KIND_REGISTRY is populated via static import, not
+// side-effecting registration. This file is the single source of truth for
+// the populated registry. `registry.ts` exports the EMPTY registry constant
+// (kept for historical/import-chain reasons) — consumers MUST import from
+// this barrel, not from `registry.ts` directly, to get the populated registry.
+//
+// Registry keys follow the `<kind>:<type>` ContentTypeKey format (per L4, D8).
+
+export { defineContentType } from './registry'
+export type { ContentTypeKey, ContentTypeDefinition } from './types'
+export { ContentNodeBaseSchema, ContentNodeSchema, ExtensionNodeSchema } from './types'
+export type { ContentNodeBase, ContentNode, ExtensionNode } from './types'
+
+export { pipelineKind, stageKind } from './pipeline'
+export type { PipelinePayload, StagePayload } from './pipeline'
+
+export { templateKind, templateStepKind } from './template'
+export type { TemplatePayload, TemplateStepPayload } from './template'
+
+export { statusFlowKind, statusKind } from './status'
+export type { StatusFlowPayload, StatusPayload } from './status'
+
+export { configKvKind } from './config'
+export type { ConfigKvPayload } from './config'
+
+import { pipelineKind, stageKind } from './pipeline'
+import { templateKind, templateStepKind } from './template'
+import { statusFlowKind, statusKind } from './status'
+import { configKvKind } from './config'
+import type { ContentTypeDefinition, ContentTypeKey } from './types'
+
+/**
+ * Compatibility registry for bridge-era System.content nodes.
+ * New schema/catalog authoring should use System.ontology, and new
+ * system-local settings should use System.config. These definitions remain so
+ * old tenant content can parse, render, migrate, and project read-only.
  *
- * Keys:
- *   'schema:pipeline'      — pipeline applying to an entity type
- *   'schema:stage'         — stage within a pipeline (parentTypes: ['schema:pipeline'])
- *   'schema:template'      — named build template
- *   'schema:template-step' — step within a template (parentTypes: ['schema:template'])
- *   'schema:status-flow'   — status set for a project/milestone/task scope
- *   'schema:status'        — single status within a flow (parentTypes: ['schema:status-flow'])
- *   'config:kv'            — flat key-value config store co-located with a system
+ * Per D8: static const object keyed by `'<kind>:<type>'` composite key.
  *
- * Wave 3A's `ContentNodeDescribeView` consumes `lookupContentType(kind, type)`
- * which indexes into this registry. Import `lookupContentType` from this barrel
- * to get the populated version.
- */
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
-export const CONTENT_KIND_REGISTRY: Readonly<Record<ContentTypeKey, ContentTypeDefinition<any>>> = {
-  'schema:pipeline': pipelineKind,
-  'schema:stage': stageKind,
-  'schema:template': templateKind,
-  'schema:template-step': templateStepKind,
-  'schema:status-flow': statusFlowKind,
-  'schema:status': statusKind,
-  'config:kv': configKvKind
-} as const
-
-/**
- * Look up a registered content-type definition by (kind, type).
- * Uses the populated CONTENT_KIND_REGISTRY from this barrel — wave 2A override
- * of the empty registry exported from registry.ts.
- * 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]
-}
+ * Bridge keys:
+ *   'schema:pipeline'      — projects to ontology catalog records
+ *   'schema:stage'         — projects to ontology catalog entries
+ *   'schema:template'      — projects to ontology/catalog or action metadata
+ *   'schema:template-step' — projects to template metadata or catalog entries
+ *   'schema:status-flow'   — projects to ontology catalog records
+ *   'schema:status'        — projects to ontology catalog entries
+ *   'config:kv'            — projects into resolved System.config
+ *
+ * Wave 3A's `ContentNodeDescribeView` consumes `lookupContentType(kind, type)`
+ * which indexes into this registry. Import `lookupContentType` from this barrel
+ * to get the populated version.
+ */
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+export const CONTENT_KIND_REGISTRY: Readonly<Record<ContentTypeKey, ContentTypeDefinition<any>>> = {
+  'schema:pipeline': pipelineKind,
+  'schema:stage': stageKind,
+  'schema:template': templateKind,
+  'schema:template-step': templateStepKind,
+  'schema:status-flow': statusFlowKind,
+  'schema:status': statusKind,
+  'config:kv': configKvKind
+} as const
+
+/**
+ * Look up a registered content-type definition by (kind, type).
+ * Uses the populated CONTENT_KIND_REGISTRY from this barrel — wave 2A override
+ * of the empty registry exported from registry.ts.
+ * 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/pipeline.ts

@@ -1,68 +1,68 @@
-import { z } from 'zod'
-import { defineContentType } from './registry'
-
-// ---------------------------------------------------------------------------
-// pipeline + stage kinds (Phase 3, Wave 2A)
-// ---------------------------------------------------------------------------
-//
-// `schema:pipeline` — a named pipeline that applies to an entity type.
-// `schema:stage`    — a stage within a pipeline; parentTypes constrains it to
-//                     live under a `schema:pipeline` sibling.
-//
-// Per L19: `schema:stage` parents only under `schema:pipeline`.
-// Per L19 (parent kind constraint): both share the same meta-kind `schema`.
-
-const PipelinePayloadSchema = z.object({
-  /**
-   * Local NodeId of the entity this pipeline applies to (e.g. 'crm.deal').
-   * `.meta({ ref: 'entity' })` enables SchemaDrivenFieldList to render a
-   * clickable graph link to the referenced entity node.
-   */
-  entityId: z
-    .string()
-    .trim()
-    .min(1)
-    .max(200)
-    .meta({ label: 'Entity', ref: 'entity', hint: 'The entity type this pipeline tracks' }),
-  /**
-   * Optional Kanban column color token for UI rendering.
-   */
-  kanbanColor: z.string().trim().min(1).max(40).optional().meta({ label: 'Kanban color', hint: 'UI color token' })
-})
-
-export type PipelinePayload = z.infer<typeof PipelinePayloadSchema>
-
-export const pipelineKind = defineContentType({
-  kind: 'schema',
-  type: 'pipeline',
-  label: 'Pipeline',
-  description: 'A named progression pipeline that applies to a specific entity type.',
-  payloadSchema: PipelinePayloadSchema,
-  parentTypes: []
-})
-
-// ---------------------------------------------------------------------------
-
-const StagePayloadSchema = z.object({
-  /**
-   * Semantic classification for this stage.
-   * Drives color, icon, and CRM-priority logic in consuming views.
-   * Optional — prospecting stages use data.entityKind instead.
-   * Enum aligned with SalesStageSemanticClassSchema (sales.ts).
-   */
-  semanticClass: z
-    .enum(['open', 'active', 'nurturing', 'closed_won', 'closed_lost', 'won', 'lost', 'closed'])
-    .optional()
-    .meta({ label: 'Semantic class', hint: 'Semantic meaning of this stage', color: 'blue' })
-})
-
-export type StagePayload = z.infer<typeof StagePayloadSchema>
-
-export const stageKind = defineContentType({
-  kind: 'schema',
-  type: 'stage',
-  label: 'Stage',
-  description: 'A stage within a pipeline. Must be parented under a schema:pipeline content node.',
-  payloadSchema: StagePayloadSchema,
-  parentTypes: ['schema:pipeline']
-})
+import { z } from 'zod'
+import { defineContentType } from './registry'
+
+// ---------------------------------------------------------------------------
+// pipeline + stage kinds (Phase 3, Wave 2A)
+// ---------------------------------------------------------------------------
+//
+// `schema:pipeline` — a named pipeline that applies to an entity type.
+// `schema:stage`    — a stage within a pipeline; parentTypes constrains it to
+//                     live under a `schema:pipeline` sibling.
+//
+// Per L19: `schema:stage` parents only under `schema:pipeline`.
+// Per L19 (parent kind constraint): both share the same meta-kind `schema`.
+
+const PipelinePayloadSchema = z.object({
+  /**
+   * Local NodeId of the entity this pipeline applies to (e.g. 'crm.deal').
+   * `.meta({ ref: 'entity' })` enables SchemaDrivenFieldList to render a
+   * clickable graph link to the referenced entity node.
+   */
+  entityId: z
+    .string()
+    .trim()
+    .min(1)
+    .max(200)
+    .meta({ label: 'Entity', ref: 'entity', hint: 'The entity type this pipeline tracks' }),
+  /**
+   * Optional Kanban column color token for UI rendering.
+   */
+  kanbanColor: z.string().trim().min(1).max(40).optional().meta({ label: 'Kanban color', hint: 'UI color token' })
+})
+
+export type PipelinePayload = z.infer<typeof PipelinePayloadSchema>
+
+export const pipelineKind = defineContentType({
+  kind: 'schema',
+  type: 'pipeline',
+  label: 'Pipeline',
+  description: 'A named progression pipeline that applies to a specific entity type.',
+  payloadSchema: PipelinePayloadSchema,
+  parentTypes: []
+})
+
+// ---------------------------------------------------------------------------
+
+const StagePayloadSchema = z.object({
+  /**
+   * Semantic classification for this stage.
+   * Drives color, icon, and CRM-priority logic in consuming views.
+   * Optional — prospecting stages use data.entityKind instead.
+   * Enum aligned with SalesStageSemanticClassSchema (sales.ts).
+   */
+  semanticClass: z
+    .enum(['open', 'active', 'nurturing', 'closed_won', 'closed_lost', 'won', 'lost', 'closed'])
+    .optional()
+    .meta({ label: 'Semantic class', hint: 'Semantic meaning of this stage', color: 'blue' })
+})
+
+export type StagePayload = z.infer<typeof StagePayloadSchema>
+
+export const stageKind = defineContentType({
+  kind: 'schema',
+  type: 'stage',
+  label: 'Stage',
+  description: 'A stage within a pipeline. Must be parented under a schema:pipeline content node.',
+  payloadSchema: StagePayloadSchema,
+  parentTypes: ['schema:pipeline']
+})