From 2ea496040991db156ab5b39089a3eba614d88cf9 Mon Sep 17 00:00:00 2001 From: Alec Wenzowski Date: Sat, 22 Aug 2026 07:20:03 +0000 Subject: [PATCH] docs(memory): every key a PR carries moves its row, and DO-NOT-CLOSE does not stop it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CLOUD-847's arm I deferred one obligation: write the attachment half beside the closing-key entry the next time anything touches this file. `39dc672` was that change and went in without it, so this lands both halves — and the second one corrects what `39dc672` itself concluded. That entry read "the branch name lost" from CLOUD-860 moving on #635. Re-read from the board, CLOUD-847 — the branch's own row — moved on exactly the same events, and so did both rows on #639's open and merge. Nothing lost; every key a PR carries moves its row on both events, and every one collects the attachment as a union. Three consequences, and none of them was written down: - arm I's starvation prediction does not reproduce. A row cannot end In Review with no PR attached while an unrelated row hoards them, so `graph-check`'s `in-review-no-pr` is not at risk from a branch naming another key. - `DO-NOT-CLOSE` is an exemption from `closing-key-check`, not a hold on the automation. #639 declared it, closed nothing, and moved two rows twice. - a PR OPENING drags a linked row backwards: #639 knocked CLOUD-860 out of the In Review #635 had just given it, back to In Progress, for work that was not its own. The completion half stands unchanged — `Refs:` still does not close, and no row here reached Done. The one tension left is named rather than smoothed over: #398's `Refs:`-only body moved nothing while #639's moved two rows, and the discriminating measurement is written down for whoever needs it. DO-NOT-CLOSE — this corrects a memory entry and completes no row; CLOUD-847's own completion is a release. Refs: CLOUD-847 --- .serena/memories/workflow/board-states.md | 42 +++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/.serena/memories/workflow/board-states.md b/.serena/memories/workflow/board-states.md index 37bb7e2e7..cf5c4dade 100644 --- a/.serena/memories/workflow/board-states.md +++ b/.serena/memories/workflow/board-states.md @@ -354,6 +354,48 @@ Review`, exit 1. It is `landed-check`'s terminal twin — both name In Review hand-correction here from the older wording wrote the prediction twice before the board falsified it. +- **"The branch name lost" was measured on one row and read as a contest. It is + not one: EVERY key a PR carries moves, and every one collects the + attachment.** The entry above is right that a `Closes` key is what redirects + _completion_; it is wrong to conclude the branch's own row sat still. Both + rows moved, on both events, on both PRs — re-read from the board 2026-08-22, + from the same two PRs the entry above cites. + + | event | PR (branch names CLOUD-847) | body | CLOUD-847 | CLOUD-860 | + | ----------------- | --------------------------- | --------------------------------- | ------------------------ | ---------------------------- | + | opened `22:22:19` | #635 | `Closes CLOUD-860` | → In Progress `22:22:22` | (claimed by hand `22:21:49`) | + | merged `23:24:33` | #635 | " | → In Review `23:24:35` | → In Review `23:24:35` | + | opened `23:26:18` | #639 | `DO-NOT-CLOSE`, `Refs: CLOUD-860` | → In Progress `23:26:21` | → In Progress `23:26:21` | + | merged `00:27:23` | #639 | " | → In Review `00:27:26` | → In Review `00:27:26` | + + Three things follow, and the third is the one that costs something. + + **Attachment is a UNION, not a winner.** #635 and #639 are each attached to + both rows. So the starvation shape CLOUD-847's arm I predicted — a row ending + In Review with no PR attached while an unrelated row hoards PRs it did not + produce, which is exactly what `graph-check`'s `in-review-no-pr` refuses — + **does not reproduce.** Do not re-derive that fear from the precedence entry + above; it is about state, and attachment does not behave like state. + + **`DO-NOT-CLOSE` stops `closing-key-check`, not the board.** #639 declared it, + closed nothing, and still moved two rows twice. It is an exemption from the + body convention, never a hold on the automation — a PR deliberately not + completing its row should expect the row to move anyway, and check. + + **A PR opening drags a linked row BACKWARDS.** #639 knocked CLOUD-860 out of + In Review, where #635 had just landed it, back to In Progress — a row losing + ground to a PR that was not its work. `landed-check` names a board behind git + and is the gate that catches this; the fix is a hand-move forward, and the + avoidance is not to mention a settled row in a body that is about to open a PR. + + What this does NOT overturn is the completion half. `Refs:` still does not + _close_ (#398 vs #400 above stands, and no row here reached Done). The + unresolved tension is narrower than it looks: #398's `Refs:`-only body moved + nothing at all, while #639's moved two rows to In Review. The discriminating + variable is untested — likeliest that #398 predates the merged→In Review + mapping's effect on merely-linked rows. Whoever next needs it should measure a + `Refs:`-only PR against a row in Todo, and write the condition down. + - **It does not guard on the source column, so it can resurrect a dead issue.** CLOUD-35 was **Canceled** when that merge landed, and the automation moved it to Done — a closed-out issue silently reappearing as completed work it never