@tablation/crew 0.40.0 → 0.41.0

package/dist/cli.js

@@ -5232,7 +5232,14 @@ function missingBlockerIds(tickets) {
 function blockerInfoMap(tickets, extra = []) {
   const info = {};
   for (const t of [...tickets, ...extra]) {
-    info[t.id] = { issue_id: t.issue_id, issue_tag: t.issue_tag, status: t.status };
+    info[t.id] = {
+      issue_id: t.issue_id,
+      issue_tag: t.issue_tag,
+      status: t.status,
+      repo_id: t.repo_id,
+      merged_at: t.merged_at,
+      commit_sha: t.commit_sha
+    };
   }
   return info;
 }
@@ -5241,14 +5248,18 @@ function computeBlockedIds(tickets, info) {
   for (const t of tickets) if (unresolvedBlockers(t, info).length > 0) blocked.add(t.id);
   return blocked;
 }
-function unresolvedBlockers(t, info) {
+function unresolvedBlockers(t, info, opts = {}) {
+  const mergeGated = opts.mergeGated ?? true;
   return (t.blocked_by ?? []).filter((id) => {
-    const status2 = info[id]?.status;
-    return status2 !== void 0 && !RESOLVED_STATUSES.has(status2);
+    const b = info[id];
+    const status2 = b?.status;
+    if (!b || status2 === void 0) return false;
+    if (!RESOLVED_STATUSES.has(status2)) return true;
+    return mergeGated && status2 === "verified" && !!t.repo_id && b.repo_id === t.repo_id && !b.merged_at && !b.commit_sha;
   });
 }
-function describeUnresolved(t, info) {
-  return unresolvedBlockers(t, info).map((id) => `${info[id]?.issue_tag ?? info[id]?.issue_id ?? "?"} (${info[id]?.status ?? "unknown"})`).join(", ");
+function describeUnresolved(t, info, opts = {}) {
+  return unresolvedBlockers(t, info, opts).map((id) => `${info[id]?.issue_tag ?? info[id]?.issue_id ?? "?"} (${info[id]?.status ?? "unknown"})`).join(", ");
 }
 function sweepDiagnostics(tickets, info) {
   const dangling = [];
@@ -5317,7 +5328,7 @@ function filingErrors(tickets, opts = {}) {
 function sweepComment(step) {
   return step.action === "park" ? `Parked as **Blocked** by the crew \u2014 waiting on: ${step.blockers}.
 
-This is automatic and reversible: an approved ticket whose \`Blocked by\` entries are not all resolved is parked out of the queue, and restored on the first poll after the last one resolves. Nothing else about the ticket changes. A blocker counts as resolved at \`verified\`, \`closed_deployed\`, \`closed_wont_fix\` or \`closed_duplicate\` \u2014 not at \`fixed\`, which is still an unmerged branch awaiting QA.` : `Restored to **Approved** by the crew \u2014 every blocker has resolved${step.blockers && step.blockers !== "\u2014" ? ` (${step.blockers})` : ""}.
+This is automatic and reversible: an approved ticket whose \`Blocked by\` entries are not all resolved is parked out of the queue, and restored on the first poll after the last one resolves. Nothing else about the ticket changes. A blocker counts as resolved at \`closed_deployed\`, \`closed_wont_fix\` or \`closed_duplicate\`, or at \`verified\` when it is in a different repository or already merged (\`merged_at\` set) \u2014 not at \`fixed\`, which is still an unmerged branch awaiting QA, and not at \`verified\` for a blocker in this ticket's own repository until the release has merged it, so nothing gets built stacked on an unmerged branch.` : `Restored to **Approved** by the crew \u2014 every blocker has resolved${step.blockers && step.blockers !== "\u2014" ? ` (${step.blockers})` : ""}.
 
 This restores the status it was approved at before being parked; it is back in the queue and a role may pick it up. If a blocker resolved as \`closed_wont_fix\` or \`closed_duplicate\` this ticket may still not be buildable as written \u2014 that is a call for a human, not the crew.`;
 }
@@ -5897,7 +5908,7 @@ ${sorted(held).map((t) => `| ${displayKey2(t)} | ${stopOf(t)} |`).join("\n")}
     "\nWork the first one you are not required to skip. Tickets waiting on an\nunresolved dependency are already out of this table \u2014 see Blocked below.\n",
     table(step2, i, header, row),
     "\n### Blocked \u2014 waiting on a dependency, not yours to start\n",
-    '\nListed rather than hidden so "nothing to do" stays distinguishable from\n"everything is parked". The loop parks and restores these itself, on every\npoll: an approved ticket whose `Blocked by` entries are unresolved moves to\n`blocked`, and back to `accepted` once the last one resolves. **Do not pick\none up, do not set or clear `blocked` by hand, and do not "unblock" one by\nediting its `Blocked by` field** \u2014 if a blocker looks wrong, say so in your\nrun summary. A blocker counts as resolved at `verified`, `closed_deployed`,\n`closed_wont_fix` or `closed_duplicate`; `fixed` is still an unmerged branch\nawaiting QA, so it does not count.\n',
+    '\nListed rather than hidden so "nothing to do" stays distinguishable from\n"everything is parked". The loop parks and restores these itself, on every\npoll: an approved ticket whose `Blocked by` entries are unresolved moves to\n`blocked`, and back to `accepted` once the last one resolves. **Do not pick\none up, do not set or clear `blocked` by hand, and do not "unblock" one by\nediting its `Blocked by` field** \u2014 if a blocker looks wrong, say so in your\nrun summary. A blocker counts as resolved at `closed_deployed`,\n`closed_wont_fix` or `closed_duplicate`, or at `verified` when it is in another\nrepository or already merged; `fixed` is still an unmerged branch awaiting QA,\nand a `verified` blocker in the same repository as the blocked ticket is unmerged until the\nrelease merges it, so neither counts.\n',
     blockedTable(i.tickets.filter(isBlocked)),
     ...heldTable ? [heldTable] : []
   ]);
@@ -5926,7 +5937,7 @@ function qaDigest(i) {
 ### Waiting on blockers \u2014 not yours to verify yet
 
 A \`fixed\` or \`qa\` ticket whose \`Blocked by\` names something not yet resolved
-(\`verified\`, \`closed_deployed\`, \`closed_wont_fix\` or \`closed_duplicate\`) is held out of
+(\`closed_deployed\`, \`closed_wont_fix\` or \`closed_duplicate\`, or \`verified\` once merged or in another repository) is held out of
 verification: its change needs the blocker released first. It becomes yours on
 the first poll after the last blocker resolves. No one needs to change the ticket.
 
@@ -6466,7 +6477,7 @@ function handBackComment(b, merged) {
 
 \`${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.
 
-${merged ? `\`${b.base}\` has been merged into \`${b.branch}\` in its worktree and the conflict is left in place, so \`git status\` there shows exactly what disagrees. Resolve it, commit, and hand back to QA as usual \u2014 \`git merge --abort\` backs the merge out if you would rather start differently.` : `This ship has no worktree for \`${b.branch}\`, so nothing has been merged for you. Merge \`${b.base}\` into the branch wherever it lives, resolve the conflict, and commit.`}
+${merged ? `\`${b.base}\` has been merged into \`${b.branch}\` in its worktree and the conflict is left in place, so \`git status\` there shows exactly what disagrees. Resolve it, commit, push as a plain fast-forward (the branch is pushed, so rebasing it is not an option) and hand back to QA as usual \u2014 \`git merge --abort\` backs the merge out if you would rather start differently.` : `This ship has no worktree for \`${b.branch}\`, so nothing has been merged for you. Merge \`${b.base}\` into the branch wherever it lives, resolve the conflict, and commit.`}
 
 Nothing was written to \`${b.base}\`: the failed merge was rewound, and the rest of the release shipped without this ticket. Re-verifying is what puts it back in the merge queue.`;
 }
@@ -6476,7 +6487,7 @@ function escalateComment(b) {
 
 \`${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(", ")})` : ""}.
 
-Either \`${b.base}\` is moving faster than this branch can be rebased onto it, or this ticket overlaps work that has already shipped and needs rethinking rather than merging. That is a call for a person, not another lap through the lanes.`;
+Either \`${b.base}\` is moving faster than this branch can absorb it, or this ticket overlaps work that has already shipped and needs rethinking rather than merging. That is a call for a person, not another lap through the lanes.`;
 }
 async function applyConflictBounce(writer, b, contract, memberId, log, dryRun) {
   const t = { ticket: b.ticket.issue_id, step: "merge" };
@@ -8421,7 +8432,7 @@ function checkGuards(cwd, base = "main") {
 }
 function heldByBlockers(tickets, verifiedStatus, info) {
   if (!info) return [];
-  return tickets.filter((t) => t.status === verifiedStatus && unresolvedBlockers(t, info).length > 0).map((ticket) => ({ ticket, blockers: describeUnresolved(ticket, info) }));
+  return tickets.filter((t) => t.status === verifiedStatus && unresolvedBlockers(t, info, { mergeGated: false }).length > 0).map((ticket) => ({ ticket, blockers: describeUnresolved(ticket, info, { mergeGated: false }) }));
 }
 var describeHeld = (held) => held.map((h) => `${h.ticket.issue_tag ?? h.ticket.issue_id} held: blocked by ${h.blockers}`);
 var CHANGELOG_LINE = /^Changelog:[ \t]*(.*)$/gm;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tablation/crew",
-  "version": "0.40.0",
+  "version": "0.41.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/lane-qa.md

@@ -153,6 +153,11 @@ pass.
   base branch or the primary checkout.** The release phase merges verified
   branches and removes their worktrees; a merge may be in flight while you
   run.
+- **You never ask a builder to rewrite a pushed branch.** If you check
+  mergeability (`git merge-tree`) and the branch conflicts with or trails the
+  base, the bounce says to merge `<remote>/<base>` into the branch, resolve and
+  push fast-forward; a rebase would need a force push the builder cannot make.
+  Or pass the ticket and let the release's conflict path do the merge.
 - **You only ever enter the worktree of the ticket you are verifying.**
 - Throwaway verification scripts go in a scratch directory outside the
   repository — not the worktree root either.

package/prompts/default/skills/crew-lane-agent.md

@@ -149,10 +149,11 @@ Then:
   has posted a new comment since your last one — the comment clears you to
   act, never the flag. Clearing either flag is always the operator's move.
 - **Before resuming in an existing worktree, run `crew sync`** (fetches and
-  fast-forwards every worktree branch that tracks a remote; never merges or
-  rebases). If it reports your branch as diverged, stop: comment with what it
-  printed and park the ticket for a person (see "Stopping"); never merge or
-  rebase it yourself.
+  fast-forwards every worktree branch that tracks a remote and does nothing
+  else to it). If it reports your branch as diverged, stop: comment with what
+  it printed and park the ticket for a person (see "Stopping"); do not try to
+  reconcile it yourself. A branch that is merely stale or conflicts with the
+  base is not this case: Step 4.4 says how to fix it.
 - A ticket QA bounced back arrives as `in_progress`, reassigned to your row
   (or unassigned, when your ship holds it), with a comment saying what still
   fails. Treat it as new direction: fix what it names and take it back to
@@ -336,7 +337,8 @@ before going further, and never change a ticket's `report_type` yourself.
    first**: `git push --set-upstream <remote> <branch>` from the worktree
    (the remote is `origin` unless the repository's configuration says
    otherwise; a repository with no remote has nothing to push to — say so and
-   skip it). Push as a plain fast-forward, never `--force`; a rejected push
+   skip it). Push as a plain fast-forward, never `--force` (Step 4.4 covers a stale
+   branch); a rejected push
    means someone else moved the branch, so stop and say so on the ticket.
    Then, in one write, set `status` to `fixed` and hand the ticket to QA: in
    an `automatic` project **clear `assignee_id`**; in a `hybrid` project set
