docs(gap-baseline): retract false main-history-splice claim (shallow-clone artifact)

docs/product-technical-gap-baseline.md

@@ -2649,6 +2649,23 @@ Higgins, S. S., Crepalde, N., & Fernandes, L. (2021). Segmented multiplexity: A
 
 **Follow-up.** If the organization later solves free+ZDR routing robustly enough to deliberately widen required-review CI to `orchestrator/auto` (e.g. once a spend ceiling and reviewer-visible cost evidence exist for that path), the change is exactly one `case` arm plus the corresponding assertions in `test_sidecar_pins_the_pool_to_free_for_github_actions` — this entry is the record of *why* it was narrowed, not a permanent prohibition.
 
+## 2026-09-02 — RETRACTED: `main`'s history was NOT spliced; the "unrelated histories" wall was a shallow-clone artifact
+
+**This entry retracts and replaces a same-day entry that incorrectly claimed `main`'s history had been spliced onto new roots around 2026-08-20/21.** That claim was wrong. Do not act on it. It was already posted as individual triage comments on 16 open PRs (#1027, #1046, #1058, #1053, #1035, #991, #1061, #1060, #1036, #1112, #1062, #939, #1051, #933, #932, #1065); every one of those 16 posted comments has since received a follow-up retraction comment linking here. Two more (#1147, #1009) had the same comment queued but never posted — no comment exists on those two and none is needed. If you find any PR with the original claim and no retraction reply, post the same retraction (template in the 16 comments above) before triaging it any other way.
+
+**What actually happened.** The analysis sandbox's local clones of this repo (`/home/user/.github` and, separately, `ContextualWisdomLab/noema`) were **shallow clones** (`git rev-parse --is-shallow-repository` → `true`, with `.git/shallow` listing several commits from ~2026-08-22 through 2026-08-25 as fake history "roots"). Two well-known, easily-confused-for-a-real-splice symptoms follow directly from a shallow clone and require no actual history rewrite to produce:
+
+1. `git rev-list --max-parents=0 origin/main` reports the shallow boundary's commits as root commits — they look exactly like disjoint history roots even though the real, full history is a single connected line above them.
+2. `git merge` (and `git pull`) run from inside a shallow checkout genuinely does raise `fatal: refusing to merge unrelated histories` when the merge target's shared ancestor sits before the shallow boundary — this is git's real, documented behavior for shallow clones, not a bug in the diagnosis tooling, which is exactly why it read as convincing evidence of a real split.
+
+**The correction.** `git fetch --unshallow origin` (run against `/home/user/.github`) resolved the clone to full depth. After that: `origin/main` has exactly **one** root commit (`0c6e99ed0acab17b1cdd9f853a8398ddb0eed269`), and `731af58e` (the commit the retracted entry claimed was "not reachable from current `main` at all") is now correctly recognized as a normal ancestor (`git merge-base --is-ancestor 731af58e origin/main` → true). A `noema` checkout in the same sandbox was found shallow too (unrelated to this specific false claim, since no splice claim was ever made about `noema`, but unshallowed proactively for the same reason). `contextual-orchestrator`'s checkout was not shallow and was unaffected.
+
+**How the false claim was caught.** A Devin Review comment on this PR (the one that originally carried the false claim) directly disputed it — "All 15 listed heads share a merge base with current `main`, and `731af58e` is its ancestor" — and asked for the ancestry checks to be re-run against exact recorded SHAs with reproducible evidence. Re-running `git merge-base --is-ancestor 731af58e origin/main` against a *freshly fetched* `origin/main` still returned false at first (because the local clone was still shallow), which is what led to actually checking `git rev-parse --is-shallow-repository` rather than trusting the ancestry check at face value — that check was the missing step in the original triage pass. The bot's specific claim that all 15 heads shared a merge base with `main` was itself imprecise (it does not distinguish "shares a merge base" from "is a fast-forward-mergeable ancestor," and a shallow clone's merge-base computation near its truncation boundary is not generally reliable either), but its core objection — that the "unrelated histories" diagnosis needed independently reproducible verification before being published and acted on — was correct, and prompted the check that found the real cause.
+
+**Standing lesson — verify this before ever diagnosing a multi-root or "unrelated histories" condition on any repo in this ecosystem:** `git rev-parse --is-shallow-repository`. If it prints `true`, run `git fetch --unshallow origin` (or clone without `--depth`) *before* running any `git rev-list --max-parents=0`, `git merge-base --is-ancestor`, or `git merge` diagnosis. A shallow clone will produce a "multiple roots" / "unrelated histories" signature that is indistinguishable from a real history rewrite without this check. This sandbox does not shallow-clone every repo by default (`contextual-orchestrator` was full-depth), so the presence or absence of this problem is per-checkout, not a fixed environment property — check it every time, on every repo, before trusting an ancestry or root-commit result.
+
+**Corrective actions taken:** retraction comments posted on all 16 affected PRs (listed above); the second, larger triage pass that was queued to continue applying the same false diagnosis to more PRs was stopped before it posted beyond the 2 comments already covered above; no merges, pushes, force-pushes, or branch rewrites were made on the basis of the false diagnosis at any point (the recommended remediation was comment-only by design, which limited the blast radius to incorrect guidance rather than lost work) — confirmed via the stopped triage agent's own read-only action log.
+
 ## 2026-09-02 org-queue-sweep investigation: historical conclusion superseded by PR #1821
 
 **Current status (2026-09-04).** The conclusion below was invalidated by live queue evidence. PR #1821 removed the organization-wide Actions-run inventory and cancellation block from `org-queue-sweep` and merged as `11bb6a7871f4d95ab8a3eab616b4264d02327010`. Native per-PR concurrency and the current-head coalescer now own stale-run cancellation; the scheduled sweep retains only missed review, merge, and branch-update recovery. Focused ownership contracts passed 78 tests before merge. This preserves the event-gap recovery described below without paying the repository-wide run-listing and cancellation API cost.