[potiuk]

What

vetted-op-tracker rollup-append (and rollup-amend-latest / rollup-fold, which share the lookup) recognised only the legacy status-rollup marker, <!-- <tracker-name> status rollup v1 — … -->. Skills and the rest of the framework (preflight-audit's skill-marker check, the issue-sync bulk-mode classifier, skill-evals fixtures) recognise skill comments by the <!-- apache-magpie: <kind> v<N> --> marker, and adopters' rollups carry <!-- apache-magpie: status-rollup v1 -->. On those trackers rollup-append did not find the rollup and created a separate comment with the legacy marker. Every later pass then grew that second comment.

Change

• rollup_format.py (vetted-ops) and its identical copy rollup.py (github-rollup):
  • ROLLUP_MARKER = "<!-- apache-magpie: status-rollup v1 -->" is what a new rollup starts with.
  • CANONICAL_MARKER_RE / LEGACY_MARKER_RE match the two marker shapes. is_rollup_body matches either one, and is_canonical_rollup_body matches only the canonical one.
  • find_rollup_index(bodies) returns the first comment with the canonical marker, or the first legacy one when there is none. A tracker that has both keeps growing the canonical rollup.
  • marker_line / build_new_rollup_body still accept the old tracker_name argument so existing callers keep working, but they ignore it.
• procedures._find_rollup (vetted-ops) and cli._find_rollup (github-rollup) now use find_rollup_index. New rollups no longer get the tracker name in their marker.
• The entry envelope is unchanged: <details><summary>DATE · @actor · Label</summary>, a blank line, the body, a blank line, </details>, with the --- ruler and blank lines between entries.
• tools/github/status-rollup.md, both tool READMEs and the issue-invalidate skill now name the canonical marker and say the legacy one is still recognised. The issue-invalidate measured_tokens stamp is refreshed.

github-rollup is fixed here too. Its rollup.py is byte-identical to rollup_format.py, and skills use both tools. If only vetted-ops changed, github-rollup would not find the canonical rollups that vetted-ops creates, and would make duplicates.

Tests

• tools/vetted-ops: covers a new rollup getting the canonical marker; appending to legacy-marker rollups (any tracker name); the canonical rollup winning over an earlier legacy one for both append and amend; no second rollup being created next to a canonical one; fold refusing a legacy-marker rollup; marker detection cases; and find_rollup_index. uv run pytest: 396 passed. ruff check, ruff format --check and mypy are clean.
• tools/github-rollup: the same cases for the CLI and the formatter. 54 passed, and ruff and mypy are clean.
• tools/preflight-audit: 42 passed (unchanged; it already accepts both markers).
• prek run --files <changed> passes, with lychee and workspace-pytest skipped.

Not in scope

• tools/forgejo/status-rollup.md and tools/local-tracker still describe or write the legacy marker on their own backends. They can follow separately.
• rollup-fold still refuses to fold a legacy-marker rollup into the canonical one, because folding would nest <details> blocks. Merging two rollups stays a manual step, as the spec's hard rules say.

🤖 Generated with Claude Code