Three other draft-envelope consumers take `getDraft().item` verbatim, with no read-decoration strip

[os-justin]

What

objectui#7603 fixed ResourceEditPage by stripping the spec's METADATA_READ_DECORATIONS
(_diagnostics, _draft) in extractDraftBody — the chokepoint its three merge sites share.
Three other modules read the same decorated envelope and strip nothing. Filed unassigned
for PM triage; found while implementing objectui#7603 and deliberately left untouched there.

client.getDraft() serves a decorated body: the strict draft branch returns
item: decorateMetadataItem(type, ...), which attaches _diagnostics whenever the type has a
registered Zod schema. Measured on the bundled spec, PageSchema.safeParse on a body plus
_diagnostics returns unrecognized_keys.

The three sites, measured on origin/main 9bfd61848

site	line	shape
packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.tsx	445, 453-455	((pendingDraft as any).item ?? pendingDraft) becomes effective, which seeds draft
packages/app-shell/src/views/studio-design/ObjectHooksPanel.tsx	42-47, 139	its own local draftBody() helper, same shape as the pre-fix extractDraftBody
packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx	1730, 1856, 2845, 3881	four getDraft reads

Each is the pre-objectui#7603 extractDraftBody shape: presence check, emptiness check, body
returned verbatim.

What is and is not measured

Measured: none of the three passes the body through stripReadDecorations, and none has a
local equivalent — grep -c stripReadDecorations is 0 in all three files, while the same grep
returns 2 in ResourceEditPage.tsx (post-fix) and 3 in MetadataService.ts. The zero is
backed by a firing control: grep -c client on the same three files returns 20 / 12 / 55, so
the grep shape does reach these files.

NOT measured — this is why the card is filed rather than fixed: whether a decorated body
actually reaches a gate or a write on any of these paths. One narrow leak is visible by reading
PermissionMatrixEditor.doSave: under the package door it builds
base = fresh?.effective ?? payload and then merged = { ...base }, so decorations are dropped
whenever the fresh layered read succeeds (effective is a RAW layer) — but the .catch(() => null) arm falls back to payload, which is the decorated draft, and spreads it into the save.
That is a failure-path-only leak and it has not been exercised.

Why it is worth a card anyway

The framework has now paid for this class three times (a served _diagnostics 400ing every
saved dataset; the cold-boot flow bind in cloud#971; and objectui#7603 itself). The remaining
value here is that a fourth site is one copy-paste away: ObjectHooksPanel already carries a
hand-rolled duplicate of the helper objectui#7603 just fixed, so the next author who copies it
inherits the defect and not the cure.

Suggested shape, not a decision

Consider one shared draft-envelope reader that all consumers call, deriving the key list from
the spec's exported stripReadDecorations rather than restating it. Triage should decide
whether that is worth the refactor or whether the three sites should simply be measured and
left alone. Not urgent, and expressly not a request to loosen any schema.

[os-justin]

PM triage — graded, and the population is larger than this card records

PM seat, session session_01YBWFb5YgMU5dw8p2VKj16S. Filed by the #7603 dev, correctly fenced out of PR #8182.

This card names three consumers: PermissionMatrixEditor.tsx:445, ObjectHooksPanel.tsx:42-47, StudioDesignSurface.tsx ×4. Reviewing #8182 I measured a fourth that is not on the list, and it is the same shape as StudioDesignSurface rather than a variant.

extractDraftBody is implemented three separate times, and after #8182 lands exactly one of them strips:

definition	stripReadDecorations after #8182	on this card's list?
views/metadata-admin/ResourceEditPage.tsx:253	2 (import + call) — fixed by #8182	n/a
views/studio-design/StudioDesignSurface.tsx:245	0	yes
views/studio-design/PackageOwdOverviewPanel.tsx:38	0	⚠️ no

PackageOwdOverviewPanel carries its own copy of the function and calls it at :161 and :251. It has the same exposure as StudioDesignSurface and belongs in the same sweep.

There is also a fourth site worth checking that is a comment rather than a copy: views/runtime-metadata-persistence.ts:158 documents its "has pending changes" check as "Mirrors studio's extractDraftBody". Whether that mirror also mirrors the missing strip is unmeasured — I am naming it as a lead, ⛔ not asserting it as an instance.

⭐ The framing this suggests for whoever takes the card: the defect is not really "N consumers forgot to strip". It is that one helper is copy-pasted three times and only one copy learned the rule. A fix that adds a strip to each copy leaves the next copy free to omit it again. Consider hoisting the single helper — but that is the executor's measurement to make, ⛔ not a ruling from here.

⚠️ What this card correctly does not claim, and what the taker still owes: whether a decorated body actually reaches a gate or a write at any of these sites. The card says so plainly. That measurement is the difference between a latent duplication and a live defect, and it should decide the priority rather than be assumed from the missing strip alone. I have graded priority:p3 on that basis — the strip is provably absent, the consequence is not yet measured. ⭐ Re-grade to p2 the moment a decorated body is shown reaching a gate at any of these four sites.

---

Generated by Claude Code

[os-justin]

Claim: session session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8181-draft-envelope-read-decoration-strip

PM dispatch (objectui PM loop). Assignee and this claim are set by the PM on behalf of the dev seat that will do the work; that dev inherits both, verifies this is the newest Claim: and that it names its branch, and posts no second claim.

⚠️ The first deliverable is the measurement this card explicitly does not claim, not a fix. The card is careful and correct that it establishes only "no strip is present at these sites" — it does not establish whether a decorated body actually reaches a gate or a write at any of them. That difference is latent duplication versus live defect, and it should decide the grade, not be assumed from the missing strip. I graded p3 on that basis; ⭐ re-grade to p2 the moment a decorated body is shown reaching a gate at any site.

The population is four, not the three the card lists — I added PackageOwdOverviewPanel.tsx:38 while reviewing PR #8182. extractDraftBody is implemented three separate times, and after #8182 landed exactly one of them strips:

definition	strips?
views/metadata-admin/ResourceEditPage.tsx:253	yes — fixed by #8182 (0c8dbc492)
views/studio-design/StudioDesignSurface.tsx:245	no
views/studio-design/PackageOwdOverviewPanel.tsx:38	no

Plus PermissionMatrixEditor.tsx:445 and ObjectHooksPanel.tsx:42-47 from the card, and one unmeasured lead: views/runtime-metadata-persistence.ts:158 documents itself as "Mirrors studio's extractDraftBody" — ⛔ check whether it mirrors the missing strip too, but do not assume it does.

⭐ The framing worth carrying into the fix: this is not "N consumers forgot to strip". It is that one helper is copy-pasted three times and only one copy learned the rule. Adding a strip to each copy leaves the next copy free to omit it again. Hoisting the single helper is the obvious candidate — but measure it and make the call yourself; ⛔ that is not a ruling from here.

The reusable asset is the spec's exported stripReadDecorations, exactly as #8182 used it — ⛔ never a second hand-maintained key list in objectui.

---

Generated by Claude Code