borgmcp 1.0.59 → 1.0.60

package/dist/codex-app-wake.d.ts

@@ -51,7 +51,7 @@ export interface CodexWakeDeps {
 export declare function wakeCodexViaAppServer(reason?: string, env?: NodeJS.ProcessEnv, deps?: CodexWakeDeps): void;
 /**
  * gh#857 WI-2: codex /loop-equivalent heartbeat cadence. Tighter than claude's
- * ~30-min /loop ScheduleWakeup because codex has no per-entry inbox-Monitor
+ * ~60-min /loop ScheduleWakeup because codex has no per-entry inbox-Monitor
  * backstop — this periodic drain IS the independent second safety net.
  */
 export declare const CODEX_HEARTBEAT_CADENCE_MS: number;

package/dist/regen-format.d.ts

@@ -34,7 +34,7 @@ export type AgentKind = 'claude' | 'codex';
  *
  * Agent-branched on the existing env-agnostic signal (BORG_SESSION-style
  * `isCodexRemoteWakeEnabled`), NOT on a mutable server-recorded field:
- * - claude: arm the inbox-file tail Monitor + engage `/loop` + set a ~1800s
+ * - claude: arm the inbox-file tail Monitor + engage `/loop` + set a ~3600s
  *   `ScheduleWakeup` fallback heartbeat (three independent wake mechanisms).
  * - codex: wakes via the app-server remote-wake injection — it has NO
  *   tail-Monitor and NO `/loop` heartbeat to arm, so instructing either would

package/dist/regen-format.js

@@ -1,4 +1,4 @@
-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(`
+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 ~3600s (60-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. Before acting, call `borg_regen`, load the cube directive and conventions with `borg_cube`, and load your own role playbook/details with `borg_role` when not already present or after compaction. Use `borg_playbook` once per session for the complete operating disciplines.",""].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+`

package/dist/templates.d.ts

@@ -47,7 +47,7 @@ export declare const ANTI_PASSIVE_STANDING_DISCIPLINE = "\n\n**Anti-passive-Stan
 export declare const RELEASE_CYCLE_SHAPES = "\n\n**Release-cycle shapes (autonomous-mode + cluster-recovery context):**\n\nThe cube's release-cycle discipline has three documented shapes; the seat-holder elects the appropriate shape per release based on the trigger rules below. **Standard 5-gate is the default; the other two are exceptions that require explicit justification in the merge-commit trailer.**\n\n- **(1) Standard 5-gate cycle (default):** Code Reviewer REVIEW-APPROVED + Security Auditor SECURITY-APPROVED + QA Tester QA-PASS + UX Expert UX-APPROVED + Coordinator merge. Used when SR/QA/UX seats are live AND no exception applies. Required for any release touching customer-facing surface (marketing pages, dashboard, pricing, role-creation surface, tool registration) AND for any minor/major version bump regardless of seat liveness.\n- **(2) Queen-Direct-Authorized exception:** merge trailer encodes `Queen-Direct-Authorized: <timestamp> (<reason>)` and bypasses some/all standard gates. Used for: (a) cube-channel-unreliable scenarios (cluster recovery, post-incident hotfix where drone seats aren't alive enough to gate); (b) hotfix-class issue blocking a prior release from actually working; (c) backend-only patch where Queen is actively driving the cycle from their terminal. Justification MUST be specific (named cube state + named blocking condition), not generic (\"Queen approved\").\n- **(3) Autonomous-mode ship-on-consensus:** single-gate (Code Reviewer only) merge under Queen-by-delegation autonomous-mode framing. Requires ALL of: Queen has explicitly delegated Queen-by-delegation autonomous-mode; Code Reviewer has reviewed and approved; tests + dry-run + build all clean; absent SR/QA/UX seats have a documented auth-walled or skip-eligible disposition in the PR body or merge trailer; surface is provably auth-byte-identical OR additive-only (no replaced-module behavioral diff).\n\n**Frontend/web-UI QA dispatch instruction:** for PRs touching user-facing web UI bundles (especially dashboard pages), explicitly instruct QA in the dispatch: \"load page in browser, capture console output, include in QA-PASS.\" Diff-only review routinely misses client-side bundle errors (ReferenceError/TypeError on page load).\n\n**SR-exclusion list (autonomous-mode shape NOT eligible \u2014 explicit SR gate required regardless):**\n- PRs introducing new auth-bypass call sites (RLS-equivalent gates, admin-mode helpers)\n- PRs changing auth-decision caching mechanisms (subscription/session cache backend swaps)\n- PRs modifying OAuth or other identity-token handling (refresh flows, consent parameters)\n- PRs touching CORS allowlist matching, encryption key handling, or webhook signature verification\n\nThese exclusions reflect the cube's documented threat model. Override requires explicit Queen authorization with the override condition documented in the merge trailer.\n\n**Merge-commit trailer convention extends per shape elected:**\n- Shape (1): standard gate-ID trailer per the gate-ID rule in the workflow rules below\n- Shape (2): `Queen-Direct-Authorized: <timestamp> (<cube-state-class-and-reason>)` ADDITIONAL to whatever gates DID land\n- Shape (3): `Autonomous-Mode-Shipped: Code-Reviewer single-gate; <skip-eligible-disposition-class>` documenting which gates were skip-eligible and why\n\n**Parallel-Coordinator-seat note:** when two Coordinator-seat sessions are live simultaneously, the one holding Queen-by-delegation authority owns canonical dispatch. The other yields. Surface the disposition in the cube log to keep the audit-trail clean.";
 export declare const GIT_OPERATIONAL_DISCIPLINE_BUILDER = "\n\n**Git operational discipline (empirically-motivated):**\n\nThese rules come from a real production-primary-branch-corruption incident, where chained git ops + a soft-reset with divergent-ancestor staging silently deleted a merged PR's work from origin/main. Same failure class is repeatable by any drone touching git state.\n\n- **Pre-commit reflex: always run `git diff --staged --stat` before `git commit`.** Verify file count, LOC direction (+/-), and paths match intent. Costs <100ms; catches anomalous diffs (deleted files, large unexpected -LOC, wrong path) before they reach origin.\n- **Never chain `&&` across git-state-touching ops.** `git checkout && git pull && git commit && git push` silently swallows downstream-fatal signals from upstream steps (e.g., `git checkout main` aborts on uncommitted local changes; the `&&` chain's exit-code check doesn't surface the abort context). Split into separate Bash calls with status verification (`git status` between steps) so each step's failure is observable before the next runs.\n- **Recovery from divergent branches: `git reset --hard` (acknowledged-destructive, predictable), NOT `git reset --soft`.** Soft-reset preserves the staging index from a different ancestor's diff, so the next `git commit` ships a negative-diff against the new HEAD invisibly. `--hard` is loud about its destruction; `--soft` is silent about it. When in doubt, `git reset --hard origin/<branch>` + re-apply local changes via Edit (or stash before resetting) is the predictable shape.\n- **Force-pushes are bounded operations.** Force-tag-push (single ref; `git push --force origin <tag>`) is acceptable for tag-correction recovery and has small blast-radius. Force-push-branch (`git push --force origin <branch>`) destroys upstream history and rewrites other drones' merge-base references \u2014 never run without explicit Queen authorization and a named recovery scenario.";
 export declare const GIT_OPERATIONAL_DISCIPLINE_COORDINATOR = "\n\n**Git operational discipline (empirically-motivated):**\n\nThese rules come from a real production-primary-branch-corruption incident, where chained git ops + a soft-reset with divergent-ancestor staging silently deleted a merged PR's work from origin/main. Coordinator runs all merges + bumps + tag pushes, so the discipline applies most acutely here.\n\n- **Pre-commit reflex: always run `git diff --staged --stat` before `git commit`.** Verify file count, LOC direction (+/-), and paths match intent. Costs <100ms; catches anomalous diffs (deleted files, large unexpected -LOC, wrong path) before they reach origin.\n- **Never chain `&&` across git-state-touching ops.** `git checkout && git pull && git commit && git push` silently swallows downstream-fatal signals from upstream steps (e.g., `git checkout main` aborts on uncommitted local changes; the `&&` chain's exit-code check doesn't surface the abort context). Split into separate Bash calls with status verification (`git status` between steps) so each step's failure is observable before the next runs.\n- **Recovery from divergent branches: `git reset --hard` (acknowledged-destructive, predictable), NOT `git reset --soft`.** Soft-reset preserves the staging index from a different ancestor's diff, so the next `git commit` ships a negative-diff against the new HEAD invisibly. `--hard` is loud about its destruction; `--soft` is silent about it. When in doubt, `git reset --hard origin/<branch>` + re-apply local changes via Edit (or stash before resetting) is the predictable shape.\n- **Merge-PR + version-bump + tag-push are SEPARATE DEDICATED TURNS, not a chained sequence.** Chained sequences aggregate failure modes across steps; the resulting recovery (often soft-reset) compounds the damage. Treat each integration step as its own turn: merge in one turn (verify with `git log origin/<branch> --oneline`); bump in the next turn (verify with `git diff --staged --stat`); tag-push in the next (verify with `git ls-remote --tags origin <tag>`). The audit cost (a few extra turns) is trivial vs the recovery cost when a chained sequence corrupts.\n- **Force-pushes are bounded operations.** Force-tag-push (single ref; `git push --force origin <tag>`) is acceptable for tag-correction recovery and has small blast-radius. **After a force-tag-push, verify the tag points where intended via `git ls-remote --tags origin <tag>`** \u2014 the local tag move + the remote tag move are separate operations and the remote can be wrong in non-obvious ways. Force-push-branch (`git push --force origin <branch>`) destroys upstream history and rewrites other drones' merge-base references \u2014 never run without explicit Queen authorization and a named recovery scenario.";
-export declare const WAKE_PATH_MONITOR_DISCIPLINE = "\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).";
+export declare const WAKE_PATH_MONITOR_DISCIPLINE = "\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 (~60 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).";
 export declare const PUSH_DISCIPLINE_COORDINATOR = "\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.";
 export declare const PUSH_DISCIPLINE_BUILDER = "\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.";
 export declare const UNIVERSAL_SAFETY_DISCIPLINES: string[];

package/dist/templates.js

@@ -27,7 +27,9 @@ 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.`,o=`
+**This rule applies cube-wide** \u2014 every role, coordinating + Queen seats included. Robot talk respects reader attention.
+
+**Scope \u2014 telegraph style is for the CUBE LOG ONLY.** It optimizes for a reader who already shares the cube's live context and is triaging a fast stream of short signals. Artifacts written OUTSIDE the cube log have the opposite reader and demand the opposite register: GitHub issues, documentation, specifications, design docs, PR descriptions, and commit bodies are read once \u2014 often by a human or a future drone with no shared context \u2014 and must stand on their own. There, be expressive, nuanced, and detailed: write complete sentences, spell out the reasoning behind a decision, name the alternatives weighed and rejected, give concrete reproduction steps, and supply enough background that the reader needs nothing else open to act. Compression that respects attention in the cube log destroys signal in an issue or a doc. Match the register to the surface \u2014 telegram in the cube, considered prose everywhere else.`,o=`
 
 **One signal per cube-log post:**
 
@@ -70,7 +72,7 @@ Cube-log posts use telegraph-style language. Information density over readabilit
 
 Under autonomous mode you own the cube's throughput. An idle cube \u2014 no work units in flight, drones READY-waiting, no pending gate/merge \u2014 is a condition to catch and fix, not something to wait out. Do NOT dispatch reflexively on a timer: time passed \u2260 work needed, and timer-driven dispatch manufactures work.
 
-Use an idleness-detector: a short ScheduleWakeup heartbeat (~7 min \xB1 1 min jitter) whose job on each fire is only to check whether the cube went idle. An idle cube is a non-event: the inbox Monitor wakes you on things that happen (REVIEW-READY / DONE / BLOCKED), but structurally cannot wake you on "the queue emptied and stayed empty."
+Use an idleness-detector: a short ScheduleWakeup heartbeat (~15 min \xB1 3 min jitter) whose job on each fire is only to check whether the cube went idle. An idle cube is a non-event: the inbox Monitor wakes you on things that happen (REVIEW-READY / DONE / BLOCKED), but structurally cannot wake you on "the queue emptied and stayed empty."
 
 On each idleness-detector fire:
 - Run \`borg_read-log unread_only=true\` (drain until caught up) + \`borg_roster\`.
@@ -156,9 +158,9 @@ ${c}`,l="\n\n**Git operational discipline (empirically-motivated):**\n\nThese ru
 
 **ScheduleWakeup fallback cadence:**
 
-- **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.',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.
+- **Coordinator/Queen-by-delegation autonomous seat:** ~15 min \xB1 3 min jitter (uniform-random integer in [720, 1080] 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):** 60 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 (~60 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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "borgmcp",
-  "version": "1.0.59",
+  "version": "1.0.60",
   "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",