cctest-recipe-upstream: verify merge-base before rebasing; beware stray upstream main vs master

.opencode/skills/cctest-recipe-upstream/SKILL.md

@@ -50,6 +50,39 @@ not the test server — so it can run either way. Probe, then follow that branch
   4. Everything else in the canonical script (origin/dev remote setup, release recommendation,
      emitted next-steps) is identical.
 
+Every time the branch was prepared **here**, remember it exists only on this host — the
+operator's machine must fetch it first. Always emit this **step 0** before the push step
+(anonymous public fetch, no credentials needed):
+
+```
+  # 0. On a machine WITHOUT the branch pre-fetched, get it from the autonomic mirror
+  #    (fetch by URL — works regardless of what the local remotes are named):
+  cd <local checkout of the recipe>
+  git fetch https://git.autonomic.zone/recipe-maintainers/<recipe>.git +refs/pull/<PR_NUM>/head:refs/heads/<HEAD_REF>
+  git checkout <HEAD_REF>
+```
+
+If the operator's checkout does NOT yet have the mirror remote, emit once before the fetch:
+
+```
+  git remote add gitea https://git.autonomic.zone/recipe-maintainers/<recipe>.git
+```
+
 In both modes the final output is a set of commands for the operator to run on a machine **with
 push access to `git.coopcloud.tech`** — always print them, even when everything local is
 already prepared.
+
+**Verify the merge-base BEFORE rebasing — bases can be traps.** Upstream repos can
+carry a stray, divergent `main` ALONGSIDE the real `master` base branch. Rebase targets must be
+chosen by evidence: `git ls-remote origin | grep -E 'refs/heads/(main|master)$'`, then
+`git merge-base <head_ref> origin/<candidate>` — the correct base is the one where the upgrade
+branch's merge-base is its tip's parent (i.e. `<head_ref>` is already directly on that line —
+then NO cherry-pick is needed, the raw branch compares clean). Cherry-picking onto the wrong
+base produces the very messy 3-dot compare this guard exists to prevent (real case: gitea —
+first "rebase" landed on a stray `main` and had to be redone onto `master`).
+
+**Branch-name mismatch mirror vs upstream.** The mirror and upstream can use different base-branch
+names (gitea: mirror `main`, upstream `master`). When emitting step 3 (the post-merge release),
+NEVER hardcode `main` — derive the upstream default branch from the existing remotes (`git
+remote show origin` or `git ls-remote --symref origin HEAD`) and emit `git checkout <that>;
+git fetch origin; git merge --ff-only origin/<that>;` before `abra recipe release`.

scripts/gen-cctest-skills.py

@@ -78,9 +78,42 @@ not the test server — so it can run either way. Probe, then follow that branch
   4. Everything else in the canonical script (origin/dev remote setup, release recommendation,
      emitted next-steps) is identical.
 
+Every time the branch was prepared **here**, remember it exists only on this host — the
+operator's machine must fetch it first. Always emit this **step 0** before the push step
+(anonymous public fetch, no credentials needed):
+
+```
+  # 0. On a machine WITHOUT the branch pre-fetched, get it from the autonomic mirror
+  #    (fetch by URL — works regardless of what the local remotes are named):
+  cd <local checkout of the recipe>
+  git fetch https://git.autonomic.zone/recipe-maintainers/<recipe>.git +refs/pull/<PR_NUM>/head:refs/heads/<HEAD_REF>
+  git checkout <HEAD_REF>
+```
+
+If the operator's checkout does NOT yet have the mirror remote, emit once before the fetch:
+
+```
+  git remote add gitea https://git.autonomic.zone/recipe-maintainers/<recipe>.git
+```
+
 In both modes the final output is a set of commands for the operator to run on a machine **with
 push access to `git.coopcloud.tech`** — always print them, even when everything local is
 already prepared.
+
+**Verify the merge-base BEFORE rebasing — bases can be traps.** Upstream repos can
+carry a stray, divergent `main` ALONGSIDE the real `master` base branch. Rebase targets must be
+chosen by evidence: `git ls-remote origin | grep -E 'refs/heads/(main|master)$'`, then
+`git merge-base <head_ref> origin/<candidate>` — the correct base is the one where the upgrade
+branch's merge-base is its tip's parent (i.e. `<head_ref>` is already directly on that line —
+then NO cherry-pick is needed, the raw branch compares clean). Cherry-picking onto the wrong
+base produces the very messy 3-dot compare this guard exists to prevent (real case: gitea —
+first "rebase" landed on a stray `main` and had to be redone onto `master`).
+
+**Branch-name mismatch mirror vs upstream.** The mirror and upstream can use different base-branch
+names (gitea: mirror `main`, upstream `master`). When emitting step 3 (the post-merge release),
+NEVER hardcode `main` — derive the upstream default branch from the existing remotes (`git
+remote show origin` or `git ls-remote --symref origin HEAD`) and emit `git checkout <that>;
+git fetch origin; git merge --ff-only origin/<that>;` before `abra recipe release`.
 """,
 }