@elevasis/sdk 1.41.1 → 1.43.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.41.1",
+  "version": "1.43.0",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {
@@ -58,7 +58,7 @@
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
     "zod": "^4.1.0",
-    "@repo/core": "0.57.0",
+    "@repo/core": "0.58.0",
     "@repo/typescript-config": "0.0.0",
     "@repo/eslint-config": "0.0.0"
   },

package/reference/claude-config/sync-notes/2026-07-28-agent-reply-is-its-own-field.md

@@ -0,0 +1,84 @@
+# The agent's reply to the user is now its own field
+
+## Why this note exists
+
+**Your agents' user-facing text was being silently corrupted, and no layer could catch it.**
+
+Measured across three 14-turn production sessions on 2026-07-28: 42 of 42 turns passed, and **20
+corruption sites landed across 12 of the 42 replies — 28.6%**. The model emits a JSON escape
+sequence for an em-dash and then completes it with the next letter of the sentence, so
+`Hold on — red-line for me` becomes `Hold on \red-line for me`. That parses as valid JSON, satisfies
+the response schema, and passes validation. There is no error state, no retry, and no provider-side
+fix to wait for. The characters are simply gone from the stored transcript.
+
+The cause is where the text sat in the schema, not the text itself. The reply used to be one variant
+of an `anyOf` union nested inside the `nextActions` array. In the very same responses, the flat
+top-level `reasoning` string carried **33 em-dashes with zero corruption** while the nested reply
+text carried **59 em-dashes with 20 corruption sites** — and `reasoning` is the longer field.
+
+The reply is now a flat top-level `message` property, declared beside `reasoning` rather than nested
+inside the actions array. Re-measured over a fresh multi-turn session: **42 em-dashes, zero
+corruption.**
+
+**This supersedes the two-field description in `2026-07-27-agent-strict-output-and-turn-drift.md`.**
+That note described the iteration response as `nextActions` then `reasoning`. It is now three
+fields, in this order: `nextActions`, `message`, `reasoning`. The ordering rationale from that note
+is unchanged and still holds — `reasoning` stays last so the actions and the reply are already on the
+wire before any mid-response drift can start.
+
+**`message` is required for session-capable agents.** This is not a detail you can ignore. When the
+field shipped as optional, the model filled it **zero times in three turns** and those turns produced
+no user-facing message at all. Under grammar-constrained sampling the model fills keys in declaration
+order, so `nextActions` is chosen before the model has reasoned about the reply, `complete` is the
+cheapest legal action, and a skippable `message` then gets skipped. Making it required costs nothing:
+an empty or whitespace-only value is suppressed and produces no message bubble.
+
+## Applies to
+
+- **Every `sessionCapable: true` agent.** `message` is the only field the user sees, so this is the
+  field that was being damaged.
+- **Agents on Anthropic models**, where the enforced-schema path is active. On the unenforced path
+  the platform still accepts a message delivered the old way, as an entry in the actions list, so
+  nothing breaks mid-transition.
+- **Anything that reads stored assistant messages** — a transcript, an export, a summarizer, a
+  downstream workflow. Already-stored text is not repaired by this change; see below.
+- **No agent definition changes are required.** You do not edit your agents. The shape lives in the
+  runtime your bundle carries.
+
+## Required actions
+
+1. **Take the `@elevasis/sdk` baseline bump** this train propagates, then reinstall in `operations/`
+   so the new worker bundle is present.
+2. **Redeploy your operations bundle.** This is the step that actually closes the defect. The
+   response schema is emitted by the runtime inlined into your deployed bundle, so an existing
+   deployment keeps emitting the old nested shape — and keeps corrupting replies — until it is
+   redeployed:
+
+   ```bash
+   pnpm -C operations exec elevasis-sdk deploy --prod
+   ```
+
+   A platform-side deploy does not fix this for you, and neither does the reinstall on its own.
+
+3. **If you read or display stored assistant text, do not treat old records as clean.** Nothing is
+   rewritten retroactively. Transcripts written before your redeploy keep whatever corruption they
+   already have.
+
+## Verification
+
+- Run a session and prompt for a reply likely to contain an em-dash — asking the agent to summarize
+  something in a couple of sentences is usually enough. Confirm the reply arrives, and read it: the
+  signature failure is a missing letter immediately after where punctuation belonged
+  (`Hold on \red-line`), not a visible error.
+- **Confirm every turn produced an assistant message at all.** A turn that completes with no message
+  is the symptom of a bundle that has the flat field but not the required flag — that combination
+  only exists in an unreleased build, but it is the one failure worth ruling out explicitly.
+- Check the observability rows for an execution: iteration calls should still record the enforced
+  path with no fallback reasons. This change does not push the schema off it.
+
+## Not handled by /git-sync
+
+- **The redeploy.** `/git-sync` commits and pushes the propagated dependency baseline. The corruption
+  continues on your deployed agents until you run action 2 above.
+- **Repairing existing transcripts.** No backfill is performed, and none is possible — the dropped
+  characters were never received.

