Reservation and announcement commits that abcd pushes to origin name the holder by their forge login: the Abcd-Holder and Abcd-Sender trailers carry it, and the announcement branch is named after it, so every reservation publishes which account made it in text and in the branch list.

Frontmatter

.abcd/work/issues/resolved/iss-2610290809526033-reservation-and-announcement-commits.md
open on GitHub ↗ · commit history ↗

mentions4

• dcn-26103005254314482026-10-30 — Withdrawals a person made under their login on a release that has ended, before their home keeps a holder id, are re-armed only once their first reservation or announcement keeps an id (iss-2610290809526033); until then the peers listing says each time that held merges from before the holder id stay held until that act, without naming the login. The cost accepted is that those merges stay held longer for a person who has not acted since the update. Three alternatives were rejected: minting the holder id on a read path such as the peers listing, since a read never writes the person's identity file; pushing a tombstone that names the login, since nothing pushed carries the login; and re-arming without the tombstone that claims the end, since that tombstone is the compare-and-swap that keeps two copies of the person from settling against different tips. The act that keeps the id writes each of those withdrawals under it, in the tombstone that settles them and in every later push of the person's that carries them, so no push names the login; a home whose id is set or kept but refused is not told the id is awaited, since every act refuses until it is fixed. Ruled by the facilitator on delegation from the product thinker.
• dcn-26103015160400542026-10-30 — An entry another holder recorded on a release before the holder id names that holder's login, which nothing abcd pushes may carry, so an act that writes one still to settle into a new commit writes it under one fixed, login-free marker, pre_id, meaning a holder from before the holder id, and keeps it on the release instead of refusing the act (iss-2610290809526033). The refusal it replaces left such a release with no act able to renew, release or settle it, and while it was still being cut it turned every new cut away. A marker entry is no reader's own in any first-record, own-record, vouching, acting or lost-withdrawal check, and no copy ever re-arms, withdraws again or admits it; renewals and take-overs carry it unchanged; the act that ends the release settles each one still to settle as manual, without asking the forge or posting on it, and prints one line naming its pull requests for their authors to re-arm by hand, naming no login. The write guard still refuses a withdrawal whose holder is neither a holder id nor the marker, so no act can add a login. The holder who first recorded the entry still finds it, through their own newest push rather than the tip: their own vouched entry for the pull request is kept over the marker entry and re-armed under their kept id, and the marker entry is dropped from that push. A release holds one entry for each pull request, and a commit listing one twice is never written. Another login's entry never displaces the reader's own: where two records are combined, the reader's own entry, as their own newest push records it, is kept over every other entry for its pull request, whatever that entry's state, vouching or place on the branch; between two entries neither of which is the reader's own, the entry still to settle is kept over a settled one, then the one its holder's own push vouches for, then, both vouched or neither, the one recorded earliest on the branch; this also fixes the default branch writing the reader's own entry beside another holder's for the same pull request. Rejected alternatives: dropping the entry, which loses the only record that the merge is held; and naming the login, which the holder id exists to keep off the remote. Ruled by the coordinating session on delegation from the product thinker.
• itd-2609151838312703Sessions under any account, on any machine or in the cloud announce what they are doing through short fixed-form announcements on the shared remote, a person reads everyone's status with one command, and what is really a hold stays a reservation
• spc-2610150728396006sessions-announce-what-they-are-doing