@tablation/crew 0.40.0 → 0.40.1

package/dist/cli.js

@@ -6466,7 +6466,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 +6476,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" };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tablation/crew",
-  "version": "0.40.0",
+  "version": "0.40.1",
   "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