eve-hub 0.16.22 → 0.16.24

package/execution-context.mjs

@@ -22,8 +22,12 @@ const claims = (jwt) => JSON.parse(Buffer.from(jwt.split(".")[1], "base64url").t
 
 export function deploymentFacts(env = process.env) {
   const oidc = env.VERCEL_OIDC_TOKEN ? claims(env.VERCEL_OIDC_TOKEN) : {};
-  const repoOwner = env.VERCEL_GIT_REPO_OWNER && env.VERCEL_GIT_REPO_SLUG ? env.VERCEL_GIT_REPO_OWNER : undefined;
-  const repo = repoOwner ? `${repoOwner}/${env.VERCEL_GIT_REPO_SLUG}` : undefined;
+  // An uploaded build has no git metadata. Onboarding's first one is the workspace repo's, which the hub names in
+  // HUB_GITHUB_REPO (`owner/name`) before the repo exists, so its bots get the git extension too.
+  const [hubOwner, hubSlug] = (env.HUB_GITHUB_REPO ?? "").split("/");
+  const git = env.VERCEL_GIT_REPO_OWNER && env.VERCEL_GIT_REPO_SLUG ? [env.VERCEL_GIT_REPO_OWNER, env.VERCEL_GIT_REPO_SLUG] : hubOwner && hubSlug ? [hubOwner, hubSlug] : undefined;
+  const repoOwner = git?.[0];
+  const repo = git ? `${git[0]}/${git[1]}` : undefined;
   return {
     team: oidc.owner,
     project: oidc.project,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve-hub",
-  "version": "0.16.22",
+  "version": "0.16.24",
   "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/prepare.mjs

@@ -13,8 +13,9 @@
 //   Vercel Kit connection is wired in, every bot of a build from a repo gets eve's git extension, and the
 //   workspace's memory and each bot's team architecture are embedded in the bots' memory providers, (a function has no workspace cwd);
 // - /hub/manifest: the roster and the commit sha the deployment was built
-//   from, for the hub to sync from: a custom channel on main, routed in
-//   vercel.mjs. From the hub, as on each bot's eve channel (hub-oidc.mjs).
+//   from (its deployment id when it was uploaded, not built from git), for the
+//   hub to sync from: a custom channel on main, routed in vercel.mjs. From the
+//   hub, as on each bot's eve channel (hub-oidc.mjs).
 import { existsSync, mkdirSync, readdirSync, readFileSync, rmSync, rmdirSync, unlinkSync, writeFileSync } from "node:fs";
 import { createRequire } from "node:module";
 import { basename, dirname, join } from "node:path";
@@ -123,9 +124,10 @@ import workspace from "../../../../hub.manifest.json" with { type: "json" };
 // The roster, humans and subagent cap as deployed, Mac bots included, and the eve-hub and eve versions that built it, for the hub to sync from:
 // hub.manifest.json is bundled at build, so a push whose deploy fails never
 // changes it. \`sha\` is the commit the deployment was built from, which the hub
-// syncs by; a deployment with none (\`vercel deploy\` uploads no git metadata)
-// has no manifest to give.
-const sha = process.env.VERCEL_GIT_COMMIT_SHA;
+// syncs by. An uploaded deployment (onboarding's first, built while the repo is
+// made) has no commit, so it answers its own deployment id, which the hub reads
+// from the project's production deployment.
+const sha = process.env.VERCEL_GIT_COMMIT_SHA || process.env.VERCEL_DEPLOYMENT_ID;
 const { agents, humans, subagentCap, hopLimit } = parseWorkspace(workspace);
 const manifest = { sha, kit: ${JSON.stringify(KIT_VERSION)}, eve: ${JSON.stringify(EVE_VERSION)}, agents, humans, subagentCap, ...(hopLimit === undefined ? {} : { hopLimit }) };
 
@@ -133,7 +135,7 @@ export default defineChannel({
   routes: [
     GET("/hub/manifest", async (request) => {
       if (!(await isHubRequest(request, getVercelOidcToken))) return new Response("unauthorized", { status: 401 });
-      if (!sha) return new Response("no commit sha: this deployment wasn't built from git", { status: 500 });
+      if (!sha) return new Response("no commit sha or deployment id: this isn't a Vercel deployment", { status: 500 });
       return Response.json(manifest);
     }),
   ],

package/templates/engineering.md

@@ -3,12 +3,13 @@
   - Question it again whenever two fixes on one idea fail.
   - Why: a correct fix for the wrong problem costs a full build and review, then a second one.
 - **Brief before building**
-  - The owner posts a brief, scaled to the change (three lines for a copy fix): the required behavior in the human's words, how it works today (file:line), every PR, repo or moving part it adds, and the real-path test.
+  - The owner posts a brief, scaled to the change (three lines for a copy fix). It leads with its impact for the human: the measured change (latency, CPU, cost, steps), or the named work it unblocks with that work's number. Then the required behavior in the human's words, how it works today (file:line), every PR, repo or moving part it adds, and the real-path test.
+  - A step or PR with no measured impact, schema cleanup that only tidies included, is offered to the human as optional, never built by default.
   - Building waits for the human's yes, even while they're offline; meanwhile do the research, the repro and the draft. Picking an option that names what gets built counts as a yes.
   - Build only what the brief names; within it, make the sensible call on details and say which you made.
   - A new PR, repo or subsystem, or a dropped requirement, is a question to the human, never a build step or a review blocker.
   - Small reversible setup (a webhook, a secret, a project setting) isn't building: do it, then say what you set.
-  - Why: the human's yes on scope is cheaper than their no on a finished PR.
+  - Why: the human's yes on scope is cheaper than their no on a finished PR, and a step that changes nothing they can measure still costs a build, a review and the code it leaves behind.
 - **Build it right**
   - Fix the cause at the module that owns the broken invariant, then grep for the same bug elsewhere. No guard, retry, catch or default that hides a failure.
   - Subtract before you add: every new flag, layer, cache, retry or file names the requirement that forces it today. A replacement deletes the old mechanism.