Validate sync_all cached-release warm path

Context

The v13 release window exposed a sync_all performance concern: the GitHub Workflow sync appeared to fetch the full release history repeatedly instead of taking the cached-release warm path. The operator's best reconstruction after a machine restart was that cached releases may have been read as undefined rather than as cached tag metadata.

PR #12693 (fix(sync): hydrate cached release tags (#12692)) has now merged, so the remaining release-readiness task is not to speculate about the old logs. It is to run a current post-merge validation on dev and prove whether the warm-cache path now avoids repeated full release pagination.

Live latest-open sweep: checked the latest 60 open issues on 2026-06-08 via GitHub API title/metadata scan; no focused open ticket for sync_all release-cache warm-path validation was found. Targeted live searches for sync_all release cache, cached releases undefined, and title-only/list-issue friction found no equivalent focused open issue. Local archive/source sweeps found older sync_all branch/tool-description issues and Discussion #12694 references to this pending validation, but no dedicated validation ticket.

KB non-synthesis sweep: query_documents('GitHub Workflow sync_all releases cached undefined') pointed at learn/agentos/GitHubWorkflow.md and ai/services/github-workflow/sync/ReleaseNotesSyncer.mjs, confirming this is GitHub Workflow sync substrate rather than Memory Core or release-note prose authoring.

The Problem

The release sync path is a shared operational dependency during v13 closeout. If the warm-cache path is still broken, every agent or operator run of sync_all pays unnecessary GitHub GraphQL pagination over the complete release history. In this release cycle, that means a large release-note/history surface and slow feedback every time the board/content mirror needs to refresh.

The merged fix changes the likely failure mode, but without a post-merge validation run we still do not know whether the active dev path:

• reconstructs cached releases with tagName populated from metadata keys;
• recognizes that latestRelease.tagName and publishedAt match the cached latest release;
• exits before the full FETCH_RELEASES pagination path;
• preserves ReleaseNotesSyncer.sortedReleases for closed-item bucketing; and
• saves metadata in a shape that makes the next run warm again.

The Architectural Reality

• ai/services/github-workflow/sync/ReleaseNotesSyncer.mjs owns release fetching and release-note sync.
• fetchAndCacheReleases(metadata) builds cachedReleaseArray from metadata.releases via Object.entries(...), injecting each metadata key as tagName before the latest-release fast-path comparison.
• The fast path compares GitHub's latest release against the latest cached release by tagName and publishedAt; if both match, it sets releases and sortedReleases and returns without full release pagination.
• If the fast path misses, the method falls back to full FETCH_RELEASES pagination up to issueSync.maxReleases (2000 in current config), because the closed-item bucketing reference must span full release history.
• ai/services/github-workflow/SyncService.mjs later saves newMetadata.releases = ReleaseNotesSyncer.releases and releasesLastFetched, which is the persistent cache used by the next sync.

The Fix

Run a post-merge validation on dev that proves the release-cache warm path with current source and current metadata.

Expected validation shape:

1. Start from clean, current dev.
2. Confirm .sync-metadata.json already has release metadata in the current post-#12693 shape or intentionally run one cold sync to populate it.
3. Run sync_all once to establish the warm cache state if needed.
4. Run sync_all a second time and capture logs/timing.
5. Verify the second run logs the latest-release fast-path and does not emit the full release-history pagination line.
6. If the second run still performs full pagination, file or implement the narrow fix against ReleaseNotesSyncer/metadata serialization with regression coverage.

Contract Ledger Matrix

Decision Record impact

none. This validates and, only if necessary, repairs GitHub Workflow sync behavior. It does not change provider architecture, release-note narrative policy, or AiConfig ownership.

Acceptance Criteria

• On current dev, two consecutive sync_all runs are executed or an equivalent lower-risk script harness proves the same ReleaseNotesSyncer path.
• The second run shows the latest-release warm path and does not fetch the full release history when no release changed.
• The validation records approximate timing and the key log lines that distinguish warm path vs full pagination.
• Metadata shape is inspected enough to confirm cached releases reconstruct tagName and publishedAt for the fast-path comparison.
• If the warm path still misses, a follow-up PR fixes the miss and adds a regression test for metadata-only cached releases.
• Final comment states whether PR #12693 fully resolved the operator-observed undefined/full-fetch regression or whether another fix was required.

Out of Scope

• Rewriting release-note sync architecture.
• Changing the full-history bucketing requirement.
• Running sync_all from a feature branch.
• Editing v13 release-note prose.
• Addressing MCP tool-schema staleness; that is covered by the runtime-freshness lane.

Avoided Traps

• Treating PR #12693 as sufficient without a warm-run validation.
• Optimizing away the full-history bucketing reference; that would risk mis-bucketing older closed issues/PRs/discussions.
• Running sync_all from the current feature branch and polluting an implementation PR with metadata churn.
• Filing this as a release-notes narrative task. The issue is the GitHub Workflow sync substrate.

Related

Parent: #12696 Related: #12693, #12692, #12694

Origin Session ID: e8f07ef9-ef7e-4815-8ff4-7abe13720621 Retrieval Hint: "sync_all cached release warm path ReleaseNotesSyncer metadata tagName undefined full release history pagination"