@elevasis/sdk 1.17.0 → 1.19.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.17.0",
+  "version": "1.19.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -57,7 +57,7 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.17.0",
+    "@repo/core": "0.20.0",
     "@repo/eslint-config": "0.0.0",
     "@repo/typescript-config": "0.0.0"
   },

package/reference/claude-config/registries/graph-skills.json

@@ -0,0 +1,4 @@
+{
+  "generatedBy": "generate-knowledge-nodes",
+  "domains": {}
+}

package/reference/claude-config/rules/package-taxonomy.md

@@ -0,0 +1,33 @@
+# Package Taxonomy (Consumer View)
+
+External projects consume the **published `@elevasis/*` surface only**. The Elevasis monorepo also has workspace-internal `@repo/elevasis-*` packages — those are NOT installable here and should never appear in your imports or `package.json`.
+
+## What You Can Import
+
+| Package          | Subpaths                                     | Where it lives in `node_modules` |
+| ---------------- | -------------------------------------------- | -------------------------------- |
+| `@elevasis/sdk`  | default, `/worker`, `/node`, `/test-utils`   | `node_modules/@elevasis/sdk/`    |
+| `@elevasis/ui`   | default, `/auth`, `/initialization`, etc.    | `node_modules/@elevasis/ui/`     |
+| `@elevasis/core` | `/organization-model`, `/entities`, `/utils` | `node_modules/@elevasis/core/`   |
+
+## What You Will See in Monorepo Docs (and should NOT import)
+
+Monorepo source and docs reference `@repo/elevasis-core` and `@repo/elevasis-operations`. These are workspace-internal packages used by Elevasis as a tenant of its own platform. They are `private: true` and never published. If you see them mentioned:
+
+- Do NOT add them to this project's `package.json`
+- Do NOT try to import from them — they are not in your `node_modules`
+- They are not a substitute for `@elevasis/core` even though the name overlaps
+
+## Confused About Where Something Lives?
+
+Check the import path:
+
+- `@elevasis/...` → published, consumable here
+- `@repo/...` → monorepo-internal, not consumable
+
+This project's own org-model and workflows live in `core/config/organization-model.ts` and `operations/src/**` — those are project-owned, not part of either family above.
+
+## References
+
+- `node_modules/@elevasis/sdk/reference/scaffold/index.mdx` — full SDK scaffold reference
+- Monorepo source rule: `.claude/rules/package-taxonomy.md` in the elevasis-monorepo (when working across both)

package/reference/claude-config/rules/vibe.md

@@ -66,6 +66,17 @@ The user wants the agent to explain something -- a scope, an entity, a concept w
 
 **Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Features, and Foundations layers only.
 
+**Stage/state/catalog sub-routing:** when the noun being described is a stage, state, status
+bucket, catalog entry, progress step, pipeline column, or similarly closed business vocabulary,
+also show the cross-system impact before the normal description:
+
+1. Read `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` for the layering pattern.
+2. Read the relevant domain in `foundations/config/organization-model.ts`.
+3. Explain the impact in vibe-coder language only: the business profile entry, the saved progress
+   on each record, the automations that produce updates, and the dashboard or reports that read it.
+4. Route follow-up changes through `/knowledge <domain>`. Do not mention the technical pattern name
+   unless the user explicitly asks for internals.
+
 ### 4. Transition
 
 The user wants to change the status of a task or entity.
@@ -114,6 +125,18 @@ The user describes organizational reality that is not yet expressed in the model
 
 **Agent action:** delegate immediately to `/knowledge`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/knowledge crm` for deal/contact changes, `/knowledge projects` for project types, `/knowledge features` for feature toggles. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/knowledge`.
 
