Skip to content

chore: remove downstream-consumer product names from all tracked files - #156

Closed
totalslacker wants to merge 1 commit into
mainfrom
chore/purge-legacy-consumer-name
Closed

totalslacker wants to merge 1 commit into
mainfrom
chore/purge-legacy-consumer-name

Conversation

@totalslacker

Copy link
Copy Markdown
Owner

Why

This repository is public. Tracked files referenced two private consumer product names — the current one and its pre-rename predecessor — 40 occurrences across 12 files, including cross-repo citations to private issue trackers (totalslacker/<private>#254, #344, #394). Those citations resolve to nothing for any external reader and disclose more about the package's consumers than a public repo should.

What changed

Replacements are neutral — "a downstream consumer", "the consumer's embedder" — rather than substituting one product name for the other. Renaming the old name to the current one would be the same leak in newer branding.

Cross-repo citations to private trackers are replaced with substantive descriptions of what actually changed, since a private issue number tells an external reader nothing.

Code changes are limited to test-local identifiers:

Before After
safariUnfuckerRegressionTest searchWriteStallRegressionTest
print("[SafariUnfucker] …") print("[StallRegression] …")

The new log tag matches the existing [PerfTest] precedent. No API, type, or behaviour changes. Technical content of the affected ADRs is untouched — only the names of who reported what.

Verification

git grep -iE "safariunfucker|webbrain|veilpix"   →  0 results (all tracked files)
swift build                                       →  Build complete
swift test --filter SQLiteStorageConcurrency      →  2/2 passed
    ✓ Write completes while slow FTS read is in flight (WAL liveness)
    ✓ Bulk write loop is not stalled by a concurrent slow FTS scan
      [StallRegression] tIsolated=0.0043s tConcurrentWrites=0.0041s ceiling=0.0343s

Not addressed here — needs a decision

16 commit messages in the existing history contain the predecessor name. Rewriting them requires a force-push on a public repo, which invalidates every clone, fork, and pinned commit SHA — including the revision consumers currently depend on. That is a deliberate call, not something to slip into a text cleanup.

No recurrence guard is included. A grep-based CI check would need to contain the forbidden strings to detect them, reintroducing into the tree the very thing it protects against. Resolving that (encoded pattern, CI secret, or partial match) is worth doing properly rather than hastily.

🤖 Generated with Claude Code

This repository is public. Tracked files referenced two private consumer
product names — the current one and its pre-rename predecessor — 40
occurrences across 12 files, including cross-repo citations to private
issue trackers. Those citations are unresolvable for any external reader
and disclose more than a public package should about its consumers.

Replacements are deliberately neutral ("a downstream consumer", "the
consumer's embedder"), not a substitution of one product name for the
other: naming the current product in a public repo is the same leak
wearing newer branding.

Cross-repo citations to private trackers are replaced with substantive
descriptions of what changed, since an issue number in a private repo
conveys nothing to a reader who cannot open it.

Code changes are limited to test-local identifiers:
  safariUnfuckerRegressionTest -> searchWriteStallRegressionTest
  print tag [SafariUnfucker]   -> [StallRegression]
matching the existing [PerfTest] precedent. No API, type, or behaviour
changes. Technical content of the affected ADRs is untouched — only the
names of who reported what.

Verified: git grep -iE "safariunfucker|webbrain|veilpix" returns nothing
across all tracked files; swift build clean; SQLiteStorage WAL
Concurrency suite 2/2 passing with the renamed test.

Not addressed here: 16 commit messages in the existing history contain
the predecessor name. Rewriting them means a force-push on a public
repo, invalidating every clone, fork, and pinned SHA — including the
revision consumers currently depend on. That needs an explicit decision,
not a side effect of this cleanup.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant