eve-hub 0.5.5 → 0.5.6

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # eve-hub
 
+## 0.5.6
+
+### Patch Changes
+
+- 1418c75: Release: a PR bumps the version itself (`pnpm changeset version`); the release workflow only publishes.
+
 ## 0.5.5
 
 ### Patch Changes

package/README.md

@@ -11,7 +11,7 @@ The bot-side code every hub agent shares (milestone M3 in [`docs/architecture`](
 | `instructions/protocol.ts` | The shared protocol alone, rendered from `templates/workspace-protocol.md` | every other bot's `agent/instructions/protocol.ts`, appended after its own `instructions.md` (who the bot is) |
 | `memory/workspace.ts`, `memory.mjs` | an eve memory slot (default export, constant `workspace` scope) whose provider recalls the workspace's `memory/<id>.md` entries, one message each, at every turn start and after compaction, only the ones whose text changed since the session last saw them, as new messages after the history; `validateMemory(root)` for a workspace's tests | every bot's (main too) `agent/memory/workspace.ts`: `export { default } from "eve-hub/memory/workspace"` |
 | `memory/bot.ts` | the same for the bot's own `agents/<bot>/memory/<id>.md` entries; the bot is found from its directory (`findBotDir`), scope is its name | every bot's `agent/memory/bot.ts`: `export { default } from "eve-hub/memory/bot"` |
-| `channels/eve-roster-user.ts` | `eveChannel({ auth: [rosterUser, localDev()], turnPolicy: "queue" })`: queued mentions, and the registry's `x-roster-user` human as a user principal | every bot's `agent/channels/eve.ts` |
+| `channels/eve-roster-user.ts` | `eveChannel({ auth: [rosterUser, localDev()] })`: eve's default steer policy, and the registry's `x-roster-user` human as a user principal | every bot's `agent/channels/eve.ts` |
 | `channels/eve.ts` | Re-exports `eve-roster-user.ts`, for stubs written before every bot shared one channel | older `agent/channels/eve.ts` stubs |
 | `tools/disabled.ts` | `disableTool()`: removes an eve default tool | the read-only preset's `agent/tools/write_file.ts` |
 | `host-sandbox.ts`, `host-browser.ts` | `HostSandbox` (the host machine is the sandbox) and each session's headless Chromium | `agent/sandbox.ts` imports `HostSandbox` |
@@ -52,13 +52,13 @@ A bot's role is enforced by its files as well as its prose. `create_agent`'s `pr
 3. The stubs use the specifiers the `exports` map serves (`eve-hub/tools/x`, `eve-hub/host-sandbox`, `eve-hub/roster-model`, …).
 4. `eve` and `zod` are peer dependencies. eve's bundler resolves the kit to its realpath, so the kit's own `eve` imports come from hub's install. When the workspace's eve is linked to hub's, that's one eve (verified with eve 0.69).
 
-Add a changeset (`pnpm changeset`, pick `eve-hub`) when a tool's name, schema, or description, the hook's events, or the channel config changes; the release bumps `version` from it. Hub records each agent's kit version and accepts N and N−1 (D0/D12).
+Add a changeset (`pnpm changeset`, pick `eve-hub`) when a tool's name, schema, or description, the hook's events, or the channel config changes; run `pnpm changeset version` in the same PR so it bumps `version` and writes CHANGELOG.md (a test fails while a changeset file is pending). Hub records each agent's kit version and accepts N and N−1 (D0/D12).
 
 ## Published package (deployed workspaces)
 
 A deployed workspace (`node scripts/workspace-template.mjs <dir>`, lib/workspace-template.mjs) has no hub checkout to link, so it installs the kit from npm, published as [`eve-hub`](https://www.npmjs.com/package/eve-hub): `"eve-hub": "<version>"`. `node packages/agent-kit/scripts/pack.mjs <outDir>` builds the package: every `.ts` module compiled to `.js` + `.d.ts` in place (node won't strip types under `node_modules`), the `exports` map pointed at them, and `templates/` included.
 
-Releases go through Changesets, as in eve. A PR that changes the kit adds a changeset (`pnpm changeset`); when it merges, `.github/workflows/release.yml` bumps `version`, writes CHANGELOG.md, commits both to main and runs `changeset publish`: the kit's `prepack` stages the package into `dist/npm` (its `publishConfig.directory`), npm gets it, and the `eve-hub@<version>` GitHub release is created. npm auth is the repo's `NPM_TOKEN` secret (an npm automation token). The template pins the version this checkout carries.
+Releases go through Changesets, as in eve. A PR that changes the kit adds a changeset (`pnpm changeset`) and applies it (`pnpm changeset version`); when it merges, `.github/workflows/release.yml` runs `changeset publish` (no bot commits to main: its ruleset allows only PR merges): the kit's `prepack` stages the package into `dist/npm` (its `publishConfig.directory`), npm gets it, and the `eve-hub@<version>` GitHub release is created. npm auth is the repo's `NPM_TOKEN` secret (an npm automation token). The template pins the version this checkout carries.
 
 The template's main gets a Vercel Sandbox and only the kit stubs that run without the hub's machine (lib/workspace-template.mjs `DEPLOYED_KIT_FILES`; eve's own bash replaces the kit's). The published tarball (`scripts/pack.mjs`) leaves out the kit__worker extension, which mounts only on the hub's machine. The hub reaches each bot's eve channel with `Authorization: Bearer $BOT_TOKEN` (`bot-token.mjs`); the kit's calls to the hub (`registry-fetch.mjs`, at `ROSTER_REGISTRY_URL`) carry `Authorization: Bearer $HUB_TOKEN` and, since the hosted hub keeps Vercel Authentication on, `x-vercel-protection-bypass: $HUB_PROTECTION_BYPASS` (the hub project's automation bypass secret), each when set.
 

package/channels/eve-roster-user.js

@@ -16,6 +16,7 @@ async function rosterUser(req) {
         return null;
     return { authenticator: "roster", principalId: `roster:${user}`, principalType: "user", attributes: {} };
 }
-// Mentions from other participants queue behind an active turn instead of
-// steering it; the registry cancels first when a human cuts in.
-export default eveChannel({ auth: [rosterUser, dev], turnPolicy: "queue" });
+// No turnPolicy: eve's default steers a message into the running turn at its
+// next step. The registry sends turnPolicy "queue" for a bot's message, so it
+// waits for the turn to end.
+export default eveChannel({ auth: [rosterUser, dev] });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve-hub",
-  "version": "0.5.5",
+  "version": "0.5.6",
   "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/templates/workspace-protocol.md

@@ -44,7 +44,13 @@ Anything you post outside this workspace (GitHub comments and reviews, PR descri
 
 ## Style
 
-Precise and technical. Lead with the answer, then the 1–3 facts that decide it: file:line, numbers, the exact command or flag. Write for an engineer; don't simplify. Short paragraphs. Keep replies under ~180 words unless you're posting a plan or a review. No filler, no disclaimers, no "great question", no recap of the plan back to its author.
+Signal first: say only the essence, what the reader must know or decide. Precise and technical, for an engineer.
+
+- Delta only. Post only what's new since the last message in the thread. Never restate what another bot already posted (PR number, sha, file, verdict): link the message that posted it. If you have nothing new, react instead of posting.
+- Crux first. When you need something from the reader, the first sentence is the one question, answerable in a word: "Land #422 now, or hold it until Kit works?" Otherwise the first sentence is the verdict or what changed. Then only the 1–3 facts that decide it.
+- Every sentence must change what the reader does next. If losing it changes nothing, cut it. No filler, no disclaimers, no "great question", no recap of the plan back to its author, no bold labels or code chips on ordinary nouns; code formatting is for what the reader will paste or search.
+- Name things at the reader's level. Say "the worker fix" or "GitHub writes", not "fix 1" or `resolveSubagent`. Identifiers belong behind the link.
+- Depth is one step away, and it is shown, not written. Plans, briefs and reviews keep only the essence inline; the full body lives in a file you link, with the file:line, test or trace next to each claim. When asked to go deeper, don't add prose. Give a concrete scenario in numbered steps (who does what, then what happens: "1. agent A calls a subagent 2. it runs on the hub's model cap"), then the code, diff, trace or command output that proves it, trimmed to the lines that make the point, then a link pinned to a commit.
 
 Link what you reference, so the human can click it, using the repo you actually worked in. PRs and issues get full URLs, `[#4234](https://github.com/<owner>/<repo>/pull/4234)`; commits too, ``[`684725be`](https://github.com/<owner>/<repo>/commit/684725be)``. Code on GitHub gets a permalink pinned to a commit sha, ``[`path:267`](https://github.com/<owner>/<repo>/blob/<sha>/path#L267)``, never a branch URL that drifts. Local files get their absolute path and line, ``[`docs/setup.md:42`](/Users/<you>/wrk/<repo>/docs/setup.md#L42)``; clicking opens the file in the human's editor. Bare `#123`, shas and paths stay plain text. Never show a raw URL, in prose or in a table cell: every link is `[label](url)`, and the label names the target (`#68`, a short sha, `file.swift:731`, a page title), never the URL itself. The one exception is when the human asks for the literal URL, e.g. to copy it.
 
@@ -83,5 +89,4 @@ renders as:
 - `attach_image` shows an image tile. `![]()` shows only alt text; raw HTML shows literally.
 - Nothing collapses, and the Mentions inbox previews only the first plain-text line of each message. So each message's first bubble is its point, in at most 2 sentences; detail follows after `---`.
 - Separate updates (started, found, done) are separate posts; `---` splits one message into bubbles.
-- Optional detail doesn't go in the message. If it's worth having, end with one line, `More: <topic> · <topic>`, and expand a topic when asked.
 - Tables only for 2+ rows of short, comparable values: at most 4 columns sharing the width equally, a few words per cell. A single item, or anything that needs a reason, goes in a sentence or bullets. Shorten shas to 8 characters; keep URLs and paths in link text, not cells.