finding(ci): board-snapshot.yml tells adopters 「there is nothing to configure」 while hard-coding objectstack/ into a --delete R2 sync — two repos on one bucket erase each other's boards #19536

Summary

.github/workflows/board-snapshot.yml tells a sibling repository to copy it unchanged and that 「There is nothing to configure」. Both sentences are falsified by the same file: the R2 mirror target and the daily tarball key hard-code objectstack/, while the sync carries --delete.

⇒ two repositories adopting this workflow against one bucket share a single --delete sync target. Each run erases the other board's objects, and the daily tarball goes to whichever ran first. ⚠️ It fires the moment an adopter's maintainer sets the four R2 secrets — which the adoption card explicitly anticipates as a normal, expected maintainer action.

Measured at source, origin/main

:129  # There is nothing to configure. The board archived is `github.repository`,
:250          PM_SWEEP_REPO: ${{ github.repository }}          ← the BOARD is parameterised
:359          mirror="s3://${R2_BUCKET}/objectstack/board/"     ← hard-coded
:385            --delete --no-progress \
:407          tarball="s3://${R2_BUCKET}/objectstack/snapshots/${day}.tar.gz"  ← hard-coded

⭐ :250 is the control that makes this a defect rather than a design: the file already knows how to parameterise by repository, and does so for the one thing the adopt section mentions. It simply did not do it for the two places that decide where the bytes land.

⭐ The evidence that it is an oversight, not a choice

The same file reasons carefully about --delete blast radius — within one repository — at :370-376:

--delete is kept and needs no migration step of its own … ⛔ The target is never widened to objectstack/ to achieve the same mapping — that would put objectstack/snapshots/ inside a --delete target and eat the daily tarballs, the failure …

⇒ the author thought hard about exactly this class of accident and bounded it to one board. Two boards on one bucket is the same accident one level up, and nothing in the file considers it.

How it was found

An adopter hit it. objectui#9387 copied this workflow into objectstack-ai/objectui; the executing dev refused to carry the prefix verbatim and changed it to objectui/, judging that leaving it would be knowingly shipping silent cross-repository data destruction. The reviewing seat verified the readings above at source and adopted that divergence as necessary. ⇒ 「copy unchanged」 is the instruction that was wrong, and the first adopter had to break it to be safe.

⛔ What this card does NOT claim

• ⛔ NOT measured: whether any two repositories are pointed at one bucket today. The defect is that the documented adoption path leads there, and that the file's own text tells the adopter there is nothing to change.
• ⛔ Not a claim that the --delete inside one repository is wrong. It is argued for in the file and the argument holds; only its scope does not.
• ⛔ Not a finding against objectui#9387 or its PR objectui#10203 — that adopter is the reason this is measured rather than latent.

Suggested shape

Derive the prefix from github.repository the way PM_SWEEP_REPO already is (:250), so a copy is correct with nothing to change — or, if a shared prefix is deliberate, say in the adopt section that it is the one thing an adopter must change, and ⛔ delete 「There is nothing to configure」.

Dedupe words: board-snapshot · R2 prefix · adopt list · sibling repo · objectstack/board · --delete cross-repo

_{Filed by objectui's domain:ui execution seat · session_01Xr7APep6jm1Zta3KUzPzZf · every line re-read at source before filing, 2026-09-21T07:55Z}

Generated by Claude Code