@@ -6,7 +6,7 @@ fix(plugin-sharing): position- and team-recipient sharing rules are re-evaluated
 
 Clause-②: no
 
-A sharing rule's grants are materialised per user. When a position assignment (`sys_user_position`), a membership role (`sys_member.role`, the position transition source) or a team membership (`sys_team_member`) is inserted, deleted, or updated in a column the recipient expansion reads (the user, the position or team, the organization, the validity window), every sharing rule whose recipient the row names is now re-evaluated for the user the row names, before the write returns. A new holder gains the rule's grants and a former holder loses them. Other users' grants, and rules naming other recipients, are not touched.
+A sharing rule's grants are materialised per user. When a position assignment (`sys_user_position`) or a team membership (`sys_team_member`) is inserted, deleted, or updated in a column the recipient expansion reads (the user, the position or team, the organization, the validity window), every sharing rule whose recipient the row names is now re-evaluated for the user the row names, before the write returns. A new holder gains the rule's grants and a former holder loses them. Other users' grants, and rules naming other recipients, are not touched.
 
 The re-evaluation is scoped to that one user and to the rules naming the recipient: an indexed holder check, that user's grants of the rule, and the rule's criteria read only when the rule reaches the user. A bulk assignment import therefore costs one user-scoped pass per row and never a whole-rule pass. An organization's rule is re-evaluated only for rows of its own organization; a platform-global rule for every row.
 
 
@@ -220,7 +220,7 @@ be an explicit act, and it happens at **five** moments:
 | **The write that deactivates or edits the rule** | That rule's grants, immediately — deactivating with `active: false` (or `POST {basePath}/sharing/rules` with the same name) revokes them before the call returns |
 | **The next insert/update of a matching record** | That record's grants for every rule on the object — an inactive rule desires nothing, so its rows are revoked |
 | **A `sys_business_unit` or `sys_business_unit_member` write** | The grants of rules whose recipients read the BU graph — `unit_and_subordinates` and `business_unit`, and only those two. Recipients the rule no longer reaches are revoked **before the write returns**; the grant direction (a unit moved *into* a shared subtree) is queued and coalesced per rule (objectstack#7729) |
-| **A `sys_user_position`, `sys_member` or `sys_team_member` write** | The grants of rules whose recipient is the position or team the row names (`sys_member.role` is the position transition source), re-evaluated for the user the row names — inserts, deletes, and updates to the user, the recipient, the organization or the validity window. A new holder gains the rule's grants and a former holder loses them **before the write returns**; other users' grants and rules naming other recipients are not touched |
+| **A `sys_user_position` or `sys_team_member` write** | The grants of rules whose recipient is the position or team the row names, re-evaluated for the user the row names — inserts, deletes, and updates to the user, the recipient, the organization or the validity window. A new holder gains the rule's grants and a former holder loses them **before the write returns**; other users' grants and rules naming other recipients are not touched |
 | **Every boot** | All rules, plus a sweep of `source: 'rule'` rows whose `source_id` no longer resolves to any rule |
 
 Deleting a rule withdraws its grants too, whether you delete it through
 
@@ -5,8 +5,8 @@
  * user when the membership behind the recipient changes
  * (`recipient-membership-recompute.ts`).
  *
- * The invariant: a write to `sys_user_position`, to the `sys_member.role`
- * transition source, or to `sys_team_member` re-evaluates every sharing rule
+ * The invariant: a write to `sys_user_position` or to `sys_team_member`
+ * re-evaluates every sharing rule
  * whose recipient the row names, for the user the row names, before the write
  * returns — a new holder gains the rule's grants, a former holder loses them,
  * and no other user's grants and no other rule move.
@@ -360,15 +360,16 @@ describe('position assignment writes re-evaluate position-recipient rules for th
   });
 });
 
