@elevasis/sdk 1.25.0 → 1.26.0

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

@@ -10,8 +10,8 @@ description: |
   - The user asks "what governs X?", "what does X control?", "system governs", "what is our
     identity set to?", "what's our timezone?", "show me all reference docs", "list my roles",
     "where does outreach-cadence apply?", or similar.
-  - An agent is editing files matching: core/config/organization-model.ts or
-    core/config/knowledge/**.
+  - An agent is editing files matching: core/config/organization-model.ts,
+    core/config/organization-model/**, or core/config/knowledge/**.
   SKIP this skill when the task is purely UI layout, workflow authoring, or infrastructure
   work with no reference to org-model or knowledge-graph entities.
 
@@ -19,6 +19,7 @@ description: |
 metadata:
   pathPatterns:
     - "core/config/organization-model.ts"
+    - "core/config/organization-model/**"
     - "core/config/knowledge/**"
     - "core/config/extensions/**"
   promptSignals:
@@ -77,7 +78,8 @@ This skill auto-invokes whenever:
 - The user asks to read, list, find, show, query, navigate, describe, codify, add, edit,
   update, toggle, enable, or disable any of those
 - An agent is editing files matching `core/config/organization-model.ts`,
-  `core/config/extensions/**`, or `core/config/knowledge/**`
+  `core/config/organization-model/**`, `core/config/extensions/**`, or
+  `core/config/knowledge/**`
 
 Auto-invocation is driven by frontmatter `description`, `metadata.pathPatterns`, and
 `metadata.promptSignals` -- no explicit prefix is required.
@@ -238,7 +240,11 @@ safety ceremony preserved verbatim from the legacy `/configure` flow.
 
 ### Step 1: Snapshot
 
-Read `core/config/organization-model.ts` into memory before any edit. This is the rollback target.
+Determine the target file for the domain being edited (see the domain reference file for
+"Where it lives" guidance). Read that file into memory before any edit. This is the rollback
+target. For unsplit projects the target is `core/config/organization-model.ts`; for split projects
+use the appropriate sub-file (`profile.ts`, `systems.ts`, or `navigation.ts` under
+`core/config/organization-model/`).
 
 ### Step 2: Propose
 
@@ -275,7 +281,9 @@ The rollback is mandatory -- never leave the project in a broken state.
 
 **Two-level ceremony:**
 
-- **Level A** -- config-only edits to existing schema fields in `core/config/organization-model.ts`.
+- **Level A** -- config-only edits to existing schema fields in a single config file under
+  `core/config/` (the entry `organization-model.ts` for unsplit projects, or the appropriate
+  sub-file for split projects — see the domain reference for the correct target).
   Execute: `.claude/skills/om/operations/codify-level-a.md`
 - **Level B** -- new Zod extension files in `core/config/extensions/`. Gated to explicit user
   ask. On casual second mentions of a new type, suggest Level B and wait for confirmation rather

package/reference/claude-config/skills/om/operations/codify-level-a.md

@@ -1,100 +1,109 @@
-# Codify Pipeline: Level A (Config-Only Edits)
-
-Level A is the codify pipeline for changes that land exclusively in
-`core/config/organization-model.ts`. No new TypeScript files are created. The entire
-ceremony is: snapshot current file, propose the edit, write the edit, validate, and roll back on
-failure.
-
-This pipeline is called by domain operations (identity, customers, offerings, roles, goals,
-techStack, systems, actions, labels, and legacy feature compatibility) after the user has confirmed the proposed change. The caller provides
-the specific field/block being changed and the proposed new value.
-
----
-
-## Pipeline
-
-### Step 1: Snapshot
-
-Before any write, read `core/config/organization-model.ts` and keep the full file content
-in memory as the rollback snapshot. Do not write any file during this step.
-
-```
-Read("core/config/organization-model.ts")
--- store as ROLLBACK_SNAPSHOT
-```
-
-### Step 2: Apply the edit
-
-Use the Edit tool to apply the caller's proposed change to
-`core/config/organization-model.ts`.
-
-Rules for the edit:
-
-- Edit only the specific field or block the caller specified. Do not reformat or restructure
-  unrelated sections.
-- Preserve all other keys in `defineOrganizationModel({...})` exactly as they are.
-- Maintain the existing code style (trailing commas, quote style, indentation) of the file.
-- If the target field does not yet exist in the adapter call, add it as a new property in the
-  appropriate position (following the declared domain order in the schema).
-
-### Step 3: TypeScript type-check
-
-Run the type-check for the operations package:
-
-```bash
-pnpm -C operations check-types
-```
-
-Capture stdout and stderr. If the command exits non-zero, proceed to Step 5 (rollback).
-
-### Step 4: Runtime schema validation
-
-Confirm that the adapter's output passes `OrganizationModelSchema.parse()`. The adapter calls
-`resolveOrganizationModel()` internally, which merges defaults with overrides and then parses the
-result. A successful `check-types` pass is strong evidence that the schema is valid, but
-cross-reference checks (segment ID refs in offerings, role reporting refs, period ordering in
-goals) are runtime-only.
-
-If the project exposes a validation script (e.g. `pnpm -C operations check`), run that too:
-
-```bash
-pnpm -C operations check
-```
-
-If either validation step fails, proceed to Step 5 (rollback).
-
-### Step 5: Rollback (on failure only)
-
-If Step 3 or Step 4 failed:
-
-1. Write the ROLLBACK_SNAPSHOT content back to `core/config/organization-model.ts`
-   verbatim (use the Write tool with the exact snapshot content).
-2. Confirm the file has been restored by checking that the content matches the snapshot.
-3. Return the error message to the caller.
-
-The caller is responsible for reporting the rollback to the user.
-
-### Step 6: Success signal
-
-If Steps 3 and 4 both passed, return a success signal to the caller with:
-
-- The fields changed
-- `Type-check: PASS`
-- `Schema validation: PASS`
-
-The caller formats and presents the final report.
-
----
-
-## Caller Contract
-
-Callers must provide before invoking this pipeline:
-
-- **Target file:** always `core/config/organization-model.ts`
-- **Target block:** the specific domain key or sub-key being changed (e.g. `identity`,
-  `customers.segments`, `roles.roles`, `resources.hubspot`)
-- **Proposed value:** the new TypeScript literal to write for that block
-- **Confirmed:** the user has already said yes to the proposed change
-
-This pipeline does not ask the user any questions. All confirmation happens in the domain
-operation before this pipeline is invoked.
+# Codify Pipeline: Level A (Config-Only Edits)
+
+Level A is the codify pipeline for changes that land in a single config file inside
+`core/config/`. No new TypeScript files are created. The entire ceremony is: snapshot the target
+file, propose the edit, write the edit, validate, and roll back on failure.
+
+This pipeline is called by domain operations (identity, customers, offerings, roles, goals,
+techStack, systems, actions, labels, and legacy feature compatibility) after the user has confirmed the proposed change. The caller provides
+the specific field/block being changed, the proposed new value, and the target file.
+
+---
+
+## Pipeline
+
+### Step 1: Snapshot
+
+Before any write, read `TARGET_FILE` and keep the full file content in memory as the rollback
+snapshot. Do not write any file during this step.
+
+```
+Read(TARGET_FILE)
+-- store as ROLLBACK_SNAPSHOT
+```
+
+`TARGET_FILE` is the value the caller provides in the Caller Contract (see below). When the
+project has not been split yet, callers pass the default
+`core/config/organization-model.ts`.
+
+### Step 2: Apply the edit
+
+Use the Edit tool to apply the caller's proposed change to `TARGET_FILE`.
+
+Rules for the edit:
+
+- Edit only the specific field or block the caller specified. Do not reformat or restructure
+  unrelated sections.
+- For edits targeting `profile.ts`: preserve all other keys in `defineOrganizationModel({...})`
+  exactly as they are.
+- Maintain the existing code style (trailing commas, quote style, indentation) of the file.
+- If the target field does not yet exist in the file, add it as a new property in the appropriate
+  position (following the declared domain order in the schema).
+
+### Step 3: TypeScript type-check
+
+Run the type-check for the operations package:
+
+```bash
+pnpm -C operations check-types
+```
+
+Capture stdout and stderr. If the command exits non-zero, proceed to Step 5 (rollback).
+
+### Step 4: Runtime schema validation
+
+Confirm that the adapter's output passes `OrganizationModelSchema.parse()`. The adapter calls
+`resolveOrganizationModel()` internally, which merges defaults with overrides and then parses the
+result. A successful `check-types` pass is strong evidence that the schema is valid, but
+cross-reference checks (segment ID refs in offerings, role reporting refs, period ordering in
+goals) are runtime-only.
+
+If the project exposes a validation script (e.g. `pnpm -C operations check`), run that too:
+
+```bash
+pnpm -C operations check
+```
+
+If either validation step fails, proceed to Step 5 (rollback).
+
+### Step 5: Rollback (on failure only)
+
+If Step 3 or Step 4 failed:
+
+1. Write the ROLLBACK_SNAPSHOT content back to `TARGET_FILE` verbatim (use the Write tool with
+   the exact snapshot content).
+2. Confirm the file has been restored by checking that the content matches the snapshot.
+3. Return the error message to the caller.
+
+The caller is responsible for reporting the rollback to the user.
+
+### Step 6: Success signal
+
+If Steps 3 and 4 both passed, return a success signal to the caller with:
+
+- The file edited (`TARGET_FILE`)
+- The fields changed
+- `Type-check: PASS`
+- `Schema validation: PASS`
+
+The caller formats and presents the final report.
+
+---
+
+## Caller Contract
+
+Callers must provide before invoking this pipeline:
+
+- **Target file:** the sub-file path to snapshot and edit. Default (unsplit projects):
+  `core/config/organization-model.ts`. Split-project routing:
+  - `core/config/organization-model/profile.ts` for identity, customers, offerings, roles, goals
+    (and techStack/labels when those keys exist in `profile.ts`)
+  - `core/config/organization-model/systems.ts` for systems, actions, resources
+  - Callers use the default entry path when the domain does not yet have a dedicated sub-file
+- **Target block:** the specific domain key or sub-key being changed (e.g. `identity`,
+  `customers.segments`, `roles.roles`, `resources.hubspot`)
+- **Proposed value:** the new TypeScript literal to write for that block
+- **Confirmed:** the user has already said yes to the proposed change
+
+This pipeline does not ask the user any questions. All confirmation happens in the domain
+operation before this pipeline is invoked.

package/reference/claude-config/skills/om/operations/customers.md

@@ -89,19 +89,23 @@ customers: {
 
 ## Where it lives in the adapter
 
-`core/config/organization-model.ts` under the `customers` key of
+**Split projects:** `core/config/organization-model/profile.ts` under the `customers` key of
 `defineOrganizationModel({...})`.
 
-To read current segments: open the adapter file and inspect the `customers.segments` array, or
-use `pnpm exec elevasis-sdk om:cat customers` (external project).
+**Unsplit projects:** `core/config/organization-model.ts` under the same key.
+
+To read current segments: open the appropriate file and inspect the `customers.segments` array,
+or use `pnpm exec elevasis-sdk om:cat customers` (external project).
 
 ## Write path
 
 To add, edit, or remove a segment, the `/om` skill runs the codify ceremony
 (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Only the `segments` array is written; no other keys in the adapter are
-touched. When adding, append to the array. When editing, replace the matching entry by `id`.
-When removing, filter it out — and surface any dangling `targetSegmentIds` references first.
+rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
+projects, or `core/config/organization-model.ts` for unsplit projects. Only the `segments` array
+is written; no other keys in the target file are touched. When adding, append to the array. When
+editing, replace the matching entry by `id`. When removing, filter it out — and surface any
+dangling `targetSegmentIds` references first.
 
 ---
 

package/reference/claude-config/skills/om/operations/features.md

@@ -31,10 +31,14 @@ guidance that depends on it; prefer `by-system` everywhere.
 For natural-language requests like "turn on lead gen", "disable SEO", or "enable CRM":
 
 1. Treat the request as a System availability/routing change.
-2. Read `core/config/organization-model.ts` and find the matching System entry or platform
-   default constant exposed by `@elevasis/core/organization-model`.
+2. Read the Systems config file to find the matching System entry or platform default constant
+   exposed by `@elevasis/core/organization-model`. For split projects this is
+   `core/config/organization-model/systems.ts`; for unsplit projects use
+   `core/config/organization-model.ts`.
 3. Propose the exact availability/routing change in plain language.
-4. After confirmation, run the Level A codify ceremony in `operations/codify-level-a.md`.
+4. After confirmation, run the Level A codify ceremony in `operations/codify-level-a.md`, passing
+   `targetFile` as `core/config/organization-model/systems.ts` (split) or
+   `core/config/organization-model.ts` (unsplit).
 
 Do not create new extension files for a simple on/off change.
 

package/reference/claude-config/skills/om/operations/goals.md

@@ -98,19 +98,23 @@ goals: {
 
 ## Where it lives in the adapter
 
-`core/config/organization-model.ts` under the `goals` key of
+**Split projects:** `core/config/organization-model/profile.ts` under the `goals` key of
 `defineOrganizationModel({...})`.
 
-To read current goals: open the adapter file and inspect the `goals.objectives` array, or use
-`pnpm exec elevasis-sdk om:cat goals` (external project).
+**Unsplit projects:** `core/config/organization-model.ts` under the same key.
+
+To read current goals: open the appropriate file and inspect the `goals.objectives` array, or
+use `pnpm exec elevasis-sdk om:cat goals` (external project).
 
 ## Write path
 
 To add, edit, remove, or update progress on a goal, the `/om` skill runs the codify
 ceremony (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck →
-Zod parse → rollback on failure. Only the `objectives` array is written; no other keys in the
-adapter are touched. For progress-only updates (changing `currentValue` on an existing outcome),
-a targeted edit is preferred over rewriting the entire goals block.
+Zod parse → rollback on failure. Pass `targetFile` as
+`core/config/organization-model/profile.ts` for split projects, or
+`core/config/organization-model.ts` for unsplit projects. Only the `objectives` array is written;
+no other keys in the target file are touched. For progress-only updates (changing `currentValue`
+on an existing outcome), a targeted edit is preferred over rewriting the entire goals block.
 
 ---
 

package/reference/claude-config/skills/om/operations/identity.md

@@ -74,18 +74,21 @@ identity: {
 
 ## Where it lives in the adapter
 
-`core/config/organization-model.ts` under the `identity` key of
+**Split projects:** `core/config/organization-model/profile.ts` under the `identity` key of
 `defineOrganizationModel({...})`.
 
-To read the current values: open the adapter file and inspect the `identity` block directly, or
-use `pnpm exec elevasis-sdk om:cat identity` (external project).
+**Unsplit projects:** `core/config/organization-model.ts` under the same key.
+
+To read the current values: open the appropriate file and inspect the `identity` block directly,
+or use `pnpm exec elevasis-sdk om:cat identity` (external project).
 
 ## Write path
 
 To edit any field, the `/om` skill runs the codify ceremony
 (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Only the confirmed fields are written; no other top-level keys in the adapter
-are touched.
+rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
+projects, or `core/config/organization-model.ts` for unsplit projects. Only the confirmed fields
+are written; no other top-level keys in the target file are touched.
 
 ---
 

package/reference/claude-config/skills/om/operations/labels.md

@@ -4,7 +4,7 @@
 knowledge nodes, registry entries, and sidebar surfaces in the OrganizationModel. Labels control what users see in the UI and what
 agents say when narrating state. Editing a label does not change the entry's `id` or
 `semanticClass` -- only the human-readable display string. This is Level A only (config-only
-edits to `core/config/organization-model.ts`).
+edits to a single file under `core/config/`).
 
 ## What carries labels
 
@@ -76,6 +76,22 @@ navigation.sidebar.primary:
   sales.crm:     label "Pipeline"       -> "Deal Pipeline"
 ```
 
+## Where it lives
+
+**Split projects:** the target file depends on what carries the label being edited:
+
+- Status/stage entries and System entries -- `core/config/organization-model/systems.ts`
+- Sidebar navigation surfaces -- `core/config/organization-model/navigation.ts`
+- Business-profile domain entries (customers, offerings, roles, goals) -- `core/config/organization-model/profile.ts`
+
+**Unsplit projects:** `core/config/organization-model.ts` for all label edits.
+
+Pass the appropriate path as `targetFile` when invoking `operations/codify-level-a.md`.
+
+**Note:** `labels` is not currently authored as a standalone top-level domain key in either the
+template or reference tenant model. Label fields are inline properties on the entries listed
+above. Do not invent a top-level `labels` key in `profile.ts`.
+
 ## Validation gate
 
 Every label change must pass before codify completes:

package/reference/claude-config/skills/om/operations/offerings.md

@@ -88,20 +88,24 @@ offerings: {
 
 ## Where it lives in the adapter
 
-`core/config/organization-model.ts` under the `offerings` key of
+**Split projects:** `core/config/organization-model/profile.ts` under the `offerings` key of
 `defineOrganizationModel({...})`.
 
-To read current products: open the adapter file and inspect the `offerings.products` array, or
-use `pnpm exec elevasis-sdk om:cat offerings` (external project).
+**Unsplit projects:** `core/config/organization-model.ts` under the same key.
+
+To read current products: open the appropriate file and inspect the `offerings.products` array,
+or use `pnpm exec elevasis-sdk om:cat offerings` (external project).
 
 ## Write path
 
 To add, edit, or remove a product, the `/om` skill runs the codify ceremony
 (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Only the `products` array is written; no other keys in the adapter are
-touched. Before writing, the skill verifies all `targetSegmentIds` and `deliverySystemId`
-references resolve. When adding, append to the array. When editing, replace by `id`. When
-removing, filter out — and surface any dangling references first.
+rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
+projects, or `core/config/organization-model.ts` for unsplit projects. Only the `products` array
+is written; no other keys in the target file are touched. Before writing, the skill verifies all
+`targetSegmentIds` and `deliverySystemId` references resolve. When adding, append to the array.
+When editing, replace by `id`. When removing, filter out — and surface any dangling references
+first.
 
 ---
 

package/reference/claude-config/skills/om/operations/roles.md

@@ -78,20 +78,24 @@ roles: {
 
 ## Where it lives in the adapter
 
-`core/config/organization-model.ts` under the `roles` key of
+**Split projects:** `core/config/organization-model/profile.ts` under the `roles` key of
 `defineOrganizationModel({...})`.
 
-To read the current role chart: open the adapter file and inspect the `roles.roles` array, or
-use `pnpm exec elevasis-sdk om:cat roles` (external project).
+**Unsplit projects:** `core/config/organization-model.ts` under the same key.
+
+To read the current role chart: open the appropriate file and inspect the `roles.roles` array,
+or use `pnpm exec elevasis-sdk om:cat roles` (external project).
 
 ## Write path
 
 To add, edit, or remove a role, the `/om` skill runs the codify ceremony
 (`operations/codify-level-a.md`): snapshot → propose → confirm → write → typecheck → Zod parse →
-rollback on failure. Only the `roles` array is written; no other keys in the adapter are touched.
-Before writing, the skill verifies all `reportsToId` references resolve to IDs that will exist
-after the write. When removing a role, the skill surfaces any other roles that `reportsToId` to it
-and asks whether to clear those reporting lines before proceeding.
+rollback on failure. Pass `targetFile` as `core/config/organization-model/profile.ts` for split
+projects, or `core/config/organization-model.ts` for unsplit projects. Only the `roles` array is
+written; no other keys in the target file are touched. Before writing, the skill verifies all
+`reportsToId` references resolve to IDs that will exist after the write. When removing a role,
+the skill surfaces any other roles that `reportsToId` to it and asks whether to clear those
+reporting lines before proceeding.
 
 ---
 

package/reference/claude-config/skills/om/operations/techStack.md

@@ -11,10 +11,18 @@ Tech stack information is no longer modeled through `resourceMappings`. Resource
 
 ## Where To Look
 
-- `core/config/organization-model.ts` -- Systems and Resources descriptors.
+- **Systems and Resources descriptors** -- `core/config/organization-model/systems.ts` (split
+  projects) or `core/config/organization-model.ts` (unsplit projects).
 - `operations/src/index.ts` -- deployment assembly that binds executable behavior to descriptors.
 - `pnpm elevasis-sdk project:list --pretty` -- live deployed resource surface.
-- Project knowledge nodes -- narrative details such as credential owner, setup notes, and system-of-record rationale when they do not fit the descriptor shape.
+- Project knowledge nodes -- narrative details such as credential owner, setup notes, and
+  system-of-record rationale when they do not fit the descriptor shape.
+
+**Note:** `techStack` is not currently authored as a top-level key in either the template or
+reference tenant model. Integration context lives in Resource descriptors (`systems.ts`) and
+project knowledge nodes rather than a dedicated `techStack` domain block. Do not invent a
+`techStack` key in `profile.ts`; if the schema adds one in a future SDK release, this note will
+be updated.
 
 ## Write Path
 

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

@@ -0,0 +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.

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

@@ -0,0 +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.

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

@@ -0,0 +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.