@tablation/crew 0.21.0 → 0.22.0

package/dist/cli.js

@@ -4500,6 +4500,9 @@ function blockers(t, i) {
   });
   return list.length === 0 ? "\u2014" : list.join(", ");
 }
+function modeCell(t, i) {
+  return i.workModes && i.workModes.modes.size > 0 ? modeOf(t, i.workModes) : "\u2014";
+}
 var sorted = (ts) => [...ts].sort(compareRank);
 var stream = (segments) => `${segments.join("\n")}
 `;
@@ -4511,14 +4514,14 @@ ${sorted(ts).map(row).join("\n")}
 `;
 }
 function buildingDigest(i) {
-  const header = "| ticket | repo | branch | worktree | status | assignee | filed by | sev | pri | eff | updated | last comment | new since last poll |\n|---|---|---|---|---|---|---|---|---|---|---|---|---|";
+  const header = "| ticket | repo | branch | worktree | mode | status | assignee | filed by | sev | pri | eff | updated | last comment | new since last poll |\n|---|---|---|---|---|---|---|---|---|---|---|---|---|---|";
   const row = (t) => {
     const n = newFromOthers(i, t.id);
     const branch = i.branchFor ? i.branchFor(t) : "";
     const worktree = i.worktreeFor ? i.worktreeFor(t) : "";
     const dir = i.dirFor ? i.dirFor(t) : null;
     const repo = i.dirFor ? dir ?? "**NO CHECKOUT**" : "";
-    return `| ${displayKey2(t)} | ${repo} | ${branch} | ${worktree} | ${t.status} | ${who(t, i)} | ${filedBy(t, i)} | ${t.severity ?? "\u2014"} | ${t.priority ?? "\u2014"} | p${effectivePriority(t)} | ${t.updated_at.slice(0, 16)}Z | ${lastComment(i, t.id)} | ${n > 0 ? `**${n} new**` : "\u2014"} |`;
+    return `| ${displayKey2(t)} | ${repo} | ${branch} | ${worktree} | ${modeCell(t, i)} | ${t.status} | ${who(t, i)} | ${filedBy(t, i)} | ${t.severity ?? "\u2014"} | ${t.priority ?? "\u2014"} | p${effectivePriority(t)} | ${t.updated_at.slice(0, 16)}Z | ${lastComment(i, t.id)} | ${n > 0 ? `**${n} new**` : "\u2014"} |`;
   };
   const blockedRow = (t) => `| ${displayKey2(t)} | ${t.status} | ${who(t, i)} | p${effectivePriority(t)} | ${blockers(t, i)} |`;
   const blockedTable = (ts) => ts.length === 0 ? "\n_None._\n" : `
