@elevasis/sdk 1.42.0 → 1.44.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "1.42.0",
+  "version": "1.44.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/eslint-config": "0.0.0",
     "@repo/typescript-config": "0.0.0"
   },

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).
 

package/reference/sdk/resources/index.mdx

@@ -271,28 +271,63 @@ Agents are autonomous resources that use an LLM and tools to complete a goal. Yo
 
 **Note:** Use `elevasis-sdk exec --async` when executing agents. Agents can run for minutes or longer, and the synchronous execute endpoint will time out for long-running runs. The `--async` flag returns an execution ID immediately and polls for the result.
 
+There is no separate `agentConfig` object — agent-specific fields (`kind`, `systemPrompt`, `constraints`, `sessionCapable`, `securityLevel`, `memoryPreferences`) live directly on `config`, alongside the same identity fields a `WorkflowDefinition` uses. `modelConfig` is a sibling of `config`, not nested inside it. `kind` and `contract` are both required.
+
+This example is a minimal single-shot (non-session) agent: one question in, one structured answer out. It is type-checked against the published `@elevasis/sdk` on every `pnpm check:docs-snippets` run — see `operations/src/example/example-agent.ts` in a scaffolded project for the working, OM-descriptor-bound copy (`resourceId` there derives from the OM Resource descriptor, same as the workflow example above; this version inlines the id directly to keep the snippet self-contained).
+
+{/* doc-snippet:start:agent-definition-example */}
+
 ```typescript
 import type { AgentDefinition } from '@elevasis/sdk';
-import { resourceDescriptors } from '@core/config/organization-model';
+import { z } from 'zod';
+
+const inputSchema = z.object({
+  question: z.string().min(1),
+});
+const outputSchema = z.object({
+  answer: z.string(),
+  confidence: z.enum(['high', 'medium', 'low']),
+});
 
 const myAgent: AgentDefinition = {
   config: {
-    resource: resourceDescriptors.myAgent,
-    resourceId: resourceDescriptors.myAgent.id,
-    name: 'my-agent',
-    type: resourceDescriptors.myAgent.kind,
-    description: 'Answers questions using platform tools',
+    resourceId: 'my-agent',
+    name: 'My Agent',
+    description: 'Answers a single question with a structured, confidence-rated response.',
+    type: 'agent',
+    kind: 'utility',
+    version: '1.0.0',
     status: 'dev',
+    systemPrompt:
+      'You answer a single question directly and concisely. State your confidence honestly.',
   },
-  agentConfig: {
-    model: { provider: 'openai', model: 'gpt-5' },
-    systemPrompt: 'You are a helpful assistant.',
-    maxIterations: 10,
-  },
+  contract: { inputSchema, outputSchema },
   tools: [],
+  modelConfig: {
+    provider: 'anthropic',
+    model: 'claude-sonnet-5',
+    apiKey: process.env.ANTHROPIC_API_KEY ?? '',
+  },
 };
 ```
 
+{/* doc-snippet:end:agent-definition-example */}
+
+### config (agent-specific fields)
+
+| Field               | Type                                                                               | Description                                                                                                                                                            |
+| ------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `kind`              | `'orchestrator' | 'specialist' | 'utility' | 'platform'`                        | Required. What role this agent plays — not enforced at runtime today, but tenant-authored and validated at deploy against your OM resource descriptor's own `kind`.    |
+| `systemPrompt`      | `string`                                                                           | Required. The agent's base system prompt.                                                                                                                              |
+| `constraints`       | `{ maxIterations?, timeout?, maxSessionMemoryKeys?, maxMemoryTokens? }` (optional) | Iteration budget, execution timeout in ms, and session-memory limits.                                                                                                  |
+| `sessionCapable`    | `boolean` (optional)                                                               | Opt in to multi-turn sessions. Defaults to `false` — the shape used in the example above, which completes and returns `contract.outputSchema` in a single turn.        |
+| `securityLevel`     | `'standard' | 'hardened' | 'none'` (optional)                                    | Prompt-hardening tier. Auto-derived from `sessionCapable` when omitted (`true` → `'hardened'`, `false` → `'standard'`). Never set `'none'` on a session-capable agent. |
+| `memoryPreferences` | `string` (optional)                                                                | Guidance injected into the system prompt when session memory management is enabled.                                                                                    |
+
+### contract (agent)
+
+`contract.inputSchema` is required, same as a workflow. `contract.outputSchema` is what a **non-session** (single-shot) agent like the example above returns — there is no conversational reply to read a structured answer from otherwise. A `sessionCapable: true` agent typically omits `outputSchema` and speaks through its conversational `message` instead.
+
 ---
 
 ## DeploymentSpec

package/reference/sdk/resources/types.mdx

@@ -59,20 +59,20 @@ config: {
 
 ## Execution Types
 
-| Type                 | Description                                                                    |
-| -------------------- | ------------------------------------------------------------------------------ |
-| `WorkflowDefinition` | Complete workflow definition including config, contract, steps, and entryPoint |
-| `WorkflowStep`       | Individual step definition with type, handler, and next routing                |
-| `WorkflowConfig`     | Metadata block: name, description, status, links, category                     |
-| `StepHandler`        | Function type: `(input: unknown, context: StepContext) => Promise<unknown>`    |
-| `NextConfig`         | Union of `LinearNext` and `ConditionalNext`                                    |
-| `LinearNext`         | Fixed next step routing                                                        |
-| `ConditionalNext`    | Branching step routing                                                         |
-| `StepType`           | Runtime enum for step routing                                                  |
-| `AgentDefinition`    | Complete agent definition including config, agentConfig, and tools             |
-| `ExecutionContext`   | Runtime context passed to step handlers                                        |
-| `ExecutionMetadata`  | Metadata about a running execution                                             |
-| `ExecutionInterface` | Interface for triggering and inspecting executions                             |
+| Type                 | Description                                                                                                                                             |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `WorkflowDefinition` | Complete workflow definition including config, contract, steps, and entryPoint                                                                          |
+| `WorkflowStep`       | Individual step definition with type, handler, and next routing                                                                                         |
+| `WorkflowConfig`     | Metadata block: name, description, status, links, category                                                                                              |
+| `StepHandler`        | Function type: `(input: unknown, context: StepContext) => Promise<unknown>`                                                                             |
+| `NextConfig`         | Union of `LinearNext` and `ConditionalNext`                                                                                                             |
+| `LinearNext`         | Fixed next step routing                                                                                                                                 |
+| `ConditionalNext`    | Branching step routing                                                                                                                                  |
+| `StepType`           | Runtime enum for step routing                                                                                                                           |
+| `AgentDefinition`    | Complete agent definition: `config` (agent-specific fields live here directly, not in a separate `agentConfig`), `contract`, `tools`, and `modelConfig` |
+| `ExecutionContext`   | Runtime context passed to step handlers                                                                                                                 |
+| `ExecutionMetadata`  | Metadata about a running execution                                                                                                                      |
+| `ExecutionInterface` | Interface for triggering and inspecting executions                                                                                                      |
 
 ## ElevasConfig