the bump report names the pin_map edge paths and no LEAF path, and no edge's served value — a wave's report carries the counts and none of the names of what moved #61

What I observed

The bump report names the pin_map EDGE paths and no LEAF path, and no edge's served value. A wave's report therefore carries the counts and none of the names of what actually moved.

Measured on the umbrella's own tree, 2026-10-27 (opencharly/opencharly#750, pin wave 12), on a LIGHT tree — 409 declared paths, 396 of them with no checkout at all:

$ ./charly/bin/charly task sync
task sync: 2 step(s), 0 failed, 0 skipped
  [pass] run — bump the pins (charly rolls first, then distro-* from its new gitlinks)
      pinned 6 pin_map entr(y|ies) (distro-arch, distro-cachyos, distro-debian, distro-fedora, distro-omarchy, distro-ubuntu; 1 moved) after rolling 7 leaf submodule(s) to their default-branch HEAD (1 moved) and advancing 396 leaf pin(s) in the index (0 moved); 2 pin(s) moved

What the verb did: 409 pins — 396 advanced in the index, 7 leaf submodules rolled, 6 edges re-pinned. What the report says: 2 pin(s) moved, the six edge paths, and three counts.

The three things a reader needs, and what the report gives.

So the operator cannot tell from the report what moved, and cannot see the phase order's dependency: the edge's served value is only reachable after the leaf has moved, and the report shows the edge's name and the leaf's count as two independent facts.

Why this is filed here and not folded into #26

#26 is a behaviour question (what a "preview" may do to a working tree) and it is answered on its own thread. This one is message-shaped, the same class as #25 (the accounting and the diagnostic in this same verb) — the walk already collects what the report needs, and the report does not print it.

The RCA

• Mechanism. The walk collects three name lists — done (paths rolled in a checkout), inIndex (paths advanced in the index) and pinned (the pin_map entries) — and the report prints a name list for ONE of them (pinnedNames). The two leaf groups are reported by their LENGTHS only. The moved counters were added to the same message later (plugin-task#53) as counts, so the message grew two numbers where the paths were already in hand.
• Missed control. The accounting fix (bump: the report counts index WRITES, not pins that moved — 406 reported, 4 moved #53) pinned that every group carries a TOUCHED count and a MOVED count. Nothing pinned that a group which MOVED a path also NAMES it — so a group can report 1 moved with the path unnamed, and no test can see the difference. The edges are the one group that is named, and the naming is what makes the asymmetry invisible: the report looks detailed.
• Blast radius. Every wave's report, in every repo that uses the verb. The wave's own scope is visible only afterwards, in the diff — and the report is the only warning there is while the sweep runs. The near-miss this caused is recorded in charly task sync reads like a targeted tool and is an org-wide pin cutover — 422 pins, 30+ checkouts, nothing warns beforehand opencharly#501: an org-wide sweep run to move one pin, with nothing announcing its scope.
• Root fix. Each group names the paths that MOVED, with the value each moved from and to; each edge names the twin value it was served. The TOUCHED counts stay (they are the write count), and the report stays a message — no new mode, no new input, no behaviour change.

The shape is open, and here is what I would choose

The moved set is the small one in a healthy wave (2 of 409 above) and the touched set is the large one, so the moved paths are the ones worth naming — a report that printed 396 names would be the report nobody reads. The values are what make a name actionable: charly b6a108d80b -> c4f... says what moved, and distro-fedora: served from charly's b6a108d80b says which tree the edge was pinned from — the dependency the phase order exists to create.

Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0

Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)