AL-2115 — [P28-M06] Offer native signup and let a guest confirm it

Approved implementation ticket. Plan key: P28-M06. Work only after its real blockers and exact qualification gates are satisfied. Publication does not establish implementation, qualification or activation.

Parent

Phase 28 implementation specification #2064. Canonical specification commit e93e2e9958f32380e28ec0e005d7ef3ee24f7e7a; documentation PR #2065. The full published spec and comments were verified against the canonical source. Preserve the parent’s body, title, labels, state and comments; new native child/dependency relationships are metadata only.

What to build

Authorized staff and exact-Page contributors offer a source-ready newsletter invitation; a guest submits Email/optional Name, receives an exact seven-day request and deliberately confirms without a gift or account.

Source of truth and acceptance ownership

• Communications: part 1 · part 2 · part 3 · part 4
• Common safeguards and proof: part 1 · part 2
• Owner reconciliation and later-decision precedence: part 1
• Evidence and existing seam limits: part 1

Primary requirement references: REQ28-M01, REQ28-M02, REQ28-M03, REQ28-M07, REQ28-M09, REQ28-M12. Stories: US28-M01, US28-M02, US28-M03, US28-M07, US28-M09, US28-M12.

The checked criteria below are this ticket’s primary trace ownership, not a relaxation of the full normative contract. For a requirement split across tickets, this ticket delivers its named behavior and enforces applicable invariants immediately; the other ticket’s full scenario is not claimed complete early. All source-specific state/control, numeric-boundary, owner, monitoring and exclusion sections in the linked volume remain binding. Preserve settled D1–D50 and C01–C20; do not reopen them or import contradictory vendor conventions.

Acceptance criteria

• AC28-M01-01 — Given an actor whose only relationship is Page subject, spouse, coauthor or Ministry/Support Assignment, when that actor changes the signup entry without the current exact-Page capability, then the command is denied and no publication candidate or effective entry changes.
• AC28-M01-02 — Given an accepted entry Off and a cached form or older release candidate, when either attempts new intake or publication, then the controlling source fence prevents a new accepted request or reenabled entry, while the existing Page and subscriptions remain unchanged.
• AC28-M01-03 — Given a permitted On save awaiting normal review, when the save succeeds, then the interface distinguishes saved/awaiting review from shown publicly and releases the entry only after current readiness and publication authority pass.
• AC28-M02-01 — Given an unexpired request accepted before Page hide, when organization native signup is disabled, then pending admission and not-yet-admitted confirmation dispatch are blocked without deleting existing membership, stopping unrelated authorized issues or disabling unsubscribe.
• AC28-M02-02 — Given a newly deliberately enabled qualified native capability, when no stricter existing policy applies, then the verified-email option starts On; given missing or invalid policy, then immediate admission is unavailable rather than inferred On.
• AC28-M02-03 — Given organization signup is reenabled or the verified-email shortcut changes, when an old request is reviewed, then its original expiry and revocation history remain binding and no terminally stopped delivery or pending admission restarts automatically.
• AC28-M03-01 — Given a qualified published signup entry and an eligible guest instruction that requires fresh proof, when valid Email and optional Name are submitted without a gift or account, then one pending source occurrence and required confirmation intent commit together and only afterward does the reader receive the generic accepted receipt.
• AC28-M03-02 — Given a fresh-proof instruction fails before its required source-and-intent commit, when the request returns, then no accepted receipt or partial membership is presented and retry uses the same operation rather than duplicating effects.
• AC28-M03-03 — Given a forged Tenant, sender or template field, or an address matching an existing restricted or active record, when public intake is handled, then trusted source routing controls the target and the response reveals no hidden match or restriction.
• AC28-M07-01 — Given a valid confirmation link, when a scanner, preview, GET or HEAD opens it, then membership and proof-use state remain unchanged and the selector-only response exposes no private purpose, address or deadline.
• AC28-M07-02 — Given valid fragment proof and current source authority, when the protected landing protocol and deliberate confirmation action complete, then only the exact frozen newsletter/address may be admitted without login, Auth verification or CRM identity creation.
• AC28-M07-03 — Given a stripped fragment, missing script, retired host, wrong origin or invalid verifier, when the link is used, then proof is not consumed by a weakened fallback and safe nonrevealing help is shown.
• AC28-M09-01 — Given an occurrence accepted at an authoritative instant, when its deadline is established, then it is exactly 168 elapsed hours later and the localized display identifies date, time and timezone without changing the source instant.
• AC28-M09-02 — Given trusted decision time reaches the deadline during a lock wait, when confirmation attempts to commit, then equality or later is expired even if the request started earlier; DST, leap dates and display-zone changes do not change the result.
• AC28-M09-03 — Given resend, provider delay, hide/reopen, disable/reenable or restoration, when the original request is recovered, then its deadline never extends; an expired link may offer fresh Join only through a currently authorized entry and never expires an already confirmed membership.
• AC28-M12-01 — Given guest or verified-email signup, when membership is accepted, then no Party, donor, prospect, household link, canonical-contact overwrite or protected-reader/finance grant is created as a side effect.
• AC28-M12-02 — Given two readers with different private membership states, when the public Page is served through shared caching, then the public representation is audience-invariant and neither private addresses nor receipts enter public cache, URLs or analytics.
• AC28-M12-03 — Given an unqualified address, context switch or signout, when history lookup or a late private response arrives, then address-specific state remains inaccessible and stale client content cannot expose the prior reader or Tenant.
• AC28-M12-04 — Given an account deletion, forged cross-tenant reference or direct browser/privileged mutation, when membership and evidence are accessed or changed, then qualified source identity/history survive the defined deletion policy, forbidden scope/state mutation is rejected, and errors or feeds expose no hidden membership.

Implementation decisions and slice boundaries

• New entries remain Off unless deliberately enabled and source-ready through normal Page publication. Page Off immediately fences cached/direct intake and stale candidates without changing Page reach or existing membership.
• Organization native signup disable blocks new and pending admission/unstarted confirmation dispatch while unsubscribe and independent issue delivery survive. D42 proof-reuse defaults On only for a newly deliberately enabled qualified native capability; preserve stricter policy and fail closed on invalid policy.
• Implement source-owned admission fences and history from the start; pending lifecycle scenarios may use durable owner fixtures until M06 creates live requests. Do not add duration editors or per-Page policy variants.
• Qualify the bounded P17 same-Tenant non-constituent descriptor branch and exact native confirmation producer; never fabricate Party/Auth/workforce identity to satisfy older recipient shape.
• Acceptance atomically fixes source/purpose/destination, original acceptance+168 elapsed hours, evidence, receipt and required P6 delivery intent. Before activation establish finite source-owned pending/proof/evidence retention and bounded abuse profile; do not adopt the abandoned 24-hour purge proposal.
• Use verified Tenant Donor Portal origin, nonsecret selector plus independent 256-bit fragment verifier, deliberate same-origin POST and exact confirm action. GET/HEAD/scanners are inert, selector response nonrevealing, no-script protected doorway preserves proof with useful help; public intake retains its own no-JavaScript route.
• Deadline equality and post-lock-wait expiry reject. Account deletion, supported email comparison, tenant FKs/grants/RLS/privileged paths, recipient non-enumeration and public-cache audience invariance are proved before exposure.
• The first admitted membership must already expose a permitted exact-scope withdrawal/recovery action and enforce withdrawal fences; M09 adds complete current-membership/rejoin/channel-choice behavior, not the first escape from consent.

Binding normative decisions

REQ28-M01 — Control the exact public signup entry

Story US28-M01: As an authorized missionary, I want to show or hide native newsletter signup on my permitted Page, so that I control its public invitation without changing existing subscribers.

Decision basis: D6 selected native signup and exact-Page control; D43 C01–C05/C09; Phase 22/23 placement and release owners.

The following behavior is required.

• Use the current exact-Page contributor/source capability, P22/P23 typed
  placement and existing publication/review workflow. Subject/spouse/coauthor,
  Ministry/Support Assignment or CRM access alone grants no Page mutation.
• New entries are not inferred On from a published Page, Resend connection, old
  Request button or legacy contacts. On needs deliberate choice, current
  readiness and normal release. Show Saved/awaiting review separately from Shown.
• Page-entry Off immediately stops new source intake through that entry,
  including cached forms/direct requests and stale publication candidates. It
  does not publish/unpublish the Page, change reach, remove consent, block
  independently permitted issue sends or replace signup with external Request.
• Display: “Hides signup from this page. Earlier requests can still be confirmed
  before they expire. Existing subscribers are unchanged.”
• Prove both orders of intake/Off, cached form, stale release, wrong Page actor
  and provider outage; no save outcome falsely claims public visibility.

REQ28-M02 — Understand organization signup controls

Story US28-M02: As an authorized organization administrator, I want simple independent signup controls, so that hiding a Page and disabling admissions have predictable effects.

Decision basis: D42 C07; D43 C05/C09; Phase 3/12 source consent and settings authority.

The following behavior is required.

• The source-owned native signup capability can be disabled under existing
  settings/permission owners. Disabled blocks new and pending admissions and
  unstarted confirmation dispatch, while preserving existing subscriptions,
  unsubscribe, giving/Page reach and independently authorized newsletter delivery.
