@elevasis/sdk 1.44.3 → 1.46.0

package/reference/claude-config/sync-notes/2026-05-09-resource-governance-and-misc.md

@@ -1,69 +0,0 @@
-# Resource Governance Runtime + CRM Detail Pages + Service-Context Rename
-
-## Why this note exists
-
-The 2026-05-09 release train extends the clients-domain ship with three additional bodies of work that affect template-derived projects:
-
-1. **Resource Governance runtime cutover.** The shared resource-governance validator now defaults to **strict** mode. The OM Resources/Systems descriptor catalog is the source of truth for resource identity. Operations bundles must bind workflows, agents, and integrations to descriptors via `defineResource(s)` + descriptor binding helpers; raw `resourceId` literals in `DeploymentSpec` no longer pass strict validation.
-2. **CRM detail-page surface expansion.** `@elevasis/ui` now publishes `ContactDetailPage` (new) and `CompanyDetailPage` (now exported from `sdk-barrel`) under `@elevasis/ui/features/crm`. The lead-gen flow no longer renders detail modals on row click — both pages are reached via TanStack Router routes (`/crm/contacts/$contactId`, `/crm/companies/$companyId`). The legacy `CompanyDetailModal` and `ContactDetailModal` exports were removed from `@elevasis/ui/features/lead-gen/shared`.
-3. **`ElevasisServiceContext` field rename.** `useElevasisServices().organizationId` is renamed to `useElevasisServices().workOSOrganizationId` to make the WorkOS-vs-Supabase distinction loud at call sites. The old `organizationId` field is preserved as a back-compat alias on both `ElevasisServiceContextValue` and `ElevasisServiceProviderProps` for one release cycle, so existing template consumers continue to work without immediate migration.
-
-Companion items already covered elsewhere:
-
-- Scaffold/agent guidance for descriptor-first authoring → see `2026-05-08-resource-governance-scaffold-guidance.md`.
-- Clients domain (new sidebar pillar, write operations, project/client linkage) → see `2026-05-09-clients-domain.md`.
-
-## Applies to
-
-Any template-derived project (e.g. `nirvana-marketing`, `ZentaraHQ`) that:
-
-- Deploys workflows, agents, or integrations through `operations/src/index.ts` (resource-governance validator).
-- Renders contacts/companies in any feature surface, including custom CRM views (CRM detail pages + modal removal).
-- Uses `useElevasisServices()` from `@elevasis/ui` in custom hooks, components, or test fixtures (service-context rename).
-
-## Required actions
-
-### 1. Resource Governance — descriptor-backed deployment
-
-- Confirm `core/config/organization-model.ts` declares your tenant's resources in the id-keyed `organizationModel.resources` map (single-author resource IDs).
-- In `operations/src/index.ts`, bind your workflow/agent/integration definitions to those descriptors via the helpers exported from `@elevasis/sdk` instead of authoring raw `resourceId` strings inline in `DeploymentSpec`.
-- Run `pnpm -C operations check`. The default validator mode is now strict; missing descriptors, raw-ID authoring, runtime/OM type mismatches, and missing Systems will fail the build. Set `ELEVASIS_RESOURCE_VALIDATOR=warn-only` only as a temporary emergency escape hatch — do not let normal CI silently depend on it.
-- New SDK CLI commands are available: `elevasis-sdk agent:list`, `elevasis-sdk agent:get \<id>`, `elevasis-sdk session:list`, `elevasis-sdk session:get \<id>`, `elevasis-sdk session:end \<id>`. Existing `resources` / `describe` / `exec` / `executions` / `execution` are unchanged.
-
-### 2. CRM detail pages
-
-- If your project imports `CompanyDetailModal` or `ContactDetailModal` from `@elevasis/ui/features/lead-gen/shared`, those exports were removed. Replace modal-on-row-click patterns with `useNavigate` to `/crm/contacts/$contactId` or `/crm/companies/$companyId`.
-- If you need detail-page UI in custom routes, import `ContactDetailPage` and `CompanyDetailPage` from `@elevasis/ui/features/crm`. Both are part of the published `sdk-barrel` and accept `contactId` / `companyId` props.
-- The `extend-lead-gen.md` recipe in `node_modules/@elevasis/sdk/reference/scaffold/recipes/` was updated — it no longer documents the modal helpers.
-
-### 3. `workOSOrganizationId` field rename
-
-- New idiomatic destructure: `const { apiRequest, workOSOrganizationId, isReady } = useElevasisServices()`.
-- The old `organizationId` field still resolves correctly through the back-compat alias, so existing template code compiles and runs without changes. New code in this project should use `workOSOrganizationId`.
-- If your project uses `<ElevasisServiceProvider organizationId={...}>`, that prop also accepts both names. Provider's resolver is `workOSOrganizationId ?? organizationId ?? null` — passing both names is supported but unnecessary.
-- For test fixtures that mock `useElevasisServices` via `vi.mock`, return `workOSOrganizationId` rather than `organizationId` when authoring NEW mocks; existing mocks will continue to work via the alias but should be migrated opportunistically. The runtime trap is: `vi.mock(...)` is untyped — TypeScript will not catch a mock that returns the deprecated key, but the resolver bypass means downstream `services.workOSOrganizationId` reads `undefined`.
-
-## Verification
-
-After reconciling local project guidance and writing any descriptor / service-context updates:
-
-```bash
-pnpm -C operations check
-pnpm -C operations check-types
-pnpm -C ui check-types
-pnpm -C ui test
-```
-
-If your project deploys to production and you author runtime resources directly:
-
-```bash
-pnpm -C operations exec elevasis-sdk deploy
-```
-
-Expect strict-mode validator output. Investigate any "OM resource missing for code resource" or "raw resourceId authoring detected" errors as descriptor-binding work, not as test bypass.
-
-## Not handled by /git-sync
-
-- `/git-sync` pulls the new `@elevasis/sdk`, `@elevasis/ui`, and `@elevasis/core` versions and template-owned files, but it does **not** rewrite existing project-owned `operations/src/**` workflow/agent/integration files to use descriptor-backed binding. Maintainers must migrate raw `resourceId` literals to descriptor lookups intentionally.
-- `/git-sync` does **not** rewrite custom UI routes that import `CompanyDetailModal` / `ContactDetailModal` from `@elevasis/ui/features/lead-gen/shared`. Replace those imports with `useNavigate` to detail-page routes manually.
-- `/git-sync` does **not** rename `useElevasisServices().organizationId` reads in project-owned code. The back-compat alias keeps existing code working; proactive renaming is a manual cleanup.

