Repository navigation
task: post-detach verification against the pre-detach snapshot #162
Description
Parent: #158.
Prove the detach did what we wanted and broke nothing, by diffing against the pre-detach snapshot.
Corrected 2026-10-03. The original version of this checklist expected our commit SHAs to return 404 under
Kpa-clawbot/CoreScopeafter the detach. That was wrong and would have made a successful detach look like a failure. Settled empirically on a disposable fork — see the correction comment. Detaching stops future object sharing but does not retract objects already in the network.
Checks
Did it work
| check | expected |
|---|---|
gh api repos/OKI-Mesh/CoreScope -q .fork |
false |
parent / source |
absent (NONE) |
repos/Kpa-clawbot/CoreScope/commits/66aa4c5 |
still 200 — pre-detach objects are retained upstream by design |
repos/Kpa-clawbot/CoreScope/commits/ff5e338 |
still 200 — same |
| a commit pushed after the detach | 422 / not found upstream — this is the real proof that sharing stopped |
| Sync fork button | gone from the UI |
The load-bearing check is the second-to-last one. Push a commit after detaching and confirm it is not reachable upstream; that is what distinguishes a completed detach from a stalled one. Note the detach is asynchronous and took ~75 s on the test repo, so fork staying true for a minute after the click is normal.
Did anything break — every row re-read and diffed against the snapshot in #160: repo settings, rulesets (including bypass_actors), both self-hosted runners online, Actions variables (ENABLE_STAGING_DEPLOY still true), secret names, labels, board links, webhooks, open issue and PR numbers, GHCR tags.
Issues, PRs, comments, stars and watchers are not at risk — verified on the test repo, all preserved across the detach. The docs warning about losing them applies to the manual clone-delete-recreate procedure, not the Settings path.
Does it still run
git log origin/master -1matches the snapshot SHA exactly — history unchanged.- A no-op commit or manual dispatch produces a green
CI/CD Pipelineon master. 🚀 Deploy Stagingstill reaches thecorescope-dev-offbandrunner.
Is upstream still watchable
git fetchofhttps://github.com/Kpa-clawbot/CoreScopeas a plain remote still works.gh pr list -R Kpa-clawbot/CoreScopestill works.
Both already verified as detach-independent in #159 (control test against grafana/grafana, a repo we have no fork relationship with).
Done when
Every check above is recorded here with its actual output, and any row that differs from the snapshot is either fixed or has its own issue.
Activity
diffwireauto commentedon Oct 3, 2026
Correction: the 404 checks in this issue are wrong and must not be used
This issue's "Did it work" table expects our commit SHAs to return 404 under
Kpa-clawbot/CoreScopeafter the detach. They will not. Anyone running this checklist as written would conclude the detach had failed when it had succeeded.Replaced by measurement, not reasoning. Tested end to end on a disposable fork,
OKI-Mesh/fork-detach-test(a 1 KB public fork ofoctocat/Hello-World, meeting the same three preconditions as CoreScope), detached by the owner 2026-10-03 ~02:36Z.What the experiment showed
[verified: api 2026-10-03]e717edc6d4bf44Detaching stops future object sharing. It does not retract objects already in the network. Every commit pushed to CoreScope while it was a fork stays readable under
Kpa-clawbot/CoreScopepermanently, including commits on branches we have since deleted.Accepted, not a problem to solve: this is public code, and what went upstream is upstream's to hold.
Corrected "Did it work" table
gh api repos/OKI-Mesh/CoreScope -q .forkfalseparent/sourceNONE)repos/Kpa-clawbot/CoreScope/commits/66aa4c5repos/Kpa-clawbot/CoreScope/commits/ff5e338The load-bearing check is the last-but-one: push one commit after detaching and confirm it is not reachable upstream. That is what distinguishes a completed detach from a stalled one.
Also verified by the same experiment — nothing is destroyed
[verified: api 2026-10-03]The docs warning on Detaching a fork reads: "The new repository will not retain any of its issues, pull requests, wikis, stars, watchers, comments, child forks, or other metadata." That warning belongs to the manual clone → delete → recreate procedure further down the same page. It does not apply to the Settings path.
Measured across the detach on the test repo:
fork/parent/sourcetrue/octocat/Hello-Worldfalse/NONE/NONEmergeable=truehas_issuesSo CoreScope's 124 issues and 33 PRs are not at risk, and #160's snapshot does not need to attempt the impossible job of preserving issue history. It covers settings, which is what it can cover.
Detach completed in roughly 75 seconds and is asynchronous, as the docs state —
forkstayedtruefor over a minute after the click. Do not read that interval as a failed detach.Provenance of the error
The original table was written from the assumption that severing the network withdraws shared objects. That was never tested before being written into a verification checklist. The owner's prior knowledge was correct: what goes upstream stays upstream.
The test repository has been deleted now that the result is recorded here.
#162 post-detach object-sharing probe
#162 post-detach object-sharing probe
diffwireauto commentedon Oct 3, 2026
Post-detach verification: 34 of 34 pass
Detach completed 2026-10-03T03:05:17Z, ~60 s after the owner's click. All checks below
[verified: api + box 2026-10-03].Did it work
forkfalseparent/sourcenetwork_count0(was 67)repos/Kpa-clawbot/CoreScope/commits/66aa4c5repos/Kpa-clawbot/CoreScope/commits/ff5e338aeeb798, pushed AFTER the detachThe last row is the load-bearing proof. A throwaway branch carried one commit, it was confirmed unreachable under the former parent, and the branch was deleted in the same run.
Did anything break — nothing
mastertipff5e338f8c2bb612477e2a1bbb75040d0a9c567b18667552 Protect Maindeletion,non_fast_forward,pull_request,required_status_checksOrganizationAdmin/always,RepositoryRole 5/always✅ Go Build & Testcorescope-dev-offband,deadbeef-prodENABLE_STAGING_DEPLOY=truePROJECT_PATThe required-check context deserves a note: the automated run flagged it as a mismatch, but that was this session's console decoding gh's UTF-8 as cp1252. Re-read as bytes and decoded explicitly it is
U+2705 U+0020 U+0047 U+006F ...— identical to baseline, and identical to thename:of the job indeploy.ymlthat produces it. That exact-string match, emoji included, is what the whole required-check mechanism depends on, and it survived.Does it still run
CI/CD Pipelinedispatched on master atff5e338after the detach, run37092118347:Detect changes✅ Go Build & Test🏗️ Build & Publish Docker Image🚀 Deploy Staging🎭 Playwright E2E TestsDeploy Stagingran on runnercorescope-dev-offband, 03:20:46 → 03:21:54[api: actions/runs/37092118347/jobs], and the dev container came back healthy on the box[box: offband, docker ps]. Self-hosted runners, GHCR publishing and the dev deploy path all work with no fork relationship.Is upstream still watchable — yes
git ls-remote --heads https://github.com/Kpa-clawbot/CoreScope.git master→093e320c2bdagh api repos/Kpa-clawbot/CoreScope→ reads fineBoth are ordinary public-repo operations, independent of any fork link, as #159 established with
grafana/grafanaas a control.Outcome
CoreScope is a standalone repository. The Sync fork network button is gone, so no future one-click merge of upstream can undo what #144 removes. Nothing was lost in the process.
Accepted and unchanged: commits pushed while CoreScope was a fork stay readable under
Kpa-clawbot/CoreScopepermanently. Only post-detach commits are ours alone.Remaining under the Epic: #163 (how we track upstream now the link is gone) and #164 (live CI still had the pre-handover registry hardcoded — fixed on
fix/164-release-fast-path-registry, awaiting a PR grant).