@elevasis/sdk 1.25.0 → 1.26.1

package/reference/claude-config/sync-notes/2026-05-22-lead-gen-tenant-config.md

@@ -0,0 +1,40 @@
+# Lead Gen Tenant Config Boundary
+
+## Why this note exists
+
+The lead-gen list-builder package boundary changed so shared packages own reusable mechanics and tenant projects own lead-gen values. `@elevasis/core` no longer carries Elevasis tenant build-template defaults, and `@elevasis/ui` derives lead-gen configuration from the provider-injected Organization Model through `useLeadGenConfig()` instead of importing Elevasis-owned defaults.
+
+## Applies to
+
+Template-derived projects that use the shared lead-gen pages, list-builder runner, build templates, workflow actions, or `@elevasis/ui/features/lead-gen`.
+
+Projects with no lead-gen surface and no list-builder workflows can ignore the lead-gen authoring steps, but should still accept package baseline updates from the release train.
+
+## Required actions
+
+1. Pull the template/package updates with `/git-sync` after the SDK ship train lands.
+2. Keep lead-gen stage catalogs, build templates, workflow actions, resources, topology, and credential names in the project Organization Model (`core/config/organization-model.ts`).
+3. Provide project-owned list-builder action wiring in the UI, typically through `ui/src/config/listActions.ts` and the local app shell.
+4. Keep tenant workflow implementations in the project operations package and use `listBuilderWorkflow` from `@elevasis/sdk/worker` for stage handlers.
+5. Do not import Elevasis workspace packages such as `@repo/elevasis-core`, `@repo/core`, or `@repo/ui` from an external project. Use the published `@elevasis/*` packages.
+6. If the project previously relied on shared UI fallback defaults for lead-gen templates or export workflow IDs, add those values to the project Organization Model before expecting list creation or the build runner to behave usefully.
+
+## Verification
+
+Run the project baseline gates after syncing:
+
+```powershell
+pnpm -C core test
+pnpm -C operations check-types
+pnpm -C operations check
+pnpm -C operations test
+pnpm -C ui check-types
+pnpm -C ui build
+pnpm test
+```
+
+For projects with lead-gen enabled, also open the lead-gen list creation and list detail routes and confirm the shared UI sees the project-authored build templates, stage labels, and export workflow.
+
+## Not handled by /git-sync
+
+`/git-sync` updates template-propagated files and package baselines. It does not invent project-specific lead-gen catalogs, workflow contracts, credentials, or `listActions` for an existing tenant. Those remain project-authored decisions.

package/reference/claude-config/sync-notes/2026-05-22-org-model-multi-file-split.md

@@ -0,0 +1,61 @@
+# Organization Model Multi-File Split
+
+## Why this note exists
+
+`core/config/organization-model.ts` has grown large enough that authoring, review, and `/om`
+codify writes are easier against focused files. This change splits the single file into an
+entry file plus a sibling directory, WITHOUT changing the entry filename, the public export
+contract, or any consumer import. The SDK loader, the Tier-2 merge rule, and every downstream
+consumer continue to resolve `core/config/organization-model.ts` exactly as before.
+
+This note is the Tier-1 → Tier-2 handoff interface: the source split lands now (Tier 1); the
+`/external sync` propagation to derived tenants is deferred to a `/sdk ship` cycle (Tier 2).
+
+## What changed
+
+The model is now authored across four files:
+
+- `core/config/organization-model.ts` -- ENTRY: assembles `canonicalOrganizationModel` /
+  `organizationModel` and re-exports every public symbol. No consumer import changes.
+- `core/config/organization-model/profile.ts` -- the `defineOrganizationModel(...)` body
+  (identity, customers, offerings, roles, goals). Primary `/om` codify write target.
+- `core/config/organization-model/systems.ts` -- systems, resources, topology, entities,
+  actions, resource governance, feature/system-ID constants.
+- `core/config/organization-model/navigation.ts` -- sidebar navigation tree and surface
+  projection; imports `systems.ts` directly (never via the entry) to keep the graph acyclic.
+
+## Applies to
+
+- `external/_template/core/config/organization-model.ts` and the new `organization-model/`
+  sibling directory
+- Any downstream tenant project derived from `_template` that opts in to the split (the
+  Tier-2 merge does NOT force adoption — single-file projects remain valid)
+
+## Sync tiers for the new siblings
+
+- `organization-model.ts` (entry) -- `merge` / `merge-regions` / `@elevasis/core` (unchanged)
+- `organization-model/systems.ts` -- `merge` / `merge-regions` / `@elevasis/core`
+- `organization-model/navigation.ts` -- `merge` / `merge-regions` / `@elevasis/core`
+- `organization-model/profile.ts` -- `never-touch` / `verify-only` / project-owned (the
+  `/om` codify write target; sync never overwrites it)
+
+## Required actions
+
+- For an unsplit project that wants the split: mirror the four-file layout from `_template`,
+  preserving the `defineOrganizationModel(...)` body verbatim into `profile.ts`. Keep the
+  entry filename and the full public export barrel.
+- No action is required to stay on the single-file layout — it remains supported.
+
+## Verification
+
+- `pnpm -C core test` (snapshot equality — the resolved model must be byte-identical to the
+  pre-split fixture)
+- `pnpm -C operations check-types`
+- `pnpm sync:verify` from the monorepo root after `/external sync` propagates (the
+  export-presence checks now tolerate the re-export form across the sibling files)
+
+## Not handled by /git-sync
+
+`/git-sync` does not split your `core/config/organization-model.ts` for you. The split is an
+intentional one-time structural migration — author it directly (or via `/om`), preserving the
+`defineOrganizationModel(...)` body verbatim, and review it in a normal PR.

