Skip to content

Release 2.1.200 (2026-08-22)

Bug fixes

  • roll ad-hoc archives past GitHub's 100-sub-issue cap (#2873)
  • fix(epics): roll ad-hoc archives past GitHub's 100-sub-issue cap

The scheduled ad-hoc drain crashed once a quarter's archive epic reached GitHub's hard limit of 100 sub-issues: reparent_child is rejected and, because the drain runs org-wide, one over-full quarter blocked every repo's drain.

Add in-quarter overflow segments. Segment 1 keeps its original unsuffixed title (no migration); a quarter that reaches the cap spills into ' (2)', ' (3)', etc. The roll threshold is 95, leaving a 5-slot margin below the hard 100 cap for concurrent-run races. A pure _segment_placements helper holds the roll logic; the batch drain fills forward across segments in one pass.

Fix both reparent sites sharing the same root cause: the batch apply_adhoc_drain and the on:issues.closed rollup path (via the new capacity-aware ensure_writable_adhoc_archive), so neither can land a child in a full archive.

  • docs(epics): cross-reference the two ad-hoc archive re-parent sites

The batch drain (apply_adhoc_drain) and the on:issues.closed single-child path (rollup) both re-parent closed children into ad-hoc archives and both must honour the per-segment cap. They can't be merged (batch vs single-child), so add a comment at each site pointing at the other: change the shared capacity helpers rather than open-coding a reparent, and keep the two aligned when segment fill/roll behaviour changes.

CI Evidence: All gates passed — full audit bundle available. Download →