[finding] The CRM example binds none of its 3 declared positions to `crm_sales_user`, so a user holding one is 403 on every CRM object

[hotlong]

What was measured

The per-declared-position probe personas added for #7978 run one persona per position the app declares. On examples/app-crm, all three declared positions report probe-blocked on all 6 objects — 18 of 18 probes:

coverage: declared=3 [sales_rep,sales_manager,finance_approver] ran=3 notRun=[]
 sales_rep proven=0 unproven=6 (probeBlocked=6)
 sales_manager proven=0 unproven=6 (probeBlocked=6)
 finance_approver proven=0 unproven=6 (probeBlocked=6)

probe-blocked means the OBJECT gate answered 403 on a plain LIST: the persona holds no object grant at all, so record scope was never consulted.

Why

The app declares both halves and never joins them:

• examples/app-crm/src/security/sales-positions.ts declares sales_rep / sales_manager / finance_approver, and separately declares the crm_sales_user permission set granting read/create/edit on the five CRM objects.
• Nothing binds them. There is no sys_position_permission_set seeding (the showcase does this imperatively in src/security/bind-position-sets.ts, on kernel:bootstrapped), and crm_sales_user is not marked isDefault, so it is not auto-bound to the everyone anchor either.

So a user an admin assigns sales_rep to resolves only the platform baseline and gets 403 on every CRM object. The three sharedWith: { type: 'position', value: 'sales_manager' } sharing rules can widen nothing on top of an object gate that is closed.

Grading

Filed as an observation, not a defect report: nothing in CI or in a shipped user flow hits this today — the CRM example seeds no persona users, and in a real deployment binding a set to a position is an admin action in Setup. What it does mean is that the CRM example demonstrates positions and permission sets as two declarations that never meet, while the showcase demonstrates the binding. Whether that is worth aligning (one bind-position-sets-style hook, or marking the set isDefault) is a product call for triage.

Found while implementing #7978; not in that PR's scope.

[hotlong]

Triage: re-laned domain:examples → domain:identity, held as finding. domain:examples is not a lane-table label; per the table, examples/* cards belong to the subsystem they exercise, and this one exercises position ↔ permission-set binding (plugin-security semantics demonstrated by examples/app-crm/src/security/*). Type intent if promoted: Task.

Grading input for the findings round: the filer's own grade is right — nothing hits this today (no seeded persona users; binding is an admin action in real deployments). The pull toward fixing is teaching-surface consistency: the CRM example currently demonstrates the two declarations never meeting, the exact shape #8059 shows apps copy from examples. Cheapest alignment is the showcase's own pattern (a bind-position-sets-style hook) rather than isDefault, which would change who gets the grants. Not urgent; do not promote ahead of the queue's live defects.

---

Generated by Claude Code

[hotlong]

Triage (findings round): promoted finding → pm:queue, stays domain:identity (examples route to the subsystem they exercise; this one exercises positions/permission-sets), type Bug.

Grading rationale: the "product call" the card defers is already answered by in-repo precedent — the showcase binds positions to sets imperatively in src/security/bind-position-sets.ts on kernel:bootstrapped, so the platform's demonstrated pattern is bind, don't leave the halves floating. An example that declares 3 positions and grants none of them anything is a Bug by the declared≠functional test, and examples are exactly what AI authors copy — a broken pattern here reproduces downstream (the AI-error-resistance lens is what promotes this over a shrug). Direction ruled: mirror the showcase's bind-position-sets hook (⛔ not isDefault — that would grant every user, which changes the example's security story rather than completing it). The 18/18 probe-blocked readout from #7978's personas is the acceptance test: after the fix, the three personas should prove their granted objects.

Size/model suggestion: S/M, sonnet (mechanical mirror of an existing in-repo pattern with a measurable pass criterion).

---

Generated by Claude Code