finding: GET /api/v1/meta/skill lists a skill twice after a runtime PUT, and the meta PUT never reaches the prompt bridge (two divergent skill-read paths)

[huangyiirene]

Unconfirmed observation from the QA run — recorded for triage; the two mechanisms below were located but not independently root-caused, and the natural next step is to decide the single source of truth for skill rows (merge/dedup by name) that both the meta HTTP list and the MCP prompt bridge read from.

Symptom

Two related divergences in how skill metadata is read after a runtime store override:

1. GET /api/v1/meta/skill returns the same skill twice after a runtime PUT — the store-override row and the package row are both listed, not merged/deduped by name.
2. PUT /meta/skill/<name> {active:true} → 200 does not reach the prompt bridge. Flipping a skill active via the runtime metadata API does not make it appear over MCP prompts.

• Expected: one row per skill name (override merged over package), and a runtime {active:true} PUT reflected in the prompt bridge.

Root cause (as located, unconfirmed)

The two surfaces read from different sources:

• The MCP prompt bridge's listSkills calls metadataService.list('skill') — registry/package rows (packages/mcp/src/mcp-server-runtime.ts:753, listSkills: async () => (await metadataService.list('skill')) ?? []).
• The HTTP meta list goes through protocol.getMetaItems — which merges store overrides.

So the store override (the {active:true} PUT) lands on the getMetaItems path but never on the metadataService.list path the bridge consumes; and on the HTTP list path the override and package rows are not deduped by name, producing the double listing. Both mechanisms are present on origin/main (mcp-server-runtime.ts:753; the dedup gap is in the getMetaItems merge in packages/metadata-protocol).

Note: the fix straddles packages/metadata-protocol (dedup/merge of skill rows) and packages/mcp (which source listSkills reads). Routed domain:metadata because the defining symptom — duplicate rows and un-merged overrides — lives in the metadata read/list layer; flag if the maintainer prefers the bridge-side lane.

Reproduction

1. Boot a showcase with a packaged skill.
2. PUT /api/v1/meta/skill/<name> with {active:true} → 200.
3. GET /api/v1/meta/skill → the skill appears twice (override row + package row).
4. Query the skill over MCP prompts → the {active:true} flip is not reflected.

Source

Extracted from the QA run #7627 (framework 92f26f7, console 6314e87f).

[os-zhuang]

Triage — dual-state resolution: pm:queue + domain:metadata kept; finding removed (queue+finding is an illegal pair).

• Why queue, despite the "unconfirmed" hedge: unlike a bare observation, this card has a 4-step repro and BOTH mechanisms located to file/line. Verified on origin/main @ 5823d59: packages/mcp/src/mcp-server-runtime.ts:753 reads metadataService.list('skill') verbatim (registry rows, no overrides), while the HTTP list goes through getMetaItems in packages/metadata-protocol (the overlay-merging path — its store-outage test header confirms the overlay-read role). Two read paths for one truth is a concrete divergence defect, not a design question: expected behavior (one row per name, override merged over package, PUT visible to the bridge) follows from the existing overlay semantics.
• Routing kept: domain:metadata — the defining fix (dedup/merge by name) lands in the metadata read/list layer; the packages/mcp half is pointing listSkills at the merged read, a consumer-side one-liner riding the same PR. The filer's flag-if-preferred note stands; dispatch should name both files.
• Dedup: no open card on skill-row duplication or the bridge/override divergence (adjacent finding: ?preview=draft self-inflicts an invalid diagnostic — the injected _draft key is validated, so the read carries _diagnostics.valid:false #7656 is a different defect — draft-preview diagnostics).
• target:v17: no — admin-facing runtime-override surface, not one of the four blocking classes; flag for re-judgment if skills become a headline v17 surface.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[huangyiirene]

Deferred at batch selection (round 1, domain:metadata seat) — recording the traps rather than silently pushing it to a later round. Stays pm:queue, unassigned.

Why deferred: the dedup/merge half lands in packages/metadata-protocol (getMetaItems), and protocol.ts is serialized — PR #7814 (#7779) holds it and is in the landing window, with #7819 → #7134 → #4716 queued behind it in this seat's hot-file order. This card enters that queue rather than jumping it.

Two things worth having on the record before anyone takes it up:

1. ⚠️ The card names two symptoms, and they may not be one bug. The double listing (override row + package row not deduped by name) and the prompt bridge missing the {active:true} flip are attributed here to a single cause — two surfaces reading different sources. That reading is plausible and unconfirmed by the filer's own admission. Whoever implements should establish whether fixing the getMetaItems merge alone changes the bridge's answer at all; if not, this is two cards, and the bridge half (packages/mcp/src/mcp-server-runtime.ts:753, listSkills reading metadataService.list('skill')) belongs to domain:cli under the package table, not here.
2. The card's own framing invites the real question, and it is a design one, not a repair: what is the single source of truth for skill rows that both the meta HTTP list and the MCP prompt bridge read from? Answering "dedup the list" without answering that leaves the two paths divergent and merely hides one symptom. If the dev reaches that fork, the correct output is a needs_decision design exit, not a guess — this seat treats that as a successful run, not a failed one.

Cross-lane note: the routing comment already invites a flag if the bridge-side lane is preferred. This seat is not re-routing it unilaterally; that is the triage seat's call and the observation above is offered as input to it.

---

Generated by Claude Code

[huangyiirene]

Held this round — collides with an active claim on #6504, not deprioritised. Recording the collision now so it is not re-derived.

This card's bridge-side half wants to change which source listSkills reads, located here as packages/mcp/src/mcp-server-runtime.ts:753 — listSkills: async () => (await metadataService.list('skill')) ?? [].

#6504 is claimed (assignee os-zhuang) and names that same expression as one of its two measured consumers — its body quotes agent_prompt's sibling skill bridge, (await metadataService.list('skill')) ?? [], as a consumer of the known-partial list() answer. #6504 proposes adding a listDiagnosed counterpart to IMetadataService and sweeping consumers.

So both cards rewrite the same call, for different reasons: #7654 wants it to read a source that reflects store overrides; #6504 wants it to receive a degraded-verdict-carrying answer. Dispatching this concurrently would put two agents on one line with two incompatible intents — the failure mode where each side is individually green and the merged result is wrong.

Sequencing: this card waits for #6504's shape to land or for its claim to be released. Whoever picks this up afterwards should re-read #6504's outcome first — if listDiagnosed lands, the bridge-side half of this card may need to be expressed against the new method rather than the old one.

Note the split-lane caveat already in the body: the fix straddles packages/metadata-protocol (dedup/merge of skill rows) and packages/mcp (which source the bridge reads). The metadata-protocol half — duplicate rows on GET /api/v1/meta/skill not being deduped by name in the getMetaItems merge — does not collide with #6504 and could be split into its own card if the bridge half stays blocked for long. Flagging rather than doing that split now, since splitting a QA-sourced finding before either half is root-caused tends to produce two cards that each assume the other's context.

Also unchanged from the body: this is an unconfirmed observation — both mechanisms were located, neither independently root-caused. Whoever takes it root-causes first.

---

Generated by Claude Code