Skip to content

docs: add custody-transfer / membership-churn flow (R-36)#28

Open
ChelseaKR wants to merge 1 commit into
mainfrom
roadmap/custody-transfer-membership-churn-flow-r-11
Open

docs: add custody-transfer / membership-churn flow (R-36)#28
ChelseaKR wants to merge 1 commit into
mainfrom
roadmap/custody-transfer-membership-churn-flow-r-11

Conversation

@ChelseaKR

Copy link
Copy Markdown
Owner

A documented, manual flow for handing off a case when a union member
leaves — built entirely on commands that exist today (sync, key rotate,
key backup, key restore, status, export). No new code, matching the key
custody playbook's own framing that the transfer flow is manual and
documented; explicitly no threshold recovery and no transfer command.

New docs/custody-transfer.md covers:

  • scope, principles (member's data, consent-first, no honeypot)
  • Scenario A: cooperative departure (sync -> rotate / re-issue backup)
  • Scenario B: unreachable member (restore from second organizer's blob,
    then rotate; plain about the case being gone if no backup exists)
  • Scenario C: steward change without a departure
  • Devon's board question ("whose data is it?") with cross-references
  • per-scenario checklists

Also:

  • key-custody-playbook.md: replace the "on the backlog" parenthetical
    with a link to the new flow
  • adoption/board-risk-briefing.md + adoption/README.md: one-line
    pointers answering P-13's question directly
  • research/execution-log.md: mark R-36 done (feedback study doc left
    untouched, as its Roadmap column classifies origin, not completion)

Verified every cited CLI invocation against src/habitable/cli.py.
make test (pytest -m "not integration") green: 196 passed.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com


Backfill PR for a completed roadmap item (roadmap/custody-transfer-membership-churn-flow-r-11, 1 commit(s) over main). Part of the portfolio roadmap batch.

A documented, manual flow for handing off a case when a union member
leaves — built entirely on commands that exist today (sync, key rotate,
key backup, key restore, status, export). No new code, matching the key
custody playbook's own framing that the transfer flow is manual and
documented; explicitly no threshold recovery and no transfer command.

New docs/custody-transfer.md covers:
- scope, principles (member's data, consent-first, no honeypot)
- Scenario A: cooperative departure (sync -> rotate / re-issue backup)
- Scenario B: unreachable member (restore from second organizer's blob,
  then rotate; plain about the case being gone if no backup exists)
- Scenario C: steward change without a departure
- Devon's board question ("whose data is it?") with cross-references
- per-scenario checklists

Also:
- key-custody-playbook.md: replace the "on the backlog" parenthetical
  with a link to the new flow
- adoption/board-risk-briefing.md + adoption/README.md: one-line
  pointers answering P-13's question directly
- research/execution-log.md: mark R-36 done (feedback study doc left
  untouched, as its Roadmap column classifies origin, not completion)

Verified every cited CLI invocation against src/habitable/cli.py.
make test (pytest -m "not integration") green: 196 passed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants