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:audio_tagger:g1 CHAIN : audio_tagger GENERATION : 1 HIGH-WATER-MARK : (none — chain is fresh) 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 2 unique module(s), resuming from the mark: python3 checkouts/current/congruency/tools/forge_refactor_ticketer.py --file-tickets --batch 2 --gen 1 --subset audio_tagger The `--gen 1` 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 2, 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 2` 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)