+**Stage/state/catalog impact preview:** if the Codify intent adds, renames, removes, reorders, or
+re-scopes a stage, state, status bucket, catalog member, pipeline step, or progress vocabulary,
+preview the cross-system impact before delegating:
+
+- Which business-profile entry changes.
+- Which saved record progress keys may already exist.
+- Which automations or templates reference the key.
+- Which dashboard, report, queue, or API reads may display or filter by it.
+
+Then delegate to `/knowledge <domain>` with that preview as context. Vibe does not write the
+change and does not expose monorepo-only commands.
+
 This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/knowledge`):
 
 - **Level A** (config-only edits to `organization-model.ts`, feature toggles, label renames): delegate to `/knowledge <domain>` immediately.

package/reference/claude-config/skills/knowledge/SKILL.md

@@ -92,11 +92,38 @@ cannot bypass the write gate.
 | Read     | "what playbooks govern sales.crm?", "show me all reference docs", "list my roles"  | Run CLI read commands (monorepo or external); format result                                                   |
 | Navigate | "what governs this feature?", "where does outreach-cadence apply?"                 | Same CLI; pick mount axis from intent; default to `by-feature` for orientation queries                        |
 | Describe | "what is our identity set to?", "what's our timezone?"                             | Read current values from OM source; narrate                                                                   |
-| Codify   | "we're an e-commerce company", "add a customer segment", "our outreach goal is..." | Run codify ceremony: snapshot -> propose -> confirm -> write -> typecheck -> Zod parse -> rollback on failure |
+| Codify   | "we're an e-commerce company", "add a customer segment", "our outreach goal is..." | Run codify ceremony with shared-layer impact preview: snapshot -> propose -> confirm -> write -> typecheck -> Zod parse -> rollback on failure |
 | Toggle   | "enable the lead-gen feature", "turn off SEO"                                      | Codify ceremony scoped to `features` domain; flip the boolean; same validation/rollback                       |
 
 ---
 
+## Shared Layering Preview
+
+When opening a domain that uses a closed stage, status, or catalog vocabulary -- especially
+prospecting, CRM, outreach, or another pipeline-like domain -- read the scaffold-shipped primer:
+
+```bash
+node_modules/@elevasis/sdk/reference/spine/spine-primer.md
+```
+
+Use it to emit a short domain layering preview before the normal read, describe, or codify flow:
+
+1. **Catalog:** which `organizationModel.<domain>` catalog owns the keys, labels, descriptions,
+   ordering, and entity ownership.
+2. **Runtime state:** where record progress is stored as sparse state keyed by those catalog
+   members.
+3. **Producers:** which templates, automations, or factories write entity-tagged results for those
+   keys.
+4. **Consumers:** which dashboards, queues, reports, filters, or API reads render or aggregate the
+   same keys.
+
+For vibe-coder sessions, translate this into plain language: "business profile", "saved progress",
+"automations", and "dashboard or reports". For technical sessions, it is acceptable to name the
+catalog, state map, producer, and consumer surfaces directly. External tenants route all follow-ups
+through `/knowledge`; do not point them at monorepo-only commands.
+
+---
+
 ## Read Patterns
 
 ### Monorepo (platform defaults)
@@ -104,9 +131,9 @@ cannot bypass the write gate.
 ```bash
 pnpm exec elevasis knowledge:ls
 pnpm exec elevasis knowledge:cat <node-id>
-pnpm exec elevasis knowledge:graph --axis by-feature
-pnpm exec elevasis knowledge:graph --axis by-domain
-pnpm exec elevasis knowledge:graph --mount <mount-id>
+pnpm exec elevasis knowledge:ls /by-feature/<feature-id>
+pnpm exec elevasis knowledge:ls /by-owner/<owner-id>
+pnpm exec elevasis knowledge:graph <node-id>
 ```
 
 ### External projects (org instance)
@@ -114,14 +141,15 @@ pnpm exec elevasis knowledge:graph --mount <mount-id>
 ```bash
 pnpm exec elevasis-sdk knowledge:ls
 pnpm exec elevasis-sdk knowledge:cat <node-id>
