Add privacy-safe account Block List management

[KalebCole]

User scenario

I want to review my Partiful Block List and explicitly block or unblock an account without opening the app, while keeping blocked-account details private in logs and agent responses.

Problem

Partiful exposes a Block List in account settings. The CLI has no block-list read or mutation commands, no endpoint contracts, and no safe output policy for this sensitive account state.

Verified product and API facts

The current product shows Block List as a durable account setting. The CLI source has no block or unblock implementation. The current-user payload does not contain a blocked-user collection, so this is a separate account contract rather than a profile field.

Bundle searches did not recover a complete read/add/remove protocol. Authenticated probes using guessed operation names returned 404. Those guesses are not evidence and must not become implementation names. No block mutation was attempted.

Proposed experience

Subject to API discovery:

partiful account blocks list
partiful account blocks add --user-id <id> --dry-run
partiful account blocks remove --user-id <id> --dry-run
partiful schema account.blocks.add

Normal output should use safe display names and status, not raw IDs or private account details. JSON may retain only identifiers required for deterministic follow-up under the CLI's explicit machine-output contract.

Scope boundaries

• Blocking is a safety action, not contact tagging, guest removal, or event banning.
• Do not discover targets from hidden guest lists or expose blocked users through ordinary contact output.
• Add and remove must require exact target resolution. Never choose among duplicate names automatically.
• Unblocking needs explicit confirmation because it relaxes a safety boundary.
• --dry-run must not change account state.
• Keep Opt-Out List separate until its semantics are verified.

Discovery needed

Use the current app or controlled network capture to verify canonical list/add/remove operations, request envelopes, target identifiers, pagination, idempotency, error behavior, block effects, and read-back timing. Determine which display fields are safe and whether blocked accounts disappear from Mutuals, events, messages, or discovery. Do not infer those effects from the setting label.

Acceptance criteria

• A canonical, verified Block List API contract is documented before implementation.
• Users can list blocked accounts without exposing phone numbers, authentication metadata, or unnecessary internal details.
• Users can block an exactly resolved account with confirmation and --dry-run support.
• Users can unblock an exactly resolved account with stronger confirmation and --dry-run support.
• Mutations read back the resulting block state.
• Empty Block List is a successful deterministic result.
• Duplicate names, unavailable targets, already-blocked/already-unblocked states, permission failures, and read-back mismatches produce structured results or errors.
• CLI help, schemas, privacy tests, unit tests, and controlled E2E tests with restoration ship together.

Related work

#76 handles permitted Mutual and attendee discovery. Blocking must not bypass or weaken its roster privacy rules. Opt-Out List has a separate setting and unknown semantics, so it should not be implemented as an alias for blocking.