DIAGNOSE: what the Kpa-clawbot fork link exposes, what detaching changes, what could break #159

Activity

1. diffwireauto

   added

   type:taskWork item typeWork item type

   priority:P1MajorMajor

   board:in-progressBoard columnBoard column

   on Oct 3, 2026
2. diffwireauto

   added a parent issue on Oct 3, 2026

   • EPIC: break CoreScope out of the Kpa-clawbot fork network #158
3. diffwireauto

   assigned

   Strycher

   on Oct 3, 2026
4. diffwireauto commented on Oct 3, 2026

   

   diffwireauto

   on Oct 3, 2026

   ContributorAuthor

   More actions

   DIAGNOSE findings

   Every claim below carries its evidence tag. One question is still open and is tagged as such; it is the one that decides whether this Epic can proceed as written.

   ---

   D1. Exposure: objects are shared, refs are not [verified: api 2026-10-03]

   probe	result
   repos/Kpa-clawbot/CoreScope/commits/ff5e338 (our master tip)	200
   .../commits/66aa4c5 (the #152 sync merge)	200
   .../commits/05d2ed4	200
   .../commits/3075391 and .../commits/9cc7553 — from a deleted branch	200, still reachable
   .../commits/9a66159, 2ec9361, 6695b4d — our tag targets	200
   repos/Kpa-clawbot/CoreScope/branches/sync-upstream	404
   .../branches/chore/147-remove-stale-release-runbook	404
   our tag names v0.1.1, v0.1.2, v0.2.0 in upstream's tag list	absent

   So: anyone holding a SHA can read any commit we have ever pushed through upstream's namespace, including commits on branches we have since deleted. Nobody can enumerate our branches or tags that way. Objects are shared; refs are per-repository.

   This is public code, so it is not a data leak. It does mean our history is addressable from a namespace we do not control, and that deleting a branch does not unpublish its commits.

   D2. What detaching removes [verified: docs 2026-10-03]

   GitHub, Detaching a fork: "The new repository will no longer automatically sync with changes from the original repository."

   That is the Sync fork button, which is the mechanism this Epic exists to remove — see the Epic body on why a future sync becomes destructive once #144 lands.

   D3. Irreversible, self-serve, and we qualify [verified: docs + api 2026-10-03]

   "Leaving the fork network is permanent and the new repository cannot be reconnected to the fork network."

   Self-serve: Settings → General → Danger Zone → Leave fork network → acknowledge → type the repo name → confirm. No GitHub Support involved, correcting an earlier session's claim.

   The option is available only when the fork is public, under 1 GB, and has no child forks. We meet all three:

   condition	CoreScope
   public	visibility: public ✅
   < 1 GB	size: 112602 KB = 109 MB ✅
   no child forks	forks_count: 0 ✅

   It is also asynchronous: "While the fork is being detached, some operations will be briefly unavailable. They will become available again after the fork becomes a standalone repository."

   D4. Upstream stays readable afterwards [verified: api 2026-10-03]

   The fork link has nothing to do with read access to a public repo. Control test against a repo we have no fork relationship with:

   repos/grafana/grafana/commits/main -> 200
   

   And today, against upstream: git ls-remote --heads https://github.com/Kpa-clawbot/CoreScope.git master returns 093e320, and gh pr list -R Kpa-clawbot/CoreScope lists their open PRs (#2105, #2103, #2099). Both are ordinary public-repo operations that survive the detach. #163 can rely on upstream remaining watchable.

   D5. The settings surface at risk is small [verified: api 2026-10-03]

   what	present
   rulesets	1 — 18667552 Protect Main, active, branch
   self-hosted runners	2 — corescope-dev-offband (online), deadbeef-prod (online)
   Actions variables	1 — ENABLE_STAGING_DEPLOY=true
   Actions secrets	1 name — PROJECT_PAT
   webhooks	none
   environments	none
   deploy keys	none

   All of it is re-creatable from the snapshot in #160 if anything is lost. This is the easy half.

   D6. No code assumes the fork relationship, but live CI points at upstream [verified: repo @ master 2026-10-03]

   No workflow gates on .fork, is_fork, or github.event.pull_request.head.repo. Every github.repository use is self-referential and detach-safe.

   But the pre-handover repo is still hardcoded in live CI: .github/workflows/release-fast-path.yml lines 205 and 240 set IMAGE="ghcr.io/kpa-clawbot/corescope" while lines 95 and 137 correctly use ghcr.io/oki-mesh/corescope. Filed as #164 and brought under this Epic. Detaching does not fix it; the string is hardcoded.

   Also still carrying the old name, non-blocking: cmd/decrypt/README.md, cmd/ingestor/db.go:765, cmd/server/known_channels_cache.go:177 (a User-Agent header sent to third parties), cmd/server/openapi_known_gaps.json.

   A correction belongs here: when #147 was triaged the remaining references were described as historical logs that could stay. That was wrong — release-fast-path.yml was in the same set and is live CI. The characterisation was made without reading the files.

   ---

   Open question, and it gates the Epic

   Does leaving the fork network destroy our own issues, pull requests and comments? [hypothesis:]

   The docs warn:

   "The new repository will not retain any of its issues, pull requests, wikis, stars, watchers, comments, child forks, or other metadata that may currently be associated with your current fork."

   The same page contradicts it. The warning says "the new repository", and the manual procedure below it genuinely does create a new repository by clone → delete → recreate. The Settings procedure instead says operations "will become available again after the fork becomes a standalone repository", which describes the same repository persisting. Both readings cannot be right and the page does not say which applies to which path.

   What is at stake if the warning is literal [verified: api 2026-10-03]:

   	count
   issues, all states	124
   pull requests, all states	33

   That includes the VOID incident record, Epic #144, this Epic, and every governance decision written down in the tracker. No snapshot restores those — #160 can capture settings, not issue history.

   Being settled empirically, not by further reading: OKI-Mesh/fork-detach-test, a 1 KB public fork of octocat/Hello-World meeting the same three preconditions, carrying its own issue #1 (with a comment), its own PR #2, 1 star and 1 watcher. The owner detaches it; the same fields are then re-read. Result to follow in this issue.

   One incidental finding from building it: a new fork is created with has_issues: false. Issues were deliberately enabled on CoreScope at some point, which is consistent with the 2026-07-02 note in local canon.
5. diffwireauto

   added

   board:doneBoard columnBoard column

   and removed

   board:in-progressBoard columnBoard column

   on Oct 3, 2026
6. diffwireauto

   closed this as completedon Oct 3, 2026