@elevasis/sdk 1.44.2 → 1.45.0

package/reference/claude-config/sync-notes/2026-05-24-platform-invite-router-core-baseline.md

@@ -1,28 +0,0 @@
-# Platform Invite Router Core Baseline
-
-## Why this note exists
-
-The platform invite router train publishes a new `@elevasis/core` auth schema export for the narrow organization auth-config endpoint used by the backend invite router.
-
-## Applies to
-
-- Template-derived projects that consume `@elevasis/core`.
-- Project `core/package.json` and `operations/package.json` package baselines after the core release.
-
-## Required actions
-
-- Accept the `@elevasis/core` dependency baseline update after the core publish stage.
-- Do not add tenant app-origin routing code to template projects from this train; invitation routing remains platform API behavior.
-- Keep tenant app WorkOS login routes accepting `invitation_token` when project-specific launch work has already added that route support.
-
-## Verification
-
-- Run `pnpm sync:verify` after manifest-scoped external sync.
-- For projects receiving the baseline, run project-local checks required by the sync plan.
-
-## Not handled by /git-sync
-
-- Publishing `@elevasis/core`.
-- Updating package baselines after publish.
-- WorkOS production application configuration.
-- Per-tenant invitation smoke tests.

package/reference/claude-config/sync-notes/2026-05-24-system-interface-readiness.md

@@ -1,43 +0,0 @@
-# System Interface readiness, scoped topology grants, and org ID brands
-
-## Why this note exists
-
-The Organization Model API boundary now uses `system.apiInterface` plus derived readiness instead of authored `System.contracts` or top-level `bridgeContracts`. API-backed Systems are ready when their scoped Resources, ontology bindings, catalog contents, and scoped topology grants satisfy the published readiness profile.
-
-This removes the old declaration-triggered contract layer before it became a tenant authoring requirement, and it gives API and UI consumers structured readiness diagnostics instead of incidental runtime failures.
-
-The same release train also publishes branded WorkOS organization IDs and Supabase organization UUIDs through the shared core/UI package surface. The brands are a compile-time guard against mixing auth identity (`org_...`) with database identity (UUID) in package consumers.
-
-## Applies to
-
-Template-derived projects that opt into API-backed Systems such as lead-gen or CRM after updating to the released package baselines that include `system.apiInterface` support.
-
-The bare `_template` remains API-interface-light by default. Disabled sales, lead-gen, and CRM shell Systems should not declare API interfaces until a compatible recipe pack or tenant-owned model intentionally opts in.
-
-Projects that consume the updated `@elevasis/core` or `@elevasis/ui` types may see stricter TypeScript checks around organization IDs. This is expected: WorkOS org IDs and Supabase org UUIDs are intentionally no longer interchangeable at typed chokepoints.
-
-## Required actions
-
-1. Pull the new package baselines after the release train publishes:
-   - `@elevasis/core`
-   - `@elevasis/ui`
-   - `@elevasis/sdk`
-2. Do not author `contracts`, `bridgeContracts`, versioned `*@v1` contract IDs, or a keyed `interfaces` map in tenant Organization Models.
-3. For an API-backed System, author the flat `system.apiInterface` marker only after the System's scoped Resources and ontology bindings are ready.
-4. Model cross-System API behavior with scoped topology grants rather than broad sibling-System references.
-5. Keep disabled optional-pack shells contract/interface-free until the project deliberately installs an API-ready pack.
-6. When TypeScript reports a branded org-ID mismatch, fix the source value rather than casting through `string`; use package-provided brand helpers only at trusted source boundaries.
-
-## Verification
-
-- `pnpm -C core test -- organization-model`
-- `pnpm -C operations check`
-- Verify API-backed routes return structured readiness errors when a required System Interface is absent or not ready.
-- Verify API-backed UI actions are disabled until the relevant System Interface readiness passes.
-- Verify org-scoped query keys and Supabase `organization_id` filters receive the intended org-ID flavor after package baselines update.
-
-## Not handled by /git-sync
-
-`/git-sync` can propagate template guidance, package baselines, and this note, but it does not decide when a tenant's business model is ready to declare `system.apiInterface`. Tenant-specific System Interface markers, scoped Resource bindings, and topology grants remain project-owned authoring decisions.
-
-`/git-sync` also does not repair tenant-specific organization identity plumbing. If a project has local hooks or direct Supabase calls outside the template baseline, audit those call sites manually when adopting the branded org-ID package surface.

package/reference/claude-config/sync-notes/2026-05-25-invitation-login-loader.md

@@ -1,26 +0,0 @@
-# Invitation Login Loader
-
-## Why this note exists
-
-The template login route now handles WorkOS `invitation_token` links without flashing the normal tenant sign-in card before redirecting to hosted AuthKit.
-
-## Applies to
-
-- Template-derived apps that accept WorkOS organization invitations through `ui/src/routes/login.tsx`.
-- Apps using `@elevasis/ui/features/auth` for shared auth UI helpers.
-
-## Required actions
-
-1. Pull the latest template sync changes.
-2. Install dependencies so `@elevasis/ui` resolves to the released version that exports `AuthRedirectLoadingScreen`.
-3. Keep any tenant-specific WorkOS env values, especially `VITE_WORKOS_ORG_ID`, in the app environment.
-
-## Verification
-
-- Open `/login?invitation_token=test-token` and confirm the app shows a neutral gray full-screen loader while redirecting.
-- Run `pnpm -C ui check-types`.
-- Run `pnpm -C ui test src/routes/__tests__/auth-routes.test.tsx` when the project carries the template auth route tests.
-
-## Not handled by /git-sync
-
-`/git-sync` transports commits only. It does not accept invitations, configure WorkOS invitation URLs, set tenant WorkOS org IDs, or smoke-test the hosted AuthKit redirect in production.

package/reference/claude-config/sync-notes/2026-05-25-om-topbar-requests.md

