fix(governance): count the genesis founder as "another admin" in last-admin guard

[rtb-12]

Problem

After #2931 (namespace founder derived from a genesis op rather than materialised as an Admin member ROW), the last-admin invariant credits the founder for "is this member an admin?" but not for "is there another admin?" — in both the live has_another_admin (governance-store/.../membership/view.rs) and the at-cut is_last_admin_at_cut (context/src/scope_projection.rs).

In a {founder + one promoted admin} group, demoting/removing the promoted admin is rejected as "cannot demote the last admin". The authoring node applies it fine, but a peer replaying the DAG throws mid-batch at apply_signed_namespace_op.rs:255; because delta-apply is all-or-nothing, the peer drops every op after it → permanent governance divergence (we_missing=1 peer_missing=1).

Surfaced as mero-drive's E2E (members) job, red since the founder-derivation change: Bob's node wedges on the demote and never applies the later set_member_capabilities ops, so the cross-node capability assertion reads 0.

Fix

Make "another admin" symmetric with "is admin" — credit the derived/genesis founder in both paths. member was already counted as an admin via the genesis source; the orphan check now counts it as another admin too when it is a distinct identity.

Test

Extends membership_policy_guards_last_admin_and_tee_paths with a founder-only case (sole Admin row + a different meta.admin_identity). Verified FAILED pre-fix, ok post-fix. projection_membership_equivalence (live==projection) still green.

Not included

The all-or-nothing batch apply that turns one rejected op into a total sync wedge (apply_signed_namespace_op.rs) — separate hardening; the symmetry fix alone unblocks E2E (members).

🤖 Generated with Claude Code

[meroreviewer]

🤖 MeroReviewer

Reviewed by 1 agents | Quality score: 27% | Review time: 70.2s

---

🟡 Warning (2)

1. group_admin double-counts the genesis founder already covered by root

File: crates/context/src/scope_projection.rs (line 1484-1488) | Consensus: 1/1 agents ✓

The has_other expression now has three OR-branches:

1. A distinct Admin-role ROW in groups[group].
2. view.group_admin.get(&group) is some identity other than member.
3. root is (group, admin) where admin != member.

view.group_admin stores the subgroup creator (the genesis admin for that group), and root stores the namespace-root genesis admin. For the ROOT group specifically, view.group_admin.get(&root_group) and root.as_ref().map(|(rg, ra)| rg == group && ra != member) can refer to the same identity — the namespace founder. If both are set to the same person, the expression is still correct (OR is idempotent), but if they diverge (e.g. after an AdminChanged op updates group_admin but root still holds the original genesis admin), the two branches count different people, which may or may not be the intended semantics.

More concretely: for a non-root subgroup, branch 2 fires when the subgroup creator is someone other than member, and branch 3 fires when the namespace-root founder is someone other than member. These are genuinely different identities and both should count — so the logic appears correct. The concern is that for the ROOT group, branch 2 and branch 3 may overlap, but since OR is idempotent this is harmless.

The real issue is that the pre-fix comment said "matching live's row-based has_another_admin, which scans stored rows and ignores the genesis admin" — the fix intentionally breaks that symmetry. The new has_another_admin in view.rs also counts the genesis founder. But view.group_admin in the projection corresponds to the SUBGROUP creator (folded from GroupCreated ops), not the stored meta.admin_identity. These are different sources. If a subgroup's creator is different from the namespace root's meta.admin_identity, the projection counts the subgroup creator via branch 2 but view.rs counts the namespace root's meta.admin_identity. For a non-root group, the projection may declare "has another admin" (via branch 2, the subgroup creator) while view.rs does not (the subgroup has no meta.admin_identity row in the store). This asymmetry between the live path and the at-cut projection path could cause projection_membership_equivalence failures for subgroups.

Suggested fix:

Verify that for a non-root subgroup, `view.group_admin.get(&group)` and `MetaRepository::load(&group)?.admin_identity` refer to the same identity (i.e. the subgroup creator is always stored as `meta.admin_identity`). If they can diverge, the two paths need to be reconciled. Add a test case covering a non-root subgroup with a distinct creator to confirm the live and at-cut paths agree.

Found by: security-reviewer

2. Genesis founder counted as "another admin" even when they are the same as excluded

File: crates/governance-store/src/membership/view.rs (line 30-43) | Consensus: 1/1 agents ✓

The new has_another_admin implementation returns Ok(true) from the early-return branch (line 33-36) when a stored Admin row belongs to someone other than excluded. Then it falls through to the MetaRepository check (lines 38-42). However, if the stored-row scan finds no other admin but meta.admin_identity == *excluded, the function correctly returns Ok(false). The logic is sound for that case.

The subtle risk is the opposite scenario: excluded IS the genesis founder (meta.admin_identity == *excluded) AND there is exactly one stored Admin row that also belongs to excluded. The stored-row scan returns false (no OTHER admin row), and the meta check also returns false (admin_identity == *excluded). That is correct.

But consider: excluded is NOT the genesis founder, there are zero stored Admin rows for anyone else, and meta.admin_identity == excluded is false. The meta check fires and returns Ok(true) — the founder IS another admin. This is the intended fix.

One edge case remains: what if meta.admin_identity equals excluded but the stored-row scan already found another admin? The early-return fires first and returns Ok(true) — correct. So the logic is actually fine.

However, there is a subtle double-count risk: if the genesis founder ALSO has a stored Admin row (i.e. they were explicitly added as an admin member), the stored-row scan would count them as "another admin" when excluded != founder, AND the meta check would also count them. The early-return prevents the meta check from running in that case (the stored-row scan already returned true), so there is no double-count bug — but the code's correctness depends on the early-return short-circuit. This is fragile and worth a comment.

Suggested fix:

Add a comment above the `MetaRepository` check clarifying that it only runs when no stored-row admin was found, and that the genesis founder may also have a stored row (which the early-return already handles). This makes the short-circuit dependency explicit and prevents future refactoring from accidentally removing it.

Found by: security-reviewer

💡 Suggestion (1)

1. New test does not cover the case where lone_admin == founder

File: crates/governance-store/src/membership/tests.rs (line 158-183) | Consensus: 1/1 agents ✓

The new test block seeds lone_admin and founder as distinct random keys and asserts that ensure_not_last_admin_removal and ensure_not_last_admin_demotion return Ok. This covers the fix's happy path.

However, the regression that motivated the fix — lone_admin == founder (i.e. the only stored Admin row IS the genesis founder, so there truly is no other admin) — is not explicitly tested. Without this case, a future regression that accidentally counts meta.admin_identity even when it equals excluded would not be caught by this test suite.

Additionally, the test does not assert that ensure_not_last_admin_removal(&founder) (removing the founder themselves when they are the only admin) still returns Err — confirming the guard still fires for the actual last admin.

Suggested fix:

