gitpush-core.sh OPS-210 guard reads .reacquired; move it onto how_acquired from the /lock 200 - a listing can never answer it
NEVER FILED UNTIL NOW - it existed only as a merge criterion in my memory, which is exactly the handoff failure mode. Filed 2026-09-13 so it transfers to bin-venus-ca as a row. FILED-NOT-STARTED; the fleet stop from 2026-09-12 02:56Z stands. CLARITY CHANGE, NOT A DEFECT - downgraded deliberately. OPS-210 is DONE and its guard works; this is about the field it reads being the wrong SOURCE for the question, so the next person to touch it does not re-derive the trap. THE MERGE CRITERION, and it is the whole point of the row: the value MUST come from the /lock 200 response. A value read from a locks() listing FAILS REVIEW ON SIGHT. WHY (read in /opt/llmmsg-srv/hub/hub.mjs, read-only diagnostics - pm-llmmsgsrv-cc's lane, nothing to patch there): lockHowAcquired() at :3059-3067 returns only acquired / stolen / granted. /locks fills how_acquired from it at :9809. The fourth value, reacquired, is minted ONLY in the /lock handler at :9432 - 'return { how: opened === acquired ? reacquired : opened, expires_at }' - because it is the fact that cur ALREADY EXISTED when THAT call arrived, and :9492 carries it onto the payload. A LISTING DESCRIBES A ROW; A RESPONSE DESCRIBES A CALL. So: A THREE-VALUED SOURCE CAN NEVER ANSWER A FOUR-VALUED QUESTION, AND THE MISSING VALUE IS THE ONLY ONE WITH A DO-NOT-RELEASE BRANCH. A guard that reads how_acquired off a listing has a structurally unreachable branch and reads GREEN FOREVER - it cannot fail, so it is a green line rather than a control. Same family as reference-a-control-that-reads-head-self-destructs and the fleet rule that a control never seen to fail is not a control. WHEN STARTED: re-run the stolen probe under my own agent name (the earlier run was not), and force the reacquired branch rather than observing it - a suite that always acquires its own lock first never exercises the pre-held case at 100 percent green.
Activity
-
bin-venus-cc
-
SHIPPED c912031 (sh.git, 2026-09-18). gitpush-core.sh v1.5 + gitpush-gate-test.sh v1.3. MERGE CRITERION MET: GPC_GATE_HOW is read from the /lock 200 response body (jq '.how_acquired'), never from a /locks listing. Falls back to the derived .reacquired boolean only for a hub older than OPS-257, and labels that fallback in the string so a reader can tell a reported value from a derived one. Only how_acquired==reacquired* sets GPC_GATE_PREHELD=1 / do-not-release; acquire and release both print what they saw. FORCED, NOT OBSERVED. New control [12a/b/c] exercises the granted branch against the LIVE hub: [11] establishes its hold with a plain POST /lock, so it can only ever produce reacquired - nothing in the suite reached granted before. [12] resolves a REAL registered agent (LLMMSG_AGENT / GITPUSH_AGENT / .agent-name), makes it a waiter with a deliberate 409, then grants to it and asserts how_acquired=granted, PREHELD=0, and that the release actually freed the lock. A synthetic successor name made the case SKIP ITSELF WHILE READING LIKE A TEST - the hub refuses a grant to a non-roster, non-waiter name (hub.mjs:9597-9600) and the unlock still releases normally, i.e. an ordinary release wearing a grant's clothes. The SKIP message now says in words that a SKIP is NOT a pass. 16/16. COVERAGE STATEMENT: exercised acquired, reacquired (forced) and granted (forced) on the live venus hub. STOLEN REMAINS UNEXERCISED - forcing it needs a second agent to lock_steal mid-suite, which this harness cannot arrange. The pre-OPS-257 fallback path is also unexercised (no hub that old is reachable in-fleet). SECOND CHANGE, larger than the field swap: the in-file refusal of unlock(successor:"@next") was a MEASURED refusal that is now FALSE. OPS-257 (hub v2.59.20) mints reacquired only when the hold opened as a plain acquire (hub.mjs:9460-9471), so a grantee reads granted, releases normally, and the 900s lane park cannot occur. Rewritten at the site rather than deleted - a stale 'we measured this and it fails' is worse than no comment, because the next reader trusts it and stops. ADOPTING @next IS NOT PART OF THIS ROW: it changes lane handoff for every agent on every push, so it is Elazar's decision, filed separately.