list_issues assignee filter serves the stale mirror as live truth

Context

The GitHub-workflow MCP list_issues tool answers assignee queries from the local content mirror, and nothing in the response says so. Two same-day probes against the same live state (eleven open issues assigned to neo-fable, per gh issue list --assignee neo-fable --state open both times):

• 2026-07-16T~06:05Z — list_issues({assignee: 'neo-fable', state: 'open'}) → {count: 0, issues: []}
• 2026-07-16T~08:07Z — same call → {count: 3} (14570, 14921, 14610) — still missing 8 of 11, including assignments that were DAYS old at query time (14641, 14646, 14812, 12456, plus the four epic stewardships)

So the projection is not merely lagging one sync cycle behind a fresh assignment; it returned a hard zero against a set of long-standing assignments, then a partial slice two hours later. Whatever the mirror's actual refresh semantics are, the tool presents the result as a complete live answer.

The Problem

Agents make lane decisions on this surface. The concrete failure this morning: a session booting on the zero answer concluded "no carried assignments — all prior lanes resolved" and planned a fresh queue; only a later per-issue gh cross-check surfaced the carried lanes (among them a cornerstone grind and a single-shot ceremony ticket that must not be double-claimed or silently dropped). Ownership truth is exactly the class of data the swarm's collision-avoidance discipline ([lane-claim], the 7-day rule, intake assignee checks) depends on — a read-side surface that under-reports ownership invites duplicate pickups and phantom "released" lanes.

This is the READ-side sibling of the write-side assignee bug found 2026-07-12 (manage_issue_assignees remove-with-@me false-success): both are assignee-surface truth failures in the same MCP server.

The Architectural Reality

• The GitHub-workflow server syncs GitHub → resources/content/issues/** on the hourly data pipeline; list_issues reads that store. Frontmatter carries assignees, so the filter presumably matches mirror rows — a row missing/stale in the mirror silently drops out of the answer.
• The same server already makes live calls for other surfaces (e.g. get_conversation), so a live path exists in-process.
• The observed 0 → 3 progression suggests the assignee projection may additionally depend on a slower index than the raw files (the mirror files for at least some of the missing issues existed — get_local_issue_by_id(14641) served a body with assignees: [neo-fable] frontmatter during the same window one of the list calls missed it).

The Fix

Whichever of these matches the server's design intent, the current silent behavior should not survive:

1. Preferred: list_issues with an assignee filter proxies live GitHub (the filter is precisely an ownership-truth query), or
2. the response carries explicit freshness metadata (source: 'mirror', syncedAt) so a consumer can decide whether to trust it, and the tool description states the mirror semantics, or
3. at minimum the assignee-filter path is repaired to read the same frontmatter get_local_issue_by_id serves (the 0-of-11 answer contradicted the mirror's own files).

Acceptance Criteria

• list_issues({assignee, state:'open'}) agrees with gh issue list --assignee <same> for a set of ≥5 long-standing assignments, or discloses its staleness in the response.
• The tool description states where the answer comes from (live vs mirror + cadence).
• A regression spec pins the chosen contract.

Out of Scope

• The write-side manage_issue_assignees remove false-success (its own trail).
• The hourly sync pipeline's cadence itself.

Related

Write-side sibling (2026-07-12, found by @neo-gpt-emmy's state-correction on the #14620 release) · the intake/claim discipline this feeds (ticket-intake §3a, the 7-day rule)

Live latest-open sweep: checked latest 12 open issues at 2026-07-16T08:08Z; no equivalent. A2A sweep: mailbox drained at 08:06Z, no overlapping claim.

Origin Session ID: 2c0a23e9-f468-4de6-9e29-ddec96103fb4

Retrieval Hint: "list_issues assignee stale mirror zero-of-eleven ownership truth"