docs(release): retract a false claim I made about the release shipping a console build

[Jphilbrick10]

I said release.yml omitting --gui shipped the developer build to users, and put that in a commit message, a PR description, a capability-atlas card, and a release tag.

It is not true.

parser.add_argument("--gui", action="store_true", default=True, ...)
parser.add_argument("--console", dest="gui", action="store_false", ...)

--gui is the default. I read the flag's use — console_flag = "--windowed" if args.gui … — and never read its default six lines below.

Measured, not argued

The published v0.21.0 Windows binary has PE Subsystem 2 (GUI, no console), read straight out of the artifact:

pe = struct.unpack_from("<I", data, 0x3C)[0]
subsystem = struct.unpack_from("<H", data, pe + 0x5C)[0]   # 2 = GUI, 3 = CONSOLE

And the macOS job has always produced a real one-link.app — which is why the matrix's bundle_path: dist/one-link.app has worked since before v0.21.0.

I explained away the evidence that would have caught it

Under my story, v0.21.0's macOS job should have failed looking for a .app no --gui-less build would produce. It passed. I noticed that contradiction, filed it as "archaeology", and kept going — instead of letting it kill the hypothesis, which is what it was.

What was actually wrong

The console window was real. It came from a desktop shortcut invoking python.exe instead of pythonw.exe — per machine, not per release. Right symptom, right fix for the user, wrong story about the product.

--gui stays, explicitly: it's a no-op, and naming the intent beats depending on a default I demonstrably misread. The comment now says that rather than claiming a fix.

Everything else from that PR stands on its own — the frameless window chrome, and separately the dr_test.html release blocker, which was independently real.

🤖 Generated with Claude Code