Resolve group eNames to their members, by eName or profile id

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Follow-up to #1122. A group eName in a policy now resolves to the eNames of its members, so naming a group in a grant or denial actually does something.

Closes the fail-open flagged in #1122: a denial naming a group previously matched nobody and silently failed to deny.

Both member reference forms

A group's participant list names members two different ways in practice, and the resolver accepts both because both are already in the data:

Written as	Where it occurs	Resolved by
An eName	GroupManifest.members	Taken as-is.
A profile record's id	Group.participantIds (users(participants[].id),participantIds in the platform mappings)	Following the record to the eName behind it.

A profile id resolves through that record's own ename field where it has one, falling back to the vault the record lives in. The record's own statement wins because the same profile syncs into several vaults, so the vault it happens to sit in does not reliably identify its subject. An id resolving to nothing is skipped rather than counted.

Group records are found either in the group's own vault or by an ename field naming the group, across the Group/Chat (550e8400-…-440003) and GroupManifest (a8bfb7cf-…) ontologies. Participants are read from members, memberIds, participants, participantIds, admins and owner and unioned — so admins and the owner count as members.

Undeterminable membership is not "not a member"

The distinction matters because the two cases lead to opposite answers, and collapsing them would be wrong in one direction or the other:

• A grant to a group applies only on proof of membership. Uncertainty withholds it.
• A denial naming a group applies unless the party is shown not to be a member. Uncertainty holds the denial.

So a group whose record cannot be read hands out nothing and stops removing nothing. A resolver that throws yields unknown rather than no.

With no resolver configured at all, groups match nobody — that is the feature switched off rather than a lookup that failed, and it keeps every pre-existing decision unchanged.

Resolution is skipped when it cannot matter

A user or platform grant outranks any group grant, so when a direct grant matches, no group is resolved at all — there is a test asserting zero resolver calls in that case. Within one decision each group is resolved at most once, including across a grant and a denial naming it.

API shape

evaluate's fourth argument moves from a bare ConditionEvaluator to { conditions?, groups? }, since there are now two collaborators. mostSpecificGrant becomes async.

Testing

• 13 engine tests with a fake resolver: group grants and denials, matching through the carrying platform, direct-grant precedence, union across several groups, the zero-lookups optimisation, per-decision caching, and both directions of undeterminable membership.
• 12 resolver tests against real Neo4j covering both reference forms explicitly — members by eName, members by profile id, mixed lists, the stated-ename and vault-fallback paths, dangling ids, scalar owner, every participant field unioned, deduplication, unknown groups, non-eName input, and non-group records.
• 4 guard tests end to end, including one group whose members are written both ways in the same record, and one asserting a group denial stays inert when no resolver is configured.

249/249 across 19 files. Typecheck clean; docs build passes with onBrokenLinks: 'throw'.

Docs

The group limitation is removed from the protocol doc, the post-platform guide, and the bundled skills/w3ds reference, replaced with how resolution works and both reference forms. Adds "How a group resolves" and "When membership cannot be determined" to the protocol doc, "Naming a group instead of a person" to the implementation guide, and extends the glossary's Group entry.

Still not in scope

Condition evaluation remains an unconnected seam, and enforcement is still eVault-side only. Group resolution reads records this eVault holds, so a group that has not synced here is undeterminable — which the docs spell out in both directions.

https://claude.ai/code/session_01UpwygDu2cizLp12tvvKqVZ

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: edc0e324-3c0d-46a5-acb3-e1c2844693ea

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}