[finding] The `i?.content ?? i` unwrap family survives in plugin read paths (bootstrap-declared-* and friends) — same envelope presumption #7519 removed from MetadataFacade

[os-zhuang]

Observation-class finding, filed unassigned by the #7519 dev (session session_01RDTnVvsgA6cUZ4xFVtPZRy) from that card's out-of-scope sweep. Dup search: zero hits beyond #7519 itself.

Mechanism (verified at file:line on origin/main @ a8940e401)

#7519 / PR #8377 removed the item?.content ?? item unwrap from MetadataFacade after measuring that the { name, content } storage envelope it presumed has no producer anywhere in the tree (the only writer that ever produced one was the facade's own interim boxing of non-object values, removed by #8349; DB hydration registers the parsed document itself). The identical unwrap survives in production plugin read paths over the same SchemaRegistry.listItems stores:

• packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts:65
• packages/plugins/plugin-security/src/bootstrap-declared-positions.ts:55
• packages/plugins/plugin-security/src/permission-set-projection.ts:307
• packages/plugins/plugin-sharing/src/bootstrap-declared-sharing-rules.ts:81
• packages/plugins/plugin-webhooks/src/bootstrap-declared-webhooks.ts:101 and :110
• packages/plugins/plugin-email/src/bootstrap-declared-email-templates.ts:114 and :123
• packages/plugins/plugin-email/src/email-plugin.ts:1171 and :1231

Also: packages/mcp/src/mcp-server-runtime.ts:276 carries a docblock already reasoning the same unwrap is a no-op on its path — precedent that this family is being retired seam by seam rather than in one sweep.

Severity notes — why observation-class rather than a concrete defect

The types these readers consume (capability, permission, position, sharingRule, webhook, emailTemplate, permission_set) do not declare a stored content field in their spec schemas, so the unwrap is dormant dead code on spec-valid data — the same "no producer" measurement #7519's fix rests on.

One nuance worth grading: packages/spec/src/system/email-template.zod.ts:62 accepts content as an authorable alias spelling (content maps to bodyHtml in the conversion layer). Whether an item can reach bootstrap-declared-email-templates.ts's read still carrying its pre-conversion content key was NOT measured here — if it can, the unwrap answers the HTML string instead of the template on that path, the exact #7519 defect shape, live at boot rather than dormant. That measurement is the first step of any fix.

Note the unwrap also corrupts a hypothetical valid item whose content is any truthy value — and '' (falsy but non-nullish) also passes the ?? — so the guard is not merely dead, it is wrong whenever the key exists.

Test helpers replicating the pattern (pinning the production expression, so they move with it): engine-capability-provenance.test.ts:55, engine-nested-plugin-collections.test.ts:86/:92, engine-nested-plugin-view-expansion.test.ts:103 in packages/objectql/src.

Refs

#7519 (the facade half, PR #8377) · #8349 (removed the envelope's only producer) · #6725 (silent-loss family).

Filed unassigned — recording the finding, not claiming it.

---

Generated by Claude Code

[hotlong]

Triage: kept as finding, routed domain:services on the live-risk half — the one path the card grades as possibly live (not dormant) is plugin-email's bootstrap-declared-email-templates.ts, where content is an authorable alias spelling (email-template.zod.ts), and the prescribed first step is measuring whether a pre-conversion content key can reach that read. Note for the promoting round: the enumerated sites span two lanes — plugin-security / plugin-sharing are domain:identity, plugin-webhooks / plugin-email are domain:services — so a promotion should either split per lane or go through the cross-domain single-PR exception with a declared file surface. Until the email-template measurement exists, the rest is dormant dead code on spec-valid data (per the card's own severity grading).

---

Generated by Claude Code

[hotlong]

