Design: group charters, recall and term limits #429

Problem

A group stack's members have no encoded say in how its admins use their power. A group may want rules like "removing a member needs two admins", "admin roles expire unless renewed", or "a majority of members can recall an admin".

Core shouldn't pick a form of governance for every group. It could let a group state its own and enforce whatever it says.

Direction

• A charter Record in the group's stack declares which actions need what approval. Stack enforces it. The default charter is today's behavior, so a group that writes none sees no change.
• Recall and term limits are expressible in a charter, and worth offering as templates.
• Approvals are carried by the commons poll/vote Records from Commons: finish poll and vote as a group's non-binding voice #425.

Why it waits

Whoever acts as the owner bypasses any rule core enforces, so a charter binds only admins acting as themselves. It's worth building once #422 settles who acts as a Group (for example, through delegations that can be revoked) and #423 defines the roster a charter governs. Until then it would be mostly theater.

Costs to weigh

A charter engine is procedure, and procedure is prescriptive in its own way. It also adds a permission path every scoped write must consult.

Order

Blocked by #422 and #423.