@elevasis/sdk 1.21.0 → 1.22.1

package/reference/claude-config/sync-notes/2026-05-04-knowledge-bundle.md

@@ -1,83 +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.
+# 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-04-template-skills-run-ui-and-tutorial.md

@@ -1,59 +1,59 @@
-# Template Skills: `/run-ui` and `/tutorial`
-
-## Why this note exists
-
-This sync introduces two new template skills and a project-wide tone-block in the always-loaded `agent-start-here` rule:
-
-- **`/run-ui`** -- new skill at `.claude/skills/run-ui/SKILL.md`. One-command path to start the project's Vite dev server on port `4300` in the background. Probes the port, branches on free/own-vite/other-holder, asks before killing a non-vite holder, polls Vite stdout for `Local:` / `ready in`, then surfaces the URL and the background shell ID. Resolves the `strictPort: true` failure mode introduced by the `2026-05-02` WorkOS hardcode train -- before this skill, port collisions were a hard manual debug.
-- **`/tutorial`** -- new skill at `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md`. Persona-aware onboarding that forks at first invocation into a `vibe-coder` track (zero technical vocabulary, agent does all the work) or a `technical` track (full SDK depth, code-first). The choice persists to `.claude/memory/profile.md` and ships a tone block applied project-wide for the rest of every session.
-- **`agent-start-here.md` Project Profile section** -- the always-loaded entrypoint rule now reads `profile.md` at session start and applies the per-track tone block to ALL agent output, not just inside `/tutorial`. This is the load-bearing change that lets `/tutorial` actually flip agent behavior across the whole project.
-
-The project-owned `CLAUDE.md` Slash Commands table has a new `/tutorial` row in the template, but `CLAUDE.md` is verify-only on `/git-sync` -- derived projects own that file and need to add the row themselves if they want it documented.
-
-This sync moves three pieces into derived projects:
-
-- `.claude/skills/run-ui/SKILL.md` -- new file, replace-all surface, lands automatically
-- `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md` -- new files, replace-all surface, lands automatically
-- `.claude/rules/agent-start-here.md` -- replace-all surface, the Project Profile section lands automatically
-
-## Applies to
-
-All template-derived projects. There are no surface preconditions -- the new skills do not depend on a particular org-model shape, feature set, or workspace topology. Operations-only projects with no `ui/` will receive `/run-ui` but it will not be useful in that context (no Vite dev server to launch); leaving it installed is harmless.
-
-`agent-start-here.md` is replace-all: any project that hand-edited that file will lose those local edits on this sync. Run `git diff .claude/rules/agent-start-here.md` after `/git-sync` and re-apply local customizations if needed -- the template version assumes no project-local changes.
-
-## Required actions
-
-1. Pull template changes with `/git-sync` after this train publishes so the new skills and the `agent-start-here.md` Project Profile section reach the project.
-
-2. Optionally run `/tutorial` to set the project's persona track. The first run asks one gate question (`vibe-coder` vs `technical`) and writes the choice to `.claude/memory/profile.md`. Subsequent runs go straight to the menu. If you skip this, the agent behaves normally and prompts you to consider running `/tutorial` only when relevant.
-
-3. If you want the `/tutorial` row visible in the project's own Slash Commands table, manually add a row to `CLAUDE.md` (project-owned, not overwritten by `/git-sync`):
-
-   ```
-   | `/tutorial` | Guided onboarding -- picks one of two tracks (vibe-coder for non-technical users, technical for developers) and walks through the menu interactively |
-   ```
-
-4. If the project hand-edited `.claude/rules/agent-start-here.md` for project-local agent behavior, diff against the new template version and re-apply those edits on top of the new Project Profile section. The replace-all behavior of this file is unchanged from prior trains.
-
-5. Optionally run `/run-ui` at the start of UI work. It is an explicit ask to start the dev server, not an ambient hook -- there is no behavior change unless you invoke it.
-
-## Verification
-
-After upgrading:
-
-- `.claude/skills/run-ui/SKILL.md` exists and is non-empty.
-- `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md` all exist and are non-empty.
-- `.claude/rules/agent-start-here.md` includes a `## Project Profile` section near the top that references `.claude/memory/profile.md` and the `vibe-coder` / `technical` tracks.
-- Running `/run-ui` from a UI-bearing project either starts Vite on `4300` and reports the URL, or detects a port holder and asks before proceeding.
-- Running `/tutorial` for the first time asks the gate question and writes `.claude/memory/profile.md`. Running it a second time skips the question and shows the menu.
-- For a project that ran `/tutorial`: the agent's tone in subsequent (non-`/tutorial`) responses reflects the chosen track per the tone block in `profile.md`. Vibe-coder track: no technical vocabulary, no slash-command surfacing. Technical track: real paths, code-first, no over-explanation.
-
-## Not handled by /git-sync
-
-`/git-sync` does not:
-
-- create or update `.claude/memory/profile.md`. The file is created on first `/tutorial` invocation. If a project never runs `/tutorial`, the agent operates as if no profile exists -- normal default behavior.
-- write the new `/tutorial` row into the project's own `CLAUDE.md` Slash Commands table. `CLAUDE.md` is project-owned (verify-only); the row is a manual edit if the project wants it documented.
-- preserve project-local edits to `.claude/rules/agent-start-here.md`. That file is replace-all. Re-apply local customizations after the sync if any exist.
-- run smoke tests for either skill. The `/tutorial` task doc explicitly defers smoke testing to a fresh-scaffold pass; `/run-ui` is exercised on first user invocation, not via sync verification.
+# Template Skills: `/run-ui` and `/tutorial`
+
+## Why this note exists
+
+This sync introduces two new template skills and a project-wide tone-block in the always-loaded `agent-start-here` rule:
+
+- **`/run-ui`** -- new skill at `.claude/skills/run-ui/SKILL.md`. One-command path to start the project's Vite dev server on port `4300` in the background. Probes the port, branches on free/own-vite/other-holder, asks before killing a non-vite holder, polls Vite stdout for `Local:` / `ready in`, then surfaces the URL and the background shell ID. Resolves the `strictPort: true` failure mode introduced by the `2026-05-02` WorkOS hardcode train -- before this skill, port collisions were a hard manual debug.
+- **`/tutorial`** -- new skill at `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md`. Persona-aware onboarding that forks at first invocation into a `vibe-coder` track (zero technical vocabulary, agent does all the work) or a `technical` track (full SDK depth, code-first). The choice persists to `.claude/memory/profile.md` and ships a tone block applied project-wide for the rest of every session.
+- **`agent-start-here.md` Project Profile section** -- the always-loaded entrypoint rule now reads `profile.md` at session start and applies the per-track tone block to ALL agent output, not just inside `/tutorial`. This is the load-bearing change that lets `/tutorial` actually flip agent behavior across the whole project.
+
+The project-owned `CLAUDE.md` Slash Commands table has a new `/tutorial` row in the template, but `CLAUDE.md` is verify-only on `/git-sync` -- derived projects own that file and need to add the row themselves if they want it documented.
+
+This sync moves three pieces into derived projects:
+
+- `.claude/skills/run-ui/SKILL.md` -- new file, replace-all surface, lands automatically
+- `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md` -- new files, replace-all surface, lands automatically
+- `.claude/rules/agent-start-here.md` -- replace-all surface, the Project Profile section lands automatically
+
+## Applies to
+
+All template-derived projects. There are no surface preconditions -- the new skills do not depend on a particular org-model shape, feature set, or workspace topology. Operations-only projects with no `ui/` will receive `/run-ui` but it will not be useful in that context (no Vite dev server to launch); leaving it installed is harmless.
+
+`agent-start-here.md` is replace-all: any project that hand-edited that file will lose those local edits on this sync. Run `git diff .claude/rules/agent-start-here.md` after `/git-sync` and re-apply local customizations if needed -- the template version assumes no project-local changes.
+
+## Required actions
+
+1. Pull template changes with `/git-sync` after this train publishes so the new skills and the `agent-start-here.md` Project Profile section reach the project.
+
+2. Optionally run `/tutorial` to set the project's persona track. The first run asks one gate question (`vibe-coder` vs `technical`) and writes the choice to `.claude/memory/profile.md`. Subsequent runs go straight to the menu. If you skip this, the agent behaves normally and prompts you to consider running `/tutorial` only when relevant.
+
+3. If you want the `/tutorial` row visible in the project's own Slash Commands table, manually add a row to `CLAUDE.md` (project-owned, not overwritten by `/git-sync`):
+
+   ```
+   | `/tutorial` | Guided onboarding -- picks one of two tracks (vibe-coder for non-technical users, technical for developers) and walks through the menu interactively |
+   ```
+
+4. If the project hand-edited `.claude/rules/agent-start-here.md` for project-local agent behavior, diff against the new template version and re-apply those edits on top of the new Project Profile section. The replace-all behavior of this file is unchanged from prior trains.
+
+5. Optionally run `/run-ui` at the start of UI work. It is an explicit ask to start the dev server, not an ambient hook -- there is no behavior change unless you invoke it.
+
+## Verification
+
+After upgrading:
+
+- `.claude/skills/run-ui/SKILL.md` exists and is non-empty.
+- `.claude/skills/tutorial/{SKILL,vibe-coder,technical,progress-template}.md` all exist and are non-empty.
+- `.claude/rules/agent-start-here.md` includes a `## Project Profile` section near the top that references `.claude/memory/profile.md` and the `vibe-coder` / `technical` tracks.
+- Running `/run-ui` from a UI-bearing project either starts Vite on `4300` and reports the URL, or detects a port holder and asks before proceeding.
+- Running `/tutorial` for the first time asks the gate question and writes `.claude/memory/profile.md`. Running it a second time skips the question and shows the menu.
+- For a project that ran `/tutorial`: the agent's tone in subsequent (non-`/tutorial`) responses reflects the chosen track per the tone block in `profile.md`. Vibe-coder track: no technical vocabulary, no slash-command surfacing. Technical track: real paths, code-first, no over-explanation.
+
+## Not handled by /git-sync
+
+`/git-sync` does not:
+
+- create or update `.claude/memory/profile.md`. The file is created on first `/tutorial` invocation. If a project never runs `/tutorial`, the agent operates as if no profile exists -- normal default behavior.
+- write the new `/tutorial` row into the project's own `CLAUDE.md` Slash Commands table. `CLAUDE.md` is project-owned (verify-only); the row is a manual edit if the project wants it documented.
+- preserve project-local edits to `.claude/rules/agent-start-here.md`. That file is replace-all. Re-apply local customizations after the sync if any exist.
+- run smoke tests for either skill. The `/tutorial` task doc explicitly defers smoke testing to a fresh-scaffold pass; `/run-ui` is exercised on first user invocation, not via sync verification.

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

@@ -1,42 +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.
+# 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

@@ -1,60 +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.
+# 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

@@ -1,37 +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.
+# 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.