finding: ?preview=draft self-inflicts an invalid diagnostic — the injected _draft key is validated, so the read carries _diagnostics.valid:false

[huangyiirene]

Unconfirmed observation from the QA run — recorded for triage; the injection site was located but the fix (strip _draft before computing _diagnostics, or whitelist the read-decoration keys in the diagnostics validation) is the natural next step to confirm.

Symptom

Reading a metadata item with ?preview=draft returns a response whose own diagnostics call the item invalid because of a key the read itself injected.

• Observed: the response carries _diagnostics.valid:false with "Unrecognized key(s) … _draft".
• Expected: _diagnostics.valid:true for an otherwise-valid draft — the preview marker must not be validated against the item's strict schema.

Root cause (as located, unconfirmed)

The draft-preview read injects _draft:true onto the item and then validates the item with that key still present. In packages/metadata-protocol/src/protocol.ts the single-item draft read stamps (draftItem as any)._draft = true (around protocol.ts:4441, and the list overlay at :4261) and then decorates/validates it; the item schema is strict, so _draft is rejected by name. stripReadDecorations exists to remove exactly these stamped keys before a strict re-parse, but it is not applied on the path that computes _diagnostics for the draft read. Mechanism still present on origin/main.

Related but distinct: #6810 (closed) was the same class of defect for the indexed key at a different injection site — see the module header in packages/metadata-core/src/injected-system-columns.ts. This one is the _draft preview marker.

Reproduction

1. Create a draft of a valid metadata item (e.g. an object).
2. GET /api/v1/meta/<type>/<name>?preview=draft.
3. Inspect _diagnostics in the response → valid:false, "Unrecognized key(s) … _draft".

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: located, reproducible, self-contained — the read injects _draft:true and then strict-validates with the key still present. Verified on origin/main @ 5823d59: both injection sites live exactly as filed (packages/metadata-protocol/src/protocol.ts:4441 single-item, :4261 list overlay), and stripReadDecorations is imported (:72) and used on the write path (:9581) but not on the draft-read _diagnostics path. The fix direction (strip stamped keys before computing diagnostics) is the mechanism the codebase already owns — nothing to rule.
• Known class: next instance of the closed meta: applySystemFields stamps indexed on organization_id — a key FieldSchema rejects by name, so every registry-backed object read answers _diagnostics: { valid: false } #6810 pattern (stamped read-decoration key rejected by the strict schema); the in-flight finding: GET /api/v1/meta/diagnostics reports 94/94 registry entries INVALID — the platform's own __search column carries a key FieldSchema rejects, plus a missing config #7561 is the index-key sibling at search-companion.ts — different site, not a duplicate, but the dispatching lane may want one dev to take both for the shared discipline.
• Routing kept: domain:metadata — both fix sites in packages/metadata-protocol.
• target:v17: no — draft-preview diagnostics decoration, admin-facing cosmetic-semantic; not one of the four blocking classes.

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

---

Generated by Claude Code