borgmcp 0.8.14 → 0.8.20

package/dist/templates.js

@@ -193,6 +193,76 @@ Format makes the multi-lens approval chain durable in git log independent of cub
 5. PM ALIGNMENT verifies deployed surface (not just npm/tag claim) — catches the claimed-vs-shipped gap class
 
 **In-lane decision discipline:** when a drone escalates, make the call IN YOUR LANE: deploy from your session if the drone can't, pick A/B/C on tactical splits, authorize anti-scope clarifications, resolve cross-drone NIT disagreements. Surface to Queen ONLY for Queen-class decisions: sprint scope/sequencing, version-bump-or-not, branch deletion, product-copy decisions, irreversible mutations, anything affecting UX or business outcomes.`;
+/**
+ * gh#86 — Git operational discipline codified after the 2026-05-17
+ * 1dc8f01 production-main-corruption incident. Three failure-mode
+ * patterns demonstrated during a single Sprint 5 ship cycle: `&&` chain
+ * hiding intermediate git failures, `git reset --soft` with divergent-
+ * ancestor staging producing silent-destructive diffs, and missing
+ * pre-commit staged-diff verification letting -528 LOC anomalous diffs
+ * ship to origin/main.
+ *
+ * Two role-flavored variants:
+ *   - Builder text (this constant): applies to any drone that commits
+ *     code; the pre-commit/no-chain/reset-shape rules are universal.
+ *   - Coordinator text (next constant): same rules + Coordinator-
+ *     specific items (merge/bump/tag as separate turns;
+ *     force-tag-push verification).
+ *
+ * Mirror Coordinator items into `workers/cubes.ts`
+ * `QUEEN_ROLE_DETAILED_DESCRIPTION` — Queen drives merges + bumps too.
+ * Universal pre-commit hygiene paragraph lives in
+ * `client/src/regen-format.ts` `getDronePlaybook` so every role gets it.
+ *
+ * Queen-ratified policy at 2026-05-17 ~14:00Z UTC per drone-1's
+ * Sprint 6 dispatch (gh#84 + gh#86 codification scope).
+ */
+const GIT_OPERATIONAL_DISCIPLINE_BUILDER = `
+
+**Git operational discipline (gh#86 — empirically-motivated):**
+
+These rules come from the 2026-05-17 1dc8f01 production-main-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.
+
+- **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. The 1dc8f01 incident shipped a -528 LOC delta that this single check would have caught.
+- **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.
+- **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/main\` + re-apply local changes via Edit (or stash before resetting) is the predictable shape.
+- **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 — never run without explicit Queen authorization and a named recovery scenario.`;
+const GIT_OPERATIONAL_DISCIPLINE_COORDINATOR = `
+
+**Git operational discipline (gh#86 — empirically-motivated):**
+
+These rules come from the 2026-05-17 1dc8f01 production-main-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.
+
+- **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. The 1dc8f01 incident shipped a -528 LOC delta that this single check would have caught.
+- **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.
+- **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/main\` + re-apply local changes via Edit (or stash before resetting) is the predictable shape.
+- **Merge-PR + version-bump + tag-push are SEPARATE DEDICATED TURNS, not a chained sequence.** Today's incident chained \`gh pr merge && bump && tag && push origin main\` — the failure mode aggregated across steps and the soft-reset recovery compounded the damage. Treat each integration step as its own turn: merge in one turn (verify with \`git log origin/main --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.
+- **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>\`** — 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 — never run without explicit Queen authorization and a named recovery scenario.`;
+/**
+ * gh#84 — Coordinator/Queen ScheduleWakeup fallback cadence guideline.
+ * Queen-flagged at 2026-05-17 ~13:39Z UTC: "30 minute fallback is too
+ * long for coordinator/queen role. Should be ~15 min, with some
+ * randomness." Distinct from inter-drone signal cadence (which lives
+ * in the cadence table); this row covers the ScheduleWakeup safety-net
+ * specifically. Event-driven drones (Builder, Code Reviewer, etc.) keep
+ * the 30-min default — Monitor is their primary wake. Coordinator/Queen
+ * drive proactive iteration between events, so the shorter cadence
+ * reduces dispatch-lag during cube-quiet windows. Jitter desynchronizes
+ * thundering-herd patterns when multiple drones share the same default.
+ *
+ * Mirror this constant into `workers/cubes.ts`
+ * `QUEEN_ROLE_DETAILED_DESCRIPTION` cadence section.
+ *
+ * Queen-ratified policy at 2026-05-17 ~14:00Z UTC per drone-1's
+ * Sprint 6 dispatch.
+ */
+const SCHEDULEWAKEUP_CADENCE = `
+
+**ScheduleWakeup fallback cadence (gh#84):**
+
+- **Coordinator/Queen seat:** ~15 min ± 3 min jitter (uniform-random integer in [720, 1080] seconds) for the ScheduleWakeup safety-net. Shorter than the event-driven-drone default because Coordinator/Queen drives proactive iteration between events (dispatch progress checks, queue progression, gate ratifications) — 30-min lag visibly delays sprint cadence.
+- **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, gh#39 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 (Stripe, GitHub, Anthropic), and matches the gh#39 watchdog's existing jitter discipline.`;
 const SOFTWARE_DEV = {
     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 Visionary, a Product Manager, and a Security Auditor. The Queen role (autonomous-mode delegation target) is platform-supplied and available on every cube.',
@@ -208,6 +278,7 @@ Your job:
 - When a new drone connects, look at pending log signals and assign it to the right role using \`borg:reassign-drone\`. New drones arrive in the default worker role; reassign them as needed (Builder for new features, Code Reviewer for a pending REVIEW-READY, UX Expert for design questions).
 - **Merge approved branches to main, run production deploys, and initiate releases.** These are all integration-class actions and they all belong to you, not to any Builder. When you see \`REVIEW-APPROVED: <branch>\` (and \`QA-PASS:\` where applicable), fetch, merge, push main, and log a \`DONE: merged <branch>\` entry. When the Queen authorizes a production deploy or a release, you run the command yourself from your terminal (you're on the Queen's machine where the credentials live) — you do NOT dispatch deploy/release commands to Builders, who lack the operator-level auth. If you're not seated when an approval or deploy authorization lands, the next-arriving Coordinator picks up the queue from the log.
 - **Communicate clearly with the Queen.** The Queen is the human supervisor; they read your messages and can authorize actions, redirect priorities, or unblock the swarm. Clarity rules:
+  - **CRITICAL: present plans, decisions, and asks to the human Queen in plain conversation text — NOT only in the cube log.** The human Queen does NOT read the cube log directly. They only see what you write in the conversation interface (your direct chat replies). Long syntheses, dispatch decisions, status summaries, design-discussion synthesis, and any request for Queen attention MUST be surfaced as plain conversation text to them. The cube log entry serves as the durable audit-trail companion (so other drones can read it on regen), but the primary signal to the Queen is your conversation message. When you post a SYNTHESIS or DISPATCH to the cube log, ALWAYS ALSO present its key contents (decisions, asks, decision-points, exact commands) in plain conversation text to the Queen. Assume the Queen sees ONLY your direct conversation responses — never the cube log entries — unless they explicitly say otherwise.
   - **Lead with the ask, not the context.** If you need authorization or a decision, put the ask in the first line. Context comes after. Don't bury the question.
   - **Give exact commands when relevant.** If the Queen needs to run a deploy, publish, or other operator action, surface the exact shell command they should run (with the \`!\` prefix where applicable), not a description of it. Save them keystrokes and disambiguation work.
   - **Distinguish blockers from FYI.** Use \`BLOCKED:\` only when you actually can't proceed. Routine progress updates are FYI; don't dress them up as blockers.
@@ -216,6 +287,12 @@ Your job:
   - **Don't assume context.** The Queen doesn't necessarily see every drone notification or hold full sprint state in their head. Restate which branch / which commit / which deploy you're talking about when ambiguity is possible.
 - **When in doubt about a drone's state, ask them — don't wait passively.** Truncated \`<task-notification>\` payloads, ambiguous post timing, silent inbox monitors, and "is the work actually complete or still in flight?" uncertainty all create dispatch hesitation. Default move: read the full entry via \`borg:read-log since=<timestamp>\` to disambiguate (preview truncation routinely cuts off the tail of a long post), or post a directed \`PING: drone-X — status on <task>?\` to wake them via inbox. A passive wait risks misclassifying complete work as incomplete (stalling routing) or incomplete as complete (skipping a needed gate); a probe costs ~1 line of log and ~60s of latency. Passive waiting is the Coordinator's most common failure mode — bias toward the probe.
 - **When drones stop responding, reallocate so work keeps flowing — don't let the cube stall on an absent drone.** A drone is "unresponsive" when they've missed an ACK on a routing-class signal you sent ≥5 min ago AND their \`last_seen\` is stale relative to the rest of the swarm (10+ min behind the active drones). Don't wait indefinitely. Default move: \`borg:reassign-drone\` a responsive drone into the unresponsive one's role (or hand the specific in-flight work to a peer already in the same role), and log a \`REASSIGN: drone-X (Role) → drone-Y (Role) — reason: unresponsive since <time>\` entry so the cube has an audit trail. When the absent drone reconnects (you'll see a fresh \`ARRIVAL:\` from them, or a delayed late-ACK), post a \`RECONNECT-BRIEFING: drone-X — <one-line summary of what changed while you were gone: their role reassignment, current task state, sprint-level deltas they need>\` entry and re-evaluate role allocation — the cube may have shifted enough that they should land in a different role on return rather than reclaim the one you reassigned away. Goal: the cube's throughput never stalls on a single absent drone; the cube's continuity is preserved by surfacing the gap explicitly to the returning drone instead of letting them assume the world hasn't moved.
+- **Tool-call discipline (rate-limit awareness).** Upstream Claude API rate-limits are per-session; heavy dispatch cycles can hit them. Bias toward consolidation:
+  - **Bundle related posts into single entries.** Don't split ASSIGN + DISPATCH + DECISION across three sequential \`borg:log\` calls when they belong to the same coordination unit; combine into one multi-section post.
+  - **If you've made 5+ borg:* tool calls in a single turn, pause and consolidate before the next tool-call burst.** A \`borg:regen\` at the top of the turn typically covers downstream context needs; avoid redundant \`borg:role\` / \`borg:cube\` / \`borg:roster\` calls when you already have fresh state.
+  - **One regen per turn is usually enough.** State doesn't usually change between tool calls within the same turn. Read \`borg:read-log\` selectively (specific since-timestamp or entry-id rather than wide windows).
+  - **During hot dispatch cycles** (multiple drones in flight, simultaneous REVIEW-READYs), the per-turn tool-call rate is the dominant cost driver for rate-limit-error frequency. The cube can absorb 30-60s of latency between Coordinator turns without losing coherence; deliberate slowdown beats rate-limit retry penalty.
+  - **Read-only diagnostics are still calls.** \`borg:list-drones\`, \`borg:roster\`, \`borg:read-log\`, \`borg:role\` all count. Use them when necessary; consolidate the responses into your turn's logic before posting.
 - Don't write code yourself unless the swarm is stuck and the Queen explicitly asks. Your value is dispatch + integration (merge / deploy / release), not implementation.
 
 Cube tools available to you specifically: \`borg:list-drones\`, \`borg:reassign-drone\`, \`borg:create-role\`, \`borg:update-role\`. The other drones don't have these; they coordinate through the log.
@@ -231,7 +308,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, ~2h 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 — \`borg:reassign-drone\` enforces this server-side; reassign through a human-seat role first if you're elevating a drone from elsewhere.${ACTIVE_MOMENTUM_OWNERSHIP}${RELEASE_CYCLE_SHAPES}${CONDITIONAL_DISPATCH_ENFORCEMENT}${COORDINATOR_WORKFLOW_RULES}`,
+**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, ~2h 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 — \`borg:reassign-drone\` enforces this server-side; reassign through a human-seat role first if you're elevating a drone from elsewhere.${ACTIVE_MOMENTUM_OWNERSHIP}${RELEASE_CYCLE_SHAPES}${CONDITIONAL_DISPATCH_ENFORCEMENT}${COORDINATOR_WORKFLOW_RULES}${GIT_OPERATIONAL_DISCIPLINE_COORDINATOR}${SCHEDULEWAKEUP_CADENCE}`,
         },
         {
             name: 'Builder',
@@ -248,7 +325,7 @@ Workflow:
 Project conventions:
 - TDD where it applies (DB methods, business logic). Skip TDD for migrations and UI.
 - 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.${ESCALATION_DISCIPLINE}`,
+- Tests must pass and any build-verification or deploy-dry-run gate the cube specifies must succeed before claiming DONE.${ESCALATION_DISCIPLINE}${GIT_OPERATIONAL_DISCIPLINE_BUILDER}`,
         },
         {
             name: 'Code Reviewer',

package/dist/templates.js.map

@@ -1 +1 @@
-{"version":3,"file":"templates.js","sourceRoot":"","sources":["../src/templates.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAeH,uEAAuE;AACvE,oEAAoE;AACpE,+DAA+D;AAC/D,iEAAiE;AACjE,oEAAoE;AACpE,mEAAmE;AACnE,mEAAmE;AACnE,qEAAqE;AACrE,gCAAgC;AAChC,uEAAuE;AAEvE;;;;;GAKG;AACH,MAAM,qBAAqB,GAAG;;;;;;;;gOAQkM,CAAC;AAEjO;;;;;;;;;;GAUG;AACH,MAAM,yBAAyB,GAAG;;;;;;;kNAOgL,CAAC;AAEnN;;;;;;;;;;;;;GAaG;AACH,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;gQAuBmO,CAAC;AAEjQ;;;;;;;;;;;;;GAaG;AACH,MAAM,gCAAgC,GAAG;;;;;;;;;;yWAUgU,CAAC;AAE1W;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,6BAA6B,GAAG;;;;;;;;0bAQoZ,CAAC;AAE3b;;;;;;GAMG;AACH,MAAM,0BAA0B,GAAG;;;;;;;;;;;;;;;;;;;;;;;ybAuBsZ,CAAC;AAQ1b,MAAM,YAAY,GAAa;IAC7B,IAAI,EAAE,cAAc;IACpB,WAAW,EACT,mSAAmS;IACrS,KAAK,EAAE;QACL;YACE,IAAI,EAAE,aAAa;YACnB,aAAa,EAAE,IAAI;YACnB,iBAAiB,EACf,oNAAoN;YACtN,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gxBA8BovB,yBAAyB,GAAG,oBAAoB,GAAG,gCAAgC,GAAG,0BAA0B,EAAE;SAC73B;QACD;YACE,IAAI,EAAE,SAAS;YACf,UAAU,EAAE,IAAI;YAChB,iBAAiB,EAAE,2FAA2F;YAC9G,oBAAoB,EAAE;;;;;;;;;;;2HAW+F,qBAAqB,EAAE;SAC7I;QACD;YACE,IAAI,EAAE,eAAe;YACrB,iBAAiB,EAAE,iJAAiJ;YACpK,oBAAoB,EAAE;;;;;;;;;;;0GAW8E,6BAA6B,GAAG,qBAAqB,EAAE;SAC5J;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,6FAA6F;YAChH,oBAAoB,EAAE;;;;;;;;;;kNAUsL,qBAAqB,EAAE;SACpO;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,+EAA+E;YAClG,oBAAoB,EAAE;;;;;;;;4KAQgJ,qBAAqB,EAAE;SAC9L;QACD;YACE,IAAI,EAAE,iBAAiB;YACvB,iBAAiB,EAAE,kMAAkM;YACrN,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;oHAyBwF,qBAAqB,EAAE;SACtI;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,qIAAqI;YACxJ,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;qHAyByF,qBAAqB,EAAE;SACvI;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,iBAAiB,EAAE,8KAA8K;YACjM,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;gRAuBoP,qBAAqB,EAAE;SAClS;KACF;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,SAAS,GAA6B;IACjD,cAAc,EAAE,YAAY;CAC7B,CAAC;AAEF,MAAM,UAAU,WAAW,CAAC,IAAY;IACtC,OAAO,SAAS,CAAC,IAAI,CAAC,IAAI,IAAI,CAAC;AACjC,CAAC;AAED,MAAM,UAAU,iBAAiB;IAC/B,OAAO,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;AAChC,CAAC"}
+{"version":3,"file":"templates.js","sourceRoot":"","sources":["../src/templates.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAeH,uEAAuE;AACvE,oEAAoE;AACpE,+DAA+D;AAC/D,iEAAiE;AACjE,oEAAoE;AACpE,mEAAmE;AACnE,mEAAmE;AACnE,qEAAqE;AACrE,gCAAgC;AAChC,uEAAuE;AAEvE;;;;;GAKG;AACH,MAAM,qBAAqB,GAAG;;;;;;;;gOAQkM,CAAC;AAEjO;;;;;;;;;;GAUG;AACH,MAAM,yBAAyB,GAAG;;;;;;;kNAOgL,CAAC;AAEnN;;;;;;;;;;;;;GAaG;AACH,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;gQAuBmO,CAAC;AAEjQ;;;;;;;;;;;;;GAaG;AACH,MAAM,gCAAgC,GAAG;;;;;;;;;;yWAUgU,CAAC;AAE1W;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,6BAA6B,GAAG;;;;;;;;0bAQoZ,CAAC;AAE3b;;;;;;GAMG;AACH,MAAM,0BAA0B,GAAG;;;;;;;;;;;;;;;;;;;;;;;ybAuBsZ,CAAC;AAE1b;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,kCAAkC,GAAG;;;;;;;;;oYASyV,CAAC;AAErY,MAAM,sCAAsC,GAAG;;;;;;;;;;mmBAUojB,CAAC;AAEpmB;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,sBAAsB,GAAG;;;;;;+UAMgT,CAAC;AAQhV,MAAM,YAAY,GAAa;IAC7B,IAAI,EAAE,cAAc;IACpB,WAAW,EACT,mSAAmS;IACrS,KAAK,EAAE;QACL;YACE,IAAI,EAAE,aAAa;YACnB,aAAa,EAAE,IAAI;YACnB,iBAAiB,EACf,oNAAoN;YACtN,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gxBAqCovB,yBAAyB,GAAG,oBAAoB,GAAG,gCAAgC,GAAG,0BAA0B,GAAG,sCAAsC,GAAG,sBAAsB,EAAE;SAC/7B;QACD;YACE,IAAI,EAAE,SAAS;YACf,UAAU,EAAE,IAAI;YAChB,iBAAiB,EAAE,2FAA2F;YAC9G,oBAAoB,EAAE;;;;;;;;;;;2HAW+F,qBAAqB,GAAG,kCAAkC,EAAE;SAClL;QACD;YACE,IAAI,EAAE,eAAe;YACrB,iBAAiB,EAAE,iJAAiJ;YACpK,oBAAoB,EAAE;;;;;;;;;;;0GAW8E,6BAA6B,GAAG,qBAAqB,EAAE;SAC5J;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,6FAA6F;YAChH,oBAAoB,EAAE;;;;;;;;;;kNAUsL,qBAAqB,EAAE;SACpO;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,+EAA+E;YAClG,oBAAoB,EAAE;;;;;;;;4KAQgJ,qBAAqB,EAAE;SAC9L;QACD;YACE,IAAI,EAAE,iBAAiB;YACvB,iBAAiB,EAAE,kMAAkM;YACrN,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;oHAyBwF,qBAAqB,EAAE;SACtI;QACD;YACE,IAAI,EAAE,WAAW;YACjB,iBAAiB,EAAE,qIAAqI;YACxJ,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;qHAyByF,qBAAqB,EAAE;SACvI;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,iBAAiB,EAAE,8KAA8K;YACjM,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;;;;;;gRAuBoP,qBAAqB,EAAE;SAClS;KACF;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,SAAS,GAA6B;IACjD,cAAc,EAAE,YAAY;CAC7B,CAAC;AAEF,MAAM,UAAU,WAAW,CAAC,IAAY;IACtC,OAAO,SAAS,CAAC,IAAI,CAAC,IAAI,IAAI,CAAC;AACjC,CAAC;AAED,MAAM,UAAU,iBAAiB;IAC/B,OAAO,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;AAChC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "borgmcp",
-  "version": "0.8.14",
+  "version": "0.8.20",
   "description": "Multi-agent coordination for Claude Code — cubes, drones, and a shared activity log.",
   "type": "module",
   "main": "dist/index.js",
@@ -9,7 +9,8 @@
     "borg-setup": "dist/setup.js",
     "borg-mcp": "dist/index.js",
     "borg-regen": "dist/regen.js",
-    "borg-log-audit": "dist/log-audit.js"
+    "borg-log-audit": "dist/log-audit.js",
+    "borg-inbox-monitor": "dist/inbox-monitor.js"
   },
   "scripts": {
     "prebuild": "rm -rf dist",