[Bug] Exact-thread sync rejects documented thread selectors

[morluto]

Description

The documented exact-thread selection shape for github_sync_threads is rejected by the MCP handler. This blocks the narrow refresh path and prevents dependent pull-request status hydration from obtaining current evidence.

Observed against morluto/leantoken#167 on 2026-07-23:

{
  "selection": "threads",
  "threads": [
    {"owner": "morluto", "repo": "leantoken", "kind": "pull_request", "number": 167}
  ]
}

The call returned:

repository filters are not accepted in thread selection mode

A subsequent github_sync_pull_request_status request for the same pull request reported that the thread had not been synced.

Steps to reproduce

1. Call github_sync_threads in thread-selection mode with one exact {owner, repo, kind, number} selector.
2. Observe the validation error above.
3. Call github_sync_pull_request_status for that exact pull request.
4. Observe that the status refresh cannot proceed because the thread is not synced.

Expected behavior

An exact thread selector should be accepted, bounded to the requested thread, and return a durable job whose completed projection can be consumed by pull-request status hydration.

Repository-selection mode should remain distinct and should not be broadened implicitly as a fallback.

Actual behavior

The published tool contract accepts exact thread objects, but the handler rejects them as if repository filters had been supplied in repository mode. This makes exact issue/PR refresh unavailable through the MCP path.

The error may indicate a schema/handler disagreement or a selection-mode routing bug; the underlying cause still needs source-level confirmation.

Acceptance criteria

• Schema and handler tests use the same exact-thread fixture and pass for both issue and pull-request kinds.
• The returned job reports the requested thread as complete, retryable, unavailable, or failed without silently widening scope.
• Repeating the same exact sync is idempotent and does not duplicate observations.
• github_sync_pull_request_status succeeds after the exact thread sync and reports facet completeness accurately.
• Repository-selection mode retains its own validation and budgeting behavior.
• An end-to-end MCP test exercises sync, job polling, and dependent status hydration through stdio.

Evaluation scenario

Freeze a fake GitHub repository with one issue and one pull request plus the exact MCP request above.

A correct agent/tool path must:

• accept the exact selector;
• sync only that thread;
• poll the durable job to completion; and
• make the dependent PR-status call observe the synced projection.

A tempting invalid path is to retry the same malformed route, silently switch to a broad repository sync, or report PR health as current without a complete sync. The evaluation should reject all three. It should also verify that missing facets remain explicitly unknown rather than being treated as success.

Impact

Agents and integrations must fall back to native GitHub commands or broader syncs for a request that should be narrow and bounded. This increases network work, weakens freshness provenance, and prevents the contribution workflow from composing its existing exact-thread and PR-health capabilities.

Related work

This is a follow-up to the PR-health and scalable MCP contracts covered by #20; it is specifically about the exact-thread sync prerequisite and does not replace the existing PR-health scope.

[morluto]

Confirmed again through the published MCP tool on 2026-07-23 with the exact request from this issue:

{
  "selection": "threads",
  "threads": [
    {"owner": "morluto", "repo": "leantoken", "kind": "pull_request", "number": 167}
  ],
  "max_requests": 9
}

Result:

repository filters are not accepted in thread selection mode

Confirmed source cause

At current main (42f805b025310f065c95d5c22cab6707a73ed2eb):

1. SyncThreadsInput.LimitPerRepository is an optional integer shared by both selection modes (scalable.go).
2. The generated MCP schema assigns limit_per_repository a default of 100 without conditioning it on selection == repositories (catalog registration).
3. The observed MCP wire path therefore applies that schema default and turns an omitted thread-mode field into LimitPerRepository == 100.
4. The handler rejects any nonzero LimitPerRepository in thread mode (handler guard).

The application operator also defaults LimitPerRepository unconditionally after the handler (SyncThreads), but the observed request never reaches that layer.

The current invalid-input stdio table tests thread mode with an explicitly invalid state field; there is no paired valid exact-thread stdio call proving that omitted repository fields survive schema defaulting. Open PR #111 improves typed MCP errors but retains both the global default and the rejection guard, so it does not currently close this issue.

Regression shape

The regression must cross the real MCP schema boundary. A direct Go call to the handler with a zero-valued struct is insufficient because it bypasses client/schema default injection.

Add paired stdio cases:

• valid: selection=threads plus only threads and optional max_requests;
• invalid: the same input plus one repository-only field such as state or limit_per_repository;
• valid repository mode with omitted limit_per_repository, still receiving its documented default;
• exact issue and exact pull-request variants;
• repeated exact sync proving idempotent projection updates.

After the valid job completes, github.sync_pull_request_status must consume the stored PR. The test should fail if implementation silently broadens to repository mode, ignores an explicitly supplied repository-only field, or reports status freshness before the sync job completes.

A mode-specific oneOf schema is one possible fix. Another is to remove the wire default and apply 100 only after repository mode is selected. The observable requirement is that omitted fields remain semantically omitted in thread mode.

[morluto]

Additional verification after the fix merged:

On 2026-07-24, the configured GitContribute 0.8.0 MCP runtime still rejected the exact-thread request from this issue:

{
  "selection": "threads",
  "threads": [
    {"owner": "morluto", "repo": "leantoken", "kind": "pull_request", "number": 193}
  ]
}

It returned:

repository filters are not accepted in thread selection mode

The source fix is present on main through merged PR #119, so this appears to be release/runtime skew rather than a new source regression. The installed runtime predates that merge. A release or setup refresh that includes #119 should make the published MCP behavior match main.