Add two sub-cases: (1) `lone_admin == founder` (same key for both stored row and meta) — assert `ensure_not_last_admin_removal` returns `Err`; (2) call `ensure_not_last_admin_removal(&founder)` in the existing test (where founder has no stored row but is the meta admin and lone_admin is a different stored admin) — assert it returns `Ok` (founder can be "removed" from a role they don't hold as a row, but the guard should not fire since lone_admin is still present).

Found by: security-reviewer

---

_{🤖 Generated by MeroReviewer | Review ID: review-5ee263d6}

[meroreviewer]

Documentation Review

The following documentation may need updates based on the changes in this PR:

• 🟡 architecture/auto-follow.html: Files matching crates/governance-store/** were changed but architecture/auto-follow.html was not updated (per source_to_docs_mapping).
• 🟡 architecture/crates/context.html: Files matching crates/context/** were changed but architecture/crates/context.html was not updated (per source_to_docs_mapping).
• 🟡 architecture/local-governance.html: Files matching crates/governance-store/** were changed but architecture/local-governance.html was not updated (per source_to_docs_mapping).
• 🟡 architecture/membership-and-leave.html: Files matching crates/context/** were changed but architecture/membership-and-leave.html was not updated (per source_to_docs_mapping).

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 1 agents | Quality score: 27% | Review time: 85.7s

---

🟡 Warning (2)

1. group_admin double-counts the genesis founder already counted by the root tuple

File: crates/context/src/scope_projection.rs (line 1484-1487) | Consensus: 1/1 agents ✓

The has_other expression now has three OR branches: (1) a distinct Admin-role ROW, (2) view.group_admin.get(&group) != member, and (3) the root tuple root_admin != member. view.group_admin stores the subgroup creator / genesis admin per group, and root is the namespace-root genesis admin. For the namespace root group these two can refer to the same identity, so branch (2) and branch (3) can both fire for the same person — harmless for correctness (OR is idempotent) but the comment says they are distinct sources. More importantly, for a non-root group view.group_admin.get(&group) is the subgroup creator, while root is the namespace-root admin; both are now counted as "another admin". This is a semantic expansion beyond what the PR description says: the PR says "credit the derived/genesis founder", but branch (2) credits ANY subgroup creator (not just the namespace founder). If a subgroup creator is not the namespace founder, they may not have admin authority in the governance sense, yet they now satisfy has_other. Verify this is intentional.

Suggested fix:

If the intent is only to credit the namespace-root genesis admin (as the PR description states), remove branch (2) (`view.group_admin.get(&group).is_some_and(|a| a != member)`) and keep only branch (3) (the root tuple check). If subgroup creators should also count, update the doc-comment to say so explicitly.

Found by: security-reviewer

2. has_another_admin counts genesis founder even when they are the excluded member

File: crates/governance-store/src/membership/view.rs (line 29-44) | Consensus: 1/1 agents ✓

The new MetaRepository fallback at line 41 checks meta.admin_identity != *excluded, which is correct for the case where excluded is a promoted admin and the founder is someone else. However, consider the symmetric case: if excluded IS the genesis founder (i.e. meta.admin_identity == *excluded) and there are no other Admin rows, the function correctly returns false. But if excluded is the genesis founder AND there is another Admin row, the first branch already returns true before reaching the fallback — so that path is fine. The subtle risk is when meta.admin_identity equals a stored Admin-row member who is NOT excluded: the fallback would double-count that identity (once via the row scan, once via the meta check). This is harmless for correctness (it still returns true) but the comment says "which has no stored row" — if the genesis founder later gets a stored Admin row, the fallback still fires and returns true redundantly. This is not a bug but the comment is misleading and could cause confusion during future maintenance.

Suggested fix:

Add a guard to the fallback: only consult `meta.admin_identity` when it has no stored Admin row, or document explicitly that double-counting is harmless. E.g.: `Ok(MetaRepository::new(self.store).load(&self.group_id)?.is_some_and(|meta| meta.admin_identity != *excluded))`  is already correct — just clarify the comment to say 'may double-count if the founder also has a row, but that is harmless'.

Found by: security-reviewer

💡 Suggestion (1)

1. New test does not cover the case where lone_admin == founder

File: crates/governance-store/src/membership/tests.rs (line 158-183) | Consensus: 1/1 agents ✓

The new test block verifies that a sole Admin-row member is demotable/removable when founder != lone_admin. It does not add a regression test for the boundary case where lone_admin == founder (i.e. the genesis founder IS the only Admin row), which should still be blocked as the last admin. Without this case the test suite does not pin the invariant that the fix does not accidentally allow removing the founder when they are also the sole Admin row.

Suggested fix:

Add a sub-case: create a group where `lone_admin == founder` (same key for both the Admin row and `meta.admin_identity`), and assert that `ensure_not_last_admin_removal` returns `Err` (still the last admin).

Found by: security-reviewer

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-6bef1266}

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 1 agents | Quality score: 28% | Review time: 138.1s

---

🟡 Warning (1)

1. Double-counting when genesis founder also has an Admin row

File: crates/governance-store/src/membership/view.rs (line 30-44) | Consensus: 1/1 agents ✓

The new has_another_admin first checks stored rows for any admin other than excluded, then unconditionally checks meta.admin_identity != *excluded. If the genesis founder (meta.admin_identity) also has a stored Admin row AND is not excluded, the row-scan already returns true — that is fine. But if the genesis founder IS excluded, the second check asks whether meta.admin_identity != excluded, which is false — also fine. The real edge case is: genesis founder == excluded, and there is exactly one OTHER stored Admin row. The row scan returns true (correct). No double-count there either.

However, consider the symmetric case: genesis founder != excluded, and the founder has NO stored row. The second check returns true — the founder counts as another admin. This is the intended fix. But if the founder DOES have a stored Admin row, the row scan already returns true and the second check is redundant but harmless.

The actual logic gap is more subtle: meta.admin_identity is the genesis admin at namespace creation time. After an AdminChanged op, the live group_admin in the projection is updated, but meta.admin_identity in the store is NOT updated (it is the immutable genesis fact). So has_another_admin in view.rs may count a stale genesis identity as "another admin" even after that identity was superseded by AdminChanged. This diverges from is_last_admin_at_cut in scope_projection.rs, which uses the folded view.group_admin (which DOES track AdminChanged). The live path and the at-cut path now have different semantics for the "another admin" check when AdminChanged has been applied.

Suggested fix:

Either (a) also check `view.group_admin` in the live path (not available in `GroupMembershipView` today, which is store-only), or (b) document explicitly that `meta.admin_identity` is the immutable genesis admin and that `AdminChanged` is not reflected here, and add a test that covers the post-`AdminChanged` scenario to confirm the intended behaviour. At minimum, add a comment noting this divergence from the at-cut path.

Found by: security-reviewer

💡 Suggestion (2)

1. New test does not cover the case where founder == lone_admin

File: crates/governance-store/src/membership/tests.rs (line 158-184) | Consensus: 1/1 agents ✓

The new test case covers founder != lone_admin (the fix's target scenario). It does not add a regression test for the case where founder == lone_admin (i.e., meta.admin_identity == lone_admin and there are no other admins), which should still return Err from ensure_not_last_admin_removal. Without this, a future refactor that accidentally removes the != *excluded check would not be caught by the test suite.

Suggested fix:

Add an assertion: when `founder_meta.admin_identity == lone_admin` (same identity), `ensure_not_last_admin_removal(&lone_admin)` must return `Err` (last-admin guard still applies).

Found by: security-reviewer

2. group_admin and root checks in has_other may overlap

File: crates/context/src/scope_projection.rs (line 1484-1490) | Consensus: 1/1 agents ✓

The has_other expression checks both view.group_admin.get(&group).is_some_and(|a| a != member) AND root.as_ref().is_some_and(|(root_g, root_admin)| *root_g == group && root_admin != member). For the namespace root group, view.group_admin is populated by AdminChanged ops (which update group_admin), while root is the immutable genesis admin from meta.admin_identity. After an AdminChanged op, both could be set to different values, potentially double-counting two distinct "other admins" when there is actually only one. This is harmless for the boolean result (OR-ing two trues is still true), but it means the comment "another admin = a distinct Admin-role ROW or the genesis founder" is slightly imprecise — it could count both the current group_admin and the genesis root admin as separate "other admins".

Suggested fix:

Add a comment clarifying that for the root group, `group_admin` tracks `AdminChanged` while `root` is the immutable genesis admin, and that double-counting is harmless for the boolean invariant check.

Found by: security-reviewer

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-c64eeac9}

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 1 agents | Quality score: 27% | Review time: 145.2s

💡 1 suggestions. See inline comments.

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-6b45bc36}

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 2 agents | Quality score: 42% | Review time: 119.2s

🟡 1 warnings. See inline comments.

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-88e020c0}

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 2 agents | Quality score: 40% | Review time: 117.2s

---

🟡 Warning (4)

1. has_another_admin counts genesis founder even when no Admin row exists for them

File: crates/governance-store/src/membership/view.rs (line 38-45) | Consensus: 1/2 agents

The new MetaRepository load at line 42 returns true whenever meta.admin_identity != *excluded, regardless of whether the genesis founder is actually an admin. If the founder has been demoted or removed (their admin status changed via governance ops), this check would still count them as 'another admin', potentially allowing the last real admin to be removed. The precondition comment says callers confirm excluded is an admin, but the genesis founder's current admin status is not verified here — only their identity inequality is checked.

Suggested fix:

Before counting the genesis founder as 'another admin', verify they are actually still an admin (e.g., check `is_admin` for `meta.admin_identity`). If the founder's admin status can change via governance ops, this check needs to reflect the current state, not just identity inequality.

Found by: security-reviewer

2. has_another_admin counts genesis founder even when no meta row exists

File: crates/governance-store/src/membership/view.rs (line 38-46) | Consensus: 1/2 agents

When MetaRepository::load returns Ok(None) (no meta row for the group), is_some_and short-circuits to false, which is correct. However, when meta IS present but admin_identity is the zero/default public key (e.g. a group created without explicitly setting meta), the genesis founder is counted as "another admin" even though it is a sentinel value, not a real identity. This is a latent correctness risk introduced by this PR. The projection path in scope_projection.rs has the same exposure via root.as_ref().is_some_and(...). Consider asserting or documenting that admin_identity is always a real key before this check runs, or filtering out the zero key.

Suggested fix:

Add a guard: `is_some_and(|meta| meta.admin_identity != PublicKey::default() && meta.admin_identity != *excluded)`. Alternatively, document in `GroupMetaValue` that `admin_identity` must never be the zero key.

Found by: patterns-reviewer

3. is_last_admin_at_cut double-counts group_admin when it equals the genesis root admin

File: crates/context/src/scope_projection.rs (line 1484-1487) | Consensus: 1/2 agents

The has_other expression ORs three independent conditions: (1) a distinct Admin-role row, (2) view.group_admin.get(&group) != Some(member), and (3) the genesis root admin when it differs from member. For the namespace root group, view.group_admin and root may refer to the same identity (the subgroup creator stored in group_admin IS the genesis admin stored in root). If that identity differs from member, both conditions (2) and (3) fire, which is harmless for correctness but means the same identity is counted twice. More importantly, if view.group_admin holds a DIFFERENT identity from root.root_admin for the same group (possible if AdminChanged updated group_admin but root still reflects the genesis), condition (2) could count a non-genesis admin as "another admin" even though they are the same person as member under a different key. The logic should be: collect the distinct set of "other admin" identities and check if it is non-empty, rather than three independent boolean ORs.

Suggested fix:

Build a small set: `let mut others = BTreeSet::new(); if let Some(m) = rows { others.extend(m.iter().filter(|(k,r)| *r==Admin && k!=member).map(|(k,_)| k)); } if let Some(a) = view.group_admin.get(&group) { if a != member { others.insert(a); } } if let Some((rg, ra)) = root.as_ref() { if rg == &group && ra != member { others.insert(ra); } } let has_other = !others.is_empty();`

Found by: patterns-reviewer

4. is_last_admin_at_cut double-counts group_admin and root as 'another admin' independently

File: crates/context/src/scope_projection.rs (line 1484-1488) | Consensus: 1/2 agents

The has_other computation ORs three conditions: a distinct Admin-role row, view.group_admin.get(&group) != Some(member), and the root genesis admin. The second condition (view.group_admin.get(&group).is_some_and(|a| a != member)) fires whenever ANY group_admin exists for the group that is not member, even if that group_admin is the same identity as member_is_admin's root check. This could count the same identity twice across the second and third conditions, but more critically, view.group_admin.get(&group) returning Some(other) does not verify other is still an admin — it's the subgroup creator, which may have been demoted. This is a pre-existing design issue but the new code extends it.

Suggested fix:

Document clearly that `group_admin` in the AclView represents the subgroup creator/genesis admin and is treated as permanently admin-equivalent, or add a note that this is intentional and consistent with `member_is_admin` logic above.

Found by: security-reviewer

💡 Suggestion (1)

1. New test cases reuse the same store/gid across the symmetric sub-case

File: crates/governance-store/src/membership/tests.rs (line 158-197) | Consensus: 1/2 agents

The "symmetric case" (lines ~185-197) mutates founder_store/founder_gid by saving a new sole_founder_meta on top of the previous founder_meta. This means the test relies on the store being mutable mid-test and the founder_policy object (created before the meta update) still reading the updated meta at call time. While this works because MembershipPolicy reads the store lazily, it is fragile: if MembershipPolicy ever caches meta at construction time, the symmetric assertions would silently pass vacuously. Using a fresh store+gid for the symmetric case would make the two sub-cases independent.

Suggested fix:

Create a second `let sole_store = test_store(); let sole_gid = test_group_id();` for the symmetric sub-case and add `lone_admin` as an Admin row there before saving `sole_founder_meta`.

Found by: patterns-reviewer

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-a29059fd}

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 2 agents | Quality score: 41% | Review time: 144.4s

🟡 1 warnings, 💡 1 suggestions. See inline comments.

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-8e91a5bf}

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 2 agents | Quality score: 40% | Review time: 221.9s

🟡 2 warnings. See inline comments.

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-c46c8b33}

[meroreviewer]

🟡 Non-admin excluded identity silently returns false instead of error

The new early-return if !self.is_admin(excluded)? { return Ok(false); } changes the observable contract of has_another_admin. Previously a caller passing a non-admin excluded would get Ok(false) only because no admin rows matched it — the semantics were 'is there another admin besides this identity'. Now the function returns Ok(false) for a non-admin for a different reason: 'this identity is not an admin, so the question is moot'. The comment says this is intentional, but callers that pass a non-admin identity (e.g. a member being demoted) and expect the function to tell them whether any admin exists will now get false even when admins do exist. The ensure_not_last_admin_demotion / ensure_not_last_admin_removal callers appear to always pass the identity being acted on, which is checked to be an admin first, so the current callers are safe — but the silent false for a non-admin is a footgun for future callers. Consider returning an error or a distinct Ok(false) with a clearer name, or at minimum document that Ok(false) means 'not applicable' as well as 'no other admin'.

Suggested fix:

Either rename the function to `has_another_admin_if_admin` and document the dual meaning, or return an `Err` (e.g. `MembershipError::NotAdmin`) when `excluded` is not an admin, so callers cannot silently misinterpret the result.

[meroreviewer]

🟡 MetaRepository::load failure silently treated as 'no genesis founder'

If MetaRepository::new(self.store).load(&self.group_id) returns an Err, the ? propagates it correctly. But if it returns Ok(None) — meaning no meta row exists for this group — the genesis founder is silently treated as absent and has_another_admin returns Ok(false). In a namespace where the meta row was never written (e.g. a subgroup that has no GroupMetaValue), this is correct. However, for the root namespace group where meta should exist but is transiently missing (e.g. a partial write), the function will incorrectly conclude there is no genesis founder and allow a last-admin removal. This is a pre-existing risk that the new code path now makes load-bearing for correctness.

Suggested fix:

Add a tracing warn when `load` returns `Ok(None)` for a group that has at least one Admin row, since that is an unexpected state for a namespace root. This makes the silent fallback observable without changing the return value.

[meroreviewer]

🤖 AI Code Reviewer

Reviewed by 2 agents | Quality score: 41% | Review time: 305.2s

🟡 3 warnings. See inline comments.

---

_{🤖 Generated by AI Code Reviewer | Review ID: review-c9d83961}

[meroreviewer]

🟡 Non-admin excluded from genesis-founder check, but is_admin only checks stored rows

The early-return guard if !self.is_admin(excluded)? { return Ok(false); } is intended to prevent a non-admin from being credited as "another admin" via the genesis founder. However, is_admin only checks stored GroupMember rows. If excluded is the genesis founder but has no stored Admin row (the exact scenario this PR fixes — founder derived from genesis, not materialised as a row), is_admin returns false and the function returns Ok(false) before ever reaching the genesis-founder check. This means has_another_admin would incorrectly return false for a genesis founder who has no stored row, even when another stored Admin row exists. The guard defeats the fix for the founder-without-row case.

Suggested fix:

Either (a) extend the admin check to also credit the genesis founder (mirror `is_last_admin_at_cut`'s `member_is_admin` logic), or (b) move the early-return guard to after the genesis-founder check, so a founder without a stored row still reaches the `meta.admin_identity != *excluded` path.

[meroreviewer]

🟡 **Non-admin excluded returns false but callers interpret it as **

The new early-return if !self.is_admin(excluded) { return Ok(false); } changes the semantics of has_another_admin. Before the fix the function answered

Suggested fix:

Document the new contract explicitly in the doc-comment, or rename the function to `is_last_admin` (returning `true` when `excluded` is the last admin) to make the boolean polarity unambiguous. At minimum add a doc-comment sentence: `Returns false when excluded is not an admin (a non-admin can never be the last admin).`

[meroreviewer]

🟡 Genesis founder counted as "another admin" even when no meta row exists

The final Ok(MetaRepository::new(self.store).load(&self.group_id)?.is_some_and(|meta| meta.admin_identity != *excluded)) returns false when load returns None (no meta row). That is correct for the "no founder" case, but it silently swallows a store error that ? would propagate — load returns EyreResult, so ? is already used. The logic is fine; the concern is that a transient store fault on load would be propagated as an error (correct), but the absence of meta is treated as "no other admin" (also correct). However, the at-cut path in scope_projection.rs reads MetaRepository unconditionally and the live path now also reads it, adding a second store round-trip on every has_another_admin call even in the common case where a second Admin row already exists. Consider short-circuiting before the MetaRepository read when the row-scan already found another admin (which the current code already does via the early return Ok(true) — this is fine). No code change strictly required, but worth noting the extra I/O on the hot path.

Suggested fix:

No change required for correctness; the early `return Ok(true)` already avoids the extra read when a second Admin row exists. Add a comment noting the `None`-meta case is intentionally treated as "no genesis founder".