@@ -376,8 +378,18 @@ worktree, runs the test gate and deploys. Three consequences:
    reads the diff later to fill them in.
 3. **A branch that no longer squash-merges cleanly comes back to you** at
    `in_progress`, reassigned to your lane, with a comment naming the
-   conflict. Fix it in the same worktree and take it to `fixed` again; never
-   merge by hand to "help".
+   conflict. Fix it in the same worktree and take it to `fixed` again. "Never
+   merge" above means never merge INTO the base; merging the base INTO your
+   own ticket branch is the expected fix (rule 4), and it is not "by hand to
+   help".
+4. **A pushed branch is never rewritten; merge `<remote>/<base>` into it.**
+   Never rebase, reset or amend a branch you have pushed: that needs a force
+   push, which this ship denies, and it strands every other ship's copy. When
+   the branch is stale or conflicts with `<base>`, run `git fetch <remote>`
+   then `git merge <remote>/<base>` in the ticket's worktree, resolve any
+   conflict, commit, run the suite, and `git push` as a plain fast-forward.
+   The merge commit disappears when the release squash-merges, so the ticket's
+   own diff is all that ships.
 
 Never set `verified` yourself — that is QA's call (or the operator's), and
 setting it is what queues a branch for merge. The deployed status is set by

package/prompts/default/skills/worktree-setup.md