-pnpm exec elevasis-sdk knowledge:graph --axis by-feature
-pnpm exec elevasis-sdk knowledge:graph --axis by-domain
-pnpm exec elevasis-sdk knowledge:graph --mount <mount-id>
+pnpm exec elevasis-sdk knowledge:ls /by-feature/<feature-id>
+pnpm exec elevasis-sdk knowledge:ls /by-owner/<owner-id>
+pnpm exec elevasis-sdk knowledge:graph <node-id>
 ```
 
 Use `knowledge:ls` to enumerate all knowledge nodes. Use `knowledge:cat` to read a specific
-node's content. Use `knowledge:graph` to navigate the governance graph -- `by-feature` is the
-default axis for "what governs X?" queries; `by-domain` for domain-wide surveys.
+node's content. Use `knowledge:ls /by-feature/<feature-id>` or
+`knowledge:ls /by-owner/<owner-id>` to navigate feature and owner groupings. Use
+`knowledge:graph <node-id>` to inspect incoming and outgoing graph edges for a specific node.
 
 ### `/knowledge read-folder` (chat shorthand from the Knowledge Browser)
 
@@ -156,6 +184,12 @@ Read `foundations/config/organization-model.ts` (external) or the appropriate pl
 Show the diff in chat. Identify which domain and field changes. Present the proposed new value
 in context alongside the current value.
 
+For stage, status, or catalog vocabulary edits, include the shared-layer impact preview before
+asking for confirmation. Name the affected catalog key, whether existing sparse runtime state may
+contain the old key, which producers/templates reference it, and which consumers render or filter by
+it. If the impact cannot be determined from the local project, say which surface is unknown and keep
+the write gated.
+
 ### Step 3: Confirm
 
 Pause for explicit user confirmation. Do not proceed without a clear yes. Permission prompts
@@ -240,13 +274,12 @@ Cross-link: `.claude/skills/knowledge/SKILL.md` (monorepo pointer)
 
 ## Cross-Links
 
-- `/org-os` -- Organization OS architecture overview, seven layers, propagation pipeline,
-  feature/surface management. Use `/org-os` when the question is about the architecture or
-  propagation system rather than reading or editing org-model values. Cross-link:
-  `.claude/skills/org-os/SKILL.md`
 - `/configure` -- Legacy org-model editor (pre-absorption). Absorbed into this skill; all
   Codify and Toggle intents now route here. `/configure` vocabulary still works as a domain
   hint (e.g., "configure identity" is parsed as domain=identity, intent=Describe-or-Codify).
+- `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` -- Scaffold-shipped layering
+  primer for stage/status/catalog vocabularies that coordinate business-profile entries, runtime
+  progress, producers, and consumers in tenant projects.
 
 ---
 

package/reference/claude-config/skills/project/SKILL.md

@@ -399,6 +399,27 @@ Recent Notes
   2026-04-01 [call_note] Kickoff — confirmed scope and timeline
 ```
 
+#### Tenant Skill Bindings Footer
+
+After the normal status output, append a short footer when the project kind, tags, name,
+description, milestones, or active tasks map to a known tenant domain such as `prospecting`,
+`crm`, `outreach`, `finance`, or `support`.
+
+Resolve the best domain from explicit metadata first (`tags`, `kind`, domain fields), then from
+project/task text. If no clear domain maps, omit the footer.
+
+Footer shape:
+
+```text
+Related skill bindings
+- Domain: <domain>
+- Read or change business profile: /knowledge <domain>
+- Layering primer: node_modules/@elevasis/sdk/reference/spine/spine-primer.md
+```
+
+External projects do not expose monorepo-only architecture commands. Never suggest `/org-os`,
+`/om-spine`, or monorepo paths in this footer.
+
 ### `create` — Guided Project Creation (QnA Flow)
 
 Interactive walkthrough that collects project details step by step using `AskUserQuestion`,

package/reference/claude-config/skills/tutorial/SKILL.md

