diff --git a/.opencode/skills/cctest-recipe-upstream/SKILL.md b/.opencode/skills/cctest-recipe-upstream/SKILL.md
index 1db8420..2710596 100644
--- a/.opencode/skills/cctest-recipe-upstream/SKILL.md
+++ b/.opencode/skills/cctest-recipe-upstream/SKILL.md
@@ -72,16 +72,14 @@ In both modes the final output is a set of commands for the operator to run on a
 push access to `git.coopcloud.tech`** — always print them, even when everything local is
 already prepared.
 
-**History-divegence check before emitting the compare URL.** The autonomic recipe-maintainer
-mirrors' `main` can share only a distant ancestor with upstream `main` (same work re-committed
-with different hashes as the mirror was synced/rebuilt). A 3-dot compare
-`main...<head_ref>` from the raw mirror branch then shows the ENTIRE diverged history, not the
-one upgrade commit. Guard: while preparing, run
-`git merge-base <head_ref> <base_ref>`; if the result is older than a few commits below upstream
-`origin/main`, cherry-pick the upgrade commit(s) onto fresh upstream `origin/main` (branch
-`<head_ref>-rebased`), push THAT to the autonomic mirror, and emit the fetch/push/compare commands
-using the rebased branch instead of the raw one. Also fix the stale `origin/main` wording above:
-the upstream base branch may be `master`, not `main` — derive it from the remotes.
+**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),
diff --git a/scripts/gen-cctest-skills.py b/scripts/gen-cctest-skills.py
index 7d1d9e0..bd74f60 100644
--- a/scripts/gen-cctest-skills.py
+++ b/scripts/gen-cctest-skills.py
@@ -100,16 +100,14 @@ In both modes the final output is a set of commands for the operator to run on a
 push access to `git.coopcloud.tech`** — always print them, even when everything local is
 already prepared.
 
-**History-divegence check before emitting the compare URL.** The autonomic recipe-maintainer
-mirrors' `main` can share only a distant ancestor with upstream `main` (same work re-committed
-with different hashes as the mirror was synced/rebuilt). A 3-dot compare
-`main...<head_ref>` from the raw mirror branch then shows the ENTIRE diverged history, not the
-one upgrade commit. Guard: while preparing, run
-`git merge-base <head_ref> <base_ref>`; if the result is older than a few commits below upstream
-`origin/main`, cherry-pick the upgrade commit(s) onto fresh upstream `origin/main` (branch
-`<head_ref>-rebased`), push THAT to the autonomic mirror, and emit the fetch/push/compare commands
-using the rebased branch instead of the raw one. Also fix the stale `origin/main` wording above:
-the upstream base branch may be `master`, not `main` — derive it from the remotes.
+**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),