@@ -1,33 +0,0 @@
-# OM-Declared Topbar Actions + Tenant Request Affordance + Requests→Platform Re-bucket
-
-## Why this note exists
-
-This release adds an OM-governed topbar region and a shared in-app request affordance, and moves the submitted-requests System under `platform`:
-
-- `@elevasis/core` gains a `navigation.topbar` schema region (`TopbarActionNodeSchema`, `TopbarSectionSchema`) plus the `message-plus` icon token. The topbar is now declared by the Organization Model and toggled via `/org-os manage`, mirroring how the sidebar already works.
-- `@elevasis/ui` gains the topbar substrate (`TopbarActionModule`, `ResolvedTopbarAction`, `TOPBAR_ACTION_MANIFESTS`, `<TopbarActions />`, topbar projection) and the request feature (`useSubmitRequest` hook, `RequestModal`, `RequestButton`, `RequestActionIcon`).
-- The submitted-requests System moves from `monitoring` to a `platform` governance System. A headless `platform` System is introduced and `monitoring.submitted-requests` is re-parented to `platform.submitted-requests`. The route path stays `/monitoring/requests`; only System ownership and the surface's `targets.systems` change.
-
-## Applies to
-
-- Template-derived apps that render `AppTopbar` and want OM-governed topbar actions.
-- Apps that want an end-user "Request a feature / report an issue" affordance (topbar icon, dashboard card, requests-page button) backed by the existing `reported_requests` API.
-- Apps whose Organization Model declares `monitoring.submitted-requests`.
-
-## Required actions
-
-1. Pull the latest template sync changes, then `/git-sync` to surface this note.
-2. Install dependencies so `@elevasis/core` and `@elevasis/ui` resolve to the released versions that export the `navigation.topbar` schema and the topbar/request surfaces.
-3. Confirm your OrganizationModel declares `navigation.topbar` (the schema defaults to `{}`, so omitting it is valid). To adopt the request topbar action, add a `navigation.topbar.request` node and register `requestTopbarActionManifest` in your `TOPBAR_ACTION_MANIFESTS` array in `ui/src/routes/__root.tsx`, then render `<TopbarActions />` in `AppTopbar`.
-4. If your OM still parents submitted-requests under `monitoring`, introduce a headless `platform` System and re-parent `monitoring.submitted-requests` to `platform.submitted-requests` in `core/config/organization-model/systems.ts`, and retarget the `monitoring-requests` surface in `navigation.ts`. This is an `/om` content change (direct edits discouraged) — the route path stays `/monitoring/requests`.
-
-## Verification
-
-- `pnpm -C ui check-types && pnpm -C ui build`.
-- `pnpm -C ui test` — topbar projection, `<TopbarActions />`, and request component tests green.
-- Toggle the `request` topbar action `enabled: false` in your OM and confirm the icon disappears from the topbar.
-- Submit from the UI and confirm a row appears in the requests list with `source = user`.
-
-## Not handled by /git-sync
-
-`/git-sync` transports commits only. It does not re-bucket your Organization Model (the `platform` System introduction and `monitoring.submitted-requests` → `platform.submitted-requests` re-parent are `/om` content edits authored per project), register topbar manifests in your `__root.tsx`, or add the requests-page nav surface where your project does not already define one.

package/reference/claude-config/sync-notes/2026-05-25-system-interface-profile-registry-and-substrate.md

