eve-hub 0.16.0 → 0.16.2

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # eve-hub
 
+## 0.16.1
+
+### Patch Changes
+
+- A status post is a phase marker of at most 8 words with no @-mention; the brief, question or handoff goes in its own post. The shared instructions say so, and the hub refuses a status post that carries more.
+
 ## 0.16.0
 
 ### Minor Changes

package/README.md

@@ -53,13 +53,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; 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).
+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. Commit only the changeset file: the version is computed from the pending changesets, and `pnpm changeset version` (which a hub-runner PR runs) leaves eve-hub's alone (a test fails when a kit change adds none). Hub records each agent's kit version and accepts N and N−1 (D0/D12).
 
 ## Published package (deployed workspaces)
 
 A deployed workspace (lib/workspace-template.mjs, staged by hosted-hub/scripts/stage-workspace.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`) and applies it (`pnpm changeset version`); when it merges, `ci.yml`'s `deploy-hub` job 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.
+eve-hub's version is `package.json`'s `version` (the base) plus one patch per `.changeset/*.md` naming `eve-hub` (`lib/kit-version.mjs`). A PR that changes the kit only adds its changeset (`pnpm changeset`), so two open kit PRs never edit the same file. When it merges, `ci.yml`'s `deploy-hub` job runs `scripts/publish.mjs`, which stages the package into `dist/npm` with the computed version, publishes it when npm lacks it, and the `eve-hub@<version>` GitHub release is created; nothing is committed (main's ruleset allows only PR merges). A minor or major release raises the base and deletes the pending changesets in one PR; a kit change must raise the version, and it never goes down (`test/kit-version-bumped.test.mjs`). CHANGELOG.md stops at 0.14.x; the release notes and changesets carry later changes. 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 template's builder also mounts eve-code (`eve/extensions/code`: `apply_patch`, `grep`, the review skills, a read-only worker) and `eve/extensions/git` (`git({})`), both with no `github` option. Every bot of a build with the project's `GITHUB_TOKEN` mounts `eve/extensions/git`; a build without one mounts it nowhere, and the execution context points the bot to the `vercel-kit` connection instead (packages/agent-kit/prepare.mjs, execution-context.mjs; the rendered prompts are snapshotted in hosted-hub/test/prompts). The bot uses `gh` and `git` from bash, whose GitHub token is the sandbox firewall's (the Vercel sandbox `create_agent` writes, lib/agent-template.mjs `sandboxFile`), and no `gh` tool is contributed. A deployed workspace's eve is the one pin in `hosted-hub/bots/package.json`, which staging copies over the template's (an eve snapshot with `eve/extensions/git`; `hosted-hub/test/stage-workspace.test.mjs` checks the staged imports resolve against it). The hub and local bots stay on the hub's eve. 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` when set. The hosted hub keeps Vercel Authentication on: a deployed bot sends its project's OIDC token in `x-vercel-trusted-oidc-idp-token` too (the hub project lists each bots project in its Trusted Sources, `hosted-hub/src/onboard/trust.ts` `trustBots`, and never the bypass secret, even while its deployment still holds the env), and a bot on a Mac sends `x-vercel-protection-bypass: $HUB_PROTECTION_BYPASS` (the hub project's automation bypass secret) when it has one.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve-hub",
-  "version": "0.16.0",
+  "version": "0.16.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",
@@ -48,4 +48,4 @@
     "tree-sitter-bash": "0.25.1",
     "web-tree-sitter": "0.27.1"
   }
-}
+}

package/templates/reaching-others.md

@@ -16,4 +16,5 @@
   - `policy: "steer"` adds your input to the turn it's running; `"abort"` stops it and your text starts its next turn.
   - Use them only to correct work already under way; otherwise queue.
 - **Phase**
-  - When the thread's phase changes (planning, working, reviewing, done), make that post a status post.
+  - When the thread's phase changes (planning, working, reviewing, done), add a status post: at most 8 plain words, no @-mention.
+  - The brief, question or handoff is its own post, without `status`: the app draws a status post as a grey phase row, and the hub refuses one that carries more.