@popoverinstall/cli 0.7.2 → 0.8.0

package/plugin/scripts/ensure-daemon.mjs

@@ -12,6 +12,16 @@ import { daemonAddress, popoverHome, readStdin, request, sendFireAndForget } fro
 
 const HERE = path.dirname(fileURLToPath(import.meta.url));
 
+/*
+ * A fork has nothing to do here, and doing it is actively harmful.
+ *
+ * The daemon spawns forks itself, so a daemon demonstrably exists — and registering the
+ * fork's session id would put a ghost agent on the team roster for every ask answered. Same
+ * guard, same reason, as emit-event.mjs; see its header for what the ghost then does to
+ * attribution.
+ */
+if (process.env.CLAUDE_CODE_ENTRYPOINT === "popover-fork") process.exit(0);
+
 async function main() {
   const raw = await readStdin().catch(() => "");
   let payload = null;
@@ -22,7 +32,12 @@ async function main() {
   }
 
   const alive = await ping();
-  if (!alive) {
+  // `updateInProgress()` is the interlock, not an optimisation. `popover update` stops the
+  // daemon and hands npm up to five minutes to replace the global install; a daemon started
+  // in that window runs out of the tree being replaced and holds its files open, so npm's
+  // rename fails EPERM/EBUSY on Windows and the update aborts half-done. Every session on the
+  // machine runs this hook, so without the check one of them wins that race almost every time.
+  if (!alive && !updateInProgress()) {
     const entry = resolveDaemonEntry();
     if (entry) {
       launch(entry);
@@ -95,6 +110,31 @@ function resolveDaemonEntry() {
   return null;
 }
 
+/**
+ * Whether `popover update` is replacing the install tree right now.
+ *
+ * Written by `beginUpdateLock` in packages/cli/src/daemon-lock.ts, which holds the readable
+ * version of why this exists. Duplicated here rather than imported for the same reason
+ * `resolveDaemonEntry` duplicates its path: this file must resolve no imports beyond the ones
+ * it already has, because a hook that throws breaks every session on the machine. Keep the
+ * two in step.
+ *
+ * Every branch fails towards starting the daemon. A marker with no deadline, or one whose
+ * deadline has passed, is a crashed update rather than a running one, and refusing to start
+ * on that basis would leave a machine permanently without a daemon and nothing on screen to
+ * explain it. Only a marker that is present, readable and unexpired holds us back.
+ */
+function updateInProgress() {
+  try {
+    const file = path.join(popoverHome(), "update.lock");
+    if (!existsSync(file)) return false;
+    const deadline = Number(JSON.parse(readFileSync(file, "utf8")).deadline);
+    return Number.isFinite(deadline) && Date.now() < deadline;
+  } catch {
+    return false;
+  }
+}
+
 function launch(entry) {
   try {
     // Detached with stdio to a log file: the daemon must outlive this hook, this session,

package/plugin/scripts/roster.mjs

@@ -18,6 +18,11 @@ const reply = await request(
     id: "cli",
     refresh: true,
     ...(callerSessionId() ? { fromSessionId: callerSessionId() } : {}),
+    // Fallback for the window where the daemon has not yet resolved this session's repo —
+    // the same hint the MCP server sends. Without it an unplaceable caller falls through to
+    // pure recency across every session on the machine, so `/popover:team` run in one repo
+    // could print the roster for another, under a heading claiming it was this one.
+    cwd: process.cwd(),
   },
   { timeoutMs: 8000 },
 );

package/plugin/skills/popover/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: popover
-description: Reach a teammate's Claude Code agent working in this same repo. Use when a question is about what a colleague decided, already ruled out, or is changing right now — why the code is the way it is when the repo does not say, whether work you are about to start is already in flight, or why something you did not touch is broken. Also covers handing this whole conversation to a teammate as a fork.
+description: "Judgment for reaching a teammate's Claude Code agent *without being asked to* — when it is worth spending their tokens, and which of /popover:team, /popover:ask, /popover:tell and /popover:fork fits. Nothing to invoke by hand: use it when a question turns on what a colleague decided, ruled out, or is changing right now — why the code is the way it is when the repo does not say, whether work about to start is already in flight, or why something nobody touched is broken."
 ---
 
 # popover
@@ -10,10 +10,21 @@ accumulated context you do not have: the alternatives they rejected, the constra
 forced an awkward shape, what they changed twenty minutes ago and have not pushed. popover
 lets you reach those agents.
 
-The reason this skill exists is that the moment to use popover rarely announces itself. The
+**This skill is not a command, and there is nothing here for a user to invoke.** The four
+commands are the things a user types:
+
+| | |
+| --- | --- |
+| `/popover:team` | who is working in this repo right now |
+| `/popover:ask` | one question to one agent, and you wait for the answer |
+| `/popover:tell` | a heads-up into a teammate's live session; nothing comes back |
+| `/popover:fork` | hand this whole conversation to a teammate |
+
+This file is the judgment around them: when reaching for one is worth it, which one fits, and
+what each one spends. It exists because the moment to use popover rarely announces itself. The
 user asks why something is the way it is, and the honest answer is that the repo does not
-record it — but a colleague's agent worked it out this morning. Nobody will type
-`/popover:team` for you. Noticing is your job.
+record it — but a colleague's agent worked it out this morning. Nobody will type `/popover:ask`
+for you. Noticing is your job.
 
 ## The three tools
 
@@ -139,7 +150,11 @@ The tools return errors as text; relay them rather than retrying with different
 
 ## The user-facing commands
 
-`/popover:team` and `/popover:fork` carry the full flows for when the user drives this
-explicitly, including how to present a roster and how to take delivery of a fork. Do not
-restate their steps here or work around them — when the user invokes a command, follow it.
-This skill is for the case where nobody invoked anything and you noticed the moment yourself.
+The four commands carry the full flows for when the user drives this explicitly — how to
+present a roster, how to word an ask, how to take delivery of a fork. Do not restate their
+steps here or work around them: **when the user invokes a command, follow that command.** This
+skill is for the other case, where nobody invoked anything and you noticed the moment yourself.
+
+When you act on your own, prefer naming the command you are standing in for — "I'll run the
+equivalent of `/popover:ask B1`" — so the user learns the surface they can drive directly next
+time.