@elevasis/sdk 1.29.0 → 1.30.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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