• Reenable permits a still-current unexpired original request to finish; it does
  not renew the clock, revive withdrawn/superseded proof or automatically replay
  a P6 intent already terminally suppressed.
• One organization option, Let signed-in readers use their verified email,
  governs D42. Its Off routes subsequent new/rejoin requests through confirmation;
  it does not change existing membership or automatically activate pending work.
• Default On applies only to newly deliberately enabled and qualified native
  capability. Preserve stricter policy and Page Off; missing/invalid policy is
  not On. No per-Page/provider/project/reader exceptions or duration editor.

REQ28-M03 — Join as a guest

Story US28-M03: As a public reader, I want a short newsletter signup without donating or creating an account, so that I can request that newsletter directly.

Decision basis: D6 selected native public signup; D42 C09; D43 C08; Phase 3/4/6/17 source and proof owners.

The following behavior is required.

• Require Email, allow one optional Name, identify the public-safe newsletter and
  explain purpose/withdrawal. No required gift/login/phone/postal/split legal name,
  prechecked marketing bundle, forced popup or checkout diversion.
• Resolve operational Tenant/Page/newsletter via the qualified published target
  and CMS-to-operational mapping. Posted tenant/actor/template/sender/header
  values are not authority. Optional name cannot overwrite canonical identity.
• For an eligible guest instruction requiring fresh proof, atomically accept
  one pending occurrence, exact scope/destination, original deadline, minimal
  evidence, durable operation outcome and required confirmation delivery intent.
  Only a durably accepted intake outcome permits “Signup received.” An
  active-identical request stays unchanged without unnecessary confirmation;
  restricted/ineligible outcomes remain non-enumerating and cannot claim a
  pending request or queue forbidden confirmation.
• Public receipt does not disclose prior membership, donor/CRM match or a
  restriction. It is not proof of confirmed subscription or message delivery.
• Duplicate HTTP keys cannot create endless mail; unverified intake cannot
  reserve an address indefinitely against its legitimate reader.

REQ28-M07 — Confirm through one protected deliberate action

Story US28-M07: As a reader needing confirmation, I want to confirm the exact newsletter/address without signing in, so that a forwarded/scanned email cannot silently enroll me.

Decision basis: D43 C06/C13; Phase 17 protected-action protocol with the bounded native-newsletter non-constituent descriptor amendment.

The following behavior is required.

• Use P17's verified frozen Tenant Donor Portal origin/path, nonsecret HTTP
  selector and independent 256-bit fragment verifier. Minimal first-party script
  removes the fragment from browser history and deliberate same-origin POST
  establishes the bounded non-authorizing landing session; qualified review then
  exposes the exact Confirm subscription action under current source proof.
• GET/HEAD/prefetch/preview/scanner opening neither subscribes nor consumes proof.
  Selector-only responses reveal no organization/action/recipient/deadline/state.
  No automatic submit or stripped-fragment alternate protocol.
• Apply existing CSP/cache/referrer/cookie/HMAC/origin/CSRF/key-rotation contracts.
  Missing script leaves proof unconsumed with safe help. Retired/reassigned host
  fails safely, not a redirect guessing new authority. Original Page/device is
  unnecessary.
• Confirmation is not Auth email verification/OTP sign-in, CRM claiming, protected
  reading or identity merge. Do not substitute Auth sign-in or verification operations.

REQ28-M09 — Know the seven-day deadline

Story US28-M09: As a reader needing confirmation, I want one unambiguous deadline, so that I know when I must finish and how to start again if it expires.

Decision basis: D44 A and D45 A: one Asym-controlled 168-hour period; D43 C03 strict expiry.

The following behavior is required.

• Set the source deadline to authoritative original acceptance plus 168 elapsed hours, once.
  Require trusted decision time strictly before expiry after lock waits.
  Equality is expired; DST/leap dates/local display zone cannot change validity.
• Render the actual source deadline in the permitted email/review as localized
  date, time and timezone. Generic selector doorway still reveals no deadline.
  No relative-only midnight, countdown or timing configuration.
• Read, resend, retries, provider delay, Page Off/On and organization Off/On never
  extend/pause/reset the clock. Future policy change is prospective; confirmed
  memberships do not expire at their old proof deadline.
• Expired link offers fresh Join only through a currently authorized entry.
  Old link never creates fresh intent automatically. Late delivery is honestly
  expired; no invented replacement validity.

REQ28-M12 — Keep signup private and separate from CRM

Story US28-M12: As a reader, I want signup to reveal no unrelated identity or membership, so that my interest does not become staff prospect data or access to other records.

Decision basis: D42 C04–C06/C12/C13/C17/C20; D6 separate native membership; Phase 3/4/9/10/12 isolation.

