Improving on what the four-line plist incident looked like from the outside: PR #17 fixed two files. The inline plist block in macos-launchd-tcc.mdx had /Users/<your-username>/ in the path string rendered on the live site. The template script in scripts/launchd/ had three more absolute-path strings. Correctness review shipped the article. Privacy review didn’t exist yet.
What I took from PR #17 wasn’t that I’d been careless. The gap was a missing checklist for the right category of review. For most software, correcting the code and publishing it correctly are one job. On a personal technical site published under a real name, they diverge.
What the privacy reviewer is actually checking
Code review asks: does this function compute the right thing? Does this query return the expected rows? The reflex is correctness — a function of logic and intent.
Privacy review on a personal technical site asks something different. Not: does this plist work? But: does this plist example contain a real path segment that identifies who wrote it? Not: is this project link accurate? But: does this project link connect a personal brand to another entity in a way that was never decided?
Technical content is the worst category. An article about a launchd configuration needs a plist example. The plist example needs a path. You will use the real path because you copied it from the working config, and that path contains your username. The article goes to review as a prose document. The prose reviewer reads for clarity, accuracy, grammar. Nobody is running grep -r "$USER" across the MDX before the commit.
PR #17 was the fix for not having that grep. The commit created the rule: scrub macOS usernames from published content. The pre-commit hook in ~/.git-hooks/pre-commit enforces it. Bypass token is BBBRAIN_NAMELEAK_BYPASS=1 for any deliberate exception.
That covers one layer. There are two more.
The three layers
Identifier strings. Usernames in paths. Real email addresses. GitHub handles. The PR #17 category. Literal strings in published files that resolve to a real identity. The pre-commit hook catches them. This layer is solvable with tooling.
Project attribution. Which projects appear on the site, attributed how, to whom. The /creative section added the first music track in June: Tasogare — Cinematic Boom Bap, uploaded to YouTube. That link connects the personal site to a YouTube channel. The choice of channel, and whether it connects to a real name, a pseudonym, or a business account, is a decision that has to be made before the link ships. No hook catches this. It is a decision, not a string.
Entity linkage. This is the layer with no technical surface at all. While planning the /work/ expansion in July 2026, the standing position was made explicit: Captain Random (the personal site) and Byte Bridges (the software business) are two separate entities. The site does not link them. Projects get discussed architecture-first, not company-first, and the business name stays out of the content.
That sounds like a simple rule. Enforcing it requires the reviewer to read every project card, every bio paragraph, every work-history entry, and ask: does this sentence connect Captain Random to Byte Bridges? No hook exists for that. No grep pattern catches it. It is a standing editorial rule that the reviewer has to hold in their head and apply to every new section.
Why layer three is harder than it looks
The plist example was the easy case. Literal string. The hook finds it.
Entity linkage is the hard case. A violation does not look like a violation. A sentence like “I build software for businesses, including this project” might be accurate and publishable. Or it might be the sentence that connects Captain Random to Byte Bridges for the first time. The difference is context, not content. No grep returns a match.
Publishing under a real name means holding two operating identities at once: one personal, one business. The reviewer has to carry that distinction into every review. That reviewer is also the person who wrote the article.
The privacy page is not the privacy work
When the newsletter launched in June 2026, a privacy policy landed at /privacy/ alongside it. Standard pattern for a site collecting email addresses. The page documents what gets collected, how long it lives, who sees it.
It is not the work described above. A policy page does not prevent a username from shipping in a plist example. It does not enforce entity separation. It does not review the YouTube channel attribution on a music track.
The privacy page is for the reader. The review checklist is for the publisher.
The mastery tracking decision
The learning mastery feature added in July stores progress data device-locally. One write, four reads, no server sync. That is a privacy decision made at architecture time, not review time. Device-local by design means no data-handling commitment on the privacy page, no sync infrastructure, no breach surface. The decision lived at design time. Nothing to review at publish time.
That is the pattern to repeat: make the privacy decision at design time so it does not need to be caught at review time.
The checklist that now exists
Layer one (identifier strings):
- Replace real paths with
<your-username>placeholders in any published code block containing absolute paths - Add a substitution step to any install runbook that needs real paths at install time
- Pre-commit hook blocks literal username strings in staged content;
BBBRAIN_NAMELEAK_BYPASS=1required for any deliberate exception
Layer two (project attribution):
- Decide the platform account and attribution approach before writing the section
- Review checks the link against that decision, not against generic accuracy
Layer three (entity linkage):
- Standing rule: Captain Random and Byte Bridges are separate; the site does not connect them
- Reviewer applies the rule manually to every new section; no automation possible
The pre-commit hook is the floor, not the solution. The solution is having all three decisions made explicitly and the reviewer holding all three when the content goes to commit.
Out of scope: anonymisation (the site is explicitly published under a real name). Per-platform pseudonymous accounts (a future decision, not a standing one).
The four-line PR that started this is not the outlier case. It is the illustration of what happens when layer one has no checklist. The entity separation decision is what layer three looks like when it gets made before something ships rather than after.
