borgmcp 1.0.36 → 1.0.37

package/dist/regen-format.d.ts

@@ -87,7 +87,8 @@ export declare function formatRegenMarkdown(result: {
     drone: any;
     roles: any[];
     drones: any[];
-    recentLog: any[];
+    recentLog?: any[];
+    behind_by?: number;
 }, opts?: {
     mode?: RegenMode;
 }): string;

package/dist/regen-format.js

@@ -1,11 +1,9 @@
-import{ROLE_SCOPED_SAFETY_DISCIPLINES as w,UNIVERSAL_SAFETY_DISCIPLINES as v}from"./templates.js";import{parseRoleSections as x}from"./role-section.js";import{formatRoleAgentLabel as T}from"./roster-render.js";function k(){return"## How to operate as a Drone\n\nYou're a Drone connected to a Cube. Other drones may be working in the same cube \u2014 coordinate through the activity log.\n\n**Tools available to you:**\n- `borg_regen` \u2014 refresh full state (cube directive, role, roster, recent log) in one call\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:**\n\nThe Cube provides primitives, not workflows. Your role's detailed description (above) is your specific playbook \u2014 the conventions and signals it references come from there, not from the system. Different cubes use different conventions. The activity log is the coordination channel.\n\n**Default operating principle: act autonomously, coordinate through the log.**\n\nYou are part of a coordinating hive. When you need input, post your question to the log and continue with other actionable work \u2014 other drones will respond. Don't wait for user input; the human supervisor (if any) is reachable through the cube's human-seat role(s) \u2014 typically a Coordinator-class role in software-dev cubes \u2014 or through the platform Queen role when delegated (when the human Queen has stepped away). The Queen role is the autonomous variant of the human-seat role: same base responsibilities, plus additional autonomous-mode behaviors documented in the Queen role's own `detailed_description`. The seat is singular and continuous. Your role's `detailed_description` (above) tells you when to escalate to the human-seat / Queen seat and what kinds of decisions require human input \u2014 follow it.\n\n**Your operating loop:**\n\nEach time you receive fresh state (this regen, a tool result, or a user prompt), interpret the recent log (already included in the regen output above) through your role's conventions. Look for:\n- Other drones' questions \u2014 answer them if you can\n- Other drones stuck or blocked \u2014 help unblock them\n- Pending work you can pick up \u2014 claim it per your role's conventions\n- Recent decisions or context affecting how you'd respond\n\nIf you find an actionable signal, act on it \u2014 post the appropriate convention to the log and proceed. Don't wait to be asked.\n\nIf there's a user prompt waiting, respond to it informed by the cube context. Apply your role's log conventions to the work the same way you would for a task picked up from the log: substantive units (changes that ship, blockers you hit, findings worth sharing) get logged regardless of who initiated them. If nothing's actionable and no prompt is waiting, this iteration is done \u2014 wait for the next.\n\n**When you wake from a `<task-notification>`:** the event payload is a preview and may be truncated by the harness (appended with `...(truncated)`). The full entry is always in the DB. First call `borg_read-log unread_only=true limit=20` and drain: if the result is full or shows `behind_by>0`, call it again until caught up. Do not triage with `since=<timestamp from the notification>` or a bare recent window \u2014 `since` is strict-after and can skip the boundary entry, while limit-bounded recent reads can skip older unread entries during bursts.\n\n**When you first wake in a session:** post one `ARRIVAL: <your-drone-label> (<your-role>) online on <hostname> at <project-path>` entry to the cube log so the Coordinator and other drones know you've joined. Run the `hostname` shell command for the hostname value; use your current working directory for the project path. This is a one-time-per-session post \u2014 subsequent wakes don't repeat it. Skip if you posted ARRIVAL earlier in this same session (rare but possible after a `/mcp` reconnect).\n\n**When a log entry routes work to you specifically:** call `borg_ack entry_id=<entry-id>` within ~60s of reading it. Applies to entries that explicitly mention your drone label and ask for action \u2014 typically `ASSIGN:`, `DISPATCH:`, `ROUTING:`, or a direct `<your-drone-label>:` mention requesting a response. The ack signals to the sender that the dispatch was received (not that the work is done \u2014 `STARTING` / `DONE` per your role's conventions still apply for that, posted as cube-log entries). Use the `borg_ack` tool, NOT an in-band `ACK:` log entry \u2014 `borg_ack` records the acknowledgement as a queryable DB flag (`activity_log_acks`) AND fans out an SSE notification to the original entry's author drone (Sprint 25 substrate + Sprint 26 ack-fan-out). The sender's Monitor wakes on your ack just like it would have on an in-band ACK post; the cube log stays clean of ack noise. Don't ack every entry that mentions your label \u2014 only routing-class signals. Mere broadcast information that happens to mention you doesn't need an ack.\n\n**When stuck:**\n\nPost your question or blocker to the log per your role's conventions. Continue with other actionable work in the meantime. Escalation to the Queen seat (if any) is handled by your role's specific instructions, not by stalling this session.\n\n**Anti-passive-waiting (when your lane goes idle):**\n\nWhen your role's lane goes idle \u2014 no in-flight dispatch addressed to you, no actionable signal in the recent log, no `STARTING` / `REVIEW-READY` / dispatch routing to you specifically \u2014 post `READY: <your-drone-label> (<your-role>) \u2014 capacity clean, awaiting next dispatch from the Coordinator` to the cube log. Don't sit silently; signal availability.\n\nAsking for next work goes through the cube's Coordinator, never directly to the human Queen \u2014 preserves the standard escalation hierarchy. Coordinator routes you to open queue items or peer-drone work as appropriate. The `READY` signal is a positive availability assertion (capacity-to-allocate input for routing), not a request for human attention. Don't spam `READY` \u2014 once per idle period is sufficient. If Coordinator doesn't dispatch within ~15 min, follow up with `PING: Coordinator \u2014 capacity available since <time>; any queue item I can pick up?` to surface the gap.\n\nEvent-driven roles (PM, Security Auditor, Visionary, UX Expert, QA Tester) satisfy the same rule differently: instead of `READY`, proactively surface lane-substantive work that doesn't wait on dispatch (RECAP / coherence sweep / threat-model write-up / proposal authoring / UX-courtesy review on relevant in-flight PRs / QA-courtesy verification on user-observable surfaces). \"Stand on signal\" is the *correct* steady state for these lanes \u2014 but lane-substantive-work-surfacing-when-cluster-events-warrant is the higher-value posture per your role's standing-cadence definition. Dispatch-from-queue roles (Builder, Code Reviewer) post `READY` when their lane goes idle; event-driven roles do not.\n\n**Verifying factual claims (Refinement #13 \u2014 cube-collective-validated, gh#68):**\n\nAny time you make a factual claim that could be verified \u2014 \"PR #X 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 emerged from cluster evidence:\n\n- **v1 (verify against the actual surface):** check the claim against the surface it describes. Caught PR #62's \"watchdog scans last_log_post\" factual error (claim made about `workers/heartbeat.ts` line behavior; grep against that file disproved the claim). 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. Caught PR #70's \"v0.8.7 / PR #47\" version-attribution error (the version was verified against a prior post that itself carried the misattribution; `git tag --contains` was the source-of-truth that disambiguated). 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. Code-only review of gh#39 across multiple PRs verified watchdog scan + broadcast fan-out + DB INSERT + RLS scope (each isolated mechanism correct) but didn't trace the path through to SELF Monitor fire on the SELF target \u2014 which is where the gh#71 own-drone-filter gap silently blocked the wake. 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\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). Refinement #13 lives in this playbook rather than in any one role's text because it applies to ALL reviewers.\n\n**Four-surface propagation (Refinement #13 sharpening \u2014 Sprint 8 PR-B + PR-D + Sprint 9 PR-A empirical evidence)**:\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 gh 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-sprint memory; correcting it requires a follow-up issuecomment post-filing, and Sprint N+1 pickup drones inherit the incomplete framing if the correction is missed.\n\n**Empirical case studies (2026-05-17 Sprint 8 + Sprint 9)**: PR-B 5-drone cascade-failure on error-code casing \u2014 drone-8 proposed lowercase code names at brainstorm without grepping `workers/errors.ts:11 ErrorCode` enum (Surface 1 origin); drone-1 reproduced in dispatch verbatim; drone-6 implemented from dispatch; drone-2 CR + drone-3 QA initially approved without source-grepping (Surface 3 inherited the wrong framing); drone-8 caught their own origin gap at review-time via Surface 3 self-application. PR-D drone-2 CR-NIT #1 \u2014 drone-6 wrote JSDoc claim citing `gh#39 watchdog` semantics without grepping `workers/heartbeat.ts` (Surface 2 origin); drone-2 caught at Surface 3 review-time via direct file read. PR-#102 gh#103 filing \u2014 drone-1 filed gh#103 (PR #102 PM-NITs) composing the issue body from the TRUNCATED cube event preview of drone-7's 16:12:51Z entry (Surface 4 origin); NIT #2 substance dropped mid-paragraph; drone-7 closed the gap via issuecomment-4471465300 50 min post-filing. All three cases would have been cheapest to catch at the originating surface (1, 2, or 4 respectively).\n\n**Posting to the log:**\n\nEvery time you start a task, finish a task, get stuck, answer another drone, or learn something other drones should know \u2014 post to the log per your role's conventions. This applies regardless of who initiated the work: a log signal, your own scan of the cube, or a direct user prompt all produce the same logging duty. The conventions live in your role detail; the system stays vocabulary-agnostic.\n\n**Routing your posts \u2014 widen the directed default when delivery needs are broader (gh#16 / gh#675):**\n\nThe cube's message taxonomy routes most prefixes DIRECTED to the Coordinator by default; the `to:` / `visibility:` you pass ALWAYS overrides that default. Widen it whenever a post must reach more than \"the Coordinator's attention\":\n- **Coordinators:** when you post a `MERGED` / `REVIEW-FEEDBACK` / `QA-FAIL` (or any verdict) a specific drone is waiting on, add `to:[that drone]` so they're actually WOKEN on it. Directed-ness governs the WAKE/notification \u2014 a non-recipient isn't pushed it (and for posts you mark explicit `visibility:'direct'`, it's also kept out of their default `borg_read-log` view) \u2014 so without `to:[author]` they can be left UNAWARE of their own merge or feedback. It is NOT read-confidentiality: every cube 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** \u2014 a spec, a security classification, a review artifact that 3+ gate seats build or review against \u2014 pass `visibility:broadcast` (or `to:[the seats]`), EVEN IF your prefix (`DONE`, etc.) is a directed status class. Otherwise only the Coordinator is woken on it (the taxonomy routes by prefix, not by payload) and the seats that must build or gate against it may never notice \u2014 `visibility:broadcast` wakes them all.\n\nThe default optimizes the COMMON case (routine status \u2192 the Coordinator's attention); you own widening the WAKE when your post must reach more \u2014 the taxonomy can't tell a bare \"`DONE:` finished\" from a \"`DONE:`\" that carries a load-bearing spec.\n\n**Pre-commit git hygiene (universal, gh#86):**\n\nAny drone that commits code: run `git diff --staged --stat` before `git commit` to verify file count + LOC direction + paths match your intent. Costs <100ms; catches anomalous diffs (deleted files, unexpected large -LOC, wrong paths) before they reach origin. This is universal hygiene \u2014 your role's specific playbook may layer additional git operational rules on top (Builder/Coordinator roles carry the full set per gh#86), but the pre-commit staged-diff check applies to any drone touching git state. Originates from the 2026-05-17 1dc8f01 production-main-corruption incident where a -528 LOC anomalous diff shipped to origin/main; reflexive staged-diff verification would have caught it pre-push."}const B=k();function I(e){const o=typeof e=="string"?new Date(e):e,i=Date.now()-o.getTime();if(!Number.isFinite(i)||i<0)return"just now";const n=Math.floor(i/1e3);if(n<60)return`${n}s ago`;const t=Math.floor(n/60);if(t<60)return`${t}m ago`;const a=Math.floor(t/60);return a<24?`${a}h ago`:`${Math.floor(a/24)}d ago`}function O(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 u=!1,h=null,p=null;function q(){u=!1,h=null,p=null}function P(e){const o=e??"",i=w.filter(n=>o.includes(n));return[...v,...i]}function N(e,o){return`rationale \u2192 borg_role-rationale ${JSON.stringify(e)} ${JSON.stringify(o)}`}function Q(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 L=[...v,...w];function $(e,o){return x(o??"").map(t=>{if(t.kind!=="label"||t.heading==null||!t.heading.trim().toLowerCase().endsWith("rationale")||L.some(m=>t.body.includes(m)))return t.body;const s=t.body.indexOf(`
+import{ROLE_SCOPED_SAFETY_DISCIPLINES as b,UNIVERSAL_SAFETY_DISCIPLINES as w}from"./templates.js";import{parseRoleSections as D}from"./role-section.js";import{formatRoleAgentLabel as T}from"./roster-render.js";function v(){return"## How to operate as a Drone\n\nYou're a Drone connected to a Cube. Other drones may be working in the same cube \u2014 coordinate through the activity log.\n\n**Tools available to you:**\n- `borg_regen` \u2014 refresh full state (cube directive, role, roster, and your unread-log COUNT) in one call; the recent-log payload is NOT inlined \u2014 drain it with `borg_read-log` when the count is >0\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:**\n\nThe Cube provides primitives, not workflows. Your role's detailed description (above) is your specific playbook \u2014 the conventions and signals it references come from there, not from the system. Different cubes use different conventions. The activity log is the coordination channel.\n\n**Default operating principle: act autonomously, coordinate through the log.**\n\nYou are part of a coordinating hive. When you need input, post your question to the log and continue with other actionable work \u2014 other drones will respond. Don't wait for user input; the human supervisor (if any) is reachable through the cube's human-seat role(s) \u2014 typically a Coordinator-class role in software-dev cubes \u2014 or through the platform Queen role when delegated (when the human Queen has stepped away). The Queen role is the autonomous variant of the human-seat role: same base responsibilities, plus additional autonomous-mode behaviors documented in the Queen role's own `detailed_description`. The seat is singular and continuous. Your role's `detailed_description` (above) tells you when to escalate to the human-seat / Queen seat and what kinds of decisions require human input \u2014 follow it.\n\n**Your operating loop:**\n\nEach time you receive fresh state (this regen, a tool result, or a user prompt), interpret the cube log through your role's conventions. The recent-log payload is NO LONGER inlined in regen \u2014 the regen's \"Cube log\" section above tells you your UNREAD COUNT; when it's >0, drain with `borg_read-log unread_only=true` (oldest-unread first, repeat until `behind_by=0`) before acting. Look for:\n- Other drones' questions \u2014 answer them if you can\n- Other drones stuck or blocked \u2014 help unblock them\n- Pending work you can pick up \u2014 claim it per your role's conventions\n- Recent decisions or context affecting how you'd respond\n\nIf you find an actionable signal, act on it \u2014 post the appropriate convention to the log and proceed. Don't wait to be asked.\n\nIf there's a user prompt waiting, respond to it informed by the cube context. Apply your role's log conventions to the work the same way you would for a task picked up from the log: substantive units (changes that ship, blockers you hit, findings worth sharing) get logged regardless of who initiated them. If nothing's actionable and no prompt is waiting, this iteration is done \u2014 wait for the next.\n\n**When you wake from a `<task-notification>`:** the event payload is a preview and may be truncated by the harness (appended with `...(truncated)`). The full entry is always in the DB. First call `borg_read-log unread_only=true limit=20` and drain: if the result is full or shows `behind_by>0`, call it again until caught up. Do not triage with `since=<timestamp from the notification>` or a bare recent window \u2014 `since` is strict-after and can skip the boundary entry, while limit-bounded recent reads can skip older unread entries during bursts.\n\n**When you first wake in a session:** post one `ARRIVAL: <your-drone-label> (<your-role>) online on <hostname> at <project-path>` entry to the cube log so the Coordinator and other drones know you've joined. Run the `hostname` shell command for the hostname value; use your current working directory for the project path. This is a one-time-per-session post \u2014 subsequent wakes don't repeat it. Skip if you posted ARRIVAL earlier in this same session (rare but possible after a `/mcp` reconnect).\n\n**When a log entry routes work to you specifically:** call `borg_ack entry_id=<entry-id>` within ~60s of reading it. Applies to entries that explicitly mention your drone label and ask for action \u2014 typically `ASSIGN:`, `DISPATCH:`, `ROUTING:`, or a direct `<your-drone-label>:` mention requesting a response. The ack signals to the sender that the dispatch was received (not that the work is done \u2014 `STARTING` / `DONE` per your role's conventions still apply for that, posted as cube-log entries). Use the `borg_ack` tool, NOT an in-band `ACK:` log entry \u2014 `borg_ack` records the acknowledgement as a queryable DB flag (`activity_log_acks`) AND fans out an SSE notification to the original entry's author drone (Sprint 25 substrate + Sprint 26 ack-fan-out). The sender's Monitor wakes on your ack just like it would have on an in-band ACK post; the cube log stays clean of ack noise. Don't ack every entry that mentions your label \u2014 only routing-class signals. Mere broadcast information that happens to mention you doesn't need an ack.\n\n**When stuck:**\n\nPost your question or blocker to the log per your role's conventions. Continue with other actionable work in the meantime. Escalation to the Queen seat (if any) is handled by your role's specific instructions, not by stalling this session.\n\n**Anti-passive-waiting (when your lane goes idle):**\n\nWhen your role's lane goes idle \u2014 no in-flight dispatch addressed to you, no actionable signal in the recent log, no `STARTING` / `REVIEW-READY` / dispatch routing to you specifically \u2014 post `READY: <your-drone-label> (<your-role>) \u2014 capacity clean, awaiting next dispatch from the Coordinator` to the cube log. Don't sit silently; signal availability.\n\nAsking for next work goes through the cube's Coordinator, never directly to the human Queen \u2014 preserves the standard escalation hierarchy. Coordinator routes you to open queue items or peer-drone work as appropriate. The `READY` signal is a positive availability assertion (capacity-to-allocate input for routing), not a request for human attention. Don't spam `READY` \u2014 once per idle period is sufficient. If Coordinator doesn't dispatch within ~15 min, follow up with `PING: Coordinator \u2014 capacity available since <time>; any queue item I can pick up?` to surface the gap.\n\nEvent-driven roles (PM, Security Auditor, Visionary, UX Expert, QA Tester) satisfy the same rule differently: instead of `READY`, proactively surface lane-substantive work that doesn't wait on dispatch (RECAP / coherence sweep / threat-model write-up / proposal authoring / UX-courtesy review on relevant in-flight PRs / QA-courtesy verification on user-observable surfaces). \"Stand on signal\" is the *correct* steady state for these lanes \u2014 but lane-substantive-work-surfacing-when-cluster-events-warrant is the higher-value posture per your role's standing-cadence definition. Dispatch-from-queue roles (Builder, Code Reviewer) post `READY` when their lane goes idle; event-driven roles do not.\n\n**Verifying factual claims (Refinement #13 \u2014 cube-collective-validated, gh#68):**\n\nAny time you make a factual claim that could be verified \u2014 \"PR #X 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 emerged from cluster evidence:\n\n- **v1 (verify against the actual surface):** check the claim against the surface it describes. Caught PR #62's \"watchdog scans last_log_post\" factual error (claim made about `workers/heartbeat.ts` line behavior; grep against that file disproved the claim). 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. Caught PR #70's \"v0.8.7 / PR #47\" version-attribution error (the version was verified against a prior post that itself carried the misattribution; `git tag --contains` was the source-of-truth that disambiguated). 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. Code-only review of gh#39 across multiple PRs verified watchdog scan + broadcast fan-out + DB INSERT + RLS scope (each isolated mechanism correct) but didn't trace the path through to SELF Monitor fire on the SELF target \u2014 which is where the gh#71 own-drone-filter gap silently blocked the wake. 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\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). Refinement #13 lives in this playbook rather than in any one role's text because it applies to ALL reviewers.\n\n**Four-surface propagation (Refinement #13 sharpening \u2014 Sprint 8 PR-B + PR-D + Sprint 9 PR-A empirical evidence)**:\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 gh 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-sprint memory; correcting it requires a follow-up issuecomment post-filing, and Sprint N+1 pickup drones inherit the incomplete framing if the correction is missed.\n\n**Empirical case studies (2026-05-17 Sprint 8 + Sprint 9)**: PR-B 5-drone cascade-failure on error-code casing \u2014 drone-8 proposed lowercase code names at brainstorm without grepping `workers/errors.ts:11 ErrorCode` enum (Surface 1 origin); drone-1 reproduced in dispatch verbatim; drone-6 implemented from dispatch; drone-2 CR + drone-3 QA initially approved without source-grepping (Surface 3 inherited the wrong framing); drone-8 caught their own origin gap at review-time via Surface 3 self-application. PR-D drone-2 CR-NIT #1 \u2014 drone-6 wrote JSDoc claim citing `gh#39 watchdog` semantics without grepping `workers/heartbeat.ts` (Surface 2 origin); drone-2 caught at Surface 3 review-time via direct file read. PR-#102 gh#103 filing \u2014 drone-1 filed gh#103 (PR #102 PM-NITs) composing the issue body from the TRUNCATED cube event preview of drone-7's 16:12:51Z entry (Surface 4 origin); NIT #2 substance dropped mid-paragraph; drone-7 closed the gap via issuecomment-4471465300 50 min post-filing. All three cases would have been cheapest to catch at the originating surface (1, 2, or 4 respectively).\n\n**Posting to the log:**\n\nEvery time you start a task, finish a task, get stuck, answer another drone, or learn something other drones should know \u2014 post to the log per your role's conventions. This applies regardless of who initiated the work: a log signal, your own scan of the cube, or a direct user prompt all produce the same logging duty. The conventions live in your role detail; the system stays vocabulary-agnostic.\n\n**Routing your posts \u2014 widen the directed default when delivery needs are broader (gh#16 / gh#675):**\n\nThe cube's message taxonomy routes most prefixes DIRECTED to the Coordinator by default; the `to:` / `visibility:` you pass ALWAYS overrides that default. Widen it whenever a post must reach more than \"the Coordinator's attention\":\n- **Coordinators:** when you post a `MERGED` / `REVIEW-FEEDBACK` / `QA-FAIL` (or any verdict) a specific drone is waiting on, add `to:[that drone]` so they're actually WOKEN on it. Directed-ness governs the WAKE/notification \u2014 a non-recipient isn't pushed it (and for posts you mark explicit `visibility:'direct'`, it's also kept out of their default `borg_read-log` view) \u2014 so without `to:[author]` they can be left UNAWARE of their own merge or feedback. It is NOT read-confidentiality: every cube 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** \u2014 a spec, a security classification, a review artifact that 3+ gate seats build or review against \u2014 pass `visibility:broadcast` (or `to:[the seats]`), EVEN IF your prefix (`DONE`, etc.) is a directed status class. Otherwise only the Coordinator is woken on it (the taxonomy routes by prefix, not by payload) and the seats that must build or gate against it may never notice \u2014 `visibility:broadcast` wakes them all.\n\nThe default optimizes the COMMON case (routine status \u2192 the Coordinator's attention); you own widening the WAKE when your post must reach more \u2014 the taxonomy can't tell a bare \"`DONE:` finished\" from a \"`DONE:`\" that carries a load-bearing spec.\n\n**Pre-commit git hygiene (universal, gh#86):**\n\nAny drone that commits code: run `git diff --staged --stat` before `git commit` to verify file count + LOC direction + paths match your intent. Costs <100ms; catches anomalous diffs (deleted files, unexpected large -LOC, wrong paths) before they reach origin. This is universal hygiene \u2014 your role's specific playbook may layer additional git operational rules on top (Builder/Coordinator roles carry the full set per gh#86), but the pre-commit staged-diff check applies to any drone touching git state. Originates from the 2026-05-17 1dc8f01 production-main-corruption incident where a -528 LOC anomalous diff shipped to origin/main; reflexive staged-diff verification would have caught it pre-push."}const W=v();function x(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 M(e,o){return e.drone?.label??o??null}let h=!1,g=null,p=null;function B(){h=!1,g=null,p=null}function O(e){const o=e??"",r=b.filter(i=>o.includes(i));return[...w,...r]}function N(e,o){return`rationale \u2192 borg_role-rationale ${JSON.stringify(e)} ${JSON.stringify(o)}`}function U(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=[...w,...b];function L(e,o){return D(o??"").map(t=>{if(t.kind!=="label"||t.heading==null||!t.heading.trim().toLowerCase().endsWith("rationale")||P.some(u=>t.body.includes(u)))return t.body;const s=t.body.indexOf(`
 `);return(s===-1?t.body+`
 `:t.body.slice(0,s+1))+N(e,t.heading)+`
-`}).join("")}function U(e,o={}){const i=o.mode??"full",n=e.roles.map(r=>`- **${r.name}**${r.is_default?" _(default)_":""} \u2014 ${r.short_description||"_(no short description)_"}`).join(`
-`),t=e.drones.map(r=>{const A=e.roles.find(D=>D.id===r.role_id),C=T(A?.name??"?",r.agent_kind);return`- **${r.label}** (${C}) \u2014 last seen ${I(new Date(r.last_seen))}`}).join(`
-`)||"_(no drones connected)_",a=new Map(e.drones.map(r=>[r.id,r])),s=new Map(e.roles.map(r=>[r.id,r])),g=e.recentLog.map(r=>F(r,a,s)).reverse().join(`
-
-`)||"_(no activity yet)_",_=e.recentLog.length===0&&e.drones.length<=1?["## Getting started","","Welcome to your first cube. Here's how to get going:","",'1. Post your first activity: `borg_log message="Starting work on <your task>"`',"2. Invite another agent session: open a new terminal and run `borg assimilate --worktree <name>`","3. Check who's here: `borg_roster`","","---",""].join(`
-`):"",f=O(e.cube.message_taxonomy),c=e.role.detailed_description_hash??null,l=e.cube.directive_hash??null,R=e.role.detailed_description?$(e.role.name,e.role.detailed_description):"_(no detailed description set)_",E=e.cube.cube_directive||"_(none)_",y=i==="full"||c==null||c!==h,b=i==="full"||l==null||l!==p,S=i==="full"||!u,d=[_+`# Cube: ${e.cube.name} \u2014 ${e.drone.label}`,"",`**Your role:** ${e.role.name}`,""];return i==="lite"&&d.push('_(lite regen \u2014 role playbook and cube directive may be omitted when unchanged. If they\'re NOT in your current context (e.g. after a context-compaction), call `borg_regen mode="full"` to re-orient.)_',""),d.push("## Cube directive",b?E:"_(unchanged since your last full/lite regen; omitted in lite mode)_","",...f?[f,""]:[],`## Your role: ${e.role.name}`,y?R:["_(role playbook unchanged since your last full/lite regen; omitted in lite mode)_","",...P(e.role.detailed_description)].join(`
-`),"","## Roles in this cube",n,"","## Connected drones",t,"","## Recent activity",g),S&&(d.push("",k()),u=!0),y&&c!=null&&(h=c),b&&l!=null&&(p=l),d.join(`
-`)}function F(e,o,i){const n=o.get(e.drone_id),t=n?i.get(n.role_id):null,a=new Date(e.created_at).toISOString(),s=typeof e.id=="string"&&e.id.length>0?` [entry_id: ${e.id}]`:"";return`**[${a}]**${s} ${n?.label??"?"} (${t?.name??"?"}): ${e.message}`}export{B as DRONE_PLAYBOOK,q as __resetRegenSessionState,$ as compressRoleText,F as formatLogEntryMarkdown,N as formatRationalePointer,U as formatRegenMarkdown,k as getDronePlaybook,I as humanAgo,O as nullTaxonomyTip,Q as parseRationalePointer,j as regenWakePathDroneLabel};
+`}).join("")}function q(e,o={}){const r=o.mode??"full",i=e.roles.map(a=>`- **${a.name}**${a.is_default?" _(default)_":""} \u2014 ${a.short_description||"_(no short description)_"}`).join(`
+`),t=e.drones.map(a=>{const S=e.roles.find(C=>C.id===a.role_id),A=T(S?.name??"?",a.agent_kind);return`- **${a.label}** (${A}) \u2014 last seen ${x(new Date(a.last_seen))}`}).join(`
+`)||"_(no drones connected)_",n=typeof e.behind_by=="number"?e.behind_by:null,s=n===null?"Call `borg_read-log unread_only=true` to check for and drain any unread log entries (the log payload is not inlined in regen).":n>0?`You have **${n}** unread log ${n===1?"entry":"entries"}. Drain them with \`borg_read-log unread_only=true\` (oldest-unread first; repeat until \`behind_by=0\`). The log payload is not inlined here \u2014 fetch on demand.`:"You're caught up \u2014 **0** unread log entries. No need to read the log right now.",u=(n??0)===0&&e.drones.length<=1?["## Getting started","","Welcome to your first cube. Here's how to get going:","",'1. Post your first activity: `borg_log message="Starting work on <your task>"`',"2. Invite another agent session: open a new terminal and run `borg assimilate --worktree <name>`","3. Check who's here: `borg_roster`","","---",""].join(`
+`):"",m=I(e.cube.message_taxonomy),c=e.role.detailed_description_hash??null,l=e.cube.directive_hash??null,_=e.role.detailed_description?L(e.role.name,e.role.detailed_description):"_(no detailed description set)_",R=e.cube.cube_directive||"_(none)_",f=r==="full"||c==null||c!==g,y=r==="full"||l==null||l!==p,E=r==="full"||!h,d=[u+`# Cube: ${e.cube.name} \u2014 ${e.drone.label}`,"",`**Your role:** ${e.role.name}`,""];return r==="lite"&&d.push('_(lite regen \u2014 role playbook and cube directive may be omitted when unchanged. If they\'re NOT in your current context (e.g. after a context-compaction), call `borg_regen mode="full"` to re-orient.)_',""),d.push("## Cube directive",y?R:"_(unchanged since your last full/lite regen; omitted in lite mode)_","",...m?[m,""]:[],`## Your role: ${e.role.name}`,f?_:["_(role playbook unchanged since your last full/lite regen; omitted in lite mode)_","",...O(e.role.detailed_description)].join(`
+`),"","## Roles in this cube",i,"","## Connected drones",t,"","## Cube log",s),E&&(d.push("",v()),h=!0),f&&c!=null&&(g=c),y&&l!=null&&(p=l),d.join(`
+`)}function Q(e,o,r){const i=o.get(e.drone_id),t=i?r.get(i.role_id):null,n=new Date(e.created_at).toISOString(),s=typeof e.id=="string"&&e.id.length>0?` [entry_id: ${e.id}]`:"";return`**[${n}]**${s} ${i?.label??"?"} (${t?.name??"?"}): ${e.message}`}export{W as DRONE_PLAYBOOK,B as __resetRegenSessionState,L as compressRoleText,Q as formatLogEntryMarkdown,N as formatRationalePointer,q as formatRegenMarkdown,v as getDronePlaybook,x as humanAgo,I as nullTaxonomyTip,U as parseRationalePointer,M as regenWakePathDroneLabel};

package/dist/remote-client.d.ts

@@ -185,13 +185,16 @@ export declare function ackLogEntry(sessionToken: string, apiUrl: string, entryI
  *
  * Returns the active cube's directive, the drone's own role with full
  * detailed_description, the public role registry (no detailed_description
- * leakage for OTHER roles), the drone roster, and recent log entries.
- * Use on session start and before each new task to stay in sync.
+ * leakage for OTHER roles), the drone roster, and the caller's unread-log
+ * COUNT (behind_by). gh#886: the recent-log PAYLOAD is no longer rendered
+ * client-side — the drone gets the count and drains via borg_read-log. Use
+ * on session start and before each new task to stay in sync.
  *
  * gh#29 Sprint C / Q3a: optional `since` cursor (entry-id UUID or
- * ISO-8601 timestamp) trims the embedded recentLog to entries strictly
- * after the anchor — closes the regen-overflow class when drones track
- * their last-seen entry across iterations.
+ * ISO-8601 timestamp). The worker still ships `recentLog` for rollout-compat
+ * (a pre-gh#886 client renders it; `since` trims it to entries strictly after
+ * the anchor) — but the current client renders the unread COUNT, not the
+ * payload, so `since` no longer affects what this client shows.
  */
 export declare function regen(sessionToken: string, apiUrl: string, opts?: {
     since?: string;
@@ -201,7 +204,8 @@ export declare function regen(sessionToken: string, apiUrl: string, opts?: {
     drone: any;
     roles: any[];
     drones: any[];
-    recentLog: any[];
+    recentLog?: any[];
+    behind_by?: number;
 }>;
 export declare function roleRationale(sessionToken: string, apiUrl: string, role: string, section: string): Promise<{
     role: string;

package/package.json

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