@elevasis/sdk 1.16.0 → 1.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.16.0",
+  "version": "1.18.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.16.0",
+    "@repo/core": "0.19.0",
     "@repo/eslint-config": "0.0.0",
     "@repo/typescript-config": "0.0.0"
   },

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)
@@ -156,6 +183,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 +273,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/sync-notes/2026-05-04-knowledge-bundle.md

@@ -0,0 +1,83 @@
+# Knowledge Bundle Ship-Train
+
+## Why this note exists
+
+The Knowledge Map (Browser, CLI, skill, icons, external parity) is being shipped as a coordinated bundle. The Organization Model now treats `knowledge` as a first-class graph domain with `kind`-discriminated nodes (`playbook` / `strategy` / `reference`) connected to features and capabilities through `governs` edges. A new `/knowledge` skill absorbs the prior `/configure` skill as a unified intent-inferring surface (read + describe + codify + toggle); `/configure` is tombstoned via `sync-delete-manifest.json`. A new `knowledge:*` CLI subcommand suite ships on both `elevasis` and `elevasis-sdk` over a shared `@repo/core/knowledge/queries` data layer. The Knowledge Browser is wired into `@elevasis/ui` with reusable primitives (`KnowledgeBrowser`, `KnowledgeTree`, `DescribeNodeView`, `KindChip`, `NodeHeader`, `NodeDescribeShell`, etc.) and a build-time MDX codegen pipeline at `@elevasis/sdk/node`. A unified semantic icon-token catalog lives at `@elevasis/core/organization-model` and is shared across core, SDK, UI, Command Center, and external projects. External-parity work makes the bundle zero-config for tenant projects: a dual-mode Vite plugin walks up to `.elevasis`, runs the two-codegen pipeline in-process, and writes artifacts the published Browser already imports -- no flags, no paths, no recipe steps.
+
+## Applies to
+
+All template-derived projects that consume `@elevasis/sdk`, `@elevasis/core`, or `@elevasis/ui`. Specifically:
+
+- `nirvana-marketing`
+- `ZentaraHQ`
+- Any future external SDK consumer derived from the `_template` baseline
+
+## Required actions
+
+1. Pull template changes with `/git-sync` after this train publishes so the refreshed knowledge wiring (template OM defaults, starter `welcome.mdx`, vite plugin pre-wiring, `/knowledge` skill, `/configure` tombstone, scaffold recipe) reaches the project.
+
+2. **`/configure` is gone.** The skill was absorbed into `/knowledge`. `/git-sync` removes `external/_template/.claude/skills/configure/` (and its 10 operations files) via `sync-delete-manifest.json` (wave: `knowledge-skill`). Update any tenant-side automation, prompts, or docs that still reference `/configure` -- replace with `/knowledge`. The skill is intent-inferring: classify by natural language (read / describe / codify / toggle), not by verb namespace.
+
+3. **`/knowledge` ceremony is unchanged.** The codify ceremony (snapshot -> propose -> confirm -> write -> validate -> rollback) and the two-level model (Level A config-only edits vs. Level B new Zod extension files) are preserved bit-for-bit. The skill body lives at `.claude/skills/knowledge/SKILL.md` (~245 lines) with 10 operations files: `codify-level-a.md`, `codify-level-b.md`, plus 8 domain references (`identity`, `customers`, `offerings`, `roles`, `goals`, `techStack`, `features`, `labels`).
+
+4. **Vite plugin is pre-wired.** `external/_template/ui/vite.config.ts` imports and spreads `elevasisVite()` from `@elevasis/ui/vite`. After `/git-sync`, the plugin auto-discovers the project via `.elevasis` walk-up, runs both knowledge codegens in-process, and writes:
+   - `core/config/knowledge/_generated/nodes.ts`
+   - `core/config/knowledge/_generated/knowledge-bodies.tsx`
+   - `core/config/knowledge/_generated/knowledge-search-index.json`
+
+   Same behavior in `vite dev` and `vite build`. No flags, no manual codegen step required for the bundle to work.
+
+5. **Starter knowledge node lands.** `core/config/knowledge/nodes/welcome.mdx` ships in the template so a fresh clone has a non-empty Browser on first `pnpm -C ui dev`. Replace with tenant-authored MDX nodes as the project codifies real organizational knowledge. Tenant nodes go under `core/config/knowledge/nodes/**/*.mdx` with frontmatter declaring `id`, `kind`, `title`, optional `icon` (semantic token), and an MDX body. Default fallback icons by `kind` apply when `icon` is omitted.
+
+6. **Knowledge baseline propagates to the OM.** `core/config/organization-model.ts` now includes baseline knowledge defaults imported from `@elevasis/core/organization-model`. The merge-aware Tier 2 sync preserves tenant overrides while picking up the baseline. After `/git-sync`, verify `resolveOrganizationModel()` still parses (Zod) and `pnpm -C ui exec tsc --noEmit` passes.
+
+7. **`knowledge:*` CLI subcommands are available.** From inside the project (any subdirectory):
+
+   ```bash
+   pnpm exec elevasis-sdk knowledge:ls /by-feature/sales/crm
+   pnpm exec elevasis-sdk knowledge:ls /by-kind/playbook
+   pnpm exec elevasis-sdk knowledge:cat <node-id>
+   pnpm exec elevasis-sdk knowledge:graph <node-id>
+   ```
+
+   These walk up to `.elevasis`, load the project's OM (with tenant nodes), and print results. Output flags: default text, `--json` envelope, `--ids-only` for piping. The Knowledge Browser sidebar copy buttons emit matching skill-resolvable commands (`/knowledge read <node-id>`, `/knowledge read-folder feature:<id>`, `/knowledge read-folder kind:<kind>`).
+
+8. **Semantic icon tokens replace ad-hoc strings.** When authoring or editing nodes (OM or MDX frontmatter), use semantic tokens from the catalog: `nav.*`, `knowledge.*`, `feature.*`, `resource.*`, `integration.*`, plus `custom.*` namespace for tenant extensions. `IconNameSchema` validates them. The UI renders via Tabler mappings in `@elevasis/ui/icons`; library names (`IconBook`, etc.) stay out of the OM/MDX surface.
+
+9. **Rebuild and type-check:**
+
+   ```bash
+   pnpm install
+   pnpm -C ui build
+   pnpm -C ui exec tsc --noEmit
+   pnpm -C operations exec tsc --noEmit
+   ```
+
+   The first `vite dev` or `vite build` after sync triggers the in-process codegen automatically. To regenerate codegen artifacts manually (one-shot, not normally required):
+
+   ```bash
+   pnpm exec elevasis-sdk knowledge:generate
+   ```
+
+## Verification
+
+After applying all actions above:
+
+- `/configure` skill directory is absent: `external/<project>/.claude/skills/configure/` does not exist after sync.
+- `/knowledge` skill is present at `.claude/skills/knowledge/SKILL.md` with the 10 operations files under `.claude/skills/knowledge/operations/`.
+- `core/config/knowledge/nodes/welcome.mdx` exists; `core/config/knowledge/_generated/` has been populated by the vite plugin (3 files).
+- `pnpm -C ui dev` boots; navigating to `/knowledge` renders the Browser with the welcome node visible in the tree.
+- The 5 mount axes resolve: `/knowledge`, `/knowledge/by-feature/$path`, `/knowledge/by-kind/$kind`, `/knowledge/by-owner/$id`, `/knowledge/graph/$nodeId/governs|governed-by`.
+- `pnpm exec elevasis-sdk knowledge:ls /by-kind/playbook` returns text output without error.
+- `pnpm install` completes cleanly with no unresolved peer warnings.
+- `pnpm -C ui exec tsc --noEmit` passes; `pnpm -C operations exec tsc --noEmit` passes.
+
+## Not handled by /git-sync
+
+`/git-sync` propagates template-authored files (package baselines, `welcome.mdx` starter node, generated `_generated/` files, `/knowledge` skill, `/configure` tombstones, vite.config.ts wiring, scaffold recipe doc) but does NOT:
+
+- Author tenant-specific knowledge MDX nodes. The starter `welcome.mdx` is illustrative; real organizational playbooks, strategies, and reference docs need to be hand-authored under `core/config/knowledge/nodes/**/*.mdx`. Use `/knowledge` for ceremony when codifying.
+- Regenerate `_generated/` artifacts on its own. The vite plugin runs the codegens automatically on next `vite dev` / `vite build`. To regenerate manually before booting, run `pnpm exec elevasis-sdk knowledge:generate`.
+- Migrate references in tenant code from `/configure` to `/knowledge`. Search the project for `/configure` mentions in `.claude/`, `docs/`, `README.md`, prompts, and CI scripts; rewrite to `/knowledge`. The tombstone deletes the skill files but does not edit downstream references.
+- Replace tenant-authored icon strings with semantic tokens. Existing nodes that carried library-specific icon names (`IconBook`, etc.) will continue to render via fallback, but the canonical surface is semantic tokens. Migrate at-touched nodes to `knowledge.*` / `feature.*` / `nav.*` / `custom.*` over time.
+- Clear the Vite module-graph cache (`ui/node_modules/.vite`). After upgrading the bundle, clear this directory manually and restart the dev server before verifying the Browser renders -- stale cache can mask a successful generation.

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-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.