@elevasis/sdk 1.29.0 → 1.30.0

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

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