package/reference/claude-config/sync-notes/2026-05-23-branding-names-to-identity.md

@@ -0,0 +1,49 @@
+# Branding Names to Identity
+
+## Why this note exists
+
+The Organization Model now treats `identity.organizationName`, `identity.productName`,
+and `identity.shortName` as the preferred source for display naming. The older
+`branding.*` name fields remain valid for backward compatibility, but new template code
+reads identity first and falls back to branding only for legacy projects.
+
+Branding also now supports first-class expression fields such as `voice`, `tagline`,
+`values`, and `themePresetId`, while still accepting tenant-specific passthrough fields.
+
+## Applies to
+
+Template-derived projects that customize Organization Model branding or read
+`organizationModel.branding.organizationName`, `productName`, or `shortName` directly in
+UI or setup code.
+
+## Required actions
+
+1. Keep existing `branding.organizationName`, `branding.productName`, and
+   `branding.shortName` values in place for compatibility.
+2. Add matching values under `identity.organizationName`, `identity.productName`, and
+   `identity.shortName`.
+3. Update project UI code to read `identity.* ?? branding.*` for display naming.
+4. Move brand expression into the broadened `branding` fields: `voice`, `tagline`,
+   `values`, `themePresetId`, and project-owned passthrough fields as needed.
+
+## Verification
+
+Run the normal template-derived project gates after syncing:
+
+```powershell
+pnpm -C core test
+pnpm -C ui check-types
+pnpm -C ui build
+pnpm -C operations check-types
+pnpm -C operations check
+```
+
+Also open the app shell and Knowledge Base identity/branding views. Confirm display names
+render from identity and branding expression fields render under Branding.
+
+## Not handled by /git-sync
+
+`/git-sync` cannot choose real brand voice, tagline, values, logo assets, or custom
+passthrough fields for an individual tenant. It also cannot remove legacy
+`branding.*` name fields from project-specific code until maintainers confirm every
+consumer has migrated to the identity-first fallback.

package/reference/claude-config/sync-notes/2026-05-23-om-deployment-drift-detection.md

@@ -0,0 +1,42 @@
+# OM Deployment Drift Detection
+
+## Why this note exists
+
+The platform API now persists deployed Organization Model snapshots and validates tenant
+lead-gen and CRM catalogs against the requesting tenant's active deployed model. The
+template does not need source changes for this server-side fix, but template-derived
+projects should accept the `@elevasis/core` package baseline when this release train
+publishes it so generated database and shared type surfaces stay aligned.
+
+## Applies to
+
+Template-derived projects that use SDK deployments, lead-gen list creation, CRM stages,
+or CRM actions through the hosted Elevasis API.
+
+## Required actions
+
+1. Pull the package baseline update produced by this ship train.
+2. Redeploy or verify tenant operations resources if the project has recently changed its
+   Organization Model catalogs.
+3. After the API deployment stage completes, smoke lead-gen list creation with a
+   project-owned build template ID.
+
+## Verification
+
+Run the normal template-derived project gates after syncing:
+
+```powershell
+pnpm -C core test
+pnpm -C operations check-types
+pnpm -C operations check
+pnpm -C ui check-types
+pnpm -C ui build
+```
+
+For projects using lead-gen, also verify list creation against the hosted API with a
+tenant-owned build template ID.
+
+## Not handled by /git-sync
+
+`/git-sync` cannot apply the production database change or deploy the hosted API. It also
+does not create project-specific Organization Model catalogs or workflow resources.