@tablation/crew 0.53.4 → 0.53.6

package/dist/cli.js

@@ -6475,11 +6475,16 @@ function materializeBranchForTicket(dir, cfg, t, role, onProblem) {
 import { writeFileSync as writeFileSync7 } from "fs";
 import { join as join11 } from "path";
 
+// src/callout.ts
+var calloutHeader = (kind, label) => `> [!${kind}]
+> **Crew** \u2014 ${label}`;
+var calloutLabelLine = (label) => `> **Crew** \u2014 ${label}`;
+
 // src/stalled.ts
 var STALLED_AFTER_CYCLES = 30;
 var CYCLE_MS = 120 * 1e3;
 var STALLED_AFTER_MS = STALLED_AFTER_CYCLES * CYCLE_MS;
-var STALLED_MARKER = "<!-- crew:stalled -->";
+var STALLED_MARKER = calloutHeader("WARNING", "Stalled");
 var stalledKey = (issueId) => `stalled:${issueId}`;
 var ms = (iso) => {
   const n = iso ? Date.parse(iso) : NaN;
@@ -6501,7 +6506,7 @@ function planStalled(tickets, comments, ships, contract, holds2 = /* @__PURE__ *
     const lastMarker = Math.max(0, ...events.filter((e) => e.record_id === t.id && e.event_type === "stalled").map((e) => ms(e.occurred_at ?? e.created_at ?? "")));
     const lastActivityAt = Math.max(
       ms(t.updated_at),
-      ...mine.filter((c) => !(c.body ?? "").includes(STALLED_MARKER)).map((c) => ms(c.created_at))
+      ...mine.filter((c) => !(c.body ?? "").includes(calloutLabelLine("Stalled"))).map((c) => ms(c.created_at))
     );
     if (now - lastActivityAt < STALLED_AFTER_MS) continue;
     if (ships.some((s) => s.engaged && s.engaged_ticket_id === t.id)) continue;
@@ -6518,6 +6523,7 @@ function stalledComment(s, ships, now = Date.now()) {
   const mins = Math.round((now - s.lastActivityAt) / 6e4);
   const who2 = s.holderShipId ? `Held by ${shipName(ships, s.holderShipId)}, which is not engaged on it. That ship has an attention item open; the ticket is otherwise left as it is, and resumes the moment the ship picks it back up.` : `No ship holds it and none is engaged on it. It is waiting for the next ship that polls its lane; its status and assignee are left as they are.`;
   return `${STALLED_MARKER}
+
 **Stalled \u2014 no activity on \`${s.ticket.issue_id}\` for ${mins} minutes (\`${s.ticket.status}\`).**
 
 ${who2}`;
@@ -6917,7 +6923,7 @@ async function resolveTopCandidate(tracker, candidates, seat, approvedStatus, bu
 
 // src/conflict.ts
 import { StaleWriteError as StaleWriteError5 } from "@tablation/client";
-var BOUNCE_MARKER = "<!-- crew:merge-conflict -->";
+var BOUNCE_MARKER = calloutHeader("WARNING", "Merge Conflict");
 function worktreeForBranch(cwd, branch) {
   for (const w of worktrees(cwd)) {
     if (w.branch === branch && !w.prunable) return w.path;
@@ -6965,6 +6971,7 @@ function refreshBranch(worktree, base) {
 function handBackComment(b, merged) {
   const list = b.paths.length ? b.paths.map((p) => `\`${p}\``).join(", ") : "files this branch and the base both changed";
   return `${BOUNCE_MARKER}
+
 **Back with the dev lane \u2014 this branch no longer merges.**
 
 \`${b.branch}\` was verified, but squash-merging it into \`${b.base}\` conflicts in ${list}. Work that landed on \`${b.base}\` after this branch was cut has changed the same lines.
@@ -6975,6 +6982,7 @@ Nothing was written to \`${b.base}\`: the failed merge was rewound, and the rest
 }
 function escalateComment(b) {
   return `${BOUNCE_MARKER}
+
 **Conflicting again after a hand-back \u2014 stopping rather than looping.**
 
 \`${b.branch}\` was handed back once for a merge conflict, verified again, and conflicts against \`${b.base}\` a second time${b.paths.length ? ` (${b.paths.map((p) => `\`${p}\``).join(", ")})` : ""}.
@@ -7050,7 +7058,7 @@ async function applyConflictBounce(writer, b, contract, memberId, log, dryRun) {
 
 // src/build-failure.ts
 import { StaleWriteError as StaleWriteError6 } from "@tablation/client";
-var BUILD_FAILURE_MARKER = "<!-- crew:build-failure -->";
+var BUILD_FAILURE_MARKER = calloutHeader("CAUTION", "Build Failure");
 function failingPaths(output, cwd) {
   const found = /* @__PURE__ */ new Set();
   const ext = String.raw`[\w.-]+\.[A-Za-z]{1,6}`;
@@ -7086,6 +7094,7 @@ function planBuildFailureBounce(cwd, c, base, remote) {
 function buildFailureComment(b) {
   const how = b.how === "files" ? `The failing output names files that only \`${b.branch}\` changed among the branches in that release.` : `Built alone on the previous \`${b.base}\`, \`${b.branch}\` fails the same hook.`;
   return `${BUILD_FAILURE_MARKER}
+
 **Back with the dev lane \u2014 this branch builds on its own but not on current \`${b.base}\`.**
 
 \`${b.branch}\` was verified, but the release's \`${b.hook}\` hook failed once it was merged with the other branches in the same release. ${how}
@@ -7125,7 +7134,7 @@ async function applyBuildFailureBounce(writer, b, contract, memberId, log, dryRu
 }
 
 // src/stranded-verified.ts
-var STRANDED_MARKER = "<!-- crew:stranded-verified -->";
+var STRANDED_MARKER = calloutHeader("WARNING", "Stranded Verified");
 var STRANDED_ESCALATE_AFTER_MS = 30 * 60 * 1e3;
 var priorStrandedFlags = (ticket, events) => events.filter((e) => e.record_id === ticket.id && e.event_type === "stranded_flagged").length;
 function planStrandedVerified(candidate, base, remote, events) {
@@ -7141,6 +7150,7 @@ function planStrandedVerified(candidate, base, remote, events) {
 function flagComment(s) {
   const key = s.candidate.ticket.issue_id;
   return `${STRANDED_MARKER}
+
 **Verified, but nothing to merge \u2014 flagging before this repeats forever.**
 
 \`${key}\` is \`verified\` with no branch on this ship, and its key names no commit anywhere in this ship's \`${s.base}\` history (searched all of it, local commits included, for a bounded \`${key}\` in a commit subject or body). One of three things is true: it landed under a commit that never named the key, the branch was deleted before it merged, or it was verified in error \u2014 the crew cannot tell these apart and will not guess.
@@ -7150,6 +7160,7 @@ If it is still unplaceable next cycle, this ticket is escalated to a person. If
 function escalateComment2(s) {
   const key = s.candidate.ticket.issue_id;
   return `${STRANDED_MARKER}
+
 **Still nothing to merge \u2014 stopping rather than repeating.**
 
 \`${key}\` was flagged as stranded at \`verified\` on an earlier cycle and still has no branch on this ship or on \`${s.remote}\` and no commit in this ship's \`${s.base}\` history naming its key (searched all of it, local commits included). This needs a person: either the work landed under a commit that doesn't name the key and this ticket can simply close, or the branch is gone and the work needs redoing.
@@ -7197,7 +7208,8 @@ async function applyStrandedVerified(writer, s, contract, operatorId, memberId,
 }
 
 // src/gate-red.ts
-var GATE_RED_MARKER = "<!-- crew:test-gate-red";
+var GATE_RED_MARKER = calloutHeader("CAUTION", "Test Gate Red");
+var shaLine = (g) => `Head \`${g.sha.slice(0, 8)}\`.`;
 var GATE_RED_AFTER = 3;
 var lastLines = (output, n) => output.replace(/\u001b\[[0-9;]*m/g, "").trimEnd().split("\n").slice(-n).join("\n");
 function gateRedTickets(merged, merges) {
@@ -7211,7 +7223,9 @@ function gateRedTickets(merged, merges) {
   return out;
 }
 function gateRedComment(g) {
-  return `${GATE_RED_MARKER} ${g.sha.slice(0, 8)} -->
+  return `${GATE_RED_MARKER}
+> ${shaLine(g)}
+
 **This ticket is merged on the base, but the release test gate is red \u2014 nothing has shipped.**
 
 The \`test\` hook (\`${g.hook}\`) has failed ${g.count} cycles running on the same head (\`${g.sha.slice(0, 8)}\`). The ticket's commit is on the base and will ship once the gate passes; it is not stranded, and re-setting it to \`verified\` will not help. Last lines of the hook's output:
@@ -7221,7 +7235,7 @@ ${g.tail}
 \`\`\`
 `;
 }
-var alreadyReported = (ticket, g, events) => events.some((e) => e.record_id === ticket.id && e.event_type === "gate_red" && (e.message ?? "").includes(`${GATE_RED_MARKER} ${g.sha.slice(0, 8)}`));
+var alreadyReported = (ticket, g, events) => events.some((e) => e.record_id === ticket.id && e.event_type === "gate_red" && (e.message ?? "").includes(shaLine(g)));
 
 // src/agent.ts
 import { spawn as spawn2, spawnSync as spawnSync5 } from "child_process";
@@ -9115,7 +9129,7 @@ async function finishRunWorktree(dir, cfg, branch) {
 }
 
 // src/handoff-guard.ts
-var HANDOFF_BOUNCED_MARKER = "<!-- crew:handoff-bounced -->";
+var HANDOFF_BOUNCED_MARKER = calloutHeader("WARNING", "Hand-off Bounced");
 var pushedEventBody = (sha, remote, branch) => `pushed ${sha} to ${remote}/${branch}`;
 function remoteTip(dir, remote, branch) {
   const out = gitOk(dir, ["ls-remote", "--heads", remote, `refs/heads/${branch}`]);
@@ -9164,6 +9178,7 @@ function inspectHandoff(dir, cfg, ticket, role) {
 }
 function bounceComment(v, shipName2) {
   return `${HANDOFF_BOUNCED_MARKER}
+
 **Hand-off bounced: the branch is not on \`${v.remote}\` at the tip this ticket was built to.**
 
 ${shipName2 ? `Ship: ${shipName2}
@@ -9298,7 +9313,7 @@ function repoConfigFor(route, t) {
   }, target.dir);
   return { target, cfg };
 }
-var STRAY_HANDOFF_MARKER = "<!-- crew:stray-handoff -->";
+var STRAY_HANDOFF_MARKER = calloutHeader("WARNING", "Stray Hand-off");
 async function guardStrayHandoffs(i) {
   const st = i.contract.statuses;
   if (i.role === "qa") return;
@@ -9311,6 +9326,7 @@ async function guardStrayHandoffs(i) {
         await i.writer.postEvent(
           t.id,
           `${STRAY_HANDOFF_MARKER}
+
 **Hand-off bounced: this ticket is held by another ship.**
 
 ${i.shipName ? `${i.shipName}'s ` : "A "}${i.role} run set it to \`${st.handoff}\` without having claimed it. Set back to \`${st.building}\`; the holding ship's own hand-off is the one that counts.`,
@@ -10796,12 +10812,13 @@ async function mergeAndRelease(o, decision, fresh, releaseBranch, isolated = fal
 }
 
 // src/failure-alert.ts
-var FAILURE_ALERT_MARKER = "<!-- crew:failure-alert -->";
+var FAILURE_ALERT_MARKER = calloutHeader("CAUTION", "Failure Alert");
 function findOpenFailureAlert(tickets, headline) {
   return tickets.find((t) => t.title === headline);
 }
 function ticketBody(n, route) {
   return `${FAILURE_ALERT_MARKER}
+
 ${n.detail ?? n.headline}
 
 Filed automatically \u2014 no \`notify\` hook is configured for route \`${route}\`, so this is the crew's built-in fallback rather than a silent log line. Configure \`hooks.notify\` on this route to replace it.`;
@@ -10816,6 +10833,7 @@ async function applyFailureAlert(writer, n, route, openTickets, memberId, log, d
     }
     try {
       await writer.postEvent(existing.id, `${FAILURE_ALERT_MARKER}
+
 Still failing: ${n.detail ?? n.headline}`, memberId, "failure_alert");
       log.warn(`release failure recurring \u2014 commented on ${label}`, { step: "release" });
       return { kind: "commented", issueId: label };
@@ -13287,10 +13305,11 @@ import { join as join25 } from "path";
 // src/interrupted.ts
 import { existsSync as existsSync25, readdirSync as readdirSync9, readFileSync as readFileSync18 } from "fs";
 import { join as join24 } from "path";
-var INTERRUPTED_MARKER = "<!-- crew:interrupted -->";
+var INTERRUPTED_MARKER = calloutHeader("NOTE", "Interrupted");
 function interruptedComment(b) {
   const tree = b.dirty === null ? "The worktree could not be checked." : b.dirty ? "The worktree has uncommitted changes \u2014 they are this seat's own, from that run." : "The worktree is clean.";
   return `${INTERRUPTED_MARKER}
+
 The agent run on this ticket was cut short (${b.reason}) before it handed on${b.branch ? `; its branch is \`${b.branch}\`` : ""}. ${tree} The next run on this seat resumes from the worktree rather than starting over.`;
 }
 var handled = /* @__PURE__ */ new Set();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tablation/crew",
-  "version": "0.53.4",
+  "version": "0.53.6",
   "description": "A standing team of headless agents that picks work off a Tablation board, does it on a machine you control, and reports back.",
   "type": "module",
   "license": "MIT",

package/prompts/default/skills/grill-me.md

@@ -31,9 +31,23 @@ prior conversation history exists.
    on the Maps table), ordered by `version`. If one exists with
    `status: active`, that's the current settled PRD — treat this session
    as a **revision** interview, not a fresh one (see §5). If the most
-   recent one is `status: draft` and was never promoted, you're likely
-   continuing or restarting that same attempt — ask the interviewee
-   which they intend.
+   recent one is `status: draft` (never promoted) or `status: planning`
+   (an interview that was interrupted), you're likely continuing or
+   restarting that same attempt — ask the interviewee which they intend.
+   Ignore `abandoned` Maps when picking what to continue; they still count
+   when you compute the next `version`.
+4. Before your first question, make sure a Map record for this session
+   exists and is at `status: planning`, so a grill in progress is visible
+   on the Maps table:
+   - Fresh grill: create the Map now (`epic_id`, a short `title`, the
+     `version` from §3 step 1, empty `content` and `conversation`) at
+     `planning`.
+   - Continuing a `draft` or an interrupted `planning` Map: set that same
+     record to `planning`.
+   - Restarting instead: set the old Map to `abandoned`, then create a new
+     version at `planning`.
+   - Revising an `active` Map: create the next version at `planning` now.
+     Leave the active one as it is until promotion.
 
 ## 2. Run the interview
 
@@ -52,11 +66,13 @@ and don't manufacture more questions once you've genuinely converged.
 
 Once you've reached mutual agreement the session is done:
 
-1. Compute the new Map's `version`: default to
+1. Compute the Map's `version`: default to
    `max(existing versions for this epic_id) + 1`. If the interviewee
    wants a different version label (e.g. a deliberate jump for a major
-   revision), use what they say instead.
-2. Write a new Maps record:
+   revision), use what they say instead. (You normally settled this when
+   you created the record in §1; change it there if the interviewee asks.)
+2. Fill in the Maps record you created in §1 — update that same record,
+   do not create a second one:
    - `epic_id` → this Epic
    - `title` → short, human-readable
    - `content` → the PRD itself, in Markdown. Write this as a real
@@ -66,8 +82,8 @@ Once you've reached mutual agreement the session is done:
      actual back-and-forth (questions asked, answers given, points where
      you changed your recommendation based on pushback). This is the
      record of *how* you got to the PRD, not a duplicate of it.
-   - `status` → always `draft` on creation. Never create a Map as
-     `active` directly.
+   - `status` → `draft`, now that the PRD is written. Never create a Map
+     as `active` directly, and never leave a finished PRD at `planning`.
 
 ## 4. Proposing child tickets
 
@@ -94,6 +110,9 @@ Alongside the draft Map, propose the child Issues implied by the PRD:
 Before ending the session, ask the interviewee directly: **should this
 Map go active now, or stay a draft?**
 
+Only a `draft` Map can be promoted. A Map still at `planning` is an
+unfinished interview and is never activated.
+
 - **If they say stay draft:** leave everything as-is. Nothing else to
   do. A later session (yours or someone else's) picks this back up.
 - **If they say go active:**
@@ -124,6 +143,26 @@ Map go active now, or stay a draft?**
 Do all of this yourself via direct MCP writes. There is no automation
 watching for this — if you don't do it, it doesn't happen.
 
+## 6. Abandoning a Map
+
+A Map moves through `planning` (interview running) → `draft` (PRD written,
+awaiting the promotion decision) → `active` (promoted) → `superseded` (a
+later version went active). `abandoned` is the terminal state for a Map
+that never got that far.
+
+If the interviewee says to stop working on a Map that is at `planning` or
+`draft`:
+
+1. Set that Map to `status: abandoned`.
+2. Ask whether its `draft` Issues should go to `closed_obsolete`, and
+   recommend yes. Apply their answer; leave Issues that have already left
+   `draft` alone.
+3. Leave the Epic's status alone.
+
+An abandoned Map is never reactivated. If work on the Epic resumes later,
+that is a new Map at the next `version`. Do these writes directly via MCP,
+as in §5.
+
 ## What this mode is never responsible for
 
 - Writing or editing code.

package/prompts/dev-qa/skills/grill-me.md

@@ -31,9 +31,23 @@ prior conversation history exists.
    on the Maps table), ordered by `version`. If one exists with
    `status: active`, that's the current settled PRD — treat this session
    as a **revision** interview, not a fresh one (see §5). If the most
-   recent one is `status: draft` and was never promoted, you're likely
-   continuing or restarting that same attempt — ask the interviewee
-   which they intend.
+   recent one is `status: draft` (never promoted) or `status: planning`
+   (an interview that was interrupted), you're likely continuing or
+   restarting that same attempt — ask the interviewee which they intend.
+   Ignore `abandoned` Maps when picking what to continue; they still count
+   when you compute the next `version`.
+4. Before your first question, make sure a Map record for this session
+   exists and is at `status: planning`, so a grill in progress is visible
+   on the Maps table:
+   - Fresh grill: create the Map now (`epic_id`, a short `title`, the
+     `version` from §3 step 1, empty `content` and `conversation`) at
+     `planning`.
+   - Continuing a `draft` or an interrupted `planning` Map: set that same
+     record to `planning`.
+   - Restarting instead: set the old Map to `abandoned`, then create a new
+     version at `planning`.
+   - Revising an `active` Map: create the next version at `planning` now.
+     Leave the active one as it is until promotion.
 
 ## 2. Run the interview
 
@@ -52,11 +66,13 @@ and don't manufacture more questions once you've genuinely converged.
 
 Once you've reached mutual agreement the session is done:
 
-1. Compute the new Map's `version`: default to
+1. Compute the Map's `version`: default to
    `max(existing versions for this epic_id) + 1`. If the interviewee
    wants a different version label (e.g. a deliberate jump for a major
-   revision), use what they say instead.
-2. Write a new Maps record:
+   revision), use what they say instead. (You normally settled this when
+   you created the record in §1; change it there if the interviewee asks.)
+2. Fill in the Maps record you created in §1 — update that same record,
+   do not create a second one:
    - `epic_id` → this Epic
    - `title` → short, human-readable
    - `content` → the PRD itself, in Markdown. Write this as a real
@@ -66,8 +82,8 @@ Once you've reached mutual agreement the session is done:
      actual back-and-forth (questions asked, answers given, points where
      you changed your recommendation based on pushback). This is the
      record of *how* you got to the PRD, not a duplicate of it.
-   - `status` → always `draft` on creation. Never create a Map as
-     `active` directly.
+   - `status` → `draft`, now that the PRD is written. Never create a Map
+     as `active` directly, and never leave a finished PRD at `planning`.
 
 ## 4. Proposing child tickets
 
@@ -94,6 +110,9 @@ Alongside the draft Map, propose the child Issues implied by the PRD:
 Before ending the session, ask the interviewee directly: **should this
 Map go active now, or stay a draft?**
 
+Only a `draft` Map can be promoted. A Map still at `planning` is an
+unfinished interview and is never activated.
+
 - **If they say stay draft:** leave everything as-is. Nothing else to
   do. A later session (yours or someone else's) picks this back up.
 - **If they say go active:**
@@ -124,6 +143,26 @@ Map go active now, or stay a draft?**
 Do all of this yourself via direct MCP writes. There is no automation
 watching for this — if you don't do it, it doesn't happen.
 
+## 6. Abandoning a Map
+
+A Map moves through `planning` (interview running) → `draft` (PRD written,
+awaiting the promotion decision) → `active` (promoted) → `superseded` (a
+later version went active). `abandoned` is the terminal state for a Map
+that never got that far.
+
+If the interviewee says to stop working on a Map that is at `planning` or
+`draft`:
+
+1. Set that Map to `status: abandoned`.
+2. Ask whether its `draft` Issues should go to `closed_obsolete`, and
+   recommend yes. Apply their answer; leave Issues that have already left
+   `draft` alone.
+3. Leave the Epic's status alone.
+
+An abandoned Map is never reactivated. If work on the Epic resumes later,
+that is a new Map at the next `version`. Do these writes directly via MCP,
+as in §5.
+
 ## What this mode is never responsible for
 
 - Writing or editing code.