package/reference/claude-config/sync-notes/2026-05-12-sdk-ready-release-train.md

@@ -1,30 +0,0 @@
-# SDK Ready Release Train
-
-## Why this note exists
-
-This release train carries SDK CLI, Organization OS/Knowledge scaffold, shared UI, and external template guidance changes from the monorepo into template-derived projects. Downstream projects need an operative sync note because the train includes `external/_template/.claude/**`, package baseline cascades, and generated/reference surfaces that are not handled by ordinary git merge alone.
-
-## Applies to
-
-- Template-derived external projects, including `external/ZentaraHQ` when its local worktree is ready for reconciliation.
-- Managed Claude skill/rule/registry surfaces under `.claude/**`.
-- Package dependency baselines for `@elevasis/core`, `@elevasis/ui`, and `@elevasis/sdk` after the publish stages complete.
-
-## Required actions
-
-- Run the prepared `/external sync --all` scope from `_external-sync-prep.json` after `/sdk ship` completes publish and deploy stages.
-- Preserve project-owned files such as tenant `CLAUDE.md`, operations runtime code, and knowledge nodes unless the sync manifest marks a path as managed.
-- Reconcile dirty tenant worktrees before applying managed `.claude` skill/rule writes.
-
-## Verification
-
-- Run the external sync planner/verify flow for each target project before applying writes.
-- Confirm queue, schedule, note, Knowledge, and Organization OS guidance renders in the downstream `.claude` command/skill surfaces.
-- Regenerate downstream knowledge/scaffold artifacts where the sync report requires generated freshness.
-
-## Not handled by /git-sync
-
-- Publishing `@elevasis/core`, `@elevasis/ui`, or `@elevasis/sdk`.
-- Deploying the SDK resources bundle.
-- Tenant-specific conflict resolution in dirty external project repositories.
-- Manual review of project-owned `CLAUDE.md`, operations source, and knowledge content.

package/reference/claude-config/sync-notes/2026-05-14-organization-model-ontology-refactor.md

