What a parallel review taught me about publication gates

I was moving a pack of lab plans, deployment files, and project snapshots between machines. Some of it was private working material. Some was meant to become public portfolio evidence. Before pushing anything, I wanted to know whether the instructions matched the files, whether they matched the lab, and whether the public copies exposed anything they should not.

I ran the review across September 26 and 27. I used one coordinating session and eight worker sessions across the review and follow-up rounds, with Claude and Codex as tools for document and repository inspection. I produced seven read-only reviews in the first pass. In later sessions, I checked the fixes and the repositories that had changed.

My first secrets pass missed material that I found in other review passes. In the final sweep, I caught a disclosure in the commit messages of the cleanup work itself. Both changed what I now require before publishing technical evidence.

Give each review a boundary

I gave each initial review one bounded, read-only brief: a particular payload, the deployment configuration, consistency between documents, or secrets and internal exposure. I allowed inspection and reporting, without authorizing changes to the pack or live infrastructure.

The severity scale was small. A blocker stopped the affected item from shipping. A warning needed attention without necessarily stopping its intended private use. An OK result meant a stated check had passed within its scope. Findings needed a file location and a suggested correction.

I collected those reports into a go/no-go list in the coordinating session. Conflicts became decisions for me to resolve before the repair work started. Repository visibility, conflicting configuration proposals, and the hardware-validation gate were separate choices. Finding a problem did not authorize a replacement design; I had to make that decision.

That separation also made the parallel work reviewable. I could trace a proposed change back to a finding and its evidence, instead of accepting a pile of edits from several sessions at once.

Check the plan against the lab

I had prepared parts of the transfer pack with an assistant without giving it current infrastructure context. The prose sounded settled, but it described old hardware, treated completed work as pending, and proposed DNS changes at a provider that was no longer authoritative.

The lab’s own repositories supplied the operational history and recorded decisions. I used a private records repo as the starting point, then checked claims against read-only observations where necessary. Even the repository inventory had a stale DNS entry, so I could not treat every committed sentence as current merely because it was versioned.

This mattered before execution. A syntactically valid runbook can still send someone to the wrong control panel or tell them to overwrite newer work with an older snapshot. The consistency review found those problems by comparing the instructions with their sources and with the actual transfer contents.

Three disclosure patterns the first sweep missed

In the initial secrets review, I used pattern searches and inspected repository history. Dedicated secret scanners were unavailable in that session, which I recorded as a gap. I found a publication blocker, but my clean verdicts for other material were too broad.

In other review passes, I found three missed classes.

The first was signed CDN URLs in image sidecar JSON files. The images looked like ordinary assets; adjacent generation metadata carried signed links and account-related information. Reviewing only the visible image would not inspect that material. The sidecars were removed from the unpublished repository history before its first push, and a later sweep checked that they were absent from the fetched history.

The second was sanitization notes that quoted what they had removed. The public copy described its cleanup by repeating a private repository link and original webhook paths. The explanation had become another copy of the disclosure. The corrected notes described categories and replacements without reproducing the original values.

The third was identifiers shared between public and private workflow copies. Replacing credentials and hostnames had left node and webhook IDs unchanged. Those IDs were another link between the example and the private source. They needed a comparison against the private copy, not just a search for familiar token formats.

The follow-up regenerated the public node and webhook IDs. The final comparison parsed both sets and measured zero overlap for the 133 node IDs and three webhook IDs in the public templates.

There was still a useful qualification. A broader UUID search found shared condition-rule IDs nested inside a few workflows. Those were editor metadata, not demonstrated credentials or callable endpoints. They did contradict a blanket claim that no identifiers matched. The report kept that as a warning: narrow the claim or regenerate the remaining IDs. It did not turn every matching string into a secret.

Pixelation is not redaction

The same publication boundary applies to screenshots. My rule is to remove sensitive content from the exported image, not make it harder to read with blur or pixelation. I do not count a pixelated field as cleared for publication.

That is a handling rule, not a claim that this review recovered text from pixelated images. The concrete image-related finding here was in the sidecar files. It showed why the review has to cover the asset and the files that travel with it.

For screenshots, I keep the original in private evidence, use opaque redaction or crop the sensitive region from the public copy, and inspect the flattened export. OCR helps locate text, but I still check the final image visually. Embedded metadata, filenames, captions, and sidecars need their own pass. A screenshot can have every visible secret covered while an adjacent file still publishes an account identifier.

The cleanup leaked through commit messages

The final repository sweep found private repository names in commit messages on six public branches. The changed files could look clean while the messages described private projects involved in the wider cleanup. Those messages were already public.

The proposed changes were recreated on clean branches with corrected messages and replacement pull requests, and the superseded requests were closed. The repair proceeded without force-pushing. That corrected the proposed publication path; it did not establish that the earlier messages had vanished from every retained reference or copy. I treat their prior visibility as a disclosure, not something a later clean commit can undo.

The standing rule now covers every text surface attached to public work: file contents, commit messages, PR titles, and PR descriptions must not name private repositories. I describe their roles generically, such as “a private records repo” or “a private infrastructure repo.” The same rule applies to this post even though its source repository is private.

This also separates two different repairs. Removing sensitive artifacts from unpublished history before its first push is a prepublication cleanup. Replacing a proposed public change after its messages have been visible does not carry the same assurance. The report needs to say which one happened.

What I now require before publishing

The later sweeps combined Gitleaks with custom checks for the disclosure patterns the reviews had found. They covered archive contents and Git history as well as current files. A clean credential scan did not settle questions about private project names or matching workflow IDs, so those kept their own checks.

My publication gate now asks for a few explicit answers:

Which artifact and destination were reviewed, including whether the repository is private but its output is public?
Which claims were checked against operational records, and which still depend on an assumption or an open decision?
Did the checks include attachments, metadata, archives, commit messages, and relevant history?
Was each correction checked in the final artifact, with a narrow statement of what passed and what remains open?
Who has approved the remaining release decision?

I kept the briefs, findings, decisions, and verification records as private evidence. This public account leaves out the identifiers that made the findings sensitive in the first place.

For the move toward platform engineering, this is work I can explain in an interview: how I limited access, reconciled conflicting reports, stopped unsafe publication, and checked the repairs. The sessions made parallel inspection practical, but I still owned the scope, the decisions, and the claims I was willing to publish. The missed findings are part of that evidence too.