@@ -1,35 +0,0 @@
-# System Interface: Closed Profile Registry, Capability Catalog & Substrate Guidance
-
-## Why this note exists
-
-`@elevasis/core@0.38` tightens the `system.apiInterface` adoption handshake from a free-string `readinessProfile` to a **closed, registry-derived literal union** with a generated capability catalog. The published-schema change is _effectively non-breaking_ because no tenant has authored an `apiInterface` profile to date, but the contract is now explicit: a tenant adopts a platform-provided System Interface (`sales.lead-gen.api`, `sales.crm.api`, `sales.lead-gen.crm-handoff`) by naming the System at its convention-locked path, marking `system.apiInterface` with one of the supported `readinessProfile` literals, and satisfying derived readiness via ontology bindings / scoped resources / scoped topology grants. Authoring an unrecognized profile is now a tenant **typecheck** error with autocomplete, not a deploy-time `RegistryValidationError`. The runtime backstop diagnostic (`SYSTEM_INTERFACE_INVALID: unknown-readiness-profile`) is retained for hand-edited / non-TypeScript OMs and now names the supported profiles and tells authors that custom Systems do not carry `apiInterface` — custom behavior belongs in workflows/operations, ontology, resources, catalogs, topology, and navigation.
-
-Parallel substrate updates ride the same train: the SDK scaffold recipes (`extend-lead-gen.md`, `extend-crm.md`, `customize-crm-actions.md`), the SDK agent-rules (`organization-os.md`, `organization-model.md`), the SDK-bundled glossary, and the template `.claude/skills/om/SKILL.md` now teach the flat `system.apiInterface` model and the closed-handshake boundary explicitly. The retired authored `SystemContract` / `BridgeContract` / `@vN` ID vocabulary is gone from all teaching surfaces; agents that still remember it should consult the canonical recipes/agent-rules at `node_modules/@elevasis/sdk/reference/`.
-
-## Applies to
-
-- All tenants that consume `@elevasis/core` and `@elevasis/sdk` and adopt the platform-provided `sales.lead-gen` / `sales.crm` Systems.
-- Tenants whose `core/config/organization-model.ts` (or `organization-model/systems.ts` under the split layout) currently declares `system.apiInterface` on a lead-gen or CRM System.
-- Tenants whose `/om` skill agents reach for authored-contract vocabulary (`SystemContract`, `bridgeContracts`, `*@v1` IDs); those vocabulary mentions should be treated as retired/avoid language after this sync.
-- `external/nirvana-marketing` is the canonical first downstream consumer.
-
-## Required actions
-
-1. After `/git-sync` runs `pnpm install` and pins `@elevasis/core ^0.38.0` and `@elevasis/sdk ^1.30.0` (run by template-baseline cascade), run `pnpm -C core check-types` and `pnpm -C operations check-types` from the tenant project root. If any pre-existing `system.apiInterface.readinessProfile` value is now a typecheck error, replace it with one of the supported literals from the capability catalog at `node_modules/@elevasis/sdk/reference/scaffold/reference/system-interface-capabilities.md`.
-
-2. Browse the capability catalog and the updated glossary in `node_modules/@elevasis/core/reference/glossary.md` to refresh the team's mental model. The terms _System Interface_, _System Interface profile_, _derived readiness_, _scoped topology bridge_, and _boundary invariant_ now have authoritative definitions; old _System Contract_ / _Bridge Contract_ wording should be treated as historical.
-
-3. If the tenant has authored a custom System that previously carried a free-string `readinessProfile` (none expected, but verify), drop the `apiInterface` field entirely. Custom Systems extend the platform through the layers the tenant fully owns — ontology, resources, catalogs, topology, navigation, and workflows/operations — never through `apiInterface`.
-
-4. After applying baseline + any required `readinessProfile` migration, run `pnpm -C operations check` to confirm deploy preflight (`validateDeclaredSystemInterfaceReadiness` + `detectMissingApiInterfaceDeclarations`) accepts the model.
-
-## Verification
-
-- `pnpm -C core check-types` and `pnpm -C operations check-types` — must pass against the new narrowed `OrganizationModelSystemInterfaceReadinessProfile` literal union.
-- `pnpm -C operations check` — must pass. The conformance gate now distinguishes API-backed Systems from purely UI-backed ones and only flags the former when `apiInterface` is missing.
-- `pnpm -C operations exec elevasis-sdk om:verify --json` — surface-level model coherence; no new diagnostic shape, but updated wording for `SYSTEM_INTERFACE_*` diagnostics.
-
-## Not handled by /git-sync
-
-- **Tenant-authored OM that carried a literal `SystemContract` or `bridgeContracts` shape** would have failed schema validation before this sync (that field was already removed). If a tenant has private fixtures or out-of-tree examples using the old shape, migrate them by hand — `/git-sync` only ships template files, not project-private fixtures.
-- **`/om` skill agents that quote the old authored-contract vocabulary** in tenant-local memory or notes will not be auto-corrected. Refresh those notes after reading the updated recipes; the canonical agent-rule guidance now lives at `node_modules/@elevasis/sdk/reference/rules/organization-os.md`.

package/reference/claude-config/sync-notes/2026-05-25-tenant-om-scaffold-cli.md

