@elevasis/core 0.2.1 → 0.4.0

package/src/business/base-entities.ts

@@ -0,0 +1,241 @@
+import { z } from 'zod'
+
+/**
+ * Base Entity Contracts
+ *
+ * Typed base interfaces for CRM, Lead-Gen (Acquisition), and Projects domains.
+ * Each uses a `<TMeta>` generic parameter so client projects can narrow the
+ * metadata type in their own `foundations/types/` directory.
+ *
+ * These are PARALLEL abstractions — they do NOT replace or modify the existing
+ * row types (ProjectRow, AcqDealRow, etc.). Use these as the SDK-facing contract
+ * layer; use the row types internally for direct Supabase access.
+ *
+ * Usage in a client project:
+ *   import { BaseProject } from '@elevasis/core' (or '@repo/core' internally)
+ *   type Project = BaseProject<{ budget: number; riskScore: 'low' | 'medium' | 'high' }>
+ *
+ * Extending a Zod schema in a client project:
+ *   import { BaseProjectSchema } from '@elevasis/core'
+ *   const ProjectMetaSchema = z.object({ budget: z.number(), riskScore: z.enum(['low','medium','high']) })
+ *   const ProjectSchema = BaseProjectSchema.extend({ metadata: ProjectMetaSchema })
+ */
+
+// =============================================================================
+// Projects / Delivery
+// =============================================================================
+
+/**
+ * Common fields shared across all project implementations.
+ * `TMeta` narrows the `metadata` JSONB column (prj_projects.metadata).
+ */
+export interface BaseProject<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  name: string
+  kind: string
+  status: string
+  description: string | null
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+/**
+ * Common fields shared across all milestone implementations.
+ * `TMeta` narrows the `metadata` JSONB column (prj_milestones.metadata).
+ */
+export interface BaseMilestone<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  projectId: string
+  name: string
+  status: string
+  description: string | null
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+/**
+ * Common fields shared across all task implementations.
+ * `TMeta` narrows the `metadata` JSONB column (prj_tasks.metadata).
+ */
+export interface BaseTask<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  projectId: string
+  name: string
+  status: string
+  type: string
+  description: string | null
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+// =============================================================================
+// CRM / Acquisition
+// =============================================================================
+
+/**
+ * Common fields shared across all deal implementations.
+ * `TMeta` is an extension point for client-specific deal metadata.
+ * Note: The underlying acq_deals table does not have a `metadata` column;
+ * this field serves as a typed extension slot for SDK consumers.
+ */
+export interface BaseDeal<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  contactEmail: string
+  stage: string | null
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+/**
+ * Common fields shared across all company implementations.
+ * `TMeta` is an extension point for client-specific company metadata.
+ */
+export interface BaseCompany<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  name: string
+  domain: string | null
+  status: string
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+/**
+ * Common fields shared across all contact implementations.
+ * `TMeta` is an extension point for client-specific contact metadata.
+ */
+export interface BaseContact<TMeta = Record<string, unknown>> {
+  id: string
+  organizationId: string
+  email: string
+  firstName: string | null
+  lastName: string | null
+  status: string
+  metadata: TMeta
+  createdAt: string
+  updatedAt: string
+}
+
+// =============================================================================
+// Base Zod Schemas
+// =============================================================================
+
+/**
+ * Base Zod schema for a project record.
+ * Extend with `BaseProjectSchema.extend({ metadata: ProjectMetaSchema })`.
+ */
+export const BaseProjectSchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  name: z.string(),
+  kind: z.string(),
+  status: z.string(),
+  description: z.string().nullable(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+/**
+ * Base Zod schema for a milestone record.
+ * Extend with `BaseMilestoneSchema.extend({ metadata: MilestoneMetaSchema })`.
+ */
+export const BaseMilestoneSchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  projectId: z.string(),
+  name: z.string(),
+  status: z.string(),
+  description: z.string().nullable(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+/**
+ * Base Zod schema for a task record.
+ * Extend with `BaseTaskSchema.extend({ metadata: TaskMetaSchema })`.
+ */
+export const BaseTaskSchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  projectId: z.string(),
+  name: z.string(),
+  status: z.string(),
+  type: z.string(),
+  description: z.string().nullable(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+/**
+ * Base Zod schema for a deal record.
+ * Extend with `BaseDealSchema.extend({ metadata: DealMetaSchema })`.
+ */
+export const BaseDealSchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  contactEmail: z.string(),
+  stage: z.string().nullable(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+/**
+ * Base Zod schema for a company record.
+ * Extend with `BaseCompanySchema.extend({ metadata: CompanyMetaSchema })`.
+ */
+export const BaseCompanySchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  name: z.string(),
+  domain: z.string().nullable(),
+  status: z.string(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+/**
+ * Base Zod schema for a contact record.
+ * Extend with `BaseContactSchema.extend({ metadata: ContactMetaSchema })`.
+ */
+export const BaseContactSchema = z.object({
+  id: z.string(),
+  organizationId: z.string(),
+  email: z.string(),
+  firstName: z.string().nullable(),
+  lastName: z.string().nullable(),
+  status: z.string(),
+  metadata: z.record(z.string(), z.unknown()).default({}),
+  createdAt: z.string(),
+  updatedAt: z.string()
+})
+
+// =============================================================================
+// Inferred types (convenience — matches the interface shapes above)
+// =============================================================================
+
+/** Default (unnarrowed) inferred type from BaseProjectSchema */
+export type BaseProjectInput = z.infer<typeof BaseProjectSchema>
+/** Default (unnarrowed) inferred type from BaseMilestoneSchema */
+export type BaseMilestoneInput = z.infer<typeof BaseMilestoneSchema>
+/** Default (unnarrowed) inferred type from BaseTaskSchema */
+export type BaseTaskInput = z.infer<typeof BaseTaskSchema>
+/** Default (unnarrowed) inferred type from BaseDealSchema */
+export type BaseDealInput = z.infer<typeof BaseDealSchema>
+/** Default (unnarrowed) inferred type from BaseCompanySchema */
+export type BaseCompanyInput = z.infer<typeof BaseCompanySchema>
+/** Default (unnarrowed) inferred type from BaseContactSchema */
+export type BaseContactInput = z.infer<typeof BaseContactSchema>

package/src/business/delivery/types.ts

@@ -19,7 +19,7 @@ export type NoteInsert = Database['public']['Tables']['prj_notes']['Insert']
 // Status enums
 export type ProjectStatus = 'active' | 'on_track' | 'at_risk' | 'blocked' | 'completed' | 'paused'
 
-export type ProjectKind = 'client_engagement' | 'internal'
+export type ProjectKind = 'client_engagement' | 'internal' | 'research' | 'other'
 
 export type MilestoneStatus = 'upcoming' | 'in_progress' | 'completed' | 'overdue' | 'blocked'
 

package/src/business/index.ts

@@ -10,3 +10,6 @@ export * from './acquisition/index'
 
 // SEO types (seo_pages, seo_metrics, chart types)
 export * from './seo/index'
+
+// Base entity contracts (generic TMeta types for SDK consumers)
+export * from './base-entities'

package/src/execution/index.ts

@@ -1,7 +1,7 @@
 /**
  * Execution group barrel - browser-safe exports
  *
- * Execution engine, core types, scheduler, calibration
+ * Execution engine, core types, scheduler
  */
 
 // Execution Engine
@@ -13,8 +13,5 @@ export * from './core/index'
 // Scheduler types
 export * from './scheduler/index'
 
-// Calibration types and schemas
-export * from './calibration/index'
-
-// Integration types (browser-safe param/result interfaces for adapters)
-export * from './engine/tools/integration/types'
+// Integration types (browser-safe param/result interfaces for adapters)
+export * from './engine/tools/integration/types'

package/src/index.ts

@@ -21,7 +21,7 @@ export * from './platform'
 // Auth: multi-tenancy types
 export * from './auth'
 
-// Execution: engine, core types, scheduler, calibration
+// Execution: engine, core types, scheduler
 export * from './execution'
 
 // Commands: command queue types

package/src/organization-model/README.md

@@ -12,6 +12,9 @@ The public entry point exposes:
 - `DEFAULT_ORGANIZATION_MODEL`
 - `defineOrganizationModel`
 - `resolveOrganizationModel`
+- `PROJECTS_FEATURE_ID`
+- `PROJECTS_INDEX_SURFACE_ID`
+- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID`
 - `OrganizationModel` and the supporting domain types
 
 Import it from the published subpath:
@@ -19,7 +22,10 @@ Import it from the published subpath:
 ```ts
 import {
   DEFAULT_ORGANIZATION_MODEL,
+  DELIVERY_PROJECTS_VIEW_CAPABILITY_ID,
   defineOrganizationModel,
+  PROJECTS_FEATURE_ID,
+  PROJECTS_INDEX_SURFACE_ID,
   resolveOrganizationModel,
   type OrganizationModel
 } from '@elevasis/core/organization-model'
@@ -31,43 +37,36 @@ The model is versioned and currently validates against `version: 1`.
 
 Top-level fields:
 
-- `domains` - semantic domain entries that bind entity IDs, surface IDs, resource IDs, and capability IDs.
+- `version` - schema version for the resolved contract.
 - `branding` - organization branding defaults and overrides.
-- `features` - grouped shell-level feature flags and labels.
+- `features` - unified feature entries that combine enablement, labels, and semantic references.
 - `navigation` - navigation model for the product shell.
 - `crm` - CRM-specific contract data.
 - `leadGen` - lead generation contract data.
 - `delivery` - delivery and project contract data.
 - `resourceMappings` - cross-surface resource mappings.
 
-## Default Domain Set
+## Default Feature Set
 
-The default model includes four semantic domains:
+The default model includes seven feature IDs:
 
 - `crm` - deal pipeline and relationship management.
 - `lead-gen` - lists, companies, and contacts.
-- `delivery` - projects, milestones, and tasks.
+- `projects` - projects, milestones, and tasks.
 - `operations` - organization graph and command-view surfaces.
+- `monitoring` - monitoring surfaces.
+- `settings` - organization settings.
+- `seo` - SEO surfaces (disabled by default).
 
-## Feature Keys
+## Project Bridge Constants
 
-The current canonical feature keys are grouped shell features:
+The organization-model surface now exports a narrow set of canonical IDs for the shared Projects bridge:
 
-- `acquisition`
-- `delivery`
-- `operations`
-- `monitoring`
-- `settings`
-- `calibration`
-- `seo`
+- `PROJECTS_FEATURE_ID` -> `projects`
+- `PROJECTS_INDEX_SURFACE_ID` -> `projects.index`
+- `DELIVERY_PROJECTS_VIEW_CAPABILITY_ID` -> `delivery.projects.view`
 
-Each feature can carry an enabled flag and an optional label override.
-
-This is intentionally different from the domain and surface vocabulary:
-
-- domains and surface IDs still use IDs such as `crm`, `lead-gen`, and `projects.index`
-- navigation surfaces point those routes at grouped `featureKey` values such as `acquisition` and `delivery`
-- downstream apps may still carry compatibility aliases for legacy route-level keys, but the published organization-model contract does not
+Use these when wiring shared UI manifests, template adapters, or other consumers that need to agree on the same Projects contract without repeating raw literals.
 
 ## Resolution Semantics
 
@@ -82,13 +81,13 @@ This is intentionally different from the domain and surface vocabulary:
 
 - `navigation.defaultSurfaceId` must point at a declared navigation surface.
 - Every navigation group `surfaceId` must resolve to a declared surface.
-- Domain, surface, and resource-mapping IDs must resolve to declared counterparts; dangling references fail validation.
-- Domain-to-surface and domain/surface-to-resource links are validated in both directions so one-sided declarations fail during resolution.
-- Feature-bearing surfaces validate `featureKey` against the canonical grouped feature set.
+- Feature, surface, and resource-mapping IDs must resolve to declared counterparts; dangling references fail validation.
+- Feature-to-surface and feature/surface-to-resource links are validated in both directions so one-sided declarations fail during resolution.
+- Feature-bearing surfaces validate `featureId` against the canonical feature set.
 
 ## Practical Guidance
 
 - Use `resolveOrganizationModel()` when you need a runtime-safe model for rendering or policy checks.
 - Use `defineOrganizationModel()` when authoring a static partial model in source.
-- Treat `features.enabled` and `features.labels` as the shell-level contract; do not use `crm`, `lead-gen`, or `projects` as canonical feature keys in new organization-model authoring.
-- Keep domain IDs, surface IDs, and capability IDs stable because downstream UI and policy code depend on them.
+- Treat feature IDs such as `crm`, `lead-gen`, and `projects` as the canonical shell-level contract in new organization-model authoring.
+- Keep feature IDs, surface IDs, and capability IDs stable because downstream UI and policy code depend on them.