borgmcp 1.0.54 → 1.0.56

package/README.md

@@ -78,6 +78,10 @@ To join under a specific role:
 borg assimilate code-reviewer --cli codex
 ```
 
+For Claude Code launches, Borg adds `--allowedTools mcp__borg__*` so Borg
+coordination tools can run without repeated permission prompts. The allowlist is
+only for Borg MCP tools; shell, file, and web actions still prompt normally.
+
 ## Core MCP tools
 
 After assimilation, the agent session has `borg_` tools available:

package/dist/bare-launch-menu.d.ts

@@ -48,6 +48,19 @@ export declare function shouldShowLaunchMenu(args: {
     stdinIsTTY: boolean;
     stdoutIsTTY: boolean;
 }): boolean;
+export declare function explicitCliLaunchHint(args: {
+    explicitCli: BorgCli | undefined;
+    stdinIsTTY: boolean;
+    stdoutIsTTY: boolean;
+    hasActiveCube: boolean;
+    hasLaunchAllTargets: boolean;
+}): string | null;
+export declare function shouldResolveExplicitCliLaunchHintTargets(args: {
+    explicitCli: BorgCli | undefined;
+    stdinIsTTY: boolean;
+    stdoutIsTTY: boolean;
+    hasActiveCube: boolean;
+}): boolean;
 /**
  * The context-filtered option set. Option 1 is always present; options 2/3 are
  * included only when applicable. Keys are sequential with no gaps, so a hidden

package/dist/bare-launch-menu.js

@@ -1,5 +1,6 @@
-const u={claude:"Claude",codex:"Codex"};function f(n){return n.extraArgs.length===0&&n.stdinIsTTY&&n.stdoutIsTTY}function h(n){const t=[{key:"1",label:`Launch (default \xB7 ${u[n.defaultCli]})`,action:{kind:"launch",cli:n.defaultCli}}];return n.otherInstalledCli&&t.push({key:String(t.length+1),label:`Launch with ${u[n.otherInstalledCli]} instead (one-shot)`,action:{kind:"launch",cli:n.otherInstalledCli}}),n.hasLaunchAllTargets&&t.push({key:String(t.length+1),label:"Launch all (this cube's drone worktrees)",action:{kind:"launch-all"}}),t}function s(n,t){const e=t.trim();if(e==="")return{ok:!0,action:n[0].action};const o=n.find(a=>a.key===e);return o?{ok:!0,action:o.action}:{ok:!1}}function d(n){return`borg \u2014 how do you want to launch?
+const c={claude:"Claude",codex:"Codex"};function f(n){return n.extraArgs.length===0&&n.stdinIsTTY&&n.stdoutIsTTY}function x(n){return!n.explicitCli||!n.stdinIsTTY||!n.stdoutIsTTY||!n.hasActiveCube||!n.hasLaunchAllTargets?null:`borg --cli ${n.explicitCli} launches ${c[n.explicitCli]} directly; use bare borg for the launch menu or borg launch-all --cli ${n.explicitCli} for all drone worktrees.
+`}function C(n){return!!(n.explicitCli&&n.stdinIsTTY&&n.stdoutIsTTY&&n.hasActiveCube)}function h(n){const t=[{key:"1",label:`Launch (default \xB7 ${c[n.defaultCli]})`,action:{kind:"launch",cli:n.defaultCli}}];return n.otherInstalledCli&&t.push({key:String(t.length+1),label:`Launch with ${c[n.otherInstalledCli]} instead (one-shot)`,action:{kind:"launch",cli:n.otherInstalledCli}}),n.hasLaunchAllTargets&&t.push({key:String(t.length+1),label:"Launch all (this cube's drone worktrees)",action:{kind:"launch-all"}}),t}function s(n,t){const e=t.trim();if(e==="")return{ok:!0,action:n[0].action};const i=n.find(l=>l.key===e);return i?{ok:!0,action:i.action}:{ok:!1}}function d(n){return`borg \u2014 how do you want to launch?
 ${n.map(e=>`  ${e.key}) ${e.label}`).join(`
 `)}
-[1]: `}async function k(n,t,e={}){const o=h(n);if(o.length===1)return o[0].action;const a=e.maxAttempts??3,c=d(o);for(let l=0;l<a;l++){const i=await t(l===0?c:`Invalid choice.
-${c}`),r=s(o,i);if(r.ok)return r.action;e.warn?.(`invalid launch-menu selection: ${JSON.stringify(i.trim())}`)}return o[0].action}export{h as buildLaunchMenuOptions,d as renderLaunchMenu,s as resolveLaunchMenuChoice,k as runBareLaunchMenu,f as shouldShowLaunchMenu};
+[1]: `}async function T(n,t,e={}){const i=h(n);if(i.length===1)return i[0].action;const l=e.maxAttempts??3,u=d(i);for(let o=0;o<l;o++){const a=await t(o===0?u:`Invalid choice.
+${u}`),r=s(i,a);if(r.ok)return r.action;e.warn?.(`invalid launch-menu selection: ${JSON.stringify(a.trim())}`)}return i[0].action}export{h as buildLaunchMenuOptions,x as explicitCliLaunchHint,d as renderLaunchMenu,s as resolveLaunchMenuChoice,T as runBareLaunchMenu,C as shouldResolveExplicitCliLaunchHintTargets,f as shouldShowLaunchMenu};

package/dist/claude.js

@@ -1,15 +1,15 @@
 #!/usr/bin/env node
-import{spawn as E}from"child_process";import{randomUUID as M}from"node:crypto";import{basename as O}from"node:path";import{createInterface as H}from"node:readline/promises";import t from"chalk";import{findProjectRoot as y,getActiveCube as F,getLaunchModel as N,inboxPathForDrone as B,setCodexWakeTarget as _,pruneDeadCodexWakeTargets as W}from"./cubes.js";import{applyOllamaLaunchEnv as G,checkModelReachable as Y}from"./model-presets.js";import{handleVersionFlag as U,getPackageVersion as h}from"./version.js";import{isHelpFlag as T,setupHelpText as V,topLevelHelpText as K,assimilateHelpText as j}from"./cli-help.js";import{runSpawn as q}from"./spawn.js";import{buildClaudeLaunchArgs as X}from"./claude-launch-args.js";import{parseSyncArgs as z,runSync as J}from"./sync.js";import{parseCleanupArgs as Q,runCleanup as Z}from"./cleanup-cmd.js";import{parseAssimilateArgs as ee}from"./parse-assimilate-args.js";import{runAssimilate as re}from"./assimilate-cmd.js";import{buildDefaultAssimilateDeps as oe}from"./assimilate-deps.js";import{parseLaunchAllArgs as A}from"./parse-launch-all-args.js";import{unknownSubcommand as se}from"./unknown-subcommand.js";import{runLaunchAll as I}from"./launch-all-cmd.js";import{buildDefaultLaunchAllDeps as C}from"./launch-all-deps.js";import{discoverDroneCandidates as te}from"./launch-all-discovery.js";import{runBareLaunchMenu as ae,shouldShowLaunchMenu as ie}from"./bare-launch-menu.js";import{setTerminalTitle as ce}from"./terminal-title.js";import{initConsolePrefix as ne,consolePrefix as o}from"./console-prefix.js";import{initDebugFromArgv as le}from"./debug.js";import{fetchLatestBorgmcpVersion as de,compareVersionsForStaleness as pe}from"./stale-version-check.js";import{defaultCliChoiceDeps as ue,detectCliAvailability as k,installedCliNames as P,parseCliFlag as me,resolveCliChoice as fe}from"./cli-platform.js";import{getRefreshToken as ge,getIdToken as he}from"./config.js";import{composeGetStarted as we,shouldShowGetStarted as xe}from"./get-started.js";import{prepareCodexRemoteLaunch as Ce,withCodexCwdArg as ke,defaultCodexRemoteDeps as ve,checkCodexBridgeHealthy as be}from"./codex-remote.js";import{findLoadedCodexThread as $e}from"./codex-app-server.js";import{buildAgentKickoffPrompt as Se,buildKickoffWakePathClause as ye,recordCodexWakeTarget as Te,socketPathFromRemoteArgs as R}from"./codex-launch.js";import{codexBorgSessionConfigArgs as Ae}from"./launch-gate.js";import{addCodexMcpServer as Ie,addCodexSessionStartHook as Pe,addCodexUserPromptSubmitHook as Re,addMcpServer as Le,addProjectSessionStartHook as De,addUserPromptSubmitHook as Ee,isCodexMcpServerConfigured as Me,isMcpServerConfigured as Oe,removeSessionStartHook as He}from"./config-utils.js";async function Fe(){le(process.argv),U(),await ne();const n=(async()=>{if(!process.stderr.isTTY)return;const e=h(),r=await de();if(!r)return;const i=pe(e,r);i.stale&&i.message&&process.stderr.write(`${o()}${i.message}
-`)})();if((process.argv[2]==="--help"||process.argv[2]==="-h")&&(process.stdout.write(K(h())),process.exit(0)),process.argv[2]==="setup"){T(process.argv[3])&&(process.stdout.write(V(h())),process.exit(0)),await import("./setup.js");return}if(process.argv[2]==="assimilate"){process.argv.slice(3).some(T)&&(process.stdout.write(j(h())),process.exit(0));const e=ee(process.argv.slice(3));e.ok||(process.stderr.write(t.red(`${o()}\u25FC borg assimilate: ${e.error}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=oe(),i=await re({role:e.role,flags:e.flags},r);process.exit(i)}if(process.argv[2]==="spawn"){const e=await q();process.exit(e)}if(process.argv[2]==="sync"){const e=z(process.argv.slice(3));e.ok||(process.stderr.write(t.red(`${o()}\u25FC borg sync: ${e.error}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=await J({},e.options);process.exit(r)}if(process.argv[2]==="cleanup"){const e=Q(process.argv.slice(3));e.ok||(process.stderr.write(t.red(`${o()}\u25FC borg cleanup: ${e.error}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=await Z({},e.options);process.exit(r)}if(process.argv[2]==="launch-all"){const e=A(process.argv.slice(3));e.ok||(process.stderr.write(t.red(`${o()}\u25FC borg launch-all: ${e.error}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=C(),i=await I(e.args,r);process.exit(i)}const c=se(process.argv[2]);if(c!==null&&(process.stderr.write(t.red(`${o()}\u25FC unknown command: ${c}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1)),xe(await ge()!==null,await he()!==null)){const e=P(k()).length>0;process.stdout.write(we(e)),process.exit(0)}const f=me(process.argv.slice(2));f.error&&(process.stderr.write(t.red(`${o()}\u25FC ${f.error}
-`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const v=async e=>{const r=H({input:process.stdin,output:process.stdout});try{return await r.question(e)}finally{r.close()}};let s=await fe(f.cli,ue(v,()=>process.stdin.isTTY===!0));Ne();const a=await F();if(ie({extraArgs:process.argv.slice(2),stdinIsTTY:process.stdin.isTTY===!0,stdoutIsTTY:process.stdout.isTTY===!0})){const e=P(k()).find(m=>m!==s)??null;let r=!1;a&&(r=(await te({targetCubeId:a.cubeId},C())).length>0);const i=await ae({defaultCli:s,otherInstalledCli:e,hasLaunchAllTargets:r},v);if(i.kind==="launch-all"){const m=A([]),D=m.ok?await I(m.args,C()):1;process.exit(D)}s=i.cli}const l=f.rest;ce(a?{label:a.droneLabel,cubeName:a.name}:null,O(process.cwd()));const L=ye(s==="codex"?"codex":"claude",a&&s==="claude"?B(a.cubeId,a.droneId):null);await Promise.race([n,new Promise(e=>setTimeout(e,2e3))]);const b=s==="codex"?`borg-wake-${M()}`:null;let g,$=[],d={...process.env,BORG_SESSION:"1"},p=null,u=null;if(s==="codex"&&!l.includes("--remote")){console.error(`${o()}${t.gray("\u25FC Starting Codex remote-wake app-server\u2026")}`);const e=await Ce(ve());e.warning?(console.error(`${o()}${t.yellow(`warning: ${e.warning}`)}`),g="\u26A0 Codex wake-path capability check failed: remote-control is unavailable for this session. Run borg_regen manually whenever you return, and expect only fallback wakeups until relaunch."):g="Codex wake-path capability check passed: remote-control socket established for this session.",$=e.args,d={...process.env,...e.env,BORG_SESSION:"1"},p=R(e.args),u=e.server?.cleanup??null}else s==="codex"&&l.includes("--remote")&&(g="Codex wake-path capability check: using caller-provided --remote socket; if no wake arrives, run borg_regen manually when returning to the session.",p=R(l),p&&(d={...process.env,BORG_CODEX_REMOTE_WAKE:"1",BORG_SESSION:"1"}));if(a){const e=await N(a.cubeId,y(),a.droneId),r=G(d,e,process.env);if(d=r.env,r.probe){const i=await Y(r.probe.descriptor,fetch,r.probe.baseUrl);i.ok||console.error(`${o()}${t.yellow(`warning: ${i.message}`)}`)}}const w=Se({cli:s,codexWakeNonce:b,monitorClause:L,codexWakePathClause:g});let x;s==="codex"?x=[...Ae(),...$,...ke([...l,w],process.cwd())]:x=X(l,w),console.error(`${o()}${t.blue(`\u25FC Launching ${s==="claude"?"Claude Code":"Codex"}\u2026`)}`);const S=E(s,x,{stdio:"inherit",shell:!1,env:d});s==="codex"&&a&&p&&(Te({deps:{setCodexWakeTarget:_,findLoadedCodexThread:$e},cubeId:a.cubeId,droneId:a.droneId,socketPath:p,passthroughArgs:l,previewNeedle:b??w.slice(0,120),cwd:process.cwd(),launchedAtSeconds:Math.floor(Date.now()/1e3)}),W(e=>be(e))),S.on("error",e=>{if(u)try{u()}catch{}e.code==="ENOENT"?(console.error(`${o()}${t.red(`
-\u25FC Failed to launch ${s}`)}`),console.error(`${o()}${t.gray(`Make sure ${s} is installed.
-`)}`)):console.error(`${o()}${t.red(`
+import{spawn as F}from"child_process";import{randomUUID as N}from"node:crypto";import{basename as B}from"node:path";import{createInterface as _}from"node:readline/promises";import i from"chalk";import{findProjectRoot as L,getActiveCube as W,getLaunchModel as G,inboxPathForDrone as Y,setCodexWakeTarget as U,pruneDeadCodexWakeTargets as V}from"./cubes.js";import{applyOllamaLaunchEnv as K,checkModelReachable as j}from"./model-presets.js";import{handleVersionFlag as q,getPackageVersion as g}from"./version.js";import{isHelpFlag as R,setupHelpText as X,topLevelHelpText as z,assimilateHelpText as J}from"./cli-help.js";import{runSpawn as Q}from"./spawn.js";import{buildClaudeLaunchArgs as Z}from"./claude-launch-args.js";import{parseSyncArgs as ee,runSync as re}from"./sync.js";import{parseCleanupArgs as oe,runCleanup as se}from"./cleanup-cmd.js";import{parseAssimilateArgs as te}from"./parse-assimilate-args.js";import{runAssimilate as ie}from"./assimilate-cmd.js";import{buildDefaultAssimilateDeps as ae}from"./assimilate-deps.js";import{parseLaunchAllArgs as P}from"./parse-launch-all-args.js";import{unknownSubcommand as ce}from"./unknown-subcommand.js";import{runLaunchAll as D}from"./launch-all-cmd.js";import{buildDefaultLaunchAllDeps as b}from"./launch-all-deps.js";import{discoverDroneCandidates as ne}from"./launch-all-discovery.js";import{explicitCliLaunchHint as le,runBareLaunchMenu as de,shouldResolveExplicitCliLaunchHintTargets as pe,shouldShowLaunchMenu as ue}from"./bare-launch-menu.js";import{setTerminalTitle as me}from"./terminal-title.js";import{initConsolePrefix as fe,consolePrefix as o}from"./console-prefix.js";import{initDebugFromArgv as ge}from"./debug.js";import{fetchLatestBorgmcpVersion as he,compareVersionsForStaleness as we}from"./stale-version-check.js";import{defaultCliChoiceDeps as xe,detectCliAvailability as k,installedCliNames as E,parseCliFlag as Ce,resolveCliChoice as ve}from"./cli-platform.js";import{getRefreshToken as be,getIdToken as ke}from"./config.js";import{composeGetStarted as $e,shouldShowGetStarted as Se}from"./get-started.js";import{prepareCodexRemoteLaunch as Ae,withCodexCwdArg as Te,defaultCodexRemoteDeps as ye,checkCodexBridgeHealthy as Ie}from"./codex-remote.js";import{findLoadedCodexThread as Le}from"./codex-app-server.js";import{buildAgentKickoffPrompt as Re,buildKickoffWakePathClause as Pe,recordCodexWakeTarget as De,socketPathFromRemoteArgs as H}from"./codex-launch.js";import{codexBorgSessionConfigArgs as Ee}from"./launch-gate.js";import{addCodexMcpServer as He,addCodexSessionStartHook as Me,addCodexUserPromptSubmitHook as Oe,addMcpServer as Fe,addProjectSessionStartHook as Ne,addUserPromptSubmitHook as Be,isCodexMcpServerConfigured as _e,isMcpServerConfigured as We,removeSessionStartHook as Ge}from"./config-utils.js";async function Ye(){ge(process.argv),q(),await fe();const n=(async()=>{if(!process.stderr.isTTY)return;const e=g(),r=await he();if(!r)return;const a=we(e,r);a.stale&&a.message&&process.stderr.write(`${o()}${a.message}
+`)})();if((process.argv[2]==="--help"||process.argv[2]==="-h")&&(process.stdout.write(z(g())),process.exit(0)),process.argv[2]==="setup"){R(process.argv[3])&&(process.stdout.write(X(g())),process.exit(0)),await import("./setup.js");return}if(process.argv[2]==="assimilate"){process.argv.slice(3).some(R)&&(process.stdout.write(J(g())),process.exit(0));const e=te(process.argv.slice(3));e.ok||(process.stderr.write(i.red(`${o()}\u25FC borg assimilate: ${e.error}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=ae(),a=await ie({role:e.role,flags:e.flags},r);process.exit(a)}if(process.argv[2]==="spawn"){const e=await Q();process.exit(e)}if(process.argv[2]==="sync"){const e=ee(process.argv.slice(3));e.ok||(process.stderr.write(i.red(`${o()}\u25FC borg sync: ${e.error}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=await re({},e.options);process.exit(r)}if(process.argv[2]==="cleanup"){const e=oe(process.argv.slice(3));e.ok||(process.stderr.write(i.red(`${o()}\u25FC borg cleanup: ${e.error}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=await se({},e.options);process.exit(r)}if(process.argv[2]==="launch-all"){const e=P(process.argv.slice(3));e.ok||(process.stderr.write(i.red(`${o()}\u25FC borg launch-all: ${e.error}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const r=b(),a=await D(e.args,r);process.exit(a)}const c=ce(process.argv[2]);if(c!==null&&(process.stderr.write(i.red(`${o()}\u25FC unknown command: ${c}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1)),Se(await be()!==null,await ke()!==null)){const e=E(k()).length>0;process.stdout.write($e(e)),process.exit(0)}const l=Ce(process.argv.slice(2));l.error&&(process.stderr.write(i.red(`${o()}\u25FC ${l.error}
+`)),process.stderr.write("Run `borg --help` for usage.\n"),process.exit(1));const $=async e=>{const r=_({input:process.stdin,output:process.stdout});try{return await r.question(e)}finally{r.close()}};let s=await ve(l.cli,xe($,()=>process.stdin.isTTY===!0));Ue();const t=await W();let h;const S=async()=>t?(h===void 0&&(h=(await ne({targetCubeId:t.cubeId},b())).length>0),h):!1,w=process.stdin.isTTY===!0,x=process.stdout.isTTY===!0,A=le({explicitCli:l.cli,stdinIsTTY:w,stdoutIsTTY:x,hasActiveCube:t!==null,hasLaunchAllTargets:pe({explicitCli:l.cli,stdinIsTTY:w,stdoutIsTTY:x,hasActiveCube:t!==null})?await S():!1});if(A&&process.stderr.write(A),ue({extraArgs:process.argv.slice(2),stdinIsTTY:w,stdoutIsTTY:x})){const e=E(k()).find(a=>a!==s)??null,r=await de({defaultCli:s,otherInstalledCli:e,hasLaunchAllTargets:await S()},$);if(r.kind==="launch-all"){const a=P([]),O=a.ok?await D(a.args,b()):1;process.exit(O)}s=r.cli}const d=l.rest;me(t?{label:t.droneLabel,cubeName:t.name}:null,B(process.cwd()));const M=Pe(s==="codex"?"codex":"claude",t&&s==="claude"?Y(t.cubeId,t.droneId):null);await Promise.race([n,new Promise(e=>setTimeout(e,2e3))]);const T=s==="codex"?`borg-wake-${N()}`:null;let f,y=[],p={...process.env,BORG_SESSION:"1"},u=null,m=null;if(s==="codex"&&!d.includes("--remote")){console.error(`${o()}${i.gray("\u25FC Starting Codex remote-wake app-server\u2026")}`);const e=await Ae(ye());e.warning?(console.error(`${o()}${i.yellow(`warning: ${e.warning}`)}`),f="\u26A0 Codex wake-path capability check failed: remote-control is unavailable for this session. Run borg_regen manually whenever you return, and expect only fallback wakeups until relaunch."):f="Codex wake-path capability check passed: remote-control socket established for this session.",y=e.args,p={...process.env,...e.env,BORG_SESSION:"1"},u=H(e.args),m=e.server?.cleanup??null}else s==="codex"&&d.includes("--remote")&&(f="Codex wake-path capability check: using caller-provided --remote socket; if no wake arrives, run borg_regen manually when returning to the session.",u=H(d),u&&(p={...process.env,BORG_CODEX_REMOTE_WAKE:"1",BORG_SESSION:"1"}));if(t){const e=await G(t.cubeId,L(),t.droneId),r=K(p,e,process.env);if(p=r.env,r.probe){const a=await j(r.probe.descriptor,fetch,r.probe.baseUrl);a.ok||console.error(`${o()}${i.yellow(`warning: ${a.message}`)}`)}}const C=Re({cli:s,codexWakeNonce:T,monitorClause:M,codexWakePathClause:f});let v;s==="codex"?v=[...Ee(),...y,...Te([...d,C],process.cwd())]:v=Z(d,C),console.error(`${o()}${i.blue(`\u25FC Launching ${s==="claude"?"Claude Code":"Codex"}\u2026`)}`);const I=F(s,v,{stdio:"inherit",shell:!1,env:p});s==="codex"&&t&&u&&(De({deps:{setCodexWakeTarget:U,findLoadedCodexThread:Le},cubeId:t.cubeId,droneId:t.droneId,socketPath:u,passthroughArgs:d,previewNeedle:T??C.slice(0,120),cwd:process.cwd(),launchedAtSeconds:Math.floor(Date.now()/1e3)}),V(e=>Ie(e))),I.on("error",e=>{if(m)try{m()}catch{}e.code==="ENOENT"?(console.error(`${o()}${i.red(`
+\u25FC Failed to launch ${s}`)}`),console.error(`${o()}${i.gray(`Make sure ${s} is installed.
+`)}`)):console.error(`${o()}${i.red(`
 \u25FC Failed to launch ${s}: ${e.message}
-`)}`),process.exit(1)}),S.on("exit",e=>{if(u)try{u()}catch{}process.exit(e??0)})}function Ne(){const n=k();if(n.claude)try{Oe()||Le(),De(y(process.cwd())),He(),Ee()}catch(c){console.error(`${o()}${t.yellow(`warning: Claude Code integration check failed: ${c?.message??c}`)}`)}if(n.codex)try{Me()||Ie(),Pe(),Re()}catch(c){console.error(`${o()}${t.yellow(`warning: Codex integration check failed: ${c?.message??c}`)}`)}}Fe().catch(n=>{console.error(`${o()}${t.red(`
+`)}`),process.exit(1)}),I.on("exit",e=>{if(m)try{m()}catch{}process.exit(e??0)})}function Ue(){const n=k();if(n.claude)try{We()||Fe(),Ne(L(process.cwd())),Ge(),Be()}catch(c){console.error(`${o()}${i.yellow(`warning: Claude Code integration check failed: ${c?.message??c}`)}`)}if(n.codex)try{_e()||He(),Me(),Oe()}catch(c){console.error(`${o()}${i.yellow(`warning: Codex integration check failed: ${c?.message??c}`)}`)}}Ye().catch(n=>{console.error(`${o()}${i.red(`
 \u25FC Error: ${n.message}
 `)}`),process.exit(1)});

package/dist/cli-help.js

@@ -1,4 +1,4 @@
-function o(e){return e==="--help"||e==="-h"}function n(e){return`borgmcp ${e} \u2014 run several AI coding agents on one project, together.
+function n(e){return e==="--help"||e==="-h"}function o(e){return`borgmcp ${e} \u2014 run several AI coding agents on one project, together.
               They coordinate through a shared log (a "cube"). For Claude Code & Codex.
 
 Docs & quickstart: https://borgmcp.ai/get-started
@@ -7,7 +7,7 @@ Install Claude Code or Codex first. Type \`borg ...\` in your terminal;
 type \`borg_...\` inside your agent session once you've joined a cube ("assimilate").
 
 Usage:
-  borg                     Launch your agent CLI with cube context
+  borg                     Launch your agent CLI; in a TTY, bare borg may show the launch menu
   borg setup               Set up OAuth + register MCP server
   borg setup --no-browser  Set up from SSH/headless terminals
   borg assimilate [role]   Join a cube (creates one if needed)
@@ -16,7 +16,9 @@ Usage:
   borg sync [--prune]      Sync this worktree's branch to origin/main
   borg cleanup [--prune]   Report (or --prune) worktrees orphaned by evicted drones
   borg launch-all [cube]   Launch all drone worktrees of a cube (default: active cube)
-  borg --cli claude|codex  Choose agent CLI for this project
+  borg launch-all [cube] --cli claude|codex
+                           Launch all drone worktrees with that agent CLI
+  borg --cli claude|codex  Launch that agent CLI directly
   borg --version           Show installed version
 
 All other arguments are passed through to the selected agent CLI.
@@ -59,4 +61,4 @@ Usage:
                            for SSH / headless / container terminals. Alias: --device.
                            Auto-detected on SSH/headless; this forces it.
   borg setup --help        Show this help
-`}export{t as assimilateHelpText,o as isHelpFlag,r as setupHelpText,n as topLevelHelpText};
+`}export{t as assimilateHelpText,n as isHelpFlag,r as setupHelpText,o as topLevelHelpText};

package/dist/regen-format.js

@@ -1,12 +1,12 @@
-import{ROLE_SCOPED_SAFETY_DISCIPLINES as k,UNIVERSAL_SAFETY_DISCIPLINES as _}from"./templates.js";import{parseRoleSections as A}from"./role-section.js";import{formatRoleAgentLabel as N}from"./roster-render.js";import{formatDroneAddressToken as T}from"./drone-address.js";function M(e){if(!e||!e.trim())return null;try{const r=JSON.parse(e)?.source;return typeof r=="string"?r:null}catch{return null}}function C(e,o){return e==="codex"?"Wake path: Codex wakes via the app-server remote-wake injection \u2014 there is no tail-Monitor or `/loop` heartbeat to arm. If no wake arrives when you return to the session, run `borg_regen` manually.":["Arm your wake path before working:",`1. **Inbox Monitor** (wake path) \u2014 run a persistent Monitor on \`borg-inbox-monitor ${o}\` so cube posts wake you in real time.`,"2. **Engage `/loop`** (self-paced) so you keep waking to triage the cube.","3. **Fallback heartbeat** \u2014 set a ~1800s (30-min) `ScheduleWakeup` so you never go fully silent."].join(`
-`)}function j(e,o){return{cubeName:o?.cube?.name??e.name,droneLabel:o?.drone?.label??e.droneLabel,roleName:o?.role?.name??e.roleName??null}}function q(e){const{cubeName:o,droneLabel:r,roleName:n,inboxPath:t,agentKind:i,source:s}=e,c=s==="clear"?"\n_(`/clear` cleared your conversation + session-scoped `/loop` and `ScheduleWakeup` heartbeat \u2014 re-establish them now.)_\n":"";return[`# Cube: ${o} \u2014 ${r}`,"",`**Your role:** ${n||"_(call `borg_regen` to load)_"}`,c,"You are a Borg drone \u2014 coordinate through the cube log, and never pause for the user. Blocked \u2192 escalate to your cube's coordinating role.","",C(i,t),"","This orientation is intentionally lean. For your full cube directive, role playbook, and roster \u2014 and your complete operating disciplines \u2014 call `borg_regen` (and load `borg_playbook` / `borg_cube` once per session).",""].join(`
-`)}function x(){return"## How to operate as a Drone\n\nYou're a Drone in a Cube. Coordinate with other drones through the activity log.\n\n**User asks how Borg MCP works** \u2014 a feature, setup, pricing, or concept question? Call `borg_docs {topic}` for the documentation index, then WebFetch the matching section URL and answer from the page. Don't guess borgmcp's own behavior from memory.\n\n**Tools:**\n- `borg_regen` \u2014 refresh full state (your role, roster, unread-log COUNT, and fetch-on-demand pointers) in one call; the cube directive (\u2192 `borg_cube`), the operating-playbook detail (\u2192 `borg_playbook`), and the recent-log payload (\u2192 `borg_read-log` when count >0) are NOT inlined \u2014 fetch them on demand\n- `borg_cube` \u2014 re-read the cube directive and the role overview\n- `borg_role` \u2014 re-read your role's detailed playbook\n- `borg_roster` \u2014 see who else is connected\n- `borg_read-log unread_only=true [limit]` \u2014 drain unread log entries from your server-side cursor\n- `borg_log <message>` \u2014 append to the log\n- `borg_assimilate <cube>` \u2014 switch to a different cube\n\n**How coordination works:** the Cube gives primitives, not workflows. Your role's `detailed_description` (above) is your playbook \u2014 its conventions + signals come from there, not the system. The log is the coordination channel. Different cubes, different conventions.\n\n**Default: act autonomously, coordinate through the log.** Don't wait for user input. Need input \u2192 post the question, continue other work, other drones respond. The human supervisor is reachable through your cube's coordinating / human-seat role (the role your cube designates for direction + integration), or the Queen role when the seat is delegated to a drone \u2014 one continuous seat. Your role's `detailed_description` says when to escalate + which decisions need human input; follow it.\n\n**Operating loop \u2014 each wake, in order:**\n1. Drain unread: `borg_read-log unread_only=true` (oldest-first, repeat until `behind_by=0`) before acting. The \"Cube log\" section gives your UNREAD COUNT.\n2. Apply your role's conventions to each entry. Act on: questions you can answer; blocked peers you can unblock; unowned work you can claim; decisions affecting you.\n3. Actionable signal \u2192 act + post the convention. Don't wait to be asked.\n4. User prompt waiting \u2192 respond, informed by cube context; log substantive units (shipped changes, blockers, findings) regardless of who initiated.\n5. Nothing actionable + no prompt \u2192 done; wait for next wake.\n\n**On a `<task-notification>` wake:** the payload is a truncatable preview; the full entry is in the DB. Drain: `borg_read-log unread_only=true limit=20`, repeat until `behind_by=0`. Do NOT triage with `since=<notification timestamp>` (strict-after \u2014 skips the boundary entry) or a bare window (skips older-unread during bursts).\n\n**On first wake this session:** post one `ARRIVAL: <your-label> (<your-role>) online on <hostname> at <project-path>` (run `hostname`; use cwd for the path). One-time per session \u2014 don't repeat on later wakes; skip if already posted this session (e.g. after a `/mcp` reconnect).\n\n**When a log entry routes work to you** (a routing/assignment-class entry per your cube's conventions that names your label + asks for action, or a direct `<your-label>:` mention): call `borg_ack entry_id=<id>` within ~60s. Use the `borg_ack` TOOL, not an in-band `ACK:` post (it records a queryable flag + wakes the author's Monitor + keeps the log clean). Ack = receipt, not completion (`STARTING` / `DONE` still apply). Ack only routing-class signals \u2014 not every mention.\n\n**Claim a work item before you start it (`borg_ack ... kind=claim`):** `borg_ack` has two kinds \u2014 `ack` (receipt, the default) and `claim` (advisory ownership of a routed work item you are about to take). When a routed entry could be picked up by more than one drone, `borg_ack entry_id=<id> kind=claim` BEFORE starting \u2014 it announces you are taking it so peers skip the duplicate work, and wakes the rest of the entry's audience. If a live peer already holds the claim, skip it; if the claim is STALE (the claimant went silent past the wake-path SLA), re-claim and proceed. A claim is ADVISORY only \u2014 it NEVER substitutes for the completion or approval signal your role's conventions require; a bogus or abandoned claim can at most delay a work item, never bypass its real gate.\n\n**When stuck:** post your blocker per your role's conventions, continue other work. Escalation is per your role detail, not by stalling.\n\n**Anti-passive (lane idle = no work routed to you, no actionable signal in the log):**\n- If your work arrives via dispatch / a work queue: when your lane goes idle, post your role's availability signal (capacity clean, awaiting next assignment from your coordinating role) \u2014 once per idle period, don't spam. No assignment in ~15 min \u2192 ping your coordinating role (capacity available since <time>; any queue item to pick up?).\n- If your work is SELF-DIRECTED (not dispatch-driven): do NOT post an availability signal \u2014 proactively surface lane-substantive work per your role (reviews, audits, proposals, coherence / quality sweeps on relevant in-flight work).\n- Route work-asks through your cube's coordinating role, never directly to the human Queen.\n\n**Verify factual claims:** verify any verifiable claim \u2014 versions, code-state, prod behavior, npm state \u2014 against the SOURCE-OF-TRUTH surface (`git tag` / `git show <ref>:<path>` / grep, `curl` / `wrangler tail`, `npm view`, the live DB) BEFORE writing it; never a derivative artifact (another post, summary, or your own prior framing). The full discipline \u2014 the v1/v2/v3 sharpening levels, the per-claim-type concrete surfaces, and four-surface propagation (brainstorm / comment / review / issue-filing) \u2014 is in the operating-playbook chapter (`borg_playbook`; loaded via the session-start block in your regen).\n\n**Posting to the log:** post per your role's conventions whenever you start/finish a task, get stuck, answer a drone, or learn something others need \u2014 regardless of who initiated (a log signal, your own scan, or a user prompt). Conventions live in your role detail; the system is vocabulary-agnostic.\n\n**Routing posts \u2014 widen the directed default:** the taxonomy routes most prefixes DIRECTED to your cube's coordinating role; your `to:` / `visibility:` overrides it. Widen when a post must reach more than the coordinating role:\n- Posting a verdict / decision / result a specific drone is waiting on: add `to:[that drone]` so they're WOKEN \u2014 without it they can be left UNAWARE of their own merge or feedback. Directed governs the WAKE; it is NOT read-confidentiality: every member can read every entry \u2014 the cube is the trust boundary \u2014 so never post secrets relying on `to:[x]`.\n- Any drone posting a multi-seat DELIVERABLE (spec / security classification / review artifact 3+ seats build or gate against): pass `visibility:broadcast` (or `to:[the seats]`) EVEN IF your prefix (`DONE` etc.) is a directed status class \u2014 else only your coordinating role wakes (taxonomy routes by prefix, not payload) and the building/gating seats miss it.\n\n**Pre-commit git hygiene (universal):**\n\nAny drone that commits code: run `git diff --staged --stat` before `git commit` to verify file count + LOC direction + paths match your intent. Catches deleted files / anomalous -LOC / wrong paths pre-push. Your role may layer more git rules (code-implementing + coordinating roles typically carry the full set)."}const H=x();function V(){return'## Operating playbook \u2014 full disciplines (borg_playbook chapter)\n\nThis is the on-demand detail behind the rule-spine in your regen. Load it ONCE per session; it is static \u2014 do not re-fetch on every wake.\n\n**Verifying factual claims:**\n\nAny time you make a factual claim that could be verified \u2014 "this shipped as version Y", "function Z does W", "endpoint A returns B in prod", "package P is at version Q on npm" \u2014 verify the claim against a SOURCE-OF-TRUTH surface BEFORE writing it, not against a derivative artifact (another post, doc, summary, or your own prior framing). Three sharpening levels:\n\n- **v1 (verify against the actual surface):** check the claim against the surface it describes (e.g. a code-state claim \u2192 grep the file). Apply when the claim is about code-state.\n- **v2 (source-of-truth vs derivative artifacts):** when the verification surface itself could carry the original error chain (another post citing the same wrong claim, a doc copy-mirrored from the post you\'re checking), verify against the canonical source-of-truth: `git tag` for version-attribution, code-by-grep / direct file read for code-state, live `curl` or `wrangler tail` for prod-state, `npm view` for npm-state. Apply when version numbers, deploy timestamps, or other discrete facts are in scope.\n- **v3 (end-to-end execution path vs originating mechanism):** when verifying a live-mechanism claim ("the watchdog wakes silent drones"), verify the END-TO-END execution path, not just each isolated component \u2014 each isolated mechanism can be correct while the path between them silently breaks. Apply when live-mechanism correctness is being claimed; trace the path the wake/value/state actually takes from origin to terminal observer.\n\n**Concrete verification surfaces by claim type:**\n- Version attribution \u2192 `git tag --contains <sha>` or `git log --oneline <tag>`\n- Code state \u2192 match the grep surface to the claim surface:\n  - Local uncommitted claim \u2192 `grep -n "<symbol>" <file>` or direct file read in the working tree\n  - `origin/main`, PR head, branch, merge-SHA, or tag claim \u2192 `git show <ref>:<path> | grep -n "<symbol>"` (examples: `git show origin/main:workers/heartbeat.ts | grep -n "last_log_post"`; `git show origin/feat/foo:client/src/log-stream.ts | grep -n "ownDrone"`; `git show abc1234:workers/cubes.ts | grep -n "visibility"`)\n- Prod state \u2192 `curl https://<endpoint>` or `wrangler tail --env production`\n- npm registry state \u2192 `npm view <package>@<version>` or `npm view <package>@latest`\n- DB state \u2192 query through the existing `db` interface; never trust a doc claim about row counts / column values\n- Cube log state \u2192 `borg_read-log unread_only=true` for wake triage, draining until `behind_by=0`; don\'t cite from memory or from another drone\'s summary\n- Ratified cube decision \u2192 `borg_decisions {topic}` \u2014 cite the registry\'s active decision by topic; NEVER restate a ratified decision from memory (a memory restatement drifts on the axis). A ratified decision is a first-class verifiable claim type with its own source of truth: the active registry entry. Recording one is `borg_decide` (seat-holder only \u2014 recording IS the ratification act).\n\n**The discipline is universal to reviewer-class actions** (Code Reviewer formal gates + Security Auditor SR gates + PM-courtesy verifications + UX-courtesy reviews + any drone making a verification-worthy factual claim in their cube-log post). It lives in this universal playbook rather than any one role\'s text because it applies to ALL reviewers.\n\n**Four-surface propagation:**\n\nThe discipline applies at FOUR surfaces. Catches at the surface closest to origin are cheapest; catches at later surfaces have already propagated through earlier consumers:\n\n- **Surface 1 (brainstorm-proposal time)**: when a brainstorm contribution names specific code identifiers / API field names / enum values / column names / function signatures, the PROPOSING drone source-grep\'s the referenced file BEFORE composing the proposal. If the proposal cites current `origin/main` or a branch/SHA, grep that ref via `git show <ref>:<path> | grep`; working-tree grep is only for explicitly local/uncommitted claims. Cheapest catch surface; one drone catches one error.\n- **Surface 2 (comment/JSDoc/docstring writing time)**: when an implementation comment cites cross-file invariants (other modules\' thresholds, schema columns, enum values, semantic contracts), the WRITING drone source-grep\'s the referenced file BEFORE writing the comment. If the comment describes a merged/base/PR-head state, grep the named ref via `git show <ref>:<path> | grep`; don\'t let a stale local checkout stand in for the ref being described. Mid-cost catch; one drone catches one error but downstream reviewers may inherit the wrong mental model from the comment.\n- **Surface 3 (review-time verification)**: the existing review-class discipline (Code Reviewer formal gates + Security Auditor SR gates + PM/UX/QA courtesy reviews). Late catch opportunity; if the error propagated through Surfaces 1 + 2, multiple reviewers may have already trusted the framing instead of source-grepping themselves.\n- **Surface 4 (durable-tracking-artifact-writing time)**: when filing a deferred-tracking issue from a cube event payload, the FILING drone fetches the originating entry\'s full body from the cube log BEFORE composing the issue body. For routine wake triage, use `borg_read-log unread_only=true` and drain until caught up; do not rely on a truncated event preview or a `since=<same timestamp>` read, which can skip the boundary entry. Cube event previews can truncate substantive content (mid-paragraph cuts on long entries); filing from the truncated preview trusts a derivative artifact instead of the source-of-truth full entry. Most expensive surface \u2014 the filed issue becomes the cube\'s durable cross-cycle memory; correcting it requires a follow-up correction post, and later pickup drones inherit the incomplete framing if the correction is missed.\n\n**Ratified-decision drift is a four-surface drift-class.** A ratified cube decision restated from memory drifts exactly like a code-identifier claim \u2014 it propagates dispatch (Surface 1, brainstorm) \u2192 copy (Surface 2, comment) \u2192 gate (Surface 3, review), and the cheapest catch is at the brainstorm surface. At each surface, a drone restating a ratified decision source-reads `borg_decisions {topic}` FIRST: the active registry entry is the source of truth; your memory is a derivative artifact. Core rule \u2014 **cite ratified decisions by topic; never restate one from memory.**'}function D(e){const o=typeof e=="string"?new Date(e):e,r=Date.now()-o.getTime();if(!Number.isFinite(r)||r<0)return"just now";const n=Math.floor(r/1e3);if(n<60)return`${n}s ago`;const t=Math.floor(n/60);if(t<60)return`${t}m ago`;const i=Math.floor(t/60);return i<24?`${i}h ago`:`${Math.floor(i/24)}d ago`}function I(e){return e==null||Array.isArray(e)&&e.length===0?"Tip: no message taxonomy declared \u2014 set one to enable intent-based smart routing (#468). Use borg_update-cube with a taxonomy array, or add classes with borg_patch-taxonomy-class.":""}function J(e,o){return e.drone?.label??o??null}let f=!1,y=null;function G(){f=!1,y=null}function L(e){const o=e??"",r=k.filter(n=>o.includes(n));return[..._,...r]}function $(e,o){return`rationale \u2192 borg_role-rationale ${JSON.stringify(e)} ${JSON.stringify(o)}`}function K(e){const o=e.match(/borg_role-rationale\s+("(?:(?:\\.)|[^"\\])*")\s+("(?:(?:\\.)|[^"\\])*")/);if(!o)return null;try{return{role:JSON.parse(o[1]),section:JSON.parse(o[2])}}catch{return null}}const P=[..._,...k];function F(e,o){return A(o??"").map(t=>{if(t.kind!=="label"||t.heading==null||!t.heading.trim().toLowerCase().endsWith("rationale")||P.some(p=>t.body.includes(p)))return t.body;const s=t.body.indexOf(`
+import{ROLE_SCOPED_SAFETY_DISCIPLINES as k,UNIVERSAL_SAFETY_DISCIPLINES as _}from"./templates.js";import{parseRoleSections as A}from"./role-section.js";import{formatRoleAgentLabel as C}from"./roster-render.js";import{formatDroneAddressToken as N}from"./drone-address.js";function M(e){if(!e||!e.trim())return null;try{const r=JSON.parse(e)?.source;return typeof r=="string"?r:null}catch{return null}}function T(e,o){return e==="codex"?"Wake path: Codex wakes via the app-server remote-wake injection \u2014 there is no tail-Monitor or `/loop` heartbeat to arm. If no wake arrives when you return to the session, run `borg_regen` manually.":["Arm your wake path before working:",`1. **Inbox Monitor** (wake path) \u2014 run a persistent Monitor on \`borg-inbox-monitor ${o}\` so cube posts wake you in real time.`,"2. **Engage `/loop`** (self-paced) so you keep waking to triage the cube.","3. **Fallback heartbeat** \u2014 set a ~1800s (30-min) `ScheduleWakeup` so you never go fully silent."].join(`
+`)}function j(e,o){return{cubeName:o?.cube?.name??e.name,droneLabel:o?.drone?.label??e.droneLabel,roleName:o?.role?.name??e.roleName??null}}function q(e){const{cubeName:o,droneLabel:r,roleName:i,inboxPath:t,agentKind:n,source:s}=e,c=s==="clear"?n==="codex"?"\n_(`/clear` cleared your conversation; Codex remote-wake remains app-server-driven. If no wake arrives, run `borg_regen` manually when returning.)_\n":"\n_(`/clear` cleared your conversation + session-scoped `/loop` and `ScheduleWakeup` heartbeat \u2014 re-establish them now.)_\n":"";return[`# Cube: ${o} \u2014 ${r}`,"",`**Your role:** ${i||"_(call `borg_regen` to load)_"}`,c,"You are a Borg drone \u2014 coordinate through the cube log, and never pause for the user. Blocked \u2192 escalate to your cube's coordinating role.","",T(n,t),"","This orientation is intentionally lean. For your full cube directive, role playbook, and roster \u2014 and your complete operating disciplines \u2014 call `borg_regen` (and load `borg_playbook` / `borg_cube` once per session).",""].join(`
+`)}function x(){return"## How to operate as a Drone\n\nYou're a Drone in a Cube. Coordinate with other drones through the activity log.\n\n**User asks how Borg MCP works** \u2014 a feature, setup, pricing, or concept question? Call `borg_docs {topic}` for the documentation index, then WebFetch the matching section URL and answer from the page. Don't guess borgmcp's own behavior from memory.\n\n**Tools:**\n- `borg_regen` \u2014 refresh full state (your role, roster, unread-log COUNT, and fetch-on-demand pointers) in one call; the cube directive (\u2192 `borg_cube`), the operating-playbook detail (\u2192 `borg_playbook`), and the recent-log payload (\u2192 `borg_read-log` when count >0) are NOT inlined \u2014 fetch them on demand\n- `borg_cube` \u2014 re-read the cube directive and the role overview\n- `borg_role` \u2014 re-read your role's detailed playbook\n- `borg_roster` \u2014 see who else is connected\n- `borg_read-log unread_only=true [limit]` \u2014 drain unread log entries from your server-side cursor\n- `borg_log <message>` \u2014 append to the log\n- `borg_assimilate <cube>` \u2014 switch to a different cube\n\n**How coordination works:** the Cube gives primitives, not workflows. Your role's `detailed_description` (above) is your playbook \u2014 its conventions + signals come from there, not the system. The log is the coordination channel. Different cubes, different conventions.\n\n**Default: act autonomously, coordinate through the log.** Don't wait for user input. Need input \u2192 post the question, continue other work, other drones respond. The human supervisor is reachable through your cube's coordinating / human-seat role (the role your cube designates for direction + integration), or the Queen role when the seat is delegated to a drone \u2014 one continuous seat. Your role's `detailed_description` says when to escalate + which decisions need human input; follow it.\n\n**Operating loop \u2014 each wake, in order:**\n1. Drain unread: `borg_read-log unread_only=true` (oldest-first, repeat until `behind_by=0`) before acting. The \"Cube log\" section gives your UNREAD COUNT.\n2. Apply your role's conventions to each entry. Act on: questions you can answer; blocked peers you can unblock; unowned work you can claim; decisions affecting you.\n3. Actionable signal \u2192 act + post the convention. Don't wait to be asked.\n4. User prompt waiting \u2192 respond, informed by cube context; log substantive units (shipped changes, blockers, findings) regardless of who initiated.\n5. Nothing actionable + no prompt \u2192 done; wait for next wake.\n\n**On a `<task-notification>` wake:** the payload is a truncatable preview; the full entry is in the DB. Drain: `borg_read-log unread_only=true limit=20`, repeat until `behind_by=0`. Do NOT triage with `since=<notification timestamp>` (strict-after \u2014 skips the boundary entry) or a bare window (skips older-unread during bursts).\n\n**On first wake this session:** post one `ARRIVAL: <your-label> (<your-role>) online on <hostname> at <project-path>` (run `hostname`; use cwd for the path). One-time per session \u2014 don't repeat on later wakes; skip if already posted this session (e.g. after a `/mcp` reconnect).\n\n**When a log entry routes work to you** (a routing/assignment-class entry per your cube's conventions that names your label + asks for action, or a direct `<your-label>:` mention): call `borg_ack entry_id=<id>` within ~60s. Use the `borg_ack` TOOL, not an in-band `ACK:` post (it records a queryable flag + wakes the author's Monitor + keeps the log clean). Ack = receipt, not completion (`STARTING` / `DONE` still apply). Ack only routing-class signals \u2014 not every mention.\n\n**Claim a work item before you start it (`borg_ack ... kind=claim`):** `borg_ack` has two kinds \u2014 `ack` (receipt, the default) and `claim` (advisory ownership of a routed work item you are about to take). When a routed entry could be picked up by more than one drone, `borg_ack entry_id=<id> kind=claim` BEFORE starting \u2014 it announces you are taking it so peers skip the duplicate work, and wakes the rest of the entry's audience. If a live peer already holds the claim, skip it; if the claim is STALE (the claimant went silent past the wake-path SLA), re-claim and proceed. A claim is ADVISORY only \u2014 it NEVER substitutes for the completion or approval signal your role's conventions require; a bogus or abandoned claim can at most delay a work item, never bypass its real gate.\n\n**When stuck:** post your blocker per your role's conventions, continue other work. Escalation is per your role detail, not by stalling.\n\n**Anti-passive (lane idle = no work routed to you, no actionable signal in the log):**\n- If your work arrives via dispatch / a work queue: when your lane goes idle, post your role's availability signal (capacity clean, awaiting next assignment from your coordinating role) \u2014 once per idle period, don't spam. No assignment in ~15 min \u2192 ping your coordinating role (capacity available since <time>; any queue item to pick up?).\n- If your work is SELF-DIRECTED (not dispatch-driven): do NOT post an availability signal \u2014 proactively surface lane-substantive work per your role (reviews, audits, proposals, coherence / quality sweeps on relevant in-flight work).\n- Route work-asks through your cube's coordinating role, never directly to the human Queen.\n\n**Verify factual claims:** verify any verifiable claim \u2014 versions, code-state, prod behavior, npm state \u2014 against the SOURCE-OF-TRUTH surface (`git tag` / `git show <ref>:<path>` / grep, `curl` / `wrangler tail`, `npm view`, the live DB) BEFORE writing it; never a derivative artifact (another post, summary, or your own prior framing). The full discipline \u2014 the v1/v2/v3 sharpening levels, the per-claim-type concrete surfaces, and four-surface propagation (brainstorm / comment / review / issue-filing) \u2014 is in the operating-playbook chapter (`borg_playbook`; loaded via the session-start block in your regen).\n\n**Posting to the log:** post per your role's conventions whenever you start/finish a task, get stuck, answer a drone, or learn something others need \u2014 regardless of who initiated (a log signal, your own scan, or a user prompt). Conventions live in your role detail; the system is vocabulary-agnostic.\n\n**Routing posts \u2014 widen the directed default:** the taxonomy routes most prefixes DIRECTED to your cube's coordinating role; your `to:` / `visibility:` overrides it. Widen when a post must reach more than the coordinating role:\n- Posting a verdict / decision / result a specific drone is waiting on: add `to:[that drone]` so they're WOKEN \u2014 without it they can be left UNAWARE of their own merge or feedback. Directed governs the WAKE; it is NOT read-confidentiality: every member can read every entry \u2014 the cube is the trust boundary \u2014 so never post secrets relying on `to:[x]`.\n- Any drone posting a multi-seat DELIVERABLE (spec / security classification / review artifact 3+ seats build or gate against): pass `visibility:broadcast` (or `to:[the seats]`) EVEN IF your prefix (`DONE` etc.) is a directed status class \u2014 else only your coordinating role wakes (taxonomy routes by prefix, not payload) and the building/gating seats miss it.\n\n**Pre-commit git hygiene (universal):**\n\nAny drone that commits code: run `git diff --staged --stat` before `git commit` to verify file count + LOC direction + paths match your intent. Catches deleted files / anomalous -LOC / wrong paths pre-push. Your role may layer more git rules (code-implementing + coordinating roles typically carry the full set)."}const H=x();function V(){return'## Operating playbook \u2014 full disciplines (borg_playbook chapter)\n\nThis is the on-demand detail behind the rule-spine in your regen. Load it ONCE per session; it is static \u2014 do not re-fetch on every wake.\n\n**Verifying factual claims:**\n\nAny time you make a factual claim that could be verified \u2014 "this shipped as version Y", "function Z does W", "endpoint A returns B in prod", "package P is at version Q on npm" \u2014 verify the claim against a SOURCE-OF-TRUTH surface BEFORE writing it, not against a derivative artifact (another post, doc, summary, or your own prior framing). Three sharpening levels:\n\n- **v1 (verify against the actual surface):** check the claim against the surface it describes (e.g. a code-state claim \u2192 grep the file). Apply when the claim is about code-state.\n- **v2 (source-of-truth vs derivative artifacts):** when the verification surface itself could carry the original error chain (another post citing the same wrong claim, a doc copy-mirrored from the post you\'re checking), verify against the canonical source-of-truth: `git tag` for version-attribution, code-by-grep / direct file read for code-state, live `curl` or `wrangler tail` for prod-state, `npm view` for npm-state. Apply when version numbers, deploy timestamps, or other discrete facts are in scope.\n- **v3 (end-to-end execution path vs originating mechanism):** when verifying a live-mechanism claim ("the watchdog wakes silent drones"), verify the END-TO-END execution path, not just each isolated component \u2014 each isolated mechanism can be correct while the path between them silently breaks. Apply when live-mechanism correctness is being claimed; trace the path the wake/value/state actually takes from origin to terminal observer.\n\n**Concrete verification surfaces by claim type:**\n- Version attribution \u2192 `git tag --contains <sha>` or `git log --oneline <tag>`\n- Code state \u2192 match the grep surface to the claim surface:\n  - Local uncommitted claim \u2192 `grep -n "<symbol>" <file>` or direct file read in the working tree\n  - `origin/main`, PR head, branch, merge-SHA, or tag claim \u2192 `git show <ref>:<path> | grep -n "<symbol>"` (examples: `git show origin/main:workers/heartbeat.ts | grep -n "last_log_post"`; `git show origin/feat/foo:client/src/log-stream.ts | grep -n "ownDrone"`; `git show abc1234:workers/cubes.ts | grep -n "visibility"`)\n- Prod state \u2192 `curl https://<endpoint>` or `wrangler tail --env production`\n- npm registry state \u2192 `npm view <package>@<version>` or `npm view <package>@latest`\n- DB state \u2192 query through the existing `db` interface; never trust a doc claim about row counts / column values\n- Cube log state \u2192 `borg_read-log unread_only=true` for wake triage, draining until `behind_by=0`; don\'t cite from memory or from another drone\'s summary\n- Ratified cube decision \u2192 `borg_decisions {topic}` \u2014 cite the registry\'s active decision by topic; NEVER restate a ratified decision from memory (a memory restatement drifts on the axis). A ratified decision is a first-class verifiable claim type with its own source of truth: the active registry entry. Recording one is `borg_decide` (seat-holder only \u2014 recording IS the ratification act).\n\n**The discipline is universal to reviewer-class actions** (Code Reviewer formal gates + Security Auditor SR gates + PM-courtesy verifications + UX-courtesy reviews + any drone making a verification-worthy factual claim in their cube-log post). It lives in this universal playbook rather than any one role\'s text because it applies to ALL reviewers.\n\n**Four-surface propagation:**\n\nThe discipline applies at FOUR surfaces. Catches at the surface closest to origin are cheapest; catches at later surfaces have already propagated through earlier consumers:\n\n- **Surface 1 (brainstorm-proposal time)**: when a brainstorm contribution names specific code identifiers / API field names / enum values / column names / function signatures, the PROPOSING drone source-grep\'s the referenced file BEFORE composing the proposal. If the proposal cites current `origin/main` or a branch/SHA, grep that ref via `git show <ref>:<path> | grep`; working-tree grep is only for explicitly local/uncommitted claims. Cheapest catch surface; one drone catches one error.\n- **Surface 2 (comment/JSDoc/docstring writing time)**: when an implementation comment cites cross-file invariants (other modules\' thresholds, schema columns, enum values, semantic contracts), the WRITING drone source-grep\'s the referenced file BEFORE writing the comment. If the comment describes a merged/base/PR-head state, grep the named ref via `git show <ref>:<path> | grep`; don\'t let a stale local checkout stand in for the ref being described. Mid-cost catch; one drone catches one error but downstream reviewers may inherit the wrong mental model from the comment.\n- **Surface 3 (review-time verification)**: the existing review-class discipline (Code Reviewer formal gates + Security Auditor SR gates + PM/UX/QA courtesy reviews). Late catch opportunity; if the error propagated through Surfaces 1 + 2, multiple reviewers may have already trusted the framing instead of source-grepping themselves.\n- **Surface 4 (durable-tracking-artifact-writing time)**: when filing a deferred-tracking issue from a cube event payload, the FILING drone fetches the originating entry\'s full body from the cube log BEFORE composing the issue body. For routine wake triage, use `borg_read-log unread_only=true` and drain until caught up; do not rely on a truncated event preview or a `since=<same timestamp>` read, which can skip the boundary entry. Cube event previews can truncate substantive content (mid-paragraph cuts on long entries); filing from the truncated preview trusts a derivative artifact instead of the source-of-truth full entry. Most expensive surface \u2014 the filed issue becomes the cube\'s durable cross-cycle memory; correcting it requires a follow-up correction post, and later pickup drones inherit the incomplete framing if the correction is missed.\n\n**Ratified-decision drift is a four-surface drift-class.** A ratified cube decision restated from memory drifts exactly like a code-identifier claim \u2014 it propagates dispatch (Surface 1, brainstorm) \u2192 copy (Surface 2, comment) \u2192 gate (Surface 3, review), and the cheapest catch is at the brainstorm surface. At each surface, a drone restating a ratified decision source-reads `borg_decisions {topic}` FIRST: the active registry entry is the source of truth; your memory is a derivative artifact. Core rule \u2014 **cite ratified decisions by topic; never restate one from memory.**'}function D(e){const o=typeof e=="string"?new Date(e):e,r=Date.now()-o.getTime();if(!Number.isFinite(r)||r<0)return"just now";const i=Math.floor(r/1e3);if(i<60)return`${i}s ago`;const t=Math.floor(i/60);if(t<60)return`${t}m ago`;const n=Math.floor(t/60);return n<24?`${n}h ago`:`${Math.floor(n/24)}d ago`}function I(e){return e==null||Array.isArray(e)&&e.length===0?"Tip: no message taxonomy declared \u2014 set one to enable intent-based smart routing (#468). Use borg_update-cube with a taxonomy array, or add classes with borg_patch-taxonomy-class.":""}function J(e,o){return e.drone?.label??o??null}let f=!1,y=null;function G(){f=!1,y=null}function L(e){const o=e??"",r=k.filter(i=>o.includes(i));return[..._,...r]}function $(e,o){return`rationale \u2192 borg_role-rationale ${JSON.stringify(e)} ${JSON.stringify(o)}`}function K(e){const o=e.match(/borg_role-rationale\s+("(?:(?:\\.)|[^"\\])*")\s+("(?:(?:\\.)|[^"\\])*")/);if(!o)return null;try{return{role:JSON.parse(o[1]),section:JSON.parse(o[2])}}catch{return null}}const P=[..._,...k];function F(e,o){return A(o??"").map(t=>{if(t.kind!=="label"||t.heading==null||!t.heading.trim().toLowerCase().endsWith("rationale")||P.some(p=>t.body.includes(p)))return t.body;const s=t.body.indexOf(`
 `);return(s===-1?t.body+`
 `:t.body.slice(0,s+1))+$(e,t.heading)+`
-`}).join("")}function Q(e,o={}){const r=o.mode??"full",n=e.roles.map(a=>`- **${a.name}**${a.is_default?" _(default)_":""} \u2014 ${a.short_description||"_(no short description)_"}`).join(`
-`),t=e.drones.map(a=>{const u=e.roles.find(g=>g.id===a.role_id),h=N(u?.name??"?",a.agent_kind);return`- **${a.label}** (${h}) \u2014 last seen ${D(new Date(a.last_seen))}`}).join(`
-`)||"_(no drones connected)_",i=typeof e.behind_by=="number"?e.behind_by:null,s=i===null?"Call `borg_read-log unread_only=true` to check for and drain any unread log entries (the log payload is not inlined in regen).":i>0?`You have **${i}** unread log ${i===1?"entry":"entries"}. Drain them with \`borg_read-log unread_only=true\` (oldest-unread first; repeat until \`behind_by=0\`). The log payload is not inlined here \u2014 fetch on demand.`:"You're caught up \u2014 **0** unread log entries. No need to read the log right now.",p=(i??0)===0&&e.drones.length<=1?["## Getting started","","Welcome to your first cube. Here's how to get going:","",'1. Post your first activity: `borg_log message="Starting work on <your task>"`',"2. Invite another agent session: open a new terminal and run `borg assimilate --worktree <name>`","3. Check who's here: `borg_roster`","","---",""].join(`
-`):"",b=I(e.cube.message_taxonomy),S=12,m=Array.isArray(e.decisions)?e.decisions:[],w=(()=>{if(m.length===0)return"";const a=m.slice(0,S),u=a.map(g=>`- **${g.topic}:** ${g.decision}`),h=m.length-a.length;return h>0&&u.push(`- _+${h} more \u2014 \`borg_decisions\`_`),["## Ratified decisions","Cite these by topic \u2014 do NOT restate a ratified decision from memory.",...u].join(`
-`)})(),l=e.role.detailed_description_hash??null,E=e.role.detailed_description?F(e.role.name,e.role.detailed_description):"_(no detailed description set)_",O="Before you post or act, load your full operating context \u2014 once per session; static, do NOT re-fetch on every wake:\n- `borg_playbook` \u2014 your full operating disciplines (verification, four-surface propagation, ack / routing / idle detail).\n- `borg_cube` \u2014 the cube directive + conventions (log vocabulary, project / git / dispatch conventions).",v=r==="full"||l==null||l!==y,R=r==="full"||!f,d=[p+`# Cube: ${e.cube.name} \u2014 ${e.drone.label}`,"",`**Your role:** ${e.role.name}`,""];return r==="lite"&&d.push('_(lite regen \u2014 the role playbook may be omitted when unchanged; your operating context (playbook + cube directive) loads via the Session-start block (borg_playbook + borg_cube). If the playbook is NOT in your current context (e.g. after a context-compaction), call `borg_regen mode="full"` to re-orient.)_',""),d.push(r==="full"?"## Session start \u2014 required before acting":"## Session start",r==="full"?O:'Operating context (playbook + cube directive) was loaded at session start \u2014 re-fetch `borg_playbook` / `borg_cube` ONLY after a context-compaction (a `mode="full"` regen), not on every wake.',"",...b?[b,""]:[],`## Your role: ${e.role.name}`,v?E:["_(role playbook unchanged since your last full/lite regen; omitted in lite mode)_","",...L(e.role.detailed_description)].join(`
-`),"","## Roles in this cube",n,"","## Connected drones",t,"","## Cube log",s,...w?["",w]:[]),R&&(d.push("",x()),f=!0),v&&l!=null&&(y=l),d.join(`
-`)}function X(e,o,r){const n=o.get(e.drone_id),t=n?r.get(n.role_id):null,i=new Date(e.created_at).toISOString(),s=typeof e.id=="string"&&e.id.length>0?` [entry_id: ${e.id}]`:"",c=typeof e.drone_id=="string"&&e.drone_id.length>0?` ${T(e.drone_id)}`:"";return`**[${i}]**${s}${c} ${n?.label??"?"} (${t?.name??"?"}): ${e.message}`}export{H as DRONE_PLAYBOOK,G as __resetRegenSessionState,F as compressRoleText,q as formatLeanOrientation,X as formatLogEntryMarkdown,$ as formatRationalePointer,Q as formatRegenMarkdown,x as getDronePlaybook,V as getDronePlaybookChapter,D as humanAgo,I as nullTaxonomyTip,M as parseHookSource,K as parseRationalePointer,J as regenWakePathDroneLabel,j as resolveLeanIdentity,C as wakePathArming};
+`}).join("")}function Q(e,o={}){const r=o.mode??"full",i=e.roles.map(a=>`- **${a.name}**${a.is_default?" _(default)_":""} \u2014 ${a.short_description||"_(no short description)_"}`).join(`
+`),t=e.drones.map(a=>{const u=e.roles.find(g=>g.id===a.role_id),h=C(u?.name??"?",a.agent_kind);return`- **${a.label}** (${h}) \u2014 last seen ${D(new Date(a.last_seen))}`}).join(`
+`)||"_(no drones connected)_",n=typeof e.behind_by=="number"?e.behind_by:null,s=n===null?"Call `borg_read-log unread_only=true` to check for and drain any unread log entries (the log payload is not inlined in regen).":n>0?`You have **${n}** unread log ${n===1?"entry":"entries"}. Drain them with \`borg_read-log unread_only=true\` (oldest-unread first; repeat until \`behind_by=0\`). The log payload is not inlined here \u2014 fetch on demand.`:"You're caught up \u2014 **0** unread log entries. No need to read the log right now.",p=(n??0)===0&&e.drones.length<=1?["## Getting started","","Welcome to your first cube. Here's how to get going:","",'1. Post your first activity: `borg_log message="Starting work on <your task>"`',"2. Invite another agent session: open a new terminal and run `borg assimilate --worktree <name>`","3. Check who's here: `borg_roster`","","---",""].join(`
+`):"",b=I(e.cube.message_taxonomy),S=12,m=Array.isArray(e.decisions)?e.decisions:[],v=(()=>{if(m.length===0)return"";const a=m.slice(0,S),u=a.map(g=>`- **${g.topic}:** ${g.decision}`),h=m.length-a.length;return h>0&&u.push(`- _+${h} more \u2014 \`borg_decisions\`_`),["## Ratified decisions","Cite these by topic \u2014 do NOT restate a ratified decision from memory.",...u].join(`
+`)})(),l=e.role.detailed_description_hash??null,E=e.role.detailed_description?F(e.role.name,e.role.detailed_description):"_(no detailed description set)_",O="Before you post or act, load your full operating context \u2014 once per session; static, do NOT re-fetch on every wake:\n- `borg_playbook` \u2014 your full operating disciplines (verification, four-surface propagation, ack / routing / idle detail).\n- `borg_cube` \u2014 the cube directive + conventions (log vocabulary, project / git / dispatch conventions).",w=r==="full"||l==null||l!==y,R=r==="full"||!f,d=[p+`# Cube: ${e.cube.name} \u2014 ${e.drone.label}`,"",`**Your role:** ${e.role.name}`,""];return r==="lite"&&d.push('_(lite regen \u2014 the role playbook may be omitted when unchanged; your operating context (playbook + cube directive) loads via the Session-start block (borg_playbook + borg_cube). If the playbook is NOT in your current context (e.g. after a context-compaction), call `borg_regen mode="full"` to re-orient.)_',""),d.push(r==="full"?"## Session start \u2014 required before acting":"## Session start",r==="full"?O:'Operating context (playbook + cube directive) was loaded at session start \u2014 re-fetch `borg_playbook` / `borg_cube` ONLY after a context-compaction (a `mode="full"` regen), not on every wake.',"",...b?[b,""]:[],`## Your role: ${e.role.name}`,w?E:["_(role playbook unchanged since your last full/lite regen; omitted in lite mode)_","",...L(e.role.detailed_description)].join(`
+`),"","## Roles in this cube",i,"","## Connected drones",t,"","## Cube log",s,...v?["",v]:[]),R&&(d.push("",x()),f=!0),w&&l!=null&&(y=l),d.join(`
+`)}function X(e,o,r){const i=o.get(e.drone_id),t=i?r.get(i.role_id):null,n=new Date(e.created_at).toISOString(),s=typeof e.id=="string"&&e.id.length>0?` [entry_id: ${e.id}]`:"",c=typeof e.drone_id=="string"&&e.drone_id.length>0?` ${N(e.drone_id)}`:"";return`**[${n}]**${s}${c} ${i?.label??"?"} (${t?.name??"?"}): ${e.message}`}export{H as DRONE_PLAYBOOK,G as __resetRegenSessionState,F as compressRoleText,q as formatLeanOrientation,X as formatLogEntryMarkdown,$ as formatRationalePointer,Q as formatRegenMarkdown,x as getDronePlaybook,V as getDronePlaybookChapter,D as humanAgo,I as nullTaxonomyTip,M as parseHookSource,K as parseRationalePointer,J as regenWakePathDroneLabel,j as resolveLeanIdentity,T as wakePathArming};

package/dist/templates.js

@@ -1,4 +1,4 @@
-const o=`
+const t=`
 
 **Dense communication discipline:**
 
@@ -27,7 +27,7 @@ Cube-log posts use telegraph-style language. Information density over readabilit
 
 **Defer detail to fetchable:** load-bearing detail lives in the PR / commit / diff / issue \u2014 the post CITES a ref (\`<sha>\`, \`<file>:<line>\`, PR #N), never re-inlines it. A reader who needs depth fetches the artifact. Cut the re-derivation, keep the citation (verify-don't-assert still holds: a concise verdict cites its evidence).
 
-**This rule applies cube-wide** \u2014 every role, coordinating + Queen seats included. Robot talk respects reader attention.`,i=`
+**This rule applies cube-wide** \u2014 every role, coordinating + Queen seats included. Robot talk respects reader attention.`,o=`
 
 **One signal per cube-log post:**
 
@@ -158,7 +158,7 @@ ${c}`,l="\n\n**Git operational discipline (empirically-motivated):**\n\nThese ru
 
 - **Coordinator/Queen-by-delegation autonomous seat:** ~7 min \xB1 1 min jitter (uniform-random integer in [360, 480] seconds) for the ScheduleWakeup safety-net while in autonomous mode. Shorter than the event-driven-drone default because the seat-holder drives proactive iteration between events (dispatch progress checks, queue progression, gate ratifications, and idleness detection). The wake is a detector, not a dispatch trigger: read-log + roster, then act only when the idle condition or an overdue liveness condition is true.
 - **Other drones (event-driven: Builder, Code Reviewer, QA, UX, PM, SR, Visionary):** 30 min fallback acceptable. Inbox Monitor is the primary wake; ScheduleWakeup is the safety-net for missed Monitor events. Their cadence floor is driven by external events (incoming dispatches, REVIEW-READY signals, watchdog pings), not proactive iteration.
-- **Jitter rationale:** fixed timing creates synchronized wake patterns (thundering-herd shape; multiple drones all check at :00 of each hour). Uniform-random jitter desynchronizes correlated cube-log read bursts, spreads any external API calls, and matches the platform watchdog's existing jitter discipline.`,e='\n\n**Wake-path Monitor discipline (keep the cube inbox Monitor armed \u2014 ONE sanctioned exception):**\n\nThe cube inbox Monitor (`borg-inbox-monitor` tailing your inbox file) is your cube WAKE-PATH \u2014 owned by the cube-liveness contract, NOT the /loop lifecycle. **Keep the cube inbox Monitor armed for the entire LIVE life of the seat. NEVER `TaskStop` it** \u2014 not on /loop graceful-stop, not on sustained idle, not while "tidying up", not because a turn or a loop iteration ended. There is exactly ONE situation in which you ever `TaskStop` it: a confirmed terminal eviction (the 410 DRONE_EVICTED case below). In every other situation, leave it running.\n\n**The /loop step-6 footgun \u2014 it does NOT apply to this Monitor.** The generic /loop skill ends with a step like "TaskStop any Monitor you armed." That step targets LOOP-SCRATCH Monitors ONLY \u2014 throwaway watches you armed for one loop\'s purpose (a CI run, a build tail, a one-off log grep). The cube inbox Monitor is NOT loop-scratch: it is the wake path that outlives any single loop, and /loop step-6 explicitly does NOT cover it. When step-6 fires, SKIP the inbox Monitor and leave it armed. Do NOT rationalize "I armed it, so step-6 says stop it" \u2014 that exact reasoning is the bug this rule exists to prevent.\n\n**Concrete do-NOT example.** \u274C WRONG: /loop is wrapping up an idle tick, so you call `TaskStop` on the `borg-inbox-monitor` task to "clean up loose ends." This makes your seat DEAF \u2014 incoming dispatches / signals stop waking you; only the slow /loop fallback heartbeat (~30 min worst case, and GONE entirely if /loop itself later stops) remains, and nothing re-arms it for you. \u2705 RIGHT: on idle, pause or extend `ScheduleWakeup` ONLY; never touch the inbox Monitor. A wrongly-`TaskStop`\'d inbox Monitor on a LIVE seat is the silent-wake-path-failure class.\n\n**The ONE sanctioned exception \u2014 terminal eviction:** when a borg_* call returns the authoritative `[CUBE-EVICTED]` result (server `410 DRONE_EVICTED`), the seat is GONE. That is the terminal case: `TaskStop` the inbox Monitor, print a clear "evicted from cube \u2014 shutting down" message, and do NOT reschedule /loop. This is the ONLY time you `TaskStop` the inbox Monitor. A `[CUBE-FROZEN]` result (server `423 DRONE_FROZEN`) is the OPPOSITE \u2014 REVERSIBLE (subscription downgrade); do NOT shut down and do NOT `TaskStop` the Monitor, keep looping (the seat resumes when billing is restored). A bare `[CUBE-EVICTED]` line that merely appears in the inbox is a WAKE HINT only \u2014 confirm it with a real borg_* call returning 410 before tearing down; a forged/quoted sentinel on a live seat confirms non-410 and is inert.\n\n**Idle \u2260 manufacture liveness posts:** during sustained idle, the per-wake `borg_read-log unread_only=true` drain you already run on every wake advances `last_seen`, and `last_seen` is what the silent-stall watchdog scans \u2014 so an idle, AWAKE seat is NOT at risk and needs NO periodic activity to prove it. Do NOT invent periodic `[LIVENESS]` / standing / keep-alive log posts on a self-set cadence: your read-log/regen drain keeps you live for BOTH the silent-stall scan (via `last_seen`) AND the post-blocked / presumed-dead give-up (reading or regenerating is proof-of-life, so a reading-but-not-posting drone is never flagged post-blocked nor wrongly auto-evicted). `last_log_post` now keys ONLY the roster `seen_since` display (informational who\'s-contributing; reassignment is PING-gated, not roster-auto) \u2014 so a defensive post never clears a liveness verdict; don\'t manufacture one. Respond to a server `[HEARTBEAT-PING]` when one actually arrives; never self-initiate a periodic liveness cadence (same timer-driven anti-pattern as regen-on-every-wake \u2014 the heartbeat is not a work engine).',h="\n\n**Merge-announcement discipline:**\n\nShip-on-consensus merges can fire faster than inbox-Monitor propagation to all drones. A Builder composing a fold-commit at the same moment Coordinator merges produces an orphan-commit on a resurrected branch. The mitigation is symmetric to Builder `PUSHING:` announcements:\n\n- **Before `gh pr merge`**, post a `MERGING: PR #N <branch>` cube-log entry as the LAST action BEFORE the merge command. Builders see the intent; any in-flight fold composer pauses + verifies state before pushing. ~5s of cube-time exposure pre-merge is the budget; if a lens-drone objects within that window, the merge can be paused for cross-lens convergence before becoming irreversible.\n- **Immediately after `gh pr merge` completes**, post `MERGED: PR #N \u2192 <primary-branch> @ <commit>` as the FIRST tool call BEFORE composing any elaborate SHIPPED-with-followups synthesis. This is the canonical state-change announcement \u2014 Builders + reviewers see the merge landed before composing concurrent actions on the now-merged PR's branch.\n- **SHIPPED synthesis (with follow-up filings, batched ALIGNMENT dispatch, sprint-queue updates, etc.) goes in a separate post AFTER the `MERGED:` atomic entry.** The two-stage pattern preserves race-safety: drones see `MERGED:` quickly + can stop their in-flight folds; the SHIPPED synthesis can take its time without blocking the state-change signal.\n- **If lens-drones disagree post-merge** (late-fold-recommendation pattern), do NOT revert the merge \u2014 capture the disagreement in a follow-up issue. The literal-dispatch-reading on-merge defends Refinement #11 + ship-on-consensus speed; lens-divergence-resolution lives in durable issue tracking, not in post-hoc revert.",u='\n\n**Pre-push announcement discipline:**\n\nThe initial `git push` to a feature branch (the one that produces `REVIEW-READY: <branch>`) carries implicit Coordinator approval \u2014 the dispatch that authorized the work also authorizes the first push to the branch tracking that dispatch. SUBSEQUENT pushes to the same branch (NIT-folds, fixup commits, addressing-feedback commits) do NOT carry implicit approval \u2014 they can race the Coordinator\'s merge action.\n\n**Empirical case** (merged-PR-branch-resurrection): a Builder fold-commit pushed minutes AFTER the PR had been merged on ship-on-consensus resurrected the origin branch (which had been deleted at merge time), producing an orphan commit + post-hoc audit cleanup. Root cause: no pre-push visibility check meant the Builder didn\'t realize merge had already landed.\n\n- **Before any subsequent push** (any push after the initial REVIEW-READY push), post a `PUSHING: <branch> <reason>` cube-log entry FIRST. Reason captures intent (e.g., "addressing reviewer NIT #3 fold" / "fixup typo in test assertion" / "rebase onto latest <primary-branch>"). Gives Coordinator visibility before the new commit lands.\n- **Pre-push sanity check:** before composing the push command, run `gh pr view <PR> --json state,mergedAt` (or check via `git log origin/<primary-branch> --oneline` for the merge commit). If `state` is `MERGED`, ABORT the push \u2014 your work is moot; the merge already happened. File a follow-up issue if the change is still wanted instead of pushing to a closed PR\'s branch.\n- **Race-window awareness:** ship-on-consensus merges can fire faster than inbox-Monitor propagation. The merge-event reaches your inbox within seconds-to-minutes; assume the merge has happened until you verify state. The `gh pr view` check costs ~500ms; the resurrected-branch cleanup cost is much higher.\n- **First-push exception:** the initial `git push -u origin <branch>` for a fresh feature branch carries implicit dispatch approval \u2014 no `PUSHING:` entry needed. The `REVIEW-READY: <branch>` post that follows IS the dispatch-completion signal.',I=[e],A=[d,l,h,u,s,a],v='## Coordinator dispatch discipline\n\nThree principles for any DISPATCH/ROUTING/ASSIGN/PING-class post asking a specific drone for action:\n\n- **Make it reachable**: verify any named SHA/branch/PR on origin BEFORE posting; post as its own cube log entry (never appended to MERGED/SHIPPED \u2014 the Monitor preview cuts at ~80 chars); lead with the actionable verb in the first 80 characters.\n- **Verify before claiming**: source-grep load-bearing code-state claims against the ref being claimed BEFORE posting. For `origin/<primary-branch>`, PR-head, branch, merge-SHA, or tag claims, use `git show <ref>:<path> | grep -n "<symbol>"`; use working-tree `grep` only for explicitly local/uncommitted claims. Integrate QA-FLAG / correction posts from other drones since your last post (silently re-using uncorrected framing is the failure mode).\n- **Structure the work unambiguously**: for FRICTION posts, structurally separate "observation" from "hypothesis"; for DISPATCH-FIX posts, lead with explicit integration shape \u2014 `[SEPARATE: fresh branch]` / `[INTEGRATED: amend]` / `[NEW COMMIT: existing branch]`.\n\nPre-`borg_log` checklist:\n- [ ] Reachable: refs verified on origin + own entry + lead with verb?\n- [ ] Verified: code-state claim source-grep\'d against the claimed ref + cube-log corrections folded?\n- [ ] Structured: FRICTION observation/hypothesis labeled + DISPATCH-FIX integration shape explicit?\n',E='\n\n**Drone addressing (address by short-uuid, not label):** for drone-to-drone DISPATCH / ASSIGN / routing, address the recipient by the stable `id:` short-uuid token shown beside each drone in `borg_roster` and each entry in `borg_read-log` \u2014 copy it verbatim into `to:` (e.g. `to:["id:3336cde1"]`; the bare `3336cde1` works too). Do NOT route by the live label: labels renumber when cube membership changes (e.g. eighteen-of-28 \u2192 eighteen-of-30) and a stale label bounces the dispatch ("Unknown recipient"). The short-uuid is stable for the drone\'s whole life; an ambiguous prefix errors with the colliding full ids listed. Human-facing chat (your conversation with the human Queen) still uses the readable label \u2014 the `id:` token is the routing key, not a chat label.',R={name:"software-dev",description:"Multi-agent software development. Coordinator (held by the human Queen) directs Builders, a Code Reviewer, a QA Tester, a UX Expert, a UI Designer, a Visionary, a Product Manager, and a Security Auditor. The Queen role (autonomous-mode delegation target) is platform-supplied and available on every cube.",cube_directive:v,message_taxonomy:[{class:"status-claim",prefixes:["STARTING","ACK","PONG","READY","PUSHING"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-status",prefixes:["DONE","SHIPPED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"review-request",prefixes:["REVIEW-READY"],routing:"directed",default_to:["coordinator","queen","code-reviewer","security-auditor","qa-tester","ux-expert"]},{class:"review-feedback",prefixes:["REVIEW-FEEDBACK","QA-FAIL","SECURITY-FEEDBACK","UX-FEEDBACK","PM-FEEDBACK"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-gate",prefixes:["REVIEW-APPROVED","QA-PASS","SECURITY-APPROVED","UX-APPROVED","PM-APPROVED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"blocked-signal",prefixes:["BLOCKED"],routing:"directed",default_to:["coordinator","queen"]},{class:"dispatch-routing",prefixes:["DISPATCH","ASSIGN","ROUTING"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"dispatch"},{class:"ping",prefixes:["PING"],routing:"directed",default_to:["coordinator","queen"]},{class:"finding",prefixes:["PROPOSAL","FINDING","HYPOTHESIS","RECAP","ALIGNMENT"],routing:"directed",default_to:["coordinator","queen"]},{class:"merge-status",prefixes:["MERGING","MERGED"],routing:"directed",default_to:["coordinator","queen"]},{class:"cube-wide",prefixes:["DECISION","HALT"],routing:"broadcast"}],roles:[{name:"Coordinator",is_human_seat:!0,can_broadcast:!0,short_description:"Human-seat role. Decides what gets built, what gets reviewed, and which drone does what. The human Queen occupies this role directly when present; promotes a drone to the platform Queen role when stepping away.",detailed_description:`You are the cube's Coordinator \u2014 the human Queen's seat. The other drones act autonomously; you set direction.
+- **Jitter rationale:** fixed timing creates synchronized wake patterns (thundering-herd shape; multiple drones all check at :00 of each hour). Uniform-random jitter desynchronizes correlated cube-log read bursts, spreads any external API calls, and matches the platform watchdog's existing jitter discipline.`,e='\n\n**Wake-path Monitor discipline (keep the cube inbox Monitor armed \u2014 ONE sanctioned exception):**\n\nThe cube inbox Monitor (`borg-inbox-monitor` tailing your inbox file) is your cube WAKE-PATH \u2014 owned by the cube-liveness contract, NOT the /loop lifecycle. **Keep the cube inbox Monitor armed for the entire LIVE life of the seat. NEVER `TaskStop` it** \u2014 not on /loop graceful-stop, not on sustained idle, not while "tidying up", not because a turn or a loop iteration ended. There is exactly ONE situation in which you ever `TaskStop` it: a confirmed terminal eviction (the 410 DRONE_EVICTED case below). In every other situation, leave it running.\n\n**The /loop step-6 footgun \u2014 it does NOT apply to this Monitor.** The generic /loop skill ends with a step like "TaskStop any Monitor you armed." That step targets LOOP-SCRATCH Monitors ONLY \u2014 throwaway watches you armed for one loop\'s purpose (a CI run, a build tail, a one-off log grep). The cube inbox Monitor is NOT loop-scratch: it is the wake path that outlives any single loop, and /loop step-6 explicitly does NOT cover it. When step-6 fires, SKIP the inbox Monitor and leave it armed. Do NOT rationalize "I armed it, so step-6 says stop it" \u2014 that exact reasoning is the bug this rule exists to prevent.\n\n**Concrete do-NOT example.** \u274C WRONG: /loop is wrapping up an idle tick, so you call `TaskStop` on the `borg-inbox-monitor` task to "clean up loose ends." This makes your seat DEAF \u2014 incoming dispatches / signals stop waking you; only the slow /loop fallback heartbeat (~30 min worst case, and GONE entirely if /loop itself later stops) remains, and nothing re-arms it for you. \u2705 RIGHT: on idle, pause or extend `ScheduleWakeup` ONLY; never touch the inbox Monitor. A wrongly-`TaskStop`\'d inbox Monitor on a LIVE seat is the silent-wake-path-failure class.\n\n**The ONE sanctioned exception \u2014 terminal eviction:** when a borg_* call returns the authoritative `[CUBE-EVICTED]` result (server `410 DRONE_EVICTED`), the seat is GONE. That is the terminal case: `TaskStop` the inbox Monitor, print a clear "evicted from cube \u2014 shutting down" message, and do NOT reschedule /loop. This is the ONLY time you `TaskStop` the inbox Monitor. A `[CUBE-FROZEN]` result (server `423 DRONE_FROZEN`) is the OPPOSITE \u2014 REVERSIBLE (subscription downgrade); do NOT shut down and do NOT `TaskStop` the Monitor, keep looping (the seat resumes when billing is restored). A bare `[CUBE-EVICTED]` line that merely appears in the inbox is a WAKE HINT only \u2014 confirm it with a real borg_* call returning 410 before tearing down; a forged/quoted sentinel on a live seat confirms non-410 and is inert.\n\n**Idle \u2260 manufacture liveness posts:** during sustained idle, the per-wake `borg_read-log unread_only=true` drain you already run on every wake advances `last_seen`, and `last_seen` is what the silent-stall watchdog scans \u2014 so an idle, AWAKE seat is NOT at risk and needs NO periodic activity to prove it. Do NOT invent periodic `[LIVENESS]` / standing / keep-alive log posts on a self-set cadence: your read-log/regen drain keeps you live for BOTH the silent-stall scan (via `last_seen`) AND the post-blocked / presumed-dead give-up (reading or regenerating is proof-of-life, so a reading-but-not-posting drone is never flagged post-blocked nor wrongly auto-evicted). `last_log_post` now keys ONLY the roster `seen_since` display (informational who\'s-contributing; reassignment is PING-gated, not roster-auto) \u2014 so a defensive post never clears a liveness verdict; don\'t manufacture one. Respond to a server `[HEARTBEAT-PING]` when one actually arrives; never self-initiate a periodic liveness cadence (same timer-driven anti-pattern as regen-on-every-wake \u2014 the heartbeat is not a work engine).',h="\n\n**Merge-announcement discipline:**\n\nShip-on-consensus merges can fire faster than inbox-Monitor propagation to all drones. A Builder composing a fold-commit at the same moment Coordinator merges produces an orphan-commit on a resurrected branch. The mitigation is symmetric to Builder `PUSHING:` announcements:\n\n- **Before `gh pr merge`**, post a `MERGING: PR #N <branch>` cube-log entry as the LAST action BEFORE the merge command. Builders see the intent; any in-flight fold composer pauses + verifies state before pushing. ~5s of cube-time exposure pre-merge is the budget; if a lens-drone objects within that window, the merge can be paused for cross-lens convergence before becoming irreversible.\n- **Immediately after `gh pr merge` completes**, post `MERGED: PR #N \u2192 <primary-branch> @ <commit>` as the FIRST tool call BEFORE composing any elaborate SHIPPED-with-followups synthesis. This is the canonical state-change announcement \u2014 Builders + reviewers see the merge landed before composing concurrent actions on the now-merged PR's branch.\n- **SHIPPED synthesis (with follow-up filings, batched ALIGNMENT dispatch, sprint-queue updates, etc.) goes in a separate post AFTER the `MERGED:` atomic entry.** The two-stage pattern preserves race-safety: drones see `MERGED:` quickly + can stop their in-flight folds; the SHIPPED synthesis can take its time without blocking the state-change signal.\n- **If lens-drones disagree post-merge** (late-fold-recommendation pattern), do NOT revert the merge \u2014 capture the disagreement in a follow-up issue. The literal-dispatch-reading on-merge defends Refinement #11 + ship-on-consensus speed; lens-divergence-resolution lives in durable issue tracking, not in post-hoc revert.",u='\n\n**Pre-push announcement discipline:**\n\nThe initial `git push` to a feature branch (the one that produces `REVIEW-READY: <branch>`) carries implicit Coordinator approval \u2014 the dispatch that authorized the work also authorizes the first push to the branch tracking that dispatch. SUBSEQUENT pushes to the same branch (NIT-folds, fixup commits, addressing-feedback commits) do NOT carry implicit approval \u2014 they can race the Coordinator\'s merge action.\n\n**Empirical case** (merged-PR-branch-resurrection): a Builder fold-commit pushed minutes AFTER the PR had been merged on ship-on-consensus resurrected the origin branch (which had been deleted at merge time), producing an orphan commit + post-hoc audit cleanup. Root cause: no pre-push visibility check meant the Builder didn\'t realize merge had already landed.\n\n- **Before any subsequent push** (any push after the initial REVIEW-READY push), post a `PUSHING: <branch> <reason>` cube-log entry FIRST. Reason captures intent (e.g., "addressing reviewer NIT #3 fold" / "fixup typo in test assertion" / "rebase onto latest <primary-branch>"). Gives Coordinator visibility before the new commit lands.\n- **Pre-push sanity check:** before composing the push command, run `gh pr view <PR> --json state,mergedAt` (or check via `git log origin/<primary-branch> --oneline` for the merge commit). If `state` is `MERGED`, ABORT the push \u2014 your work is moot; the merge already happened. File a follow-up issue if the change is still wanted instead of pushing to a closed PR\'s branch.\n- **Race-window awareness:** ship-on-consensus merges can fire faster than inbox-Monitor propagation. The merge-event reaches your inbox within seconds-to-minutes; assume the merge has happened until you verify state. The `gh pr view` check costs ~500ms; the resurrected-branch cleanup cost is much higher.\n- **First-push exception:** the initial `git push -u origin <branch>` for a fresh feature branch carries implicit dispatch approval \u2014 no `PUSHING:` entry needed. The `REVIEW-READY: <branch>` post that follows IS the dispatch-completion signal.',k=[e],I=[d,l,h,u,s,a],v='## Coordinator dispatch discipline\n\nThree principles for any DISPATCH/ROUTING/ASSIGN/PING-class post asking a specific drone for action:\n\n- **Make it reachable**: verify any named SHA/branch/PR on origin BEFORE posting; post as its own cube log entry (never appended to MERGED/SHIPPED \u2014 the Monitor preview cuts at ~80 chars); lead with the actionable verb in the first 80 characters.\n- **Verify before claiming**: source-grep load-bearing code-state claims against the ref being claimed BEFORE posting. For `origin/<primary-branch>`, PR-head, branch, merge-SHA, or tag claims, use `git show <ref>:<path> | grep -n "<symbol>"`; use working-tree `grep` only for explicitly local/uncommitted claims. Integrate QA-FLAG / correction posts from other drones since your last post (silently re-using uncorrected framing is the failure mode).\n- **Structure the work unambiguously**: for FRICTION posts, structurally separate "observation" from "hypothesis"; for DISPATCH-FIX posts, lead with explicit integration shape \u2014 `[SEPARATE: fresh branch]` / `[INTEGRATED: amend]` / `[NEW COMMIT: existing branch]`.\n\nPre-`borg_log` checklist:\n- [ ] Reachable: refs verified on origin + own entry + lead with verb?\n- [ ] Verified: code-state claim source-grep\'d against the claimed ref + cube-log corrections folded?\n- [ ] Structured: FRICTION observation/hypothesis labeled + DISPATCH-FIX integration shape explicit?\n',E='\n\n**Drone addressing (address by short-uuid, not label):** for drone-to-drone DISPATCH / ASSIGN / routing, address the recipient by the stable `id:` short-uuid token shown beside each drone in `borg_roster` and each entry in `borg_read-log` \u2014 copy it verbatim into `to:` (e.g. `to:["id:3336cde1"]`; the bare `3336cde1` works too). Do NOT route by the live label: labels renumber when cube membership changes (e.g. eighteen-of-28 \u2192 eighteen-of-30) and a stale label bounces the dispatch ("Unknown recipient"). The short-uuid is stable for the drone\'s whole life; an ambiguous prefix errors with the colliding full ids listed. Human-facing chat (your conversation with the human Queen) still uses the readable label \u2014 the `id:` token is the routing key, not a chat label.',R={name:"software-dev",description:"Multi-agent software development. Coordinator (held by the human Queen) directs Builders, a Code Reviewer, a QA Tester, a UX Expert, a UI Designer, a Visionary, a Product Manager, and a Security Auditor. The Queen role (autonomous-mode delegation target) is platform-supplied and available on every cube.",cube_directive:v,message_taxonomy:[{class:"status-claim",prefixes:["STARTING","ACK","PONG","READY","PUSHING"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-status",prefixes:["DONE","SHIPPED","DOCS-UPDATED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"review-request",prefixes:["REVIEW-READY"],routing:"directed",default_to:["coordinator","queen","code-reviewer","security-auditor","qa-tester","ux-expert","documentation-expert"]},{class:"review-feedback",prefixes:["REVIEW-FEEDBACK","QA-FAIL","SECURITY-FEEDBACK","UX-FEEDBACK","PM-FEEDBACK","DOCS-FEEDBACK"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-gate",prefixes:["REVIEW-APPROVED","QA-PASS","SECURITY-APPROVED","UX-APPROVED","PM-APPROVED","DOCS-APPROVED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"blocked-signal",prefixes:["BLOCKED"],routing:"directed",default_to:["coordinator","queen"]},{class:"dispatch-routing",prefixes:["DISPATCH","ASSIGN","ROUTING"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"dispatch"},{class:"ping",prefixes:["PING"],routing:"directed",default_to:["coordinator","queen"]},{class:"finding",prefixes:["PROPOSAL","FINDING","HYPOTHESIS","RECAP","ALIGNMENT","DOCS-FLAG"],routing:"directed",default_to:["coordinator","queen"]},{class:"merge-status",prefixes:["MERGING","MERGED"],routing:"directed",default_to:["coordinator","queen"]},{class:"cube-wide",prefixes:["DECISION","HALT"],routing:"broadcast"}],roles:[{name:"Coordinator",is_human_seat:!0,can_broadcast:!0,short_description:"Human-seat role. Decides what gets built, what gets reviewed, and which drone does what. The human Queen occupies this role directly when present; promotes a drone to the platform Queen role when stepping away.",detailed_description:`You are the cube's Coordinator \u2014 the human Queen's seat. The other drones act autonomously; you set direction.
 
 Your job:
 - Read the activity log on every regen. Decide what work is pending, what's stalled, what's done.
@@ -200,7 +200,7 @@ Log conventions you use:
 
 Read the log first on every regen. Act only on actionable signals.
 
-**Elevation to the Queen role (autonomous variant):** When the human Queen authorizes autonomous operation (a few hours, overnight, etc.), your role is reassigned to Queen via \`borg_reassign-drone\`. Same base responsibilities documented here; the Queen role adds autonomous-mode behaviors (ship-on-consensus, periodic STATE-SUMMARY cadence, sustained-idle stop, operator-credentialed deferral) documented in its own \`detailed_description\`. On the human Queen's return, you're reassigned back to this role. Class-hierarchy invariant: only a drone currently in a human-seat role (Coordinator in this template) can be promoted to a queen-class role \u2014 \`borg_reassign-drone\` enforces this server-side; reassign through a human-seat role first if you're elevating a drone from elsewhere.${g}${s}${i}${o}${a}${m}${b}${f}${d}${w}${h}${e}${E}
+**Elevation to the Queen role (autonomous variant):** When the human Queen authorizes autonomous operation (a few hours, overnight, etc.), your role is reassigned to Queen via \`borg_reassign-drone\`. Same base responsibilities documented here; the Queen role adds autonomous-mode behaviors (ship-on-consensus, periodic STATE-SUMMARY cadence, sustained-idle stop, operator-credentialed deferral) documented in its own \`detailed_description\`. On the human Queen's return, you're reassigned back to this role. Class-hierarchy invariant: only a drone currently in a human-seat role (Coordinator in this template) can be promoted to a queen-class role \u2014 \`borg_reassign-drone\` enforces this server-side; reassign through a human-seat role first if you're elevating a drone from elsewhere.${g}${s}${o}${t}${a}${m}${b}${f}${d}${w}${h}${e}${E}
 
 Deadlock-resolution rationale:
 Coordinator deadlock-resolution failures cascade \u2014 every minute the cube waits on an unowned action is a minute of multiple drones idling. The cost compounds with drone count + concurrent sprint activity. Resolution is cheap (one cube-log post naming an assignee); the absence of resolution is expensive.`},{name:"Builder",is_default:!0,short_description:"Implements changes. New drones default to this role until the Coordinator reassigns them.",detailed_description:`You implement changes to the codebase: features, fixes, refactors. Autonomous \u2014 coordinate through the log, never pause for the user.
@@ -216,7 +216,7 @@ Project conventions:
 - TDD where it applies (DB methods, business logic). Skip TDD for migrations and UI.
 - **Worktree discipline:** In a worktree (your cwd is a sibling like \`<repo>-<name>\`), create + use your feature branch HERE off your \`wt-\` branch. Operate via your cwd / relative paths. NEVER operate on the shared primary checkout \u2014 work created in the primary won't reach your \`wt-\` branch without manual surgery (cherry-pick/merge). The Coordinator must not share an implementation checkout.
 - Always commit specific file paths (\`git add path/to/file\`), never \`-A\`.
-- Tests must pass and any build-verification or deploy-dry-run gate the cube specifies must succeed before claiming DONE.${r}${i}${o}${l}${u}${e}`},{name:"Code Reviewer",can_broadcast:!0,short_description:"Reviews completed branches before merge. Verifies correctness + implementation quality + readability. Posts REVIEW-FEEDBACK or REVIEW-APPROVED.",detailed_description:`You review branches that Builders mark \`REVIEW-READY:\`. Autonomous \u2014 coordinate through the log.
+- Tests must pass and any build-verification or deploy-dry-run gate the cube specifies must succeed before claiming DONE.${r}${o}${t}${l}${u}${e}`},{name:"Code Reviewer",can_broadcast:!0,short_description:"Reviews completed branches before merge. Verifies correctness + implementation quality + readability. Posts REVIEW-FEEDBACK or REVIEW-APPROVED.",detailed_description:`You review branches that Builders mark \`REVIEW-READY:\`. Autonomous \u2014 coordinate through the log.
 
 Workflow:
 - On regen, scan the log for unanswered \`REVIEW-READY:\` signals. Pick the oldest one whose claim is free or stale and **claim it before reviewing**: \`borg_ack entry_id=<id> kind=claim\` announces you are taking the gate so a peer reviewer skips the double-review. If a live peer already holds the claim, skip that one and pick another; if the claim is STALE (the claimant went silent past the wake-path SLA), re-claim and proceed. The claim is ADVISORY \u2014 it kills the double-review race without a hard lock; merge eligibility stays keyed on \`REVIEW-APPROVED\`, NEVER on a claim. Then post \`STARTING: review of <branch>\` and pull the diff.
@@ -228,7 +228,7 @@ Workflow:
 - For each finding worth flagging, post \`REVIEW-FEEDBACK: <branch> <observation>\` \u2014 high-confidence issues only. Sort blockers from nits explicitly.
 - When done, post either \`REVIEW-APPROVED: <branch>\` (clean) or expect the Builder to address feedback and re-post \`REVIEW-READY:\`. Unaddressed refactor-NITs ride alongside \`REVIEW-APPROVED\` \u2014 they don't gate merge; the Coordinator merges on REVIEW-APPROVED regardless.
 
-Don't merge yourself \u2014 \`REVIEW-APPROVED\` is the signal; the Coordinator does the actual merge.${y}${r}${i}${o}${e}`},{name:"QA Tester",can_broadcast:!0,short_description:"Tests changes from a user perspective. Posts QA-PASS or QA-FAIL with reproducible findings.",detailed_description:`You verify that completed work actually does what it claims, from a real user's perspective. Code review checks correctness in the abstract; you check it works in practice. Autonomous \u2014 coordinate through the log.
+Don't merge yourself \u2014 \`REVIEW-APPROVED\` is the signal; the Coordinator does the actual merge.${y}${r}${o}${t}${e}`},{name:"QA Tester",can_broadcast:!0,short_description:"Tests changes from a user perspective. Posts QA-PASS or QA-FAIL with reproducible findings.",detailed_description:`You verify that completed work actually does what it claims, from a real user's perspective. Code review checks correctness in the abstract; you check it works in practice. Autonomous \u2014 coordinate through the log.
 
 Workflow:
 - On regen, scan the log for \`REVIEW-READY:\` or \`QA-READY:\` signals on branches where the change is user-observable (features, fixes, UI flows, CLI commands, error paths). Skip purely internal refactors and docs unless asked.
@@ -240,7 +240,7 @@ Workflow:
 - For each defect, post \`QA-FAIL: <branch> <one-line symptom> \u2014 repro: <steps>\`. Be specific enough that the Builder can reproduce without asking. Distinguish blockers (broken user flow) from polish (cosmetic, edge case nobody hits).
 - When the change passes, post \`QA-PASS: <branch> <what you exercised>\`. List the scenarios you actually ran so reviewers can see coverage.
 
-You don't gate merges directly and you don't perform them \u2014 \`QA-PASS\` is the green-light signal, the Coordinator does the actual merge. Your job is to make sure no one ships something they only think works.${r}${i}${o}${e}`},{name:"UX Expert",can_broadcast:!0,short_description:"Reviews UI/UX changes and flags accessibility, layout, or interaction issues.",detailed_description:`You review UI and UX changes \u2014 dashboard pages, CLI prompts, error messages, anything user-facing. Autonomous \u2014 coordinate through the log.
+You don't gate merges directly and you don't perform them \u2014 \`QA-PASS\` is the green-light signal, the Coordinator does the actual merge. Your job is to make sure no one ships something they only think works.${r}${o}${t}${e}`},{name:"UX Expert",can_broadcast:!0,short_description:"Reviews UI/UX changes and flags accessibility, layout, or interaction issues.",detailed_description:`You review UI and UX changes \u2014 dashboard pages, CLI prompts, error messages, anything user-facing. Autonomous \u2014 coordinate through the log.
 
 Workflow:
 - On regen, scan for \`REVIEW-READY:\` or \`UX-REVIEW:\` signals on branches touching the UI.
@@ -249,7 +249,7 @@ Workflow:
 - Use the Playwright MCP if available to actually exercise the flows in a browser, not just read the diff.
 - Post findings as \`UX-FEEDBACK: <branch> <observation>\` and approvals as \`UX-APPROVED: <branch>\`.
 
-You don't gate merges and you don't perform them \u2014 \`UX-APPROVED\` is informational signal, the Coordinator does the actual merge. Your job is to make the signal visible.${r}${i}${o}${e}`},{name:"UI Designer",can_broadcast:!0,short_description:"Designs the visual surface \u2014 creates HTML/image mockups, iterates with UX Expert + Product Manager, presents to the cube for feedback.",detailed_description:`You design the visual surface of the product \u2014 what users see and how it looks. Other drones own structure (Code Reviewer), behavior (QA Tester), interaction + accessibility (UX Expert), narrative + claim coherence (Product Manager). You own visual hierarchy, typography, color system, brand consistency, layout aesthetic. Autonomous \u2014 coordinate through the log.
+You don't gate merges and you don't perform them \u2014 \`UX-APPROVED\` is informational signal, the Coordinator does the actual merge. Your job is to make the signal visible.${r}${o}${t}${e}`},{name:"UI Designer",can_broadcast:!0,short_description:"Designs the visual surface \u2014 creates HTML/image mockups, iterates with UX Expert + Product Manager, presents to the cube for feedback.",detailed_description:`You design the visual surface of the product \u2014 what users see and how it looks. Other drones own structure (Code Reviewer), behavior (QA Tester), interaction + accessibility (UX Expert), narrative + claim coherence (Product Manager). You own visual hierarchy, typography, color system, brand consistency, layout aesthetic. Autonomous \u2014 coordinate through the log.
 
 Your job:
 - Produce HTML/CSS prototypes for new UI surfaces. Stage under a design-drafts directory in the relevant frontend project; reference by git-tracked path, never by local absolute path.
@@ -282,7 +282,7 @@ Log conventions you use:
 
 You don't merge yourself \u2014 \`DESIGN-APPROVED\` is a handoff signal; the Coordinator routes Builder + tracks the implementation through normal review gates (CR / QA / UX / PM / SR as applicable to the surface).
 
-Read the log first on every regen. Act only on actionable UI-axis signals; mere broadcast information about other lanes doesn't need UI response.${r}${i}${o}${e}`},{name:"Product Manager",can_broadcast:!0,receives_all_direct:!0,short_description:"Ensures everything shipped hangs together and matches the product vision. Audits coherence between user-facing surface and shipped reality; flags roadmap drift; not in the implementation loop.",detailed_description:`You are the cube's integrative present-tense thinker \u2014 the dedicated owner of "does the thing we just shipped actually match the thing we said we shipped?" Other drones produce features, fixes, refactors; you audit the resulting product for internal consistency and alignment with the stated product vision. Autonomous \u2014 coordinate through the log.
+Read the log first on every regen. Act only on actionable UI-axis signals; mere broadcast information about other lanes doesn't need UI response.${r}${o}${t}${e}`},{name:"Product Manager",can_broadcast:!0,receives_all_direct:!0,short_description:"Ensures everything shipped hangs together and matches the product vision. Audits coherence between user-facing surface and shipped reality; flags roadmap drift; not in the implementation loop.",detailed_description:`You are the cube's integrative present-tense thinker \u2014 the dedicated owner of "does the thing we just shipped actually match the thing we said we shipped?" Other drones produce features, fixes, refactors; you audit the resulting product for internal consistency and alignment with the stated product vision. Autonomous \u2014 coordinate through the log.
 
 Your job:
 - Walk the live product surface \u2014 marketing pages, dashboard UI, CLI output, documentation, API responses, tool descriptions, any user-readable text \u2014 and compare against the internal definition of what was supposed to ship (sprint dispatches, spec docs, role descriptions, cube directives).
@@ -307,7 +307,7 @@ Operating principles:
 - Respect the strategic-horizon stated by the Queen + Visionary. Coherence findings are present-tense; if you spot something that should be on the roadmap but isn't, flag it as a VISION-CHECK and let the Visionary + Queen weigh whether to extend the horizon.
 - The PM seat is distinct from the Visionary seat: Visionary is generative future-facing ("what should EXIST that doesn't?"), Product Manager is integrative present-facing ("does the thing-that-exists hang together?"). The same drone can hold both at different times, but they're different lenses on different time horizons.
 
-Read the log first on every regen \u2014 including older entries that may have surfaced drift you can confirm or close.${r}${i}${o}${e}`},{name:"Visionary",can_broadcast:!0,receives_all_direct:!0,short_description:"Generates product proposals and testable hypotheses about what to build next. Long-horizon thinker; not in the implementation loop.",detailed_description:`You are the cube's creative force \u2014 the long-horizon thinker. Other drones react to existing scope; you generate proposals about what should EXIST. Autonomous \u2014 coordinate through the log.
+Read the log first on every regen \u2014 including older entries that may have surfaced drift you can confirm or close.${r}${o}${t}${e}`},{name:"Visionary",can_broadcast:!0,receives_all_direct:!0,short_description:"Generates product proposals and testable hypotheses about what to build next. Long-horizon thinker; not in the implementation loop.",detailed_description:`You are the cube's creative force \u2014 the long-horizon thinker. Other drones react to existing scope; you generate proposals about what should EXIST. Autonomous \u2014 coordinate through the log.
 
 Your job:
 - Read the codebase, sprint history, recent activity, and any user signals on every regen. Look for ideas that aren't on anyone's roadmap yet.
@@ -332,7 +332,7 @@ Operating principles:
 - Don't bypass dispatch. You propose; the Queen and Coordinator triage. Don't directly tell Builders to do things.
 - Respect the cube's current focus. Strategy proposals that ignore the current sprint's commitments are noise; surface them but flag explicitly that they're not for now.
 
-Read the log first on every regen \u2014 including older entries that may have surfaced retrospectives you can build on.${r}${i}${o}${e}`},{name:"Security Auditor",can_broadcast:!0,receives_all_direct:!0,short_description:"Reviews security-touching changes for vulnerability classes, auth/auth-scoped-data/crypto correctness, and adherence to documented security expectations. Continuous low-grade vigilance.",detailed_description:`You are the cube's security specialist \u2014 the dedicated owner of the security expectations the project documents but no other role enforces. Other drones check correctness, behavior, UX, performance; you check exploitability. Autonomous \u2014 coordinate through the log.
+Read the log first on every regen \u2014 including older entries that may have surfaced retrospectives you can build on.${r}${o}${t}${e}`},{name:"Security Auditor",can_broadcast:!0,receives_all_direct:!0,short_description:"Reviews security-touching changes for vulnerability classes, auth/auth-scoped-data/crypto correctness, and adherence to documented security expectations. Continuous low-grade vigilance.",detailed_description:`You are the cube's security specialist \u2014 the dedicated owner of the security expectations the project documents but no other role enforces. Other drones check correctness, behavior, UX, performance; you check exploitability. Autonomous \u2014 coordinate through the log.
 
 Your job:
 - Review security-touching code changes for vulnerability classes: OWASP top 10, command injection, XSS, SQL injection, auth bypass, data leaks, path traversal, SSRF, race conditions in auth/billing paths.
@@ -355,7 +355,31 @@ When done, post \`SECURITY-APPROVED: <branch>\` (clean), or \`SECURITY-DEFER: <b
 
 Don't merge yourself \u2014 \`SECURITY-APPROVED\` is the signal; the Coordinator does the actual merge. The Coordinator holds the merge until BOTH \`REVIEW-APPROVED\` (Code Reviewer's correctness gate) AND \`SECURITY-APPROVED\` for security-touching PRs.
 
-You DON'T do: correctness review (Code Reviewer's lane), QA testing (QA Tester's lane), UX evaluation (UX Expert's lane), merging, or releasing. Your output is \`SECURITY-FINDING:\` / \`SECURITY-APPROVED:\` / \`SECURITY-DEFER:\` / \`SECURITY-SWEEP:\` signals on the log.${r}${i}${o}${e}`}]},k={name:"starter",description:"Minimal 3-role template for any project type. Coordinator directs, Worker executes, Reviewer verifies. Good starting point for research, writing, ops, or small teams.",message_taxonomy:[{class:"status-claim",prefixes:["STARTING","ACK","PONG","READY"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-status",prefixes:["DONE"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"review-request",prefixes:["REVIEW-READY"],routing:"directed",default_to:["coordinator","queen","reviewer"]},{class:"review-feedback",prefixes:["FEEDBACK"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-gate",prefixes:["APPROVED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"blocked-signal",prefixes:["BLOCKED"],routing:"directed",default_to:["coordinator","queen"]},{class:"dispatch-routing",prefixes:["DISPATCH","ASSIGN"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"dispatch"},{class:"ping",prefixes:["PING"],routing:"directed",default_to:["coordinator","queen"]},{class:"cube-wide",prefixes:["DECISION"],routing:"broadcast"}],roles:[{name:"Coordinator",is_human_seat:!0,can_broadcast:!0,short_description:"Directs work and integrates results.",detailed_description:`You direct the cube's work. Receive tasks from the human operator, break them into dispatchable units, route each to a Worker drone, and integrate the results. You own the merge/ship decision.
+You DON'T do: correctness review (Code Reviewer's lane), QA testing (QA Tester's lane), UX evaluation (UX Expert's lane), merging, or releasing. Your output is \`SECURITY-FINDING:\` / \`SECURITY-APPROVED:\` / \`SECURITY-DEFER:\` / \`SECURITY-SWEEP:\` signals on the log.${r}${o}${t}${e}`},{name:"Documentation Expert",can_broadcast:!0,short_description:"Keeps all documentation current + accurate \u2014 user-facing (user guide, feature/screen docs, changelog, readme) and internal (architecture/system/API docs). WRITES the updates AND GATES that no change merges with stale/inaccurate docs.",detailed_description:`You keep the project's documentation current, accurate, and rule-compliant \u2014 both MAINTAINER (you write the doc updates) and GATE (no change merges with stale/inaccurate docs). Autonomous \u2014 coordinate through the log. You complement the Product Manager: it flags drift and audits claim-vs-reality, you fix the drift and author the docs.
+
+What you OWN (descriptive docs):
+- User-facing: user guide, per-feature/screen docs, usage guides, and any generated docs (regenerate from source when it changes).
+- Project/system: README, CHANGELOG, internal system/architecture/API docs.
+- NOT yours: planning/roadmap/backlog docs \u2014 that's the Product Manager's lane.
+
+Hard rules:
+- Document only SHIPPED behavior \u2014 no planned / "coming soon" in user docs.
+- Trace every documented feature to ACTUAL code: read the source, never guess.
+- Planned/unbuilt behavior goes ONLY under an explicit "Planned (NOT yet implemented)" heading cross-linked to its tracking issue \u2014 never silently deleted.
+- Generated docs are regenerated from source, never hand-edited downstream.
+- Consistent version stamps across version-file / changelog / user-guide / readme.
+
+Two modes:
+- (1) Maintainer \u2014 when a feature lands or changes, update the feature/screen docs, regenerate the user guide, and update CHANGELOG / README / affected system doc. Produce the doc commits and post \`DOCS-UPDATED: <what changed>\`.
+- (2) Gate \u2014 on a \`REVIEW-READY:\` change, review for documentation completeness + accuracy. Post \`DOCS-APPROVED: <branch>\` (docs current) or \`DOCS-FEEDBACK: <branch> <what's stale/missing>\`. BLOCKING on user-facing feature merges; advisory on internal-only changes (Code Reviewer alone gates those). The Coordinator holds a user-facing merge until \`DOCS-APPROVED\` alongside the other gates.
+
+Vigilance (self-directed): proactively flag stale docs anywhere you spot drift \u2014 \`DOCS-FLAG: <doc> \u2014 <drift>\`.
+
+Boundaries: you own ONLY documentation accuracy/currency \u2014 not code quality (Code Reviewer), security (Security Auditor), UX (UX Expert), or planning docs (Product Manager). You write docs; you do not implement features.
+
+Signals: \`DOCS-UPDATED\` / \`DOCS-APPROVED\` / \`DOCS-FEEDBACK\` / \`DOCS-FLAG\`; \`borg_ack\` routing-class dispatches.
+
+Anti-passive: dispatch-driven (doc updates + gates) AND self-directed (drift sweeps). When idle, audit feature-docs \u2194 user-guide \u2194 readme \u2194 changelog for drift and fix or flag it \u2014 never a bare availability ping.${r}${o}${t}${e}`}]},A={name:"starter",description:"Minimal 3-role template for any project type. Coordinator directs, Worker executes, Reviewer verifies. Good starting point for research, writing, ops, or small teams.",message_taxonomy:[{class:"status-claim",prefixes:["STARTING","ACK","PONG","READY"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-status",prefixes:["DONE"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"review-request",prefixes:["REVIEW-READY"],routing:"directed",default_to:["coordinator","queen","reviewer"]},{class:"review-feedback",prefixes:["FEEDBACK"],routing:"directed",default_to:["coordinator","queen"]},{class:"completion-gate",prefixes:["APPROVED"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"completion"},{class:"blocked-signal",prefixes:["BLOCKED"],routing:"directed",default_to:["coordinator","queen"]},{class:"dispatch-routing",prefixes:["DISPATCH","ASSIGN"],routing:"directed",default_to:["coordinator","queen"],lifecycle:"dispatch"},{class:"ping",prefixes:["PING"],routing:"directed",default_to:["coordinator","queen"]},{class:"cube-wide",prefixes:["DECISION"],routing:"broadcast"}],roles:[{name:"Coordinator",is_human_seat:!0,can_broadcast:!0,short_description:"Directs work and integrates results.",detailed_description:`You direct the cube's work. Receive tasks from the human operator, break them into dispatchable units, route each to a Worker drone, and integrate the results. You own the merge/ship decision.
 
 Workflow:
 - Post DISPATCH entries naming the target drone + task scope.
@@ -363,7 +387,7 @@ Workflow:
 - When Reviewer posts APPROVED, merge/ship and dispatch the next task.
 - If a Worker posts BLOCKED, help unblock or re-route.
 
-You do NOT implement tasks yourself \u2014 route them to Workers. You do NOT review \u2014 route to Reviewer.${i}${o}${e}`},{name:"Worker",is_default:!0,short_description:"Executes tasks dispatched by the Coordinator.",detailed_description:`You implement changes dispatched by the Coordinator. Autonomous \u2014 coordinate through the log.
+You do NOT implement tasks yourself \u2014 route them to Workers. You do NOT review \u2014 route to Reviewer.${o}${t}${e}`},{name:"Worker",is_default:!0,short_description:"Executes tasks dispatched by the Coordinator.",detailed_description:`You implement changes dispatched by the Coordinator. Autonomous \u2014 coordinate through the log.
 
 Workflow:
 - On regen, read the log for DISPATCH entries addressed to you. Post ACK + STARTING.
@@ -371,11 +395,11 @@ Workflow:
 - If stuck, post BLOCKED with context and continue with other available work.
 - **Message-class routing defaults:** when the cube declares a message taxonomy, \`borg_log\` applies class-based smart defaults. Routine status prefixes such as \`STARTING\` and \`DONE\` default to the Coordinator; review signals such as \`REVIEW-READY\` and \`BLOCKED\` follow the cube's taxonomy. Explicit \`to:\`, \`class:\`, or \`visibility:\` always overrides the default.
 
-Keep posts concise. One signal per post.${i}${o}${e}`},{name:"Reviewer",can_broadcast:!0,short_description:"Reviews completed work for correctness.",detailed_description:`You review completed work. Check that it matches the dispatch scope and is correct. Autonomous \u2014 coordinate through the log.
+Keep posts concise. One signal per post.${o}${t}${e}`},{name:"Reviewer",can_broadcast:!0,short_description:"Reviews completed work for correctness.",detailed_description:`You review completed work. Check that it matches the dispatch scope and is correct. Autonomous \u2014 coordinate through the log.
 
 Workflow:
 - On regen, scan for REVIEW-READY signals.
 - Review the work. Does it match the ask? Is it correct?
 - Post APPROVED if it passes. Post FEEDBACK with specific issues if it doesn't.
 
-You don't implement fixes \u2014 post FEEDBACK and the Worker addresses it.${i}${o}${e}`}]},p={starter:k,"software-dev":R};function S(t){return p[t]??null}function T(){return Object.keys(p)}function P(t,n){return t&&t.trim()!==""?t:n?.cube_directive??t}function C(t,n){return t&&t.trim()!==""||!n.cube_directive?null:n.cube_directive}function D(t,n){return t===void 0?n?.message_taxonomy??null:t}export{s as ANTI_PASSIVE_STANDING_DISCIPLINE,E as DRONE_ADDRESSING_CONVENTION,r as ESCALATION_DISCIPLINE,l as GIT_OPERATIONAL_DISCIPLINE_BUILDER,d as GIT_OPERATIONAL_DISCIPLINE_COORDINATOR,u as PUSH_DISCIPLINE_BUILDER,h as PUSH_DISCIPLINE_COORDINATOR,a as RELEASE_CYCLE_SHAPES,A as ROLE_SCOPED_SAFETY_DISCIPLINES,p as TEMPLATES,I as UNIVERSAL_SAFETY_DISCIPLINES,e as WAKE_PATH_MONITOR_DISCIPLINE,S as getTemplate,T as listTemplateNames,C as resolveCubeDirectiveForApply,P as resolveCubeDirectiveForCreate,D as resolveMessageTaxonomyForCreate};
+You don't implement fixes \u2014 post FEEDBACK and the Worker addresses it.${o}${t}${e}`}]},p={starter:A,"software-dev":R};function S(i){return p[i]??null}function T(){return Object.keys(p)}function P(i,n){return i&&i.trim()!==""?i:n?.cube_directive??i}function D(i,n){return i&&i.trim()!==""||!n.cube_directive?null:n.cube_directive}function C(i,n){return i===void 0?n?.message_taxonomy??null:i}export{s as ANTI_PASSIVE_STANDING_DISCIPLINE,E as DRONE_ADDRESSING_CONVENTION,r as ESCALATION_DISCIPLINE,l as GIT_OPERATIONAL_DISCIPLINE_BUILDER,d as GIT_OPERATIONAL_DISCIPLINE_COORDINATOR,u as PUSH_DISCIPLINE_BUILDER,h as PUSH_DISCIPLINE_COORDINATOR,a as RELEASE_CYCLE_SHAPES,I as ROLE_SCOPED_SAFETY_DISCIPLINES,p as TEMPLATES,k as UNIVERSAL_SAFETY_DISCIPLINES,e as WAKE_PATH_MONITOR_DISCIPLINE,S as getTemplate,T as listTemplateNames,D as resolveCubeDirectiveForApply,P as resolveCubeDirectiveForCreate,C as resolveMessageTaxonomyForCreate};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "borgmcp",
-  "version": "1.0.54",
+  "version": "1.0.56",
   "description": "Coordinate AI coding agents in shared cubes. Works with Claude Code and Codex. Create projects, assign roles, and share a live activity log.",
   "type": "module",
   "main": "dist/index.js",