Release archival maroons merged PRs: milestone-gated, but PRs carry no milestones

Context

Operator-reported during the v13.0.0 release thread ("pulls did not get archived at all"), V-B-A'd to mechanism. The v13 archival moved 1,715 issues into resources/content/archive/issues/v13.0.0/ but only 120 pulls into archive/pulls/v13.0.0/ — while 1,325 merged PRs remain in active resources/content/pulls/, including samples merged squarely in the v12.1.0→v13.0.0 range (pr-11530.md closedAt 2026-05-17, pr-11592.md 2026-05-18, pr-11666.md 2026-05-20).

Release classification: post-release data hygiene (the v13 web presence ships either way; the active pulls tree just stays 10× oversized until fixed).

The Problem

The archival predicate is milestone-gated: resolveMilestoneArchiveBucket (ai/services/github-workflow/sync/PullRequestSyncer.mjs:75-92, mirrored in IssueSyncer.mjs:86-103) archives an item only when (a) the target bucket dir was pre-created (the opt-in) AND (b) the item carries that milestone. Issues receive milestones in the release flow; PRs overwhelmingly do not → the gate never opens for them. The operator's intended semantics — "a release ARCHIVES all items closed in the timerange; backlog stays" — and the implemented semantics diverge exactly where milestone assignment is sparse.

The Architectural Reality

• PullRequestSyncer.mjs:75-92 — the opt-in bucket resolution (existsSync gate + milestone candidate).
• The active pulls corpus: resources/content/pulls/chunk-* (1,325 files, mostly state: MERGED with in-range dates).
• The analyzer buildScripts/release/analyzeClosedSinceRelease.mjs:321 already documents the intended range semantics: "PR source: resources/content/pulls/**/*.md with state: MERGED and mergedAt >= cutoff" — the range-based definition exists in prose, the syncer implements milestone-based.
• Sibling precision: the issues side worked for v13 because the release flow mass-milestones closed issues; the same sparse-milestone hazard exists there for any unmilestoned closed issue.

The Fix (shape — implementer verifies against the sync service's invariants)

Either (1) the archival predicate for PRs falls back to mergedAt-in-release-range when no milestone is present (range = previous release tag date → current, matching the analyzer's documented semantics), or (2) the release flow mass-assigns the milestone to merged-in-range PRs the way it does for issues, keeping one predicate. Option (2) keeps the syncer untouched and fixes the data at the source of truth (GitHub) — likely the smaller diff and the more truthful record. A one-time backfill (milestone or move) for the 1,325 marooned PRs accompanies either shape.

Acceptance Criteria

• Merged-in-range PRs archive on the next release cycle without manual milestone curation (whichever predicate shape is chosen).
• One-time backfill: the currently marooned merged PRs (≈1,325 minus genuinely-post-v13 merges) land in their correct version buckets.
• The issues/pulls archival predicates end up consistent (same rule or explicitly documented divergence).
• analyzeClosedSinceRelease.mjs's documented range semantics and the syncer's implemented semantics agree.

Out of Scope

• The empty-source-folder cleanup gap (sibling ticket, same surface) and the v8-era misattribution residue (separate historical thread, #12186 family).

Related

#12186 (closed syncer-correctness epic), #12188/#12194 (closed bucketing-floor + re-bucket fixes), #12999 (deep-link map — regenerates over whatever buckets exist, unaffected).

Live latest-open sweep: checked latest 12 open issues at 2026-06-12T13:40Z + creations since are known (#12996, #12999); no equivalent found. A2A in-flight sweep: clean.

Origin Session ID: 3e1566f6-6336-4db4-8726-189004578d8b

Retrieval Hint: "pulls not archived milestone gate mergedAt range marooned merged PRs v13"