@rallycry/conveyor-skills 1.0.14 → 1.0.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rallycry/conveyor-skills",
-  "version": "1.0.14",
+  "version": "1.0.16",
   "description": "Shared Claude Code skills for Conveyor consumer repos, linked into .claude/skills via the conveyor-skills CLI",
   "keywords": [
     "claude",

package/skills/conveyor-build/SKILL.md

@@ -52,7 +52,8 @@ or the finish line is true.
 **Pack path goal:** the WHOLE pack, not one child. Per child the goal covers
 the full cycle: plan reviewed and promoted → implemented on the pack branch →
 gated → reviewer-of-record pass → merged (locally) or
-`mcp__conveyor__update_task` → ReviewDev (pod) → base synced. Then
+`mcp__conveyor__update_task` → ReviewDev (pod). Base readiness happens once at
+the finale unless an active child needs the newer base to proceed. Then
 cross-reference, then the finale.
 **Finish line:** every child is ReviewDev, Complete, or Cancelled AND the
 parent's finale PR into the base branch is open with CI started. One child done
@@ -290,6 +291,30 @@ in chat and mark it Complete.
 
 ## Open the PR
 
+### Readiness policy
+
+A newer base alone is not a reason to refresh an already-green branch. Keep that
+head stable until a real readiness boundary: final pre-PR verification, a merge
+conflict, or an active dependency blocked on the newer base. When a sync or
+repair is necessary, combine the base merge, conflict resolution, and CI repair
+locally, run the required local verification on the resulting head, then push
+once. Remote CI validates that exact pushed head. Adopt a shared repair at that
+same boundary unless it blocks active work now.
+
+Use the existing task chat to make the reason auditable, without a new tracking
+system:
+
+```
+[branch-readiness] reason: final_readiness | conflict_resolution | dependency_unblock | shared_repair
+prior_head: <sha>
+base: <branch>
+base_sha: <sha>
+```
+
+A no-change merge already creates no new head. The policy avoids creating a new
+head just because the base advanced. A changed branch needs fresh CI on that
+exact head; a prior green result does not carry forward.
+
 Refresh against the card's base first, then gate, then open — in that order, so
 nothing invalidates the verification you just did:
 

package/skills/conveyor-build/references/pack-path.md

@@ -244,23 +244,29 @@ leave the branch pushed, and stop.
    real pack branch. Fix the parent record (`mcp__conveyor__update_task` with
    `githubBranch: <pack>`), advance the child by hand (`update_task` →
    `ReviewDev`), and post the drift to parent chat so it is visible.
-3. **Sync `dev` into the pack branch — yours to do, in either environment.**
-   Nothing server-side syncs the pack branch for you; a session driving the
-   pack resolves conflicts in-session.
+3. **Do not sync after every child.** A pod pack has no child PRs, so those
+   repeated merges are not child CI boundaries. Sync once immediately before
+   the finale's verification pass. Sync earlier only when an active child needs
+   the newer base to proceed or when resolving a real conflict.
 
    ```bash
-   git checkout <pack> && git pull && git fetch origin <base> && git merge origin/<base> --no-edit && git push
+   git checkout <pack> && git pull && git fetch origin <base>:refs/remotes/origin/<base> && git merge origin/<base> --no-edit
    ```
 
-   **Merge, never rebase** — the pack branch is shared with open child PRs and
-   WIP refs, and rewriting it breaks them. Conflicts are yours to resolve
-   properly; you wrote the code.
+   Run the required local gate against the resulting head, then push once.
+   Remote CI validates that exact pushed head.
 
-   If the merge drags in unrelated changes or errors, `dev` may have been
-   rewound (a revert or force-push). Verify the previous sync point is still an
-   ancestor of `origin/<base>` (`git merge-base --is-ancestor`); if it is not,
-   abort the merge and escalate rather than chasing the noise.
-4. Report the merge to parent chat in a line or two.
+   **Merge, never rebase.** The pack branch is shared with open child PRs and
+   WIP refs, and rewriting it breaks them. Conflicts are yours to resolve
+   properly; you wrote the code. If the merge drags in unrelated changes or
+   errors, `dev` may have been rewound. Verify the previous sync point is still
+   an ancestor of `origin/<base>` (`git merge-base --is-ancestor`); if it is
+   not, abort the merge and escalate rather than chasing the noise.
+
+   When an early sync changes the branch, post `[branch-readiness]` to parent
+   chat with `reason`, `prior_head`, `base`, and `base_sha`. The final sync uses
+   the same record when it creates a new head. Run the finale gate against that
+   exact resulting head.
 
 ## Finale
 

package/skills/conveyor-prune/SKILL.md

@@ -71,7 +71,7 @@ mutation applied before the reply — is a stalled run, not a paused one.
 4. Skip, and list under "deliberately not touched":
    - rows with `parentTaskId` set — prune the pack parent; its children follow
      the parent's disposition;
-   - rows with a non-null `workspaceStatus` (`codespaceStatus` on older servers) — something is running on it;
+   - rows with a non-null `workspaceStatus` — something is running on it;
    - rows with a `githubPRUrl` — work exists; that is a review question, not
      a prune question.
 5. `mcp__conveyor__list_tags` once — the project's vocabulary, and whether a