@intentic/sandbox-contract 1.220.0 → 1.222.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@intentic/sandbox-contract",
-  "version": "1.220.0",
+  "version": "1.222.0",
   "description": "oRPC wire contract for the intentic sandbox daemon — shared by the daemon and its browser client",
   "license": "MIT",
   "type": "module",
@@ -89,9 +89,9 @@
     "@orpc/contract": "1.14.13",
     "tslib": "2.8.1",
     "zod": "4.4.3",
-    "@intentic/registry": "1.220.0",
-    "@intentic/extension-manifest": "1.220.0",
-    "@intentic/constants": "1.220.0"
+    "@intentic/constants": "1.222.0",
+    "@intentic/extension-manifest": "1.222.0",
+    "@intentic/registry": "1.222.0"
   },
   "devDependencies": {
     "@types/node": "24.13.2",

package/src/agent-catalog.ts

@@ -115,6 +115,22 @@ export const ACCESS_COST: Record<AccessKind, number> = { free: 0, subscription:
 export const TRIAL_ENDPOINT_ID = "free-trial";
 export const TRIAL_PROVIDER = "endpoint/free-trial";
 export const isTrialProvider = (provider: AgentProvider): boolean => provider === TRIAL_PROVIDER;
+
+/* THE ONLY MODEL THE TRIAL PUBLISHES — a synthetic id, not one of Google's, and that is the point.
+ *
+ * The trial used to publish whatever the upstream listed. Two things were wrong with that and neither could be
+ * fixed by filtering harder. Google lists ~54 models on a fresh key and declares `generateContent` for many that
+ * cannot serve an agent turn — deep-research, antigravity, gemma, robotics and computer-use previews all pass a
+ * capability check and then fail the first message — so the picker was full of rows whose only outcome was an
+ * error. And the list MOVED: the translator's routing table is written at boot and on capability edits, while
+ * the picker re-reads the catalog every minute, so a model discovered in between was pickable and unroutable,
+ * refused with "unknown provider for model".
+ *
+ * One id, never changing, ends both. There is nothing to filter because nothing is discovered, and the routing
+ * table cannot drift from a list of one constant. WHICH real model answers is decided per message by the
+ * platform, which is the only party that can see which of its keys still has quota on which model — the sandbox
+ * cannot, and a user choosing blind between rows they know nothing about was never a choice worth offering. */
+export const TRIAL_MODEL_ID = "auto";
 // What the picker calls it, and the sentence the surfaces put underneath. One wording, so the composer's notice
 // and the picker's row cannot end up describing different bargains.
 export const TRIAL_LABEL = "Free trial";

package/src/contracts/endpoints.contract.ts

@@ -29,6 +29,17 @@ export const TrialStatusSchema = z.object({
     resetsAt: z.string().optional(),
     // Earliest known time a quarantined upstream key can be tried again.
     retryAt: z.string().optional(),
+    /* THE REAL MODEL BEHIND THE TRIAL'S ONE PUBLISHED ID, on this account's most recent message.
+     *
+     * The trial routes per message across a ladder of models (the platform's trial-ladder.ts), so the id the
+     * user selected names the trial rather than what answered them. Telling them which model ran is what keeps
+     * that from being a black box: an answer that reads as weak has a visible cause, and a bug report can name
+     * the model instead of guessing at one.
+     *
+     * It arrives on the STATUS poll rather than in the turn's own stream because the translator sits between the
+     * platform and this daemon and does not forward response headers. The client refreshes this when a trial
+     * turn ends, so in practice it is the model that served the turn just finished. Absent until one has been. */
+    servedModel: z.string().optional(),
 });
 export type TrialStatusResponse = z.infer<typeof TrialStatusSchema>;
 

package/src/contracts/push.contract.ts

@@ -1,17 +1,18 @@
 import { oc } from "@orpc/contract";
-import { OkSchema, PushConfigQuerySchema, PushConfigSchema, PushEndpointSchema, PushSubscriptionSchema, PushTestSchema } from "../schemas.js";
+import { OkSchema, PushChannelIdSchema, PushChannelSchema, PushConfigQuerySchema, PushConfigSchema, PushTestSchema } from "../schemas.js";
 
-// Web-push notifications for this sandbox. The daemon owns the VAPID keypair and the subscription list (see
+// Push notifications for this sandbox. The daemon owns the VAPID keypair and the channel list (see
 // push/push-store.ts for why the key lives on the history volume), and sends on the three moments where the
 // operator's attention is genuinely wanted: a turn finished, the agent is blocked on an answer, and an
-// automation is waiting for approval.
+// automation is waiting for approval. A channel is either a browser's web-push subscription or a native
+// install reached through the platform's push relay — see PushChannelSchema for the split and why.
 //
 // `test` exists because a notification pipeline has four independent failure points the user cannot inspect
-// (browser permission, service-worker registration, the daemon's key, the push service itself) — a button
-// that proves the whole chain end-to-end is worth more than any amount of status rendering.
+// (device permission, service-worker or shell registration, the daemon's key, the push service itself) — a
+// button that proves the whole chain end-to-end is worth more than any amount of status rendering.
 export const pushContract = {
     config: oc.route({ method: "GET", path: "/push/config" }).input(PushConfigQuerySchema).output(PushConfigSchema),
-    subscribe: oc.route({ method: "POST", path: "/push/subscribe" }).input(PushSubscriptionSchema).output(OkSchema),
-    unsubscribe: oc.route({ method: "POST", path: "/push/unsubscribe" }).input(PushEndpointSchema).output(OkSchema),
+    subscribe: oc.route({ method: "POST", path: "/push/subscribe" }).input(PushChannelSchema).output(OkSchema),
+    unsubscribe: oc.route({ method: "POST", path: "/push/unsubscribe" }).input(PushChannelIdSchema).output(OkSchema),
     test: oc.route({ method: "POST", path: "/push/test" }).output(PushTestSchema),
 };

package/src/schemas.ts

@@ -3619,9 +3619,7 @@ export const EndpointConfigSchema = z.object({
  * `allow`/`deny` are hostname lists (comma- or newline-separated). Empty allow = any host, each behind its
  * card; deny wins over allow. One capability per sandbox (singleton card): a second balance would just be a
  * second opinion about the same owner's wallet. */
-const usdAmount = z
-    .string()
-    .regex(/^\d+(\.\d{1,6})?$/, "a USD amount like 0.50 (up to six decimals — USDC's own precision)");
+const usdAmount = z.string().regex(/^\d+(\.\d{1,6})?$/, "a USD amount like 0.50 (up to six decimals — USDC's own precision)");
 export const WalletNetworkSchema = z.enum(["eip155:8453", "eip155:84532"]);
 export type WalletNetwork = z.infer<typeof WalletNetworkSchema>;
 export const WalletConfigSchema = z.object({
@@ -6680,15 +6678,23 @@ export const PresenceReportSchema = z.object({
 });
 export type PresenceReport = z.infer<typeof PresenceReportSchema>;
 
-// ---- push: web-push notifications to the owner's devices ----
-// The daemon is the only tier that knows what the agent is doing, so it is the sender. Subscriptions are
-// per-BROWSER (the endpoint is minted by that browser's push service — Google's, Mozilla's, Apple's), which
-// is why they live here and not on the platform: the platform is off the command path and would have to be
-// told about every turn to be useful.
+// ---- push: notifications to the owner's devices ----
+// The daemon is the only tier that knows what the agent is doing, so it is the sender. A registration is
+// per-DEVICE and comes in two kinds, distinguished by who can be posted to directly:
+//   webpush  a browser (including the Android TWA, which IS Chrome). The endpoint is minted by that
+//            browser's push service and the daemon sends to it directly, end-to-end encrypted.
+//   relay    a native app install (the iOS shell), whose OS push service (APNs) only accepts sends from
+//            the app's vendor. The daemon posts plain JSON to the platform's push relay, which holds the
+//            vendor credential and forwards. The payload transits the relay readable — the price of Apple
+//            requiring the vendor in the loop — which is why the channel records WHERE to post (`url`)
+//            rather than the daemon knowing any platform by name.
+// Channels live here and not on the platform because the daemon is on the command path: the platform would
+// have to be told about every turn to be useful.
 
 // A browser's PushSubscription, in the exact shape `web-push` consumes — the browser produces it via
 // PushManager.subscribe() and the client posts it back verbatim, so the daemon never reshapes it.
-export const PushSubscriptionSchema = z.object({
+export const WebPushChannelSchema = z.object({
+    kind: z.literal("webpush"),
     endpoint: z.url(),
     keys: z.object({
         // The client's public key and auth secret for payload encryption (RFC 8291). Opaque base64url here.
@@ -6696,7 +6702,27 @@ export const PushSubscriptionSchema = z.object({
         auth: z.string().min(1),
     }),
 });
-export type PushSubscription = z.infer<typeof PushSubscriptionSchema>;
+export type WebPushChannel = z.infer<typeof WebPushChannelSchema>;
+
+// A native install, addressed through a push relay. `secret` is the send capability the relay minted at
+// registration — the daemon proves it may notify this device by presenting it; the relay never learns which
+// sandbox is calling. `deviceId` doubles as the channel's identity (see channelId below).
+export const RelayChannelSchema = z.object({
+    kind: z.literal("relay"),
+    // The absolute URL the daemon POSTs a send to — minted by the relay at registration, stored verbatim.
+    url: z.url(),
+    deviceId: z.string().min(1),
+    secret: z.string().min(1),
+});
+export type RelayChannel = z.infer<typeof RelayChannelSchema>;
+
+export const PushChannelSchema = z.discriminatedUnion("kind", [WebPushChannelSchema, RelayChannelSchema]);
+export type PushChannel = z.infer<typeof PushChannelSchema>;
+
+// The one identity every push route speaks: subscribe upserts by it, unsubscribe and the config probe name
+// devices by it. Shape-derived so the daemon and the web app can never disagree about what identifies a row —
+// a browser is its push endpoint, a native install is the deviceId its relay registration minted.
+export const channelId = (channel: PushChannel): string => (channel.kind === "webpush" ? channel.endpoint : channel.deviceId);
 
 // What the service worker renders. `url` is the in-app route the notification opens (the click handler
 // focuses an existing tab there rather than spawning a new one); `tag` collapses repeats — a second
@@ -6715,14 +6741,14 @@ export const PushNotificationSchema = z.object({
 });
 export type PushNotification = z.infer<typeof PushNotificationSchema>;
 
-// The VAPID public key a browser needs to subscribe, plus whether this browser's endpoint is already known —
-// so the settings toggle can render its true state instead of trusting the browser's permission alone (a
-// granted permission with no server-side row would notify nothing).
+// The VAPID public key a browser needs to subscribe (native shells ignore it), plus whether the asking
+// device's channel is already known — so the settings toggle can render its true state instead of trusting
+// the device's permission alone (a granted permission with no daemon-side row would notify nothing).
 export const PushConfigSchema = z.object({ publicKey: z.string(), subscribed: z.boolean() });
-export const PushEndpointSchema = z.object({ endpoint: z.url() });
-// The optional `endpoint` says WHICH browser is asking; without it `subscribed` could only speak for the
-// sandbox as a whole, which is never the question the settings toggle needs answered.
-export const PushConfigQuerySchema = z.object({ endpoint: z.url().optional() });
+export const PushChannelIdSchema = z.object({ id: z.string().min(1) });
+// The optional `id` says WHICH device is asking (see channelId); without it `subscribed` could only speak
+// for the sandbox as a whole, which is never the question the settings toggle needs answered.
+export const PushConfigQuerySchema = z.object({ id: z.string().min(1).optional() });
 
 // What a test send actually achieved. `{ ok: true }` would be a lie the one place it matters most: the button
 // exists to prove a chain the user cannot inspect, so "the daemon accepted the request" is not the answer to