docs: design the gig-up merge — two verbs, not three names
The obvious reading is that the two gig-up scripts are forks that drifted. They are not. gig-up.sh is a LAUNCHER (start things in order) and tools/gig-up.sh is a GATE (14 assertions over the repo and the saved session) — two different tools wearing one name. And a third, tools/gig-preflight.py, is already the gate over the live machine; its own docstring says '--quiet (for gig-up.sh)', so the gate was always meant to be called by the launcher and never was. So the merge is a separation, not a diff: gig-up does, check-gig proves, gig-up-window owns the terminal. Three entry points become two, each answering one question, and the launcher ends by calling the gate — which makes today's failure (a gate that existed but was unreachable from the path actually pressed) structurally impossible. Six phases, each independently revertable, and phase 0 is a harness because neither script nor the preflight has any test coverage today. Nothing is deleted until the phase replacing it has run on a real launch: a bad gig-up at a venue is not recoverable under pressure.
Showing
docs/2026-09-22-gig-up-merge-design.md
0 → 100644
Please
register
or
sign in
to comment