Context
app-components/group-profile-v1.md, "Authorization" (lines 45-51):
## Authorization
Only an active admin MAY send a standalone profile update proposal.
Only an active admin MAY commit a profile update.
The admin check is evaluated against the prior epoch state.
Defect
"The admin check" is set off as its own trailing sentence after both the proposal-authorization sentence and the commit-authorization sentence, leaving it ambiguous which check(s) it modifies. This differs from its structurally similar siblings that also state an epoch rule: admin-policy-v1.md (line 82) explicitly names which check it modifies ("The commit authorization is evaluated against the prior epoch's active admins"), and group-encrypted-media-v1.md (lines 102-103) keeps its epoch sentence in the same paragraph immediately after "commit," tying it unambiguously to the commit check. group-profile-v1.md is the only one of the three documents that states an epoch rule at all whose placement leaves the scope genuinely unclear.
This is a different problem from open issue #201, which is about the other five components never stating an epoch rule at all — #201 in fact cites group-profile-v1.md:51 as one of the 3 components that already "explicitly" states the rule. Fixing #201 by adding epoch statements to the silent components would not resolve this document's own internal ambiguity about what its existing statement covers.
Failure scenario
Two conformant implementations both read "the admin check" as applying to only one of the two authorization checks — one applies it to the commit check only, the other applies it to both. A member who was an active admin in the prior epoch but is removed from admins in the very commit that also carries a pending profile-update proposal is accepted by one implementation and rejected by the other, producing a validity fork on otherwise-identical commit bytes.
Suggested fix
Rephrase as "The commit authorization is evaluated against the prior epoch state" (matching admin-policy-v1.md's phrasing), or explicitly state it covers both checks, and move it into the same paragraph as whichever check(s) it governs.
Context
app-components/group-profile-v1.md, "Authorization" (lines 45-51):Defect
"The admin check" is set off as its own trailing sentence after both the proposal-authorization sentence and the commit-authorization sentence, leaving it ambiguous which check(s) it modifies. This differs from its structurally similar siblings that also state an epoch rule:
admin-policy-v1.md(line 82) explicitly names which check it modifies ("The commit authorization is evaluated against the prior epoch's active admins"), andgroup-encrypted-media-v1.md(lines 102-103) keeps its epoch sentence in the same paragraph immediately after "commit," tying it unambiguously to the commit check.group-profile-v1.mdis the only one of the three documents that states an epoch rule at all whose placement leaves the scope genuinely unclear.This is a different problem from open issue #201, which is about the other five components never stating an epoch rule at all — #201 in fact cites
group-profile-v1.md:51as one of the 3 components that already "explicitly" states the rule. Fixing #201 by adding epoch statements to the silent components would not resolve this document's own internal ambiguity about what its existing statement covers.Failure scenario
Two conformant implementations both read "the admin check" as applying to only one of the two authorization checks — one applies it to the commit check only, the other applies it to both. A member who was an active admin in the prior epoch but is removed from
adminsin the very commit that also carries a pending profile-update proposal is accepted by one implementation and rejected by the other, producing a validity fork on otherwise-identical commit bytes.Suggested fix
Rephrase as "The commit authorization is evaluated against the prior epoch state" (matching
admin-policy-v1.md's phrasing), or explicitly state it covers both checks, and move it into the same paragraph as whichever check(s) it governs.