@@ -33,7 +33,7 @@ person says so. **A missing worktree is never a reason to stop.**
 1. From the primary checkout, run `crew sync` (name the route if this ship
    serves more than one). It fetches the remote and fast-forwards the primary
    checkout's base branch, and every worktree branch that tracks a remote,
-   never merging or rebasing. It is quiet about a checkout that is not cleanly
+   doing nothing else to them. It is quiet about a checkout that is not cleanly
    on the base — something else may be mid-edit there; that is expected.
 2. If it prints `DO NOT CUT A WORKTREE FROM THIS BASE` and exits non-zero, the
    base has diverged from the remote: **hard stop.** Do not `git worktree
@@ -50,7 +50,9 @@ person says so. **A missing worktree is never a reason to stop.**
 When resuming an existing worktree, run `crew sync` first; if it reports your
 branch as diverged (local commits not on the remote *and* the remote has
 moved), stop, comment with what it printed, and park the ticket for a person
-(`needs_info`, operator as assignee). Never merge or rebase it yourself.
+(`needs_info`, operator as assignee). A branch that is only stale or conflicts
+with the base is a different case: merge `<remote>/<base>` into it, per the lane
+policy, and push fast-forward.
 
 ## Making the worktree runnable
 

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

@@ -152,6 +152,11 @@ pass.
   base branch or the primary checkout.** The release phase merges verified
   branches and removes their worktrees; a merge may be in flight while you
   run.
+- **You never ask a builder to rewrite a pushed branch.** If you check
+  mergeability (`git merge-tree`) and the branch conflicts with or trails the
+  base, the bounce says to merge `<remote>/<base>` into the branch, resolve and
+  push fast-forward; a rebase would need a force push the builder cannot make.
+  Or pass the ticket and let the release's conflict path do the merge.
 - **You only ever enter the worktree of the ticket you are verifying.**
 - Throwaway verification scripts go in a scratch directory outside the
   repository — not the worktree root either.

package/prompts/dev-qa/skills/crew-lane-agent.md

@@ -149,10 +149,11 @@ Then:
   has posted a new comment since your last one — the comment clears you to
   act, never the flag. Clearing either flag is always the operator's move.
 - **Before resuming in an existing worktree, run `crew sync`** (fetches and
-  fast-forwards every worktree branch that tracks a remote; never merges or
-  rebases). If it reports your branch as diverged, stop: comment with what it
-  printed and park the ticket for a person (see "Stopping"); never merge or
-  rebase it yourself.
+  fast-forwards every worktree branch that tracks a remote and does nothing
+  else to it). If it reports your branch as diverged, stop: comment with what
+  it printed and park the ticket for a person (see "Stopping"); do not try to
+  reconcile it yourself. A branch that is merely stale or conflicts with the
+  base is not this case: Step 4.4 says how to fix it.
 - A ticket QA bounced back arrives as `in_progress`, reassigned to your row
   (or unassigned, when your ship holds it), with a comment saying what still
   fails. Treat it as new direction: fix what it names and take it back to
@@ -336,7 +337,8 @@ before going further, and never change a ticket's `report_type` yourself.
    first**: `git push --set-upstream <remote> <branch>` from the worktree
    (the remote is `origin` unless the repository's configuration says
    otherwise; a repository with no remote has nothing to push to — say so and
-   skip it). Push as a plain fast-forward, never `--force`; a rejected push
+   skip it). Push as a plain fast-forward, never `--force` (Step 4.4 covers a stale
+   branch); a rejected push
    means someone else moved the branch, so stop and say so on the ticket.
    Then, in one write, set `status` to `fixed` and hand the ticket to QA: in
    an `automatic` project **clear `assignee_id`**; in a `hybrid` project set
@@ -376,8 +378,18 @@ worktree, runs the test gate and deploys. Three consequences:
    reads the diff later to fill them in.
 3. **A branch that no longer squash-merges cleanly comes back to you** at
    `in_progress`, reassigned to your lane, with a comment naming the
-   conflict. Fix it in the same worktree and take it to `fixed` again; never
-   merge by hand to "help".
+   conflict. Fix it in the same worktree and take it to `fixed` again. "Never
+   merge" above means never merge INTO the base; merging the base INTO your
+   own ticket branch is the expected fix (rule 4), and it is not "by hand to
+   help".
+4. **A pushed branch is never rewritten; merge `<remote>/<base>` into it.**
+   Never rebase, reset or amend a branch you have pushed: that needs a force
+   push, which this ship denies, and it strands every other ship's copy. When
+   the branch is stale or conflicts with `<base>`, run `git fetch <remote>`
+   then `git merge <remote>/<base>` in the ticket's worktree, resolve any
+   conflict, commit, run the suite, and `git push` as a plain fast-forward.
+   The merge commit disappears when the release squash-merges, so the ticket's
+   own diff is all that ships.
 
 Never set `verified` yourself — that is QA's call (or the operator's), and
 setting it is what queues a branch for merge. The deployed status is set by

package/prompts/dev-qa/skills/worktree-setup.md

@@ -33,7 +33,7 @@ person says so. **A missing worktree is never a reason to stop.**
 1. From the primary checkout, run `crew sync` (name the route if this ship
    serves more than one). It fetches the remote and fast-forwards the primary
    checkout's base branch, and every worktree branch that tracks a remote,
-   never merging or rebasing. It is quiet about a checkout that is not cleanly
+   doing nothing else to them. It is quiet about a checkout that is not cleanly
    on the base — something else may be mid-edit there; that is expected.
 2. If it prints `DO NOT CUT A WORKTREE FROM THIS BASE` and exits non-zero, the
    base has diverged from the remote: **hard stop.** Do not `git worktree
@@ -50,7 +50,9 @@ person says so. **A missing worktree is never a reason to stop.**
 When resuming an existing worktree, run `crew sync` first; if it reports your
 branch as diverged (local commits not on the remote *and* the remote has
 moved), stop, comment with what it printed, and park the ticket for a person
-(`needs_info`, operator as assignee). Never merge or rebase it yourself.
+(`needs_info`, operator as assignee). A branch that is only stale or conflicts
+with the base is a different case: merge `<remote>/<base>` into it, per the lane
+policy, and push fast-forward.
 
 ## Making the worktree runnable