@@ -29,6 +29,15 @@ This router does not enforce that tone -- it only writes profile.md and loads th
 file. The project-wide tone effect is handled by the rules layer reading profile.md on each
 session start.
 
+Track separation is explicit:
+
+- The vibe-coder track teaches the underlying coordination idea through business language only:
+  business profile, saved progress, automations, dashboard, and reports. Do not name the technical
+  pattern in vibe-coder menus, lessons, prompts, or progress labels.
+- The technical track may name OM spine vocabulary and can point developers at
+  `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` when lessons discuss shared stage,
+  status, or catalog vocabularies.
+
 ---
 
 ## Step 1: Parse the Argument
@@ -111,8 +120,9 @@ In this project, always:
 
 ## Tone Implications
 
-Code-first communication. Use current command names and SDK terminology without hand-holding.
-No vocabulary substitutions. Slash commands may be surfaced directly. Full technical depth.
+Code-first communication. Use current command names, SDK terminology, and OM spine vocabulary
+without hand-holding. No vocabulary substitutions. Slash commands may be surfaced directly. Full
+technical depth.
 ```
 
 ### Initialize Progress File
@@ -156,7 +166,7 @@ Read `.claude/memory/tutorial-progress.md`.
 - [ ] 15 Error handling
 - [ ] 16 LLM and agents
 - [ ] 17 Composition
-- [ ] 18 Rules, memory, scaffold registry
+- [ ] 18 Rules, memory, scaffold registry, OM spine
 - [ ] 19 Template lifecycle and /git-sync
 ```
 

package/reference/claude-config/skills/tutorial/technical.md

