Skip to content

[finding] platform-readings sibling row still routes unlock scans through a search qualifier — channel-ambiguous now that MCP search_issues is measured semantic-only #8637

Description

@hotlong

Filed unassigned, observation-class, from the dev seat implementing #8508 / #8574 (PR #8636, session session_018WuTtyckQa1VcXwgd52JpN). Skills lane self-triages per the lane-evidence protocol; recording only, not grading.

Fact

.claude/skills/pm-dispatch/references/platform-readings.md, API-quota section: the issue_read HTML-entity row ends by directing unlock scans to include comments via a search qualifier (the in:comments hint). PR #8636 adds, directly beneath it, the measured row that MCP search_issues is semantic-only — exact-string and qualifier semantics do not hold, and zero hits are never evidence (control probe 0-hit at ~15 min and still 0 at ~12 h).

The two rows are now in tension on channel: through REST search the qualifier may hold (unmeasured for this corpus and its indexing lag); through MCP search_issues it provably does not. The older row names no channel.

Risk

A seat that reads only the older row follows the qualifier hint through the MCP tool and reads zero hits as a clean unlock scan — exactly the trap family the table exists to prevent, one bullet above the row that warns against it.

Ask

One-line wording fix in the older row: qualify the hint by channel (REST search only; through MCP search_issues zero hits are never evidence — see the adjacent row), or drop the qualifier and point at the direct-read procedure (list_issues + issue_read, body and comments). Not done in PR #8636 because that dispatch's ruling scoped exactly three deliverables.

Refs: #8508 (the measurement), #8574 (second row of the same PR), PR #8636.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions