@elevasis/sdk 1.24.0 → 1.26.0

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.

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

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