@@ -570,12 +570,12 @@ the user what happens if they omit the `default` route (runtime failure for unma
 
 ### Item 8: Going to production
 
-**Goal:** The user knows the dev/prod split, version bumping flags, and the `cli-cwd-invariant`
-rule for `--prod` flag placement.
+**Goal:** The user knows the dev/prod split, version bumping flags, and the SDK CLI CWD
+guidance in the deployment rule.
 
 **Estimated time:** 15 min
 
-**Files referenced:** `.claude/rules/deployment.md`, `.claude/rules/cli-cwd-invariant.md`
+**Files referenced:** `.claude/rules/deployment.md`
 
 **Commands:** `pnpm -C operations deploy:prod`
 
@@ -606,19 +606,17 @@ pnpm elevasis-sdk deploy --prod --major   # 1.0.0 -> 2.0.0
 Bump rules: `--patch` for bug fixes, `--minor` for new features (no breaking schema changes),
 `--major` for breaking input/output schema changes.
 
-**The `cli-cwd-invariant`.** Read `.claude/rules/cli-cwd-invariant.md`. Two critical rules:
+**SDK CLI CWD guidance.** Read `.claude/rules/deployment.md`. Two critical rules:
 
-1. The `--prod` flag on the `elevasis-sdk` binary MUST come before the subcommand name:
+1. The `--prod` flag belongs to the `deploy` command:
 
    ```bash
    # Correct
-   pnpm elevasis-sdk --prod deploy
-   # Wrong -- --prod after deploy is silently ignored
    pnpm elevasis-sdk deploy --prod
    ```
 
    The `pnpm -C operations deploy:prod` script in `package.json` handles this correctly.
-   Prefer the script over a raw CLI call to avoid the pitfall.
+   Prefer the script over a raw CLI call for production deploys.
 
 2. Never use bare `cd <dir> && elevasis-sdk ...` -- use a subshell `(cd <dir> && ...)` or
    `pnpm -C <dir> ...` to avoid CWD drift that causes env resolution failures.

package/reference/claude-config/sync-notes/2026-05-05-list-builder.md

@@ -0,0 +1,42 @@
+# 2026-05-05 — List Builder UX + Schema-Driven Step Config
+
+## Why this note exists
+
+The list-builder ship train publishes a coordinated `@elevasis/core` + `@elevasis/ui` release that:
+
+- Replaces every per-integration bespoke step-config component (and the `SerializedExecutionFormSchema` middle tier) with one generic `<StepConfigForm>` driven by the workflow's `contract.inputSchema` (Zod) plus a small `StepConfigLayout` hints object per integration.
+- Standardizes the BuildTab step-detail right column on a `Configuration | Advanced | Runs` tab shell (`StepDetailRightColumn`).
+- Makes `schema + layout` REQUIRED on `ListBuilderWorkflow`. The legacy `configSchema?` / `ConfigurationFields?` / `AdvancedFields?` / `inputForm?` fields are gone.
+- Removes several `@elevasis/core` execution-form types (`SerializedFormField`, `SerializedFormSchema`, `SerializedExecutionFormSchema`, `SerializedExecutionInterface`, `ExecutionRunnerCatalogItem`, `ExecutionRunnerCatalogResponse`, plus `interface?` from definition types), the `ResourceExecuteForm` / `ResourceExecuteDialog` / `ExecutionRunner` surfaces from `@elevasis/ui`, and the API `execution/runner/` runtime.
+
+If a derived project authors its own list-builder step actions or imported any of the deleted types, it will not compile against the new `@elevasis/ui` / `@elevasis/core` baselines without the migration below.
+
+## Applies to
+
+- All template-derived projects whose `ui/` consumes `@elevasis/ui` and registers list-builder actions.
+- Any project whose `core/` or `operations/` imports the removed execution-form types from `@elevasis/core`.
+- Any project rendering the list-builder Build tab via `LeadGenListDetailPage` or its `RunWorkflowModal`.
+
+## Required actions
+
+1. Bump `@elevasis/core` and `@elevasis/ui` to the versions published by this train (see `external/_template/{core,ui}/package.json` baselines).
+2. For every `ListBuilderWorkflow` registry entry the project authors locally, swap to the `schema + layout` contract:
+   - Add a browser-safe sibling schema export (split-file pattern: keep Node-only deps out of `ui/`).
+   - Provide a `StepConfigLayout<T>` describing field hints (no React, no validation logic).
+   - Drop any `ConfigurationFields` / `AdvancedFields` / `configSchema` / `inputForm` references.
+3. Delete any imports of the removed core types: `SerializedFormField`, `SerializedFormSchema`, `SerializedExecutionFormSchema`, `SerializedExecutionInterface`, `ExecutionRunnerCatalogItem`, `ExecutionRunnerCatalogResponse`, and the `interface?` field on workflow definitions.
+4. If the project rendered the deleted `ResourceExecuteForm` / `ResourceExecuteDialog` / `ExecutionRunner` surfaces, replace with `<StepConfigForm>` (curated UX) or `<ZodFormRenderer>` (auto-derived from Zod) as appropriate. `renderExecuteDialog` is now REQUIRED on `ResourceDetailPage`.
+5. Re-run `pnpm -C ui check-types` and `pnpm -C operations check-types` to confirm the schema sibling files resolve and no removed types remain referenced.
+
+## Verification
+
+- `pnpm -C ui check-types` — no references to `SerializedFormField`, `SerializedExecutionFormSchema`, `ResourceExecuteForm`, etc.
+- `pnpm -C ui build` — clean build with the new `@elevasis/ui` baseline.
+- `pnpm -C operations check` and `check-types` — clean.
+- BuildTab smoke (manual): open a list under `/lead-gen/lists/{listId}`, select a step, confirm the right column renders the `Configuration | Advanced | Runs` tabs and the schema-driven form (defaults populate, validation Alert fires + clears on edit, conditional `when:` predicates toggle, `recentRuns[0]` auto-load works).
+
+## Not handled by /git-sync
+
+- Project-authored `ListBuilderWorkflow` registrations are project-owned code; `/git-sync` does not migrate them. Each project must port its action entries to `schema + layout` by hand following the `apolloImportLayout` pattern in the template's `apps/command-center/src/main.tsx`.
+- Browser dev-smoke for each migrated step type is operator-driven; not automatable through sync.
+- Any local re-implementations or extensions of the deleted `ResourceExecuteForm` / `ExecutionRunner` surfaces must be removed manually before this baseline can be adopted.

package/reference/claude-config/sync-notes/2026-05-06-crm-spine.md

@@ -0,0 +1,60 @@
+# 2026-05-06 -- CRM OM Spine Migration
+
+## Why this note exists
+
+The CRM deal vocabulary (`stage_key`, `state_key`, `pipeline_key`) is now a fully-realized OM Spine matching the lead-gen list-builder pattern. `CRM_PIPELINE_DEFINITION` becomes the single source of truth: `@elevasis/core` derives `CrmStageKeySchema` and `CrmStateKeySchema` from the catalog, the catalog gains optional `color?` metadata on each stage, and `@elevasis/sdk` re-exports both schemas plus the catalog so external SDK consumers see the same vocabulary as monorepo callers. `@elevasis/ui` rewires the CRM page helpers (`DEAL_STAGE_COLORS`, `DEAL_STAGE_OPTIONS`, `formatDealStageLabel`, `formatDealStateLabel`) to read from the catalog instead of hardcoded maps -- public exports are preserved, behavior is now catalog-driven.
+
+The platform side also closed a long-standing data drift: `pipeline_key='default'` in `acq_deals` is gone; live writers now use `pipeline_key='crm'` matching the catalog's `pipelineKey: 'crm'`. The Elevasis backfill applied directly to prod and dev on 2026-05-06; tenant deal rows are not affected by that backfill and continue to use whatever value tenant code wrote.
+
+## Applies to
+
+- All template-derived projects that consume `@elevasis/core`, `@elevasis/ui`, or `@elevasis/sdk`.
+- Projects that customize CRM stages or states in `core/config/organization-model.ts` under the `sales` domain.
+- Projects that read or write CRM transitions through `@elevasis/sdk` worker adapters (`acqDb.transitionDeal`, `acqDb.transitionItem`).
+- Projects that render CRM pipeline UI from `@elevasis/ui/features/crm`.
+
+## Required actions
+
+1. Pull synced template package baselines through `/git-sync`:
+   - `core/package.json`: `@elevasis/core` -> 0.20.0
+   - `ui/package.json`: `@elevasis/ui` -> 2.29.0
+   - `operations/package.json`: `@elevasis/core` -> 0.20.0 and `@elevasis/sdk` -> 1.19.0
+
+2. Run `pnpm install` and rebuild the project:
+
+   ```bash
+   pnpm install
+   pnpm -C ui build
+   pnpm -C ui exec tsc --noEmit
+   pnpm -C operations exec tsc --noEmit
+   ```
+
+3. **Optional: adopt `color?` on customized CRM stages.** If `core/config/organization-model.ts` overrides `sales.stages` with custom labels, you may now add an optional `color` field per stage (any Mantine palette key: `blue`, `yellow`, `orange`, `green`, `red`, `grape`, etc.). The shipped `DEAL_STAGE_COLORS` map and CRM kanban UI will read it. Stages without a `color` fall back to the platform default mapping in the catalog.
+
+4. **Optional: tighten project-owned CRM workflow inputs.** New schemas are available from `@elevasis/sdk`:
+
+   ```ts
+   import { CrmStageKeySchema, CrmStateKeySchema, CRM_PIPELINE_DEFINITION } from '@elevasis/sdk'
+   ```
+
+   Project-authored CRM action workflows that previously used `z.string()` for `toStage` / `toState` can now validate against the catalog-derived enum. The `transitionItem` / `transitionDeal` worker adapters still accept strings, but unknown stage/state keys are rejected at the platform writer layer for `pipelineKey: 'crm'` writers.
+
+5. **No tenant data backfill required.** The `pipeline_key='default'` -> `'crm'` backfill was applied to Elevasis databases only. Tenant `acq_deals` rows are unaffected. If tenant code writes `pipelineKey: 'default'` to `acqDb.transitionDeal`, that behavior is unchanged; only the published catalog declares `'crm'` as canonical and the published schemas validate `'crm'` exclusively for CRM-shaped transitions.
+
+## Verification
+
+After applying the actions above:
+
+- `pnpm -C ui check-types`
+- `pnpm -C ui build`
+- `pnpm -C ui test`
+- `pnpm -C operations check`
+- `pnpm -C operations check-types`
+- `pnpm -C operations test`
+- Browser smoke: open `/crm/pipeline` (or the project's CRM kanban surface) and verify stage labels and column colors render from the catalog. Custom-labeled stages should show the override label; default stages show the platform palette.
+
+## Not handled by /git-sync
+
+- **Tenant CRM action workflows.** If a project authored its own CRM action workflows in `operations/` that import `transitionDeal` / `syncDealStateKeyToDb` directly (rather than `emitCrmTransition`), `/git-sync` does NOT refactor them. The platform-side `emitCrmTransition` factory is internal to `@repo/elevasis-operations` (workspace-internal) and is not part of the published SDK surface. Project-owned workflows continue to call the worker adapters directly; the new validation guard rejects unknown stage/state keys but does not require migration.
+- **Customized stage colors.** Existing tenant overrides under `sales.stages[].label` and `sales.stages[].states[]` continue to work unchanged. Adopting the new optional `color` field is a project-by-project decision; `/git-sync` will not infer colors for custom stages.
+- **`pipeline_key` data in tenant databases.** If a project has historic `acq_deals` rows with `pipeline_key='default'` and wants to align with the new canonical `'crm'` identity, that is a tenant-managed migration -- not part of this train.

package/reference/claude-config/sync-notes/2026-05-06-sdk-changes-release-train.md

@@ -0,0 +1,37 @@
+# 2026-05-06 -- SDK Changes Release Train
+
+## Why this note exists
+
+This train coordinates the Google Calendar integration, list-builder OM Spine cleanup, and OM Spine documentation/skill surfaces into one package and external-sync release. It publishes updated `@elevasis/core`, `@elevasis/ui`, and `@elevasis/sdk` baselines, then syncs template Claude guidance and package versions to derived projects.
+
+## Applies to
+
+- Template-derived projects consuming `@elevasis/core`, `@elevasis/ui`, or `@elevasis/sdk`.
+- Projects using the list-builder workflow factory or custom lead-gen build-state UI.
+- Projects relying on tenant Claude guidance for `/knowledge`, `/project`, `/tutorial`, or ambient `vibe` behavior.
+
+## Required actions
+
+1. Pull the synced template changes through `/git-sync`.
+2. Accept the package baseline bumps published by this train:
+   - `core/package.json`: `@elevasis/core`
+   - `ui/package.json`: `@elevasis/ui`
+   - `operations/package.json`: `@elevasis/core` and `@elevasis/sdk`
+3. Review local list-builder customizations against the OM-owned stage vocabulary and SDK `listBuilderWorkflow(...)` factory.
+4. Review any local tenant guidance overrides before accepting the synced `.claude/rules/vibe.md` and `.claude/skills/{knowledge,project,tutorial}/SKILL.md` changes.
+
+## Verification
+
+- `pnpm -C ui check-types`
+- `pnpm -C ui build`
+- `pnpm -C ui test`
+- `pnpm -C operations check`
+- `pnpm -C operations check-types`
+- `pnpm -C operations test`
+- `pnpm -C core test`
+
+## Not handled by /git-sync
+
+- Project-authored list-builder workflow registrations remain project-owned code.
+- Google Calendar OAuth configuration remains an Elevasis platform/admin responsibility, not a tenant scaffold migration.
+- Manual browser smoke for authenticated calendar views is not automated by template sync.