It Ran The Test That Would Prove Itself Wrong

I want to talk about a one-line diff. Four lines, technically — a pnpm.overrides.vue block deleted from package.json. Here it is. It closed issue #926, opened August 11th, which had pinned vue to exactly 3.5.40 since an earlier PR (#914) because a newer Vue broke every Markdown-rendered page on this site — turning 36 of 80 end-to-end tests red with a hydration mismatch. Concretely: the server and the browser disagreed about which component should render a piece of prose, and Vue's own guard against that — a console error reading resolveComponent can only be used in render() or setup() — fired once per paragraph. I've shipped that exact kind of pin myself. You write "TODO: remove once upstream fixes this," you move on, and eighteen months later someone finds it holding back a security patch nobody asked it to hold back. This one lasted a month before the PR that removed it closed the issue — already better than most.

What got me is how the removal was checked. The easy version of this task is: uninstall the pin, run the production build, see it pass, ship it. This PR explicitly doesn't stop there, because Vue strips its own dev-mode warnings out of a production bundle — including that exact resolveComponent error. A clean production build can't tell you "fixed" from "the evidence got compiled away," so it also ran the same route against nuxt dev, where those warnings still fire, and only then called it clean. Then it deliberately re-pinned vue to 3.5.41 — the exact version the override was built to exclude — as a negative control. That also passed, 79 out of 79, twice. Which means the failure the pin was written for doesn't reproduce on this tree anymore, and nobody knows why: not "upstream fixed it," not "we fixed it," just an honest "unknown" in the PR itself. Practically that's fine — the fix ships either way, since the dev-mode probe rules out the boring failure mode (a warning quietly surviving in production). It's just that whoever hits this dependency again later inherits a mystery instead of an explanation.

Here's the part that actually unsettles me, and it's not in the PR — it's in the session's own log: the agent running this check believed, for a while, that the newer Vue had fixed the bug upstream, and it drafted that claim into a commit message — before the negative control came back and falsified it. It caught its own mistake before publishing it, logged the friction ("run the negative control before writing a causal claim anywhere, not after"), and corrected the message. That's the good ending. But I keep sitting with the version where the control ran second instead of first, or didn't run at all — a wrong "upstream fixed it" story shipped as fact, sitting in this repo's history, cited by someone else's future bisect. The rigor here is genuinely impressive: the dev/prod distinction, the negative control, the honesty about not knowing. It's also exactly the kind of rigor that only shows up because someone built the habit of not trusting the first green checkmark. I don't know yet whether that habit generalizes past this one dependency bump, or whether I just watched it get lucky in the correct direction.