Member setup checklists

Invariant: a step should show Done only when the assigned member's same-organization records establish completion. There is no completion write API. Members find their checklist in Settings → People & access → Member setup checklists, with a reminder on Projects when enabled. Admins create ordered templates, assign a template to a member and a project the member can reach, and see paginated progress. The migration seeds Agency outreach member for every org. Custom templates stay in their own org. Completion: active Gmail, connected Outlook or connected Zoho mailbox; a complete import job by the member with a successful result pointing to an existing same-org CRM contact; active member DM Discord pairing; fulfilled secret request with a secure card and existing vault entry; current policy acknowledgement; a ticket reported by the member in the assigned project. Sending domain setup is Coming soon on this base; it cannot complete until the separate blueprint is integrated. Credential requests reuse the existing DM and secret-request routes, always supply conversationId, and never collect or reveal values on onboarding. Credential work queues before its transaction to keep the shared pool available for DM creation; assignment row locks coordinate separate API instances. A failed request releases capacity for the next attempt. Nudges are in-app only. They send no external message. The admin setting takes effect after server confirmation. Feature defaults ON. MEMBER_ONBOARDING_ENABLED=false unregisters the API routes; the UI entry disappears on their 404. No provider flag, permit, policy limit, or production setting is changed by assigning a checklist or acknowledging policy. Local acceptance: acceptance/p51-member-onboarding-checklist.live.json is executable by the supplied live-accept runner with a local fake member storage-state. For a production org, copy the spec and replace member-onboarding-lab with the approved org slug, then run the same runner with --base and --storage-state. Production verification is MANUAL-PENDING; deploy/promotion and production access are outside this lane.

The kit records whole-shell HTTP errors separately. Invites (403 for a member) and dark chat sidebar/preferences (404) reproduce on pinned base ff738aa87; feature acceptance asserts the checklist actions and rejects any failing onboarding request.

The signed-in human route family is /v1/orgs/{orgId}/member-onboarding. It includes catalog, personal assignments, admin progress, templates, assignment creation, policy acknowledgement and credential-card requests. These person-session routes stay outside the public integration document and do not grant an API key the member's identity. Reads recheck current project access; a revoked project cannot expose its name or ticket state. A pending credential can be reused only while its live card is in the member's current conversation.

• API reference: /v1/openapi.json describes the public integration surface; this settings family is person-only.
• MCP tools: MCP tool reference; member setup has no agent tool.
• Runbook: Member setup.