A false claim at runtime
A third-party integration I depend on daily was forked and hardened months earlier, with external network access stripped out and a security note in the readme saying no data leaves the machine.
That claim was false at runtime, and the repository had drifted twenty-six published releases behind upstream without anyone noticing — because the hardened files were never being loaded.
Verify by timestamp, not by reading
The vendor’s server copies its own three plugin files over the install path on every single start, and the readme tells you to import from exactly that path. The proof is that those three files carried a timestamp matching the current session’s server start, and were byte-identical to the freshly downloaded package.
Reading the source I controlled proved nothing about the bytes that ran. It is the same mistake as auditing a package by reading its readable source instead of hashing its shipped artifact.
The second decision was how to resolve latest against mine, because those genuinely conflict. Hand-editing a vendored blob loses every upstream fix. Pinning loses twenty-six releases. The answer is a script that fetches the newest package, re-applies a small named patch set, and refuses to install if any vendor reference survives the filter.
A sync that can fail closed
A sync script that pulls the latest published package directly rather than from a cache, renames the plugin to mine, filters the permitted network domains down to local-only matches, clears the cloud relay host, and then hard-fails the install if a single vendor string is left. It also empties the vendor’s install directory and locks it, so that copy cannot regenerate as a second importable plugin competing with mine.
A rewritten verification script that checks the installed version against the latest published, greps for leakage, counts the available commands, warns when the wrong directory could be the one the tool imports, and flags multiple listeners on the port range.
A readme with the ghost sections deleted. The old one advertised six capabilities that returned zero matches in my plugin, the vendor’s plugin, and the vendor’s server. They were never built. The security section now states what is actually true — including that the server itself is unaudited upstream code.
Separately, a deploy guardrail that blocks release and production targets and refuses any deploy without an explicit destination, written after a build landed on a shared box because the deploy target was inferred from where a local proxy pointed.
Checking the running version
The live manifest had been permitting a connection to an external relay the whole time, while the document beside it promised the opposite. Comparing the installed files with the running version exposed the mismatch.
Two of my own bugs the same session are worth recording, because they were the sneakier failure. A quoting error inside a script turned a strict-mode line into a silent early exit mid-run. And a counter written too narrowly under-reported 109 available commands as 74 — a verification counter that undercounts is worse than no counter, because it presents as missing features and sends you looking in the wrong place.
One command
Twenty-six releases of upstream fixes recovered in one run, with the command surface going from 105 to 109 and the patch surface held at five references — the number that makes the sync reliable rather than fragile.
One command now brings the fork current and refuses to install anything carrying a vendor reference, so latest and mine stopped being a choice. The deployment check runs automatically, so it does not depend on remembering to ask an agent.