package/reference/claude-config/sync-notes/2026-07-30-login-screen-and-member-provisioning-state.md

@@ -0,0 +1,114 @@
+# Your login route is now a stub, and pre-provisioned members become visible
+
+## Why this note exists
+
+Two independent defects in this train, plus one change to what your `package.json` is required to
+provide. All three reach you through the `@elevasis/ui` and `@elevasis/core` baseline bump.
+
+**1. The login route's authentication logic moved into the package.** It used to exist five times —
+once in Command Center and once in each of the four template-family projects — and all four tenant
+copies were byte-identical, same 5,729 bytes, same hash. That duplication had a real cost: an
+invited user who did not yet have an account was sent to the **sign-in** screen instead of the
+**sign-up** screen and could never complete registration, and fixing it meant editing the same line
+in five files. Any project that missed the propagation stayed broken silently.
+
+`login.tsx` is now a thin route stub. It registers the path and passes your branding; everything
+else — the invitation-token branch, the sign-up versus sign-in decision, the WorkOS `context`
+branch, `returnTo` handling, and the authenticated-user redirect — lives in `LoginScreen`, exported
+from `@elevasis/ui/features/auth` alongside `validateLoginSearch`.
+
+The fix itself already reached you in a previous cycle. This train removes the duplication that
+caused it, verified in a browser before shipping: an invitation token now lands on the WorkOS
+`/invite` accept-invitation screen rather than the sign-in screen.
+
+**The standing consequence, stated plainly: every future login change is now a package release.**
+Auth-entry bugs are exactly the class you most want to hotfix quickly, and you can no longer do that
+by editing your own file. The trade was made deliberately — five-way silent divergence was judged
+the worse risk, since your updates already gate on sync regardless.
+
+**2. Members who were invited but have not yet signed up were invisible on your settings page.**
+The members list read WorkOS as the primary source, so a member who exists in the platform database
+but has no WorkOS identity yet did not appear at all — your member count was wrong, not just your
+detail view. `MembershipService.listMemberships` now reads the platform database as the primary set
+and enriches from WorkOS where a link exists, and `MembershipWithDetails` gains an optional
+`provisioningState` of `'linked' | 'pre_provisioned' | 'workos_only'`.
+
+Correct counts reached you the moment the API deployed — that half was additive and server-side.
+The published `OrgMembersList` renders the new distinction, so the column only appears after this
+baseline bump.
+
+**3. `@elevasis/ui` now declares two peer dependencies it previously required but did not name:**
+`@workos-inc/authkit-react` and `@supabase/supabase-js`. This is a published-contract change, not a
+new requirement — the package always needed both at runtime. `@supabase/supabase-js` in particular
+had been shipping undeclared for a long time: it is reachable from roughly twenty published entry
+points through a shared bundle chunk, including entry points whose own subpath never mentions
+Supabase.
+
+You almost certainly already have both installed, since the template has depended on them directly
+for as long as it has had auth. Practical risk is low. What changes is that a project missing either
+one now gets an honest peer warning at install time instead of a runtime failure with no
+explanation.
+
+## Applies to
+
+- **Every template-family project.** All four `login.tsx` copies are affected and all four are
+  currently identical, so this propagates cleanly unless you have edited yours.
+- **Any project whose settings page renders `OrgMembersList`** — that is the published component,
+  not a local copy, so the new column arrives with the baseline bump.
+- **Any project that invites members.** The invisible-member defect affected your own settings page,
+  not only platform admin.
+- **Not applicable to your agents or operations bundle.** Nothing here touches the worker runtime,
+  and no redeploy of `operations/` is required.
+
+## Required actions
+
+1. **Take the `@elevasis/ui` and `@elevasis/core` baseline bump** this train propagates, then
+   reinstall in `ui/`.
+
+2. **Clear the Vite cache and restart your dev server.** This is not optional hygiene — a stale
+   `.vite` cache serves the _old_ bundle while every gate reports green, which is the specific way
+   this failure hides:
+
+   ```bash
+   rm -rf ui/node_modules/.vite
+   pnpm -C ui dev
+   ```
+
+3. **If you customized `login.tsx`, merge rather than accept.** The sync engine preserves a diverged
+   copy instead of overwriting it, which means a customized login route will silently keep its own
+   duplicated auth logic and miss future fixes. Port your customization onto the stub shape: the
+   branding values are props, and `appConfig={{ workosOrganizationId: __ELEVASIS_WORKOS_ORG_ID__ }}`
+   carries the org binding.
+
+4. **You may now drop the local `signUp` override in `ui/src/routes/__tests__/auth-routes.test.tsx`.**
+   The shared `mockUseAuth` in `@elevasis/ui/test-utils` gained `signUp`, so the local layer is
+   redundant. Leaving it in place is harmless — it just shadows an identical value.
+
+## Verification
+
+- **Sign in normally.** This is the check that matters most, because the login route is the only
+  entry point to your application and it was rewritten. Confirm the logo and the Sign In button
+  render for a signed-out visitor, and that signing in lands you where you expect.
+- **Visit `/login` while already signed in.** You should be redirected to `/`, and `/login?returnTo=/some-path`
+  should redirect to that path.
+- **Open your settings members page** and confirm invited-but-not-yet-registered members appear.
+  Compare the count against the invitations you have actually sent — a member who has not signed up
+  yet should now be listed rather than missing.
+- **Read the installed bundle, not the version number.** A bumped pin and a green sync report are
+  claims about intent; the installed file is the only ground truth:
+
+  ```bash
+  grep -rl "LoginScreen" ui/node_modules/@elevasis/ui/dist/features/auth/
+  ```
+
+  No match means the install did not actually land, regardless of what `package.json` says.
+
+## Not handled by /git-sync
+
+- **The Vite cache clear and dev-server restart.** `/git-sync` propagates and commits the dependency
+  baseline. Your running dev server keeps serving the previously cached bundle until you do step 2
+  yourself, and it will look like the sync did nothing.
+- **Merging a customized `login.tsx`.** If your copy has diverged, the engine deliberately preserves
+  it and does not merge for you. That file will keep its old duplicated auth logic until you port it
+  by hand.
+- **Removing the redundant `signUp` test override.** Cosmetic, and left to you.

package/reference/sdk/platform-tools/index.mdx

@@ -130,12 +130,11 @@ Call any supported LLM from your workflow with no API keys required. Keys are re
 
 **Supported models:**
 
-| Provider     | Models                                                    |
-| ------------ | --------------------------------------------------------- |
-| `google`     | `gemini-3-flash-preview`, `gemini-3.1-flash-lite-preview` |
-| `openai`     | `gpt-5`, `gpt-5.4-mini`, `gpt-5.4-nano`                   |
-| `anthropic`  | `claude-sonnet-5`                                         |
-| `openrouter` | `openrouter/z-ai/glm-5`                                   |
+| Provider     | Models                                  |
+| ------------ | --------------------------------------- |
+| `openai`     | `gpt-5`, `gpt-5.4-mini`, `gpt-5.4-nano` |
+| `anthropic`  | `claude-sonnet-5`                       |
+| `openrouter` | `openrouter/z-ai/glm-5`                 |
 
 **Key params:** `provider`, `model`, `messages` (`{ role, content }[]`), `responseSchema` (optional JSON Schema), `temperature` (optional).