A lane binding is observed, never reserved: two places can wait on one release and both bind (Amendment 18 clause (c), the residual window) #84

Lane: openRepoTools-3 (openRepoTools-3)

Raised by Copilot's first round on #83 (Amendment 18's tooling), in three places at once — lane:971, lane-start:1898, lanes-edit.sh:8430 — and it is one finding:

Returning 0 once a poll sees released|free is only an observation, not an ownership reservation. Two lane-start/lane invocations can wait on the same release, both exit through this branch, and then independently write STARTED/RESUMED; commit_push rebases both append-only writes rather than rejecting the second, creating two bindings.

It is real, and it is not closable without a ruling. Amendment 18 clause (c) ends "When one arrives the lane is free and the requester binds as it would have" — and "as it would have" is this tooling's ordinary bind, which has always been read that nothing holds the lane, then write. lane-start's step 3 (live_holder) has that shape and has had it since Amendment 6. What #83 adds is a second door into it, not the shape itself.

The protocol has an arbiter for exactly this, and it is not applied to lanes. Rule 1 decides a race for an OBJECT by which CLAIMED lands on main first: fetch, pre-check, append, push, and on a rebase RESCAN and write CLAIM-LOST if somebody else's landed first. A lane binding has no such act — write_event appends and commit_push rebases, so a second STARTED lands beside the first rather than losing to it.

What #83 did do, and what it deliberately did not. It narrowed the window where that is free:

• lane-start re-reads binding immediately before the rename, which is its first act with an effect, and refuses naming where the lane went (3d). The window is then one read wide rather than a question, a rename, two register writes and a launch wide.
• lanes-edit.sh request-handoff --force re-reads the binding immediately before its append and refuses when it moved, so a forced release cannot land on a holder that arrived after the scan.
• request-handoff's own wait already refuses when the lane is released and bound again while it waits.

It did not invent a reservation. A lane-scoped claim — a CLAIMING/BOUND verb decided by push order, with a BIND-LOST for the loser, on Rule 1's own model — is a new act on in-force text, and this estate's rule is that such an act is ratified before it is built, never smuggled into an adoption PR.

What a ruling would have to settle

1. Does a lane binding get Rule 1's race at all, or is the narrowed window accepted as the cost of an append-only log with no locks?
2. If it does: which verb, and does the loser write a line (a BIND-LOST is a line in an append-only log about a lane that never was) or simply refuse?
3. Does the rescan belong in write_event for the lane-kind verbs, or in lane-start around its own append?

Until then the behaviour is: narrowed, named in the code where it is narrowed, and filed here.

🤖 Generated with Claude Code