Make your first typed Jev decision
Original starter based on the official TypeSafe JavaScript SDK. You define the possible labels, pass message state, and read a typed answer plus confidence. Live execution needs a TypeSafe API key; mock mode does not.
A local function returns fixture Choice results so the UI works with no network and no key.
Live mode is optional and server-onlyWhat you'll make
Stand up a mock-first app that asks Jev to classify a short support ticket.
A tiny UI, fixture tickets, a mock Choice adapter, and an optional server-only TypeSafe client following the official JS SDK README.
Given ticket state, returns one of the labels you defined (for example billing, technical, other) plus confidence.
The coding agent writes the app. Application code stores fixtures, calls Jev, validates the typed result, and renders it. No LLM is required at runtime.
Agent prompt
Give your agent a useful brief.
You are helping a developer prototype a Jev-powered application. Goal: Build a mock-first support ticket classifier using Jev Choice. Product truth: - Jev (TypeSafe System One) returns typed decisions and calibrated probabilities. It does not write emails, generate UI copy, play games by emitting pixels, or call Zapier. - Your job is to write application code. Jev only answers questions whose possible answers are defined in advance. - Use the official JS SDK documented at https://github.com/typesafe-ai/typesafe-sdk-js. Read the current README before inventing method names. - Keep API keys in server-only environment variables. Never put TYPESAFE_API_KEY in client code, screenshots, git, or logs. - Ship a working mock adapter first. Live TypeSafe calls are optional and must be clearly labeled. Required behavior: 1. Inspect the current project and only change what is needed. 2. Define a small typed Choice or Score schema. Include an explicit uncertain / human-review path. 3. Implement mock mode with fixtures that include ordinary, ambiguous, and conflicting examples. 4. Add a server-only adapter that calls TypeSafe only when TYPESAFE_API_KEY is present. 5. Application code must validate the typed response and decide the action. Failed provider calls must not trigger side effects. 6. Do not send, delete, archive, or mutate real user accounts in this first version. 7. Add tests for the schema and mock path. Report what was run and what remains untested. Official source to read: https://github.com/typesafe-ai/typesafe-sdk-js Keep the change set small. Include a README with mock vs live verification steps. When finished, write a short Verification section distinguishing mock results from any live API call.
Copies instructions into your clipboard. It does not run or install anything.
Setup and guardrails
Start small. Keep the boundary clear.
Prerequisites
- Node.js 20+
- Ability to read the official JS SDK README
- Optional: TYPESAFE_API_KEY in a server environment
Setup steps
- Create a local app or use an existing one.
- Add .env.example with TYPESAFE_API_KEY listed by name only.
- Implement mock classification first.
- Add a server route that never exposes the key to the browser.
- Compare mock labels with your own manual labels on 8–12 tickets.
A local function returns fixture Choice results so the UI works with no network and no key.
Server-only TypeSafeClient.systemOne call using choice() questions from the current SDK.
Ready-to-download
Keep the notes with the build.
Original educational drafts, clearly labeled with their evidence status.