Tracking: make trust, governance and exit visible #417

Why

A stack should leave the people who use it in control of their own practice. That means four things:

• The trade-offs are stated, not discovered. Who can read the data, what a host sees, and what a lost key costs.
• Power over others is visible. In a group stack, roster changes and grants are made by a few people and affect everyone else.
• Leaving never needs permission. A group can move hosts, or self-host, without the current host's cooperation and without losing authorship or history.
• The reversible is preferred over the irreversible, and losing data to a key or a host is treated as the worst outcome.

Most of what Haverstack already does fits these. The gaps are mostly in what the spec leaves unsaid or defers: key custody, who acts as a Group, what members can see, and how a stack leaves a host.

Decisions this work rests on

• Undeclared content fields stay refused (data-model.md § Undeclared content fields). A typo needs an error, not a warning an app may never show. Extension stays deliberate: sidecar types and declared open containers.
• Core doesn't encrypt. The host can read everything, metadata included. A group with high security needs self-hosts or moves to a host it controls, so moving hosts must be lossless.
• Member voice lives in data. Core makes governance visible; proposals and votes are non-binding commons records whose meaning each group decides. Enforced rules wait for key lifecycle, since whoever acts as the owner bypasses any rule core enforces.
• Member exit stays as it is. Authorship confers no read, so removal from a roster cuts a member's reach, including to what they wrote. Removal stays a clean safety tool.
• Spec text is written once, in its final form. A gap is described in the issue that fixes it, not in the spec ahead of the fix.

Issues

State what's true now (docs only, no dependencies):

• Spec: a trust model page #418 Spec: a trust model page
• Spec: state who governs a group stack, and what removal takes away #419 Spec: state who governs a group stack, and what removal takes away
• Commons guide: lead with the strict-fields rule and the extension paths #420 Commons guide: lead with the strict-fields rule and the extension paths
• Add trust, defaults, reversibility and formats to the existing design rules #421 Add trust, defaults, reversibility and formats to the existing design rules
• Guide: what to expect from a community host #430 Guide: what to expect from a community host

Leaving a host:

• Portable export and full-fidelity import #426 Portable export and full-fidelity import
• A hosted stack's owner can copy it out over the wire #427 An export endpoint only the owner can call (blocked by Portable export and full-fidelity import #426)

Voice:

• Commons: finish poll and vote as a group's non-binding voice #425 Commons: finish poll and vote as a group's non-binding voice

Keys and governance:

• Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422 Design: key lifecycle (custody, recovery, rotation, and acting as a Group)
• Design: a stack names its own roster #423 Design: a stack names its own roster (blocked by Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422)
• Members can see their stack's governance changes #424 Members can see their stack's governance changes (blocked by Design: a stack names its own roster #423)
• Design: sealed Records for a group's sensitive data #428 Design: sealed Records for a group's sensitive data (blocked by Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422)
• Design: group charters, recall and term limits #429 Design: group charters, recall and term limits (blocked by Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422 and Design: a stack names its own roster #423)