@elevasis/sdk 1.15.0 → 1.15.1

package/dist/test-utils/index.js

@@ -6752,6 +6752,7 @@ createAdapter("acqDb", [
   "markProposalReviewed",
   "updateCloseLostReason",
   "updateFees",
+  "cacheInstantlyThreadIds",
   "transitionItem",
   "setContactNurture",
   "cancelSchedulesAndHitlByEmail",
@@ -24262,6 +24263,7 @@ var mockAcqDb = (overrides) => createMockAdapter(
     "markProposalReviewed",
     "updateCloseLostReason",
     "updateFees",
+    "cacheInstantlyThreadIds",
     "transitionItem",
     "setContactNurture",
     "cancelSchedulesAndHitlByEmail",

package/dist/types/worker/adapters/lead.d.ts

@@ -4,7 +4,7 @@
  * Typed wrapper over platform.call() for acquisition lead management.
  * Singleton export -- no credential needed (platform tool).
  *
- * 51 methods covering lists, companies, contacts, deals, list-stage updates, deal-sync, deal notes, deal tasks, enrichment, and social monitoring operations.
+ * 56 methods covering lists, companies, contacts, deals, list-stage updates, deal-sync, deal notes, deal tasks, enrichment, and social monitoring operations.
  * organizationId is injected server-side by the dispatcher -- never sent from the SDK.
  */
 import { type TypedAdapter } from './create-adapter.js';

package/dist/worker/index.js

@@ -4998,6 +4998,7 @@ var acqDb = createAdapter("acqDb", [
   "markProposalReviewed",
   "updateCloseLostReason",
   "updateFees",
+  "cacheInstantlyThreadIds",
   "transitionItem",
   "setContactNurture",
   "cancelSchedulesAndHitlByEmail",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.15.0",
+  "version": "1.15.1",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -50,7 +50,7 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.15.0",
+    "@repo/core": "0.15.1",
     "@repo/typescript-config": "0.0.0"
   },
   "scripts": {

package/reference/claude-config/rules/ui.md

@@ -104,13 +104,9 @@ For real-time updates, feature surfaces use the local singleton wrapper:
 import { sseConnectionManager } from '@/lib/sse/SSEConnectionManager'
 ```
 
-**Required env vars:**
+**WorkOS config:**
 
-```bash
-VITE_WORKOS_CLIENT_ID=client_...
-VITE_WORKOS_REDIRECT_URI=http://localhost:4300/auth-redirect
-VITE_WORKOS_SIGNOUT_URI=http://localhost:4300/login
-```
+WorkOS `clientId`, `redirectUri`, and `signoutUri` are hardcoded in `ui/src/config/workos.ts` -- no UI env vars are required to run the template. Edit that file if a fork needs a different WorkOS client. The dev server runs on port `4300` with Vite `strictPort: true`, so a second `pnpm -C ui dev` on the same machine fails fast instead of drifting.
 
 The API URL is centralized in `ui/src/lib/constants/api.ts`. In the current template it is hard-coded to `https://api.elevasis.io`, so if the bootstrap is repointed to another API target, that file is the source of truth.
 

package/reference/claude-config/sync-notes/2026-05-02-crm-ownership-next-action.md

@@ -0,0 +1,58 @@
+# CRM Ownership and Next-Action Projection
+
+## Why this note exists
+
+This release train ships CRM ownership and next-action projection across the shared core, UI, API, and Elevasis operations bundle.
+
+Shared CRM deal responses now carry nullable `ownership` and `nextAction` values derived from activity history. The CRM list and detail surfaces render the move owner directly, and detail actions prefer the projected `nextAction` before falling back to ownership-aware derivation. The Elevasis operations bundle also writes canonical follow-up and deferred-next-step activity events so ownership can sort consistently.
+
+## Applies to
+
+Template-derived projects that:
+
+- consume `@elevasis/core/business/acquisition/api-schemas` deal list or detail response types
+- render CRM list, detail, or action surfaces from `@elevasis/ui`
+- author CRM operations workflows that append or interpret deal activity events
+- read `activity_log` rows and classify who owns the next move
+
+Projects with no CRM surface and no `acq_deals` workflow logic can ignore this train.
+
+## Required actions
+
+1. Pull template changes with `/git-sync` after this train publishes so package baselines for `@elevasis/core` and `@elevasis/ui` are refreshed.
+
+2. Upgrade shared packages in the derived project after the publish stages complete:
+
+```bash
+pnpm up @elevasis/core @elevasis/ui --latest
+```
+
+3. Audit any project-owned CRM workflow code that writes activity events. Outbound follow-up should emit `followup_email_sent`, and "lead will check / get back to us" replies should emit `lead_deferred_next_step` when they defer our next action.
+
+4. Audit any project-owned CRM UI code that computes available actions locally. Prefer the server-projected `nextAction` when present, and suppress send-reply affordances when `ownership` is `them`.
+
+5. If the project deploys an operations bundle with CRM reply or follow-up handlers, redeploy that bundle after package upgrades so runtime activity writes match the new ownership derivation:
+
+```bash
+pnpm -C operations exec elevasis-sdk deploy --prod
+```
+
+## Verification
+
+After upgrading:
+
+- `pnpm check-types` passes in project packages that consume CRM types or UI.
+- CRM list rows show the expected move owner for deals with inbound replies, outbound replies, follow-ups, reminders, booking nudges, and deferred-next-step replies.
+- CRM detail actions expose Send Reply only when the server-projected action and ownership allow it.
+- Operations tests or smoke probes confirm follow-up handlers emit `followup_email_sent`.
+- A CRM reply where the lead says they will check internally records `lead_deferred_next_step` and sorts after the inbound reply event.
+
+## Not handled by /git-sync
+
+`/git-sync` does not:
+
+- publish `@elevasis/core` or `@elevasis/ui`
+- run package upgrades inside derived projects
+- redeploy project-owned operations bundles
+- rewrite project-owned CRM workflow logic that still emits legacy activity event names
+- verify or repair historical `activity_log` rows in project databases

package/reference/claude-config/sync-notes/2026-05-02-template-hardcode-workos-config.md

@@ -0,0 +1,56 @@
+# Template WorkOS Hardcode + Strict Dev Port
+
+## Why this note exists
+
+The template UI no longer reads WorkOS configuration from `VITE_WORKOS_*` env vars. WorkOS `clientId`, `redirectUri`, and `signoutUri` are hardcoded in a new file `ui/src/config/workos.ts` so a freshly bootstrapped template runs without any UI `.env` setup. The Vite dev server now uses `strictPort: true` on port `4300` so a second `pnpm -C ui dev` on the same machine fails fast instead of silently drifting to another port.
+
+This sync moves three pieces into derived projects:
+
+- `ui/src/config/workos.ts` -- new merge-baseline file holding `clientId`, `redirectUri`, `signoutUri`
+- `ui/src/main.tsx` and `ui/src/routes/__root.tsx` -- merge-regions updates that import `WORKOS_CONFIG` from `@/config/workos` instead of reading `import.meta.env.VITE_WORKOS_*`
+- `ui/vite.config.ts` -- `strictPort: true` added next to `port: 4300`
+- `ui/.env.example` -- WorkOS section removed (replaced with a single comment pointing at `ui/src/config/workos.ts`)
+- `.claude/rules/ui.md` and `CLAUDE.md` -- prose updated; project-owned `CLAUDE.md` is verify-only and the project keeps its own narrative
+
+`nirvana-marketing` and `ZentaraHQ` already received `ui/src/config/workos.ts`, the `strictPort` flag, and the `.claude/rules/ui.md` baseline as prep-gate repairs in the previous train. This note formally attributes those changes to an owning task doc and covers any remaining template-derived projects.
+
+## Applies to
+
+Template-derived projects that:
+
+- run a WorkOS-authenticated UI from `ui/src/main.tsx` and `ui/src/routes/__root.tsx`
+- run the Vite dev server on port `4300`
+- have a project-owned `ui/src/config/workos.ts` (created via prep-gate repair) or are seeing it land for the first time on this sync
+- maintain a `ui/.env` file that previously set `VITE_WORKOS_CLIENT_ID`, `VITE_WORKOS_REDIRECT_URI`, or `VITE_WORKOS_SIGNOUT_URI`
+
+Projects with no WorkOS surface or no Vite dev server are not affected.
+
+## Required actions
+
+1. Pull template changes with `/git-sync` after this train publishes so the WorkOS hardcode and strict-port baselines reach the project's UI shell.
+
+2. Confirm the project's `ui/src/config/workos.ts` reflects the WorkOS client ID the project should authenticate against. The template ships the platform team's dev-tier `clientId`; client-facing projects must overwrite that value with the project's own WorkOS client ID before going to production. Edit the literal in `ui/src/config/workos.ts` -- no env vars are involved.
+
+3. Stop providing `VITE_WORKOS_CLIENT_ID`, `VITE_WORKOS_REDIRECT_URI`, and `VITE_WORKOS_SIGNOUT_URI` in `ui/.env`. They are no longer read. Delete the entries to keep the file honest. The WorkOS values now live in `ui/src/config/workos.ts`.
+
+4. Confirm `ui/vite.config.ts` carries `strictPort: true` next to `server.port: 4300`. If a second dev server starts on the same port, expect a hard failure instead of a drift to `4301`.
+
+5. If the project hand-rolled an env-vars notice component or a `REQUIRED_ENV_VARS` array around WorkOS, remove it. `createElevasisApp` no longer needs the `MissingEnvNotice` prop now that `clientId` is always truthy.
+
+## Verification
+
+After upgrading:
+
+- `pnpm -C ui check-types` and `pnpm -C ui build` pass with `WORKOS_CONFIG` imported from `@/config/workos`.
+- `pnpm -C ui dev` boots on `4300`. Starting a second `pnpm -C ui dev` in another terminal fails with a port-in-use error instead of incrementing to `4301`.
+- WorkOS sign-in and sign-out still round-trip through the project's WorkOS tenant. Sign-out lands on the URL configured in `ui/src/config/workos.ts` (`signoutUri`).
+- `grep -r VITE_WORKOS_ ui/src` returns nothing.
+
+## Not handled by /git-sync
+
+`/git-sync` does not:
+
+- delete `VITE_WORKOS_*` entries from project-local `ui/.env` files
+- overwrite `ui/src/config/workos.ts` if the project has already customized the `clientId` for a non-default WorkOS tenant (the file is merge-baseline; customizations are preserved)
+- update WorkOS dashboard redirect URIs or CORS origins for projects that run the dev server on a non-`4300` port; if the project changed the dev port, it must also change the WorkOS dashboard accordingly
+- redeploy any project-owned operations bundle; this train is UI-shell only