-describe('the membership role transition source and team membership move the holding too', () => {
-  it('a membership role naming the position grants, and a role change away from it revokes', async () => {
+describe('team membership writes re-evaluate team-recipient rules, and the transition source still counts', () => {
+  it('a holder who still holds the position through the membership role keeps the grants when the assignment goes', async () => {
     const t = await boot();
-    await t.ql.insert('sys_member', { id: 'm_1', organization_id: ORG_A, user_id: 'u_member', role: 'eu_sales' }, { context: SYSTEM } as never);
-    expect(await t.grantsOf('u_member')).toEqual(EU_GRANTS);
+    await t.driver.create('sys_member', { id: 'm_1', organization_id: ORG_A, user_id: 'u_both', role: 'eu_sales' } as never);
+    await t.assign('up_both', 'u_both', 'eu_sales');
+    expect(await t.grantsOf('u_both')).toEqual(EU_GRANTS);
 
-    await t.ql.update('sys_member', { id: 'm_1', role: 'member' }, { context: SYSTEM } as never);
+    await t.ql.delete('sys_user_position', { where: { id: 'up_both' }, context: SYSTEM } as never);
 
-    expect(await t.grantsOf('u_member')).toEqual([]);
+    expect(await t.grantsOf('u_both')).toEqual(EU_GRANTS);
   });
 
   it('a new team member gains the team rule\'s grants, and a removed one loses them', async () => {
@@ -416,7 +417,6 @@ describe('binding and write classification', () => {
   it('watches exactly the membership tables the position and team expansions read', () => {
     expect(RECIPIENT_MEMBERSHIP_SOURCES.map((s) => `${s.object}.${s.recipientColumn}->${s.recipientType}`)).toEqual([
       'sys_user_position.position->position',
-      'sys_member.role->position',
       'sys_team_member.team_id->team',
     ]);
   });
@@ -434,7 +434,7 @@ describe('binding and write classification', () => {
   });
 
   it('pins a rule to the organizations of the rows it can read', () => {
-    const [positions, , teams] = RECIPIENT_MEMBERSHIP_SOURCES;
+    const [positions, teams] = RECIPIENT_MEMBERSHIP_SOURCES;
     const orgs = new Set<string | null>([ORG_A]);
     expect(ruleReadsRowsOf(positions, { organization_id: ORG_A }, orgs)).toBe(true);
     expect(ruleReadsRowsOf(positions, { organization_id: ORG_B }, orgs)).toBe(false);
 
@@ -15,7 +15,6 @@
  * | recipient_type | membership table    | recipient column | read by                                   |
  * |----------------|---------------------|------------------|-------------------------------------------|
  * | `position`     | `sys_user_position` | `position`       | `PositionGraphService` (source of truth, ADR-0057 D4) |
- * | `position`     | `sys_member`        | `role`           | `PositionGraphService` (transition source, ADR-0057 D4 addendum) |
  * | `team`         | `sys_team_member`   | `team_id`        | `TeamGraphService.expandUsers`            |
  *
  * So when one of those rows is inserted, deleted, or updated in a column the
@@ -32,6 +31,12 @@
  * and `field` (per record, re-derived by the record's own write) have no
  * membership table to watch.
  *
+ * The position expansion also unions `sys_member.role`, the ADR-0057 D4
+ * transition source. The holder check reads it — a user who still holds the
+ * position there keeps the rule's grants when an assignment row goes — but its
+ * writes are not watched here: its values are the closed set of membership
+ * grades (ADR-0108), not business positions.
+ *
  * ## Cost: scoped to one user and to the rules that name the recipient
  *
  * The BU module refuses to recompute every rule on every graph write, and
@@ -73,8 +78,8 @@
  * delete still knows whose membership it removed.
  *
  * System writes are NOT skipped. The realistic producers of these rows are an
- * HRIS or directory sync, a seed, and better-auth's own adapter (which writes
- * through the engine as a system context) — skipping them would leave the
+ * HRIS or directory sync, a seed, and — for team membership — better-auth's own
+ * adapter, which writes through the engine as a system context. Skipping them would leave the
  * invariant false on the paths most likely to exercise it. The rule-hook
  * materialisation reached the same conclusion (`rule-hooks.ts`, the retired
  * `isSystem` skip).
@@ -127,8 +132,6 @@ export interface RecipientMembershipSource {
  *    for an organization rule, `organization_id`; it projects `user_id` and
  *    drops a holder outside `valid_from` / `valid_until` (ADR-0091 D2), so a
  *    change to the window moves the holding as surely as a change of user.
- *  - `sys_member` — the same service unions `role` as the position
- *    transition source, filtered by `organization_id` the same way.
  *  - `sys_team_member` — `TeamGraphService.expandUsers` filters on `team_id`
  *    alone, with no organization scope.
  */
@@ -140,13 +143,6 @@ export const RECIPIENT_MEMBERSHIP_SOURCES: readonly RecipientMembershipSource[]
     organizationScoped: true,
     expansionColumns: ['user_id', 'position', 'organization_id', 'valid_from', 'valid_until'],
   },
-  {
-    object: 'sys_member',
-    recipientType: 'position',
-    recipientColumn: 'role',
-    organizationScoped: true,
-    expansionColumns: ['user_id', 'role', 'organization_id'],
-  },
   {
     object: 'sys_team_member',
     recipientType: 'team',
 
@@ -854,9 +854,8 @@ export class SharingServicePlugin implements Plugin {
             bindBusinessUnitTreeRecompute(engine, this.ruleService, ctx.logger as any);
 
             // …and a rule whose recipient is a POSITION or a TEAM changes
-            // audience when a membership row (`sys_user_position`, the
-            // `sys_member.role` transition source, `sys_team_member`) is
-            // written. Each such write re-evaluates the rules naming that
+            // audience when a membership row (`sys_user_position`,
+            // `sys_team_member`) is written. Each such write re-evaluates the rules naming that
             // recipient for the one user the row names, so a new holder gains
             // the rule's grants and a former holder loses them before the write
             // returns. Bound outside the rebind seam for the same reason as the