The following behavior is required.

• Both proof paths converge on one source authority; provider contacts, imports,
  P25 requests and a negative-only suppression helper never create membership.
• No Party/donor/household/prospect/cultivation/follower/protected-reader/finance
  grant or canonical-contact overwrite follows from Email/Name or confirmation.
• Enforce non-null trusted tenant/purpose/destination identity and tenant-aware
  relationships. Optional account linkage has explicit null/delete behavior and
  is not the membership identity; account deletion does not cascade away required
  history or imply withdrawal of all independent memberships. Use source-owned
  supported email comparison, without invented plus/dot equivalence or a global
  person-by-email key. Consent evidence binds destination/revision, instruction,
  qualified proof reference, policy/disclosure revision and trusted acceptance.
• Browser roles cannot directly mutate positive admission, proof or evidence.
  Every privileged path preserves immutable tenant/actor/purpose, valid states
  and current source rules; no public proof table, subscriber feed or raw
  constraint response reveals private membership.
• Public Page HTML/RSC/CDN remains audience-invariant. Exact email, membership,
  receipts and controls are private request data, excluded from public cache,
  URLs, metadata and analytics; signout/context/host switch fences late responses.
• Address-specific status/manage/recovery requires current same-address proof or
  an exact qualified source capability. A guest receipt exposes only its own
  permitted operation; an authenticated but unqualified address is not history
  access. Error/timing/constraints do not enumerate hidden states.
• Apply bounded abuse controls without indefinite address reservation, mandatory
  inaccessible challenge or unsupported global person-by-email uniqueness.

Testing, migration and operating obligations

Every reached layer belongs to this slice: actual source persistence and upgrade behavior, canonical command/query, permitted UI, and executed proof. Reuse native owners, shared Base UI/base-maia components and the established architecture. No parallel CRM, Tasks, consent, sender, permission or retention engine.

Before affected activation, prove current trusted tenant/actor/subject/role and fine-grained purpose/field authority, effective old-row/new-row RLS and grants, same-tenant relationships, applicable uniqueness/history/delete constraints, and every reached view/RPC/storage/service path. Caller identifiers and metadata are never authority. Source revision and privacy checks precede disclosure and are repeated after ordering waits where required.

Implement semantic idempotency, required source history/receipt and durable secondary intent, truthful partial/unknown/lost-response recovery, context-switch/revocation fencing, temporal boundaries and correction lineage. Preserve each adopted default and exact Off/new-work/accepted-work/reenable behavior. Never infer consent, money, completion or actual interaction from a presentation action.

Test through existing Playwright whole-user journeys as the primary boundary; use canonical API Vitest tests, real PostgreSQL roles and at least two concurrent sessions, qualified Auth and existing provider-contract seams where the browser cannot prove the guarantee. Reuse existing account-frame/session-guard, task-recovery, roster/redaction, operation-handler, dispatch/restriction, field-policy SQL and replay proof patterns while retaining their demo/mock limits. No new test framework and no skipped mandatory fixture may count as a pass.

Use persistent truthful outcomes, clear context and next steps, keyboard/screen-reader/touch/list equivalents, narrow-screen reflow, localization, safe international data and honest interrupted-connection recovery. Inventory and fence reached legacy writers/readers, preserve lawful history and unresolved obligations, and qualify mixed versions, restore, retention and containment before activation. Adopt existing source-specific signals/thresholds/owners/responses and measured cohort budgets; do not invent a numeric SLO or defer correctness to monitoring.

Shared requirements Q01–Q27 apply where relevant to every ticket. R43, F41–F44, M41–M42 and C49 apply to their affected lanes. W05/W06 aggregate composed evidence; they are not permission to defer any slice’s safeguards.

Related source owners (references are not automatically blockers): #1284, #1350, #1382, #886, #897, #903. Current source contract takes precedence over superseded issue wording.

Blocked by

• #897
• #903
• #1284
• #1350

A blocker’s closure is not runtime qualification: verify the exact consumed revision and executed proof. Keep independently qualified capabilities useful while an affected effect is unavailable. Integrate the approved specification into the implementation base; the open documentation PR is not evidence that these features exist.

Related approved slices

Short ticket keys in implementation notes resolve here. Published requirement, acceptance, story, decision and completeness codes retain their original meanings.

• P28-M09 / #2116 — Manage exact membership, withdrawal and deliberate rejoin
• P28-W05 / #2151 — Recover and contain the composed workspace after restore
• P28-W06 / #2152 — Qualify whole journeys and the exact Phase 28 release cohort

The full execution index and primary-acceptance ownership map are published with the Phase 28 release-qualification ticket. Every shared safeguard remains mandatory within its implementing slice.