Ticket graphs

Self-repopulating successor (the #196 pattern: append-only governance means a ticket cannot reopen, so the work perpetuates by spawning its successor). UNIT KEY : forge-rw:successor:dz_debug:g2 CHAIN : dz_debug GENERATION : 2 HIGH-WATER-MARK : code__code__jazz__litellm__dz_debug 5 forge repo(s) past the high-water-mark are still un-enumerated. Run the ticketer again to file the next batch of at most 4 unique module(s), resuming from the mark: python3 checkouts/current/congruency/tools/forge_refactor_ticketer.py --file-tickets --batch 4 --gen 2 --subset dz_debug The `--gen 2` pins the run to THIS ticket's generation, so it will not mistake this very ticket for a successor someone else already filed; it then spawns generation 3, and the chain continues after this ticket settles. DROPPING THE FLAG DOES NOT KILL THE CHAIN (it used to — see #245). With no --gen the ticketer DERIVES its generation from the queue: the highest OPEN successor of this chain is normally this very ticket, so a plain `--file-tickets --batch 4` reaches the same conclusion and spawns the next generation anyway. Keep the flag regardless — it is what makes a run started from a STALE copy of this line (one the chain has already moved past, because a NEWER successor is open) correctly DECLINE, instead of adding a redundant successor. It is IDEMPOTENT: it re-files nothing already ticketed — a module already carrying a rewrite ticket is skipped by its module-sha, whether this chain filed it or another did. Run it with no --file-tickets first to see the next batch without writing anything. A stop ticket aimed at #201 (or at this ticket) is the brake for this chain. Filed mechanically by checkouts/current/congruency/tools/forge_refactor_ticketer.py under ticket #201.

— browse congruency source (forge-parked tree)