Epic: Build private member profiles and Slack onboarding

Product outcome

A verified durable account can own one private community accounts.MemberProfile, complete and maintain it once, and use that confirmed profile to become eligible for secret-safe Slack access. The same account-owned service supports self-service onboarding, authorized support correction, and privacy lifecycle integration without creating, synchronizing, or inferring the public GitHub-backed content.Person identity.

#108 is the parent epic and coordination/HUMAN acceptance record. It is not one engineer-sized change. Delivery is split into bounded child issues filed by the orchestrator and independently groomed, engineered, tested, PM-accepted, merged, and observed under _docs/PROCESS.md.

Course registration, cohort evidence, and learner-preservation implementation are no longer owned here: #242, #243, and #244 own those boundaries. They may consume only the accepted accounts-owned confirmed-profile service and immutable scalar contract.

Normative authority

• _docs/PROCESS.md: role-separated issue lifecycle and release evidence.
• _docs/architecture/app-boundaries.md: accounts owns CustomUser, private MemberProfile, and Slack grants; content.Person remains separate; public, Studio, API, job, and command code are adapters over owning services.
• _docs/specs/01-platform-architecture.md: member-profile version 1, account ownership, completion, and expand-and-contract architecture.
• _docs/specs/03-github-content-and-people.md: strict private MemberProfile versus public editorial Person boundary.
• _docs/specs/05-events-registration-email.md: Slack grant, secret-at-reveal/send, and durable delivery rules.
• _docs/specs/06-studio-and-admin-api.md: self API, Members management, capabilities, revision checks, masking, audit, and adapter parity.
• _docs/specs/07-security-privacy-operations.md: private/no-store handling, redaction, approved privacy baseline, rights, erasure, retention, and restore propagation.
• _docs/specs/09-migration-rollout-roadmap.md: MemberProfile expand, reconciliation, projection, activation, rollback, and contract sequence.
• _docs/specs/10-verification-strategy.md: migration, security, browser, Slack, management, privacy, and no-Person-side-effect evidence.
• _docs/specs/open-decisions.md, resolved decision 19: one private account-owned MemberProfile and immediate automated Slack eligibility through the shared secret-stored join URL; no Slack API or manual review queue.

Current gap

Current main preserves accounts.CustomUser and legacy account settings but has no runtime MemberProfile, SlackAccessGrant, profile HTML/self API, Slack reveal route, Members Studio/admin adapters, or member-domain rights propagation. AccountSettingsForm still writes CustomUser directly. Declaring MemberProfile canonical before adapters and compatibility projections exist would create competing writers.

The accepted specification amendment is already merged. It is authority for the children below, not evidence that runtime implementation or the deployed HUMAN Slack check exists.

Child delivery map

The five children were filed through raw intake and are independently groomed under _docs/PROCESS.md. Each child’s current labels, body, accepted artifact dependencies, and role evidence control readiness; parent grooming never makes a child engineer-ready.

1. Accounts MemberProfile foundation — one-to-one schema; exact version-1 fields/choices/validation; stable UUID; completion, confirmation, and revision metadata; owner-safe confirmed-scalar read service; synthetic expand/reconciliation/projection migrations. Backend only.
2. Verified profile onboarding and account-settings cutover — /accounts/profile/, GET/PATCH /api/v1/me/profile, verified-email gate, safe path-only intent/resume, non-blocking incomplete-profile prompt, and migration of account-settings writes to the shared accounts service.
3. Slack grant, reveal, and delivery — atomic eligibility/grant/delivery intent, authenticated secret-safe reveal, invite rotation, Relay delivery lifecycle, and safe outage/quarantine behavior. Hard-blocked on #49.
4. Member management and Slack resend — capability-scoped Studio and /api/v1/admin/ list/detail/correction/resend adapters with masking, revision/idempotency, reason, confirmation, and redacted audit. Final grooming/engineering is downstream of accepted #32/#33 foundations, the Slack child and ordinary #49 manual-resend contract, and the accepted #251 member-domain privacy adapter.
5. Member privacy lifecycle adapter — connect profile, grants, compatibility projections, and queued delivery state to account export/correction/full-erasure, retention, processor propagation, and restore-tombstone workflows owned globally by #64. This child does not recreate the global privacy inventory or generic rights engine.

Current decision gates

The three former foundation choices are no longer open decisions: groomed #247 pins the complete country/region catalog and compatibility projection, UUID/revision/confirmation invariants, and Phase-A/B/C activation-and-rollback exit gate. They remain acceptance requirements of #247; they are not authority to start while #247 prerequisites are open.

The shared masked-member presentation decision is now isolated in #288 for both course and Member management; its recommended UUID-derived grammar is not approval. #250 separately retains the Slack manual-resend interval/inclusive-boundary and management write-registry cost decision. Keep decision and needs grooming on both consumers as documented until the owner responses and artifact dependencies exist.

#64 retains its own HUMAN/legal decisions. Those decisions gate production/protected-data activation, not the separately sealed non-activating source contracts described below. The real Slack secret/deployed link exercise remains the #249/#108 HUMAN gate and is never inferred from synthetic evidence.

Exact delivery DAG and activation boundary

Dependency gates below are artifact-based: an issue that intentionally stays open for HUMAN closure may supply a prerequisite only through a focused slice that has passed independent testing, PM acceptance, merge/push, and green on-call, with exact immutable identity recorded. Groomed prose, a frozen candidate, or an open issue alone supplies no interface.

1. Member foundation lane: accepted #224, #231, #234, and #51 -> #247 -> #248. These course/identity prerequisites may advance independently, but #247 engineering waits for all four exact accepted identities.
2. Ordinary email lane: #49 ordinary durable-delivery/manual-resend work follows its existing template, Relay, job, and management prerequisites. It is independent of #281/#283/#284. Once its exact ordinary delivery symbols and Relay contract are accepted and integrated, #249 may follow after #247 and #248; #249 does not wait for restore recovery merely to create/reveal the Slack grant.
3. Email recovery lane: #264 -> non-activating source-only #284 -> recovery-specific #49 implementation -> #258. #284 supplies no runtime adapter, provider access, send, or restore authority and does not let #258 invent an email state-to-safe mapping.
4. Privacy-interface lane: source-only #254 -> source-only #281. After #281 is accepted, #255, source-only #283, and source-only #285 may proceed in parallel. Then #255 + #283 -> #257, and #255 + #285 -> #256. After accepted #254/#281/#255/#257 plus the email-recovery lane above, PM may re-groom and deliver the execution-disabled #258 foundation. After accepted #254/#281/#255/#256/#257/#258, source-only #282 precedes re-groomed #259.
5. Member privacy adapter: only after accepted #254 and #255-#259 interfaces plus accepted #247/#248/#249 and the applicable #49 symbols may PM re-groom #251. #250 and #32/#33 are not prerequisites for this backend adapter. A bounded #251 slice may use synthetic data and fail-closed production registration; it uses Refs #251 and remains open until operational activation gates pass.
6. Member management lane: #32 and #33, #288, the remaining #250 resend decision, and the member/email lanes may advance independently. Final #250 grooming and engineering wait for accepted #32/#33, #247/#248/#249, the applicable #49 manual-resend contract, and the accepted #251 member-domain privacy adapter. This direction is #251 -> #250; never add the reverse dependency.

Source-only #254/#281/#283/#284/#285/#282 artifacts define and validate contracts only. Execution-disabled #251 or other privacy foundations permit synthetic implementation evidence only. They do not enable a production privacy request, export/correction, retention, erasure, restore, processor action, Slack email, support correction, or resend.

Operational activation remains separately gated by the applicable accepted #254 HUMAN/legal rows, enabled production registrations and adapters in #255-#259, #66 restore/startup enforcement and rehearsal, accepted #49/Relay execution and receipts, #32/#33 management controls, #249 secret/deployed HUMAN evidence, and every owning issue lifecycle. No provider, protected-data, production, secret, or deployment authority is inferred.

Cross-child product and security invariants

• MemberProfile belongs one-to-one to the preserved durable CustomUser; it never creates, mutates, auto-links, or grants authority through content.Person.
• Only the owner or an explicit support capability may read/change profile data. Every profile, Slack, self, Studio, admin, and rights response is private, no-store, noindex, and excluded from sitemap/search/public serializers.
• Version-1 values, choice codes, lengths, trimming, safe URL rules, completion schema/revision, and confirmed-scalar reads are identical through one accounts application service.
• Free text, URLs, email, raw country/header/IP, credentials, tokens, and the Slack URL never enter ordinary logs, metrics, audit text, screenshots, issue evidence, or retained delivery bodies.
• Business mutations occur in owning services; network delivery occurs only after commit through #49's durable lifecycle.
• The Slack join URL exists only in the approved runtime secret channel and is exposed only to an authenticated eligible member or provider submission. Rotation, retry, resend, outage, quarantine, disablement, and erasure fail safely without revoking already-used external Slack membership or claiming that they do.
• Course-owned consumers receive only the accepted confirmed scalar contract. They do not write MemberProfile or infer profile completion from course data.

Parent acceptance criteria

• All five child issues are filed, independently groomed, delivered, tested, PM-accepted, merged, and observed in dependency order.
• #247 preserves and verifies the already-recorded country/catalog, identity/state, and activation/rollback contracts against its accepted prerequisite identities.
• One account-owned MemberProfile service enforces the exact version-1, confirmation, completion, UUID, revision, validation, projection, and owner-safe read contract with zero Person side effects.
• Verified self onboarding and legacy account settings use the same service with safe resume, CSRF/mass-assignment/revision defenses, private responses, accessible errors, and no lockout of existing account/history access.
• Slack eligibility, grant, reveal, delivery, rotation, outage, retry, resend, quarantine, and erasure satisfy the secret-safe durable-delivery contract without duplicate logical work.
• Studio and admin API adapters have capability/queryset parity, masking, revision/idempotency controls, confirmed high-risk actions, bounded searches, and redacted audits.
• #64's privacy workflow covers every new profile/grant/projection/queued-delivery field and state, including full erasure and restored-backup tombstone behavior, without exposing the shared Slack secret.
• Migrations pass forward/reverse/apply-twice, precedence/conflict/alias/quarantine, SQLite and production-like PostgreSQL constraint/concurrency, rollback, and no-sensitive-output checks.
• Focused Django/security/parity/OpenAPI tests and the graph-selected full verification pass for each child; render-owning children pass independent desktop/mobile Playwright and inspected screenshots.
• [HUMAN] An authorized operator configures the real Slack secret through the approved channel; a synthetic deployed verified member completes onboarding and receives/reveals a working link; redacted evidence confirms no secret or member PII leakage.

Parent browser and operational acceptance

Browser-owning children must independently cover desktop about 1440×900 and mobile about 390×844: verified and existing-account profile journeys, accessible error summary/focus/preserved values, safe path-only resume, stale revisions, incomplete prompt, secret unavailable/delayed, Slack eligibility/reveal without capturing the link, denied roles, masked support views, correction/resend confirmation, and private-cache/history behavior. Backend-only foundation work has screenshots not_applicable only when the computed verification graph confirms no render impact.

Operational evidence uses synthetic identities and bounded aggregate counts only. Migration/reconciliation, delivery, audit, export, deletion, and restore evidence must contain no real or reversible member data or secret. Every child supplies its own versioned verification plan and independent tester report under _docs/PROCESS.md.

Explicit non-goals

• No course registration schema, enrollment conversion, immutable course evidence, learner dashboard/calendar/progress, or course management implementation; those belong to #242/#243/#244 and their parent #54.
• No public member directory/page, Person creation/link inference/synchronization, editorial role, social graph, avatar, organization directory, arbitrary links, or ranking/recommendations.
• No replacement login/user model, production-data import, CloudFront trust implementation, Slack API/SCIM/member synchronization, manual Slack review queue, marketing campaign, or synchronous external URL fetch.
• No global privacy inventory/rights engine or generic retention/tombstone implementation in the member adapter; #64 owns those cross-domain mechanisms.
• No removal of legacy compatibility columns or canonical activation before the recorded exit/rollback gate.

Delivery convention

Child commits close their child issue after normal gates. Because the real deployed Slack secret/link criterion remains HUMAN, coordinating commits reference #108 as appropriate, the parent keeps human, and #108 remains open until the final redacted HUMAN acceptance is recorded.

Start with _docs/PROCESS.md and _docs/architecture/app-boundaries.md, then read the listed specification files and the five child issues. This parent is coordination-only, so there is no single entry point or test to run; done means all child issues are independently groomed, implemented, tested, accepted, merged, and observed in dependency order.