eve-hub 0.13.8 → 0.14.2

package/CHANGELOG.md

@@ -1,5 +1,30 @@
 # eve-hub
 
+## 0.14.2
+
+### Patch Changes
+
+- Fix the published declaration of the wake schedule, so eve-hub packs.
+
+## 0.14.1
+
+### Patch Changes
+
+- list_agents returns a Mac bot that is out as unavailable, with the reason, instead of leaving it out.
+
+## 0.14.0
+
+### Minor Changes
+
+- Bot-armed wake-ups: `schedules/wake` is an eve dynamic schedule a hosted bot arms for its own thread (`schedule__wake__create` with a note, a delay and `until`, the last time it may fire). When it fires, the bot's deployment tells the hub (`POST /api/wakes`), which posts a system @-mention into the thread unless the bot has had a turn there since arming. A recurring one (a cron expression) posts whenever the thread has been quiet since its last firing. Every wake-up must set `until`, so a cron is always bounded, and the first firing past it deletes the schedule. The shared instructions say when to arm one.
+- Pins eve 0.83.3 (with the hub's patches). Per-session caps move to eve's `limits.sessionUsage` check over the session window; the old keys stay for bots still on eve 0.81.
+
+## 0.13.9
+
+### Patch Changes
+
+- Bots are told their closing text is not posted once their turn has posted into its thread, so a result always goes in a `post_message`. The `post_message` and `react` tool descriptions say the same.
+
 ## 0.13.8
 
 ### Patch Changes

package/kit-modules.json

@@ -11,6 +11,7 @@
   "memory/workspace",
   "schedules/dash",
   "schedules/prune",
+  "schedules/wake",
   "skills/forms",
   "skills/local-onboarding",
   "skills/onboarding-profile",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve-hub",
-  "version": "0.13.8",
+  "version": "0.14.2",
   "license": "Apache-2.0",
   "description": "Bot-side code shared by every hub agent: registry tools, the roster hook, the eve channel, the host sandbox and browser, and model helpers.",
   "type": "module",

package/registry-fetch.d.mts

@@ -0,0 +1,6 @@
+export function registryBase(): string;
+export function sandboxRegistry(): string | null;
+export function registryHeaders(init?: HeadersInit, env?: Record<string, string | undefined>): Record<string, string>;
+export function connectionErrorCode(error: unknown): string | null;
+export function hubHeaders(init?: HeadersInit, env?: Record<string, string | undefined>): Promise<Record<string, string>>;
+export function registryFetch(path: string, init?: RequestInit, options?: { base?: string; deadlineMs?: number; attemptTimeoutMs?: number; fetchImpl?: typeof fetch }): Promise<Response>;

package/roster-model.mjs

@@ -13,6 +13,7 @@
 // - `createRosterModel({ agents, subagentCap })`: bound to a roster given
 //   explicitly (e.g. a test).
 import { defineDynamic } from "eve";
+import evePackage from "eve/package.json" with { type: "json" };
 import { CONTEXT_WINDOW, selectModel } from "./bot-model.mjs";
 import { DEFAULT_SUBAGENT_CAP } from "./subagent-cap.mjs";
 import { sessionLimits } from "./session-limits.mjs";
@@ -55,7 +56,7 @@ const rosterOf = ({ agents, humans, subagentCap, limits }) => ({ agents, humans,
 // `subagentCap`) for `data`, validated the same way as the file.
 export function bindRoster(data) {
   const roster = rosterOf(parseWorkspace(data));
-  return { ...roster, rosterModel: createRosterModel(roster), rosterLimits: (name) => sessionLimits(roster, name) };
+  return { ...roster, rosterModel: createRosterModel(roster), rosterLimits: (name) => sessionLimits(roster, name, evePackage.version) };
 }
 
 // Bots scaffolded before bindRoster read the roster from disk instead: the
@@ -71,5 +72,5 @@ export function rosterModel(name, options) {
 }
 
 export function rosterLimits(name) {
-  return sessionLimits(workspaceRoster(), name);
+  return sessionLimits(workspaceRoster(), name, evePackage.version);
 }

package/schedules/wake.d.ts

@@ -0,0 +1,52 @@
+import { defineDynamicSchedules } from "eve/experimental/schedules";
+import { z } from "zod";
+export declare const WakeInput: z.ZodObject<{
+    note: z.ZodString;
+    until: z.ZodString;
+}, z.core.$strict>;
+/** What the provider stores: the note, the arming session and the expiry (epoch ms). */
+export type ArmedWake = {
+    readonly note: string;
+    readonly sessionId: string;
+    readonly until: number;
+};
+type Principal = {
+    readonly type: string;
+    readonly authenticator: string;
+    readonly issuer?: string;
+    readonly principalId: string;
+    readonly subject?: string;
+};
+type Occurrence = {
+    readonly executionId: string;
+    readonly name: string;
+    readonly scheduledAt: string;
+};
+/** The hub relays the workspace's human as `roster:<user>` (channels/eve-roster-user.ts): the one principal a wake-up runs as. Anyone else: null, and nothing fires. */
+export declare function wakeAuth(principal: Principal): {
+    principalType: string;
+    authenticator: string;
+    principalId: string;
+    attributes: {};
+    issuer?: string | undefined;
+    subject?: string | undefined;
+} | null;
+/** The one call a firing makes: the hub decides whether to post, keyed on the occurrence so a retry posts once.
+ * A definitive refusal (a 4xx: the session is unknown, the thread archived) is returned, not thrown: retrying it can't change it. */
+export declare function fireWake(payload: ArmedWake, occurrence: Occurrence, { fetchImpl, base }?: {
+    fetchImpl?: typeof fetch;
+    base?: string;
+}): Promise<{
+    status: "posted" | "skipped";
+} | {
+    status: "refused";
+    error: string;
+}>;
+/** A firing: one scheduled past `until` removes the schedule and never reaches the hub; any other fires. */
+export declare function expireOrFire(payload: ArmedWake, occurrence: Occurrence, { remove, fire }: {
+    remove: (name: string) => Promise<unknown>;
+    fire: (payload: ArmedWake, occurrence: Occurrence) => Promise<unknown>;
+}): Promise<unknown>;
+type WakeSchedules = ReturnType<typeof defineDynamicSchedules<z.output<typeof WakeInput>, ArmedWake>>;
+declare const definition: WakeSchedules;
+export default definition;

package/schedules/wake.js

@@ -0,0 +1,70 @@
+// A bot's wake-up for its own thread: an eve dynamic schedule (schedule__wake__create
+// with { name, expression, payload: { note, until } }). One-shot with
+// { type: "delay", minutes }; recurring with { type: "cron", cron }. Every wake-up carries
+// `until`, the last time it may fire: eve has no expiry of its own, and authored code never
+// sees the expression (a timing-only update can turn a one-shot into cron without calling
+// preparePayload), so requiring it of every payload is what keeps a cron bounded. The model
+// gives the note, the timing and `until`; the thread comes from the arming turn's session,
+// which the hub reserved for that thread.
+// The stored payload is a function of the input and the session only: eve prepares it
+// before approval and again before writing, and refuses the write if the two differ.
+// When it was armed is the hub's: it records the schedule record the tool call returns.
+// When it fires, run() tells the hub (POST /api/wakes, hosted-hub/src/api/wakes.ts)
+// as the bot's deployment; the hub skips it if the bot has had a turn in the thread
+// since arming or its last firing, and otherwise posts a system @-mention that queues
+// behind any running turn. An occurrence scheduled past `until` deletes the schedule
+// instead. run() never starts a session itself: a session eve starts here is one the
+// hub cannot see.
+import { byPrincipal, defineDynamicSchedules, schedules } from "eve/experimental/schedules";
+import { z } from "zod";
+import { registryFetch } from "../registry-fetch.mjs";
+export const WakeInput = z.object({
+    note: z.string().min(1).max(500).describe("What to pick up when it fires, in your words."),
+    until: z.string().datetime({ offset: true }).describe("ISO 8601 datetime: the last time it may fire; after it, the schedule deletes itself. For a one-shot, a little after its delay."),
+}).strict();
+/** The hub relays the workspace's human as `roster:<user>` (channels/eve-roster-user.ts): the one principal a wake-up runs as. Anyone else: null, and nothing fires. */
+export function wakeAuth(principal) {
+    if (principal.authenticator !== "roster" || principal.type !== "user" || !principal.principalId.startsWith("roster:"))
+        return null;
+    return { principalType: principal.type, authenticator: principal.authenticator, principalId: principal.principalId, attributes: {}, ...(principal.issuer === undefined ? {} : { issuer: principal.issuer }), ...(principal.subject === undefined ? {} : { subject: principal.subject }) };
+}
+/** The one call a firing makes: the hub decides whether to post, keyed on the occurrence so a retry posts once.
+ * A definitive refusal (a 4xx: the session is unknown, the thread archived) is returned, not thrown: retrying it can't change it. */
+export async function fireWake(payload, occurrence, { fetchImpl = fetch, base } = {}) {
+    const res = await registryFetch("/api/wakes", {
+        method: "POST",
+        headers: { "content-type": "application/json" },
+        body: JSON.stringify({ sessionId: payload.sessionId, name: occurrence.name, note: payload.note, executionId: occurrence.executionId, scheduledAt: occurrence.scheduledAt }),
+    }, { fetchImpl, deadlineMs: 10_000, ...(base === undefined ? {} : { base }) });
+    if (res.ok)
+        return res.json();
+    const error = `POST /api/wakes: ${res.status} ${(await res.text()).slice(0, 300)}`;
+    if (res.status >= 400 && res.status < 500 && ![408, 425, 429].includes(res.status))
+        return { status: "refused", error };
+    throw new Error(error);
+}
+/** A firing: one scheduled past `until` removes the schedule and never reaches the hub; any other fires. */
+export async function expireOrFire(payload, occurrence, { remove, fire }) {
+    if (Date.parse(occurrence.scheduledAt) > payload.until) {
+        await remove(occurrence.name);
+        return { status: "expired" };
+    }
+    return fire(payload, occurrence);
+}
+const definition = defineDynamicSchedules({
+    description: "A wake-up for this thread: arm it when you end a turn with your own work unfinished and nothing sure to wake you. One-shot: a delay set to the expected wait. Recurring: a cron expression. Always set `until`, the last time it may fire. The hub posts it into this thread unless you have had a turn here since it was set or last fired.",
+    inputSchema: WakeInput,
+    scope: byPrincipal,
+    tool: true,
+    // A wake-up only reaches the arming bot's own thread, and an unattended turn cannot wait for approval.
+    approval: { create: () => "not-applicable", update: () => "not-applicable", delete: () => "not-applicable" },
+    preparePayload(input, context) {
+        return { note: input.note, sessionId: context.session.id, until: Date.parse(input.until) };
+    },
+    auth: ({ principal }) => wakeAuth(principal),
+    async run({ payload, occurrence }) {
+        // eve runs this under the creator's auth: the bound client deletes within the same byPrincipal scope.
+        await expireOrFire(payload, occurrence, { remove: (name) => schedules(definition).then((client) => client.delete(name)), fire: fireWake });
+    },
+});
+export default definition;

package/session-limits.mjs

@@ -5,11 +5,18 @@
 // When a session crosses a limit, eve pauses it before the next model call and
 // asks the human to Approve (a fresh window of the same size) or Stop; the
 // registry shows that as a "session-limit" request. Delegated sessions
-// (subagents, `agent` copies) draw from their parent's remaining budget.
+// (subagents, `agent` copies): up to eve 0.81 they draw from their parent's
+// remaining budget. From 0.82 eve runs the root's `sessionUsage` on each
+// child's own window, so a child may spend up to the full cap, and what it
+// spent counts toward its parent's window once it replies. The check sees only
+// the session it is asked about, so the old parent-remaining bound can't be
+// kept from here.
 //
 // Order: DEFAULT_SESSION_LIMITS, then the file's top-level `limits`, then the
 // bot's own `limits`. A key set to `false` uncaps that axis. Plain JS: the
 // workspace parser validates with LIMIT_KEYS, and tests import it directly.
+// It imports nothing: the parser runs where eve isn't installed, so the caller
+// passes the eve version in (roster-model.mjs).
 
 // The keys a workspace may set (eve's session usage limits).
 export const LIMIT_KEYS = Object.freeze(["maxTokenCostUsdPerSession", "maxInputTokensPerSession", "maxOutputTokensPerSession"]);
@@ -19,10 +26,27 @@ export const LIMIT_KEYS = Object.freeze(["maxTokenCostUsdPerSession", "maxInputT
 // Input tokens keep eve's own default (40M); output tokens stay uncapped.
 export const DEFAULT_SESSION_LIMITS = Object.freeze({ maxTokenCostUsdPerSession: 75 });
 
-// The `limits` value for `name`'s defineAgent.
-export function sessionLimits({ agents = [], limits = {} } = {}, name) {
+// eve's own cap on new input tokens per window, kept when a workspace sets none.
+const EVE_DEFAULT_INPUT_TOKENS = 40_000_000;
+
+// The `limits` value for `name`'s defineAgent, in the shape of the eve the bot
+// runs: up to 0.81 the three keys; from 0.82 one `sessionUsage` check, and the
+// three keys are an error. A Mac bot on 0.81 and a hosted bot on 0.83 get one cap.
+export function sessionLimits({ agents = [], limits = {} } = {}, name, eveVersion) {
   const own = agents.find((a) => a.name === name)?.limits ?? {};
-  return { sessionTimeoutMs: false, ...DEFAULT_SESSION_LIMITS, ...limits, ...own };
+  const caps = { ...DEFAULT_SESSION_LIMITS, ...limits, ...own };
+  const [major, minor] = eveVersion.split(".").map(Number);
+  if (major === 0 && minor < 82) return { sessionTimeoutMs: false, ...caps };
+  return { sessionTimeoutMs: false, sessionUsage: sessionUsage(caps) };
+}
+
+// The same caps as one eve 0.82+ `sessionUsage` check over the current window
+// (since the last approved continuation). `false` uncaps an axis.
+function sessionUsage({ maxTokenCostUsdPerSession: cost, maxInputTokensPerSession: input = EVE_DEFAULT_INPUT_TOKENS, maxOutputTokensPerSession: output }) {
+  return ({ window }) =>
+    (typeof cost === "number" && (window.costUsd ?? 0) >= cost) ||
+    (typeof input === "number" && window.inputTokens - window.cacheReadTokens >= input) ||
+    (typeof output === "number" && window.outputTokens >= output);
 }
 
 // Validation for a `limits` object: null, or the rest of an error message

package/templates/execution.md

@@ -23,6 +23,9 @@
 - **Waiting**
   - Never sleep or poll more than 60 seconds in one command. Check CI or a deploy once, report, and say what you're waiting on.
   - While work runs, post at least every 30 minutes: a result, or the one thing blocking you.
+  - Ending a turn with your own work unfinished and nothing sure to wake you (CI, a deploy, a background task, stopping partway): arm a wake-up with `schedule__wake__create`, the delay set to the expected wait, the note saying what to pick up and `until` a little after it. It posts into this thread unless you've had a turn here since.
+  - To check back repeatedly (a long CI run, a slow rollout), arm it with a cron expression, `until` the last time it may fire. It posts each time the thread has been quiet since the last one.
+  - Don't arm one while waiting on the human or on a bot you just mentioned: their reply wakes you.
 - **Ending a turn**
   - End only with results, a blocker you can't clear, or a question for the human; never "I'll do it next".
   - If the human says stop or hold off, do it and confirm in one line.

package/templates/reaching-others.md

@@ -1,6 +1,7 @@
 - **One channel**
   - Everything to the human or a bot is a `post_message`: into this thread, another thread, or a bot's DM.
   - Posting doesn't end your turn. Post when you start something long, when you find something that matters, and when you're done, each as its own post.
+  - Once a turn has posted into this thread, the hub drops its closing text, so your result always goes in a post, never only in the text you end the turn with.
 - **Mentions wake**
   - `@<name>` wakes one bot or person; `@all` wakes every participant in the thread.
   - Each wake costs that bot a turn, so mention at most one name per message: whoever acts next, in the message that hands off.

package/tools/list_agents.d.ts

@@ -16,6 +16,7 @@ declare const _default: import("eve/tools").ToolDefinition<Record<string, never>
         clamped?: string[];
     };
     status: string;
+    reason?: string;
     busyIn: string[];
     process?: {
         status: string;
@@ -48,6 +49,7 @@ declare const _default: import("eve/tools").ToolDefinition<Record<string, never>
             clamped?: string[];
         };
         status: string;
+        reason?: string;
         busyIn: string[];
         process?: {
             status: string;

package/tools/list_agents.js

@@ -2,7 +2,7 @@ import { defineTool } from "eve/tools";
 import { z } from "zod";
 import { registryFetch } from "../registry-fetch.mjs";
 export default defineTool({
-    description: "List the workspace's bots right now: each one's role, kind (its place in the team: coordinator, planner, builder, reviewer, git-ops, demo, or other), where it runs (hosted or local), the tools its runtime reports (null when not yet reported), its model, the model and reasoning each of its declared subagents and its built-in `agent` copies resolve to under the workspace subagent cap (clamped from hub.workspace.json, never rejected), whether it's idle or busy (and where; a bot's threads run in parallel, so busy elsewhere doesn't mean it can't start work in a new thread), its server's memory (process.rssMb) and uptime (process.uptimeS; only on a local hub, since a hosted hub runs no bot process to measure), and any restart in progress (restart_agent, or the registry recycling a bot that grew too big or ran too long). The team changes; check it before routing work.",
+    description: "List the workspace's bots right now: each one's role, kind (its place in the team: coordinator, planner, builder, reviewer, git-ops, demo, or other), where it runs (hosted or local), the tools its runtime reports (null when not yet reported), its model, the model and reasoning each of its declared subagents and its built-in `agent` copies resolve to under the workspace subagent cap (clamped from hub.workspace.json, never rejected), whether it's idle, busy (and where; a bot's threads run in parallel, so busy elsewhere doesn't mean it can't start work in a new thread) or unavailable (with `reason`: a Mac bot whose Mac couldn't set up the workspace; a post that @-mentions it is refused, so route the work elsewhere or ask the human), its server's memory (process.rssMb) and uptime (process.uptimeS; only on a local hub, since a hosted hub runs no bot process to measure), and any restart in progress (restart_agent, or the registry recycling a bot that grew too big or ran too long). The team changes; check it before routing work.",
     inputSchema: z.object({}),
     async execute() {
         // Anything but a 2xx list of bots is an error naming the status and the

package/tools/post_message.d.ts

@@ -22,7 +22,6 @@ declare const _default: import("eve/tools").ToolDefinition<{
     threadId: string;
     title: string;
     deliveries: Record<string, string>;
-    comms?: boolean;
 }> & {
     execute(input: {
         threadId?: string | undefined;
@@ -48,7 +47,6 @@ declare const _default: import("eve/tools").ToolDefinition<{
         threadId: string;
         title: string;
         deliveries: Record<string, string>;
-        comms?: boolean;
     }>;
 };
 export default _default;

package/tools/post_message.js

@@ -18,7 +18,7 @@ import { registryFetch } from "../registry-fetch.mjs";
 // move), the text is its summary, `metadata` its PR and sha. The hub keeps the
 // latest one per bot and thread for the workspace state and the Dash.
 export default defineTool({
-    description: "Post a message as you. Leave out threadId and agent to post into the thread you're in, while you work: posting doesn't end your turn, and when your turn's last step is only comms (a plain post into this thread, a reaction), your end-of-turn text isn't posted. Or post into another workspace thread or a bot's DM. @-mentions wake bots the same way your replies do (at most one, never yourself); `@all` wakes every participant; each bot's gate decides whether it replies. Posting into a bot's DM wakes that bot. Archived threads are refused. `policy` says how a post reaches the one bot it @-mentions: queue (default) runs as its next turn, or starts one now if it is idle; steer lands in its RUNNING turn at the next step boundary and the bot folds it in without a restart, to correct course mid-turn; abort stops its turn in that thread (running commands are killed, the process keeps running) and the text starts its fresh turn, \"stop, do this instead\". Steer and abort need exactly one @-mention, not `@all`, and cut into work already under way: use them only to change what a running turn is doing. A status post sets the thread's phase: planning, working, reviewing or done; allowed moves are start → planning or working, planning → working, working → reviewing, reviewing → working (fix first), planning (rethink) or done. Any other move is refused with the allowed next phases. The text is a phase marker, not a report: at most 8 plain words on what is happening now (\"Building the input-count fix\"), with no bot or role names, no restating the phase, no parentheticals. Test results, branch names and caveats go in a separate message. The PR URL and sha go in metadata, never in the text.",
+    description: "Post a message as you. Leave out threadId and agent to post into the thread you're in, while you work: posting doesn't end your turn, and once your turn has posted into this thread, its end-of-turn text isn't posted, so put your result in a post. Or post into another workspace thread or a bot's DM. @-mentions wake bots the same way your replies do (at most one, never yourself); `@all` wakes every participant; each bot's gate decides whether it replies. Posting into a bot's DM wakes that bot. Archived threads are refused. `policy` says how a post reaches the one bot it @-mentions: queue (default) runs as its next turn, or starts one now if it is idle; steer lands in its RUNNING turn at the next step boundary and the bot folds it in without a restart, to correct course mid-turn; abort stops its turn in that thread (running commands are killed, the process keeps running) and the text starts its fresh turn, \"stop, do this instead\". Steer and abort need exactly one @-mention, not `@all`, and cut into work already under way: use them only to change what a running turn is doing. A status post sets the thread's phase: planning, working, reviewing or done; allowed moves are start → planning or working, planning → working, working → reviewing, reviewing → working (fix first), planning (rethink) or done. Any other move is refused with the allowed next phases. The text is a phase marker, not a report: at most 8 plain words on what is happening now (\"Building the input-count fix\"), with no bot or role names, no restating the phase, no parentheticals. Test results, branch names and caveats go in a separate message. The PR URL and sha go in metadata, never in the text.",
     inputSchema: z.object({
         threadId: z.string().optional().describe("Another thread's id, e.g. thr_0002, or a DM id, dm-<bot>. Omit it to post into the thread you're in."),
         agent: z.string().optional().describe("Post into this bot's DM instead of a thread."),

package/tools/react.js

@@ -1,9 +1,9 @@
 import { defineTool } from "eve/tools";
 import { z } from "zod";
 import { registryFetch } from "../registry-fetch.mjs";
-// Reactions are the bot's own choice, not delivery bookkeeping. `comms: true` declares it talks in the thread: a turn whose last step is only comms posts no end-of-turn text.
+// Reactions are the bot's own choice, not delivery bookkeeping. A turn whose last step is only reactions posts no end-of-turn text: the hub reads the tool name; `comms: true` is for hubs that predate that.
 export default defineTool({
-    description: "React to a message in this thread with an emoji (toggles). Use the [msg_…] id shown before each message. Good for light acknowledgement (👍 got it, 👀 looking, ✅ done, 🎉 nice) when a full reply isn't needed. A turn that ends on only reactions and posts posts no closing text, so never write one.",
+    description: "React to a message in this thread with an emoji (toggles). Use the [msg_…] id shown before each message. Good for light acknowledgement (👍 got it, 👀 looking, ✅ done, 🎉 nice) when a full reply isn't needed. A turn that ends on a reaction, or that posted into this thread, posts no closing text, so never write one.",
     inputSchema: z.object({
         messageId: z.string().describe("The id in brackets before the message, e.g. msg_0012."),
         emoji: z.string().describe("A single emoji."),