@@ -4564,7 +4567,7 @@ ${sorted(held).map((t) => `| ${displayKey2(t)} | ${stopOf(t)} |`).join("\n")}
   ]);
 }
 function qaDigest(i) {
-  const header = "| ticket | repo | status | built by | assignee | filed by | sev | pri | eff | branch | worktree | updated | last comment | new since last poll |\n|---|---|---|---|---|---|---|---|---|---|---|---|---|---|";
+  const header = "| ticket | repo | mode | status | built by | assignee | filed by | sev | pri | eff | branch | worktree | updated | last comment | new since last poll |\n|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|";
   const branchCell = (t) => {
     if (i.dirFor && i.dirFor(t) === null) return "\u2014";
     if (!i.existingBranchFor) return "";
@@ -4579,7 +4582,7 @@ function qaDigest(i) {
     const n = newFromOthers(i, t.id);
     const dir = i.dirFor ? i.dirFor(t) : null;
     const repo = i.dirFor ? dir ?? "**NO CHECKOUT**" : "";
-    return `| ${displayKey2(t)} | ${repo} | ${t.status} | ${builtBy(t)} | ${who(t, i)} | ${filedBy(t, i)} | ${t.severity ?? "\u2014"} | ${t.priority ?? "\u2014"} | p${effectivePriority(t)} | ${branchCell(t)} | ${worktreeCell(t)} | ${t.updated_at.slice(0, 16)}Z | ${lastComment(i, t.id)} | ${n > 0 ? `**${n} new**` : "\u2014"} |`;
+    return `| ${displayKey2(t)} | ${repo} | ${modeCell(t, i)} | ${t.status} | ${builtBy(t)} | ${who(t, i)} | ${filedBy(t, i)} | ${t.severity ?? "\u2014"} | ${t.priority ?? "\u2014"} | p${effectivePriority(t)} | ${branchCell(t)} | ${worktreeCell(t)} | ${t.updated_at.slice(0, 16)}Z | ${lastComment(i, t.id)} | ${n > 0 ? `**${n} new**` : "\u2014"} |`;
   };
   return stream([
     "## Current queue \u2014 built for you by the poll\n",
@@ -5446,6 +5449,18 @@ function renderEnvironment(i) {
       "another (the digest prints other ships by name) \u2014 write its name, never a Ships row id."
     );
   }
+  const seatIds = Object.entries(route.resolved?.seats ?? {}).filter(([, id]) => !!id);
+  if (seatIds.length > 0) {
+    lines.push(
+      "",
+      "## Seats on this ship",
+      "",
+      "The Crew row id of each role's seat on this ship, to write verbatim where a hand-off",
+      "assigns the next lane (a ticket whose digest `mode` is `hybrid`):",
+      "",
+      ...seatIds.map(([role, id]) => `- ${role}: \`${id}\``)
+    );
+  }
   lines.push(
     "",
     "## What the columns are called here",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tablation/crew",
-  "version": "0.21.0",
+  "version": "0.22.0",
   "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/personas/common.md

@@ -305,10 +305,18 @@ Never start work on a ticket without first setting `assignee_id` to your
 own id (Step 3.3 already does this) — that claim is itself part of what
 keeps a concurrent interactive session from re-entering the same ticket.
 
-A project in **manual work mode** (its Projects row says so) is never consumed
-automatically: the digest lists its tickets only when a person has assigned them to
-your seat, and status alone never makes one yours. The digest says so when it
-applies; do not go looking for the missing tickets. QA is unaffected.
+Every ticket's project has a **work mode**, shown in the digest's `mode`
+column: `automatic` (lanes work tickets by status), `hybrid` (a lane considers a
+ticket only when it is assigned to an agent — a Crew row backed by an Agent, not a
+hold), or `manual` (no automation touches it; a ticket with no project counts as
+manual). The digest says so when a project is not automatic; do not go looking for
+a ticket it leaves out. **One hand-off rule:** in a `hybrid` project, hand a ticket
+to the next lane by *assigning that lane's seat on this ship* (ids under "Seats on
+this ship" in the Environment section, else the roster); in an `automatic` project,
+clear `assignee_id` as before. If there is no seat for the target role, assign any
+Crew row with that role's Agent; if there is none, clear it and say so in the
+hand-off comment. Parks (`needs_info`, `needs_planning` → the operator) are the
+same in every mode.
 
 Never touch a ticket still at `new` — only `accepted` tickets are yours to
 pick up; triage (a separate process) is what promotes `new` → `accepted`/
@@ -558,7 +566,9 @@ if `report_type` is either of those.
    this is your own isolated worktree, no special permission needed for this
    part).
 9. Set the ticket's `status` to `fixed` once you have verified it yourself,
-   and **clear `assignee_id`** — that pair is the hand-off to the QA lane.
+   and hand the ticket to the QA lane: in an `automatic` project **clear `assignee_id`**; in a
+   `hybrid` project **set `assignee_id` to this ship's QA seat** instead (the digest's `mode`
+   column says which). That pair is the hand-off to the QA lane.
    If the Issues table has a `held_by_ship_id` column, clear it in the same
    write (the hold is for the building roles; QA on any ship may take a `fixed`
    ticket). A QA bounce or `needs_info` park leaves it set; QA clears it again

package/prompts/default/personas/lane-design.md

@@ -98,6 +98,11 @@ stopping for this run, do the following instead:
     it) — revise the comp against what they said and post again. This cycle
     repeats as many times as the operator wants.
 
+  In a `hybrid` project (the digest's `mode` column), where the operator
+  leaves the hand-off to you, assign this ship's Developer seat when
+  `needs_design` is cleared rather than leaving the assignee blank, so the dev lane
+  still sees the ticket; in an `automatic` project nothing changes.
+
   Never implement past the comp to "just finish it" because the fix looks
   small, and never set `needs_design`, `accepted`, or clear
   `needs_planning`/`needs_review` yourself — all of that is the operator's

package/prompts/default/personas/lane-qa.md

@@ -141,6 +141,11 @@ human review, so "probably fine" is not a pass.
      bump the version, and deploy this cycle or the next. Say in
      the comment what you exercised, so the record shows what "verified"
      covered.
+   - **Person-built hybrid ticket with no branch** — a `hybrid` ticket at
+     `fixed` whose branch under the repo's naming convention does not exist
+     (the digest's `branch` column says **MISSING**) is not a bounce to a
+     builder: set `needs_info` and assign the operator, with a comment naming the
+     branch you expected. A person built it; the operator has to push it.
    - **It doesn't** → `status` = `in_progress`, `assignee_id` = the building
      lane's own Crew row id from the roster above — the dev seat if
      `needs_design` is false or null, the design seat if true. **Exception:** when the Issues table has a `held_by_ship_id` column, **clear** `assignee_id` *and* `held_by_ship_id` instead of naming a seat — the

package/prompts/dev-qa/personas/common.md

@@ -286,6 +286,19 @@ Never start work on a ticket without first setting `assignee_id` to your
 own id (Step 3.3 already does this) — that claim is itself part of what
 keeps a concurrent interactive session from re-entering the same ticket.
 
+Every ticket's project has a **work mode**, shown in the digest's `mode`
+column: `automatic` (lanes work tickets by status), `hybrid` (a lane considers a
+ticket only when it is assigned to an agent — a Crew row backed by an Agent, not a
+hold), or `manual` (no automation touches it; a ticket with no project counts as
+manual). The digest says so when a project is not automatic; do not go looking for
+a ticket it leaves out. **One hand-off rule:** in a `hybrid` project, hand a ticket
+to the next lane by *assigning that lane's seat on this ship* (ids under "Seats on
+this ship" in the Environment section, else the roster); in an `automatic` project,
+clear `assignee_id` as before. If there is no seat for the target role, assign any
+Crew row with that role's Agent; if there is none, clear it and say so in the
+hand-off comment. Parks (`needs_info`, `needs_planning` → the operator) are the
+same in every mode.
+
 Never touch a ticket still at `new` — only `accepted` tickets are yours to
 pick up; triage (a separate process) is what promotes `new` → `accepted`/
 `needs_info`.
@@ -535,7 +548,9 @@ if `report_type` is either of those.
    this is your own isolated worktree, no special permission needed for this
    part).
 9. Set the ticket's `status` to `fixed` once you have verified it yourself,
-   and **clear `assignee_id`** — that pair is the hand-off to the QA lane.
+   and hand the ticket to the QA lane: in an `automatic` project **clear `assignee_id`**; in a
+   `hybrid` project **set `assignee_id` to this ship's QA seat** instead (the digest's `mode`
+   column says which). That pair is the hand-off to the QA lane.
    If the Issues table has a `held_by_ship_id` column, clear it in the same
    write (the hold is for the building roles; QA on any ship may take a `fixed`
    ticket). A QA bounce or `needs_info` park leaves it set; QA clears it again

package/prompts/dev-qa/personas/lane-qa.md

@@ -128,6 +128,11 @@ human review, so "probably fine" is not a pass.
      bump the version, and deploy this cycle or the next. Say in
      the comment what you exercised, so the record shows what "verified"
      covered.
+   - **Person-built hybrid ticket with no branch** — a `hybrid` ticket at
+     `fixed` whose branch under the repo's naming convention does not exist
+     (the digest's `branch` column says **MISSING**) is not a bounce to a
+     builder: set `needs_info` and assign the operator, with a comment naming the
+     branch you expected. A person built it; the operator has to push it.
    - **It doesn't** → `status` = `in_progress`, `assignee_id` = the dev
      seat's own Crew row id from the roster above. **Exception:** when the Issues table has a `held_by_ship_id` column, **clear** `assignee_id` *and* `held_by_ship_id` instead of naming a seat — the
      hold on a `qa` ticket is yours, as verifier, and seats are per ship, so