@@ -1,45 +0,0 @@
-# Organization Model Ontology Refactor
-
-## Why this note exists
-
-The template now demonstrates the Organization Model ontology and topology bridge. New semantic contracts should be authored in `System.ontology`; executable Resources bind through `resource.ontology.actions` and optional `resource.ontology.primaryAction`; durable operational wiring belongs in `organizationModel.topology.relationships`. Legacy `entities`, `actions`, and `System.content` remain compatibility mirrors for current consumers.
-
-## Applies to
-
-- `core/config/organization-model.ts`
-- `core/config/organization-model.test.ts`
-- `core/config/organization-model.contract.test.ts`
-- `core/config/README.md`
-- `operations/src/index.ts`
-- `operations/src/resource-registry.test.ts`
-- `operations/src/README.md`
-- `.claude/rules/organization-model.md`
-- `.claude/rules/operations.md`
-
-## Required actions
-
-1. Preserve system-colocated ontology scopes when syncing template organization-model changes.
-2. Migrate Resource descriptors from `ontology.implements` / `actionKey` to `ontology.actions` / `ontology.primaryAction`; keep `codeRefs` with the Resource descriptor.
-3. Preserve `organizationModel.topology.relationships` when syncing template organization-model changes; keep secrets, credential values, provider webhook mechanics, and per-run state outside the OM.
-4. Keep `entities`, `actions`, and `System.content` aligned as compatibility mirrors until downstream consumers move fully to compiled ontology indexes.
-5. Do not overwrite project-owned `core/config/extensions/**` files.
-
-## Verification
-
-Run the template verification lane after applying this sync:
-
-```bash
-pnpm -C external/_template/core test
-pnpm -C external/_template/core exec tsc --noEmit
-pnpm -C external/_template/operations check
-pnpm -C external/_template/operations check-types
-pnpm -C external/_template/operations test
-pnpm sync:verify --pre
-```
-
-## Not handled by /git-sync
-
-- Choosing project-specific ontology IDs for tenant-owned systems.
-- Choosing project-specific topology relationships for tenant-owned workflows, checkpoints, integrations, or schedules.
-- Migrating project-owned extension files under `core/config/extensions/**`.
-- Retiring compatibility mirrors before the full internal, SDK, scaffold, and external template-family green cycle.

package/reference/claude-config/sync-notes/2026-05-15-om-skill-rename-and-write-family.md

