Context

Empirically observed across multiple recent PR cycles (#10258, #10261, #10262, #10264, #10266): the resources/content/.sync-metadata.json file accrues unrelated 2-line timestamp diffs in PRs that touch entirely different code. The file's lastSync and releasesLastFetched fields update, the rest stays identical, and these no-op-content diffs propagate into commits.

Per @tobiu's diagnosis this session: "on startup, it syncs tickets, prs, discussions. if there is content, it pushes to dev. however, if there is NO new content, it still seems to update the timestamp. worth an investigation ticket for future us."

The Problem

1. PR diff pollution: every multi-file PR accrues an unrelated 2-line diff. Reviewers waste cognitive cycles filtering it out. I flagged it on Gemini's PR #10261 as a polish item; Gemini's PRs #10264 + #10266 include the same noise; my own PR #10262 did not (because I used targeted git add, but the discipline isn't enforceable).

2. Merge-conflict surface: concurrent PRs both touch the same file; landings require resolution even though the semantic content is identical (different timestamps only).

3. Spurious dev commits: if the sync-metadata write triggers auto-push to dev (per the diagnosis), dev accumulates timestamp-only commits with no actual content delta. Graph observers scanning commit history see noise nodes.

4. Agent-confusion surface: agents editing tickets/PRs see the sync-metadata file show up in git status --short; whether to include or exclude it in scoped commits requires case-by-case discipline rather than architectural guarantee.

The Architectural Reality

• ai/mcp/server/github-workflow/ — the MCP server implementation
• resources/content/.sync-metadata.json — the sync state file carrying lastSync, releasesLastFetched, pushFailures, and per-issue content-hash cache
• ai/mcp/server/github-workflow/services/IssueSyncer.* + related — presumed location of the sync-orchestration logic

Hypothesized boot-sync flow:

1. Fetch remote (issues, PRs, discussions, releases)
2. Compare against local .md state (content hashes)
3. If any delta: write content to .md files + update .sync-metadata.json + push-to-dev
4. If no delta: still updates .sync-metadata.json timestamps + (may?) push-to-dev

Step 4's timestamp-only write is the root noise. Whether the push follows from the write unconditionally or via a separate code path requires investigation.

Candidate Fixes (investigation picks one or combines)

Option A — Guard the write: only write .sync-metadata.json when at least one content-relevant field changed (new/updated issue body, new PR, new discussion). Timestamps-only-change = no write.

Option B — Guard the push: allow the timestamp-only write locally but skip the commit/push if the only diff is timestamps in .sync-metadata.json. Keeps the sync-state cache warm for next-boot delta calculation without polluting dev.

Option C — Split the file (architecturally cleanest if the timestamps are truly operator-local telemetry): content-hash cache stays in version control; timestamps move to .sync-metadata.local.json which gets gitignored. Structural guarantee that no timestamp churn ever reaches a PR again.

Recommendation pending investigation: Option C if timestamps aren't load-bearing for cross-agent coordination (they probably aren't — the content-hash cache is what matters for delta calculation, not the when-last-fetched).

Acceptance Criteria

• Root cause identified — which specific code path writes .sync-metadata.json on boot-sync, and which (if any) pushes to dev unconditionally
• Fix applied per the selected option
• After fix: boot-sync with zero ticket/PR/discussion content changes produces zero .sync-metadata.json diffs (verified via git status after boot)
• PR diff verification: next multi-file PR from either agent track has zero sync-metadata noise unless ticket content genuinely changed
• Regression guard — either a CI check or a comment/log in the sync pipeline that makes future drift visible

Out of Scope

• Broader github-workflow MCP server refactor — fix this specific noise surface only
• ChromaDB metadata sync timestamps — different substrate
• Release-history fetching behavior if releasesLastFetched is architecturally separate from lastSync

Avoided Traps

• "Just add .sync-metadata.json to .gitignore": rejected. The per-issue content-hash cache IS load-bearing for delta calculation across sessions; losing it would force a full resync on every cold start.
• "Auto-strip the diff in a pre-commit hook": rejected. Hooks are opt-in and can be bypassed; structural fix at the write/push layer is stronger.
• "Teach every agent to git add selectively": rejected. Works for one session but relies on agent discipline rather than architectural invariant.

Related

• PR #10258, #10261, #10262, #10264, #10266 — all include (or were at risk of including) the .sync-metadata.json timestamp-only diff as unrelated noise
• ai/mcp/server/github-workflow/services/ — the investigation anchor

Origin Session ID

Origin Session ID: `cff20948-2dbb-4ac4-99e2-df2ebe967a4b`

Handoff Retrieval Hints

Retrieval Hint: `"sync-metadata.json timestamp boot-sync no-content-change push-to-dev noise"` Retrieval Hint: `"github-workflow MCP sync_all auto-push spurious commit"` Retrieval Hint: `"PR diff pollution sync-state cache timestamp churn"`

Commit-range anchor: dev HEAD at filing time includes the latest ticket-sync commit which itself exemplifies the churn pattern.