@@ -1,49 +0,0 @@
-# Tenant OM Scaffold CLI & Conformance Gate
-
-## Why this note exists
-
-`@elevasis/sdk@1.30` adds a guided, non-technical authoring surface for tenant OM under the new `elevasis-sdk om:scaffold:*` command family, plus a **hard conformance gate** in the deploy preflight that blocks deploys when an API-backed System lacks `system.apiInterface`. Five new interactive commands (`om:scaffold:system`, `om:scaffold:resource`, `om:scaffold:role`, `om:scaffold:knowledge`, `om:scaffold:fill`) walk an author through emitting valid TypeScript into the right file in the split OM layout (`core/config/organization-model/{systems,resources,roles,navigation,profile}.ts`). Every scaffold command refuses to run unless the project uses the split layout (`assertSplitLayout`) and writes through a snapshot-rollback wrapper so an aborted emit never leaves a half-edited file.
-
-The deploy preflight now invokes `detectMissingApiInterfaceDeclarations` from `@repo/core/platform` before `validateDeclaredSystemInterfaceReadiness`. A system is flagged when it has resources with ontology bindings (`resource.ontology.actions` or `resource.ontology.writes`) but no `apiInterface` marker. When the gate trips, the diagnostic points the author at `om:scaffold:fill --gaps` for a non-interactive, snapshot-rollback-protected remediation that fills the missing marker(s) from the gap payload. The sync-engine adds a matching `conformance-blocked` lane to `assessSyncLane` and a Contract Conformance check group to `verify-sync.js`, so the same shape surfaces in both deploy and sync surfaces.
-
-## Applies to
-
-- All tenants whose `core/config/organization-model.ts` is in the split layout (the canonical layout for new tenants since the May 2026 multi-file split sync-note).
-- Tenants with API-backed Systems (lead-gen, CRM, or future closed-registry profiles) that don't yet declare `system.apiInterface`.
-- Tenants whose template `.claude/skills/om/SKILL.md` is expected to teach the scaffold surface.
-- `external/nirvana-marketing` is the canonical first downstream consumer.
-
-## Required actions
-
-1. After `/git-sync` runs `pnpm install` and the new `@elevasis/sdk ^1.30.0` baseline lands, confirm the five new commands resolve:
-
-   ```
-   pnpm exec elevasis-sdk om:scaffold:system --help
-   pnpm exec elevasis-sdk om:scaffold:resource --help
-   pnpm exec elevasis-sdk om:scaffold:role --help
-   pnpm exec elevasis-sdk om:scaffold:knowledge --help
-   pnpm exec elevasis-sdk om:scaffold:fill --help
-   ```
-
-2. Smoke-test the dry-run path from inside the tenant project:
-
-   ```
-   pnpm exec elevasis-sdk om:scaffold:system --dry-run
-   ```
-
-   Expected: `assertSplitLayout` passes, interactive prompts fire, a dry-run TypeScript block prints, nothing is written.
-
-3. Run `pnpm -C operations check` to exercise the new conformance gate locally. If the gate fails on an API-backed System, run `pnpm exec elevasis-sdk om:scaffold:fill --gaps <gap-json>` (or follow the diagnostic's exact instructions) to remediate. Tenants whose Systems are all UI-backed (no resources with ontology bindings) will not trip the gate.
-
-4. Refresh the team on the updated `/om` skill guidance: `.claude/skills/om/SKILL.md` and its operations now reference the five scaffold commands as the canonical authoring path for non-technical contributors. Pure hand-edits to `organization-model/*.ts` still work but lose the snapshot-rollback safety net.
-
-## Verification
-
-- `pnpm exec elevasis-sdk om:scaffold:system --help` — should print the new command surface (id / title / kind / lifecycle prompts and flags).
-- `pnpm -C operations check` — must pass. Conformance gate accepts every API-backed System or reports the gap with a remediation prompt.
-- `pnpm sync:verify` (run from the monorepo) — should show the `Contract Conformance` check group passing for the tenant (no `apiInterface` gaps).
-
-## Not handled by /git-sync
-
-- **Projects still on the single-file OM layout** (`organization-model.ts` without a sibling `organization-model/` directory) will see `assertSplitLayout` abort every scaffold command with a remediation message pointing at the multi-file split migration. `/git-sync` does not perform that migration; follow the existing `2026-05-22-org-model-multi-file-split.md` sync-note instructions if the split is still pending.
-- **The post-publish `external/_template/.claude/skills/om/operations/scaffold.md` operation file** that documents the new commands inside the `/om` skill is authored during the `/sdk ship` train (post-publish authoring, between `sdk` publish and `external-sync`). Until that file lands, the canonical reference for the new commands is this sync-note plus `--help` on each subcommand.

package/reference/claude-config/sync-notes/2026-05-25-vibe-operate-intent.md

@@ -1,47 +0,0 @@
-# Vibe Layer: Operate Intent + Codify/Toggle Clarifications
-
-## Why this note exists
-
-The Ambient Vibe Layer gained an eighth intent — **Operate** — that delegates to `/elevasis` for running already-deployed workflows and agents. The canonical rule (`packages/sdk/docs/agent-rules/vibe.md` → published to tenants at `node_modules/@elevasis/sdk/reference/rules/vibe.md`) was updated alongside the template's hand-written intent table (`external/_template/CLAUDE.md` Ambient Vibe Layer section). Two prior drift corrections also landed in the same train: the Codify section now distinguishes asking-about (Describe) from asking-to-change (Codify) so the classifier stops over-proposing codification on plain questions, and the Toggle section clarifies that the intent is tenant-local only (it cannot toggle platform-level Systems).
-
-A new repo gate (`scripts/monorepo/check-vibe-drift.mjs`, wired into `pnpm meta:verify`) now enforces intent-name parity and routing-token coverage between the two surfaces so this kind of drift cannot land silently again. The validator was also de-hardcoded from the seven-intent count so future expansions don't require a global rename.
-
-## Applies to
-
-- All tenants that consume `@elevasis/sdk` and inherit the template `CLAUDE.md` shell.
-- Most directly: any project whose agents already route Capture / Query / Describe / Transition / Navigate / Codify / Toggle through vibe. They will start seeing Operate routed to `/elevasis` after this sync.
-- `external/nirvana-marketing` is the canonical first downstream consumer.
-
-## Required actions
-
-1. After `/git-sync` runs `pnpm install` and lands the new template CLAUDE.md, confirm your project's `CLAUDE.md` "Ambient Vibe Layer" table contains an **Operate** row. If your tenant has a customized intent table, manually add the row using the form:
-
-   ```
-   | Operate | "run", "execute", "launch", "trigger", "kick off", "start" + deployed resource | Delegate to `/elevasis` -- `elevasis-sdk describe` + confirm + `elevasis-sdk exec` |
-   ```
-
-2. Verify the `elevasis` skill is present at `.claude/skills/elevasis/SKILL.md`. It ships from the template; if your project removed it intentionally, document that Operate intents will surface a missing-skill notice instead of being executed.
-
-3. If your project carries a tenant-customized Toggle section, confirm it does not attempt platform-level System toggles. Tenant Toggle operates only on the project's own `core/config/organization-model.ts`.
-
-## Verification
-
-- `pnpm exec elevasis-sdk note:create "test"` — sanity-check the SDK CLI still resolves under the post-sync dependency baseline.
-- In a fresh Claude session, type "run the X workflow" against any deployed resource. The agent should describe → confirm → exec via the `/elevasis` skill flow. Plain questions ("what does X do?") should stay in Describe and not propose codification.
-
-## Not handled by /git-sync
-
-- **`deploy` skill filename rename** (`.claude/skills/deploy/skill.md` → `SKILL.md`): the template includes the rename, but git is case-insensitive on macOS/Windows. After sync, manually verify the filename is uppercase `SKILL.md`:
-
-  ```
-  ls .claude/skills/deploy/
-  ```
-
-  If the file is still lowercase `skill.md`, run a two-step rename to force the case change (or use `git mv` if the project's git config is case-sensitive):
-
-  ```
-  mv .claude/skills/deploy/skill.md .claude/skills/deploy/SKILL.tmp.md
-  mv .claude/skills/deploy/SKILL.tmp.md .claude/skills/deploy/SKILL.md
-  ```
-
-- **Tenant-customized Ambient Vibe Layer prose**: `/git-sync` cannot infer what bespoke intent table edits a project has made. The required action above is the human-review checkpoint.

package/reference/claude-config/sync-notes/2026-05-28-om-snapshot-sdk-workflow-config.md

@@ -1,33 +0,0 @@
-# OM snapshot stamp + `@elevasis/sdk` workflow-config promotion + `om:ls` enumeration
-
-## Why this note exists
-
-The 2026-05-28 SDK ship train publishes two coordinated package bumps and propagates two template-authored changes:
-
-- **`@elevasis/core` 0.40.0** — adds an optional `snapshotHash` field to the Organization Model schema (deploy-time + runtime OM snapshot-drift detection), a `STALE_OM_SNAPSHOT` validation member, and three new `@elevasis/core/knowledge` enumeration helpers (`listAllSystemsFlat`, `listAllResources`, `listAllRoles`).
-- **`@elevasis/sdk` 1.31.0** — promotes the generic `defineWorkflowConfig(resourceId, descriptors, actionRegistry)` helper out of the private platform package into the published SDK barrel, and adds `om:ls /all-systems | /all-resources | /all-roles` enumeration mounts to the tenant `elevasis-sdk om:ls` CLI.
-
-These change tenant-visible behavior (a new readiness diagnostic, new CLI mounts, and a new recommended deployment-binding pattern), so they cannot be left to silent dependency-baseline drift.
-
-## Applies to
-
-- All tenant SDK consumers depending on `@elevasis/core` and/or `@elevasis/sdk` (`external/nirvana-marketing`, and any project scaffolded from `external/_template`).
-- New scaffolds: pick up the `operations/src/metadata.ts` convention seed and (after the post-publish template authoring lands) the `projectDeploymentSpec`-based `operations/src/index.ts`.
-
-## Required actions
-
-1. **Adopt the bumped baselines.** `core/package.json` → `@elevasis/core` `^0.40.0`; `operations/package.json` → `@elevasis/core` `^0.40.0` and `@elevasis/sdk` `^1.31.0`. (Handled by the package-cascade entries in `_external-sync-prep.json`; verify, do not hand-edit.)
-2. **Redeploy operations after the bump** so the deployment writes a hash-stamped OM snapshot. Until you redeploy, the deployed snapshot carries no `snapshotHash` and the new drift diagnostic stays dormant. Stale-snapshot 503s now name the cause and the fix ("redeploy via `pnpm operations:deploy`") instead of the old opaque "not ready for this API surface".
-3. **New enumeration CLI is available after the `@elevasis/sdk` bump:** `pnpm -C external/<project>/operations exec elevasis-sdk om:ls /all-systems` (also `/all-resources`, `/all-roles`; supports `--json` / `--ids-only`). The tenant `/om` skill documents the drill-down surface.
-4. **Deployment-binding convention (informational for existing tenants; default for new scaffolds):** the template now deploys through `projectDeploymentSpec` with injected descriptor getters and derives per-workflow `config` via the promoted `defineWorkflowConfig`. `operations/src/**` is project-owned, so existing tenants are NOT auto-rewritten; adopt the pattern at your discretion. A typed `operations/src/metadata.ts` stub (triggers / integrations / human checkpoints) is seeded as the home for deployment mechanics.
-
-## Verification
-
-- `pnpm -C external/<project>/operations exec elevasis-sdk om:ls /all-systems` returns systems (not an empty list).
-- After redeploy, the system-interface readiness probe no longer returns a stale-snapshot 503; a deliberate source/deploy mismatch now surfaces `STALE_OM_SNAPSHOT` with an actionable message.
-- `pnpm sync:verify` and `pnpm external:verify-template-family` pass after the sync.
-
-## Not handled by /git-sync
-
-- The **operations redeploy** (action 2) is a deliberate deploy, not a file sync — `/git-sync` will not run it.
-- **Adopting `projectDeploymentSpec` / wiring `metadata.ts`** in an existing tenant's `operations/src/**` (project-owned) is a manual, tenant-authored migration; the sync only seeds it into fresh scaffolds.

package/reference/claude-config/sync-notes/2026-05-30-client-source-and-om-profiles.md

@@ -1,39 +0,0 @@
-# Client Source and OM Client Profiles
-
-## Why this note exists
-
-The client-system release train adds first-class client source support across the platform and introduces top-level Organization Model client profiles in `@elevasis/core/organization-model`.
-
-Template-derived projects need the updated package baselines and guidance before relying on the shared clients UI, SDK client commands, or OM client-profile helpers. Tenant-authored client profile content remains project-owned and is not auto-generated by sync.
-
-## Applies to
-
-- Projects that use the shared `@elevasis/ui` clients feature.
-- Projects that create or update clients through `elevasis-sdk client:create` or `elevasis-sdk client:update`.
-- Projects that intentionally author real client profiles in `core/config/organization-model.ts`.
-- Projects that deploy operations bundles against the updated `@elevasis/sdk` baseline.
-
-## Required actions
-
-1. Pull the package baseline updates from the prepared `/sdk ship` train.
-2. Use the first-class client `source` field for direct clients, for example `word_of_mouth`, instead of storing the primary source only in ad hoc metadata.
-3. If the project intentionally authors OM client profiles, key `organizationModel.clients` by the canonical production `public.clients.id`; the profile `id` must match the same UUID.
-4. Keep tenant-specific client profile records, prompts, branding, workspace links, and custom values project-owned. Do not copy Elevasis or another tenant's client profiles into this project.
-5. Treat `Organization > Clients` as the semantic home for real client profiles and `Systems > Client Management` as the operational platform system.
-
-## Verification
-
-Run the checks that match the project surface:
-
-```bash
-pnpm -C core check-types
-pnpm -C operations check-types
-pnpm -C operations check
-pnpm -C ui check-types
-```
-
-For projects that author OM client profiles, also run the project-local OM validation or deploy preflight before publishing operations resources.
-
-## Not handled by /git-sync
-
-`/git-sync` can propagate the updated package baselines and this guidance, but it does not create tenant-specific `clients` rows, choose client source values, author OM client profile content, or decide whether a project should model a client profile at all. Maintainers must make those project-specific data and authoring decisions intentionally.

package/reference/claude-config/sync-notes/2026-06-02-knowledge-nested-group-routing.md

@@ -1,27 +0,0 @@
-# Knowledge nested-group routing fix
-
-## Why this note exists
-
-`@elevasis/ui` now exports `findOmTreeGroup` (and `OM_NESTED_TREE_GROUPS`) from `@elevasis/ui/knowledge`. The Knowledge Base `$nodeId` route must use `findOmTreeGroup` to resolve `group:` nodes instead of the direct `OM_TREE_GROUPS.find`. Without this, clicking the nested **Profile** and **Business Model** subgroups under Organization renders "Page Not Found", because those keys live in nested subgroups (not in the top-level `OM_TREE_GROUPS` list).
-
-## Applies to
-
-- Any project whose `ui/src/routes/knowledge/$nodeId.tsx` resolves `group:` route params against `OM_TREE_GROUPS`.
-- Projects on `@elevasis/ui` < `2.44.0`.
-
-## Required actions
-
-1. Bump `@elevasis/ui` to `^2.44.0` and install.
-2. In `ui/src/routes/knowledge/$nodeId.tsx`:
-   - Replace the `OM_TREE_GROUPS` import from `@elevasis/ui/knowledge` with `findOmTreeGroup`.
-   - Replace `OM_TREE_GROUPS.find((candidate) => candidate.key === groupKey)` with `findOmTreeGroup(groupKey)`.
-
-## Verification
-
-- `pnpm -C ui check-types` passes.
-- `pnpm -C ui build` succeeds.
-- In the running app, the Knowledge Base **Profile** and **Business Model** rows under Organization open a describe view instead of "Page Not Found".
-
-## Not handled by /git-sync
-
-`/git-sync` does not edit project route source. The `$nodeId.tsx` swap to `findOmTreeGroup` is a manual route edit (or applied via `/external sync` route-baseline merge); `/git-sync` only surfaces this note and installs the bumped dependency.

package/reference/claude-config/sync-notes/2026-06-02-nest-projects-under-platform.md

@@ -1,45 +0,0 @@
-# Nest `projects` under `platform` (fleet-wide OM reparent)
-
-## Why this note exists
-
-The shared `@elevasis/ui` `deliveryManifest` now emits `systemId: 'platform.projects'` (it consumes the republished `@elevasis/core` constant `PROJECTS_SYSTEM_ID`, which flipped from `'projects'` to `'platform.projects'`). Any tenant Organization Model that still declares a **root-level** `projects` system will fail `validateManifests` on boot once it installs the new `@elevasis/ui`, because the delivery manifest references a `systemId` that does not exist in the tenant OM.
-
-This is a fleet-wide convention change: `projects` is now a child of `platform` (canonical id `platform.projects`) everywhere — Elevasis, the template, and every derived tenant.
-
-## Applies to
-
-- Every tenant whose `core/config/organization-model/` declares a root `projects` system (work-item / checkpoint shape) and a root `platform` system to nest it under.
-- Confirmed in this train: `ZentaraHQ`, `nirvana-marketing`. Run the verification below in any other derived project before installing the new `@elevasis/ui`.
-
-## Required actions
-
-Apply these in your own `core/config/organization-model/` (this is project-owned OM content — `/external sync` does NOT overwrite it; reparent it yourself via `/om`):
-
-1. **Reparent the system.** In `systems.ts`, move the `projects` system block under the existing `platform` system. Set `id: 'platform.projects'` and add `parentSystemId: 'platform'`. Leave the object key, route `path`, and icon as-is.
-2. **Rewrite ontology IDs.** Change every `projects:*` ontology id to `platform.projects:*` (objects, links, actions, catalogs, events, surfaces) — including all cross-references (`ownerSystemId`, `objectType`, `catalogType`, `from`/`to`).
-3. **Navigation.** In `navigation.ts`, update any `targets: { systems: ['projects'] }` to `['platform.projects']`.
-4. **Profile / roles.** In `profile.ts` (or `roles.ts`), update `deliveryFeatureId` / role `responsibleFor` references from `projects` to `platform.projects`.
-5. **Tests.** Update `core/config/organization-model.test.ts`, `organization-model.contract.test.ts`, and `ui/src/routes/__tests__/__root.test.tsx` assertions that reference the `projects` system id, parent, or ontology ids.
-6. **Install + reparent together.** Bump `@elevasis/core` and `@elevasis/ui` (see the dependency baseline written by `/external sync`), reparent the OM in the **same** change, then `pnpm -C core test` and `pnpm -C ui check-types` before booting the app. Do not install the new `@elevasis/ui` while the OM still has root `projects`.
-
-Route file paths (`ui/src/routes/projects*.tsx`) stay at `/projects`; only OM ids and nav/profile targets change.
-
-## Verification
-
-```bash
-# 1. Find any remaining root projects references
-grep -rn "'projects'\|projects:" core/config/organization-model ui/src/routes
-
-# 2. Template-family coherence
-pnpm -C core test
-pnpm -C ui check-types
-pnpm -C ui test:contracts
-
-# 3. Boot must not throw validateManifests (deliveryManifest systemId must resolve)
-```
-
-`platform.projects` must resolve as a child System of `platform`, and the delivery surface must render under it.
-
-## Not handled by /git-sync
-
-`/git-sync` and `/external sync` will deliver the new `@elevasis/core` + `@elevasis/ui` dependency baselines and this note, but they will **not** edit your `core/config/organization-model/` — tenant OM content is project-owned (`sync-preservation`). The reparent in steps 1-5 is manual per tenant. Installing the new `@elevasis/ui` without doing the reparent first will crash the app on boot.

package/reference/claude-config/sync-notes/2026-06-03-skill-autogen-and-client-skill.md

@@ -1,34 +0,0 @@
-# Skill autogen and `/client` skill
-
-## Why this note exists
-
-This train adds the template `/client` skill, a generated `.claude/Overview.md` skill and bundled-rules inventory, `skill-coverage.json`, and capability-query guidance that points agents to `elevasis-sdk cli` as the live command surface.
-
-It also ships new `@elevasis/sdk` CLI support for `skill:scaffold` and `skill:check-coverage`, and extends `elevasis-sdk check` so future CLI domains cannot land without either skill ownership or an explicit waiver.
-
-## Applies to
-
-- Every template-derived project that carries `.claude/` skills from `external/_template`.
-- Projects that use `elevasis-sdk check` as their local validation gate.
-- Operators using Claude Code skills to discover or manage clients through the existing `client:*` CLI domain.
-
-## Required actions
-
-1. Run the prepared external sync so `.claude/skills/client/`, `.claude/Overview.md`, `.claude/registries/skill-coverage.json`, and the updated setup/elevasis skill guidance are copied from the template.
-2. Install the new `@elevasis/sdk` baseline in `operations/package.json` after the SDK publish stage.
-3. Run `pnpm -C operations exec elevasis-sdk check` in each project to verify skill coverage against the live CLI catalog.
-4. Use `elevasis-sdk cli` when answering "what can I do?" or auditing available CLI domains; do not rely on stale prose inventories.
-
-## Verification
-
-```bash
-pnpm -C operations exec elevasis-sdk cli client
-pnpm -C operations exec elevasis-sdk check
-pnpm -C operations exec elevasis-sdk skill:check-coverage
-```
-
-The project should contain `.claude/skills/client/SKILL.md`, `.claude/Overview.md`, and `.claude/registries/skill-coverage.json` after sync.
-
-## Not handled by /git-sync
-
-`/git-sync` does not infer skill coverage or regenerate local command inventories. It can deliver the synced files, but maintainers still need to install the new SDK baseline and run the verification commands above. Project-owned `CLAUDE.md` content remains verify-only; the authoritative generated inventory is `.claude/Overview.md`.

package/reference/claude-config/sync-notes/2026-06-04-scaffold-registry-lane-severity.md

@@ -1,34 +0,0 @@
-# Scaffold registry lane severity annotations
-
-## Why this note exists
-
-This train adds `sync_lane_severity` annotations to the scaffold registry schema and moves external sync lane-severity ownership from hardcoded script sets into registry metadata.
-
-The change is intended to keep project sync behavior the same while making the registry the single edit point for paths that need critical manual-merge handling or optional-feature-selection treatment.
-
-## Applies to
-
-- Template-derived projects that use `/external sync` or `pnpm sync:apply` from the Elevasis monorepo.
-- Projects that receive `@elevasis/core` package-baseline updates through `core/package.json` or `operations/package.json`.
-- Operators reviewing external-sync plans that mention critical manual-merge or optional-feature-selection paths.
-
-## Required actions
-
-1. Run the prepared external sync from the release train so this note reaches derived projects.
-2. After the `@elevasis/core` publish stage, install the prepared core package baseline in template-derived project package files.
-3. Review any sync plan lane labels against the registry entry metadata before widening a manifest or applying catch-up work.
-
-No project-authored Organization Model content should be overwritten for this train.
-
-## Verification
-
-```bash
-pnpm sync:verify
-pnpm exec tsx scripts/external/sync-apply.ts --all --dry-run --manifest apps/docs/content/docs/in-progress/active-development/sdk-changes/ship/_external-sync-prep.json --strict-manifest
-```
-
-The strict manifest dry-run should authorize only the prepared sync note and the core package-baseline cascades.
-
-## Not handled by /git-sync
-
-`/git-sync` can deliver committed file changes, but it does not publish `@elevasis/core`, install package baselines, validate scaffold registry metadata, or enforce manifest-scoped external-sync write authorization.

package/reference/claude-config/sync-notes/2026-06-05-appearance-app-mode-decouple.md

@@ -1,29 +0,0 @@
-# Appearance Page Decoupled From App-Mode
-
-## Why this note exists
-
-The Settings → Appearance page used to be hard-coupled to `dev-centric` app-mode: scaffold removed it under `--client-centric`, every `/external sync` actively deleted it (planner `delete` special-case), and verify forbade it for `client-centric` projects. That made the page silently vanish on every sync for client-centric tenants.
-
-This train decouples Appearance from app-mode. Appearance is now an optional standalone page available in any mode. The only remaining app-mode difference is the `OrganizationSwitcher` in the topbar.
-
-No npm publish is involved: the page renders the already-published `@elevasis/ui@2.46.0` `AppearanceSettings` component. The substrate changes (`scripts/external/*`) and the `_template` route are monorepo-internal and propagate through `/external sync`.
-
-## Applies to
-
-- All template-derived projects under `external/` that lack `ui/src/routes/settings/appearance.tsx`.
-- Confirmed pending at prep time: `nirvana-marketing` (sync planner `writes=1` for the appearance route). `contemplative-records` already restored it; `ZentaraHQ` shows no pending write.
-
-## Required actions
-
-1. The new template route `ui/src/routes/settings/appearance.tsx` propagates automatically via `/external sync` (registry entry `external-sync-feature-route-baseline`, `sync-preservation`). No manual file copy needed — running the prepared sync applies it.
-2. **Per-tenant nav entry is NOT propagated.** `core/config/organization-model/navigation.ts` is project-owned (sync-preservation). For any tenant that should surface Appearance in its sidebar, manually add a `settings-appearance` entry to `navigation.sidebar.bottom.settings.children` (order `50`, after `settings-webhooks`), pointing at the appearance route.
-
-## Verification
-
-- After sync: `pnpm -C external/<project>/ui check-types` passes with the new route present.
-- `pnpm sync:verify` reports `writes=0` for the synced project's `sync-plan`.
-- The Appearance entry renders in the Settings sidebar only after the per-tenant `navigation.ts` entry is added (step 2).
-
-## Not handled by /git-sync
-
-`/git-sync` does not author the per-tenant `navigation.ts` nav entry — it is project-owned business content and must be added by hand per tenant. `/git-sync` also will not retroactively restore the route for tenants that were previously stripped by the old delete special-case; run the prepared `/external sync --all` to apply the new non-deleting baseline.

package/reference/claude-config/sync-notes/2026-06-05-ontology-endpoint-rename-and-knowledge-browser-ui.md

@@ -1,86 +0,0 @@
-# Ontology `surface` → `endpoint` rename + Knowledge Browser UI upgrades
-
-## Why this note exists
-
-This release bumps **both** `@elevasis/core` and `@elevasis/ui`. Two distinct changes ride it:
-
-1. **Breaking OM contract rename (`@elevasis/core`).** The ontology kind `surface` was renamed to
-   `endpoint` to stop colliding with **navigation surfaces** (shell sidebar routes). The published
-   contract changed: the `OntologyKind` enum member `'surface'` is now `'endpoint'`, the ontology ID
-   namespace `…:surface/…` is now `…:endpoint/…`, `ontology.surfaces` is now `ontology.endpoints`,
-   and the exported `OntologySurfaceType` / `OntologySurfaceTypeSchema` are now
-   `OntologyEndpointType` / `OntologyEndpointTypeSchema`. **There is no back-compat alias** (hard
-   rename — the kind was near-dormant). Any tenant OM that still declares a `:surface/` **ontology**
-   ID will fail validation once it installs the new `@elevasis/core`.
-
-2. **Knowledge Browser UI upgrades (`@elevasis/ui`).** Three additive, platform-substrate
-   enhancements that tenants get purely on the `@elevasis/ui` bump — no authoring change required:
-   full `ClientProfile` detail rendering in the Clients panel, clickable group child cards
-   (Profile → Identity/Branding navigate like the tree), and explanatory hover tooltips on
-   platform-vocabulary badges/edge labels. The ontology tree row + its tooltip now read
-   **"Endpoints"** instead of "Surfaces", consistent with change #1.
-
-## Applies to
-
-- **Change #1 (ontology rename):** every tenant whose `core/config/organization-model/` declares any
-  ontology ID with a `:surface/` segment (i.e. an entry under a System's `ontology.surfaces`).
-  **Confirmed in this train: ZERO live tenants carry any `:surface/` ontology ID** (verified by a
-  repo-wide grep across all of `external/` — only `_template` carried one, migrated in this train).
-  The 3 live derived projects (ZentaraHQ, nirvana-marketing, contemplative-records) inherit
-  `endpoint/` cleanly. Run the verification below anyway before installing the new `@elevasis/core`.
-- **Change #2 (UI upgrades):** every template-derived project — they render on the `@elevasis/ui`
-  bump with no further action.
-
-## Required actions
-
-`/git-sync` / `/external sync` delivers the new `@elevasis/core` + `@elevasis/ui` dependency
-baselines and this note. The dependency bumps install automatically; the ontology-ID rewrite (only if
-your project authored any) is project-owned OM content and is **not** auto-applied.
-
-1. **Install the baselines together.** Bump `@elevasis/core` and `@elevasis/ui` in the same change
-   (the baseline write from sync covers `core/package.json`, `operations/package.json`, and
-   `ui/package.json`). Do not install the new `@elevasis/core` while your OM still has any `:surface/`
-   **ontology** ID.
-2. **Rename any ontology `surface/` IDs (only if present).** In `core/config/organization-model/`,
-   change every ontology ID `…:surface/<name>` to `…:endpoint/<name>`, and the containing
-   `ontology: { surfaces: { … } }` key to `ontology: { endpoints: { … } }`. Update every
-   cross-reference (`ownerSystemId`, `route`, links, etc.). Most tenants have nothing to change here.
-3. **Do NOT touch navigation surfaces.** This is the critical disambiguation. The rename is
-   ontology-only. Leave `system.surfaces`, `ui.surfaces`, sidebar `SidebarSurfaceNode`s, the
-   `surfaceType` route field, the graph node kind `surface`, and `SurfaceDescribeView` **unchanged** —
-   those legitimately own the word "surface" for shell routing and are orthogonal to the ontology kind.
-4. **Update tests.** If your `core/config/organization-model.test.ts` or contract tests assert
-   `compiled.ontology.surfaces` or a `:surface/` ontology ID, rename them to `.endpoints` /
-   `:endpoint/`. Leave any `ui.surfaces` / navigation-surface assertions alone.
-5. **Verify, then boot.** Run the verification block, then `pnpm -C core test` and
-   `pnpm -C ui check-types` before booting the app.
-
-## Verification
-
-```bash
-# 1. Find any remaining ontology surface/ IDs (navigation surfaces are fine — see discriminator)
-grep -rn ":surface/\|ontology.surfaces\|OntologySurfaceType" core/config/organization-model
-
-# Discriminator while reading hits:
-#   ontology (RENAME)  -> a ":surface/" ID segment, "ontology: { surfaces: ... }", OntologySurface*
-#   navigation (KEEP)  -> bare system.surfaces / ui.surfaces, SidebarSurface*, surfaceType
-
-# 2. Template-family coherence
-pnpm -C core test
-pnpm -C ui check-types
-pnpm -C ui test:contracts
-
-# 3. Boot must not throw OM validation (no unknown OntologyKind)
-```
-
-`OntologyKindSchema` must accept `endpoint` and reject `surface`; no `:surface/` ontology ID may
-remain. Navigation surfaces must still resolve and render in the sidebar.
-
-## Not handled by /git-sync
-
-- `/git-sync` and `/external sync` deliver the `@elevasis/core` + `@elevasis/ui` dependency baselines
-  and this note, but they do **not** edit your `core/config/organization-model/` — tenant OM content
-  is project-owned (`sync-preservation`). The `surface/` → `endpoint/` ontology-ID rewrite in steps
-  2–4 is manual per tenant (a no-op for every current live tenant, which carries none).
-- The Knowledge Browser UI upgrades (change #2) require **no** action — they are entirely inside
-  `@elevasis/ui` and appear on the bump.