@@ -1,52 +0,0 @@
-# OM Skill Rename + Write Family Release Train
-
-## Why this note exists
-
-This release train renames the tenant `/knowledge` skill to `/om` and broadens it, ports `om:search` / `om:describe` to the `elevasis-sdk` CLI, and bumps the `@elevasis/core` and `@elevasis/sdk` dependency baselines. The template `.claude` skill surface changed shape (a directory was renamed and slash-command references were rewritten across CLAUDE.md, rules, and adjacent skills), and `@elevasis/core` / `@elevasis/sdk` published new exports and CLI commands. Ordinary git merge does not reconcile a managed `.claude` skill rename or pull republished package baselines, so template-derived projects need an operative note.
-
-This note covers the `om-skill` workstream (the `/knowledge` -> `/om` rename + SDK CLI port) and the package-baseline cascades from the same train (`@elevasis/core` minor from `om-skill` + `om-create-skill`; `@elevasis/sdk` minor from `om-skill`). It does NOT cover the unrelated Shared-UI-Migration changes under `external/_template/ui/**`, which are a separate workstream and not part of this train.
-
-## Applies to
-
-- `external/_template/.claude/skills/om/SKILL.md` (renamed from `external/_template/.claude/skills/knowledge/SKILL.md`; canonical 5-bucket decision tree with the tenant Codify/Toggle ceremony preserved)
-- `external/_template/.claude/skills/om/operations/*.md` (10 files moved from `knowledge/operations/`; `elevasis-sdk knowledge:*` references rewritten to `elevasis-sdk om:*`, `/knowledge` footers rewritten to `/om`)
-- `external/_template/.claude/skills/knowledge/` (DELETED — directory removed; tombstone, do not re-create on sync)
-- `external/_template/CLAUDE.md` (Slash Commands table — `/knowledge` -> `/om`)
-- `external/_template/.claude/rules/{organization-model,organization-os,vibe}.md` (slash-command references)
-- `external/_template/.claude/skills/{setup,project,tutorial}/*.md` (slash-command references)
-- `external/_template/core/package.json` (`@elevasis/core` baseline -> 0.25.0)
-- `external/_template/operations/package.json` (`@elevasis/core` -> 0.25.0 and `@elevasis/sdk` -> 1.23.0 baselines)
-
-Package baselines become concrete only after the `core` and `sdk` publish stages of `/sdk ship` complete; the `.claude` skill rename is template-authored and already present in `external/_template`.
-
-## Required actions
-
-1. Apply the managed `.claude` skill rename atomically: create `.claude/skills/om/` (SKILL.md + `operations/`) and delete the former knowledge skill directory in the same sync. Never leave both directories present — two skills advertising the same scope is the exact confusion the rename removes.
-2. Preserve any tenant-owned Codify/Toggle ceremony content in the project's `om/SKILL.md` Write-Power section; do not overwrite project-authored knowledge node content under `core/config/knowledge/**` (the content directory is separate from the slash-command name).
-3. Rewrite `/knowledge` -> `/om` and `elevasis-sdk knowledge:*` -> `elevasis-sdk om:*` references in managed surfaces only; `knowledge:*` CLI aliases remain valid, so do not hard-fail on legacy invocations in project-owned files.
-4. After the `/sdk ship` publish stages land, bump the `@elevasis/core` (0.25.0) and `@elevasis/sdk` (1.23.0) baselines in `core/package.json` and `operations/package.json`, then reinstall.
-5. The `/om` write sub-skill family (`verify` / `create` / `rename` / `deprecate`) is intentionally NOT ported to the tenant template in this train (deferred to a dedicated task). Do not scaffold those tenant operations from this sync.
-
-## Verification
-
-Run the template verification lane after applying this sync:
-
-```bash
-pnpm sync:verify --pre
-pnpm external:verify
-pnpm -C external/_template/operations check-types
-pnpm -C external/_template/operations test
-```
-
-Then confirm in each downstream project:
-
-- `.claude/skills/om/` exists with `SKILL.md` + `operations/`; the former knowledge skill directory is gone.
-- `elevasis-sdk om:search "<query>"` and `elevasis-sdk om:describe <id>` resolve against the tenant's organization model; legacy `elevasis-sdk knowledge:*` still aliases.
-- `@elevasis/core` resolves to >= 0.25.0 and `@elevasis/sdk` to >= 1.23.0.
-
-## Not handled by /git-sync
-
-- Publishing `@elevasis/core` (0.25.0) or `@elevasis/sdk` (1.23.0) — owned by `/sdk ship` publish stages.
-- Redeploying the SDK resources bundle (`elevasis-operations`) after the `@elevasis/sdk` publish.
-- Tenant-specific conflict resolution in dirty external project worktrees, including reconciling any project-authored edits to the former `knowledge/SKILL.md`.
-- The unrelated Shared-UI-Migration changes under `external/_template/ui/**` (separate workstream; not in this train's scope).

package/reference/claude-config/sync-notes/2026-05-17-sdk-boundary-consolidation.md

@@ -1,33 +0,0 @@
-# SDK Boundary Consolidation Release Train
-
-## Why this note exists
-
-This train publishes the SDK boundary consolidation work and updates the template to consume more of the published Elevasis SDK family instead of carrying local boilerplate. It also carries the Organization Model bridge retirement and typed-contract hardening that the ship train depends on.
-
-## Applies to
-
-- Template UI shells derived from `external/_template/ui`.
-- Template operations packages that depend on `@elevasis/sdk`.
-- Template core packages that depend on `@elevasis/core`.
-- Projects that still carry copied `.claude/rules/*.md` files instead of SDK reference pointers.
-
-## Required actions
-
-- Refresh package baselines after publishing `@elevasis/core`, `@elevasis/ui`, and `@elevasis/sdk`.
-- Adopt `ElevasisAuthenticatedShell` from `@elevasis/ui/app` in template-derived root routes.
-- Replace local UI test/store/query-client helpers with `@elevasis/ui/test-utils`, `@elevasis/ui/test-utils/setup`, `createElevasisAppStore`, and `createElevasisQueryClient`.
-- Keep project-specific Claude guidance as compatibility stubs that point at `@elevasis/sdk/reference/rules/`.
-- Treat `System.ontology.catalogTypes` and `System.config` as canonical Organization Model authoring surfaces; do not reintroduce `System.content`.
-
-## Verification
-
-- `pnpm sdk:verify-release`
-- `pnpm scaffold:verify`
-- `pnpm verify:scaffold-reference`
-- `pnpm sync:verify`
-- `pnpm org-os:verify`
-- Template UI typecheck and tests from the source workstream.
-
-## Not handled by /git-sync
-
-`/git-sync` does not publish npm packages, deploy the operations resource bundle, or decide whether project-owned files should adopt a template baseline. Those steps remain owned by `/sdk ship` and the prepared external-sync manifest.

package/reference/claude-config/sync-notes/2026-05-20-om-define-helpers.md

@@ -1,32 +0,0 @@
-# Organization Model Define Helpers Release Train
-
-## Why this note exists
-
-This train publishes `@elevasis/core` 0.28.0, which adds a generic `defineDomainRecord<TSchema>(schema, entries)` helper plus eleven domain-specific authoring wrappers (`defineAction`/`defineActions`, `defineEntity`/`defineEntities`, `defineSystem`/`defineSystems`, `defineCustomer`/`defineCustomers`, `defineOffering`/`defineOfferings`, `defineRole`/`defineRoles`, `defineGoal`/`defineGoals`, `defineStatus`/`defineStatuses`, `definePolicy`/`definePolicies`, `defineKnowledgeNode`/`defineKnowledgeNodes`). The audit that motivated this train (package vs. project boundary) found that projects were hand-rolling the "validate every entry against its schema, then return an id-keyed map" pattern in multiple places — the helpers eliminate that duplication and make validation uniform.
-
-After this publish, the template's `external/_template/core/config/organization-model.ts` drops 6 local `TemplateX` type aliases and 2 local helper redefinitions in favor of the published equivalents.
-
-## Applies to
-
-- `external/_template/core/config/organization-model.ts` (template authoring surface)
-- Any downstream tenant project derived from `_template` that still carries local `TemplateActionRef` / `TemplateActionEntry` / `TemplateEntityEntry` / `TemplateSystemEntry` / `TemplateResourceOntologyBinding` / `TemplateWorkflowResourceEntry` aliases, or local `listAllSystems` / `toDomainRecord` helpers
-- `external/_template/core/package.json` and `external/_template/operations/package.json` (baseline cascade — both pin `@elevasis/core`)
-
-## Required actions
-
-- Refresh `@elevasis/core` to 0.28.0 in `core/package.json` and `operations/package.json` (caret range picks it up automatically; `pnpm install` to actualize).
-- Drop the 6 `TemplateX` type aliases from `core/config/organization-model.ts` and import the canonical types from `@elevasis/core/organization-model` instead: `ActionRef`, `OrganizationAction`, `Entity`, `OrganizationModelSystemEntry`, `ResourceOntologyBinding`, `WorkflowResourceEntry`.
-- Drop the local `listAllSystems` and `toDomainRecord` helpers; use `listAllSystems` and `defineDomainRecord` from `@elevasis/core/organization-model`.
-- Keep `TemplateWorkflowResourceEntry` ONLY as an intersection that adds the `systemId` compat mirror plus required `title`/`description`: `WorkflowResourceEntry & { systemId: string; title: string; description: string }`. This compat mirror is the sole justified divergence.
-- Author calls that build domain records should migrate from the hand-rolled `toDomainRecord(entries)` form to the validating `defineDomainRecord(Schema, entries)` form, or use the domain-specific `defineActions`, `defineEntities`, etc. wrappers where applicable.
-
-## Verification
-
-- `pnpm -C core check-types`
-- `pnpm -C operations check-types`
-- `pnpm -C ui check-types`
-- Run `pnpm sync:verify` from the monorepo root after `/external sync --all` propagates.
-
-## Not handled by /git-sync
-
-`/git-sync` does not republish `@elevasis/core`, edit your `core/config/organization-model.ts` for you, or migrate hand-rolled `toDomainRecord` call sites to `defineDomainRecord`. Those edits are intentional authoring changes; review them in a normal PR. The `pnpm install` after the dependency bump IS handled.

package/reference/claude-config/sync-notes/2026-05-22-access-model-and-right-panel.md

@@ -1,43 +0,0 @@
-# Access Model And Right Panel Host
-
-## Why this note exists
-
-This release train replaces the retired feature-access route guards with the unified Access Model and adds the shared right-panel host plus shared Notes view to the template UI. Downstream projects need to accept the new package baselines and reconcile any project-owned routes or dashboard surfaces that still use the old `SystemGuard` / `createFeatureAccessHook` pattern.
-
-## Applies to
-
-Template-derived projects that use `@elevasis/ui` route guards, dashboard feature availability, right-panel UI, Notes, or template-managed route files under `ui/src/routes/**` and `ui/src/features/**`.
-
-Projects without custom route guards or right-panel customizations can accept the template updates normally, then run the verification gates below.
-
-## Required actions
-
-1. Pull the prepared template/package updates with `/git-sync` after the SDK ship train publishes `@elevasis/core` and `@elevasis/ui`.
-2. Replace project-owned `SystemGuard`, `SurfaceGuard`, `AdminGuard`, `createFeatureAccessHook`, `useOrganizationPermissions`, and `useHasPermission` usages with `AccessGuard`, `useAccess`, and `AccessKeys`.
-3. Keep app-local right-panel registries project-owned, but compose them with `RightPanelProvider`, `RightPanelLayer`, and shared views from `@elevasis/ui/features/right-panel-host` and `@elevasis/ui/features/notes`.
-4. Preserve tenant-specific route content, Organization Model Systems, and custom dashboard cards while updating their access checks to the new Access Model.
-5. Do not import workspace packages such as `@repo/core` or `@repo/ui` from external projects. Use the published `@elevasis/*` packages.
-
-## Verification
-
-Run the project baseline gates after syncing:
-
-```powershell
-pnpm -C ui check-types
-pnpm -C ui build
-pnpm -C ui test
-pnpm -C core test
-pnpm test
-```
-
-For projects with custom route guards, also grep for retired access APIs:
-
-```powershell
-rg "SystemGuard|SurfaceGuard|AdminGuard|createFeatureAccessHook|useOrganizationPermissions|useHasPermission" ui/src
-```
-
-For projects adopting the right-panel host, open the app shell and confirm the panel trigger opens Notes, closes cleanly, preserves width on desktop, and does not hide project-owned navigation controls.
-
-## Not handled by /git-sync
-
-`/git-sync` updates template-propagated files and package baselines. It does not rewrite project-owned custom routes, custom dashboard widgets, custom right-panel views, tenant Organization Model entries, or tenant-specific access semantics. Those remain project-authored decisions that must be migrated to the Access Model by the downstream maintainer.

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

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

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

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

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

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

package/reference/claude-config/sync-notes/2026-05-23-lead-gen-manage-access.md

@@ -1,31 +0,0 @@
-# Lead Gen Manage Access Package Baseline
-
-## Why this note exists
-
-This train adds `sales.lead-gen.manage` as the OM-aligned runtime permission for operating Lead Gen list-builder mutations. The implementation ships through `@elevasis/core` and `@elevasis/ui`; template projects need the package baseline update so derived apps receive the new access key and shared Lead Gen UI guards.
-
-## Applies to
-
-- Template UI package baseline: `external/_template/ui/package.json`
-- Template core package baseline: `external/_template/core/package.json`
-- Template operations package baseline: `external/_template/operations/package.json`
-- Derived projects that expose the shared Lead Gen list-builder UI
-
-## Required actions
-
-1. Publish the prepared `@elevasis/core` release containing `sales.lead-gen.manage` and `AccessKeys.leadGenManage`.
-2. Publish the prepared `@elevasis/ui` release containing the shared Lead Gen mutation affordance guards.
-3. Run the prepared external sync manifest so derived projects receive the updated package baselines.
-4. For client launches, verify Operator users receive `sales.lead-gen.manage` through platform role grants before list-builder smoke.
-
-## Verification
-
-- `pnpm -C packages/core build:publish`
-- `pnpm -C packages/ui build:publish`
-- `pnpm -C external/_template/ui check-types`
-- `pnpm -C external/_template/ui build`
-- `pnpm sync:verify` after the manifest-scoped external sync stage
-
-## Not handled by /git-sync
-
-Database permission rows and system role grants are environment state, not template files. Apply the SQL migration or equivalent environment change separately before inviting Operator users.

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

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

package/reference/claude-config/sync-notes/2026-05-23-om-full-model-deploy-contract.md

@@ -1,33 +0,0 @@
-# Full Organization Model deploy contract
-
-## Why this note exists
-
-The deployment contract now requires SDK projects to deploy the full canonical `organizationModel`, not the internal `resourceGovernanceModel` projection. The SDK and API now parse deployment snapshots with `OrganizationModelSchema` before overlay validation or persistence, so partial governance projections will fail before they can become active deployment snapshots.
-
-This fixes the class of production failures where an active deployment persisted only `systems`, `resources`, `topology`, `entities`, and `actions`, then the runtime resolver failed because referenced `roles`, `goals`, and `navigation` were absent.
-
-## Applies to
-
-All template-derived projects with an `operations/src/index.ts` deployment spec and a `core/config/organization-model.ts` canonical model.
-
-## Required actions
-
-1. Pull the new package baselines after the release train publishes:
-   - `@elevasis/core`
-   - `@elevasis/sdk`
-2. Ensure `operations/src/index.ts` imports and passes the canonical full `organizationModel` from `@core/config/organization-model`.
-3. Keep `resourceGovernanceModel` only for local compatibility assertions or profile assembly. Do not pass it as `DeploymentSpec.organizationModel`.
-4. Redeploy the operations bundle so the active platform deployment persists a full model snapshot:
-   - dev: `pnpm -C operations deploy`
-   - prod: `pnpm -C operations deploy:prod`
-
-## Verification
-
-- `pnpm -C operations check`
-- `pnpm -C core test -- organization-model`
-- Confirm the active deployment Organization Model snapshot parses and includes full domains such as `roles`, `goals`, and `navigation`.
-- Confirm acquisition/list or other OM-backed routes no longer fail with `MODEL_PARSE_FAILED`.
-
-## Not handled by /git-sync
-
-`/git-sync` can propagate template guidance and package baselines, but it does not install dependencies, publish packages, deploy the operations bundle, or verify the active platform deployment snapshot. Each derived project must run install/deploy and production smoke checks after syncing.

package/reference/claude-config/sync-notes/2026-05-23-ui-sdk-package-fixes.md

@@ -1,37 +0,0 @@
-# UI + SDK package fixes (lastVisitedOrg, worker-manifest organizationModel)
-
-## Why this note exists
-
-`@elevasis/ui` and `@elevasis/sdk` were republished with two backward-compatible fixes:
-
-- `@elevasis/ui`: `OrganizationProvider` now persists org preference as `lastVisitedOrg` (matching the `/api/users/me` schema), removing the noisy 400 on organization switching.
-- `@elevasis/sdk`: the worker manifest now includes `organizationModel`, so platform deployment persistence receives your tenant Organization Model snapshot.
-
-The SDK change requires a deploy, not just an install, to take effect on your active platform deployment.
-
-## Applies to
-
-All template-derived projects that consume `@elevasis/ui` and `@elevasis/sdk` and run an `operations/` resources bundle on the Elevasis platform.
-
-## Required actions
-
-1. Pull and install so the new baselines land:
-   - `@elevasis/ui` baseline bump in `ui/package.json`
-   - `@elevasis/sdk` baseline bump in `operations/package.json`
-2. `pnpm -C ui install && pnpm -C operations install` (or a project-root install) to update lockfiles.
-3. Redeploy your operations bundle so the worker manifest publishes your Organization Model to the active deployment:
-   - dev: `pnpm -C operations deploy`
-   - prod: `pnpm -C operations deploy:prod`
-4. Redeploy the UI (your host, e.g. Vercel) so the `lastVisitedOrg` fix ships to the browser.
-
-No source merges are required; both changes are internal to the published packages.
-
-## Verification
-
-- `pnpm -C ui check-types && pnpm -C ui build`
-- `pnpm -C operations check && pnpm -C operations check-types`
-- After deploy, confirm the active deployment persists an Organization Model snapshot (Lead Gen / list surfaces resolve the tenant model rather than erroring), and that organization switching no longer emits a 400 against `/api/users/me`.
-
-## Not handled by /git-sync
-
-`/git-sync` pulls the new baselines and surfaces this note, but it does NOT install dependencies, deploy your operations bundle, or redeploy your UI. Run the install + deploy steps above yourself; the worker-manifest fix only takes effect on your active deployment after an operations redeploy.