One sentence in the published `objectstack-api` skill goes stale when the `contributes.routes` tombstone lands — "parses but serves nothing" becomes "is rejected loudly"

[huangyiirene]

Filed unassigned by the dev seat executing the #10726 tombstone half (family with #11328). Not fixed in that PR because skills/** is a governed face with a maintainer-owned net-line/token budget (2026-08-21 ruling), and the tombstone dispatch's file surface deliberately excluded governed faces.

The site

skills/objectstack-api/SKILL.md:164 (the decision table row PR #11327 corrected):

http.server mount (plugin code) | The endpoint needs real handler CODE — … Mount it on http.server; contributes.routes parses but serves nothing.

Why it goes stale

The trailing clause was accurate while the key was declared-but-unenforced. Once the #10726 tombstone PR lands, an authored contributes.routes no longer "parses" at all — it is a tsc error and a parse error carrying the removal prescription. The row's recommendation (mount on http.server) stays correct either way, so the stale clause misleads mildly rather than dangerously — but a published skill stating that a removed key "parses" is exactly the class the 2026-08-22 ruling had corrected.

Suggested fix (one clause, ~0 net tokens)

Replace the trailing clause with something like "the manifest contributes.routes key was removed (#10726)" — or simply drop it, which buys token-ratchet headroom (the file sits at its ceiling: 6348/6348 at PR #11327). Needs the governed-face landing path (human merge) and the skills token/line budget from the PM seat.

Dedup basis: this staleness is created by the #10726 tombstone PR, so it cannot predate it; REST issue listing is 403 from this container and MCP GraphQL listing is off-budget, so the search leg rests on the PM's at-fire dedup reads plus that causality.

Blocked-by: #10726

---

Generated by Claude Code