rastrillo / idear Public

What: a compile-time toggle for how far an actor's authority reaches.

• Default build (unchanged): an actor grants and manages only ranks strictly below their own. Admins manage Members.
• go build -tags idear_peers: reach is up to and including the actor's own rank. Admins can invite/promote people to Admin, and can demote, remove and restore other Admins.
• idear.PeerGrants (exported const) reports which build you're in.

Owner: the same in both builds. It is a singleton, not a rank with peers. RoleOwner is never granted (only Transfer), and MayActOn now refuses an Owner target as an explicit rule. Before this, that refusal came from "nothing ranks above owner", which stops being true once equal rank is in reach.

Why a build tag, not a Config field: MayActOn and Grantable are pure package functions that apps call without a Roster (the example's members page does this). They must give the same answer as the store. A per-Roster setting would give them a second source of truth.

Granting and managing move together: both call one predicate, reaches. Changing only the grant half would let an Admin create Admins that no Admin could then manage.

Tests: every mode-specific assertion states both builds' answers by hand. make ci gains test-peers, which runs vet and the tests under the tag. amadan CI gains 35-test-peers. I also checked two mutations against the peers build and both made the tests fail.