Commit efdb09f1 by PLN (Algolia)

docs(board): the fast-forward promise now carries its proof

Two sessions checked each other and each found what the other missed. I
measured that the tree was not waiting on a commit; the peer re-derived that
independently, then added the two checks my recommendation lacked -- that HEAD
is a true ancestor (so it is a real fast-forward, not a merge in disguise) and
that the branch touches none of PLN's five modified .tidal files.

That second one is the one that mattered. Recommending a checkout across
somebody's live set prep without measuring the direction is how a repair
becomes a clobber, and I had asserted the switch was clean on the strength of
the two tools files alone.

Both verified here before recording them. The caution that remains is real and
unchanged: the fast-forward swaps code under a running rig.
parent c4eb90be
......@@ -2421,3 +2421,27 @@ Also parked, from the peer session (not mine, logged so it is not lost): the
Take100; today's Take102 exists only on the laptop). The Freebox is the declared
SSOT for audio ([[feedback_freebox_ssot]]), so no space-reclaim work should
touch it until it has caught up.
### The two-command fast-forward, now with its proof (peer-verified both ways)
The peer session amended `043` (`71403a2`) and re-derived the blob hashes with a
different tool before changing it. It then added the two checks the
recommendation above was missing, and both now measure clean:
* `git merge-base --is-ancestor HEAD origin/claude/rig-streamline`**true**.
`5468507` really is an ancestor of `f56775a`, so it is a genuine
fast-forward and not a merge wearing one's clothes.
* The branch touches **none** of PLN's five modified `.tidal` files
(`veridis_quo`, `tous_ensemble`, `piment_bresilien`, `sunny_side_up`,
`rose_rouge`). His set prep survives the switch untouched. This is the check
that could actually have hurt — never say "safe" about his tracks without
measuring the direction ([[feedback_volume_is_not_direction]]).
So the remaining caution is real but it is a DIFFERENT one from the false
precondition: the ff swaps code under a running rig and then wants
`parvagues-bridge`, `midiviz` and `perf-tray` restarted. That is PLN's call,
with eyes on it.
Worth keeping from the exchange: cross-checking caught one error in each
direction. Neither session would have found its own
([[feedback_check_the_instrument_first]]).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment