[finding] `@objectstack/verify` harness never reads `config.permissions` — an app's declared `isDefault` permission set is invisible to `bootStack`, so dogfood apps cannot test the #5491-prescribed baseline

[os-zhuang]

Found and measured during cloud#1219 (the consumer-side fallout of #5491's member_default wildcard removal). Filed unassigned as a finding; the maintainer's cloud#1219 ruling (2026-08-10) names this as the upstream half that must exist for the migration prescription to be testable.

The fact

#5491's Migration section prescribes: "Ship an app default profile. Mark a permission set isDefault: true…". The CLI honors it — packages/cli/src/commands/serve.ts:2008 reads appDefaultPermissionSetName(config.permissions) and passes new SecurityPlugin({ fallbackPermissionSet }).

The verify harness does not: packages/verify/src/harness.ts constructs a vanilla new SecurityPlugin() and never reads config.permissions.

Verified empirically on cloud's apps/ee-group-showcase (cloud#1219): adding definePermissionSet({ isDefault: true, … }) + permissions: to the app changed nothing — the same 6 of 37 acceptance cases still failed at the object gate.

The consequence

Any dogfood app that follows #5491's own migration prescription cannot see its declared baseline take effect under bootStack — the only workaround is hand-constructing a SecurityPlugin in each suite, which is itself the "custom security code" the dogfood posture forbids. The prescribed migration is therefore untestable through the harness that exists to test app postures.

Suggested shape (for triage, not binding)

verify's harness resolves the app default profile the same way serve.ts does — one shared resolution helper, so the two cannot drift. A pin: an app declaring an isDefault set must observe it enforced under bootStack.

Refs: cloud#1219 (measurement + ruling), #5491 / #5492 (the narrowing and its migration prescription), cloud#880 / #3541 (ADR-0105 dogfood posture).

[os-zhuang]

Findings triage — closed: the described gap is already fixed on origin/main @ 397e731, including the exact suggested shape. (Stale-premise check per the #6488/#6279 discipline: graded against this-moment main, and this-moment main has absorbed it.)

Measured, all three elements of the card's "suggested shape" present:

1. Shared resolution helper exists and both boot paths use it: appSecurityPluginOptions (the @objectstack/verify's bootStack ignores an app's isDefault permission set, while the CLI honours it — after #5491 a dogfood app cannot test its own declared baseline #7001 helper in plugin-security/src/app-default-permission-set.ts) is consumed by packages/cli/src/commands/serve.ts:2021 (new SecurityPlugin(appSecurityPluginOptions(config))) and by packages/verify/src/harness.ts:444 (opts.security ?? new SecurityPlugin(appSecurityPluginOptions(config))) — so the two cannot drift, which is precisely the card's asked-for shape. The vanilla new SecurityPlugin() the card describes is no longer what the harness constructs.
2. The pin exists: packages/verify/src/harness.app-default-profile.test.ts asserts an app declaring an isDefault set gets it enforced under both boot paths (:183-:195: "Both boot paths call appSecurityPluginOptions; a second copy of…").
3. serve.ts no longer hand-reads appDefaultPermissionSetName(config.permissions) — zero hits; it went through the same consolidation.

The filing (05:15Z) was evidently measured against a pre-fix checkout while the fix was landing on main — the empirical cloud#1219 measurement stands as history, but the upstream half it asked for exists today. If the cloud-side re-measurement against a bumped pin still shows the 6/37 failures, that is a new fact for a new card (or reopen with the readout).

Closed as completed; maintainer veto-window applies (reopen overrides, no approval awaited).

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

---

Generated by Claude Code