[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 #7296
Description
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).
Activity
os-zhuang commentedon Aug 10, 2026
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:
appSecurityPluginOptions(the@objectstack/verify's bootStack ignores an app'sisDefaultpermission set, while the CLI honours it — after #5491 a dogfood app cannot test its own declared baseline #7001 helper inplugin-security/src/app-default-permission-set.ts) is consumed bypackages/cli/src/commands/serve.ts:2021(new SecurityPlugin(appSecurityPluginOptions(config))) and bypackages/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 vanillanew SecurityPlugin()the card describes is no longer what the harness constructs.packages/verify/src/harness.app-default-profile.test.tsasserts an app declaring anisDefaultset gets it enforced under both boot paths (:183-:195: "Both boot paths callappSecurityPluginOptions; a second copy of…").serve.tsno longer hand-readsappDefaultPermissionSetName(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