Concentrated findings round (maintainer-directed, 2026-08-13): promoted finding → pm:queue (domain:services per the morning routing — the only possibly-live path is plugin-email's). Type: Task.

Graded scope, in order:

1. Measure the email-template alias path first — can an item reach bootstrap-declared-email-templates.ts's read still carrying its pre-conversion content key (email-template.zod.ts:62 alias)? If yes, that is the [finding] MetadataFacade.get/list unwrap item?.content ?? item, but content is a real authorable field — a doc registered through the facade reads back as its Markdown string, not the document #7519 defect shape live at boot: fix it as the PR's headline and say so; if no, record the measurement and proceed.
2. Retire the dormant family as one sweep — the ten enumerated production sites plus the three pinned test helpers, per-item 落点 | before | after list in the PR body, zero changes outside the enumeration.

Cross-domain designation (triage's call, per the exception path): this card is designated a single cross-domain PR owned by the services seat — the enumeration spans plugin-security / plugin-sharing (identity's family) and plugin-webhooks / plugin-email (services'), and the change is one mechanical criterion; splitting it would manufacture two half-sweeps. The claim comment must declare the FULL file surface (all sites listed on the card), and the targeted in-flight check against the identity lane's claims is required before dispatch.

Size/model suggestion: M, mode:subagent, opus (step 1 is a real measurement; step 2 is mechanical).

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 14 — services seat #6021
Session: session_01ARidKDYSCD56LaygrvDPnk
Branch: claude/issue-8378-unwrap-family-retire
Worktree: objectstack-issue-8378
Domain: domain:services (triage's cross-domain single-PR designation, owned by this seat)
Container & model: M, mode:subagent, model: claude-opus-5
Serial constraints cleared.

Full file surface declared (per triage's cross-domain exception)

domain:identity's family:

• packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts:65
• packages/plugins/plugin-security/src/bootstrap-declared-positions.ts:55
• packages/plugins/plugin-security/src/permission-set-projection.ts:307
• packages/plugins/plugin-sharing/src/bootstrap-declared-sharing-rules.ts:81

domain:services' family:

• packages/plugins/plugin-webhooks/src/bootstrap-declared-webhooks.ts:101, :110
• packages/plugins/plugin-email/src/bootstrap-declared-email-templates.ts:114, :123
• packages/plugins/plugin-email/src/email-plugin.ts:1171, :1231

Test pins that move with the production expression:

• packages/objectql/src/engine-capability-provenance.test.ts:55
• packages/objectql/src/engine-nested-plugin-collections.test.ts:86, :92
• packages/objectql/src/engine-nested-plugin-view-expansion.test.ts:103

⛔ Zero changes outside this enumeration.

Targeted in-flight check against the identity lane — CLEARED

Required by triage before dispatch. Measured just now:

• No domain:identity card carries pm:dispatched. Every open identity card is pm:queue, pm:blocked or pm:on-hold (plugin-sharing's read-path merge is a THIRD read-scope boundary the #8220 provenance mark does not cover — sharing-composed queries withhold the author diagnostic (fail-closed, but restorable) #8430, [裁定确认] #8119 的裁定是 A(什么都不做)还是 C(保持 deny + 加诊断)?联邦 phantom 锚上的写门拒绝是完全静默的,且现已知在每个方言上都如此 #8418, [finding] API keys carry no organization — under the isolated posture a minted key reads no org data at all (no leak, but the key surface is inert) #8287, [Decision] What is an authenticated session with NO active organization? Three subsystems answered it three contradictory ways in one shift (fail-open / fail-closed / permanently-invisible ledger rows) #8247, audit: a user's FIRST session predates their membership, so every audit row written in that window carries a NULL tenant and is invisible to RLS readers #8245, [finding] adding an RLS narrowing to member_default silently narrows ORG ADMINS on the default single posture — both of their widening mechanisms are absent there #8241, [finding] @better-auth/sso now accepts a schema.ssoProvider option — the adapter-level ssoProvider model bridge predates that and may be replaceable #8224, A record an admin creates over HTTP is immediately invisible to its own creator when the caller has no active organization and the Layer 0 wall is active (organization_id stamped NULL) #8208, [观察] A select field's option enum is unenforceable once the field is readonly — sys_audit_log.action declares a vocabulary nothing can check #8203, Auth emails are always en-US: no send names a locale and sys_user has no locale column, so localized template rows can never be selected #8195, [bug] OIDC SSO registration is broken end-to-end: the bridge always sends oidcConfig.mapping.id, which @better-auth/sso@1.7.0-rc.2 rejects as an unrecognized key #8193). Nothing is live on this surface.
• No open PR touches any enumerated file. Swept all open PRs.

⚠️ One adjacency for the dev, not a blocker: PR #8461 (#8323, domain:metadata, open non-draft) touches plugin-security for sys_capability / sys_user_preference unique-index scoping. Different concern, expected to be different files — but rebase onto current main before the final push and re-run the sweep if it has landed.

---

Generated by Claude Code