AL-2064 — Phase 28 Missionary Workspace Depth & Support-Raising CRM specification

Problem Statement

Missionaries and authorized staff need a coherent support-raising workspace that keeps preparation, relationships, actual interactions, commitments, received gifts, follow-up, communications and voluntary coaching understandable and correctly scoped.

Solution

Implement the complete Phase 28 synthesis in the indexed normative package below. It preserves all D1–D50 decisions and C01–C20 completeness requirements, their scoped amendments, tenant controls and the existing Core architecture. The founder authorized /to-spec publication and confirmed testing seams on 2026-10-18. This is one full-phase specification, not a new implementation-ticket graph.

Read the full package in order. The first eight entries contain the complete product contract and evidence; subsequent entries preserve exact traceability, design, acceptance sequence and reproducible source amendments.

Document	Full text
Complete specification	Part 01 · Part 02
Common safeguards and proof	Part 03 · Part 04
Relationships and working context	Part 05 · Part 06 · Part 07 · Part 08
Finance and stewardship	Part 09 · Part 10
Communications and connections	Part 11 · Part 12 · Part 13 · Part 14
Coaching and useful resources	Part 15 · Part 16 · Part 17
Owner reconciliation	Part 18
Evidence and research	Part 19
Decision and acceptance trace	Part 20 · Part 21 · Part 22 · Part 23 · Part 24 · Part 25 · Part 26 · Part 27
OpenSpec proposal	Part 28
OpenSpec design	Part 29
Delivery acceptance checklist	Part 30
Derived OpenSpec requirements	Part 31 · Part 32 · Part 33 · Part 34 · Part 35 · Part 36 · Part 37 · Part 38 · Part 39 · Part 40 · Part 41
Canonical projection renderer	Part 42
Existing-owner amendments	Part 43 · Part 44 · Part 45 · Part 46 · Part 47
Dated evidence source manifest	Part 48 · Part 49 · Part 50 · Part 51 · Part 52
OpenSpec schema	Part 53

User Stories

The complete specification and domain volumes contain 205 numbered user stories, 205 stable requirements and 768 independently observable acceptance criteria. Every story maps to its decision basis and acceptance IDs. All five canonical domain/proof volumes are binding; the short issue overview does not replace them.

Implementation Decisions

Reuse canonical CRM, financial, identity, communication and shared UI owners. Keep signed-in public readers separate from tenant membership and admitted coaches limited to their exact coach role. Preserve immutable posted money, precise purpose-specific effects, source-scoped permission, current Auth proof, temporal rules, disabled-state consequences and same-operation recovery. Existing-owner amendments reconcile prior contradictory clauses; the complete design records the exact boundaries.

Native follow-up, optional coaching/resources/guide, newsletter Join and the remaining complete journeys are in scope. Native newsletter release must identify and qualify the actual P6 prepared-artifact/sealed-submission producer; #897 and #888 do not establish that missing producer. Other exact source qualification gates remain explicit. Settled D48 correction and D49–D50 attribution policy are not reopened.

Testing Decisions

Confirmed: existing Playwright user journeys are the primary acceptance boundary across missionary, authorized staff, coach and public-reader surfaces. Reuse canonical API tests, real PostgreSQL/RLS/concurrency tests and existing provider-contract tests for guarantees the browser cannot prove. No parallel framework. Missing mandatory fixtures, mocked sources or demo Auth cannot count as qualification.

Document checks cover all 50 decisions, all 20 completeness clauses, stable IDs, canonical projections, strict OpenSpec and exact tracker readback. Feature implementation and runtime acceptance remain unperformed by this publication.

Out of Scope

No feature implementation, live activation, hosted-data change, real supporter communication, additional product interview, new CRM/ledger/subscriber master or decomposition into implementation tickets. Optional coaching, guidance and activity logging do not become mandatory. Existing owner duties retain their scope.

Further Notes

Specification version: phase28-spec-2026-10-18-v1. Inspected base: 9cada8f3d8ab59db391d3fd20df77fcadeb09813. ready-for-agent means the specification is ready for coding work under its explicit dependencies; it does not mean every producer is deployed or qualified. All delivery checklist boxes remain unchecked.

The canonical source, derived projection and publication hashes are distinct. Full-text parts retain source identities and are independently read back after posting. Historical grill evidence and the existing glossary are preserved. Existing Phase 27 story/requirement/acceptance identifiers remain intact.

Phase 28 specification · Part 01/53

Complete specification · file part 1

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth.md
Source chunk SHA-256: f509addf32dda0dd8cc5e3f79d683dd8e1979e0e34893a16cf03f1c686e4d89c

Full index · Next part

Phase 28 — Missionary Workspace Depth & Support-Raising CRM

Specification version: phase28-spec-2026-10-18-v1.
Status: Formal synthesis authorized by the founder's /to-spec instruction on October 18, 2026. The founder confirmed the existing Playwright journey, canonical API, real PostgreSQL/RLS/concurrency and existing provider-contract testing seams. This specification establishes intended behavior and implementation acceptance; it does not establish implementation, source qualification or activation.

Problem Statement

A missionary needs one practical place to build and care for a support team inside the sending organization: remember an introduction, prepare an invitation, arrange an appointment, record the actual response, understand promised and received support, follow through and keep supporters informed. The work becomes confusing when the same person is duplicated across personal spreadsheets, organizational CRM records, payment lists, newsletter lists and coaching tools. A task marked Done is not evidence that a donor was contacted; an unpaid scheduled gift is not debt; a donation is not newsletter consent.

Staff must be able to configure a useful workspace without inheriting a particular fundraising methodology or forcing missionaries to report private preparation. Coaches need deliberately shared, limited information rather than general CRM access. Supporters and public readers need clear signup and preference journeys that neither create unwanted accounts nor expose ministry records. These users need trustworthy results during ordinary mistakes, travel, interrupted connectivity, concurrent edits, staff changes and source/provider outages.

The inspected code provides a missionary shell, partner and task views, source API entry points and useful tests. It does not establish the complete Phase 28 contracts. Loaded-row aggregates, legacy missionary/donor ownership, separate task storage, demo-auth tests and unfinished communication/settings screens are implementation evidence to reconcile, not behavior to preserve by default. The permanent solution must reuse Asym's authoritative domains and shared interface, without another CRM, ledger, subscriber master or automation engine.

Solution

Provide one coherent Missionary Workspace within the organization, centered on the current Ministry Assignment or other exactly authorized ministry/project context. The ordinary path is: enter the right context, see useful current work, understand its factual reason, perform an authorized action once and see a truthful result. Required source-backed work functions independently of optional AI, coaching, calendar/email connections, workflow products and starting guidance.

Allow restricted-start prospect preparation and deliberate contact-only sharing. Use the existing Party, referral, relationship, interaction, Task, partnership, Request and Appeal owners. Preserve private notes and planning, meaningful prayer/practical/church partnerships and the distinction between a person and work involving that person. Returning workers deliberately resume eligible retained preparation; departure does not grant successors access.

Present goals, commitments, received gifts, recognition, fulfillment and Field Account information as distinct source-backed measures with explicit currency, period, scope and currentness. Native follow-up uses qualified financial facts, exact purpose evidence and one durable effect identity. Compatible work can be handled together without merging gifts or purpose-specific completion. A confirmed missed installment with continued scheduled giving is informational; ordinary follow-up remains deliberate.

Provide complete native newsletter work through the existing authoring and communication owners: draft, approved media/layouts, permitted audience, test, review, authorize, schedule, send or print, understand outcomes and repair the exact failed work. Public readers deliberately join a named newsletter; eligible signed-in readers may reuse their current verified address. Other readers confirm by email within seven elapsed days. Optional connected-account individual email and deliberate managed calendar copies retain their own source and permission boundaries.

Offer voluntary read-only coaching, optional activity targets and check-ins, exact next-step sharing, an organization-curated resource library, an optional starting guide and approved broad-region discovery. Staff can offer, edit or disable these capabilities through the existing organization settings and permissions. Each switch has explicit effects on new work, accepted work, visibility and re-enablement. No general Off switch silently erases accepted duties, consent history or source records.

Use the existing Base UI/base-maia design system, semantic tokens, shared forms/lists/records and navigation. Keep the default daily experience calm and action-oriented. Reveal advanced scope and history when useful; preserve visible labels, mobile layouts, keyboard access, clear empty/error/disabled states and safe recovery. There is no new mandatory onboarding wizard, course, logging quota, donor-value ranking or parallel task list.

The complete normative package is binding. Short stories do not replace their full requirements and acceptance outcomes.

Volume	Scope
Relationships and working context	Preparation, sharing, corrections, source-owned work, imports, referrals, departure and return
Finance and stewardship	Goals, distinct financial measures, native follow-up, gift reporting, correction policy and campaign attribution
Communications and connections	Native signup/newsletters, personal email, appointments/calendar and author-controlled writing help
Coaching and useful resources	Exact voluntary shares, history/duration, targets/check-ins/next steps, library, guide and regional discovery
Common safeguards and proof	Setup/daily journey, current authorization, durability, accessibility, migration, recovery and release proof
Owner reconciliation	Exact domain extensions, superseded clauses and source qualification boundaries
Evidence and research	Inspected current implementation, tests, official research, tracker state and limits

User Stories

Every numbered story has one stable requirement and independently observable acceptance outcomes. Shared safeguards apply to each reached command, reader and derivative. Story order groups user jobs; it does not imply a sequential implementation dependency or permission to ignore negative cases.

US28-Q01. As a missionary, I want to reach useful native work after my organization admits me, so that I can begin without configuring optional features.
Requirement: REQ28-Q01. Acceptance: AC28-Q01-01, AC28-Q01-02, AC28-Q01-03.
US28-Q02. As a missionary serving more than one ministry, I want to enter the right authorized context, so that I understand whose work I am viewing and changing.
Requirement: REQ28-Q02. Acceptance: AC28-Q02-01, AC28-Q02-02, AC28-Q02-03.
US28-Q03. As a missionary switching contexts, I want my unfinished and accepted work to retain its original meaning, so that nothing is lost, exposed or applied to another ministry.
Requirement: REQ28-Q03. Acceptance: AC28-Q03-01, AC28-Q03-02, AC28-Q03-03.
US28-Q04. As a missionary, I want to move from a useful next action to an accurately recorded outcome, so that I can finish everyday work without duplicate entry or invented facts.
Requirement: REQ28-Q04. Acceptance: AC28-Q04-01, AC28-Q04-02, AC28-Q04-03.
US28-Q05. As a missionary handling follow-up, I want completion to mean exactly what the work requires, so that a checkbox cannot falsely resolve another source's obligation.
Requirement: REQ28-Q05. Acceptance: AC28-Q05-01, AC28-Q05-02, AC28-Q05-03.
US28-Q06. As authorized tenant staff, I want each control to explain what it changes, so that I can configure the workspace without accidentally cancelling work or restoring access.
Requirement: REQ28-Q06. Acceptance: AC28-Q06-01, AC28-Q06-02, AC28-Q06-03.
US28-Q07. As a person with several roles, I want each action to use only my current authorized role and subject, so that private work and privileges do not bleed across surfaces.
Requirement: REQ28-Q07. Acceptance: AC28-Q07-01, AC28-Q07-02, AC28-Q07-03.
US28-Q08. As a person whose information is held by the organization, I want every view and derivative to preserve the same current audience, so that hiding a field does not merely move its disclosure elsewhere.
Requirement: REQ28-Q08. Acceptance: AC28-Q08-01, AC28-Q08-02, AC28-Q08-03.
US28-Q09. As a missionary, I want support information to state what it covers, so that I can plan without mistaking a partial list, forecast or unknown value for confirmed money.
Requirement: REQ28-Q09. Acceptance: AC28-Q09-01, AC28-Q09-02, AC28-Q09-03.
US28-Q10. As a missionary or staff member, I want the same action to have the same meaning on every surface, so that boards, lists and shortcuts cannot create contradictory records.
Requirement: REQ28-Q10. Acceptance: AC28-Q10-01, AC28-Q10-02, AC28-Q10-03.
US28-Q11. As an organization administrator, I want persisted data and every access path to enforce the same boundaries, so that a valid edit cannot become a forbidden record.
Requirement: REQ28-Q11. Acceptance: AC28-Q11-01, AC28-Q11-02, AC28-Q11-03.
US28-Q12. As a user retrying interrupted work, I want my accepted intent to happen once, so that a lost response cannot duplicate follow-up, enrollment or communication.
Requirement: REQ28-Q12. Acceptance: AC28-Q12-01, AC28-Q12-02, AC28-Q12-03.
US28-Q13. As a user editing shared work, I want conflicts and corrections to be handled explicitly, so that an old form cannot overwrite newer facts or bypass a current restriction.
Requirement: REQ28-Q13. Acceptance: AC28-Q13-01, AC28-Q13-02, AC28-Q13-03.
US28-Q14. As a user with an unreliable connection, I want to know what actually succeeded, so that I can recover only missing work without repeating an accepted action.
Requirement: REQ28-Q14. Acceptance: AC28-Q14-01, AC28-Q14-02, AC28-Q14-03.
US28-Q15. As a missionary working across currencies and timezones, I want amounts and deadlines to retain their source meaning, so that display choices cannot change financial facts or access windows.
Requirement: REQ28-Q15. Acceptance: AC28-Q15-01, AC28-Q15-02, AC28-Q15-03.
US28-Q16. As a missionary leaving or returning, I want each kind of work to follow its own access and retention rule, so that private preparation stays private while lawful obligations are not lost.
Requirement: REQ28-Q16. Acceptance: AC28-Q16-01, AC28-Q16-02, AC28-Q16-03.
US28-Q17. As a user on a phone or using assistive technology, I want the complete workflow to remain clear and operable, so that I can finish work without a desktop-only or pointer-only path.
Requirement: REQ28-Q17. Acceptance: AC28-Q17-01, AC28-Q17-02, AC28-Q17-03.
US28-Q18. As a missionary or reader in varied field conditions, I want understandable localized information and honest interrupted-work recovery, so that connectivity or unfamiliar formatting does not cause mistakes.
Requirement: REQ28-Q18. Acceptance: AC28-Q18-01, AC28-Q18-02, AC28-Q18-03.
US28-Q19. As a tenant administrator, I want unavailable capabilities to identify the actual repair path, so that a setting or roadmap label cannot promise work the system cannot perform.
Requirement: REQ28-Q19. Acceptance: AC28-Q19-01, AC28-Q19-02, AC28-Q19-03.
US28-Q20. As staff responsible for existing records, I want migration to preserve lawful history and unfinished work, so that the new workspace does not fabricate facts or lose obligations.
Requirement: REQ28-Q20. Acceptance: AC28-Q20-01, AC28-Q20-02, AC28-Q20-03.
US28-Q21. As an operations owner, I want to enable and contain affected capabilities safely, so that a release problem cannot corrupt accepted work or stop unrelated ministry work.
Requirement: REQ28-Q21. Acceptance: AC28-Q21-01, AC28-Q21-02, AC28-Q21-03.
US28-Q22. As an organization administrator, I want backup recovery to respect later restrictions and completed effects, so that recovery cannot re-expose data or repeat work.
Requirement: REQ28-Q22. Acceptance: AC28-Q22-01, AC28-Q22-02, AC28-Q22-03.
US28-Q23. As an operator resolving a user problem, I want trustworthy source history and useful diagnostics, so that I can recover the accepted outcome without private-data exposure or database repair.
Requirement: REQ28-Q23. Acceptance: AC28-Q23-01, AC28-Q23-02, AC28-Q23-03.
US28-Q24. As a maintainer, I want tests at stable observable boundaries, so that they prove the user's whole job without freezing internal implementation details.
Requirement: REQ28-Q24. Acceptance: AC28-Q24-01, AC28-Q24-02, AC28-Q24-03.
US28-Q25. As a security and source owner, I want proof against the actual authorization and durable-effect paths, so that realistic races and provider failures cannot hide behind mocks.
Requirement: REQ28-Q25. Acceptance: AC28-Q25-01, AC28-Q25-02, AC28-Q25-03, AC28-Q25-04.
US28-Q26. As staff in a growing organization, I want the workspace to remain accurate and responsive as records and concurrency increase, so that a display limit cannot become silent data loss.
Requirement: REQ28-Q26. Acceptance: AC28-Q26-01, AC28-Q26-02, AC28-Q26-03.
US28-Q27. As the product owner, I want complete journeys demonstrated with representative users and traced to their decisions, so that completion means usable, qualified behavior rather than a collection of screens.
Requirement: REQ28-Q27. Acceptance: AC28-Q27-01, AC28-Q27-02, AC28-Q27-03.
US28-R01. As a missionary, I want to enter the correct organization and ministry context, so that my work affects the intended people and records.
Requirement: REQ28-R01. Acceptance: AC28-R01-01, AC28-R01-02, AC28-R01-03, AC28-R01-04.
US28-R02. As a missionary, I want to save early prospect preparation with incomplete knowledge, so that I can prepare without prematurely sharing a person's details.
Requirement: REQ28-R02. Acceptance: AC28-R02-01, AC28-R02-02, AC28-R02-03, AC28-R02-04.
US28-R03. As a missionary, I want safe identity matching and clear unresolved results, so that saving preparation neither duplicates a relationship nor exposes another person's protected record.
Requirement: REQ28-R03. Acceptance: AC28-R03-01, AC28-R03-02, AC28-R03-03.
US28-R04. As a missionary, I want to understand who can see my preparation, so that an ordinary Save never surprises me with wider disclosure.
Requirement: REQ28-R04. Acceptance: AC28-R04-01, AC28-R04-02, AC28-R04-03.
US28-R05. As a missionary, I want to make eligible contact facts available to staff deliberately, so that the organization can use its ordinary CRM without receiving my private preparation.
Requirement: REQ28-R05. Acceptance: AC28-R05-01, AC28-R05-02, AC28-R05-03.
US28-R06. As a missionary, I want to optionally tell selected staff that a contact is available, so that attention is directed without changing access or assigning work.
Requirement: REQ28-R06. Acceptance: AC28-R06-01, AC28-R06-02, AC28-R06-03, AC28-R06-04.
US28-R07. As a missionary, I want accepted sharing and later corrections to have clear history, so that recovery does not promise an impossible unshare or recall.
Requirement: REQ28-R07. Acceptance: AC28-R07-01, AC28-R07-02, AC28-R07-03.
US28-R08. As an authorized tenant administrator, I want to control missionary contact correction through existing permissions, so that our organization can enable or withhold eligible edits without another permission system.
Requirement: REQ28-R08. Acceptance: AC28-R08-01, AC28-R08-02, AC28-R08-03.
US28-R09. As a missionary, I want to correct only eligible shared contact fields, so that I can keep useful information accurate without overwriting other facts.
Requirement: REQ28-R09. Acceptance: AC28-R09-01, AC28-R09-02, AC28-R09-03, AC28-R09-04.
US28-R10. As a missionary, I want contact changes and interrupted editing to respect each field's actual rules, so that an address correction does not become a consent or account change.
Requirement: REQ28-R10. Acceptance: AC28-R10-01, AC28-R10-02, AC28-R10-03.
US28-R11. As a missionary, I want to archive unused still-unshared preparation, so that my active prospect list stays useful without deleting the person or independent work.
Requirement: REQ28-R11. Acceptance: AC28-R11-01, AC28-R11-02, AC28-R11-03.
US28-R12. As a missionary, I want to return eligible archived preparation to active work, so that setting something aside is reversible while current rules permit.
Requirement: REQ28-R12. Acceptance: AC28-R12-01, AC28-R12-02, AC28-R12-03.
US28-R13. As a missionary or responsible staff member, I want departure to end the right access without exposing private work, so that genuine organizational duties continue honestly.
Requirement: REQ28-R13. Acceptance: AC28-R13-01, AC28-R13-02, AC28-R13-03.
US28-R14. As an authorized tenant administrator, I want one finite post-departure preparation period, so that return needs are balanced with the organization's qualified privacy rules.
Requirement: REQ28-R14. Acceptance: AC28-R14-01, AC28-R14-02, AC28-R14-03, AC28-R14-04.
US28-R15. As a returning missionary, I want the original departure deadline applied accurately, so that delayed events and policy edits cannot arbitrarily preserve or erase my preparation.
Requirement: REQ28-R15. Acceptance: AC28-R15-01, AC28-R15-02, AC28-R15-03, AC28-R15-04, AC28-R15-05.
US28-R16. As a returning missionary, I want to find my eligible earlier preparation when permitted, so that I can decide what is useful without automatically restoring all old work.
Requirement: REQ28-R16. Acceptance: AC28-R16-01, AC28-R16-02, AC28-R16-03.
US28-R17. As a returning missionary, I want to resume selected preparation deliberately, so that only useful retained work becomes current work again.
Requirement: REQ28-R17. Acceptance: AC28-R17-01, AC28-R17-02, AC28-R17-03, AC28-R17-04.
US28-R18. As a missionary and records operator, I want expiry, holds and disposal to be distinct, so that retained evidence does not become renewed ordinary access.
Requirement: REQ28-R18. Acceptance: AC28-R18-01, AC28-R18-02, AC28-R18-03, AC28-R18-04.
US28-R19. As a permitted missionary, I want to import a supported contact file into restricted preparation, so that I can start work without manually recreating every eligible contact assertion.
Requirement: REQ28-R19. Acceptance: AC28-R19-01, AC28-R19-02, AC28-R19-03.
US28-R20. As a missionary, I want a trustworthy mapping preview, so that only the displayed eligible data is accepted.
Requirement: REQ28-R20. Acceptance: AC28-R20-01, AC28-R20-02, AC28-R20-03, AC28-R20-04.
US28-R21. As a missionary, I want repeated intake to recognize prior accepted work safely, so that recovery does not duplicate contacts or overwrite native corrections.
Requirement: REQ28-R21. Acceptance: AC28-R21-01, AC28-R21-02, AC28-R21-03, AC28-R21-04.
US28-R22. As a missionary, I want imported contact restrictions handled accurately, so that a file cannot silently make a person contactable.
Requirement: REQ28-R22. Acceptance: AC28-R22-01, AC28-R22-02, AC28-R22-03.
US28-R23. As a missionary, I want truthful per-row results and resumable progress, so that weak connections and partial failures do not force me to repeat accepted work.
Requirement: REQ28-R23. Acceptance: AC28-R23-01, AC28-R23-02, AC28-R23-03, AC28-R23-04.
US28-R24. As a missionary, I want to cancel or discard an import with clear consequences, so that stopping it does not erase already accepted contacts.
Requirement: REQ28-R24. Acceptance: AC28-R24-01, AC28-R24-02, AC28-R24-03, AC28-R24-04.
US28-R25. As a missionary, I want supported file limits and format problems explained before acceptance, so that the importer is predictable and does not execute spreadsheet content.
Requirement: REQ28-R25. Acceptance: AC28-R25-01, AC28-R25-02, AC28-R25-03, AC28-R25-04, AC28-R25-05.
US28-R26. As a missionary and records operator, I want private import custody with a clear working deadline, so that files and errors do not become an indefinite second contact database.
Requirement: REQ28-R26. Acceptance: AC28-R26-01, AC28-R26-02, AC28-R26-03, AC28-R26-04.
US28-R27. As a missionary, I want to record when a referral was actually given to me, so that late entry does not pretend I received a fresh introduction today.
Requirement: REQ28-R27. Acceptance: AC28-R27-01, AC28-R27-02, AC28-R27-03, AC28-R27-04.
US28-R28. As a missionary, I want the new referral's last follow-up day shown clearly, so that I know the real window without selecting another date.
Requirement: REQ28-R28. Acceptance: AC28-R28-01, AC28-R28-02, AC28-R28-03, AC28-R28-04.
US28-R29. As a missionary, I want a late or incomplete referral recorded honestly, so that useful history is not rejected or silently renewed.
Requirement: REQ28-R29. Acceptance: AC28-R29-01, AC28-R29-02, AC28-R29-03, AC28-R29-04.
US28-R30. As authorized tenant staff, I want independent New and Continued referral periods in one place, so that our organization can configure its work without asking missionaries to administer dates.
Requirement: REQ28-R30. Acceptance: AC28-R30-01, AC28-R30-02, AC28-R30-03, AC28-R30-04.
US28-R31. As a missionary, I want limited expired-referral history in my ordinary referral view, so that I recognize earlier work without assuming I may still access its private details.
Requirement: REQ28-R31. Acceptance: AC28-R31-01, AC28-R31-02, AC28-R31-03, AC28-R31-04.
US28-R32. As a missionary, I want expired history to remain read-only and purpose-limited, so that opening an old referral does not renew it or erase independent access.
Requirement: REQ28-R32. Acceptance: AC28-R32-01, AC28-R32-02, AC28-R32-03, AC28-R32-04.
US28-R33. As authorized tenant staff, I want one control for missionary continuation, so that self-service is optional without interrupting authorized staff work.
Requirement: REQ28-R33. Acceptance: AC28-R33-01, AC28-R33-02, AC28-R33-03, AC28-R33-04.
US28-R34. As an authorized missionary or staff member, I want to continue one eligible expired referral in one action, so that current work resumes on the same truthful lineage.
Requirement: REQ28-R34. Acceptance: AC28-R34-01, AC28-R34-02, AC28-R34-03, AC28-R34-04.
US28-R35. As a missionary, I want safe recovery of a continuation outcome, so that retrying cannot open a second window or conceal a later expiry.
Requirement: REQ28-R35. Acceptance: AC28-R35-01, AC28-R35-02, AC28-R35-03, AC28-R35-04.
US28-R36. As an independently authorized source corrector, I want to repair a mistaken referral date or expiry with evidence, so that correction restores truth without counterfeit renewal.
Requirement: REQ28-R36. Acceptance: AC28-R36-01, AC28-R36-02, AC28-R36-03, AC28-R36-04.
US28-R37. As a missionary, I want referrals to remain distinct from contact permission and other work, so that expiry or continuation never creates an unintended ministry action.
Requirement: REQ28-R37. Acceptance: AC28-R37-01, AC28-R37-02, AC28-R37-03, AC28-R37-04.
US28-R38. As authorized tenant staff, I want to author one optional starting guide, so that our organization can offer useful suggestions without maintaining a course platform.
Requirement: REQ28-R38. Acceptance: AC28-R38-01, AC28-R38-02, AC28-R38-03, AC28-R38-04.
US28-R39. As a missionary, I want to use, skip and revisit the guide freely, so that suggestions help my work without measuring or controlling it.
Requirement: REQ28-R39. Acceptance: AC28-R39-01, AC28-R39-02, AC28-R39-03, AC28-R39-04.
US28-R40. As authorized tenant staff, I want to disable and later re-offer the guide deliberately, so that changes do not affect independent resources or secretly undo my choice.
Requirement: REQ28-R40. Acceptance: AC28-R40-01, AC28-R40-02, AC28-R40-03, AC28-R40-04.
US28-R41. As a missionary and tenant administrator, I want contact work to remain native in this release, so that useful ordinary work does not depend on another fundraising product.
Requirement: REQ28-R41. Acceptance: AC28-R41-01, AC28-R41-02, AC28-R41-03, AC28-R41-04.
US28-R42. As a missionary, I want a connected but truthful daily journey, so that I can progress from preparation or referral to ordinary work without entering the same fact twice.
Requirement: REQ28-R42. Acceptance: AC28-R42-01, AC28-R42-02, AC28-R42-03, AC28-R42-04.
US28-R43. As an accountable source operator, I want bounded diagnostics and explicit containment triggers, so that privacy, integrity and usability failures are repaired without duplicate work or direct data alteration.
Requirement: REQ28-R43. Acceptance: AC28-R43-01, AC28-R43-02, AC28-R43-03, AC28-R43-04.
US28-F01. As a missionary, I want to understand my permitted support information without confusing money, commitments or relationships, so that I can decide what to do confidently.
Requirement: REQ28-F01. Acceptance: AC28-F01-01, AC28-F01-02, AC28-F01-03.
US28-F02. As a missionary, I want continuing financial and nonfinancial relationships to stay available while independently authorized, so that an older gift does not make a person disappear from my work.
Requirement: REQ28-F02. Acceptance: AC28-F02-01, AC28-F02-02, AC28-F02-03.
US28-F03. As a missionary, I want financial information to reflect my actual authorized scope, so that a shared donor or designation never exposes another ministry's information.
Requirement: REQ28-F03. Acceptance: AC28-F03-01, AC28-F03-02, AC28-F03-03.
US28-F04. As a missionary, I want unavailable financial conclusions to be explained without blocking unrelated work, so that I can continue safely.
Requirement: REQ28-F04. Acceptance: AC28-F04-01, AC28-F04-02, AC28-F04-03.
US28-F05. As authorized staff, I want to choose who manages a support goal, so that the organization can delegate editing without changing finance or publication permissions.
Requirement: REQ28-F05. Acceptance: AC28-F05-01, AC28-F05-02, AC28-F05-03.
US28-F06. As an authorized goal editor, I want a clear goal and its history, so that changes are meaningful and do not create competing targets.
Requirement: REQ28-F06. Acceptance: AC28-F06-01, AC28-F06-02, AC28-F06-03.
US28-F07. As an authorized goal editor, I want a single reliable Save and understandable recovery, so that a slow connection cannot overwrite someone else's change or create duplicate history.
Requirement: REQ28-F07. Acceptance: AC28-F07-01, AC28-F07-02, AC28-F07-03.
US28-F08. As a missionary, I want support progress with clear meaning, so that I can distinguish what is planned, committed and received.
Requirement: REQ28-F08. Acceptance: AC28-F08-01, AC28-F08-02, AC28-F08-03.
US28-F09. As an authorized goal editor, I want to copy a compatible approved Support Plan amount when helpful, so that I do not retype it or create a second planning process.
Requirement: REQ28-F09. Acceptance: AC28-F09-01, AC28-F09-02.
US28-F10. As a missionary, I want to know where my goal appears, so that an internal edit does not unexpectedly publish private planning information.
Requirement: REQ28-F10. Acceptance: AC28-F10-01, AC28-F10-02, AC28-F10-03.
US28-F11. As a missionary, I want a first-support follow-up when someone first gives qualifying recorded support to my ministry, so that I can respond without treating their support elsewhere as disqualifying.
Requirement: REQ28-F11. Acceptance: AC28-F11-01, AC28-F11-02, AC28-F11-03.
US28-F12. As a missionary, I want first-support work to survive retries and truthful corrections without repeating completed work, so that my queue is reliable.
Requirement: REQ28-F12. Acceptance: AC28-F12-01, AC28-F12-02, AC28-F12-03.
US28-F13. As a missionary, I want to finish or decline personal follow-up without filing a report, so that simple stewardship remains simple.
Requirement: REQ28-F13. Acceptance: AC28-F13-01, AC28-F13-02, AC28-F13-03.
US28-F14. As a missionary, I want each special-gift follow-up to explain why it exists, so that I can act without guessing what an algorithm inferred.
Requirement: REQ28-F14. Acceptance: AC28-F14-01, AC28-F14-02.
US28-F15. As a missionary, I want compatible special gifts from one supporter together, so that I can handle them once without losing their evidence.
Requirement: REQ28-F15. Acceptance: AC28-F15-01, AC28-F15-02, AC28-F15-03.
US28-F16. As a missionary, I want Done to cover exactly the gifts I reviewed, so that a new arrival or hidden item is never silently handled.
Requirement: REQ28-F16. Acceptance: AC28-F16-01, AC28-F16-02, AC28-F16-03.
US28-F17. As a missionary, I want corrected financial reasons and mistaken task dispositions handled clearly, so that valid remaining work is not lost or duplicated.
Requirement: REQ28-F17. Acceptance: AC28-F17-01, AC28-F17-02, AC28-F17-03.
US28-F18. As an authorized missionary or staff member, I want to record an explicit additional-support instruction in one action, so that an eligible received gift produces understandable follow-up.
Requirement: REQ28-F18. Acceptance: AC28-F18-01, AC28-F18-02, AC28-F18-03.
US28-F19. As an authorized purpose recorder, I want partial-gift instructions represented honestly, so that a purpose does not accidentally apply to the whole gift.
Requirement: REQ28-F19. Acceptance: AC28-F19-01, AC28-F19-02.
US28-F20. As authorized staff, I want to offer follow-up for gifts to a specific one-time need, so that the organization can support that workflow only when useful.
Requirement: REQ28-F20. Acceptance: AC28-F20-01, AC28-F20-02, AC28-F20-03.
US28-F21. As authorized staff, I want turning one-time-need follow-up Off to have a predictable effect, so that settings do not erase accepted work or replay old gifts.
Requirement: REQ28-F21. Acceptance: AC28-F21-01, AC28-F21-02, AC28-F21-03.
US28-F22. As authorized staff, I want a simple optional amount rule, so that gifts meeting the organization's threshold can receive follow-up without guessing from previous giving.
Requirement: REQ28-F22. Acceptance: AC28-F22-01, AC28-F22-02, AC28-F22-03.
US28-F23. As a missionary, I want amount-based work to retain the rule that actually admitted it, so that later settings changes do not rewrite my queue or create historical work.
Requirement: REQ28-F23. Acceptance: AC28-F23-01, AC28-F23-02, AC28-F23-03.
US28-F24. As a missionary, I want confirmed support above a commitment to have a factual reason, so that even a small real excess is handled consistently.
Requirement: REQ28-F24. Acceptance: AC28-F24-01, AC28-F24-02, AC28-F24-03.
US28-F25. As a finance source owner, I want excess certificates to conserve real support across ordered gifts and corrections, so that personal follow-up never rests on a duplicated or retroactively invented amount.
Requirement: REQ28-F25. Acceptance: AC28-F25-01, AC28-F25-02, AC28-F25-03.
US28-F26. As a missionary, I want a fulfilled-commitment purpose to represent the actual completion of the promise, so that I do not congratulate a supporter for a partial installment or administrative release.
Requirement: REQ28-F26. Acceptance: AC28-F26-01, AC28-F26-02, AC28-F26-03.
US28-F27. As authorized staff, I want one organization setting for combining compatible follow-ups, so that missionaries can handle related purposes together without losing either obligation.
Requirement: REQ28-F27. Acceptance: AC28-F27-01, AC28-F27-02, AC28-F27-03.
US28-F28. As a missionary, I want one combined action to have precise results even when policies or gifts change, so that I can trust what remains.
Requirement: REQ28-F28. Acceptance: AC28-F28-01, AC28-F28-02, AC28-F28-03.
US28-F29. As authorized staff, I want to enable missionary reports of actual offline gifts only when appropriate, so that ordinary finance intake stays simple for organizations that do not need this doorway.
Requirement: REQ28-F29. Acceptance: AC28-F29-01, AC28-F29-02, AC28-F29-03.
US28-F30. As an authorized missionary, I want a short form for a gift I actually received, so that I can hand known facts to finance without guessing.
Requirement: REQ28-F30. Acceptance: AC28-F30-01, AC28-F30-02, AC28-F30-03.
US28-F31. As finance staff, I want to continue the same reported item, so that Maya does not re-enter it and recording money does not hide unfinished physical handling.
Requirement: REQ28-F31. Acceptance: AC28-F31-01, AC28-F31-02, AC28-F31-03.
US28-F32. As a missionary, I want clear report status and safe recovery, so that a disabled setting or interrupted connection does not lose an accepted handoff or create it twice.
Requirement: REQ28-F32. Acceptance: AC28-F32-01, AC28-F32-02, AC28-F32-03.
US28-F33. As a missionary, I want to see a confirmed missed gift and the next scheduled gift, so that I can understand the situation and choose whether personal follow-up would help.
Requirement: REQ28-F33. Acceptance: AC28-F33-01, AC28-F33-02, AC28-F33-03.
US28-F34. As authorized staff, I want to control new informational missed-gift notices, so that attention fits the organization without suppressing financial facts.
Requirement: REQ28-F34. Acceptance: AC28-F34-01, AC28-F34-02, AC28-F34-03.
US28-F35. As authorized finance staff, I want posted-gift corrections to use the organization's approval policy, so that a small team can work simply while stronger required controls remain intact.
Requirement: REQ28-F35. Acceptance: AC28-F35-01, AC28-F35-02, AC28-F35-03.
US28-F36. As finance staff, I want a reviewed correction to respect current policy and exact source facts when applied, so that waiting or retrying cannot bypass a changed rule or alter the wrong gift.
Requirement: REQ28-F36. Acceptance: AC28-F36-01, AC28-F36-02, AC28-F36-03.
US28-F37. As finance staff, I want source-code campaign changes to affect future attribution without rewriting earlier gifts, so that campaign reporting remains explainable.
Requirement: REQ28-F37. Acceptance: AC28-F37-01, AC28-F37-02, AC28-F37-03.
US28-F38. As authorized finance staff, I want to correct a gift's campaign without falsifying its source code, so that a real attribution mistake can be repaired permanently.
Requirement: REQ28-F38. Acceptance: AC28-F38-01, AC28-F38-02, AC28-F38-03.
US28-F39. As finance staff, I want recurring installments to retain their accepted origin and independently recorded gifts to retain theirs, so that matching fulfillment never rewrites why a gift was given.
Requirement: REQ28-F39. Acceptance: AC28-F39-01, AC28-F39-02, AC28-F39-03.
US28-F40. As finance staff, I want campaign and subtree totals with a clear time basis, so that structural changes are useful without rewriting closed history or double-counting gifts.
Requirement: REQ28-F40. Acceptance: AC28-F40-01, AC28-F40-02, AC28-F40-03.
US28-F41. As a tenant administrator, I want every source and alternate entry path to enforce the same scope and authority, so that a permitted update cannot turn a safe record into an unauthorized one.
Requirement: REQ28-F41. Acceptance: AC28-F41-01, AC28-F41-02, AC28-F41-03.
US28-F42. As a missionary or staff operator, I want accepted actions to remain recoverable after a failure, so that fixing the display never repeats money or personal work.
Requirement: REQ28-F42. Acceptance: AC28-F42-01, AC28-F42-02, AC28-F42-03.
US28-F43. As a missionary using a phone or assistive technology, I want compact understandable support actions and statuses, so that I can work reliably with limited attention or connectivity.
Requirement: REQ28-F43. Acceptance: AC28-F43-01, AC28-F43-02, AC28-F43-03.
US28-F44. As an operations owner, I want explicit activation evidence and bounded recovery, so that incomplete legacy behavior cannot masquerade as a reliable financial workspace.
Requirement: REQ28-F44. Acceptance: AC28-F44-01, AC28-F44-02, AC28-F44-03.
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.
Requirement: REQ28-M01. Acceptance: AC28-M01-01, AC28-M01-02, AC28-M01-03.
US28-M02. As an authorized organization administrator, I want simple independent signup controls, so that hiding a Page and disabling admissions have predictable effects.
Requirement: REQ28-M02. Acceptance: AC28-M02-01, AC28-M02-02, AC28-M02-03.
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.
Requirement: REQ28-M03. Acceptance: AC28-M03-01, AC28-M03-02, AC28-M03-03.
US28-M04. As a signed-in reader, I want one deliberate Join using my displayed verified account email, so that I need not repeat an already qualified mailbox proof.
Requirement: REQ28-M04. Acceptance: AC28-M04-01, AC28-M04-02, AC28-M04-03.
US28-M05. As a reader, I want an honest fallback when my account proof is unsuitable, so that I can still join without accidentally changing my account.
Requirement: REQ28-M05. Acceptance: AC28-M05-01, AC28-M05-02, AC28-M05-03.
US28-M06. As a reader, I want an identical active signup to stay unchanged and a deliberate rejoin to be simple, so that repeated actions do not duplicate or revive consent.
Requirement: REQ28-M06. Acceptance: AC28-M06-01, AC28-M06-02, AC28-M06-03.
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.
Requirement: REQ28-M07. Acceptance: AC28-M07-01, AC28-M07-02, AC28-M07-03.
US28-M08. As a reader whose signup was durably accepted, I want to finish even after the Page invitation is hidden, so that normal Page maintenance does not cancel my request.
Requirement: REQ28-M08. Acceptance: AC28-M08-01, AC28-M08-02, AC28-M08-03.
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.
Requirement: REQ28-M09. Acceptance: AC28-M09-01, AC28-M09-02, AC28-M09-03.
US28-M10. As a reader, I want interrupted confirmation and permitted resends to recover my accepted request, so that poor connectivity does not create duplicate effects.
Requirement: REQ28-M10. Acceptance: AC28-M10-01, AC28-M10-02, AC28-M10-03.
US28-M11. As a subscriber, I want an accessible exact-newsletter unsubscribe path, so that withdrawal is effective without navigating account or staff workflows.
Requirement: REQ28-M11. Acceptance: AC28-M11-01, AC28-M11-02, AC28-M11-03.
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.
Requirement: REQ28-M12. Acceptance: AC28-M12-01, AC28-M12-02, AC28-M12-03, AC28-M12-04.
US28-M13. As a missionary, I want one integrated Draft → Review → Send/Schedule journey, so that native newsletters work without another app or a staff admin role.
Requirement: REQ28-M13. Acceptance: AC28-M13-01, AC28-M13-02, AC28-M13-03.
US28-M14. As an author, I want to reuse approved stories, images and video appropriately, so that newsletters require less duplicate work without widening disclosure.
Requirement: REQ28-M14. Acceptance: AC28-M14-01, AC28-M14-02, AC28-M14-03.

Phase 28 specification · Part 02/53

Complete specification · file part 2

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth.md
Source chunk SHA-256: da07457dd417854be159329f6ac563881be58e18c4ea78961d6673b669a6935e

Previous part · Full index · Next part

US28-M15. As a missionary, I want understandable recipients and exclusions, so that I know who this issue may reach without seeing forbidden identities.
Requirement: REQ28-M15. Acceptance: AC28-M15-01, AC28-M15-02, AC28-M15-03.
US28-M16. As an author, I want accurate desktop/mobile preview and optional real tests, so that I can assess presentation without sending the issue accidentally.
Requirement: REQ28-M16. Acceptance: AC28-M16-01, AC28-M16-02, AC28-M16-03.
US28-M17. As an authorized missionary, I want deliberate control over each issue's send, so that saving, publishing, signup or assistance never sends on my behalf.
Requirement: REQ28-M17. Acceptance: AC28-M17-01, AC28-M17-02, AC28-M17-03.
US28-M18. As an author, I want precise send/stop/recovery results, so that I do not repeat mail because a provider response was late or incomplete.
Requirement: REQ28-M18. Acceptance: AC28-M18-01, AC28-M18-02, AC28-M18-03.
US28-M19. As a recipient, I want each communication preference to mean what it says, so that joining or leaving a newsletter does not change unrelated reading/mail.
Requirement: REQ28-M19. Acceptance: AC28-M19-01, AC28-M19-02, AC28-M19-03.
US28-M20. As a newsletter reader, I want a clear, working reply path, so that I can respond without being granted unrelated access or exposing a private worker address.
Requirement: REQ28-M20. Acceptance: AC28-M20-01, AC28-M20-02, AC28-M20-03.
US28-M21. As a missionary, I want accurate print renditions, recipient lists and labels, so that supporters choosing physical mail can receive the same authored issue.
Requirement: REQ28-M21. Acceptance: AC28-M21-01, AC28-M21-02, AC28-M21-03.
US28-M22. As a missionary, I want to schedule/reschedule/cancel an eligible appointment in Asym, so that daily work remains usable without a connected calendar.
Requirement: REQ28-M22. Acceptance: AC28-M22-01, AC28-M22-02, AC28-M22-03.
US28-M23. As a missionary, I want to add one chosen appointment to my exact connected calendar, so that it appears where I plan without exporting my supporter data.
Requirement: REQ28-M23. Acceptance: AC28-M23-01, AC28-M23-02, AC28-M23-03.
US28-M24. As a missionary, I want reschedules and cancellations to update my selected calendar copy, so that Asym remains the appointment authority.
Requirement: REQ28-M24. Acceptance: AC28-M24-01, AC28-M24-02, AC28-M24-03.
US28-M25. As a missionary, I want recovery to find my existing copy, so that reconnecting or retrying does not create a duplicate appointment.
Requirement: REQ28-M25. Acceptance: AC28-M25-01, AC28-M25-02, AC28-M25-03.
US28-M26. As a missionary, I want predictable exit choices, so that stopping updates does not accidentally cancel an appointment or claim remote deletion.
Requirement: REQ28-M26. Acceptance: AC28-M26-01, AC28-M26-02, AC28-M26-03.
US28-M27. As a missionary, I want to connect my own supported sender when permitted, so that I can send an individual follow-up without leaving Asym.
Requirement: REQ28-M27. Acceptance: AC28-M27-01, AC28-M27-02, AC28-M27-03.
US28-M28. As a missionary, I want a private useful draft for one eligible contact, so that I can send a follow-up without publishing private correspondence to staff.
Requirement: REQ28-M28. Acceptance: AC28-M28-01, AC28-M28-02, AC28-M28-03, AC28-M28-04.
US28-M29. As a missionary, I want one Send to authorize exactly my reviewed message, so that double clicks or stale tabs cannot send different or duplicate content.
Requirement: REQ28-M29. Acceptance: AC28-M29-01, AC28-M29-02, AC28-M29-03.
US28-M30. As a sender, I want honest outcomes and useful next actions, so that I do not send twice because Asym lost a provider response.
Requirement: REQ28-M30. Acceptance: AC28-M30-01, AC28-M30-02, AC28-M30-03.
US28-M31. As a missionary, I want my sending fact recorded without a second manual entry, so that private message content does not become CRM or coach material.
Requirement: REQ28-M31. Acceptance: AC28-M31-01, AC28-M31-02, AC28-M31-03.
US28-M32. As a connected user, I want to distinguish stopping Asym mail from removing provider permissions, so that I understand effects on my calendar connection.
Requirement: REQ28-M32. Acceptance: AC28-M32-01, AC28-M32-02, AC28-M32-03.
US28-M33. As an authorized organization administrator, I want optional newsletter writing help with my provider and finite allowance, so that its data and cost are controlled.
Requirement: REQ28-M33. Acceptance: AC28-M33-01, AC28-M33-02, AC28-M33-03.
US28-M34. As a missionary, I want manual newsletter work complete and a personal Off choice, so that AI is useful without being mandatory or monitoring my writing.
Requirement: REQ28-M34. Acceptance: AC28-M34-01, AC28-M34-02, AC28-M34-03.
US28-M35. As an author, I want spelling/grammar, rephrase, simplify, shorten, lengthen or make-more-compelling help on my selected prose, so that the result remains mine.
Requirement: REQ28-M35. Acceptance: AC28-M35-01, AC28-M35-02, AC28-M35-03, AC28-M35-04.
US28-M36. As an author, I want the helper to leave links, personalization and required newsletter structure intact, so that rewriting cannot alter destinations or consent.
Requirement: REQ28-M36. Acceptance: AC28-M36-01, AC28-M36-02, AC28-M36-03.
US28-M37. As an author, I want original and complete proposed wording side by side, so that I decide whether the change preserves my facts, voice and meaning.
Requirement: REQ28-M37. Acceptance: AC28-M37-01, AC28-M37-02, AC28-M37-03.
US28-M38. As an administrator, I want conservative atomic usage admission, so that concurrent requests cannot exceed the finite certified allowance unnoticed.
Requirement: REQ28-M38. Acceptance: AC28-M38-01, AC28-M38-02, AC28-M38-03.
US28-M39. As an author, I want truthful failure/cancel/retry states, so that an uncertain model response neither charges twice silently nor replaces newer work.
Requirement: REQ28-M39. Acceptance: AC28-M39-01, AC28-M39-02, AC28-M39-03.
US28-M40. As an author, I want generated suggestions accessible only for their editing purpose, so that discarded drafts do not become an AI archive.
Requirement: REQ28-M40. Acceptance: AC28-M40-01, AC28-M40-02, AC28-M40-03.
US28-M41. As a missionary or reader using a phone, keyboard or assistive technology, I want one clear current state and next action, so that network or permission problems do not cause accidental disclosure or repeated effects.
Requirement: REQ28-M41. Acceptance: AC28-M41-01, AC28-M41-02, AC28-M41-03.
US28-M42. As an operator, I want source-owned safe diagnosis and migration, so that repairing connections or restoring a database cannot send old work or expose private bodies.
Requirement: REQ28-M42. Acceptance: AC28-M42-01, AC28-M42-02, AC28-M42-03, AC28-M42-04.
US28-C01. As an invited coach, I want to use my own account in the correct organization, so that I can prepare without sharing a missionary's credentials or receiving unrelated privileges.
Requirement: REQ28-C01. Acceptance: AC28-C01-01, AC28-C01-02, AC28-C01-03, AC28-C01-04, AC28-C01-05.
US28-C02. As a missionary authorized to share, I want to invite a specific eligible coach, so that coaching starts with a clear recipient and scope.
Requirement: REQ28-C02. Acceptance: AC28-C02-01, AC28-C02-02, AC28-C02-03, AC28-C02-04, AC28-C02-05, AC28-C02-06.
US28-C03. As an intended coach, I want a clear acceptance and recovery journey, so that I can tell whether my invitation and access are actually ready.
Requirement: REQ28-C03. Acceptance: AC28-C03-01, AC28-C03-02, AC28-C03-03, AC28-C03-04, AC28-C03-05.
US28-C04. As authorized organization staff, I want coaching controls to state their exact effect, so that I can permit or stop a capability without accidentally changing unrelated access.
Requirement: REQ28-C04. Acceptance: AC28-C04-01, AC28-C04-02, AC28-C04-03, AC28-C04-04, AC28-C04-05.
US28-C05. As a coach, I want a useful portfolio of the people and Ministry Projects shared with me, so that I can prepare for each conversation without searching unrelated records.
Requirement: REQ28-C05. Acceptance: AC28-C05-01, AC28-C05-02, AC28-C05-03, AC28-C05-04, AC28-C05-05, AC28-C05-06.
US28-C06. As a missionary, I want an accurate sharing preview, so that I understand what the named coach will receive before saving.
Requirement: REQ28-C06. Acceptance: AC28-C06-01, AC28-C06-02, AC28-C06-03, AC28-C06-04, AC28-C06-05.
US28-C07. As a missionary receiving coaching, I want my coach to see the agreed information without controlling my records, so that accountability does not become unintended delegation.
Requirement: REQ28-C07. Acceptance: AC28-C07-01, AC28-C07-02, AC28-C07-03, AC28-C07-04, AC28-C07-05.
US28-C08. As a missionary or coach ending a sharing relationship, I want a clear scoped Stop or Leave action, so that access ends without damaging source records or unrelated work.
Requirement: REQ28-C08. Acceptance: AC28-C08-01, AC28-C08-02, AC28-C08-03, AC28-C08-04, AC28-C08-05, AC28-C08-06.
US28-C09. As a missionary, I want to choose whether my coach sees support summaries, so that sharing a goal or inviting a coach does not automatically disclose financial information.
Requirement: REQ28-C09. Acceptance: AC28-C09-01, AC28-C09-02, AC28-C09-03, AC28-C09-04, AC28-C09-05.
US28-C10. As a coach reading shared support progress, I want expected support to have a clear dated basis, so that I do not mistake a promise or planning estimate for received money.
Requirement: REQ28-C10. Acceptance: AC28-C10-01, AC28-C10-02, AC28-C10-03, AC28-C10-04, AC28-C10-05.
US28-C11. As a missionary sharing received support, I want the figure to reflect actual authoritative contributions, so that the coach sees accurate progress without donor-level access.
Requirement: REQ28-C11. Acceptance: AC28-C11-01, AC28-C11-02, AC28-C11-03, AC28-C11-04, AC28-C11-05.
US28-C12. As a coach, I want financial figures and comparisons to retain their units and meaning, so that a polished chart cannot mislead me about support progress.
Requirement: REQ28-C12. Acceptance: AC28-C12-01, AC28-C12-02, AC28-C12-03, AC28-C12-04, AC28-C12-05.
US28-C13. As a missionary, I want a support summary to protect the people behind it, so that summary-only coaching does not expose donor details through arithmetic or missing-data shortcuts.
Requirement: REQ28-C13. Acceptance: AC28-C13-01, AC28-C13-02, AC28-C13-03, AC28-C13-04, AC28-C13-05.
US28-C14. As a missionary, I want to add specific earlier financial periods, so that my coach receives exactly the history I reviewed.
Requirement: REQ28-C14. Acceptance: AC28-C14-01, AC28-C14-02, AC28-C14-03, AC28-C14-04, AC28-C14-05, AC28-C14-06.
US28-C15. As a coach reviewing earlier support, I want corrections and unavailable periods to remain clear, so that a fixed date range is not mistaken for a frozen official statement.
Requirement: REQ28-C15. Acceptance: AC28-C15-01, AC28-C15-02, AC28-C15-03, AC28-C15-04, AC28-C15-05.
US28-C16. As a missionary, I want ongoing sharing where permitted or a simple optional end date, so that I can control access without managing needless timers.
Requirement: REQ28-C16. Acceptance: AC28-C16-01, AC28-C16-02, AC28-C16-03, AC28-C16-04, AC28-C16-05.
US28-C17. As a missionary selecting a sharing end date, I want Share through to include that whole day, so that the deadline matches the language I see.
Requirement: REQ28-C17. Acceptance: AC28-C17-01, AC28-C17-02, AC28-C17-03, AC28-C17-04, AC28-C17-05.
US28-C18. As a missionary, I want to change a valid share's end deliberately, so that the saved access window stays predictable through retries and concurrent changes.
Requirement: REQ28-C18. Acceptance: AC28-C18-01, AC28-C18-02, AC28-C18-03, AC28-C18-04, AC28-C18-05.
US28-C19. As a missionary, I want to set my own useful activity targets, so that I can plan without compulsory reporting or a financial plan.
Requirement: REQ28-C19. Acceptance: AC28-C19-01, AC28-C19-02, AC28-C19-03, AC28-C19-04, AC28-C19-05.
US28-C20. As a missionary, I want each activity measure to explain what counts, so that the displayed progress matches work I actually did.
Requirement: REQ28-C20. Acceptance: AC28-C20-01, AC28-C20-02, AC28-C20-03, AC28-C20-04, AC28-C20-05, AC28-C20-06.
US28-C21. As a missionary, I want progress attributed to the actual participant once, so that shared work and duplicate records do not distort my targets.
Requirement: REQ28-C21. Acceptance: AC28-C21-01, AC28-C21-02, AC28-C21-03, AC28-C21-04, AC28-C21-05.
US28-C22. As a missionary, I want clear target dates and calendar rules, so that travel, late entry and partial periods do not change what my progress means.
Requirement: REQ28-C22. Acceptance: AC28-C22-01, AC28-C22-02, AC28-C22-03, AC28-C22-04, AC28-C22-05.
US28-C23. As a missionary, I want to change a target with a clear effective period, so that earlier comparisons remain understandable.
Requirement: REQ28-C23. Acceptance: AC28-C23-01, AC28-C23-02, AC28-C23-03, AC28-C23-04, AC28-C23-05.
US28-C24. As a missionary, I want to pause a target without losing my work, so that planning can adapt to my circumstances.
Requirement: REQ28-C24. Acceptance: AC28-C24-01, AC28-C24-02, AC28-C24-03, AC28-C24-04, AC28-C24-05.
US28-C25. As a missionary, I want to choose which numeric target summaries a coach can see, so that creating a personal target never shares it automatically.
Requirement: REQ28-C25. Acceptance: AC28-C25-01, AC28-C25-02, AC28-C25-03, AC28-C25-04, AC28-C25-05.
US28-C26. As a missionary sharing a recurring target, I want later periods to continue predictably, so that I do not repeatedly share the same target or accidentally expose earlier and different work.
Requirement: REQ28-C26. Acceptance: AC28-C26-01, AC28-C26-02, AC28-C26-03, AC28-C26-04, AC28-C26-05.
US28-C27. As a coach, I want a truthful numeric comparison, so that I can discuss progress without interpreting incomplete records as effort or gaining private activity details.
Requirement: REQ28-C27. Acceptance: AC28-C27-01, AC28-C27-02, AC28-C27-03, AC28-C27-04, AC28-C27-05, AC28-C27-06.
US28-C28. As authorized staff, I want to offer a few optional questions, so that missionaries have useful prompts without a compulsory reporting form.
Requirement: REQ28-C28. Acceptance: AC28-C28-01, AC28-C28-02, AC28-C28-03, AC28-C28-04, AC28-C28-05.
US28-C29. As a missionary, I want my answers to retain their original questions, so that staff edits cannot later change what my words appear to answer.
Requirement: REQ28-C29. Acceptance: AC28-C29-01, AC28-C29-02, AC28-C29-03, AC28-C29-04, AC28-C29-05.
US28-C30. As a missionary, I want to prepare a check-in privately, so that I can think before deciding whether to share it.
Requirement: REQ28-C30. Acceptance: AC28-C30-01, AC28-C30-02, AC28-C30-03, AC28-C30-04, AC28-C30-05.
US28-C31. As a missionary, I want to review the exact writing and audience before sharing, so that autosave and Share cannot be confused.
Requirement: REQ28-C31. Acceptance: AC28-C31-01, AC28-C31-02, AC28-C31-03, AC28-C31-04, AC28-C31-05.
US28-C32. As a missionary, I want edits to remain private until I update the shared version, so that a working revision cannot surprise my coach.
Requirement: REQ28-C32. Acceptance: AC28-C32-01, AC28-C32-02, AC28-C32-03, AC28-C32-04, AC28-C32-05, AC28-C32-06.
US28-C33. As a coach, I want readable shared check-ins with clear limits and states, so that I can prepare without seeing private writing or struggling on a weak connection.
Requirement: REQ28-C33. Acceptance: AC28-C33-01, AC28-C33-02, AC28-C33-03, AC28-C33-04, AC28-C33-05, AC28-C33-06.
US28-C34. As a missionary, I want to share a selected next step from my existing tasks, so that my coach sees what I intend to do without creating a duplicate task.
Requirement: REQ28-C34. Acceptance: AC28-C34-01, AC28-C34-02, AC28-C34-03, AC28-C34-04, AC28-C34-05.
US28-C35. As a missionary, I want to approve a short safe description while the real due date and status stay current, so that the coach receives useful context without private task details.
Requirement: REQ28-C35. Acceptance: AC28-C35-01, AC28-C35-02, AC28-C35-03, AC28-C35-04, AC28-C35-05, AC28-C35-06.
US28-C36. As a missionary, I want changed task meaning to require a new safe description, so that an earlier review cannot expose newly sensitive work.
Requirement: REQ28-C36. Acceptance: AC28-C36-01, AC28-C36-02, AC28-C36-03, AC28-C36-04, AC28-C36-05.
US28-C37. As a coach, I want next-step status to retain its real meaning, so that I do not mistake task completion for an interaction, payment or message being completed.
Requirement: REQ28-C37. Acceptance: AC28-C37-01, AC28-C37-02, AC28-C37-03, AC28-C37-04, AC28-C37-05.
US28-C38. As a missionary, I want a simple resource library, so that I can quickly find material my organization has approved for me.
Requirement: REQ28-C38. Acceptance: AC28-C38-01, AC28-C38-02, AC28-C38-03, AC28-C38-04, AC28-C38-05, AC28-C38-06.
US28-C39. As an authorized resource curator, I want to prepare, review and publish material, so that the library contains intentional and current guidance.
Requirement: REQ28-C39. Acceptance: AC28-C39-01, AC28-C39-02, AC28-C39-03, AC28-C39-04, AC28-C39-05, AC28-C39-06.
US28-C40. As a curator, I want withdrawal to stop new library access reliably, so that outdated or unsafe material cannot remain available through stale navigation or download paths.
Requirement: REQ28-C40. Acceptance: AC28-C40-01, AC28-C40-02, AC28-C40-03, AC28-C40-04, AC28-C40-05, AC28-C40-06.
US28-C41. As a missionary, I want an optional starting guide I can use in any order, skip and revisit, so that guidance supports my work without becoming a gate.
Requirement: REQ28-C41. Acceptance: AC28-C41-01, AC28-C41-02, AC28-C41-03, AC28-C41-04, AC28-C41-05.
US28-C42. As authorized staff, I want to edit the organization's suggestions easily, so that guidance stays relevant without maintaining a course platform.
Requirement: REQ28-C42. Acceptance: AC28-C42-01, AC28-C42-02, AC28-C42-03, AC28-C42-04, AC28-C42-05.
US28-C43. As a guide curator, I want Publish to offer exactly the version I reviewed, so that missionaries never receive mixed or accidental draft content.
Requirement: REQ28-C43. Acceptance: AC28-C43-01, AC28-C43-02, AC28-C43-03, AC28-C43-04, AC28-C43-05.
US28-C44. As a missionary, I want each guide suggestion to lead to a real permitted resource or workspace action, so that guidance stays useful and never exposes hidden material.
Requirement: REQ28-C44. Acceptance: AC28-C44-01, AC28-C44-02, AC28-C44-03, AC28-C44-04, AC28-C44-05.
US28-C45. As a guide curator, I want to stop offering guidance and later re-offer a reviewed version, so that I can maintain it safely without disrupting missionary work.
Requirement: REQ28-C45. Acceptance: AC28-C45-01, AC28-C45-02, AC28-C45-03, AC28-C45-04, AC28-C45-05.
US28-C46. As authorized organization staff, I want one clear regional-discovery control, so that we can offer the list and map deliberately without changing public publication.
Requirement: REQ28-C46. Acceptance: AC28-C46-01, AC28-C46-02, AC28-C46-03, AC28-C46-04, AC28-C46-05.
US28-C47. As a missionary, I want regional browsing to contain only approved public ministry information, so that exploration cannot reveal private people or locations.
Requirement: REQ28-C47. Acceptance: AC28-C47-01, AC28-C47-02, AC28-C47-03, AC28-C47-04, AC28-C47-05.
US28-C48. As a missionary, I want to explore approved ministries using a list or a world map, so that I can use the view that works for my device and accessibility needs.
Requirement: REQ28-C48. Acceptance: AC28-C48-01, AC28-C48-02, AC28-C48-03, AC28-C48-04, AC28-C48-05, AC28-C48-06.
US28-C49. As the accountable product and service owners, we want explicit proof and operating signals, so that optional coaching and resources stay truthful, private and usable after launch.
Requirement: REQ28-C49. Acceptance: AC28-C49-01, AC28-C49-02, AC28-C49-03, AC28-C49-04, AC28-C49-05, AC28-C49-06, AC28-C49-07, AC28-C49-08, AC28-C49-09, AC28-C49-10, AC28-C49-11, AC28-C49-12.

Implementation Decisions

Reuse the existing domain owners. The missionary app owns this experience, Mission Control owns staff administration, and the public/donor surfaces retain their existing responsibilities. The canonical API package owns business database logic and consequential commands. Shared database collections/hooks remain the approved browser data boundary. Asym Postgres owns CRM truth. No Twenty integration or private alternative CRM is introduced.
Separate working identity from permission. Tenant, authenticated principal, current workforce membership, Ministry Assignment participation and Support Assignment are distinct. A coach uses the explicitly admitted tenant-scoped coach role and gains no staff or unrelated access. A signed-in newsletter reader does not become staff, a tenant member or a CRM Party through Join. A relationship, matching email, shared household, payment or former assignment does not grant access. Each command and query resolves its exact current scope from trusted server context and the source owner.
Compose source-owned commands behind one user action. Preparation admission, contact sharing, allowed correction, referral continuation, Task completion, actual interaction, Request response, gift reporting and newsletter authorization retain distinct authoritative effects. Where one deliberate action records several locally owned effects, accept required source state, permanent operation receipt, audit and effect intent atomically. Cross-owner/provider work uses the existing qualified handoff and recovery contracts; there is no distributed transaction promise or browser-orchestrated partial write.
Use one durable business-effect identity. A retry replays the originally accepted effect or returns a semantic conflict; it does not obtain a new deadline, task, gift classification, subscription, email or calendar copy. New user intent is distinguishable from replay. Changes are accepted against the expected source/policy revision. Generic Task actions cannot bypass a source-owned obligation or complete purposes the user did not see.
Keep field audience and record authority separate. Restricted preparation is a bounded P9-owned source purpose, not a fake Party or new restricted-tier classification. Sharing eligible contact facts does not share prior private notes, email content, drafts or coaching responses. All reached lists, counts, searches, files, exports, notifications, logs and caches apply current disclosure before serialization or aggregation. Existence-sensitive records are absent rather than visibly redacted where required.
Maintain logical constraints at the durable boundary. Tenant-aware relationships, required source identities, immutable actor/author attribution, legal state combinations, unique semantic effects and same-scope ownership must be enforced by qualified constraints and the single owner command, not caller convention. Mutations check both existing and resulting state. Grants, RLS, views, functions, storage policies and service-role paths must preserve the same boundary. New exposed tables require explicit intended grants and RLS; neither implies the other.
Preserve one financial truth. Contribution, credit, commitment, fulfillment, goal and account balances remain separate. Use the source currency precision, Legal Entity, period and completeness contract. Missing, partial, stale and withheld data never become zero. Do not aggregate loaded pages as complete totals, infer first support from visible history, invent excess from unmatched money or convert received gifts into spendable balances.
Make native follow-up explicit and idempotent. Qualified first support, selected amount policy, confirmed additional-support purpose, one-time need, exact positive excess and fixed-commitment fulfillment each retain their source identity, eligibility and completion. Grouping is presentation and handling scope, not financial consolidation. Later optional workflows consume the same effect identities. Native duties do not require installation of an optional workflow product.
Formalize correction and attribution policy without changing money ownership. Organizations choose when posted-gift corrections need a separate authorized approver, within independent mandatory controls. Posted rows remain immutable. Source-code reassignment leaves earlier accepted gifts and continuing recurring lines under their accepted campaign. Truthful append-only gift corrections and deliberate prospective recurring attribution amendments remain distinct. Matching an independent gift changes fulfillment, not its attribution. Current hierarchy reports and preserved historical artifacts state their different bases.
Use owner-defined time semantics. New referrals count calendar days including the original referral date; continued referrals use elapsed days from accepted continuation. Coaching Share through includes the whole selected day in its disclosed approved zone. Newsletter confirmation lasts exactly 168 elapsed hours from durable acceptance, with equality expired. Display the resulting dates and relevant zone; client clocks, travel, retry, import and background job delays cannot extend authority. Expiry is enforced at access/action time even if cleanup is delayed.
Implement specific controls, not a universal policy builder. Use the exact settings/defaults in the normative volumes. Unsupported or missing authorization never silently becomes On. Preserve explicit existing settings during migration. A setting that prevents new admissions is distinct from withdrawing accepted consent, revoking access, stopping pending outward effects or deleting source material. Re-enabling never replays terminal actions or restores old permissions by implication.
Complete communication through the existing spine. P17 supplies governed authoring, content/media, source compilation and release contracts; P6 owns prepared artifacts, sealed submission, current recipient eligibility, intent, dispatch, provider observations and recovery. P28 adds exact native issue/signup purposes rather than a second sender queue. Require positive newsletter participation as well as negative suppression checks. No raw provider call, authenticated profile shortcut, Page setting or imported flag manufactures consent.
Verify the current address, then accept new intent. The signed-in Join path uses authentic current Supabase identity and qualified same-address proof, and still requires a deliberate newsletter-specific action. Anonymous Auth, stale claims, pending email changes, user-editable metadata and an unrelated workforce profile cannot establish this proof. Guests and other addresses use the existing protected confirmation action. A confirmation link GET is inert; the deliberate confirmation command enforces its original deadline and current rules.
Keep integrations narrow and recoverable. Native appointments remain authoritative when a user deliberately creates a managed calendar copy. Personal email records actual submission/outcome through a qualified connected account without claiming delivery or a reply. Credential revocation, ambiguous external success and delayed callbacks have source-backed recovery. There is no broad inbox import, external contact-update feed or new giving-feed scope.
Keep coaching voluntary and read-only. Own-principal invitations, exact subjects/modules/history, current organization limits, expiration and revocation govern every view. Summary access does not grant donor, gift, contact or raw activity access. Numeric targets, qualitative narrative and selected task summaries are separate sharing decisions. Template ownership grants no right to responses. Ending sharing does not end the source task or goal.
Reuse existing publishing and custody. Authorized curators publish resources through governed internal access; scanning a file is not publication. Regional discovery uses only approved public-safe broad regions, with list/map parity and no precise missionary locations. The optional guide links approved resources and existing actions; it never creates completion records, new task duties or an access gate.
Keep AI assistance optional and bounded. Reuse the existing AI/provider governance and the ratified writing-help actions, data minimization, request/resource limits and tenant controls. The author deliberately requests, reviews and applies suggestions. Generated text is neither verified fact nor a saved/sent issue. Ordinary editing and sending remain useful without AI, including when a request is unavailable or rejected.
Adopt retained data safely. Inventory actual reached legacy data, rights and writers before cutover. Resolve each source identity and retain accepted evidence; never fabricate private preparation authorship, consent, financial origin, completed interaction or coach grant. Introduce compatible source contracts/readers, backfill only justified meaning, qualify reconciliation and disable competing writers before activation. Rollback may stop a capability but must not erase accepted new source effects or revive retired unsafe writers.
Use the existing visual and interaction language. Compose shared Base UI/base-maia components with semantic tokens and approved compact variants. Preserve readable information hierarchy, purposeful action labels, accessible focus/status feedback and phone usability. Show Saved, Updating, Awaiting approval, Not sent or Unavailable only when the source establishes that state. Preserve safe input and make recovery specific; do not show generic success before required effects are accepted.
Qualify each capability independently. Missing source producers, identity assurance or complete financial evidence block the exact dependent action or measure. They do not justify a local substitute or disabling unrelated work. Formal specification and the ready-for-agent label do not waive source/provider/migration/user proof. The Phase 6 sealed provider-submission producer remains an explicit dependency until its actual component and qualification are established.

Testing Decisions

Confirmed primary seam: existing Playwright whole-user journeys across missionary, authorized staff, own-principal coach and public reader. Test the observable permitted state before and after real actions. Reuse existing surface runners and fixtures; add no parallel framework or synthetic model as the acceptance authority.
Focused tests: reuse Vitest at exported canonical command/query and shared component boundaries for fast error/state coverage. Assert user-visible and durable domain outcomes, not helper call order, private structures or mock query strings as the sole oracle.
Indispensable database proof: execute actual grants/RLS/storage/function paths with different tenant/principal roles, both mutation states, revoked authority and forged context. Use multiple database sessions for races; rollback fixtures alone do not prove concurrency. Exercise privileged workers and imports as well as ordinary clients.
Indispensable Auth proof: establish actual qualified current email/session evidence; prove guest, anonymous Auth, no-workforce-profile reader, changed address, revoked session and cross-tenant target behavior. Disable demo bypass for these cases. A missing mandatory fixture is incomplete qualification, never skipped-green success.
Indispensable provider proof: reuse shared Auth, calendar, personal-email and P6/P17 contracts against supported provider fixtures/sandboxes. Challenge duplicate/out-of-order callbacks, unknown external success, timeout after acceptance, suppression/revocation races and same-operation recovery. No real supporter communication is used as a test.
Prior art: missionary account-frame/navigation and partner safety tests provide shared shell, redaction, draft preservation and mobile interaction patterns; task-delete recovery proves truthful UI recovery. Auth session-guard and callback tests provide existing browser/HTTP boundaries. Support Hub proves related multi-surface behavior. Their mock/demo limits are explicit in the evidence volume.
Prior art for durable proof: existing field-policy SQL role-switch tests and contribution fee-replay integration tests establish reusable real database fixture patterns. Existing operation-wrapper, workflow ledger, intake-command and email webhook tests establish exported command/response interfaces. Extend those seams; do not claim their current coverage proves new Phase 28 behavior.
Required complete journeys: first useful work with optional modules Off; context switching; private preparation/share/archive/departure/return; late/expired referral continuation; real interaction plus task outcome; complete/partial financial scope; purpose-specific follow-up; intake continuation; guest/verified signup/rejoin/Off/expiry; newsletter author-to-outcome; calendar/email ambiguity; coach invite/share/revoke; library/guide/map use; interrupted save/reload/retry; migration/restore.
Boundary data: include shared households/churches, multiple ministries/commitments/currencies, zero-decimal and other supported precision, anonymous/restricted donors, multiple purposes/portions, partial corrections/refunds, unknown historical origin, DST/date boundaries, leap dates, long localized names, non-Latin addresses/text and low-bandwidth conditions.
Accessible outcomes: combine automated Axe checks with actual keyboard/focus, screen-reader/status, zoom/reflow, reduced-motion and mobile tests. A passing scan alone is not accessibility conformance. Map, reorder and visual charts retain usable text/list alternatives.
Performance and completeness: prove pagination, source-complete aggregation, query plans and bounded data transfer against a documented representative workload. Use existing instant-navigation and production-build Web Vitals patterns. Record workload, units, budgets and observed percentiles; no unmeasured claim that the feature is fast or scalable is accepted.
Migration/release proof: test old/new reader-writer compatibility, retained-data classification, replay, interruption and restored backups. Reconcile actual source facts and permanently accepted effects after recovery. Kill switches stop affected new work without destroying history or cancelling independently authorized payments.
Traceability: every US/REQ/AC identifier maps to the selected decision/completeness clause, owner contract and a future test/release artifact. No spec acceptance case is considered passed by documentation generation, a research probe or an unrelated earlier suite. Document-only verification checks source/derived consistency, IDs, links, coverage, exact publication and preserved evidence.

Out of Scope

Feature implementation, production activation, live-data migration, live configuration changes, real supporter messages and a decomposition into implementation tickets in this publication task.
A standalone missionary tenant, shadow CRM/ledger, Twenty CRM, separate personal task truth or a new general policy/workflow engine.
Automatic external contact updates, broad inbox/reply import, calendar authority over Asym appointments, a new giving-feed field family or external newsletter synchronization owned by a later phase.
Mandatory coaching, targets, check-ins, guide completion, courses/LMS, performance scores, donor-worth ranking, missing-log penalties or private-work disclosure through departure.
Automatic special-gift inference from giving history, automatic newsletter enrollment from gifts/imports/login, unattended AI writing/sending, automatic future digest parity, and an additional automatic missionary task for recurring misses/attention this release.
Changing payment authorization, designation, legal donor/credit, receipts or immutable posted money through a goal, campaign label, follow-up completion, gift-purpose confirmation or fulfillment match.
Precise worker location publication, a new arbitrary map-pin system, ordinary missionary resource submission/moderation, and bypass of current privacy/source restrictions for convenience.

Existing source duties and separately qualified capabilities retain their scope. An exclusion here does not silently retire a required P6/P9/P13/P14/P16/P17/P21/P27 obligation.

Further Notes

The founder's current /to-spec instruction authorizes formal synthesis and publication, superseding the earlier grill-only transition boundary. It does not rewrite the historical approval status of individual research packets. D1–D50 and ratified completeness C01–C20 are reconciled through their final selected meaning and later scoped amendments. Unselected options, abandoned timing defaults and speculative physical designs are not adopted merely because they occur in a review.

The canonical sources for stories, requirement prose and acceptance are the five normative domain/proof volumes. The numbered story section above, traceability and active OpenSpec behavior projection are derived views. Owner reconciliation and evidence are hand-maintained. Modify a canonical source and regenerate its declared views together; do not independently edit a projection. The main problem, solution, implementation/testing decisions and exclusions remain hand-authored.

The decision coverage and supersession map and owner reconciliation connect the full interview to exact formal scope. The publication record identifies the tracker issue, ordered normative parts and readback evidence. Source evidence and historical grill artifacts retain their original meaning and hashes.

Current research corroborates deliberate intent, clear consequences, source-preserving amendments, accessible feedback and proportionate controls. Competitors are examples, not authorities over Asym's adopted domain contracts. Qualified implementation still requires representative user journeys and actual source/provider/auth/migration evidence. No publication statement may turn a selected policy or a passing document check into a claim of deployed correctness.

Phase 28 specification · Part 03/53

Common safeguards and proof · file part 1

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/proof.md
Source chunk SHA-256: 2dfd7e499b3b164c82a7e19db7eed7abf1bb859bfa3be95a296bf96f0888b491

Previous part · Full index · Next part

Phase 28 — Complete journeys, common safeguards and proof

These requirements apply to every Phase 28 capability. More specific adopted
owner contracts retain their exact authority, defaults, finite periods,
retention and completion rules. This common floor does not create a generic
permission, configuration, workflow or retention engine. Requirements describe
intended behavior; publication does not establish implementation, qualification
or activation.

REQ28-Q01 — Useful first work after authorized setup

Story US28-Q01: As a missionary, I want to reach useful native work after my organization admits me, so that I can begin without configuring optional features.

Decision basis: Ratified completeness C01/C06/C16/C17; D37 optional guide; platform surface and capability owners.

The workspace SHALL provide a coherent path from authorized tenant setup to
first useful native relationship, task and appointment work through the existing
settings and navigation. Configured, enabled, source-ready and actor-permitted
SHALL remain distinct. Qualified baseline work SHALL remain useful with optional
guide, goals, coaching, personal connections and assistance Off. No mandatory
onboarding course, master Phase 28 switch or invented access-request workflow
shall become a prerequisite. Blocked work SHALL offer only a real permitted
setup, repair, retry or staff-contact destination without revealing hidden
configuration.

AC28-Q01-01: With all optional modules Off and baseline prerequisites qualified, a newly admitted missionary reaches a permitted relationship, creates ordinary work and can return to it without configuring any optional module.
AC28-Q01-02: Not configured, intentionally Off, source unavailable and actor not permitted produce distinguishable truthful states; none is reported as a successful setup or an empty dataset.
AC28-Q01-03: Each offered setup or repair action reaches its actual authorized owner; an unauthorized user cannot obtain setup details or change configuration through a direct request.

REQ28-Q02 — Exact organization and ministry context

Story US28-Q02: As a missionary serving more than one ministry, I want to enter the right authorized context, so that I understand whose work I am viewing and changing.

Decision basis: Ratified completeness C02/C13/C14; P3/P12 authorization; P27 assignment ownership.

Entry SHALL resolve zero, one or multiple currently permitted ministry contexts.
One eligible context SHALL open without repeated selection; multiple contexts
SHALL provide a searchable permitted choice; zero contexts SHALL provide an
honest access/setup state. A failed context read SHALL not masquerade as zero.
The effective organization and subject SHALL be visible where an action's
consequence depends on them. Saved selection, financial recognition, an email
address, a guessed identifier or another acting role SHALL not grant access.
Deep links and back navigation SHALL resolve current authority before revealing
private titles, counts or details.

AC28-Q02-01: Zero, one, multiple and failed-load fixtures produce the specified entry behavior without repeated selection for one context.
AC28-Q02-02: An actor with two ministries in two organizations sees the correct subject on search, detail and consequential actions, and each accepted write belongs only to its chosen authorized context.
AC28-Q02-03: A stale saved selection, forged deep link or now-revoked assignment reveals no forbidden record, title, count or action.

REQ28-Q03 — Safe context changes with unfinished work

Story US28-Q03: As a missionary switching contexts, I want my unfinished and accepted work to retain its original meaning, so that nothing is lost, exposed or applied to another ministry.

Decision basis: Ratified completeness C02/C08/C12/C14; D27/D28 preparation ownership; current session and cache boundaries.

Switching SHALL isolate source requests, cache entries, cursors, draft state,
recipient selections and delayed responses by exact admitted context. Saved
preparation remains under its original owner and current permission. Unsaved
work SHALL use applicable save/discard/cancel navigation choices rather than
silently moving to a new context. An accepted in-flight command may finish only
under its original source contract; its response SHALL not populate the new
context. Returning SHALL recover the original accepted result under current
permission before offering a new submission. Signing out or losing the selected
authority SHALL clear unsafe displayed/private state and reject late responses,
including when cancellation cannot stop the network request.

AC28-Q03-01: Switching ministry while a read is delayed never shows the old ministry's data in the new context, even when the old response arrives last.
AC28-Q03-02: Switching with unsaved work preserves the chosen save/discard/cancel outcome; no draft or recipient is reassigned implicitly.
AC28-Q03-03: A save accepted before switching is recovered once in its original context on a permitted return; it creates no second effect and reveals nothing after access is revoked.

REQ28-Q04 — One coherent daily work journey

Story US28-Q04: As a missionary, I want to move from a useful next action to an accurately recorded outcome, so that I can finish everyday work without duplicate entry or invented facts.

Decision basis: Ratified completeness C03/C05/C08; P9 interaction/task ownership; P27 managed-work floor; D40 informational recurring miss.

Home and work detail SHALL show currently actionable work with its permitted
factual reason, relevant date, responsible actor and clear next step. Task,
appointment, actual interaction, Request response, commitment and received gift
SHALL remain distinct source facts. Optional actual-interaction recording may
reuse currently permitted entered context; it SHALL not copy private material
into shared history or impose mandatory logging. Opening a dialer or mail app,
copying contact details or checking a task SHALL not manufacture an attempt,
conversation, sent message, response, consent or payment. Decline, defer,
cancellation, no answer, no authorized contact method and nonfinancial support
SHALL remain ordinary supported outcomes. Actively managed P27 work retains a
valid next task or an owned actionable exception; displaying restricted early
preparation SHALL not enroll it in managed work.

AC28-Q04-01: A missionary can record an actual unsuccessful call once, or finish independent work without recording an interaction; neither path invents a conversation, Request response, commitment or gift.
AC28-Q04-02: An actual meeting can lead through its supported outcome to an explicitly authorized Request response and next task or owned exception, reusing only currently permitted context.
AC28-Q04-03: A confirmed missed gift remains informational until a deliberate ordinary follow-up is added; no generic urgency label or missing log creates a new missionary obligation.

REQ28-Q05 — Completion follows the work's immutable contract

Story US28-Q05: As a missionary handling follow-up, I want completion to mean exactly what the work requires, so that a checkbox cannot falsely resolve another source's obligation.

Decision basis: Ratified completeness C03/C08; D19–D22/D29–D32 follow-up purposes; P27 source-owned work.

The server-resolved work contract SHALL distinguish independent human follow-up
from source-controlled work. Its authority classification SHALL not be editable
by changing a client field, task type, board column or linked source. Independent
follow-up may finish without closing its linked source or recording compulsory
interaction. Source-controlled work SHALL close only through its qualified
owner outcome and SHALL reject generic Complete, Reopen, Delete and drag-to-Done
through every reachable writer. A visual group SHALL preserve each purpose's
identity, evidence, authorization and completion record.

AC28-Q05-01: The same source-controlled item rejects generic completion, reopening and deletion from list, detail, board, bulk action, direct command and privileged consumer paths.
AC28-Q05-02: Finishing independent human follow-up does not mark a gift, commitment, intake, appeal response or source-controlled obligation complete.
AC28-Q05-03: Completing one permitted purpose in a grouped follow-up leaves other unfinished purposes accurately visible and preserves all completed evidence after regrouping or a tenant setting change.

REQ28-Q06 — Controls explain their exact consequences

Story US28-Q06: As authorized tenant staff, I want each control to explain what it changes, so that I can configure the workspace without accidentally cancelling work or restoring access.

Decision basis: Ratified completeness C06/C08/C12/C16; D24/D30/D32/D33/D37/D40 and D42–D45 source-specific controls.

Every exposed tenant or personal control SHALL retain its adopted default and
declare its owner, permission, scope and consequences for new work, accepted
work, current reads, pending outward effects and reenable. Off SHALL not mean
generic deletion, blanket revocation or replay. Readiness SHALL remain derived
from real owners. Saving, accepted, failed, uncertain and effective states SHALL
be presented accurately; a saved choice awaiting an applicable publication step
is not yet an effective public change. Routine reversible changes SHALL not gain
unnecessary confirmation dialogs. Material consequences SHALL be explained
locally before acceptance using existing configuration surfaces.

AC28-Q06-01: Turning missionary gift reporting Off blocks new reports while Finance continues the same accepted intake and the reporter retains only currently permitted recovery.
AC28-Q06-02: Turning a coaching module/share Off removes that exact access without deleting unrelated duties or reviving an ended share when reenabled; Page signup hide retains its separately adopted pending-request behavior.
AC28-Q06-03: Reload and a second permitted session show the actual accepted configuration; permission loss, stale revision and an uncertain save cannot produce a false Saved or effective-On state.

REQ28-Q07 — Current acting authority without role union

Story US28-Q07: As a person with several roles, I want each action to use only my current authorized role and subject, so that private work and privileges do not bleed across surfaces.

Decision basis: Ratified completeness C02/C13/C14; P3/P4/P10/P12; D42/D43 public-reader qualification.

Every read, mutation, export, job and result recovery SHALL prove the currently
admitted tenant, acting context, subject, source eligibility and applicable
permission at its owning boundary. Trusted authentication/source context SHALL
derive actor, author, approver, ownership and audit attribution. Caller IDs are
requests to resolve, not authority. Staff, missionary, coach, donor and public
reader paths SHALL retain their exact contracts rather than the union of a
person's roles. A public reader's qualified signup or confirmation SHALL not
require invented workforce membership, a CRM profile or a staff context.
Service identities SHALL prove their qualified capability and current source
ceiling rather than impersonating a human session or relying on credentials
alone. Current address possession proof and newsletter consent remain distinct.

AC28-Q07-01: A mixed-role actor cannot use a staff permission while acting as missionary or coach unless the explicit current owner contract grants that operation.
AC28-Q07-02: A caller's forged tenant, actor, owner, approval or audit fields are rejected or resolved to trusted permitted context; no accepted history attributes the effect to the forged actor.
AC28-Q07-03: The qualified public-reader Join/confirmation path works without a staff profile, while revoked, stale or unqualified identity proof fails safely without granting other product access.

REQ28-Q08 — Authorization precedes every disclosure

Story US28-Q08: As a person whose information is held by the organization, I want every view and derivative to preserve the same current audience, so that hiding a field does not merely move its disclosure elsewhere.

Decision basis: Ratified completeness C09/C14; P3/P10/P12 projections; D24–D26 coaching/shared-context limits.

Authorization and field classification SHALL be applied before enumeration,
joins, sorting, ranking, search, counts, facets, paging, export and serialization.
Task titles, notifications, logs, files, generated documents, cached values and
invalidation payloads SHALL retain the same current source audience. Cache keys
and cursors SHALL bind exact admitted scope and relevant source/authorization
revision. Neither a complete count nor the existence of a hidden record may be
revealed by an otherwise forbidden projection. Source-approved anonymity SHALL
be established positively; absence from a separate capped roster SHALL not
permit identity disclosure. Private stale data SHALL not be a fallback during
an outage.

AC28-Q08-01: Two differently authorized viewers using the same saved filter receive only their own permitted records, counts, facets and export fields, including after cache reuse.
AC28-Q08-02: An anonymous gift whose donor is missing from the returned roster remains anonymous in UI, API, task title, coach view, export and ordinary diagnostics.
AC28-Q08-03: Wrong-tenant identifiers, cursors and cache entries expose neither private values nor record existence, and a source failure produces an honest unavailable outcome rather than stale private content.

REQ28-Q09 — Complete and intelligible support information

Story US28-Q09: As a missionary, I want support information to state what it covers, so that I can plan without mistaking a partial list, forecast or unknown value for confirmed money.

Decision basis: Ratified completeness C04/C09/C11; D16 goals; P13/P14/P16/P21 financial and recognition ownership.

Totals, comparisons, lists and trends SHALL use complete qualified source
projections with explicit tenant/subject, currency, period, coverage, correction
basis and freshness. Loaded pages and display caps SHALL not define totals,
firstness, absence or negative facts. Unknown, incomplete, stale, unavailable,
not applicable and known zero SHALL remain distinct. Received money, recognition,
commitment, forecast, Goal Version, Support Plan and spendable Field Account
information SHALL retain their named owners and meanings. Relationship
continuity SHALL not be inferred solely from a financial-recency band or changed
into a person-level lapsed status.

AC28-Q09-01: Loading only part of a roster or gift history does not change a complete qualified total or cause an unsupported “none,” first gift or excess determination.
AC28-Q09-02: A failed or incomplete source displays its true limitation instead of zero support, no partners or a fabricated financial conclusion.
AC28-Q09-03: Corrections, refunds and delayed observations update authorized source-derived figures without duplicate recognition or received money, while independently authorized continuing relationships remain usable.

REQ28-Q10 — One authoritative source for each fact and command

Story US28-Q10: As a missionary or staff member, I want the same action to have the same meaning on every surface, so that boards, lists and shortcuts cannot create contradictory records.

Decision basis: Ratified completeness C03/C08/C10/C13/C16; ADR0001; platform boundaries and data-access ownership.

Business mutations SHALL use the canonical shared API and authoritative source
commands; app routes remain adapters and browser collections expose only their
qualified operations. Public projections, search indexes, dashboards, task
groups and provider events SHALL not become write authorities. Each integration
SHALL identify its exact producer, consumer, fact and permitted effect. Existing
CRM, commitment, financial, content, communication, document and identity owners
remain authoritative. No parallel CRM, direct-provider shortcut, second outbox,
general inbox, external contact-update feed or new generic workflow engine is
introduced by composing Phase 28 journeys.

AC28-Q10-01: Equivalent list, board, detail and shortcut submissions reach the same source validation and yield one consistent authoritative result/history.
AC28-Q10-02: A consumer cannot write a source-owned financial, consent, publication or identity fact through a projection, raw table, provider event or direct adapter bypass.
AC28-Q10-03: An unavailable dependency blocks only its affected effect and produces no substitute fact; unrelated qualified native work remains usable.

REQ28-Q11 — Database constraints and effective privileges

Story US28-Q11: As an organization administrator, I want persisted data and every access path to enforce the same boundaries, so that a valid edit cannot become a forbidden record.

Decision basis: Ratified completeness C13/C14; P3/P12; source-owned Supabase/Postgres conventions.

New or changed source relations SHALL define stable keys, required scope,
tenant-aware relationships and uniqueness, intentional nullability, valid state
combinations, finite/positive bounds where applicable, delete/restrict behavior
and protected history. Immutable scope and attribution may change only through
a qualified source transfer or correction. Constraints or a single authoritative
mutation boundary SHALL enforce invariants for old and resulting states.
Qualification SHALL inspect actual table grants, effective RLS old-row and
new-row checks, policy composition, views, function/RPC execution, storage and
privileged service paths. Explicit intended grants and actual Data API exposure
SHALL be verified independently of RLS. Definer/bypass paths SHALL have a
qualified bounded authorization contract; broad authenticated access or service
credentials alone are insufficient.

AC28-Q11-01: Using actual database roles, an otherwise permitted edit cannot change tenant, owner, author, scope, source reference or authority state outside its contract, including via upsert, RPC, view or privileged path.
AC28-Q11-02: Missing/forbidden references, duplicate source effects and invalid state combinations fail atomically; deletion cannot silently cascade away protected evidence or valid dependent work.
AC28-Q11-03: The deployed grant/policy matrix demonstrates both intended successful access and denied cross-context access; SQL text assertions and default exposure assumptions are not accepted as this proof.

REQ28-Q12 — Durable effects and atomic required handoff

Story US28-Q12: As a user retrying interrupted work, I want my accepted intent to happen once, so that a lost response cannot duplicate follow-up, enrollment or communication.

Decision basis: Ratified completeness C08/C13; source-purpose follow-up decisions; D42/D43; P6 durable delivery ownership.

Every mutating intent SHALL have a source-owned durable effect identity scoped
to its exact tenant, purpose and business occurrence. Retrying the same intent
SHALL recover its permitted result without applying it again or overwriting a
newer correction; a different normalized intent reusing that identity SHALL
conflict. A fresh HTTP key alone SHALL not establish a new human instruction.
The source transition, required acceptance/history and required downstream
intent SHALL commit atomically or through the owning source's already qualified
durable recoverable mechanism. Best-effort callbacks SHALL not be the only
record of required work. Independent source actions composed in one screen
SHALL not be presented as a distributed transaction.

AC28-Q12-01: A committed command with a lost response is retried through different transport attempts and results in one source effect, one required history acceptance and one intended downstream effect.
AC28-Q12-02: Fault injection between proposed writes leaves either no accepted source work or durable recoverable required handoff; repeated recovery cannot duplicate the effect.
AC28-Q12-03: Reusing an effect identity with changed purpose, recipient or payload conflicts without changing the earlier accepted result; genuinely distinct admitted occurrences remain possible.

REQ28-Q13 — Concurrency and correction preserve intent

Story US28-Q13: As a user editing shared work, I want conflicts and corrections to be handled explicitly, so that an old form cannot overwrite newer facts or bypass a current restriction.

Decision basis: Ratified completeness C02/C08/C13/C14; D5 contact correction; source-owned revision and revocation contracts.

Consequential commands SHALL bind the expected source state/revision or an
equivalent qualified conflict mechanism and serialize the relevant invariant
at authoritative acceptance. A prior UI permission check is not sufficient.
Contact edits SHALL apply only deliberately changed permitted fields, keeping
absent and deliberately cleared values distinct. A stale full-form save SHALL
not overwrite unrelated newer changes or invent a country or identity value.
Withdrawal, revocation, permission loss, source correction and configuration
changes SHALL be checked at the applicable owning boundary; later changes do
not erase previously lawful history or authorize a replay.

AC28-Q13-01: Two real database sessions editing the same protected revision produce the permitted serialized outcome and a recoverable conflict, rather than a silent lost update.
AC28-Q13-02: A stale contact form can update its still-permitted deliberate changes only under the qualified conflict rule; it cannot restore removed access, overwrite newer unrelated fields or default a foreign address to another country.
AC28-Q13-03: Races between action and controlling withdrawal, expiry, disable or permission loss preserve the source's documented order and leave no forbidden later effect.

REQ28-Q14 — Truthful outcomes and recoverable partial success

Story US28-Q14: As a user with an unreliable connection, I want to know what actually succeeded, so that I can recover only missing work without repeating an accepted action.

Decision basis: Ratified completeness C08/C16/C19; D42/D43 recovery; P6 external-outcome semantics.

Requested, pending, accepted, unavailable, failed and unknown outcomes SHALL be
distinguished according to the source contract. A failed readback SHALL not
turn an accepted write into failure. A composite action may promise a single
success only when the source guarantees that result; otherwise it SHALL expose
partial outcomes and retry only missing effects. Recovery SHALL recheck current
disclosure rights and resolve the original effect. Historic success SHALL not
assert a now-withdrawn membership or ended permission. Provider acceptance,
delivery, print/export and actual human response retain distinct meanings;
ambiguous irreversible effects require reconciliation before retry.

AC28-Q14-01: When an interaction is saved but the next task is not, the UI preserves that exact result and recovery creates only the missing task.
AC28-Q14-02: A timeout after source commit presents uncertainty with same-operation recovery, never optimistic completion or a blind fresh submission.
AC28-Q14-03: A later revoked viewer cannot retrieve private result details, and an earlier successful subscription receipt does not claim current subscription after withdrawal.

REQ28-Q15 — Exact money, dates and deadlines

Story US28-Q15: As a missionary working across currencies and timezones, I want amounts and deadlines to retain their source meaning, so that display choices cannot change financial facts or access windows.

Decision basis: Ratified completeness C11/C17; D28/D38/D39 and adopted newsletter timing; canonical money and source-period owners.

Money SHALL preserve the authoritative integer-minor-unit or exact fixed-scale
decimal representation, currency and supported precision. Floating-point
comparison or a universal two-decimal assumption SHALL not determine business
facts. Source-owned financial periods and half-open instant bounds SHALL remain
exact. Date-only values, actual occurrence time, recorded time and authorization
instants SHALL remain distinct. New-referral calendar rules, continued-referral
instant rules and confirmation deadlines retain their exact adopted contracts.
Device clocks, localization, retry, resend, delayed entry or a later policy
change SHALL not implicitly renew existing authority. Expiry SHALL be enforced
at the source decision after lock waits, not by a cleanup scheduler or stale
transaction-start timestamp.

AC28-Q15-01: Literal worked examples for supported zero-, two- and three-decimal currencies render and aggregate exactly; compatible scope/period is proved before comparison.
AC28-Q15-02: Last-day nonmidnight gifts, leap days, DST and timezone changes retain the owning financial/referral/confirmation boundary without omission or extra validity.
AC28-Q15-03: An action waiting across its deadline is denied at the authoritative transition; a later display timezone, resend or retry cannot extend the original period.

REQ28-Q16 — Participation, retention and privacy across return

Story US28-Q16: As a missionary leaving or returning, I want each kind of work to follow its own access and retention rule, so that private preparation stays private while lawful obligations are not lost.

Decision basis: Ratified completeness C06/C12/C14/C15; D27/D28; exact coaching, newsletter and duty owners.

Ending or suspending exact participation SHALL apply the source's current-read,
retained-duty, pending-effect and retention rules without a generic transfer or
delete operation. Staff or a successor SHALL not acquire private preparation
through reassignment, previews, exports or support tools. No eligible assignee
SHALL produce the source-owned owned exception instead of a guessed broad
fallback. Deliberate eligible resumption SHALL affect only selected preparation
and its adopted current-work/departure rule; it SHALL not restore old coaching
shares, subscriptions, sends or unrelated deadlines. Retention/disposition
SHALL cover actual controlled derivatives and restore handling under their
owners without treating access expiry as automatic destruction of lawful history.

AC28-Q16-01: Departure with private preparation, shared duty, coaching access and pending newsletter work produces each owner's documented result without exposing private preparation to staff.
AC28-Q16-02: Return before or after the applicable deadline, temporary suspension and a same-email replacement are distinguished; only the intended eligible actor can resume selected preparation.
AC28-Q16-03: Cleanup, export and restore cannot revive expired private access or delete still-required lawful duty/completion evidence as an unintended cascade.

REQ28-Q17 — Accessible, coherent Core interaction

Story US28-Q17: As a user on a phone or using assistive technology, I want the complete workflow to remain clear and operable, so that I can finish work without a desktop-only or pointer-only path.

Decision basis: Ratified completeness C01–C03/C17/C18; existing Core Base UI/base-maia design and accessibility contracts.

The composed experience SHALL use existing shared Base UI/base-maia primitives,
semantic tokens, typography and spacing. Each local job SHALL have an
understandable primary action, clear source/context and persistent material
outcome. Keyboard, screen-reader, touch, zoom and narrow-viewport use SHALL cover
the entire journey, including dialogs and errors. Boards and maps SHALL have
equivalent accessible list/menu operations; dragging, hover or color SHALL not
be the only affordance. Focus SHALL be preserved/restored appropriately and
material asynchronous results announced without stealing focus. A disappearing
toast alone SHALL not communicate success, failure, permission or expiry.

AC28-Q17-01: A representative complete job can be completed by keyboard and on a narrow touch viewport with no inaccessible drag-only, map-only or hover-only step.
AC28-Q17-02: Validation exposes labeled field errors; dialogs restore focus; asynchronous failure and recovery are perceivable with a screen reader and do not erase authorized input or list position.
AC28-Q17-03: Composed screens pass the applicable automated accessibility checks and manual keyboard, reading-order, zoom, contrast and touch-target review; a component or screenshot pass alone is insufficient.

REQ28-Q18 — Localized and low-bandwidth work

Story US28-Q18: As a missionary or reader in varied field conditions, I want understandable localized information and honest interrupted-work recovery, so that connectivity or unfamiliar formatting does not cause mistakes.

Decision basis: Ratified completeness C17/C18; D39 date-only referral semantics; D42–D45 reader journey; international identity/address owners.

The UI SHALL preserve supported Unicode names, real country/address formats,
international email values and exact currency identity without invented required
name parts or domestic defaults. Consequential dates SHALL show an unambiguous
localized value and relevant timezone; relative-only copy or ambiguous midnight
SHALL not substitute for the deadline. Loading and retry SHALL work without
false empty, zero or saved states under latency and interruption. This release
SHALL not imply unsupported full offline sync, persistent restricted-device
caching or automatic replay of unapproved consequential work. Public intake
and the protected confirmation doorway retain their distinct script contracts.

AC28-Q18-01: Long translated text, international names/addresses and supported currencies remain readable and editable without clipping, forced domestic values or loss of meaning.
AC28-Q18-02: Offline or delayed submission never shows false completion; reconnect offers the permitted original-effect recovery instead of silently replaying consent, sends, publication or money actions.
AC28-Q18-03: Public intake works under its no-JavaScript contract; missing protected-confirmation script support produces safe useful explanation without consuming proof or inventing an alternate token protocol.

REQ28-Q19 — Real capability readiness and bounded dependencies

Story US28-Q19: As a tenant administrator, I want unavailable capabilities to identify the actual repair path, so that a setting or roadmap label cannot promise work the system cannot perform.

Decision basis: Ratified completeness C01/C07/C16/C20; P6/P17 producers; D48–D50 settled correction/attribution policy and remaining owner implementation/adapter qualification.

Every required journey SHALL name its real producer, command/projection,
compatible version, owner and readiness evidence. A configured setting, issue
title, generic sender or roadmap phase SHALL not qualify a producer. Missing
source readiness SHALL block only the affected effect with honest permitted
feedback; the required outcome remains in scope. D48–D50 settle C-01/E7 policy;
their publication SHALL not qualify the actual correction command, attribution
producer or coherent coverage adapter. Technical qualification SHALL implement
that settled meaning rather than invent another policy. Optional future products SHALL not become blanket prerequisites for
already qualified native work. A direct provider/table bypass or parallel source
SHALL not be used to hide missing readiness.

AC28-Q19-01: Disabling or withholding one exact unqualified source effect leaves independently qualified relationship/task work usable and presents a real permitted repair route.
AC28-Q19-02: An enabled setting with an unqualified producer cannot accept the affected consequential action or display it as ready.
AC28-Q19-03: Under the settled D48–D50 policy, an unqualified correction command or attribution/coverage adapter leaves its affected effect or measure unavailable without inferred attribution, posted correction or substitute authority, and its remaining implementation/qualification dependency is explicitly traceable.

REQ28-Q20 — Retained-data census and safe migration

Story US28-Q20: As staff responsible for existing records, I want migration to preserve lawful history and unfinished work, so that the new workspace does not fabricate facts or lose obligations.

Decision basis: Ratified completeness C07/C12/C15/C20; exact source-owner migration and privacy contracts.

Before affected activation, the implementation SHALL inventory reached legacy
records, readers, writers, grants and downstream consumers. Migration SHALL map
them to intended source owners while preserving required identity, provenance,
restrictions, completed evidence and unresolved work. Ambiguous records SHALL
follow an authorized exception/correction path; backfills SHALL not infer
identity matches, consent, mailbox proof, financial facts, completion or role
rights. Validation SHALL include mixed-version reads/writes and explicit
reconciliation of counts and domain invariants, rather than accepting a
successful migration command as sufficient evidence.

AC28-Q20-01: A production-shaped retained-data fixture preserves lawful IDs, restrictions, completed effects and unfinished obligations with an explainable disposition for every reached record class.
AC28-Q20-02: Ambiguous legacy emails, imported contacts and old pending requests do not become verified identities, subscriptions or freshly valid authority through backfill.
AC28-Q20-03: Old/new schema and reader/writer combinations are tested; incompatible old writes are fenced before the new capability is exposed.

REQ28-Q21 — Qualified rollout and safe containment

Story US28-Q21: As an operations owner, I want to enable and contain affected capabilities safely, so that a release problem cannot corrupt accepted work or stop unrelated ministry work.

Decision basis: Ratified completeness C06/C08/C15/C16/C19/C20; existing activation and deployment owners.

Activation SHALL identify the exact release, environment, cohort, owner,
configuration and passed evidence. Readers, commands, source fences and required
recovery SHALL be compatible before exposure. Containment and rollback SHALL
stop affected unsafe admission/execution without erasing lawful accepted work,
restoring retired unsafe writers or replaying historical outward effects.
Rollback after new writes SHALL preserve newer authority and completion fences;
when that cannot be guaranteed, retain safe containment and use a qualified
forward repair. Staff/readers SHALL receive the truthful permitted outcome.

AC28-Q21-01: A controlled cohort activation reaches the intended configuration only after its required proof passes, while unqualified cohorts remain unavailable without false readiness.
AC28-Q21-02: Containment after accepted work prevents further unsafe effects, preserves original recovery identities and leaves unrelated qualified capabilities usable.
AC28-Q21-03: A rollback/forward-repair exercise with newly written data cannot resurrect revoked rights, duplicate sends or restore an incompatible writer.

REQ28-Q22 — Restore does not restore forbidden authority

Story US28-Q22: As an organization administrator, I want backup recovery to respect later restrictions and completed effects, so that recovery cannot re-expose data or repeat work.

Decision basis: Ratified completeness C12/C14/C15; source retention, suppression, revocation and consumed-effect contracts.

Before restored reads and jobs reopen, recovery SHALL reconcile subsequent
revocations, consent withdrawals, suppression, disposition, replaced/expired
proof and consumed business effects against the recovered state. Source owners
SHALL define their authoritative reconciliation evidence and safe unavailable
result when it cannot be established. Restore SHALL not infer renewed rights
from a recovered active flag, email address, old session or pending queue item.
The process SHALL preserve lawful durable evidence while maintaining disposition
of controlled private copies under the owning retention policy.

AC28-Q22-01: Restoring a backup predating withdrawal or access revocation does not allow that old subscription, share or protected proof to act or disclose before reconciliation.
AC28-Q22-02: A restored pending job whose durable business effect already happened cannot create a second task, enrollment, intake or outward send.
AC28-Q22-03: Missing reconciliation evidence keeps only the affected restored path safely unavailable with an actionable owner diagnosis; it never defaults to the recovered permissive state.

REQ28-Q23 — Durable history and actionable operations

Story US28-Q23: As an operator resolving a user problem, I want trustworthy source history and useful diagnostics, so that I can recover the accepted outcome without private-data exposure or database repair.

Decision basis: Ratified completeness C08/C19 and its adopted monitoring table; P6 delivery history; security/privacy owners.

Business history SHALL identify the durable source effect, exact context,
responsible actor and relevant policy/version without unnecessary private body
content. It SHALL remain distinct from security audit, technical traces and
provider outcomes. Operators SHALL locate an accepted-but-unpresented effect
and recover through its qualified owner command instead of direct database
repair, deleting evidence to deduplicate, or blind resend. Required monitoring
SHALL retain the signal, threshold, accountable role and response below; release
ownership SHALL bind those roles to an actual operating roster. Known policy,
privacy and correctness failures are launch blockers rather than monitor-only
risks.

These shared signals SHALL supplement, not replace or relax, adopted
source-specific monitors; the stricter applicable trigger SHALL govern.

Signal	Threshold	Accountable owner	Required response
Cross-context disclosure or effect after required denial	One confirmed occurrence	P12 security operator and affected source owner	Contain the path, preserve minimal evidence, correct and requalify before reopening.
Duplicate accepted intent or falsely reported saved/delivered result	One confirmed occurrence	Owning command/dispatch operator	Stop the affected mutation/retry path, reconcile original effects and repair presentation without erasing evidence.
Money/unit/period/coverage mismatch or anonymous identity exposure	One confirmed occurrence	Financial projection owner; P12 for identity	Withhold the affected projection, correct source/consumer and qualify boundary cases before return.
Accepted operation exceeds its declared completion/recovery bound	One operation beyond that qualified bound	Exact source operations owner	Investigate and reconcile by original identity; an unset bound blocks activation.
Critical journey confusion, accessibility blocker or repeated-entry defect	One reproducible blocking case in a supported journey	P28 product/design owner and implementing surface owner	Correct and retest the whole job; halt affected rollout if safe completion is blocked.

AC28-Q23-01: A lost-response incident can be traced from user-visible recovery to the original accepted source effect and required downstream work without exposing raw tokens or private narrative in ordinary logs.
AC28-Q23-02: Fault injection triggers each applicable adopted signal, routes to its bound owner and demonstrates the specified response through existing operational tooling.
AC28-Q23-03: Recovery resolves the original work through a qualified command and preserves separate business, security and delivery evidence; no direct row edit or duplicate effect is required.

Phase 28 specification · Part 04/53

Common safeguards and proof · file part 2

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/proof.md
Source chunk SHA-256: 37e4ec4421c450452471c4445f7927f2b45939ee1fabd372074527596a18dec4

Previous part · Full index · Next part

REQ28-Q24 — Confirmed testing boundary and useful prior art

Story US28-Q24: As a maintainer, I want tests at stable observable boundaries, so that they prove the user's whole job without freezing internal implementation details.

Decision basis: User-confirmed /to-spec testing seams; ratified completeness C18/C20; Core testing/TDD contracts.

The primary acceptance seam SHALL be the existing Playwright user journey
boundary across the missionary workspace, authorized staff controls and public
reader surfaces. Existing runners and shared UI SHALL be reused. Supporting
proof SHALL use actual database privilege/concurrency boundaries and the
qualified Auth/shared-delivery contracts where a browser cannot establish the
invariant. Focused Vitest tests may exercise exported canonical commands,
queries and component interfaces with controlled boundary fakes for fast
feedback; they SHALL not become a shadow product model or replace required real
proof. Tests SHALL assert independently specified user/domain outcomes rather
than reproduce the implementation, private helper calls or CSS details. No new
test framework is introduced.

Existing prior art includes the Missionary Account Frame browser journey,
session-guard flow, Tasks Page deletion recovery, Partners roster safety and
server redaction, client-session stale-response protection, shared operation
handler, workflow dispatch ledger, email recipient restriction/webhook contracts,
field-policy real-role SQL proof and donation replay transaction proof. Reuse
their appropriate public seams while retaining their limits: demo, mocked,
in-memory and SQL-text checks are not production authorization or concurrency
qualification.

AC28-Q24-01: Each implemented journey maps to a real user-level acceptance case plus only the necessary supporting source/DB/provider proof, with named observable success and failure outcomes.
AC28-Q24-02: A refactor preserving public behavior does not require rewriting tests merely because private helpers, query ordering or component structure changed.
AC28-Q24-03: Required suite manifests distinguish executed, failed, skipped and blocked cases; absent mandatory fixtures cannot produce a qualified release or a skipped-green claim.

REQ28-Q25 — Real-source security and failure qualification

Story US28-Q25: As a security and source owner, I want proof against the actual authorization and durable-effect paths, so that realistic races and provider failures cannot hide behind mocks.

Decision basis: Confirmed supporting test seams; ratified completeness C08/C13–C16/C18/C20; D42/D43 and P17 protected actions.

Qualification SHALL exercise actual role/grant/RLS/function/storage boundaries
and privileged source paths in an isolated disposable environment, with both
allowed and denied actors. At least two real concurrent database sessions SHALL
challenge source races; serialized synthetic histories alone are insufficient.
Real qualified Auth proof SHALL be distinguished from demo bypass, locally
auto-confirmed signup, administrative confirmation and user-editable metadata.
Public confirmation SHALL exercise the existing P17 generic inert doorway,
fragment handoff, deliberate same-origin proof submission and qualified review,
including current authority and original deadline. Provider-contract tests
SHALL challenge ambiguity, duplicate/out-of-order events, delayed dispatch,
current suppression and terminal effects without sending real user messages
from unit tests. Research scripts or documentation validation SHALL not be
represented as application qualification.

AC28-Q25-01: Real allowed/denied roles, current permission changes and attempted permitted-row-to-forbidden-state mutations produce the correct outcome through every reached table, RPC, view, storage and privileged path.
AC28-Q25-02: Concurrent acceptance/disable, completion/revocation, expiry/resume and confirm/withdraw tests prove one valid serialized business outcome, including a lock wait crossing expiry and response loss after commit.
AC28-Q25-03: The genuine qualified verified-address path succeeds while demo/admin/autoconfirm/unknown evidence cannot masquerade as mailbox proof; guest confirmation grants no Auth or workforce privilege.
AC28-Q25-04: Scanner/GET/HEAD and abandoned protected landings create no subscription; delayed or repeated provider outcomes cannot create consent, renew proof or replay a terminal effect.

REQ28-Q26 — Measured capacity and complete bounded reads

Story US28-Q26: As staff in a growing organization, I want the workspace to remain accurate and responsive as records and concurrency increase, so that a display limit cannot become silent data loss.

Decision basis: Ratified completeness C09/C14/C18; existing source budgets and measured-performance owners.

Before activation, source owners SHALL declare and meet production-shaped
volume, concurrency, completion/recovery and latency budgets for the intended
cohort. Evidence SHALL name dataset shape, tenant distribution, actual query
plans, pagination, error/latency distributions and limiting conditions.
Authorization predicates and source-appropriate compound indexes SHALL support
bounded reads and cleanup without global tenant contention. Each actual cap,
page size and supported bound SHALL be tested below, at and above the boundary;
truncation SHALL not change authoritative totals or completeness claims.
No unmeasured throughput claim, new generic performance platform or invented
numeric SLO is adopted here.

AC28-Q26-01: Workloads representing the intended cohort and a larger individual tenant meet the declared owner budgets, with reproducible data, concurrency and plan evidence.
AC28-Q26-02: Boundary fixtures around actual gift/donor/task and API page limits preserve complete totals, correct coverage and authorized traversal without missing or duplicated records.
AC28-Q26-03: Background expiry/disposition and ordinary recovery remain bounded and do not require scanning unrelated tenant histories or serializing unrelated tenants behind a global lock.

REQ28-Q27 — Representative whole-journey and traceable release proof

Story US28-Q27: As the product owner, I want complete journeys demonstrated with representative users and traced to their decisions, so that completion means usable, qualified behavior rather than a collection of screens.

Decision basis: Ratified completeness C01–C03/C07/C18/C20; confirmed test seams; document-authority status vocabulary.

Before release, the product/design owner SHALL recruit representative missionary,
tenant-staff, donor/reader and coach participants for the applicable complete
jobs, including new/experienced, mobile/assistive and restricted-access cases.
Evidence SHALL record environment, configuration, attempts, outcomes, errors,
comprehension and repair steps. Any critical wrong-recipient, false-success,
privacy or money misunderstanding SHALL block the affected release. Vendor
research, synthetic models and automated accessibility checks alone SHALL not
be called a successful pilot. Every required journey SHALL trace decision and
glossary through owner ADR/OpenSpec, design, tasks, authorized issue, implementation
and executed release evidence. Selected, adopted, formally reconciled,
implemented, qualified and activated states SHALL remain distinct. Unperformed
steps and unresolved exact owner gates remain explicit without adding unrelated
features to claim completeness.

AC28-Q27-01: Representative users complete setup/context selection, ordinary work and applicable communication/coaching/recovery jobs; observed confusion and blocking failures are recorded and resolved before affected activation.
AC28-Q27-02: Every requirement and acceptance criterion resolves to its current decision/owner and executed proof or explicit incomplete gate, with no historical research result relabeled as new runtime evidence.
AC28-Q27-03: Release completion is withheld until the affected source, migration, security, accessibility, capacity and representative-user obligations pass; documentation publication alone cannot satisfy that claim.

Phase 28 specification · Part 05/53

Relationships and working context · file part 1

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/relationships.md
Source chunk SHA-256: 19e78aa9f18478648f13c3a7ca3b9eef355df81477bf3fa6f09b844dcfa493c5

Previous part · Full index · Next part

Phase 28 — Relationships, preparation, referrals and starting guidance

This canonical volume defines the native relationship journey from first preparation through deliberate sharing, contact correction, archive, departure and return; bounded self-service contact intake; referral timing/history/continuation; and optional organization guidance. It contains REQ28-R01–REQ28-R43 and their stable user-story and acceptance identifiers. All stated outcomes are requirements, not evidence that current code already implements them.

The authorized full-phase specification adopts the selected product outcomes and reconciled engineering requirements here. Historical D1/D3 packet labels are not retroactively changed to blanket-ratified. Later explicit amendments govern their overlapping behavior: D28 permits a selected pre-expiry Resume to end the departure schedule in favor of qualified normal current-work retention; D39 uses calendar-date semantics for New referral windows only, while Continued windows retain elapsed 24-hour days. Accepted existing windows retain their original semantic basis and endpoint.

Shared source and authorization contract

Native P9/P4 sources own CRM assertions, identity resolution, relationship lineage and accepted changes. P12 and the shared subtract-only field/source resolver own current authority. P28 supplies the workspace. Source mutation, required minimal audit/activity and source-owned accepted-outcome evidence commit together, or use a specifically qualified existing owner composition; no best-effort callback can substitute for required acceptance.
Resolve exact Tenant, active acting context, source purpose, subject and field/history authority from trusted context. Submitted identifiers select a target to authorize; they cannot author tenant, human actor, original author, owner, approver or audit attribution. Authorize both old state and resulting state. A membership, role name, authorship, email match, saved selection or a service credential does not substitute for permission.
Apply authorization and safe-field projection before enumeration, search, counts, ordering, paging, serialization, recovery, export and other reached egress. Hidden and absent subjects must not form an existence oracle. Current result-release checks after waits, context-scoped query/cursor keys, and rejection of known-obsolete client responses prevent stale-context disclosure. Do not promise recall of already delivered bytes.
Tenant-aware relationships, non-null required identities, valid state combinations, immutable accepted provenance and durable effect uniqueness enforce the source invariants. Qualify grants, old-row USING, resulting-row WITH CHECK, column mutation, views/RPC ownership, Storage and privileged paths. FORCE RLS is not a substitute for service-role semantic authorization. No general browser writer may bypass an owner command.
Every mutation has durable source-owned business-effect identity, expected-revision or equivalent conflict handling, and current-authority recovery. Duplicate/reclaimed delivery cannot repeat an effect; changed meaning cannot reuse accepted intent. Distinguish definitely rejected, accepted, accepted-but-refreshing and outcome-unknown. Failed refresh does not undo accepted work; old receipts do not overwrite a newer current state. Use existing native change evidence rather than a new generic CRM/provider command journal.
Ordinary use remains available with optional modules Off when its own prerequisites qualify. Configuration, enablement, source readiness and actor authority are different facts. A missing source gates only its dependent effect and gives a truthful authorized repair path. Feature Off is not deletion, global grant revocation, stopping expiry, undoing accepted work or permission to replay old actions on re-enable.
Use exact Core shared Base UI/base-maia and semantic tokens. Complete journeys work with keyboard, screen reader, touch, 320 CSS-pixel reflow/zoom, international names and relevant address formats, explicit source-correct zones, and weak networks. Essential feedback is persistent and not dependent only on color, hover or toast. No unsupported persistent private offline cache or automatic privileged offline replay.
Source-retention/body custody, business history, security audit and technical telemetry remain distinct. Avoid raw contact/preparation/referral bodies in broad logs or analytics. Required history does not imply unlimited plaintext. Restore must apply newer restriction, erasure/disposition and consumed-effect authority before reads/jobs reopen.

Decision basis: completeness C01–C03/C06/C08/C12–C20; P9 A4/A17/A18; P12 four-principal/context rules at its canonical authorization section; ADR-0001; ADR-0209; ADR-0211 only for actual projection-policy widening; CRM Core requirements. This common contract is normative alongside each story's specific outcomes, not an optional test checklist. All REQ28-R acceptance criteria are evaluated with this contract.

REQ28-R01 — Choose the correct working context

Story US28-R01: As a missionary, I want to enter the correct organization and ministry context, so that my work affects the intended people and records.

Decision basis: completeness C01/C02/C06/C14/C17; P12 current Tenant Authorization Context; glossary Ministry Assignment versus Active Tenant Assignment.

Zero admitted contexts yields an honest no-access/setup state and only a real permitted help destination. One context opens directly; multiple admitted contexts can be deliberately selected without exposing unadmitted names/counts.

Show the consequential current organization/subject. Saved context selection is revalidated; another role's grants are not unioned into the request.

Switching does not move a draft, recipient, uploaded file, accepted effect or recovery request to the other context. Guard unsaved work with ordinary local recovery where still authorized; discard known-obsolete responses and clear data that is no longer readable.

A useful first native job does not require a guide, coach, goal, connected provider, import or AI.

AC28-R01-01: Given zero, one or several currently admitted working contexts, when Maya enters the workspace, then she receives respectively a truthful no-access/setup result, direct entry, or a choice containing only admitted contexts; unavailable sources do not appear as an empty authorized list.
AC28-R01-02: Given a saved context or another role, when a request is authorized, then exact current Tenant, Ministry Assignment and purpose are resolved from trusted context without role union or caller-controlled actor attribution.
AC28-R01-03: Given a draft, upload, selected recipient or outstanding response in one context, when Maya changes context or loses its authority, then none is applied to the new context and known-obsolete responses cannot restore protected old content; accepted source effects remain recoverable only under current authority.
AC28-R01-04: Given optional guide, coaching, goal, provider, import and AI capabilities are unavailable or Off, when ordinary native work is otherwise authorized, then Maya can complete its first useful job without enabling them.

REQ28-R02 — Save restricted preparation

Story US28-R02: As a missionary, I want to save early prospect preparation with incomplete knowledge, so that I can prepare without prematurely sharing a person's details.

Decision basis: D1 selected decision and C01/C02/C08–C11/C14–C15; D2 C04; D27 C04; completeness C13/C14/C16. Owner extension: bounded P9 preparation source for unresolved assertions, with qualified P4/P9 canonical reuse; no second CRM.

A short form accepts the owner-required minimum without forcing a household, country, address, email, ask amount, giving status, next task, stage, coach or invented canonical Party.

Newly supplied identity/contact assertions and planning remain restricted from ordinary relationship staff across all reached surfaces. Independently authorized organizational facts about the same person remain independently available.

Successful reload returns the same accepted preparation and original authorship. A saved preparation is not a verified contact, actual encounter, Request, cultivation enrollment, gift, commitment, newsletter subscription or publication.

Save/recovery observes the common atomicity/current-authority contract. No external provider is needed.

AC28-R02-01: Given an authorized restricted-preparation scope and only its source-required minimum assertions, when Maya saves, then one preparation is accepted and reloadable without inventing an email, household, country, ask, giving status, task, coach or canonical Party.
AC28-R02-02: Given newly supplied preparation facts and separately authorized CRM facts about the same person, when Maya saves and staff query, then newly supplied facts remain restricted while independent CRM facts retain their own authority.
AC28-R02-03: Given repeated delivery or an accepted Save with a lost response, when Maya recovers under current authority, then the same preparation and original authorship are returned, required source/change evidence is complete, and no encounter, Request, cultivation enrollment, gift, subscription or publication is fabricated.
AC28-R02-04: Given an in-progress Save, definite validation rejection, acknowledged acceptance or unknown outcome, when Maya returns to the form or list, then each state has distinct persistent feedback, safe input and list position are preserved where still readable, and keyboard/screen-reader focus and error/status feedback support the same recovery without another source entry.

REQ28-R03 — Resolve identity without disclosure

Story US28-R03: As a missionary, I want safe identity matching and clear unresolved results, so that saving preparation neither duplicates a relationship nor exposes another person's protected record.

Decision basis: D1 C03/C12; D2 C05/C06; D4 C04; D17 C05/C06; P4 identity owner; CRM Core identity/merge requirements.

Names, email, phones and shared addresses are evidence, never universal person keys or automatic merge instructions. Qualified authorized canonical identity may be reused without retyping.

Establish minimum candidate/result authority before exposing an existence-dependent branch. Hidden matches cannot alter disclosed counts, suggestions, detail links, result shape or repair routes into an existence signal.

A blocked canonical admission does not masquerade as an accepted staff share; ordinary restricted assertions remain usable where source rules permit. Do not create a second P27 enrollment for the same continuing purpose merely to avoid matching.

Relevant retained/archived records participate in authorized source resolution even when absent from the active list; matching does not automatically unarchive or merge private histories.

AC28-R03-01: Given a matching name, shared address, email or phone, when preparation is resolved, then no automatic merge or universal identity assumption occurs; qualified authorized identity can be reused without duplicate entry.
AC28-R03-02: Given an otherwise identical hidden or absent candidate, when Maya searches, previews or accepts, then counts, suggestions, links, outcomes and repair routes disclose no distinguishing protected identity information.
AC28-R03-03: Given an authorized retained or archived matching source, when new preparation is admitted, then source resolution considers it without unarchiving or combining private histories; blocked canonical admission never reports successful staff sharing or creates a substitute managed-work enrollment.

REQ28-R04 — Understand preparation audience

Story US28-R04: As a missionary, I want to understand who can see my preparation, so that an ordinary Save never surprises me with wider disclosure.

Decision basis: D1 C01/C06/C07/C11/C14; D2 C04; completeness C14; ADR-0209.

Explain the organization and restricted initial audience before Save; keep preparation working state, contact availability to staff and private-note audience distinct.

Protect newly supplied facts through search, task labels, timelines, exports, notifications, AI, audit content, accessibility text and caches as well as the detail page. D1 itself admits none of those optional external consumers.

Saving/contact storage grants no permission to contact. Each later send resolves its own current recipient/purpose/restriction evidence.

AC28-R04-01: Given the preparation form, when Maya reviews and saves, then the organization and restricted audience are explained before acceptance and Save does not broaden contact availability or private-note audience.
AC28-R04-02: Given protected preparation content, when reached search, task labels, timelines, accessibility text, notifications, audit display, caches or optional egress are evaluated, then the same source and field restrictions apply before disclosure; unadmitted optional consumers receive no content.
AC28-R04-03: Given a saved contact assertion, when a later communication is attempted, then current recipient, purpose and restriction authority is checked independently and storage itself grants no contact permission.

REQ28-R05 — Share eligible contact facts with staff

Story US28-R05: As a missionary, I want to make eligible contact facts available to staff deliberately, so that the organization can use its ordinary CRM without receiving my private preparation.

Decision basis: ratified D2 C01–C06/C14; D1 selected restricted start; P4/P9/P12.

Review the exact eligible contact facts, organization and ordinary staff audience before one explicit acceptance. Cancel or failed acceptance leaves the prior state intact.

Accepted sharing creates/reuses canonical contact facts only through the qualified P4/P9 owner. Independent authoritative facts are not silently overwritten.

Ordinary authorized staff discover the shared contact without per-contact invitations or collaborator grants. Existing protected-record, purpose and field floors still apply; sharing does not give Maya general staff visibility.

Private planning, earlier notes/activity, attachments, referral context and care information are not copied, summarized or relabeled into shared history.

AC28-R05-01: Given eligible restricted preparation, when Maya reviews organization, ordinary staff audience and exact contact facts and explicitly shares, then the canonical owner accepts or reuses only those facts without overwriting independent authoritative values.
AC28-R05-02: Given Cancel, denial or a failed share, when the result is shown, then prior availability remains intact and no staff grant or contact record is falsely claimed.
AC28-R05-03: Given an accepted share, when authorized staff discover it, then ordinary protected-record, purpose and field floors apply without per-contact invitation; Maya gains no general staff access and private planning, earlier activity, attachments, referral context and care information remain unshared.

REQ28-R06 — Optionally notify selected staff

Story US28-R06: As a missionary, I want to optionally tell selected staff that a contact is available, so that attention is directed without changing access or assigning work.

Decision basis: D2 C07–C13/C18; P9 source event, P6 recipient/communication truth, P17 Information presentation. Exact source-purpose contract is a required enabler.

The optional staff selection starts empty. Empty creates no notice; valid selected same-Tenant recipients receive one source-qualified informational in-product notice each. Duplicate selections normalize; invalid selections never fall back to all staff.

Selection does not define who may access the shared contact, assign responsibility or create a task. The action contacts no prospect and sends no email, SMS or push.

Sharing acceptance and notice requested/available/failed/unknown outcomes are distinct. A post-share notice failure repairs only the original notice, never repeats sharing or creates another contact.

Source/recipient eligibility is checked before notice availability, counts, display and opening. Replay may narrow recipients, never add substitutes. Read/open status is not follow-up completion.

AC28-R06-01: Given the optional staff selector initially has no recipients, when sharing is accepted, then no notice is requested; valid explicit same-Tenant selections produce at most one informational in-product notice each, and invalid selections never expand to all staff.
AC28-R06-02: Given selected notice recipients, when the share and notice are processed, then recipient choice grants no contact access, assignment or task and sends no email, SMS, push or prospect communication.
AC28-R06-03: Given accepted sharing followed by a pending, failed or unknown notice outcome, when the user views or repairs it, then component outcomes remain distinct and only the original notice is retried without another share or contact.
AC28-R06-04: Given revoked source or recipient eligibility, when notice availability, counts, display or opening are evaluated, then current authority withholds disallowed content and replay adds no substitute recipients; opening is not recorded as completed follow-up.

REQ28-R07 — Recover sharing without false recall

Story US28-R07: As a missionary, I want accepted sharing and later corrections to have clear history, so that recovery does not promise an impossible unshare or recall.

Decision basis: D2 C10–C12/C18–C20; completeness C08/C15.

The source effect, required audit/recoverable receipt and optional identifier-only notice intent are atomically accepted. Repeated intended delivery produces one share and requested attention.

A failed refresh or lost response recovers the same outcome under current authority. A later narrowed permission can withhold the response without undoing the accepted share.

Sharing provides no generic Unshare, person deletion, permanent-publication promise or recall of previously delivered information. Source-authorized correction/restriction/disposition remains available through its own owner.

AC28-R07-01: Given one deliberate share intent delivered repeatedly, when accepted, then the source effect, required minimal audit/recovery evidence and identifier-only notice intent commit together and do not duplicate the share or requested attention.
AC28-R07-02: Given an accepted share whose response or refresh fails, when recovery occurs, then current authority determines the permitted outcome display without reversing or repeating accepted truth.
AC28-R07-03: Given information has already been shared, when Maya seeks correction or removal, then the interface uses qualified source correction, restriction or disposition and offers no generic Unshare, deletion or recall promise.

REQ28-R08 — Configure missionary contact correction

Story US28-R08: As an authorized tenant administrator, I want to control missionary contact correction through existing permissions, so that our organization can enable or withhold eligible edits without another permission system.

Decision basis: D5 C01–C04/C11/C15; D41 C04; P12; ADR-0209/0211; active roster-safety contract.

One focused entry in existing permissions exposes exact missionary-purpose action/scope and qualified field controls; show effective versus draft/pending results and inherited restrictions.

Policy administration and editing contacts are distinct capabilities. Saving a policy grants no private content access, broad CRM rights, staff promotion or per-contact collaborator power.

Preserve valid existing permissions. Missing/unknown authority denies the affected action; no universal all-tenants-On or all-tenants-Off preset is inferred. Removing one grant does not falsely claim that all independently valid paths disappeared.

Actual projection-policy widening follows ADR-0211 distinct-human approval/current-base apply. Ordinary already-authorized contact-value Save has no new approval queue.

AC28-R08-01: Given an authorized policy administrator without contact-content access, when configuring missionary-purpose edit scope and fields, then the existing permission surface shows current versus pending effect and inherited restrictions without granting content or editing rights.
AC28-R08-02: Given valid existing grants, a removed grant or missing authority, when effective policy is evaluated, then valid independent grants remain, the denied action is withheld, and no blanket default or all-access-revoked claim is inferred.
AC28-R08-03: Given actual projection-policy widening, when it is proposed and applied, then the distinct-human approval and current-base rules of ADR-0211 apply; an ordinary already-authorized contact-value Save creates no additional approval queue.

REQ28-R09 — Correct only eligible contact fields

Story US28-R09: As a missionary, I want to correct only eligible shared contact fields, so that I can keep useful information accurate without overwriting other facts.

Decision basis: D5 C04–C07/C09/C12/C13; D41 C05–C08/C10; completeness C13.

A source-qualified field inventory names each admitted field, subject/purpose, read/edit/Clear right, validation and required consequence. Edit requires view; sharing/authorship does not grant edit.

Editable values, readable-only values, not-viewable values, permission checking and temporary unavailability are distinct. Forbidden values are not serialized into disabled/hidden inputs.

Save submits only deliberately selected changes; omission means unchanged and Clear is explicit. Any invalid/forbidden submitted field rejects the entire selected action, even if apparently unchanged. A true no-op creates no artificial correction or interaction.

Atomic accepted Save preserves untouched fields and lawful provenance. A stale edit conflicts rather than silently overwriting newer facts. International names/phone/address meaning is preserved without mandatory email, Western split or inferred USA country.

AC28-R09-01: Given a qualified field inventory, when Maya opens contact correction, then only currently viewable values are delivered, editable/read-only/checking/unavailable states are distinct, and edit authority never exceeds view authority.
AC28-R09-02: Given an explicit selected change set, when Save is accepted, then omission preserves untouched values and explicit Clear follows that field's rules; any invalid or forbidden supplied field rejects the entire action and a true no-op creates no correction or interaction.
AC28-R09-03: Given a newer source revision or changed permission, when a stale Save arrives, then it conflicts or denies without silent overwrite, and accepted changes retain source provenance and required audit evidence.
AC28-R09-04: Given international names, phone or address assertions and an absent email, when qualified changes are saved, then source meaning is preserved without a forced Western split, required email or inferred USA country.

REQ28-R10 — Preserve field meaning and safe drafts

Story US28-R10: As a missionary, I want contact changes and interrupted editing to respect each field's actual rules, so that an address correction does not become a consent or account change.

Decision basis: D5 C08–C10/C14; D41 C05/C07/C08; P9/P12/contact owners.

Contact correction alone verifies no possession, merges no identity, changes no login/legal/billing/public identity, authorizes no contact, and changes no money or private-note audience.

Apply exact changed-field consequences through the owner. A mandatory withdrawal fence or acceptance prerequisite succeeds before acceptance; independently asynchronous consequences use their qualified durable contract and truthful status. No D5-invented notification or donor-self email ceremony is added.

Preserve safe drafts on ordinary validation/conflict while readable. On loss of edit rights explain and prevent stale submission; on loss of read authority/context clear affected content and reject late responses. Restored rights do not auto-resubmit.

AC28-R10-01: Given an eligible contact-value correction, when saved, then it does not independently verify possession, merge identity, alter account/legal/billing/public identity, authorize contact, change money or widen private notes.
AC28-R10-02: Given a field with a mandatory owner consequence, when acceptance is attempted, then its prerequisite or withdrawal fence succeeds before acceptance; separately qualified asynchronous consequences remain recoverable with honest status rather than a fabricated all-success result.
AC28-R10-03: Given a recoverable validation/conflict error, when the form remains readable, then safe user input is preserved; loss of edit authority blocks submission, loss of read authority clears protected content, and later restoration never auto-submits the draft.

REQ28-R11 — Archive unused preparation

Story US28-R11: As a missionary, I want to archive unused still-unshared preparation, so that my active prospect list stays useful without deleting the person or independent work.

Decision basis: D4 C01/C02/C05/C06/C13; D3 selected boundary.

A single archive action moves the same preparation from Active to Archived under current authority; original authorship and history remain.

An obvious Active/Archived control makes it findable. No reason form, routine repeated confirmation, separate archive application or compulsory cleanup workflow is required.

Archive does not deactivate a Party/donor, change another worker's context, unshare contact facts, revoke permissions, close a partnership, complete/cancel tasks, stop reminders, change money or notify staff.

Where permitted source facts prove related open work, show its existing link and a short explanation; incomplete resolution is not “no open work.” Do not block ordinary archive on an exhaustive all-domain scan.

AC28-R11-01: Given unused still-unshared preparation and current archive authority, when Maya chooses Archive, then the same entry moves from Active to Archived and remains findable through an ordinary Active/Archived control with unchanged authorship/history.
AC28-R11-02: Given independent person, task, reminder, partnership, money, communication or another worker's context, when preparation is archived, then those facts and permissions are unchanged and no staff notice is sent.
AC28-R11-03: Given qualified evidence of related open work, when Archive is offered, then its existing permitted link and consequence are explained; unavailable evidence is not called no open work and an exhaustive cross-domain scan is not required for ordinary archive.

REQ28-R12 — Return archived preparation

Story US28-R12: As a missionary, I want to return eligible archived preparation to active work, so that setting something aside is reversible while current rules permit.

Decision basis: D4 C02–C04/C07–C12; D27 C05; D28 C07.

Persistent Return to active prospects acts on the same retained preparation. Optional Undo targets only its exact accepted archive and current qualifying revision, never restores a whole old row over later changes.

Return creates no replacement contact, revived grant, reopened completed task, restarted communication or verified contact fact. Purged/erased content is not recoverable.

A later deliberate D2 share may act on archived preparation without unarchiving; the review explains that independent effect. Return to Active is a separate deliberate working-state choice.

Concurrent archive/return/share and recovered old results preserve one ordered source history and current presentation.

AC28-R12-01: Given eligible retained archived preparation, when Maya deliberately returns it to Active, then the same entry changes working state without a replacement contact, revived grant, reopened task or restarted communication.
AC28-R12-02: Given a later change after an archive, when optional Undo is attempted, then it targets only the exact qualifying transition/revision and cannot restore an old row over newer truth; persistent Return remains the ordinary current-authority route.
AC28-R12-03: Given eligible archived preparation, when a deliberate staff share is accepted, then sharing can succeed while the preparation remains Archived; concurrent or recovered archive, Return and share results preserve current ordered state and never recover purged bodies.

REQ28-R13 — End access without exposing private work

Story US28-R13: As a missionary or responsible staff member, I want departure to end the right access without exposing private work, so that genuine organizational duties continue honestly.

Decision basis: selected D3; D3 C01–C07 as reconciled by ratified D2/D4/D27/D28 and completeness C12; P9/P12/ADR-0183 duty ownership.

Confirmed source participation/access termination fences the former reader without waiting for cleanup, handoff or a replacement. Inactivity, absent giving, missing voluntary logs, a closed browser or archive state is not a departure signal.

Departure/incapacity creates no new staff, administrator, coach, spouse, successor or cleanup reader of unshared preparation; no automatic share/export/transfer follows.

Already shared/independent CRM facts and accepted duties retain their owner permissions and continuity rules. No eligible assignee yields the source-owned exception, never guessed coverage or false Done.

Removing preparation cannot delete canonical people, erase financial/consent history, clear suppression or destroy another worker's records. An unshared prospect creates no mandatory handoff or missing-log task.

AC28-R13-01: Given confirmed termination of the relevant participation or access, when it takes effect, then former access is fenced without waiting for handoff or cleanup; inactivity, missing logs or giving, a closed browser and archive state do not trigger departure.
AC28-R13-02: Given unshared private preparation on departure or incapacity, when administration or handoff occurs, then no staff, administrator, coach, spouse, successor or cleanup reader is newly admitted and no automatic share, export or transfer occurs.
AC28-R13-03: Given independently shared facts and accepted organizational duties, when a worker departs, then their owner permissions and continuity rules remain; a missing eligible assignee creates an owned exception rather than guessed coverage, while preparation disposal cannot delete independent people, suppression, finance or another worker's records.

REQ28-R14 — Configure finite preparation retention

Story US28-R14: As an authorized tenant administrator, I want one finite post-departure preparation period, so that return needs are balanced with the organization's qualified privacy rules.

Decision basis: D28 C01–C04/C09/C10/C15/C17.

Configure one organization-wide positive whole-day period for this preparation purpose only, with fixed unit, supported limits, current saved value and concise advice to choose the shortest justified period. No per-person/project overrides or universal numeric default is selected.

One preparation-retention day is exactly 24 hours, or 86,400 seconds. This elapsed-duration unit is distinct from the New referral calendar-day rule; settings explain that distinction without adding another unit selector.

Before activation, the source/privacy profile identifies supported finite range, body/derivative scope, departure trigger, ordinary-work rules, required evidence/hold schedules and copy disposal/restore obligations. All layers enforce the same range without zero/blank/negative/overflow/Forever coercion.

A missing/unqualified policy leaves affected new preparation unactivated; independent CRM work continues. It neither purges legacy content nor silently retains it forever. Unknown retained cohorts enter bounded restricted owner assessment with responsible owner and resolution deadline.

Ordinary policy Save is prospective from authoritative acceptance. Previously accepted departure episodes keep their policy/deadline; required legal/privacy corrections use a separate qualified auditable transition. Administration exposes no private body or inventory.

AC28-R14-01: Given qualified source/privacy retention profiles, when authorized staff configure post-departure preparation retention, then one organization-wide finite positive whole-day value within the same supported bounds is saved without person/project overrides or a silently selected numeric default.
AC28-R14-02: Given zero, blank, negative, fractional, overflowing or unsupported input, when Save is attempted, then it is rejected without Forever coercion, rounding or unintended changes; policy administration exposes no private preparation inventory.
AC28-R14-03: Given no qualified policy, when new dependent preparation is activated, then activation remains gated while independent CRM work continues; retained unknown cohorts enter bounded restricted owner assessment rather than guessed purge or indefinite silent retention.
AC28-R14-04: Given existing accepted departure episodes, when an ordinary policy revision is accepted, then only later applicable departures use it and existing deadlines remain unchanged; mandatory legal/privacy corrections require their distinct auditable transition.

REQ28-R15 — Preserve the true departure clock

Story US28-R15: As a returning missionary, I want the original departure deadline applied accurately, so that delayed events and policy edits cannot arbitrarily preserve or erase my preparation.

Decision basis: D28 C05/C06/C09/C11; D27 C07/C11.

A confirmed relevant source departure binds original human author, Tenant/ministry, participation episode, effective and observed times, durable event identity, and policy effective at that departure instant.

Compute the departure deadline from the authoritative effective departure instant plus the accepted number of 86,400-second days using checked UTC arithmetic. Preserve that accepted deadline across daylight-saving, display-zone and timezone-rule changes unless an independently qualified correction changes it.

Duplicate/out-of-order events do not restart the clock. A late event uses validated effective time/historical policy; missing/conflicting evidence enters restricted owner review rather than guessed deletion.

Exactly one ordinary departure episode controls a preparation at a time; earlier episodes remain history. Later genuine departure schedules only entries admitted to that later work context, not unselected older entries.

Ordinary reads/resume require trusted current time strictly before the still-applicable deadline. Equality is expired even if cleanup lags. Deadline checks occur after waits at acceptance, not only at request/transaction start.

AC28-R15-01: Given a confirmed relevant departure, when its retention episode is accepted, then original human author, exact scope, participation episode, effective/observed times, source event identity and historically applicable policy remain attributable.
AC28-R15-02: Given duplicate, delayed, out-of-order or conflicting departure evidence, when processed, then it cannot restart retention; qualified late evidence uses effective time and historical policy, while missing/conflicting evidence enters restricted owner review.
AC28-R15-03: Given one current controlling episode and a later genuine departure, when scheduling runs, then only entries admitted to that later work context receive its new episode and unselected earlier entries retain their earlier deadline.
AC28-R15-04: Given the controlling deadline, when a read or Resume reaches acceptance before, at or after it following any wait, then only strictly-before access can qualify; cleanup delay is never a grace period.
AC28-R15-05: Given effective departure instant T and accepted period N spanning a daylight-saving transition, when the deadline is calculated or later displayed in another zone, then it remains T plus N times 86,400 seconds using checked UTC arithmetic; ordinary settings or timezone-rule changes do not recompute it, and an unrepresentable result is rejected rather than clamped.

REQ28-R16 — Find eligible earlier preparation

Story US28-R16: As a returning missionary, I want to find my eligible earlier preparation when permitted, so that I can decide what is useful without automatically restoring all old work.

Decision basis: D27 C01–C06/C13–C15; D28 C15; glossary Preparation resumption.

The optional Earlier preparation view uses current same-organization/ministry/history authority and qualified original-human authorship. Matching email/name, prior membership or restored login alone is insufficient.

Search, counts, summaries, detail and recovery are authorized before disclosure; held-only/expired/erased/purged or another author's preparation is not exposed. A denied query differs safely from a temporary error and from an authorized empty result.

Show original saved/substantive-change dates honestly and use the familiar editor. No mandatory return wizard, per-entry staff approval, reason, bulk restoration or automatic selection.

Initial qualified retrieval uses 25 summary rows per page and a hard request maximum of 100, detail on demand; these are D27/D28's initial service bounds, not a total record cap or measured performance claim.

AC28-R16-01: Given Maya has current exact organization/ministry/history rights and qualified original-human authorship, when she opens Earlier preparation, then only eligible retained entries are discoverable; matching name/email or restored login alone reveals nothing.
AC28-R16-02: Given another author's, expired, held-only, erased or purged preparation, when search, counts, summary, detail or recovery runs, then it is not disclosed and a temporary failure is not mislabeled as an authorized empty result.
AC28-R16-03: Given eligible earlier work, when Maya browses it, then truthful saved/substantive-change dates and the familiar editor are available without a required return wizard, staff approval, reason or bulk restoration; the initial service profile uses 25 summary rows and rejects requests above 100 rather than implying a total-record limit.

REQ28-R17 — Resume selected preparation

Story US28-R17: As a returning missionary, I want to resume selected preparation deliberately, so that only useful retained work becomes current work again.

Decision basis: D27 C04–C08/C11/C12; D28 C07/C14.

Resume includes the same preparation in the exact current activation/work context; preserve original author, membership provenance, source facts and Active/Archived state. At most one effective inclusion exists for the same preparation/current context.

Accepted Resume strictly before expiry atomically admits only the selected entry to qualified normal current-work retention and ends applicability of its departure deadline. Retain original deadline/policy/departure history; display that it is now kept under normal current-work rules.

Missing current-work retention qualification rejects admission without cancelling its existing obligation. Viewing, login/reactivation or resuming another entry does not extend the remainder.

Archived entries remain Archived; a clearly labeled Return to active prospects may compose both current inclusion and archive return atomically when both checks pass.

Resume changes no grants, contact verification, sharing, coach rights, task/communication status, subscriptions, connected accounts, gifts or commitments. Old inclusion does not automatically survive ended participation; temporary withholding without ended participation does not require reselection.

AC28-R17-01: Given current authority and qualified normal current-work retention before the departure deadline, when Maya explicitly resumes one entry, then the same entry gains at most one current-context inclusion, preserves authorship/working state, and only its departure deadline ceases to apply while original episode history remains.
AC28-R17-02: Given missing current-work retention qualification or acceptance at/after departure expiry, when Resume is attempted, then admission fails without cancelling the old obligation; merely reading, logging in or resuming another entry changes no remaining deadline.
AC28-R17-03: Given an Archived entry, when ordinary Resume succeeds, then it remains Archived; a separately clear Return to active prospects action may atomically compose both qualified effects without partial inclusion/return.
AC28-R17-04: Given resumed preparation, when independent work is inspected, then no sharing, verification, grant, coach access, task, communication, subscription or money changed; ended participation requires deliberate eligible reselection, while temporary withholding without ended participation does not manufacture another inclusion ceremony.

Phase 28 specification · Part 06/53

Relationships and working context · file part 2

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/relationships.md
Source chunk SHA-256: f14cdb2540972868cc2114db45b956543c891e10f26f7af5677fddff8d193da5

Previous part · Full index · Next part

REQ28-R18 — Enforce expiry and qualified disposal

Story US28-R18: As a missionary and records operator, I want expiry, holds and disposal to be distinct, so that retained evidence does not become renewed ordinary access.

Decision basis: D28 C06–C08/C11–C13/C16/C17; D27 C07/C17; completeness C15.

At a controlling departure deadline, all dependent ordinary reads/discovery/resume stop even if a worker is late/failing. A successfully resumed entry is governed by current-work retention, not its ended departure schedule.

Holds preserve exact qualified custody only and confer no ordinary read/resume right. Hold review date is not automatic release. Hold, resume, correction and destructive acceptance share the qualified source ordering boundary.

Dispose only qualified bodies/actual derivatives; preserve independently scheduled minimal evidence and unrelated CRM/finance/consent facts. Report primary copy outcomes and backup limitations honestly; do not claim all copies destroyed from one successful row delete.

A stale deletion worker cannot remove a now-ineligible target. External deletion ambiguity, if such copies exist, is reconciled under the exact-object irreversible commitment; timeout cannot pretend the deletion is cancelled.

Restore uses complete forward restriction/disposition evidence before release and cannot recover purged bodies or renew deadlines.

AC28-R18-01: Given a controlling preparation deadline, when it is reached, then ordinary discovery/read/Resume stop even if cleanup fails; a validly resumed entry follows normal current-work retention instead.
AC28-R18-02: Given an applicable hold, valid preservation transition or stale destructive worker, when disposal competes, then source ordering prevents removal of an ineligible target; a hold grants no ordinary access and a review date does not release it.
AC28-R18-03: Given qualified disposal, when its outcome is reported, then only scoped bodies/derivatives are removed, independently retained facts/evidence remain, and per-copy/backup or irreversible external ambiguity is reported truthfully rather than treating timeout as cancellation.
AC28-R18-04: Given a restored backup, when reads or jobs reopen, then complete forward restrictions, dispositions and effect-consumption authority apply first without restoring purged content, forbidden access or renewed deadlines.

REQ28-R19 — Import eligible contact assertions

Story US28-R19: As a permitted missionary, I want to import a supported contact file into restricted preparation, so that I can start work without manually recreating every eligible contact assertion.

Decision basis: D17 decision/C01–C05/C09; D1/D2; roadmap P30 target-owner acceptance. Required owner amendment: bounded missionary reviewer/committer and restricted-preparation target, not broad staff migration access.

Use one Choose file → Review → Import and results journey through P30 intake/P29 private custody/P4/P9 target/P12 authority. No staff-role substitution or routine second reviewer.

Initial field profile admits source-qualified name/display labels, email, phone and faithfully preserved/structured mailing-address assertions. A row needs a usable name/label, email or phone assertion; no universal email/location requirement or forced Party kind.

Explicit multiple-value mappings are required. Source IDs/type/context labels are provenance, not new Party facts. Unsupported notes/care/history/gifts/commitments/goals/credentials/schema/automation fields are shown excluded, never silently accepted.

Intake creates eligible restricted preparation or safely reuses an authorized reference; it neither bulk-updates existing contact fields nor automatically merges/shares/enrolls/sends/verifies anything.

AC28-R19-01: Given permitted intake and a supported file, when Maya follows Choose file, Review, Import and results, then the bounded missionary profile requires no staff-role substitution or routine second reviewer and accepts only target-qualified restricted preparation or authorized reuse.
AC28-R19-02: Given rows with a usable name/label, email or phone assertion, when mapped, then no universal email, location or Party-kind requirement is imposed; supported address meaning and explicit multiple values are preserved.
AC28-R19-03: Given source IDs/type/context labels or unsupported notes, care, history, gifts, commitments, goals, credentials, schema or automation fields, when reviewed, then provenance remains provenance and unsupported fields are visibly excluded without contact overwrite, merge, sharing, enrollment, send or verification.

REQ28-R20 — Review an immutable import plan

Story US28-R20: As a missionary, I want a trustworthy mapping preview, so that only the displayed eligible data is accepted.

Decision basis: D17 C03/C04/C10/C19 and ratified format profile.

Preview writes no contact facts and binds exact finalized bytes, selected sheet/header/rows, parser/catalog/mapping versions, purpose/target, proposed effects and relevant revisions. Any change generates a new reviewed plan.

Every candidate row is validated, not merely samples. Keep columns ordinally distinct when headers repeat or are blank; every nonempty column is mapped, explicitly excluded or unresolved.

Conflicting singular mappings, ragged extra cells and merged contact data require correction/exclusion; no silent truncation, last-column-wins or guessed fill-down.

Preserve meaningful Unicode, prefixes and original uncertainty. Do not split couples, infer a country, fabricate lost digits or call imported assertions verified. Warn when numeric cells may already have lost zeros/precision.

AC28-R20-01: Given finalized bytes and selected sheet/header/rows, when Review is produced, then every candidate is validated and the plan binds those inputs, parser/catalog/mapping versions, target/purpose, proposed effects and relevant revisions without writing contact facts.
AC28-R20-02: Given changed bytes, scope, mapping or relevant revision after review, when Import is attempted, then a new reviewed plan is required and the old preview cannot authorize different effects.
AC28-R20-03: Given repeated/blank headers, ragged cells, conflicting singular mappings or merged contact cells, when reviewed, then ordinal columns remain distinct and every nonempty column is mapped, excluded or unresolved without silent truncation, last-column-wins or guessed fill-down.
AC28-R20-04: Given Unicode names, couple labels, prefixes or numeric cells that may have lost digits, when previewed, then original meaning/uncertainty is preserved and precision warnings are shown without invented country, name splitting, digits or verification.

REQ28-R21 — Recover and repeat imports safely

Story US28-R21: As a missionary, I want repeated intake to recognize prior accepted work safely, so that recovery does not duplicate contacts or overwrite native corrections.

Decision basis: D17 C05–C07/C17/C18; D41 C03; P4 identity boundary.

Retry returns durable row effect receipts. Reuploading identical bytes in the same qualified scope/profile identifies prior work and reviews remaining effects; row number/file hash/tool name alone is not identity authority.

Qualified external IDs bind Tenant, exact target/workspace, source instance, entity kind and established source binding. Reordered/changed files without stable qualified IDs require authorized review; no perfect deduplication claim.

Changed bound assertions preserve current fields, show only authorized discrepancies and direct to ordinary correction outside intake. “Previously imported” is historical acceptance, not a claim of current equality.

Hidden matches do not leak through candidates, accepted/reused/unchanged outcomes, downloads or target references. Reimport cannot reactivate Archived work, restore consent, revive erased content or replay automations.

AC28-R21-01: Given a retried row or identical-byte reupload in the same qualified scope/profile, when reviewed or recovered, then durable prior acceptance is recognized and only remaining effects are proposed; file hash, row number or tool name alone is never person identity.
AC28-R21-02: Given an external ID, when it identifies prior work, then exact Tenant, workspace target, source instance, entity kind and established binding qualify it; reordered/changed input without stable qualified identity goes through authorized review.
AC28-R21-03: Given changed source assertions for an already accepted binding, when imported again, then current native values are preserved and only authorized discrepancies lead to ordinary correction; previously imported describes history, not current equality.
AC28-R21-04: Given hidden matches, archived work, erasure or existing contact restrictions, when reimport runs, then outcomes/downloads disclose no hidden record and do not unarchive, revive content, restore consent or replay automation.

REQ28-R22 — Preserve imported contact restrictions

Story US28-R22: As a missionary, I want imported contact restrictions handled accurately, so that a file cannot silently make a person contactable.

Decision basis: D17 C08/C09/C11; P6 recipient/contactability authority; D15 consumer gate.

Imported affirmative subscribed/active/donor flags grant no opt-in, verification, subscription or send authority.

Known negative/ambiguous contactability evidence is not silently ignored, including on reused/previously imported rows. Accept an affected row only when the exact contact/P6 owner atomically accepts scoped restriction/evidence and returns durable authority enforced by actual recipient/D15 gates; otherwise leave the row blocked.

The restriction receipt binds exact Tenant, preparation/recipient/contact revision, source occurrence, channel/list-purpose and provenance. Newsletter-X unsubscribe is not guessed into all-channel suppression, and unrelated independently lawful communication retains its owner meaning.

Import itself sends no message, confirmation, invitation, receipt, notice to the contact or historic trigger.

AC28-R22-01: Given imported affirmative subscribed, active or donor flags, when a row is reviewed or accepted, then they grant no opt-in, verification, subscription or send authority.
AC28-R22-02: Given negative or ambiguous contactability evidence on a new, reused or previously imported row, when acceptance is attempted, then the affected row remains blocked unless its exact contact/communication owner atomically accepts scoped evidence and a durable restriction receipt enforced by actual recipient gates.
AC28-R22-03: Given a qualified restriction receipt, when later contact eligibility is evaluated, then exact Tenant, recipient/contact revision, occurrence, channel/list-purpose and provenance apply without converting one newsletter unsubscribe into all-channel suppression; intake itself sends no message or historic trigger.

REQ28-R23 — Track truthful row outcomes

Story US28-R23: As a missionary, I want truthful per-row results and resumable progress, so that weak connections and partial failures do not force me to repeat accepted work.

Decision basis: D17 C11/C16/C18/C19; P30 bounded recoverable processing.

Each selected business candidate has exactly one current outcome: pending, accepted, previously-imported, skipped, needs-review, failed or not-processed; these counts sum to selected candidate total. Excluded rows/columns are separate. Counts describe rows, never automatically unique people.

Accepted distinguishes new preparation from reused authorized reference; not-processed identifies cancellation, expiry or authorization stop. Preserve outcome history and never label partial success all-failed.

Row or necessary owner-defined dependency-group acceptance atomically checks current scope/revision/cancellation/expiry/worker fence and persists effect, provenance, required restriction receipt and result/audit. No whole-file transaction is promised.

Reclaimed workers cannot commit with an old lease generation or skip unprocessed work. Recover from source effect receipts, not cursor position alone; reopen only retained/eligible input under current authority.

AC28-R23-01: Given a reviewed selection, when results are displayed, then each business candidate has exactly one of pending, accepted, previously-imported, skipped, needs-review, failed or not-processed and those counts sum to the selected candidate total; exclusions are separate and rows are not called unique people.
AC28-R23-02: Given partial acceptance followed by cancellation, expiry, denial or failure, when results reload, then accepted new/reused effects remain truthful and not-processed rows show the actual stop reason rather than an all-failed claim.
AC28-R23-03: Given row or owner-required dependency-group acceptance, when it commits, then current scope/revision/cancel/expiry/worker fence and required effect/provenance/restriction receipt/result/audit succeed together without promising one whole-file transaction.
AC28-R23-04: Given a reclaimed worker or lost response, when processing resumes, then stale lease generations cannot commit and durable source receipts prevent both skipped pending work and repeated accepted effects; expired/unreadable input is not reopened.

REQ28-R24 — Cancel or discard intake

Story US28-R24: As a missionary, I want to cancel or discard an import with clear consequences, so that stopping it does not erase already accepted contacts.

Decision basis: D17 C16/C17/C21/C23; D4 deliberate Return; completeness C06/C15.

Cancel orders against row acceptance, stops future acceptance and reports rows already accepted. Cancellation alone need not discard still-eligible input.

Discard immediately blocks further input/artifact access and acceptance and starts the qualified disposal obligation. Deleting a run/file never deletes contacts.

Any source-qualified undo refuses unsafe reversal after later edits, merges, sharing or independent/immutable coverage and points to the source correction path. D17 does not require a new batch-undo engine.

A kill switch stops new acceptance while preserving durable outcomes; re-enable does not replay history or defeat current erasure dispositions.

AC28-R24-01: Given import acceptance in progress, when Cancel orders against a row commit, then no later acceptance occurs and already accepted rows remain accurately reported without necessarily discarding eligible input.
AC28-R24-02: Given Discard, when accepted, then raw/artifact access and further acceptance stop immediately and disposal begins without deleting accepted contact facts.
AC28-R24-03: Given later edits, merges, sharing or independent immutable coverage, when an optional qualified undo is requested, then unsafe reversal is refused with a source correction path rather than a new generic batch-undo promise.
AC28-R24-04: Given a stopped intake capability, when it is later re-enabled, then retained outcomes remain recoverable under current authority and no historic effect or erased input is automatically replayed.

REQ28-R25 — Enforce the supported file profile

Story US28-R25: As a missionary, I want supported file limits and format problems explained before acceptance, so that the importer is predictable and does not execute spreadsheet content.

Decision basis: D17 C12/C22 and ratified Initial file and custody profile.

Enforce the ratified initial profile: uploaded file ≤10 MiB (10 × 1,048,576 bytes); selected-range nonblank processing data rows ≤10,000 before hidden/error/skip exclusions; parsed slots ≤500,000 across whole workbook/file including explicit empties; actual decompressed XLSX package ≤128 MiB; actual ZIP members ≤4,096; decoded cell text ≤32 KiB UTF-8; one explicitly selected worksheet; source columns ≤16,384. Stricter target-field limits win without truncation.

Count actual bytes/members/cells before and during work, not trusted Content-Length, dimensions or ZIP declarations. Sparse absent coordinates neither allocate nor count; hidden/unselected content still consumes applicable resource bounds. Reject traversal, ambiguous duplicate parts and unsafe entities/references.

Admit qualified CSV/data-only XLSX plus .tsv/.txt through the same text parser. Support UTF-8 with/without BOM, BOM-identified UTF-16 and explicit Windows-1252 recovery; preview confirms proposed comma/semicolon/tab dialect. Unsupported encoding has a useful resave instruction.

Execute no formulas/macros/embedded objects/external links and fetch no referenced resources. Reject encrypted/legacy/macro formats disguised by extension. Flag saved scalar formula caches as assertions; missing/error caches block affected mapped cells, and caches are never durable-ID proof.

Prove N−1/N/N+1 for every numeric boundary, worst-distribution memory/CPU/worker deadline, cancellation and tenant fairness. These are admitted qualification limits, not demonstrated capacity.

AC28-R25-01: Given a supported input, when actual upload/parsing proceeds, then the limits are 10 MiB uploaded bytes, 10,000 selected-range nonblank data rows before hidden/error/skip exclusions with the header excluded, 500,000 parsed slots across the whole file/workbook including explicit empty slots, 128 MiB actual expanded XLSX bytes, 4,096 actual ZIP members, 32 KiB decoded UTF-8 per cell, one explicitly selected worksheet, and 16,384 source columns per CSV record or XLSX XFD. Each N+1 boundary fails without truncation, stricter target-field limits win, and declared lengths, dimensions or ZIP metadata cannot bypass actual accounting.
AC28-R25-02: Given sparse, hidden, unselected or explicit-empty data, when resource totals are computed, then sparse absent coordinates allocate/count nothing while explicit slots and actual archive bytes/members count as specified; traversal, duplicate ambiguous parts and unsafe references are rejected.
AC28-R25-03: Given qualified CSV/data-only XLSX or TSV/TXT text input, when previewed, then UTF-8 with/without BOM, BOM-identified UTF-16 or explicitly chosen Windows-1252 recovery and suggested comma/semicolon/tab dialect are confirmed without machine-locale inference; quoted separators/newlines are preserved and uncertain decoding is reviewable rather than silently replaced. Unsupported, encrypted, legacy or macro input receives a clear safe resave path rather than execution.
AC28-R25-04: Given formulas, caches, macros, embedded objects or external links, when parsed, then nothing executes or fetches externally, scalar caches are flagged as unverified assertions, missing/error caches block affected mapped cells and no cache establishes durable identity.
AC28-R25-05: Given the worst admitted input distribution and concurrent tenant work, when release qualification runs, then memory, CPU, deadlines, cancellation and fairness stay within the published measured envelope; profile limits alone are not presented as demonstrated capacity.

REQ28-R26 — Dispose private intake material

Story US28-R26: As a missionary and records operator, I want private import custody with a clear working deadline, so that files and errors do not become an indefinite second contact database.

Decision basis: D17 C13/C20/C21/C23; P29; ADR-0212.

Originals, filenames, staging, previews, error files and recovery material use private P29 purpose-bound custody, finalized integrity and required quarantine/scan controls. A public image uploader or broad staff File Manager right is insufficient.

Working access/new row acceptance ends seven days after server-recorded finalized upload; reads, edits/retries/jobs do not extend it. Unfinished uploads are separately removed within 24 hours of initiation.

Purge eligible primary raw/derived content within 24 hours after expiry or discard; after the last lawful blocking hold/reference releases, purge within 24 hours. Holds delay physical disposal, not ordinary expiry. Accepted contact facts/minimal receipts use their source schedule; backups have their separate bounded schedule.

Recovery after expiry uses minimized accepted-effect receipts, not expired raw rows. A governed new upload/run may review remaining effects using prior lineage; it cannot renew the old deadline or repeat accepted effects.

Correction artifacts require current export policy and the same custody expiry. Prefer qualified XLSX explicit text cells without formulas/active links; any CSV uses ADR-0212's single shared encoder, quoting/CRLF/BOM and accurate limitations after spreadsheet save/reopen.

AC28-R26-01: Given private originals and derived import material, when upload is finalized and custody begins, then exact purpose-bound authority, integrity and quarantine/scan rules protect originals, filenames, staging, preview, errors and recovery material without public uploader or broad File Manager access.
AC28-R26-02: Given server-recorded finalized upload time, when seven days elapse, then ordinary working access and new row acceptance end without sliding on read/edit/retry; unfinished input is removed within 24 hours of initiation.
AC28-R26-03: Given expiry, Discard or release of the last lawful blocking hold/reference, when disposal runs, then eligible primary raw/derived content is purged within 24 hours; holds do not extend ordinary access and accepted facts/minimal receipts/backups retain their separate qualified schedules.
AC28-R26-04: Given expired raw input, when outcome recovery or a governed new run occurs, then minimized accepted-effect evidence prevents replay without reopening or renewing old custody; correction-artifact export requires current export permission and the same expiry, with explicit-text XLSX or the single ADR-0212 CSV contract.

REQ28-R27 — Record the original referral date

Story US28-R27: As a missionary, I want to record when a referral was actually given to me, so that late entry does not pretend I received a fresh introduction today.

Decision basis: D39 C01/C03/C06/C13; P9 referral edge/source owner; glossary Original referral date.

Reuse qualified source evidence; ask one original-date question only when needed, with an explicit unknown path. Preserve original referral event, recipient, lineage and factual precision separately from entered/imported/accepted times.

Creation, first view, import, reassignment, merge or retry never creates a later original event or second initial window. A genuinely separate introduction requires source evidence, not another row.

Preserve a qualified date-only assertion without inventing midnight. Exact instants derive their calendar date in the declared organization calculation zone while retaining source precision/provenance. Known dates from another zone are not converted by inventing missing time.

Unknown/approximate dates remain unconfirmed, not Today/Active/Expired/Continue eligibility. Reject a clearly future event as already given; treat apparent future dates from date-line/zone differences through contextual validation. Planned work remains planned.

AC28-R27-01: Given qualified original-referral evidence, when recording begins, then it is reused; otherwise one needed original-date input includes an unknown path and preserves recipient, lineage and factual precision separately from entry/import/acceptance time.
AC28-R27-02: Given later entry, first view, reassignment, merge, import or retry, when recording is accepted, then none creates a new original introduction or another initial window without evidence of a genuinely distinct event.
AC28-R27-03: Given date-only, exact-instant or other-zone date evidence, when interpreted, then date-only precision is preserved, exact instants derive the date in the declared organization zone, and missing time is never fabricated.
AC28-R27-04: Given unknown/approximate or apparently future evidence, when validated, then unknown remains unconfirmed without deadline or Active/Expired/Continue status, clearly future completed events are rejected, and valid date-line cases receive contextual validation while planned work remains planned.

REQ28-R28 — Calculate the New calendar window

Story US28-R28: As a missionary, I want the new referral's last follow-up day shown clearly, so that I know the real window without selecting another date.

Decision basis: D39 C02–C04/C13; explicit supersession of D38 C02 for New only.

New uses the configured positive whole calendar-day count N, original date D counted as day one, last included date D+N−1 in the declared organization zone. One day ends that same day; a 30-day October 1 example ends through October 30. These examples are not default durations.

Freeze D/N, zone, calendar interpretation, policy evidence and finite endpoint E at first acceptance. E is the first valid instant at the start of D+N in that zone: first valid instant after missing midnight, earlier repeated midnight occurrence, next existing date if target date is skipped.

Trusted time at/after E is expired regardless of cached flag or worker lag. Preserve E across travel, zone/settings and timezone-rule changes; where nominal last-day wording becomes misleading, show actual stored endpoint with current date/time/offset, declared zone and concise explanation.

A date-only referral can have less than 24 remaining hours; settings help makes calendar versus Continued elapsed-day meaning explicit. Do not add a clock-mode selector or per-item expiry override.

AC28-R28-01: Given New period N and original date D, when a first calendar window is accepted, then D is day one, the nominal last included date is D+N−1 and N=1 ends that same calendar day; Maya chooses no per-referral date.
AC28-R28-02: Given a qualified calculation zone, when the endpoint is frozen, then E is the first valid instant starting D+N, using the first valid instant after missing midnight, earlier repeated midnight or next existing date after a skipped date; D/N/zone/interpretation/policy evidence remain attributable.
AC28-R28-03: Given stored E, when time reaches E or ordinary settings, travel, zone or timezone-rule data changes, then expiry remains tied to E rather than a stale flag or recomputation; misleading nominal wording is replaced by the actual endpoint with date/time/offset and zone.
AC28-R28-04: Given New and Continued help or review, when displayed, then calendar-day inclusion and possible less-than-24-hours remainder are clear and distinct from elapsed-day continuation without a clock-mode setting.

REQ28-R29 — Record late and incomplete referrals

Story US28-R29: As a missionary, I want a late or incomplete referral recorded honestly, so that useful history is not rejected or silently renewed.

Decision basis: D39 C05/C06/C10/C13/C14; D34 C03/C06.

A genuinely first window uses the current qualified New policy at deliberate source acceptance A against the original date; record when the policy was actually applied without pretending it governed historically or granting backdated access.

Active work is possible from A inclusive and before E with all current predicates. If E≤A, accepted recording yields Expired atomically without temporary Active or automatic Continue.

Preserve an existing accepted window; missing prior evidence is not proof no window existed. Unknown policy/zone/provenance blocks only dependent calculation/effect and gives a safe owner repair path, while truthful incomplete recording remains possible where admitted.

Historical recipient proof and current D34 projection rights separately determine what history Maya may see. “Recorded” and “active” are distinct outcomes.

AC28-R29-01: Given a genuinely first referral window with original date evidence, when deliberately accepted at A, then the current qualified New policy is applied transparently without claiming historical governance or granting access before acceptance.
AC28-R29-02: Given E≤A, when the late referral is accepted, then it is recorded as Expired without temporary Active or automatic Continue; when A<E, active use additionally requires all current predicates and ends at E.
AC28-R29-03: Given an existing accepted window or missing prior proof, when recording resumes, then accepted terms are preserved and absence of evidence is not assumed to mean no window; unresolved policy/zone/provenance gates dependent calculation while permitted incomplete recording remains truthful.
AC28-R29-04: Given a recorded expired referral, when Maya requests history, then separate historic-recipient and current projection authority determine the result rather than treating Recorded as Active.

REQ28-R30 — Configure New and Continued periods

Story US28-R30: As authorized tenant staff, I want independent New and Continued referral periods in one place, so that our organization can configure its work without asking missionaries to administer dates.

Decision basis: D36 C01–C03/C05–C08; D38 C01–C08/C12/C15; D39 C02/C08/C09.

Two independent positive whole-number finite periods may be equal, smaller or greater than each other within the qualified supported range. New uses calendar days; Continued uses 86,400-second days. No inheritance, copied default, zero/blank-as-Never, third mode or per-missionary/project/referral override.

Before activation P9/API publishes exact supported integer/timestamp/serialization bounds enforced identically by UI/API/database; reject invalid, fractional, nonnumeric, unsafe and overflowing input without clamping/rounding.

Preserve qualified saved values. Unconfigured New blocks only dependent new initial acceptance; unconfigured Continued blocks only dependent Continue, including staff. Neither ends accepted work or disables other qualified actions. Read failure is not unconfigured.

One normal Save/Cancel applies deliberate valid changes atomically with expected base revision, audit and recovery. Untouched unconfigured values may stay absent; attempted Clear of a configured period fails. Relevant-kind changes alone invalidate relevant reviews; editing New alone does not invalidate unchanged Continued terms.

Ordinary edits are prospective and preserve accepted kind/period/end/policy/semantic basis. Saving a period never enables self-service or supplies action rights. Disabling action remains possible despite invalid unsaved drafts.

AC28-R30-01: Given authorized settings access, when staff edit the two periods, then New calendar days and Continued 86,400-second days are independent finite positive integers that may be equal or different within qualified bounds, without inheritance, per-item override or implied Never.
AC28-R30-02: Given invalid/fractional/nonnumeric/overflowing values or a changed base revision, when Save is attempted, then the entire selected change is rejected without clamping or partial update; valid selected changes commit atomically with audit and recovery.
AC28-R30-03: Given one unconfigured kind, when its dependent action is attempted, then only that kind is gated; read failure is not Unconfigured, untouched absence may remain, and Clear of an already configured value fails while independently valid work remains usable.
AC28-R30-04: Given accepted windows and unchanged terms of the other kind, when a policy changes, then existing windows and other-kind reviews remain intact; saving periods grants no action rights or self-service enablement and disabling an action remains possible despite an invalid unsaved draft.

REQ28-R31 — Read minimal expired-referral history

Story US28-R31: As a missionary, I want limited expired-referral history in my ordinary referral view, so that I recognize earlier work without assuming I may still access its private details.

Decision basis: D34 C01–C06/C11/C15/C16; narrow active-relationship-only projection exception C02; ADR-0209.

Active remains initial view; an optional Expired filter exists only when current organization/source/history authority admits it. It is not a separate archive, inbox, review requirement or personal feature toggle.

Prove that this exact referral previously belonged to Maya's authorized work before ordinary expiry, including an eligible prior handoff recipient. Creation-time exclusivity is not required; new assignment, same email or Party merge is not historic proof.

Closed projection contains only approved recognizable name/safe alias, necessary source reference, Expired meaning and permitted known dates/precision. No email/phone/address/portrait/location/referrer/private context/notes/giving/history, nor fallback to hidden initials or raw IDs. Omit a row with no useful safe identification from results and counts.

Explain once that its follow-up window ended and contact details are not shown here. Expired never means donor refusal, Never Ask, lost support or low value. No broad contact-card link follows from this history purpose.

AC28-R31-01: Given an authorized referral view, when opened, then Active is initial and the optional Expired filter appears only under its exact current history/source authority without another archive or required review workflow.
AC28-R31-02: Given evidence the exact referral previously belonged to Maya's authorized work, including a valid prior handoff, when ordinary expiry history is projected, then that proof qualifies independently of creation recipient; new assignment, matching email or Party merge alone does not.
AC28-R31-03: Given an eligible history entry, when listed or searched, then only approved recognizable identification, necessary source reference, Expired meaning and permitted known dates/precision are disclosed; hidden contact/context fields never supply labels, and entries lacking useful safe identification disappear from results and counts.
AC28-R31-04: Given an Expired entry, when Maya reads its explanation, then the ended work window and unavailable contact details are clear without implying refusal, Never Ask, lost support or a broad contact-card grant.

REQ28-R32 — Keep expired history purpose-limited

Story US28-R32: As a missionary, I want expired history to remain read-only and purpose-limited, so that opening an old referral does not renew it or erase independent access.

Decision basis: D34 C07–C14/C17/C18/C21/C22; D35 C10/C12.

Filtering/searching/reading changes no status, dates, retention, task, interaction or communication. Source telemetry is not an outreach event.

Withdrawal, invalidation, privacy revocation, departure and generic archived/ended statuses do not qualify as ordinary expiry. Source corrections affect current eligibility without rewriting lawful history.

Ordinary supporter access is evaluated independently: D34 denial does not remove another valid path, and that path does not expose protected referral context. Retention/hold alone grants no historical read.

Search only admitted fields, before pagination/counts; hidden phone/note matches reveal nothing. No new export, print list, AI, sync or offline roster is added.

AC28-R32-01: Given expired history, when filtered, searched or opened, then no business state, date, retention, task, interaction or communication changes and telemetry is not treated as outreach.
AC28-R32-02: Given withdrawal, invalidation, privacy revocation, departure or a generic archived/ended state, when history eligibility is evaluated, then it does not masquerade as ordinary expiry and retention/hold alone creates no read right.
AC28-R32-03: Given a separate current supporter-access grant, when either history or ordinary contact is read, then each purpose is evaluated independently without a denial removing another valid path or that path exposing private referral context.
AC28-R32-04: Given hidden phone, email, referrer, location or notes, when searching or counting, then no hidden match signal is disclosed before paging; history creates no new export, print, AI, sync or offline roster purpose.

REQ28-R33 — Control missionary continuation

Story US28-R33: As authorized tenant staff, I want one control for missionary continuation, so that self-service is optional without interrupting authorized staff work.

Decision basis: D35 C01/C02/C06/C19/C22; D36 C02; D38 C04; D39 C08.

Allow missionaries to continue expired referrals starts Off for new/unconfigured tenants; preserve an existing explicit qualified choice. Existing scoped grants decide eligible actors; no per-ministry matrix or personal switch.

Off stops new missionary-lane acceptance at the source boundary. It does not undo accepted cycles, expire active work, remove independently permitted history, cancel independent work or revoke staff's separate authority. Tenant staff can restrict their own action grants through existing administration.

A caller-supplied role/surface/mode cannot switch a missionary command into staff authority. Enabling alone grants no universal authority and does not replay rejected/stale intent.

Settings Save and source acceptance share relevant policy ordering, including unconfigured→first enable and A→B→A; pending/effective states stay truthful.

AC28-R33-01: Given a new/unconfigured tenant, when continuation is configured, then the single organization-wide missionary-continuation control starts Off, preserves explicit qualified existing choices, and uses existing exact scope grants without a per-ministry or personal setting.
AC28-R33-02: Given Off accepted before a missionary Continue, when acceptance is attempted, then the missionary lane is fenced while independently permitted staff action, history, accepted active cycles and unrelated work remain intact.
AC28-R33-03: Given caller-supplied role/mode/surface or a later re-enable, when a command arrives, then it cannot escape through the staff lane, revive a rejected intent or auto-renew work; only fresh authorized intent may qualify.
AC28-R33-04: Given configuration changes including unconfigured-to-enabled or A-to-B-to-A, when settings and continuation compete, then authoritative policy ordering produces a truthful effective result rather than a stale UI-only gate.

REQ28-R34 — Continue an eligible referral once

Story US28-R34: As an authorized missionary or staff member, I want to continue one eligible expired referral in one action, so that current work resumes on the same truthful lineage.

Decision basis: D35 C03–C07/C10/C17; D36 C04/C07–C10/C15/C16; D38 C09; P9 A4/A17.

Current exact source/cycle responsibility, action permission, ordinary-expiry eligibility, privacy and policy are required. History visibility alone is insufficient; the command admits expired inputs without requiring a fake already-active relationship.

Preview explains Continued period and estimated end date/time/zone. Maya chooses no date and supplies no routine reason/approval/referrer form; source-required prerequisites remain binding. A relevant changed policy, end calendar date or display-zone context requires refreshed review/new deliberate intent, not a second-by-second confirmation loop.

After required ordering/waits, capture fresh trusted database instant A; compute E=A+N×86,400 seconds exactly and atomically accept one new cycle with A/E/N/policy/audit/activity/outcome evidence. Active is A≤now<E subject to other current rules; at E it is expired.

Preserve original introduction/prior cycles. At most one successor consumes an expired cycle across missionary/staff and different transport keys. Accepted result shows actual endpoint and current permitted active projection, not blindly restored old private fields.

AC28-R34-01: Given ordinary expired-cycle eligibility, exact current responsibility, action/privacy authority and qualified Continued policy, when review opens, then the period and estimated endpoint/zone are shown without another date, routine reason, approval or referrer form; required source prerequisites remain enforced.
AC28-R34-02: Given a relevant changed policy, resulting end calendar date or display-zone context after review, when acceptance is attempted, then fresh review and deliberate intent are required, while ordinary within-date drift causes no second-by-second confirmation loop.
AC28-R34-03: Given valid final authority after all ordering waits, when Continue commits, then fresh trusted A and E=A+N×86,400 seconds, one successor cycle and required audit/activity/recovery evidence are accepted atomically; Active holds only for A≤now<E subject to other current restrictions.
AC28-R34-04: Given competing authorized actors or different transport keys for one expired cycle, when both attempt continuation, then at most one successor consumes it, original lineage remains, and the accepted result shows the actual endpoint with current permitted fields instead of restored stale private content.

Phase 28 specification · Part 07/53

Relationships and working context · file part 3

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/relationships.md
Source chunk SHA-256: bf7d0430f28d5677e5885c8ec9a79937958bf42337b9b18dfe88911a85f2edd7

Previous part · Full index · Next part

REQ28-R35 — Recover continuation safely

Story US28-R35: As a missionary, I want safe recovery of a continuation outcome, so that retrying cannot open a second window or conceal a later expiry.

Decision basis: D35 C08/C09/C15; D36 C09/C10/C14; D39 C10/C14.

Unknown response offers current-authority recovery of original intent. Accepted retry returns original performer/terms/endpoint; it cannot consume a later expired cycle or compute another deadline.

A definitive rejection remains no-effect even if policy later returns or time makes the referral eligible; fresh intent requires fresh deliberate action. If qualified recovery evidence has expired, reject safely without re-executing.

Distinguish accepted earlier outcome from current state after another expiry, correction or continuation. Recovered success does not mean Active now. Current disclosure may withhold fields without rolling back accepted business truth.

Stale expiry work targets exact cycle/end/revision and cannot end its successor. Reconnection does not queue automatic new privileged work.

AC28-R35-01: Given a lost response to accepted Continue, when the original intent is recovered, then the original performer/terms/endpoint are shown under current authority without another deadline or consumption of a later expired cycle.
AC28-R35-02: Given a definitively rejected intent or expired qualified recovery evidence, when policy/time later changes and the old intent retries, then it produces no new effect; any further continuation requires fresh deliberate intent.
AC28-R35-03: Given an earlier accepted continuation and later expiry/correction/continuation, when recovery displays the earlier outcome, then current state is distinguished from accepted history and protected fields may be withheld without reversing truth.
AC28-R35-04: Given an old expiry worker or reconnection, when processing resumes, then exact cycle/end/revision fencing prevents ending a successor or queuing automatic privileged continuation.

REQ28-R36 — Correct referral timing with evidence

Story US28-R36: As an independently authorized source corrector, I want to repair a mistaken referral date or expiry with evidence, so that correction restores truth without counterfeit renewal.

Decision basis: D39 C07/C10–C12; D34 C14; D35 C12; P9 source correction.

Require exact scoped correction power, factual evidence, expected revision and deliberate before/after effective date/state review. General contact editing or a reason string alone is insufficient.

Recalculate from the originally accepted period/zone/semantic basis, never today's policy or a fresh start. Append actual correction history; preserve earlier assertions/acceptance/access history. Corrected endpoint may move either direction or repair a false Expired flag without another initial window or continuation.

All current read/action/display/expiry paths use the corrected effective result. If a continuation already exists, preserve its accepted terms and consumed lineage; do not reactivate predecessor, overlap cycles or silently reschedule successor. A true lineage contradiction enters owner reconciliation.

Correction cannot bypass withdrawal, refusal, erasure or revoked authority; ordinary Continue remains unavailable for active current work. No generic Undo or broad status/date PATCH.

AC28-R36-01: Given exact scoped correction authority, factual evidence and expected revision, when a referral timing correction is reviewed, then before/after effective dates/states are shown; contact-edit permission or a reason alone is insufficient.
AC28-R36-02: Given accepted original period, zone and semantic basis, when correction commits, then the effective endpoint is recomputed from those terms in either direction with attributable history, never from today's policy or a fresh start.
AC28-R36-03: Given a later accepted continuation, when original timing is corrected, then its accepted terms and consumed lineage remain intact without predecessor reactivation or overlap; genuine contradictions enter owned reconciliation.
AC28-R36-04: Given withdrawal, refusal, erasure or revoked authority, when correction is attempted, then it cannot bypass those constraints; there is no broad status/date patch or generic Undo and an active referral is not eligible for ordinary Continue.

REQ28-R37 — Keep referral effects independent

Story US28-R37: As a missionary, I want referrals to remain distinct from contact permission and other work, so that expiry or continuation never creates an unintended ministry action.

Decision basis: D34 C07/C08/C13/C14; D35 C10–C12/C16; D36 C11/C17; D39 C12.

Referral work periods are not contact consent, retention, task deadlines, supporter interest, coaching access or finance. Earlier privacy/source restrictions may end an access path without rewriting the window.

Continuation creates no donor response, new introduction, cultivation reopening, send, interaction credit, automatic duplicate task or revival of completed/cancelled work. Independent promised/planned follow-up follows its own source lifecycle.

Referrals to the same Party remain source-distinct. Merge/reassignment neither combines referral occurrences/history nor transfers another person's history rights. A qualified source collision resolves without another fake edge.

D27/D28 preparation retention does not become referral retention; continuing a new source cycle never resets old personal-data retention or restores held-only/erased content.

AC28-R37-01: Given a referral window, when it expires or continues, then it does not grant contact consent, alter source retention/task deadlines/coaching/finance or imply supporter interest; earlier source/privacy restrictions can still withhold access.
AC28-R37-02: Given successful Continue, when downstream records are inspected, then no donor response, introduction, cultivation reopening, send, interaction credit, duplicate task or revival of completed/cancelled work was fabricated.
AC28-R37-03: Given multiple referral occurrences to one Party or a later merge/reassignment, when relationships are resolved, then exact occurrence/history and another recipient's history rights remain distinct without fake replacement edges.
AC28-R37-04: Given preparation retention or held-only/erased referral content, when a referral cycle continues, then neither preparation deadlines nor old referral-body retention is reset and forbidden content is not restored.

REQ28-R38 — Author an optional starting guide

Story US28-R38: As authorized tenant staff, I want to author one optional starting guide, so that our organization can offer useful suggestions without maintaining a course platform.

Decision basis: D37 C02/C04/C05/C07/C09/C10; P28 guide owner, resource publication owner/P29 custody/P12 access.

Edit title/introduction/suggested content/order and approved destinations; begin blank or from original editable examples. No method, step count, script, quota or outcome is compulsory. Publish requires at least one nonempty audience-safe suggestion.

Each suggestion may contain advice without links, at most one approved resource reference and at most one registered existing workspace entry. No arbitrary internal route/record-ID/mutation payload/script/HTML or separate external-link catalog.

Staff review exact audience safety and rights to resources/material. No copying private record context, restricted commercial curricula or source metadata into a broader guide; no automatic semantic-classifier promise.

Save draft does not offer or modify the live revision. Preview/publish use current curation authority and expected base; Publish changes accepts one coherent whole revision atomically with minimal effect evidence.

AC28-R38-01: Given authorized guide curation, when staff create or edit a draft, then title, introduction, suggestion content/order and qualified destinations are editable from blank or original examples without a compulsory method, script, count, quota or outcome.
AC28-R38-02: Given a suggestion, when validated for publication, then it may be advice-only or contain at most one approved resource and one registered existing workspace entry; arbitrary routes, record IDs, mutation payloads, HTML/scripts and a separate external-link catalog are not accepted.
AC28-R38-03: Given exact audience/resource rights, when staff publish, then at least one nonempty audience-safe suggestion and one coherent revision commit under current authority/base with minimal accepted-effect evidence; draft Save alone never changes the live guide.
AC28-R38-04: Given protected record context or material without rights, when curation is reviewed, then it is not copied into a broader guide and no automatic classifier is claimed to make unsafe text safe.

REQ28-R39 — Use and revisit the optional guide

Story US28-R39: As a missionary, I want to use, skip and revisit the guide freely, so that suggestions help my work without measuring or controlling it.

Decision basis: D37 C01/C03/C05/C06/C11/C12.

Offered guide has one stable Resources entry; dismissible Home/Help links resolve to that same current guide. Home dismissal is user/Tenant-scoped, reversible and persists through routine revision/re-offer without becoming progress.

Any suggestion may be used in any order. No tenant setting or content acknowledgment gates ordinary work. No completion checklist, course sequence, staff/coach progress, streak, behavioral score or automated reminder.

Links navigate only; browsing, preview, prefetch and open do not create tasks, change stage, import contacts, send, give, subscribe or claim an interaction.

Current guide/resource/destination authority is checked before metadata disclosure and at use. Withhold denied target and dependent unsafe wording; retain independently safe advice only where declared conditions prove separation. Otherwise withhold the whole step without hidden numbered gaps/counts.

AC28-R39-01: Given an offered guide, when Maya enters Resources or dismissible Home/Help links, then they resolve the same current guide; dismissal is reversible, user/Tenant-scoped and survives ordinary revision/re-offer without progress tracking.
AC28-R39-02: Given optional guidance, when Maya skips, returns or uses suggestions in any order, then ordinary work remains available without completion/acknowledgment gates, staff/coach progress, scores, streaks or automated reminders.
AC28-R39-03: Given guide browsing, preview, prefetch or navigation, when performed, then no task, stage, import, send, gift, subscription or interaction is created.
AC28-R39-04: Given a destination or resource is no longer admitted, when guide metadata or links are delivered or used, then unsafe targets/dependent wording are withheld; independently safe advice remains only under qualified separation, otherwise the whole step is omitted without revealing hidden numbering/counts.

REQ28-R40 — Disable and re-offer the guide

Story US28-R40: As authorized tenant staff, I want to disable and later re-offer the guide deliberately, so that changes do not affect independent resources or secretly undo my choice.

Decision basis: D37 C07/C08/C10/C12–C15.

Existing/new tenants begin without an offered guide; any seeded examples are draft-only. Deliberate publication is required before discovery.

Disable stops new guide discovery/delivery under current checks, even with invalid unsaved draft. It deletes no resource or independent work and grants no new audience.

Stale save/publish/retry/restore cannot re-offer it; re-offer is fresh authorized deliberate acceptance against current dependencies. Recover prior command outcome separately from current availability.

Reorder works without dragging, and complete curation/reader flows preserve keyboard/focus/status/reflow. No new onboarding vendor, course engine, tracking/URL-unfurl or video dependency.

AC28-R40-01: Given a new or existing tenant without deliberate publication, when the workspace opens, then no guide is offered and any examples remain drafts.
AC28-R40-02: Given an offered guide and an invalid unsaved draft, when authorized staff Disable, then new discovery/delivery stops without deleting resources, changing independent work or requiring the draft to become valid.
AC28-R40-03: Given Disable followed by stale Save, Publish, retry or restore, when processed, then it cannot re-offer the guide; a fresh current-authority re-offer is required and recovery distinguishes previous command acceptance from current availability.
AC28-R40-04: Given keyboard, assistive technology, touch or narrow viewport use, when authoring, reordering or reading, then the complete flow works without drag-only controls or inaccessible status/focus and requires no new tracking, course, unfurl or video service.

REQ28-R41 — Keep contact work native

Story US28-R41: As a missionary and tenant administrator, I want contact work to remain native in this release, so that useful ordinary work does not depend on another fundraising product.

Decision basis: D41 C01–C05/C09/C11/C12/C16; D5; D17; P21/P31/ADR-0097.

Add no P28 external contact-update/contactability resource, feed, subscription, producer, dormant connector or contact-sync switch. Do not add automatic export or contact-refresh workarounds.

Existing D5 permissions can withhold editing while preserving independently permitted reads/staff work and source history. No separate D41 master flag.

The independently governed P21/P31 giving feed retains its exact field floor, default-Off/setup/current authorization/stop rules. Giving credentials/cursors cannot request contact enrichment, new methods or writeback; reject unsupported expansion before protected enumeration while valid giving work remains usable.

D17 intake, qualified communication/print/export and other independent purposes keep their own scope. A correction affecting an already authorized giving projection is not external contact sync. Native contact UI promises neither pending external synchronization nor “nothing ever leaves Asym.”

AC28-R41-01: Given this release, when external capabilities or requests are enumerated, then no P28 contact-update/contactability feed, producer, subscription, dormant connector or sync switch exists and automatic export/contact-refresh workarounds are not introduced.
AC28-R41-02: Given D5 editing is withheld, when native contact work is used, then independently permitted reads, staff work and source history remain without a new D41 master switch.
AC28-R41-03: Given an existing qualified giving feed, when it is configured or invoked, then its independent field floor, default-Off, admission and stop rules remain unchanged; giving credentials/cursors reject contact enrichment or writeback expansion before protected enumeration while valid giving remains usable.
AC28-R41-04: Given native corrections, qualified intake or independent communication/export, when displayed, then truthful owner outcomes are shown without claiming pending contact synchronization or promising nothing ever leaves Asym.

REQ28-R42 — Connect ordinary work without inventing facts

Story US28-R42: As a missionary, I want a connected but truthful daily journey, so that I can progress from preparation or referral to ordinary work without entering the same fact twice.

Decision basis: completeness C01–C03/C06/C08/C12/C16; D1 C10; D4 C05; D34–D39 no-implied-effects; P9/P27/ADR-0183. Detailed task/appointment/Request specifications remain their owning volume.

Within current permissions, preparation/referral can open existing native contact, appointment, task, interaction and P27 Request destinations with safe context reuse. A navigational action creates none of their facts automatically.

Task completion is distinct from recorded encounter, Request response, commitment, gift and send. Restricted preparation acquires no managed-work obligation just because it appears near the queue; managed P27 work retains its next-task-or-owned-exception rule.

Supported negative outcomes, inaccessible contacts, unknown source facts, no coach, optional modules Off and nonfinancial support remain usable ordinary paths. Do not fabricate a gift, send, contact consent or interaction to advance.

Where a composite UI performs separate source actions, show accepted/failed components honestly unless the actual owner contract provides atomicity. One accepted part is never repeated merely to repair another.

AC28-R42-01: Given current permissions, when Maya navigates from preparation/referral to an existing contact, appointment, task, interaction or Request, then authorized context may be reused without creating any of those facts merely through navigation.
AC28-R42-02: Given a completed task, when related domain state is evaluated, then it is not an encounter, response, commitment, gift or send; restricted preparation gains no managed-work duty, while real managed work retains its next-task-or-owned-exception rule.
AC28-R42-03: Given negative outcomes, unknown facts, inaccessible contacts, no coach, optional modules Off or nonfinancial support, when ordinary work continues, then supported paths remain honest without inventing contact consent, money, sends or interactions.
AC28-R42-04: Given a composite action spanning independent sources, when one part succeeds and another fails or becomes unknown, then component outcomes remain truthful unless the owner supplies actual atomicity and repair does not repeat an accepted component.

State and control contract

These are independent source facts, not a universal status enum or new workflow framework.

Source/control	Accepted transition	Effects that must not be inferred
Restricted preparation	Save/edit under current source authority; deliberate D2 share of eligible contact facts	Canonical identity overwrite, shared private history, consent, managed-work enrollment
Preparation working state	Active → Archived; deliberate current-authority Return → Active	Person archive, grant change, canceled/restarted task or retention reset
Ended participation	Terminate exact access and preserve independently owned duties	Automatic successor readership, private export, inactivity-as-departure
Earlier preparation inclusion	Exact eligible same-author/context Resume; one effective inclusion	Copy/new author, auto-unarchive, revived shares/old inclusion from ended participation
Departure retention	Source-confirmed episode → retained-before-deadline → expiry → qualified custody/disposal	Reads/return to login resetting deadline; hold as access; disposal lag as grace
Selected pre-expiry Resume	End selected departure schedule applicability and admit same entry to normal current-work retention	Extending unselected entries, indefinite retention, changing original history
Import	Finalized private input → immutable reviewed plan → bounded row outcomes; cancel/discard/expiry fence future effects	Upload as business success; deleting run as deleting contacts; resume as repeat acceptance
Initial referral	Truthful original event + first deliberate acceptance produces active-if-current, expired-if-ended, or unresolved timing	Created/import date as new introduction; unknown as active/expired; later recording as renewal
Continued referral	Consume eligible expired cycle once; accept new A/E/N terms	New person/introduction, consent, generic status restore, another cycle on retry
Referral correction	Evidence-backed append of current effective result using original timing basis	New initial window, counterfeit continuation, predecessor reactivation after successor
Missionary Continue Off	Fence new missionary acceptance; keep qualified settings editable	Staff grant revocation, deleting history, ending accepted window or stopping expiry
Guide	Draft save separate from publish; deliberate disable/re-offer	Course completion, tasks/sends, resource deletion, stale publish undoing Off
D5 edit permission removed	Deny affected new edits; preserve other valid grants and independent views	Global contact deletion/hidden status, new D41 sync flag or grant copied from role

Implementation decisions and exact owner dependencies

Preparation and inclusion belong to native CRM. Add the smallest bounded P9 preparation/assertion and current-work inclusion contract required to deliver restricted start and D27. Reuse actual qualified mechanisms where present. P4 keeps canonical identity admission/repair; no fake Party/donor/Ministry Assignment foreign-key target, universal cardinality or parallel ACL/history ledger. D1 packet status stays historical; this is an explicit engineering decision of the authorized spec.
Current authority and static projection registration are cross-surface contracts. Register preparation, expired-history, continuation review/result, guide and intake result families in the existing static field-policy source. Conditional author/recipient/history/time logic belongs in the shared resolver. D34 requires only the named narrow expired-referral history exception to the active-relationship-only workspace rule; no ordinary supporter DTO widening.
Native commands use P9 A17 with narrow source-owned recovery evidence. Create/share/archive/return/resume/correct/referral transitions preserve required local atomic source/audit/activity semantics. Do not use payment idempotency headers, provider gates or a generic CRM command journal. P6/P17 own optional D2 notice materialization and current recipient admission separately.
Lifecycle/time extension is source-owned. P9 qualifies original referral evidence, exact lineage, accepted initial/continued windows, historical recipient proof, one-cycle consumption and evidence-backed correction. P12 qualifies exact read/action scopes and current authority fences. New calendar endpoints and Continued elapsed instants must coexist with unchanged retained windows; source kind/semantic-version omissions cannot silently choose a default.
Retention is purpose-specific. Preparation source/privacy owner owns departure/current-work policies, supported finite bounds, holds, primary/derivative copy inventory and restoration evidence. Referral custody is separate. P29/P30 own D17's already-ratified seven-day input window and 24-hour disposal duties; do not reuse those numbers for preparation or referral content.
Import is an exact target profile of shared intake. Amend P30's staff-only reviewer wording for a bounded P28 missionary actor, and P29 for exact private purpose custody. Target owners validate/admit data. Reconcile older P30 shorthand permitting high-band auto-merge with P4/current roadmap: D17 permits none. The adverse-contactability adapter must produce durable authority enforced by actual communication consumers before affected row acceptance.
Guide ownership is bounded P28 content meaning, not public CMS authority. Reuse qualified content/publication primitives after exact audience/availability qualification; draft/live revisions and one coherent current release are required. Resources retain their source publication and P29 bytes. A registered navigation destination does not confer action authority. D12's historical amendment packet status is not silently changed by D37 or this specification.
Preserve selected scope and existing data. No extra external contact feed, no blanket contact-permission backfill, no inference of private/shared/archive/expiry state from legacy statuses, no empty-database assumption. Inventory old readers/writers, source provenance, known/unknown historical timing and policy. Stop incompatible writers before exposing new scope; restore/rollback cannot widen permissions or resurrect content/consumed effects.

Concrete source qualifications required, not broad future-phase dependencies

Required outcome	Exact owner output needed before activation	Independent work that remains useful
Restricted save/share/archive/return	P9 preparation + canonical admission + P12 source/field/history contracts and actual mutation/read qualification	Existing independently authorized CRM/work
Return and retention	P4 original-human resolution; P9 participation/inclusion/departure/correction/disposition; finite privacy profiles; current-history grant	Ordinary current work without any resumption
D2 selected staff notice	Exact P9 event/P6 informational recipient contract/P17 presentation and durable result linkage	Accepted share with truthful notice pending/failed outcome
Contact correction	Eligible field/source inventory and P12 policy path; owner-required destination/contact consequences; roster-rights reconciliation	Read-only permitted facts and independent staff editing
Contact intake	P30 missionary target profile/P29 private custody/parser qualification/P4 matching/P9 target; exact P6 negative-preference adapter where reached	Native manual preparation and already accepted import results
Referral history	P9 qualified ordinary-expiry/historical-recipient producer; P12 minimal purpose projection and retention	Independent current supporter/CRM work
Referral continuation/windows	Native lineage/cycle mutation; exact actor/grant control; two qualified periods; clock/zone/semantic precision; correction/recovery	Existing accepted windows and other admitted referral work
Optional guide	P28 coherent draft/release/disable owner; qualified resource publication/custody; registered navigation targets	All ordinary native work and independently permitted resources

Release qualification must bind each semantic command/projection contract in this volume to its actual version, responsible source owner and activation evidence. A roadmap phase name or a rendered button is not that qualification. Missing support does not remove a required selected outcome from scope.

Phase 28 specification · Part 08/53

Relationships and working context · file part 4

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/relationships.md
Source chunk SHA-256: 0d45fdd12ed55dbaab383756d1c0dd1f5cf54c3012449d1dc765df7653291613

Previous part · Full index · Next part

REQ28-R43 — Operate and contain failures without weakening source rules

Story US28-R43: As an accountable source operator, I want bounded diagnostics and explicit containment triggers, so that privacy, integrity and usability failures are repaired without duplicate work or direct data alteration.

Decision basis: D17 operational table; D27/D28 operational thresholds; D34–D39 operational tables; D41 monitored risks; completeness C15–C19. The domain-owner role must have an assigned on-call or operational person before activation. Technical traces, durable accepted business effects and security audit are distinct; broad telemetry contains no private preparation or contact bodies.

The following source-specific triggers remain normative. They are not reasons to wait before correcting a known safety problem. A numeric deployment budget referenced below must be measured, published with workload/sample assumptions, and qualified before activation; an undefined budget does not permit activation.

Signal	Threshold	Accountable owner	Required response
Unauthorized read/write, cross-scope disclosure, hidden-match signal, revived grant, expired ordinary access or new contact-feed egress	Any one confirmed event	P12/security incident owner with affected P9/P29/P31 owner	Contain exact affected readers/writers/egress and controllable caches, retain minimized evidence, repair through owners and requalify before reopening; preserve lawful independent giving/work.
Duplicate effect/inclusion/episode/cycle/disposition, altered origin or accepted endpoint, lost required audit, count mismatch, overwritten unrelated field or wrong-cycle expiry	Any one confirmed invariant violation	Affected P9/P30 source owner	Fence affected acceptance, reconcile accepted source evidence, preserve history and correct through owner commands with the exact regression case.
Accepted import restriction not enforced by actual recipient gates	Any accepted affected row without matching enforced owner receipt	P6/contact owner	Stop affected outreach/intake, reconcile exact restrictions and qualify real consumers; do not invent global Do Not Contact.
Expired import raw/staging material remains readable or primary disposal is late	Any post-cutoff read; any eligible primary purge beyond 24 hours	P29 operations owner	Deny access immediately, inspect references/holds and per-copy outcomes, perform bounded disposal and retain truthful evidence.
Preparation destroyed despite earlier applicable hold/preservation, or independent record affected	Any one confirmed violation	P9 preparation/disposition owner	Stop destructive work, retain access restrictions, investigate source ordering/copy evidence and recover only through authorized procedures.
Preparation cleanup/copy/restricted-review obligation misses its qualified deadline	Any one overdue obligation	P9 operations and privacy/records owners	Page the responsible operator, retain restriction and reconcile/escalate through the published response deadline; no silent indefinite queue.
Accepted Resume effect cannot be recovered with still-valid access	Any one confirmed unrecoverable effect	P9 service owner	Repair acceptance/result persistence through source authority; never ask for a duplicate preparation.
Continuation acceptance and current projection disagree without an intervening source transition, or recovery ends unexplained	Any one reproducible occurrence	P9/API operations owner	Diagnose source and projection, repair through owners without another continuation.
Unknown source/settings outcome exceeds qualified recovery time	Any one overdue outcome	API on-call owner	Recover safely or provide a definitive currently permitted status and an owned operational escalation; no supporter outreach.
Saved policy unexpectedly invalid/missing, cross-kind readiness blocks an eligible action, or valid date-only/date-line input is rejected/unknown date gets a deadline	Any one confirmed/reproducible occurrence	Tenant administration/P9 product/API owner	Keep dependent acceptance gated, preserve accepted cycles, repair mapping/precision/revision through owner controls without a guessed duration; stop correctness-affected expansion.
Import limit escape, measured envelope breach or source-preset semantic mismatch	Any one confirmed occurrence	P30 runtime/profile owner	Fence/quarantine affected job or preset, retain receipts and safe manual mapping, correct representative fixtures and requalify capacity before re-enabling.
Preparation Resume or retention query/lock/error/backlog budget regression	Two consecutive five-minute windows exceeding the published budget and declared minimum sample size	Platform API/database on-call	Inspect safe traces/plans, restrict rollout/load or affected cleanup while retaining expiry enforcement and mandatory obligations.
Expired-history/continuation query, latency or recovery budget regression	Three consecutive five-minute windows exceeding the published qualified budget	API/SRE owner with P9 query owner	Inspect scoped query/lock/load evidence, contain expensive work and remeasure without weakening authorization.
Separate-period/original-date request, import or recovery budget breach	Any measured breach of its published G3 budget	API operations owner	Limit affected work or stop expansion, inspect plans/lock/backlog evidence and restore the budget before expansion.
Repeated history projection/permission repair for one incident	Three failed safe attempts or any terminal repair failure	P9 operational owner with P12 support owner	Stop repeated retries and route an owned exception through existing operations; do not reopen records to repair display.
Critical privacy/retention/Resume misunderstanding in qualification, or repeated substantiated pilot misunderstanding	One critical pre-release misunderstanding; two distinct substantiated pilot reports	P28 product/UX owner	Block release or pause expansion, correct the flow/copy and repeat representative tests without collecting private-content surveillance.
Unsafe referral meaning, Off/consent/recovery/date interpretation or reproducible accessible/phone blocker	Any one credible unsafe misunderstanding, validated support/usability incident or reproducible blocker	P28 product/design and shared accessibility owner	Block/contain affected rollout, correct and repeat the whole journey before expansion; do not add settings reflexively.
Import interpreted as sharing, subscribing or verifying contacts	Any observed qualification occurrence or supported production report	P28 product/UX owner	Correct copy/flow and repeat the affected task test before treating intake as qualified.
Lost guide publication, stale re-offer or unaudited availability effect	Any one verified invariant breach	P28 guide engineering owner	Stop affected mutations, recover through source history and requalify concurrency/replay without deleting independent work.
Guide resource or entry is withdrawn/invalid	Any detected unavailable destination	Tenant authorized curator; platform owner for resolver fault	Immediately withhold unsafe target and show one actionable existing-management maintenance notice; no user nag or automatic replacement.
Repeated confusion about guide optionality, return path or draft/publication	Same failure in two independent usability sessions or support reports	P28 product/design owner	Correct wording/placement and test the actual task without adding mandatory walkthroughs or completion tracking.
Shipping state falsely reports Synced, Erased or Saved	Any one reproducible report	P28 product owner and source owner	Reconcile accepted truth, correct state/copy and rerun the affected journey.

AC28-R43-01: Given any trigger above crosses its stated threshold, when operations processes the signal, then the assigned owner executes the listed containment/repair response without waiting for a broader trend or weakening current authority.
AC28-R43-02: Given activation is requested, when qualification is reviewed, then actual source adapters, finite supported bounds, numeric workload/recovery budgets, minimum samples, copy-disposal evidence and accountable on-call ownership are recorded; missing evidence gates the dependent capability rather than reclassifying a required journey as optional.
AC28-R43-03: Given a restore, rollback, retry or repair, when normal reads and jobs resume, then newer restrictions, dispositions, exact accepted cycles/effects and current grants remain authoritative and no private bodies are placed into broad logs to diagnose the issue.
AC28-R43-04: Given a representative missionary/staff or accessibility test exposes a listed critical misunderstanding or task blocker, when release is evaluated, then that affected journey does not activate until corrected and retested; vendor examples and planning models are not substitutes for this evidence.

Testing decisions and release evidence

Tests should assert externally observable user/domain outcomes at the highest practical source/API-plus-projection seam; use real database roles and concurrency where authorization or atomicity is the claim. UI tests then prove the complete job, not snapshots of private implementation fields. Existing P9 A17 source changes, current contact-correction tests, qualified field-policy tests, common Tasks Hub consumer tests and import/retention owners are the extension seams; do not add one duplicate test framework per screen.

Positive journeys: new eligible restricted save; canonical reuse without disclosure; deliberate staff share with zero/selected notices; tenant-authorized selected contact correction; archive/find/return; leave/return/selectively resume; contact import review/partial acceptance/recovery; initial current/late/unknown referral; expired view/Continue; guide draft/publish/disable/re-offer. Each must persist and reload through real source authority, not merely prove denials.
Negative authority matrix: other Tenant, other ministry/current activation, wrong original author/historical recipient, denied fields/history, view-without-edit, settings-without-content, missionary Off versus staff independent lane, protected records, hidden/absent differential, raw API/table/RPC/storage/privileged route bypass. Test old/resulting-state ownership changes and service-role calls.
Concurrency and uncertain outcomes: save versus correction/revocation; share/notice materialization; archive versus return/share; resume versus expiry/disposal/hold; departure/policy late ordering; row import/cancel/lease reclamation; competing continuation actors and transport keys; stale accepted retry after a later cycle; guide publish/Disable/re-offer; source accepted but response/refresh failed. Confirm one business effect and honest current state.
Boundary proof: D17 actual bytes/expanded ZIP/member/cell/row/text/column N−1/N/N+1, repeated/blank columns and formula caches; original versus finalized upload timing; deadline equality; no sliding retry extension. New referral one-day/inclusive month/year/leap/DST/date-line/missing-midnight/repeated-midnight/skipped-date cases; Continued elapsed 24-hour semantics and time-after-lock-wait. Legacy accepted endpoints survive changed settings/timezone data.
Migration/restore: unknown origin/author/precision/policy remains unresolved, never guessed; historical restrictions precede reopened reads; new/old clients cannot omit current kind/revision checks; imported/history copies do not revive erased or ended source effects; interrupted disposal outcomes remain honest. Preserve exact accepted facts and existing valid grants.
Complete UX proof: representative missionary and staff participants on phone/desktop, slow/interrupted connection, keyboard/screen reader/zoom, long/RTL names and non-US address formats. They can explain restricted versus shared, notification versus access, archive versus deletion, current versus earlier preparation, Resume retention effect, New calendar versus Continued elapsed period, Expired versus refusal, recorded versus active, guide optionality and disabled behavior. Any critical privacy/false-success/wrong-context interpretation blocks release.
Performance/operations: production-shaped authorized pagination beyond current source caps; query plans and rows scanned/returned; bounded parser/disposal/import work and fairness; exact source lock contention; batched guide destination resolution. Numerical latency/concurrency budgets must be measured and published for the activation cohort. Do not claim 10,000-row capacity or responsiveness from a small model.

Explicit exclusions and non-effects

No separate person master/private CRM, new generic task engine, user-defined permission/retention/workflow builder, per-record referral duration, mandatory guide or coaching/course completion, staff access to private preparation on departure, automatically merged people, bulk contact overwrite, auto-restoration, automatic renewal, source-generic Undo, contact-update feed, direct email/provider transport, unsupported offline replay, or new money/consent/encounter facts is introduced. These exclusions preserve independently governed existing operations rather than disabling them globally.

Phase 28 specification · Part 09/53

Finance and stewardship · file part 1

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/finance-stewardship.md
Source chunk SHA-256: b64a030668473491253bd73cbc4befca1301840b8186ad057dbf30209801dd02

Previous part · Full index · Next part

Phase 28 — Finance, goals and stewardship

This volume defines missionary workspace consumption of financial truth, optional
support goals and personal stewardship work. It does not create a financial
ledger, commitment engine, recognition store, intake queue or second task system.
Financial and source contracts remain with Phases 13–16 and 21; relationships,
responsibility and shared tasks remain with Phase 9; current authority and
projection remain with Phases 10 and 12. Phase 27 continues to own Requests and
appeals. Requirements below amend specific owner behavior where expressly stated.
Their publication is a planning contract, not evidence of an implemented source.

REQ28-F01 — Distinguish support facts and relationship meaning

Story US28-F01: As a missionary, I want to understand my permitted support
information without confusing money, commitments or relationships, so that I can
decide what to do confidently.

Decision basis: D16; D19; D21; D40; completeness C04/C05; P14 H3–H5;
P16; P21 D8–D12; P27 REQ27-F78/F79.

The workspace SHALL distinguish received monetary support, qualified recognition,
commitment expectations, monthly-equivalent planning, approved need, workspace
goal, Finance-confirmed balance and relationship facts. It SHALL identify amount
basis, exact ministry/project, Legal Entity, currency, applicable period and
source freshness where needed to interpret a figure. A missing, denied,
incomplete or unavailable value SHALL NOT become zero. A recorded gift SHALL NOT
prove contact permission, an active commitment or cultivation enrollment.

AC28-F01-01: Given a received gift awaiting commitment matching, the
permitted view shows the received fact and unresolved match separately; it does
not mark the gift missing or the commitment fulfilled.
AC28-F01-02: Given different currencies or overlapping legal/recognition
lenses, the view presents qualified separate measures and never adds them into
an unlabeled total or silently converts currency.
AC28-F01-03: Given no approved Plan or no goal, the view states that absence
without a zero target, a funding percentage or an inferred finance requirement.

REQ28-F02 — Preserve continuing relationships independently of giving recency

Story US28-F02: As a missionary, I want continuing financial and nonfinancial
relationships to stay available while independently authorized, so that an older
gift does not make a person disappear from my work.

Decision basis: Completeness C04; P9 supports_policy_v1; P14 H3/H4/H5.

The native relationship workspace SHALL admit independently authorized continuing
relationships without deriving their lifespan from financial recency. P14's
supports_policy_v2 financial recognition roster remains its own read model and P9's named
supports_policy_v1 remains unchanged. P14 historical inclusion SHALL retain its
own 365/730-day policy, but a historical exclusion SHALL NOT override an
independently qualifying current Phase 16 commitment. Display copy SHALL describe
financial recency neutrally; it SHALL NOT label the person or relationship
“lapsed.” Neither pathway grants contact fields or indefinite data retention.

AC28-F02-01: A continuing nonfinancial relationship with no recent gift
remains in the authorized workspace while a financial-recency view accurately
reports its lack of recent recognized giving.
AC28-F02-02: A supporter with a qualifying current typed commitment remains
included through that commitment path after the historical-only 730-day limit.
AC28-F02-03: Removing financial-history inclusion changes no independent
relationship, contact authority, commitment, task or retention policy.

REQ28-F03 — Qualify the exact financial source and audience

Story US28-F03: As a missionary, I want financial information to reflect my
actual authorized scope, so that a shared donor or designation never exposes
another ministry's information.

Decision basis: D19–D22; D29–D33; P13/P14/P16; completeness C04/C05.

Every financial projection or follow-up qualifier SHALL resolve the exact Tenant,
Legal Entity, canonical Party, typed Phase 9 Ministry Assignment or Ministry
Project, relevant monetary lines, currency and material owner revisions. A login,
worker name, household, Page, source code, legacy donor assignment or visible list
is not that identity. P14 SHALL supply subject-qualified recognition; Phase 28
SHALL NOT spread header credits across subjects, infer DAF/church members, or add
recognition to legal money. Current privacy and field floors SHALL apply before
enumeration, aggregation, ranking and action eligibility. P14's financial roster
floor does not become a contact directory through Phase 28.

AC28-F03-01: One split contribution supporting two ministries yields only
the viewer's qualified portion and permitted reason; neither other amounts nor
omitted-row counts are inferable from totals.
AC28-F03-02: Multiple lawful recognition paths for one Party and business
gift produce one applicable gift-purpose member, without multiplying money.
AC28-F03-03: A missionary's relationship permission does not expose staff
financial ratings, private remittance provenance or P14-prohibited contact
fields; an independently authorized contact surface retains its own boundary.

REQ28-F04 — Keep incomplete sources honest and independently recoverable

Story US28-F04: As a missionary, I want unavailable financial conclusions to
be explained without blocking unrelated work, so that I can continue safely.

Decision basis: D16; D19–D22; D31; D40; E7 reconciliation.

Automatic financial conclusions SHALL require complete, coherent owner-qualified
coverage for the exact conclusion. A capped list, empty response, stale cached
number, maximum of unrelated cursors or missing match SHALL NOT supply that proof.
Only the affected measure, qualifier or source lane SHALL be held when evidence is
unavailable. Qualified money facts, manual work and unrelated source lanes SHALL
continue. Owner repair SHALL preserve the original live/history cohort and
business identity; processing time is never a new gift date or activation event.

AC28-F04-01: A first-support conclusion remains held for incomplete history
even when the current visible gift list contains one gift; another fully
qualified subject continues independently.
AC28-F04-02: An unqualified received-toward-appeal association displays
Unavailable while permitted received money and nonfinancial Request work remain
usable; the app does not invent an association from amount, date or source code.
AC28-F04-03: Repairing a read model restores qualified facts without
reposting money, generating historical follow-up or duplicating an admitted
business effect.

REQ28-F05 — Offer simple, scoped goal-management controls

Story US28-F05: As authorized staff, I want to choose who manages a support
goal, so that the organization can delegate editing without changing finance or
publication permissions.

Decision basis: D16 C01–C06.

One organization default SHALL initially be Staff-managed. The existing
settings surface SHALL offer Staff-managed or Missionary-managed. An exact typed
ministry/project subject MAY explicitly use the organization default or either
supported override; inheritance SHALL show the effective result. There is no
implicit household, project-member or Page cascade. Current goal-write authority
and the effective management policy are both required. Policy administration,
goal reading and goal writing SHALL remain independent capabilities. A goal is
optional; no actor must create one to use the workspace.

AC28-F05-01: A new organization with no explicit override permits only
currently authorized staff goal writers; a missionary sees the permitted goal
and Staff-managed explanation without a misleading edit control.
AC28-F05-02: Setting an exact subject to Missionary-managed permits an
independently authorized missionary writer there and changes no sibling subject
or shared project's identity.
AC28-F05-03: A policy administrator without goal-read permission can change
the permitted policy without receiving a protected goal amount in the result.

REQ28-F06 — Keep one goal authority with truthful units and history

Story US28-F06: As an authorized goal editor, I want a clear goal and its
history, so that changes are meaningful and do not create competing targets.

Decision basis: D16 C06–C10; ADR-0208; P13 campaign goals; P21 planning.

A logical goal SHALL have one authoritative head and immutable attributed
versions. Its identity SHALL distinguish exact subject, purpose, currency and
goal/period meaning. Recurring support and special-purpose goals may coexist;
one shared project does not gain a separate authoritative goal per member.
Campaign/Designation goals SHALL remain Phase 13-owned rather than being copied
to enable missionary editing. Newly entered amounts SHALL be positive, finite,
within the qualified supported range and exactly representable in that currency.
Blank, end, absence and legacy zero SHALL remain distinct. Ordinary edits are
prospective at acceptance, with no implicit backdating, proration, currency change
or scheduled adjustment.

AC28-F06-01: Editing a shared project's goal through two permitted surfaces
resolves the same logical identity and history rather than two current heads.
AC28-F06-02: An unsupported fractional minor unit, overflow, negative or
zero new goal is rejected without coercion, rounding or a default USD currency.
AC28-F06-03: Changing a goal creates a prospective version; prior dated
results retain their applicable goal version and the old version stays
attributable and readable only within current permissions.

REQ28-F07 — Save goals once and handle conflicts honestly

Story US28-F07: As an authorized goal editor, I want a single reliable Save
and understandable recovery, so that a slow connection cannot overwrite someone
else's change or create duplicate history.

Decision basis: D16 C09–C13.

A goal save SHALL bind the reviewed goal identity, base revision, normalized
payload and semantic operation identity. Accepted version, head, required
history/audit and result SHALL commit coherently. Relevant concurrent edits and
current authority SHALL be revalidated at acceptance. Same-intent retry SHALL
recover its original result under current disclosure rights; changed payload
under that identity conflicts. An unchanged save SHALL not create another version.
Turning missionary editing Off preserves goal/history and fences future
unauthorized saves without changing goal visibility or publication.

AC28-F07-01: Two editors saving from the same base cannot silently replace
one another: one accepted change is retained and the stale conflicting editor
receives a truthful refresh path with permitted unsaved input preserved.
AC28-F07-02: A lost success response followed by retry creates one version
and returns the accepted result; a newer version is not overwritten.
AC28-F07-03: When policy revocation wins acceptance order, a stale missionary
save fails without changing the goal; when Save wins, later revocation preserves
the accepted version and current reads still enforce present authority.

REQ28-F08 — Show qualified progress without inventing finance

Story US28-F08: As a missionary, I want support progress with clear meaning,
so that I can distinguish what is planned, committed and received.

Decision basis: D16 C14–C18; P16; P21 D8–D12; P27 F78/F79.

Every progress comparison SHALL identify a compatible numerator and denominator
with exact scope, Legal Entity, currency, period and basis. It SHALL use complete
qualified source coverage, not a display page or mutable profile counter.
Monthly-equivalent commitments, dated expected occurrences and received money
SHALL remain distinct. Absent, zero, denied or incompatible targets SHALL produce
no ratio. Valid over-goal progress SHALL remain truthful rather than being capped
at 100%. Source corrections update current derived results without rewriting a
dated historical artifact or its goal version.

AC28-F08-01: A 120-unit qualified received amount against a compatible
100-unit goal displays 120% with the actual amounts; an incompatible currency
produces no combined percentage.
AC28-F08-02: A recurring monthly-equivalent figure does not sum this month's
received gifts or claim those commitments are cash available to spend.
AC28-F08-03: A source refund changes the current qualified numerator, while
an issued historical report retains its stated historical basis and links to
permitted correction context rather than silently changing bytes.

REQ28-F09 — Reuse an approved Plan only by deliberate copy

Story US28-F09: As an authorized goal editor, I want to copy a compatible
approved Support Plan amount when helpful, so that I do not retype it or create a
second planning process.

Decision basis: D16 C15–C17; P21 D8–D12.

Copy from approved Plan SHALL be optional and available only with independent
current Plan-read and goal-write authority for the exact compatible scope,
currency and amount basis. The editor SHALL review the candidate amount and exact
approved version before saving. The accepted goal SHALL retain immutable copy
provenance. Later Plan changes SHALL NOT synchronize the goal, and later goal
changes SHALL NOT amend the approved Plan, budget, balance, reserve or
compensation. Manual goal use SHALL remain possible without any Plan.

AC28-F09-01: Copying a compatible approved version saves the reviewed goal
and provenance without modifying the Plan; a later Plan version leaves that
goal unchanged.
AC28-F09-02: A denied, unapproved, unavailable or differently scoped Plan
supplies no amount, default or inferred goal, while ordinary permitted manual
goal entry remains usable.

REQ28-F10 — Separate goal editing, disclosure and public publication

Story US28-F10: As a missionary, I want to know where my goal appears, so that
an internal edit does not unexpectedly publish private planning information.

Decision basis: D16 C17–C20; P21; P22 D6/D13.

Internal goal Save SHALL NOT publish a Page, alter a released public goal version,
share a coach view, create a task, send a notification or change finance. Public
adoption SHALL use the existing authorized publication/release boundary and exact
safe version. Field Account balances, assessments, reserves, availability and
compensation SHALL NOT become public support progress by resemblance or linkage.
Unavailable private data SHALL be safely suppressed rather than replaced by zero.

AC28-F10-01: Saving an internal goal leaves the released public Page and
its adopted version unchanged until a separate authorized publication action.
AC28-F10-02: A user unable to read the internal amount cannot retrieve it
through public progress, search, export, cache or an edit-policy response.
AC28-F10-03: The edit flow clearly identifies the goal's scope and explains
that Save changes the workspace goal; pilot users can distinguish that effect
from approved finance and public publication without another confirmation step.

REQ28-F11 — Admit first-support work from complete subject history

Story US28-F11: As a missionary, I want a first-support follow-up when someone
first gives qualifying recorded support to my ministry, so that I can respond
without treating their support elsewhere as disqualifying.

Decision basis: D19 C01–C10.

The native first-support purpose SHALL require positive qualified monetary
support for the exact typed ministry/project subject, complete owner-certified
recorded history and coherent financial, recognition, attribution and canonical
identity revisions. It SHALL not claim first-ever support or a new donor to the
organization. Pledges, attempts, unsupported pending payment, valuations and
nonpositive corrections are not received support. Subject identity survives
worker succession, names, multiple designations, Page changes, years and currency
changes. Genuine prior support through a qualified recognition path remains
history even where that path never allowed contact.

AC28-F11-01: A donor's first qualified gift to this subject may create work
even after gifts to another subject; a second designation mapped to the same
subject does not create another first-support purpose.
AC28-F11-02: Simultaneous first gifts produce one purpose using qualified
source history, without treating ingestion order as gift chronology.
AC28-F11-03: A promise, failed charge, incomplete import or empty capped
history produces no verified first-support conclusion or automatic task.

REQ28-F12 — Preserve first-support purpose identity through repair

Story US28-F12: As a missionary, I want first-support work to survive retries
and truthful corrections without repeating completed work, so that my queue is
reliable.

Decision basis: D19 C08–C12.

Durable coverage SHALL be keyed to the source-certified canonical supporter,
typed subject and first-support purpose within the tenant/entity scope. Source
event IDs, responsible worker and display task IDs are lineage, not substitute
business identity. Admission SHALL retain its durable task-projection intent.
Historical imports establish baseline without catch-up tasks. A source-invalid
unhandled admission SHALL be withdrawn without recording human completion;
qualified correction may restore that original live purpose or establish its
true later live first support only when no genuine prior support or human handling
contradicts it. A refund of genuine prior support never restarts firstness.

AC28-F12-01: Repeated provider deliveries, responsibility changes and
optional workflow consumption produce at most one active first-support purpose.
AC28-F12-02: A corrected mistaken-person allocation preserves its audit
history and permits only owner-proved eligible repair; a historical import or
replay alone does not create new personal work.
AC28-F12-03: Canonical identity merge reconciles active purpose coverage
while retaining both real prior interactions; it never creates a third welcome
task or silently relabels protected history.

REQ28-F13 — Make personal first-support completion truthful

Story US28-F13: As a missionary, I want to finish or decline personal
follow-up without filing a report, so that simple stewardship remains simple.

Decision basis: D19 C06/C07/C11/C13/C14; ADR-0183.

First-support work SHALL use the shared closed Independent follow-up task
contract. Done and Not needed are deliberate human dispositions, not
evidence of a conversation, send, receipt, financial resolution or permanent
suppression of other purposes. No narrative is required. Optional actual
interaction recording retains its own audience, occurrence and truth. A source
correction SHALL preserve a separately accepted call, promise or other undertaking
and reconcile any Phase 27 next-action requirement; opening, claiming or
commenting alone does not create such an undertaking. Contact actions require
independent current purpose/channel authority.

AC28-F13-01: Marking Done closes the reviewed personal purpose without
sending a message, inventing an interaction or changing money or consent.
AC28-F13-02: Conditional Undo appends a correction only when the latest
disposition, source state and authority remain compatible; it cannot erase
an actual conversation or recall a message.
AC28-F13-03: An anonymous or contact-ineligible recognition path creates
no actionable named-contact task or disabled-button substitute; independently
permitted financial awareness remains available.

REQ28-F14 — Use explicit special-gift reasons

Story US28-F14: As a missionary, I want each special-gift follow-up to explain
why it exists, so that I can act without guessing what an algorithm inferred.

Decision basis: D21; D22; D29–D31.

Automatic special-gift eligibility SHALL use only the independently qualified
purpose/amount contracts below. Prior-giving comparisons SHALL NOT decide task
admission, unsolicited suggestions, badges, default prioritization or notices.
The exclusion includes relabeling a historical-comparison score, import marker,
model output or memo as a generic special-gift flag. Ordinary one-time payment,
missing commitment, catching up or paying in advance does not prove additional
support or excess. Authorized historical charts and deliberate user sorting may
remain, without becoming an automatic reason.

AC28-F14-01: Holding the qualifying current source facts fixed while
changing prior-giving comparison context leaves automatic purpose admission,
unsolicited highlighting and default priority unchanged.
AC28-F14-02: Every visible reason identifies the actual permitted fact,
such as donor-stated additional support, a specific one-time need, a configured
amount or support above a recorded commitment; it does not imply donor intent
from amount alone.

REQ28-F15 — Group compatible special gifts in one current task

Story US28-F15: As a missionary, I want compatible special gifts from one
supporter together, so that I can handle them once without losing their evidence.

Decision basis: D20 C01–C05/C09; D21.

There SHALL be at most one current compatible special-gift task for the same
Tenant, Legal Entity, typed subject, qualified follow-up Party, completion
authority and accountable responsibility scope. Each business contribution,
Party, subject and purpose SHALL have separate stable membership; multiple lines,
reasons, recognition paths, source revisions or deliveries do not multiply it.
Distinct equal-value/date gifts remain distinct. Shared tasks own membership and
reviewed disposition; Phase 28 owns purpose admission, not a second task ledger.
An old task surviving only for an independent undertaking does not automatically
remain the current special-gift group.

AC28-F15-01: Concurrent eligible gifts for one compatible scope join one
current task with distinct gift members and clear factual reasons.
AC28-F15-02: A new eligible gift after the prior special-gift group finished
creates or joins the next current group without reopening handled members.
AC28-F15-03: Different subjects, Legal Entities, Parties or incompatible
responsibility/authority scopes remain separate even when names or amounts
match.

REQ28-F16 — Complete exactly the reviewed gift members

Story US28-F16: As a missionary, I want Done to cover exactly the gifts I
reviewed, so that a new arrival or hidden item is never silently handled.

Decision basis: D20 C06–C10/C17; D32.

A disposition SHALL bind a nonempty definite inspectable set of member identities,
material source/dependency revisions, purpose, responsibility, completion
authority, intended outcome and semantic intent. The server SHALL revalidate that
scope. A material selected change rejects the whole new disposition without
partial coverage; unrelated additions neither invalidate unchanged reviewed work
nor become handled. Exact coverage, history, receipt and residual task state SHALL
commit atomically. Same-intent recovery returns the original result rather than
reevaluating today's group. Hidden/unloaded members SHALL not be silently selected
or disclosed through residue counts.

AC28-F16-01: When gift C arrives while Maya reviews A and B, completing A
and B succeeds if their relevant facts remain valid; C stays actionable in the
current group and is never included in that completion receipt.
AC28-F16-02: A relevant correction to B before acceptance rejects the
entire A/B disposition with no newly completed subset and offers a fresh
permitted review.
AC28-F16-03: After a lost completion response, retry returns exactly its
accepted coverage; changing the selected set under the same operation identity
conflicts.

REQ28-F17 — Correct grouped work without erasing independent obligations

Story US28-F17: As a missionary, I want corrected financial reasons and
mistaken task dispositions handled clearly, so that valid remaining work is not
lost or duplicated.

Decision basis: D20 C08/C11/C12; D21; D32.

Source corrections SHALL affect only dependent unhandled automatic reasons or
members. Independent promises, actual interactions, human dispositions and
historical financial evidence remain. A qualified correction may restore an
originally live unconsumed gift-purpose under current eligibility; replay,
historical reclassification or a criterion change alone cannot restore handled
work. Conditional Undo SHALL resolve the current compatible group and preserve
correction lineage rather than reopening a second current copy. If this viewer
has no remaining authorized actionable work, their queue projection SHALL clear
without claiming hidden work is terminal.

AC28-F17-01: Withdrawing one invalid reason leaves another qualified reason
and any separately promised call intact; no automatic human Done is recorded.
AC28-F17-02: Undo of eligible handled members restores them into the
existing current compatible group when one exists and retains the original
task's historical receipt.
AC28-F17-03: Conflicting intervening handling returns a truthful conflict
and the existing authorized correction path, without changing money or sends.

REQ28-F18 — Confirm donor-stated additional-support purpose

Story US28-F18: As an authorized missionary or staff member, I want to record
an explicit additional-support instruction in one action, so that an eligible
received gift produces understandable follow-up.

Decision basis: D29.

Authorized staff and missionaries, when the organization grants the exact
capability, MAY confirm an explicit donor or authorized representative statement
that an eligible positive received gift or exact portion is additional support.
The capability SHALL be distinct from task editing, gift reading, financial
mutation and interaction authorship. One deliberate contextual Save SHALL record
and confirm minimal attributable evidence; no routine second reviewer, private
message body, essay or new checkout question is required. Qualified structured
instructions or a truthful authorized recorder attestation SHALL bind source,
Party/representative standing, method, occurrence precision, recorder and relevant
revisions. This assertion grants no financial allocation or contact authority.

AC28-F18-01: A permitted actor recording a donor's explicit instruction
against a qualified live gift yields the factual reason Donor-stated
additional support and no money, commitment or receipt change.
AC28-F18-02: A larger gift, nonrecurring payment, generic memo or actor
lacking the confirmation capability cannot establish this purpose.
AC28-F18-03: The first valid later confirmation may qualify still-unhandled
originally live money; old handled work or history-only acquisition does not
become a fresh automatic gift-purpose.

REQ28-F19 — Keep purpose portions exact and corrections source-owned

Story US28-F19: As an authorized purpose recorder, I want partial-gift
instructions represented honestly, so that a purpose does not accidentally apply
to the whole gift.

Decision basis: D29; D30; D31; ADR-0208.

A purpose SHALL identify the entire qualified gift scope or an exact supported
positive same-currency portion established by evidence. A purpose amount is not a
financial allocation or second balance. Multiple evidence records or portions
SHALL not duplicate the gift-purpose member. Ambiguous portions, unsupported
precision, cross-currency values and portions exceeding qualified source money
SHALL be rejected or held for source resolution without guessing. Original donor
instruction and its provenance remain distinct from currently surviving monetary
coverage. An ambiguous mixed partial reversal SHALL hold only the affected
reason; Phase 28 SHALL not prorate it itself or copy protected care context.

AC28-F19-01: An explicit 25-unit additional portion of a 100-unit qualified
gift records that portion without claiming the entire gift or applying 25 units
to a commitment.
AC28-F19-02: A partial return lacking evidence about the purpose portion
produces an unresolved affected reason, not a fabricated surviving amount;
another independently valid reason remains usable.

REQ28-F20 — Offer tenant-controlled one-time-need follow-up

Story US28-F20: As authorized staff, I want to offer follow-up for gifts to a
specific one-time need, so that the organization can support that workflow only
when useful.

Decision basis: D30.

One organization-wide One-time-need gift follow-up control SHALL start Off.
There are no per-need, donor, missionary or currency exceptions. Enabling SHALL
use the existing automation-management capability and required preview, inert
test and recorded activation; the ordinary flow presents one understandable Turn
on action. The test SHALL create no real gift, task or outward message. Eligible
positive received gifts or exact portions require a documented donor-accepted
specific bounded need, confirmed through the exact purpose capability by
authorized staff or missionaries when permitted. “One-time” describes the need,
not the payment count, campaign end or default designation. Existing qualified
Request/appeal context is reused where applicable; no invented appeal or universal
need registry is required.

AC28-F20-01: A qualified vehicle-repair gift admitted under an enabled
policy shows Gift for vehicle repairs, without requiring additional-support
wording, mathematical excess or an amount threshold.
AC28-F20-02: When the detailed need is private, the permitted reason is
Gift for a one-time need; private title or context is not exposed.
AC28-F20-03: Changing a need title, closing a funded need or tagging a
normal gift does not manufacture or invalidate its accepted donor meaning.

REQ28-F21 — Apply one-time-need policy changes prospectively

Story US28-F21: As authorized staff, I want turning one-time-need follow-up
Off to have a predictable effect, so that settings do not erase accepted work or
replay old gifts.

Decision basis: D30 C04–C08.

Policy revisions SHALL preserve attributable history and authoritative admission
order. Eligibility binds the first owner-certified live received event and any
first later purpose confirmation within the same enabled interval. Off ends
admission for unadmitted candidates in that interval; accepted purpose intents,
task materialization and qualified repair of their unconsumed reasons survive.
Re-enabling starts a new interval and SHALL not replay an Off interval or
historical gifts. Other independently required reasons and manual work remain
available. Policy uncertainty SHALL not authorize new admission.

AC28-F21-01: If purpose admission wins the race with Off, the accepted task
still materializes once; if Off wins, the stale candidate is not admitted.
AC28-F21-02: Re-enable does not revive an unadmitted gift from the previous
interval, while a genuinely new qualifying live gift uses the new interval.
AC28-F21-03: Turning this policy Off does not disable confirmed-excess,
first-support or independently enabled amount-based reasons.

REQ28-F22 — Configure an optional inclusive amount rule

Story US28-F22: As authorized staff, I want a simple optional amount rule,
so that gifts meeting the organization's threshold can receive follow-up without
guessing from previous giving.

Decision basis: D22.

One organization-wide amount-based rule SHALL initially be Off with no suggested
threshold. Staff MAY configure one positive exact supported threshold per
qualified currency through existing automation-management controls. A currency
without a configured amount SHALL supply no amount reason. There are no donor or
subject overrides, FX comparison, cumulative-history threshold or percentage rule.
Qualification SHALL use greater than or equal to the threshold against one
contribution's exact Party/subject/currency scope: qualified relevant monetary
allocations excluding fee-cover and unrelated support, before processor fees or
Field Account assessments, after effective monetary corrections; or the exact
P14-certified subject-recognition basis backed by that eligible money. Those
lenses SHALL never be added or arbitrarily prorated from a header credit.

AC28-F22-01: A configured threshold of 100 admits a qualified basis of 100
and rejects 99.99 in a currency supporting cents; unrelated allocation and
charitable fee-cover do not push the gift across that threshold.
AC28-F22-02: An unconfigured currency, noncash valuation, expected matching
gift, payout balance or aggregate of earlier gifts produces no amount reason.
AC28-F22-03: Configuring or removing a threshold changes no other qualifying
purpose and offers no missionary-facing amount settings.

REQ28-F23 — Freeze the amount rule at its proper live boundary

Story US28-F23: As a missionary, I want amount-based work to retain the rule
that actually admitted it, so that later settings changes do not rewrite my queue
or create historical work.

Decision basis: D22.

The source SHALL capture the relevant policy at the first owner-certified eligible
live received/support boundary independently of threshold success and worker or
recognition delay. A first genuine finality event may establish that boundary;
late processing of already eligible money does not. Changed thresholds apply
prospectively. Off or removal of one currency ends that unadmitted interval;
accepted intents and source-qualified correction of originally admitted,
unconsumed work retain their original rule. Re-enabling never revives an old held
or Off cohort. Conclusively invalid corrected reasons are withdrawn; uncertainty
is not zero and handled coverage does not restart.

AC28-F23-01: A gift whose qualified live boundary preceded a threshold
change retains the captured rule despite delayed recognition or task dispatch.
AC28-F23-02: Removing EUR leaves an accepted EUR intent and its materialization
recoverable, ends unadmitted EUR candidates and preserves a continuous USD rule.
AC28-F23-03: A correction re-evaluates the captured rule and causal source
facts without applying today's lower threshold or admitting historical money.

REQ28-F24 — Recognize any source-confirmed positive excess

Story US28-F24: As a missionary, I want confirmed support above a commitment
to have a factual reason, so that even a small real excess is handled consistently.

Decision basis: D31.

Any eligible strictly positive excess in the currency's exact supported minor
unit SHALL qualify without a minimum, percentage, epsilon or tenant amount
setting. Phase 16 SHALL own a bounded comparison association and per-gift excess
certificate distinct from fulfillment application capacity. The association SHALL
bind the entire compared portion to lawful source lineage and the exact recurring
occurrence line or whole fixed-pledge designation-line scope, including applicable
future named expectations and valid unscheduled capacity, within one exact Tenant,
Legal Entity and currency; no FX or cross-scope sum is permitted. Matching guesses,
unmatched residual, a reduced pledge total, one paid installment or capped
applications cannot certify excess. Phase 28 consumes the certificate and SHALL
not allocate, reserve or route money.

AC28-F24-01: One positive supported minor unit with a valid certificate
supplies Support above the recorded commitment, regardless of D22 or D30
settings; zero and negative excess do not.
AC28-F24-02: A fixed pledge with remaining valid future capacity does not
produce excess merely because its current installment is filled.
AC28-F24-03: An unmatched or ambiguous gift remains unresolved for this
reason and never becomes “all excess” because no comparison is available.

REQ28-F25 — Conserve excess across gifts, terms and corrections

Story US28-F25: As a finance source owner, I want excess certificates to
conserve real support across ordered gifts and corrections, so that personal
follow-up never rests on a duplicated or retroactively invented amount.

Decision basis: D31 C01–C24.

Phase 16 SHALL maintain a durable accepted association order per exact comparison
scope under its existing lock discipline. A first lawful late association appends
at acceptance; receipt dates and worker order SHALL not insert it retrospectively
into an accepted prefix. For qualified exact minor-unit values B (complete prior
compared support), G (this eligible gross-support portion excluding fee-cover,
before processor fees or Field Account assessments) and T (the recorded target
applicable to the original gift), the certificate SHALL equal
max(B + G - T, 0) - max(B - T, 0) and satisfy 0 ≤ excess ≤ G.
The original terms, prefix and result SHALL remain evidence. Corrections SHALL
revalidate all causal dependencies, including earlier gifts; ordinary term
lowering creates no new past excess. Surviving excess SHALL not exceed the original
proved amount unless the owner explicitly supersedes an erroneous certificate.
Expiry or consumption of an old application instruction SHALL not block a
mandatory source correction or erase a lawful historical comparison.

AC28-F25-01: Two 60-unit gifts against a 100-unit target certify zero and
20 respectively, never 20 each; a later 0.01-unit qualifying gift can certify
0.01 where that currency supports it.
AC28-F25-02: Reversing the earlier 60-unit gift invalidates dependent excess
in the second gift even when the second gift's own record did not change; stale
completion cannot rely on that older certificate.
AC28-F25-03: Lowering the commitment target without new money does not
create a new gift-purpose. An ambiguous partial return holds affected proof
rather than silently reallocating later gifts or prorating excess.

REQ28-F26 — Qualify whole fixed-commitment fulfillment separately

Story US28-F26: As a missionary, I want a fulfilled-commitment purpose to
represent the actual completion of the promise, so that I do not congratulate a
supporter for a partial installment or administrative release.

Decision basis: D32; P16 fulfillment ownership.

Phase 16 SHALL issue the whole fixed-commitment milestone only for an accepted
positive money-derived application or linked-coverage delta that crosses the
whole applicable positive promise under the same terms. All lines, named
expectations and valid unscheduled capacity SHALL be accounted for within
the pledge's exact Legal Entity and currency; a different currency is not summed
into fulfillment. A term
reduction, release, ending, zero target, paid installment or recurring end is not
that milestone. One continuing fixed pledge SHALL have one automatic fulfillment
purpose; revision, alias, refund/reapply and responsibility changes do not reset
it. A genuinely new pledge has a new purpose. Accepted milestone evidence and
durable consumer intent belong to the owning command, not a side effect of a pure
evaluation or money-posting retry.

AC28-F26-01: The positive final application completing all required pledge
scope yields one source-certified fulfillment purpose; paying one installment
while future capacity remains does not.
AC28-F26-02: Releasing an unpaid balance or reducing the pledged amount to
received coverage produces no automatic “commitment fulfilled” purpose.
AC28-F26-03: A duplicate source event or refund/reapply cycle cannot repeat
a human-handled milestone; an unhandled corrected purpose preserves its lineage.

Phase 28 specification · Part 10/53

Finance and stewardship · file part 2

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/finance-stewardship.md
Source chunk SHA-256: a405812e70c21ec6363de3f3c4000ac9dec4f6b6c6c4b83660d08b551352bbde

Previous part · Full index · Next part

REQ28-F27 — Let tenants combine compatible gift and fulfillment work

Story US28-F27: As authorized staff, I want one organization setting for
combining compatible follow-ups, so that missionaries can handle related purposes
together without losing either obligation.

Decision basis: D32, organization-wide choice ratified.

One organization-wide setting SHALL offer Combine compatible follow-ups or
Keep separate. New qualified activations initially combine; an existing
separate deployment SHALL preserve that behavior until staff deliberately choose
otherwise. Unknown or invalid policy safely keeps separate. Separation disables
composition, not either required purpose. No missionary/project exception matrix
is introduced. Combination SHALL be limited to compatible special-gift work and
whole fixed-commitment fulfillment causally linked to the completing gift, with
the same Tenant, Legal Entity, exact subject, Party, current responsibility,
disclosure and Independent follow-up authority. First support, receipts, care,
financial exceptions and unrelated promises SHALL not be swept into this rule.

AC28-F27-01: The same eligible completing gift and compatible fulfilled
commitment appear in one follow-up with two explicit purposes and separate
evidence when Combine is effective.
AC28-F27-02: Keep separate presents both required purposes independently
without suppressing them or altering money; a malformed policy cannot imply
combined completion authority.
AC28-F27-03: A late milestone cannot reopen a handled gift merely to attach
it to an unrelated current group; a new joint placement requires currently
unhandled causally qualifying gift membership.

REQ28-F28 — Reconcile placement and complete purposes independently

Story US28-F28: As a missionary, I want one combined action to have precise
results even when policies or gifts change, so that I can trust what remains.

Decision basis: D32 C06–C13; D20.

Current combination policy SHALL govern new and unfinished compatible work through
bounded owner reconciliation, with one active placement per purpose. Keep the
current special-gift anchor; move only unresolved fulfillment placement where
needed. Current policy SHALL fence a joint disposition immediately even while
projection catches up; a stale combine worker cannot override a later Separate
decision. A joint action SHALL bind the exact reviewed purpose/member set and
atomically record separate coverage receipts and resulting residue. Material
selected changes reject the whole new action; unrelated arrivals stay unhandled.
A fulfillment-only residue may stay in its container but SHALL release the current
special-gift grouping slot. Previously accepted dispositions survive later policy
changes. One optional actual interaction may reference explicitly covered
compatible work without inventing separate interactions.

AC28-F28-01: Switching to Separate during a combined review rejects a new
stale joint completion but permits a newly reviewed valid single-purpose action.
AC28-F28-02: Handling the gift purpose while fulfillment remains leaves
truthful fulfillment work and allows a later unrelated gift its next current
special-gift group.
AC28-F28-03: A lost successful joint-response retry recovers the original
two-purpose result; a later mode change does not re-execute or rewrite it.

REQ28-F29 — Make missionary offline reporting optional and Off by default

Story US28-F29: As authorized staff, I want to enable missionary reports of
actual offline gifts only when appropriate, so that ordinary finance intake stays
simple for organizations that do not need this doorway.

Decision basis: D33 C01–C04/C18/C23; P15; P27 F56–F74.

One organization-wide Allow missionaries to report offline gifts setting
SHALL initially be Off for new tenants and existing tenants without an explicit
qualified choice. Upgrades preserve a deliberately selected qualified On or Off.
On is necessary but not sufficient for a missionary's current reporting
capability. Staff entry SHALL remain usable without a missionary report. Phase 28
SHALL call the existing Phase 15 operational-intake owner; it SHALL not insert a
financial gift, staging record, parallel intake ledger or task-as-source record.
Enable only the qualified narrow reporting/handling/finance continuation lane,
without requiring every future accounting feature or a new workflow builder.

AC28-F29-01: An Off organization with no retained permitted reports sees
no unused missionary reporting control, while ordinary giving and staff intake
remain available.
AC28-F29-02: On plus exact current reporting authority reveals one optional
action; role name, possession or feature On alone cannot authorize acceptance.
AC28-F29-03: Missing or invalid policy never enables creation, and migration
does not infer opt-in from old gifts, roles or legacy settings.

REQ28-F30 — Record actual receipt with honest incomplete facts

Story US28-F30: As an authorized missionary, I want a short form for a gift
I actually received, so that I can hand known facts to finance without guessing.

Decision basis: D33 C04–C08/C17/C19; P15; P27 F56–F60/F68–F70.

The report SHALL be a deliberate attributed assertion of actual organizational
receipt. A promise or a donor saying a check was mailed is insufficient. The form
SHALL distinguish trusted recorder/tenant/acceptance time from asserted receipt
time and precision, reported receiver/holder and accountable next actor. Unknown
donor, amount, currency, intended Legal Entity, allocation or tender details may
remain explicit in a restricted nonfinancial envelope; required source identity
and accountability remain nonnull. A normalized amount requires known validated
currency and precision; unresolved literal information is an assertion, not money.
No fake Party, zero amount, guessed USD, signature, check photograph, bank/card
data, OCR, routine second approval or compulsory essay is introduced.

AC28-F30-01: Maya can submit an eligible actual receipt with an honestly
unknown donor or amount, receiving an attributable operational report rather
than a fabricated financial record.
AC28-F30-02: Selecting another reported holder records a validated
assertion without granting that person access or proving chain of custody.
AC28-F30-03: A date-only or approximate reported receipt retains its
precision; the server does not manufacture an exact historical timestamp.

REQ28-F31 — Continue the same intake and keep handling separate

Story US28-F31: As finance staff, I want to continue the same reported item,
so that Maya does not re-enter it and recording money does not hide unfinished
physical handling.

Decision basis: D33 C12–C16; P27 F61–F67.

Finance SHALL continue or exactly reconcile the same Phase 15 intake through its
qualified batch/commit path. Lineage SHALL survive splits, moves, carry-forward,
corrections and linking an already-posted result without reposting or reissuing
receipts. Similar amount, name, date or check number is not exact reconciliation.
Independent reports retain separate origins until owner-qualified duplicate
resolution; neither universal one-report/one-header cardinality nor a general
matching engine is presumed. Financial recording, reported possession/transfer,
deposit, clearance, commitment and fulfillment SHALL remain separate. Each
accepted report SHALL have qualified next responsibility or an owned unresolved
exception using existing source work, not a guessed staff audience.

AC28-F31-01: Recording the gift resolves exactly covered recording work
while Handling still needed remains if applicable; completing transfer
first does not post money.
AC28-F31-02: Exactly reconciling an already-posted check links the result
and preserves both report origins without creating another contribution,
commitment application or receipt.
AC28-F31-03: Return, loss, dispute, rejection, duplicate or mistake retains
attributable history and precise remaining work; reversal or NSF does not
resurrect physical possession.

REQ28-F32 — Preserve accepted reports across Off, retries and correction

Story US28-F32: As a missionary, I want clear report status and safe recovery,
so that a disabled setting or interrupted connection does not lose an accepted
handoff or create it twice.

Decision basis: D33 C09–C11/C15/C17/C20/C23.

Policy changes and report admission SHALL share an authoritative acceptance fence.
Off stops new missionary acceptance, including stale forms, but preserves accepted
reports, staff processing and independently permitted reads/corrections/handling.
Accepted report, required history, result receipt and durable accountable work
intent SHALL commit coherently. Same-intent recovery returns an earlier accepted
result even after Off under current read rights; changed payload conflicts. An
Off rejection is a terminal no-effect outcome, never queued for On. An intervening
Off/On cycle requires fresh deliberate review and a new intent for a previously
unaccepted form. Older actual receipts may be deliberately reported while
currently permitted with their real occurrence date. Closing a submitted form is
not cancellation of an accepted or indeterminate command.

AC28-F32-01: If acceptance wins the Off race, Awaiting finance remains
recoverable; if Off wins, no report is created and later On does not replay it.
AC28-F32-02: A timeout displays an unknown outcome with same-operation
Check status/Retry; it does not claim failure or invite duplicate submission.
AC28-F32-03: Recorded by finance and remaining handling are shown as
separately permitted facts; reporting alone changes no received total, deposit,
fulfillment, receipt, acknowledgment or donor message.

REQ28-F33 — Keep missed recurring gifts informational

Story US28-F33: As a missionary, I want to see a confirmed missed gift and the
next scheduled gift, so that I can understand the situation and choose whether
personal follow-up would help.

Decision basis: D40; completeness C05; P16.

When Phase 16 confirms that a scheduled automatic gift was not received after its
qualified recovery ended and confirms regular giving remains scheduled, the
permitted support view SHALL show those separate facts and the current next
scheduled gift. This condition alone SHALL create no automatic missionary review,
outreach task or donor message. Maya MAY deliberately add ordinary authorized
follow-up. Generic action-required status, missed-count thresholds or missing
observations SHALL not manufacture a missionary obligation. Provider/payment
repair, manual-expectation review, stale-source incidents and independently
established source duties retain their existing exact owners.

AC28-F33-01: A qualified missed occurrence with a next regular scheduled
occurrence appears informationally and leaves the missionary task count
unchanged until a deliberate permitted manual task is added.
AC28-F33-02: Pending recovery, stale/unknown source state, a manual expected
gift or canceled future giving is not presented as the same confirmed-miss-plus-
next-scheduled condition.
AC28-F33-03: Late evidence proving pre-closure success corrects the source
occurrence and permitted display; it does not record a fictional human action
or create a fresh task from replay.

REQ28-F34 — Control new missed-gift notices without hiding truth

Story US28-F34: As authorized staff, I want to control new informational
missed-gift notices, so that attention fits the organization without suppressing
financial facts.

Decision basis: D40; P17/P6 notification ownership.

One organization-wide New missed-gift notices control SHALL govern the
optional missionary in-product notification-plan slot. It starts On at qualified
Live activation and preserves an explicit Off choice. Off SHALL stop new notices,
including accepted but unpublished queued candidates, at the actual publication
boundary without rewriting sealed plans. Existing published history retains its
ordinary lifecycle. On SHALL not replay suppressed or historical notices. The
control SHALL not erase payment facts, next schedule, tasks, consent or donor
communications. No per-missionary threshold, retry calendar or channel matrix is
added; notification preference is never authority to inspect a source.

AC28-F34-01: Off accepted before publication suppresses the queued notice
but leaves authorized recurring-support facts and existing tasks unchanged.
AC28-F34-02: Re-enable admits only qualified new candidates, without
replaying the suppressed occurrence or changing donor notification policy.
AC28-F34-03: A notice contains only currently permitted facts and opens the
existing authorized source view; expired access removes forbidden content.

REQ28-F35 — Use organization-selected correction approval policy

Story US28-F35: As authorized finance staff, I want posted-gift corrections
to use the organization's approval policy, so that a small team can work simply
while stronger required controls remain intact.

Decision basis: D48; P13 D5; P12; ADR-0009/ADR-0206.

Phase 13/12 SHALL own the applicable organization policy for staff-initiated
posted-gift corrections. The light new-organization default SHALL not impose a
blanket second approver. Organizations MAY require a different authorized human
generally or for supported categories/qualified amount thresholds through existing
policy capabilities. No arbitrary workflow builder or per-correction bypass is
added. Mandatory money-out/risk controls, exact current financial capabilities,
required reason, immutable history, concurrency and idempotency remain. Required
independence SHALL use canonical human identity; another role, profile or session
does not make the requester a different approver. Authenticated provider/bank
settlement, return or dispute evidence follows its own source correction path
without waiting for staff ceremony.

AC28-F35-01: A permitted ordinary correction under the light policy offers
Apply correction after its before/after review and reason; a correction
requiring approval offers Request approval and truthful Awaiting approval.
AC28-F35-02: Mandatory stronger controls remain effective despite relaxed
tenant policy, and an alternate profile for the same human cannot satisfy a
required independent approval.
AC28-F35-03: A missionary's report, goal or task authority grants no posted
correction, refund, receipt or approval capability.

REQ28-F36 — Revalidate corrections at application without rewriting history

Story US28-F36: As finance staff, I want a reviewed correction to respect
current policy and exact source facts when applied, so that waiting or retrying
cannot bypass a changed rule or alter the wrong gift.

Decision basis: D48; D49; ADR-0206.

Application SHALL re-prove current policy, canonical actor/approver, exact source
and material revision. A stricter effective policy governs uncommitted work; a
relaxed policy SHALL not automatically apply a waiting request. An authorized
deliberate continuation may use the same operation with renewed review when
required. Posted corrections SHALL append exact source changes and preserve
original facts, reason and before/after evidence; they SHALL not edit posted rows
in place. Existing qualified tenant policy SHALL survive upgrade. Missing,
invalid or unknown existing policy SHALL not be interpreted as permission to
bypass approval. The explicit light default is initialized for new organizations,
not substituted as a permissive read fallback.

AC28-F36-01: Tightening approval policy while a correction is waiting
prevents its unapproved application; relaxing policy leaves it waiting until a
currently authorized human deliberately continues.
AC28-F36-02: Lost-response recovery returns one applied correction rather
than another reversal or refund; a changed reviewed payload conflicts.
AC28-F36-03: A correction to intake assertions cannot mutate posted money;
completed financial correction history remains unchanged by later policy edits.

REQ28-F37 — Preserve accepted gift campaign attribution

Story US28-F37: As finance staff, I want source-code campaign changes to
affect future attribution without rewriting earlier gifts, so that campaign
reporting remains explainable.

Decision basis: D49; E7 reconciliation; P13 D14/D13.

An accepted gift's campaign association, including known no-campaign, SHALL remain
its Phase 13-owned reporting fact when a source code is reassigned. Source-code
mapping changes SHALL be prospective at the qualified producer's authoritative
campaign-association event. Each producer SHALL name that event and distinguish
capture-time source-code facts from an actually accepted campaign association.
Late processing, provider retry, historical import or caller backdating SHALL not
replace accepted association with today's registry. Where no earlier accepted
campaign fact exists, a preview SHALL not be fabricated as historical authority.
Known absence SHALL remain distinct from unknown legacy provenance. Mapping may
change after gifts exist; preservation applies to gift evidence, not a permanent
ban on editing the operational map.

AC28-F37-01: After changing code X from campaign A to B, a prior accepted A
gift remains A, a prior known-no-campaign gift remains none, and a newly accepted
applicable gift receives B under its producer's qualified boundary.
AC28-F37-02: Replaying the earlier gift's delivery after remapping does not
reclassify it; unresolved legacy attribution is shown incomplete/unavailable
rather than silently assigned B or classified as known none.
AC28-F37-03: The staff mapping editor explains Earlier gifts keep their
recorded campaign and changes no posted money, designation or donor credit.

REQ28-F38 — Correct campaign attribution deliberately and independently

Story US28-F38: As authorized finance staff, I want to correct a gift's
campaign without falsifying its source code, so that a real attribution mistake
can be repaired permanently.

Decision basis: D48/D49; P13 correction ownership; ADR-0206.

A campaign-only correction SHALL be a deliberate Phase 13 append-only operation
with exact selected gift/line scope, current permission, before/after evidence,
required reason and applicable correction-approval policy. It SHALL preserve the
truthful source code and original campaign history; changing a code merely to
force a campaign is not the required correction path. Current effective reports
SHALL include accepted corrections; issued historical artifacts remain immutable.
Campaign correction SHALL not change received money, designation allocation,
recognition, commitment or fulfillment. Existing qualified bulk correction may
retain its per-item outcome semantics; this requirement adds no bulk engine.

AC28-F38-01: Correcting one accepted gift from A to B changes its effective
campaign reporting and records the original A plus reason while its monetary
totals, designation, credit and commitment coverage remain unchanged.
AC28-F38-02: A rejected, stale or unauthorized correction has no effect;
successful retry recovers one accepted correction under current disclosure.
AC28-F38-03: Previously issued report artifacts retain their stated source
basis; a current adjusted view can explain the later correction without silently
altering the earlier artifact.

REQ28-F39 — Retain recurring origin and independent gift attribution

Story US28-F39: As finance staff, I want recurring installments to retain
their accepted origin and independently recorded gifts to retain theirs, so that
matching fulfillment never rewrites why a gift was given.

Decision basis: D50; E7 reconciliation; P16 term/occurrence/fulfillment.

A source-generated recurring installment SHALL inherit the applicable accepted
line, term and occurrence campaign association, including known none. Changing a
tracking-code map, amount, schedule, payment method, provider or pause/resume
SHALL not silently adopt a new campaign. A deliberate Phase 16 prospective
attribution amendment MAY affect explicitly identified future eligible occurrences
and SHALL preview the first affected occurrence; accepted/in-flight occurrences
retain their frozen lineage. Historical money changes only by the applicable
Phase 13 correction. An independently recorded gift later matched toward a
commitment SHALL retain its own accepted campaign; matching changes coverage,
not money origin. Cancel and fresh Restart giving use fresh authorization;
pause/resume remains continuation.

AC28-F39-01: Code X moves A to B while a recurring line accepted under A
continues; its generated installments remain A until a deliberate qualified
prospective line amendment affects an eligible future occurrence.
AC28-F39-02: A separately accepted B gift matched to that A commitment
stays B and supplies exactly qualified fulfillment once; it is not relabeled A
or counted twice.
AC28-F39-03: Retry, delayed callback or provider replacement preserves an
accepted occurrence's attribution. Retiring a code or archiving a campaign does
not itself cancel, redirect or reclassify continuing support.

REQ28-F40 — Explain current hierarchy and historical report bases

Story US28-F40: As finance staff, I want campaign and subtree totals with a
clear time basis, so that structural changes are useful without rewriting closed
history or double-counting gifts.

Decision basis: D49/D50; E7 reconciliation; P13 D13; P27 F78/F79.

Each gift retains its accepted/effectively corrected campaign node. Current
structural subtree reporting SHALL use the current authorized campaign hierarchy;
moving a node can change ancestor totals without changing gift attribution.
This campaign only and Including sub-campaigns SHALL remain distinct
measures over a distinct qualified line set, not parent-own plus child totals.
Closed/archived hierarchy protection SHALL cover changes to ancestors or subtrees
that would alter protected historical meaning. Dated closures and issued
artifacts SHALL retain their exact hierarchy/source basis and never rebuild
against today's tree. Reconciliation SHALL include known-no-campaign amounts as
a valid bucket per currency and scope; unknown coverage prevents an assertion of
complete reconciliation. Visibility filters precede aggregation.

AC28-F40-01: Moving an open node changes applicable current ancestor totals
while the gift's campaign node remains unchanged and each source line counts
once in the selected subtree.
AC28-F40-02: An ancestor move cannot bypass closed/archived protection; an
earlier issued hierarchy report retains its historical figures and basis.
AC28-F40-03: Qualified campaign buckets plus qualified known-none equal
the same scoped complete financial source total per currency; unknown
attribution is not silently included in the none bucket to force equality.

REQ28-F41 — Enforce source contracts and tenant-safe resulting states

Story US28-F41: As a tenant administrator, I want every source and alternate
entry path to enforce the same scope and authority, so that a permitted update
cannot turn a safe record into an unauthorized one.

Decision basis: D16; D19–D22; D29–D33; D40; D48–D50; P12; ADR-0206/0208.

Owner contracts SHALL define required identity, Tenant, Legal Entity where
applicable, typed subject, Party, currency/unit, source fact kind, accepted
revision, provenance, live/history cohort, current validity and lawful correction
lineage. Mandatory relationships SHALL be nonnull at their proper owner boundary;
restricted incomplete intake is not a nullable financial root. Same-tenant
relationships and semantic uniqueness SHALL be enforced structurally where
possible. Actor, recorder, tenant and audit attribution SHALL derive from trusted
current context; a selected subject/holder/approver SHALL be independently
validated. Required immutable finance, assertions and history SHALL not be
destroyed by relationship cascades. Exact currency validation precedes coercion.

Coarse tenant RLS SHALL backstop fine-grained Phase 12 purpose/field authority.
Qualification SHALL inspect grants, effective old-row and new-row policy
behavior, SELECT requirements, views, RPC/function ownership, privileged service
paths, imports, repair and export. Omitted explicit WITH CHECK alone is not proof
of a defect where applicable PostgreSQL policy inheritance supplies the check;
tests SHALL prove actual forbidden resulting states are impossible. Legacy
role-based routes, public projections and direct browser mutation paths SHALL be
converged or fenced before affected activation.

AC28-F41-01: Hostile requests cannot substitute another tenant, Legal
Entity, Party, owner, source revision or approver through any exposed or
privileged path, including updates to previously permitted rows.
AC28-F41-02: Database/command tests prove forbidden cross-tenant references,
duplicate current goal heads, duplicate purpose coverage and destructive
attribution changes are rejected, not merely hidden by the UI.
AC28-F41-03: Current hosted grants/RLS and service-path evidence qualify the
intended boundary independently of migration text or a passing mock test.

REQ28-F42 — Commit durable effects and recover without duplicate business work

Story US28-F42: As a missionary or staff operator, I want accepted actions to
remain recoverable after a failure, so that fixing the display never repeats
money or personal work.

Decision basis: D16; D19–D22; D29–D33; D40; D48–D50.

Each authoritative owner SHALL atomically accept its business effect, required
history/semantic receipt and required durable identifier-only consumer intent.
Cross-owner delivery MAY be asynchronous through existing dispatch/reconciliation;
no distributed transaction or best-effort-only event is presumed. Financial
posting SHALL not await recognition or task projection. Admission and disposition
SHALL re-prove relevant source dependencies and current authority after waits
under the owning invalidation fences. Same business purpose SHALL remain
deduplicated across transport keys, workflows, retries and aliases. Reads of old
receipts SHALL use current disclosure. Required minimal dedupe evidence SHALL
survive lawful PII redaction without restoring private payloads.

AC28-F42-01: A failure after source commit but before task projection is
repaired from the original durable intent into one task member without
reposting money or generating another purpose.
AC28-F42-02: Revocation or material source correction winning the acceptance
order rejects a stale action even if its initial check passed; harmless
unrelated changes do not unnecessarily invalidate the reviewed scope.
AC28-F42-03: Duplicate/out-of-order delivery and restore preserve consumed
purpose identities, current Off policies and completed human history; replay
cannot recreate effects from deleted personal data.

REQ28-F43 — Deliver clear, accessible and safe everyday flows

Story US28-F43: As a missionary using a phone or assistive technology, I want
compact understandable support actions and statuses, so that I can work reliably
with limited attention or connectivity.

Decision basis: D16; D19–D22; D29–D33; D40; D48–D50.

Flows SHALL reuse the existing design system and source record/task surfaces.
Expose relevant optional settings through their current owners; do not create a
finance setup wizard for missionaries. Show factual purpose, exact selected scope,
clear current next action and authoritative Save/Done feedback. Distinguish
unsent, saving, accepted, definitively rejected, unknown outcome, unavailable,
conflict and denied. Avoid mandatory narrative or redundant confirmation for
ordinary actions. Preserve international names/text, qualified currencies and
owner calendars; dates SHALL not silently change because of device timezone.
Supported keyboard, screen reader, focus, status announcements, contrast, reflow
and phone interaction SHALL work. Account/tenant changes or revocation SHALL clear
forbidden content and prevent late responses from displaying prior-context data.
No sensitive persistent offline queue or automatic replay of rejected actions is
introduced.

AC28-F43-01: Actual phone and assistive journeys can find a reason, inspect
exact reviewed members, complete permitted work and recover an unknown result
without a hidden hover-only control, color-only state or duplicate action.
AC28-F43-02: Users can correctly distinguish goal Save from publication,
gift report from financial posting, Done from sending, and notices Off from
erasing financial facts in observed task-based usability checks.
AC28-F43-03: Switching tenant/account during an outstanding response neither
displays the old private result nor submits its action in the new context.

REQ28-F44 — Qualify source lanes, migration and measurable operation

Story US28-F44: As an operations owner, I want explicit activation evidence
and bounded recovery, so that incomplete legacy behavior cannot masquerade as a
reliable financial workspace.

Decision basis: D16; D19–D22; D29–D33; D40; D48–D50; E7 reconciliation.

Each affected source lane SHALL activate only after its real producer, exact
owner adapter, authority/fence, coherent revision contract, semantic uniqueness,
history baseline, alternate-path closure, failure recovery and composed user
journey are qualified. Existing examples, static migrations and finite models do
not prove deployed behavior. Source ownership and product semantics above are
settled; missing producer evidence creates a bounded implementation/proof task,
not a new product-policy choice or a permanent omission of required reporting.
Migration SHALL inventory legacy units, counters, assignments, task history and
source provenance; backfill only proved facts without retrospective task floods,
fabricated campaign attribution or guessed opt-in. Mixed versions and restore
SHALL preserve current restrictions and consumed identities. Kill switches fence
unsafe admission while retaining lawful accepted work and staff recovery.

Before activation, each owner SHALL publish numeric payload/page/batch/retry
ceilings and query/command/recovery budgets with units, measured on realistic
skewed tenant workloads, and prove below/at/above behavior. Implementations SHALL
use bounded indexed reads/reconciliation and tenant-fair backpressure; they SHALL
not scan full history per visible card, silently truncate evidence or drop tiny
eligible gifts to meet capacity. Named maintainers SHALL own the adopted signals
below through existing operational/support channels. Monitoring is not a substitute
for prevention of known authorization or integrity defects.

AC28-F44-01: Activation evidence includes positive/negative source proofs,
actual database and alternate-path authorization tests, exact-unit boundaries,
controlled acceptance races, idempotent recovery, restore, accessibility and
source-shaped performance results for the specific enabled lane.
AC28-F44-02: Unproved historical rows are quarantined for owner resolution
without guessed money units, campaign origin or new follow-up; independently
qualified rows and ordinary authorized work remain usable.
AC28-F44-03: Failure exercises trigger the stated owner response below and
preserve financial facts, source history and purpose identities during recovery.

Adopted signal	Threshold	Accountable functional owner	Required response
Unauthorized/cross-tenant source effect or disclosure; duplicate handled effect; precision/conservation failure; competing goal heads; missing required committed audit	Any confirmed occurrence/invariant violation	P12 security owner and affected P13/P15/P16/P28 source owner	Fence the affected path, preserve lawful evidence, assess scope and repair through owner commands before reactivation. Do not change money or introduce a minimum threshold as a workaround.
Accepted special-gift intent without projected/reconciled task state	Oldest age exceeds 5 minutes for two consecutive 1-minute checks	P28 operations on-call	Inspect source cursor/queue and retry the original durable intent; escalate an unavailable dependency without creating a manual duplicate.
Comparison correction accepted but affected excess proof not reconciled	Oldest age exceeds 1 minute for two consecutive 1-minute checks	P16 operations on-call	Verify stale-proof action fencing, pause affected reason use if needed and reconcile exact dependencies. Any stale acceptance is an immediate integrity incident.
Qualified lane cannot produce required comparison evidence	Sustained for more than 15 minutes	P16 integration owner	Diagnose source authority/completeness, mark only the affected lane unavailable and repair; never infer excess from unmatched money.
Accepted intake work intent has no projection progress	Older than 5 minutes, or any terminal retry failure	P15 operations owner	Use the existing bounded recovery and show honest updating; do not resubmit the report or repost money.
Same-intent intake recovery fails repeatedly	Three consecutive failed attempts	P15 operations owner	Stop noisy retries and route an owned exception using supported diagnostic/recovery actions.
Accepted intake exceeds its existing next-action deadline without progress	First missed applicable configured deadline	Tenant finance operations owner	Review responsibility and actual remaining work, then reassign/escalate through existing routing without a new global due date.
Goal derivative differs from current source after successful repair read	One confirmed mismatch	P28 projection owner	Invalidate/quarantine the derivative, show source-current or unavailable truth and repair the stale writer.
Duplicate/malformed comparison-source input	Any schema violation; duplicate rate above the qualified adapter baseline for 15 minutes	Financial integration owner	Quarantine malformed input, preserve idempotent results and reconcile adapter/delivery behavior; a duplicate is not a new gift.
Incorrect financial meaning in user feedback, or a blocking supported accessibility flow	Any credible unsafe misunderstanding or reproducible blocking failure	Missionary product/UX and accessibility owners	Contain the affected presentation, correct it and repeat the actual journey before wider activation.
Correct small-excess work repeatedly reported unhelpful	Three independent eligible-user complaints in a rolling 30 days; any wrong amount/meaning investigated immediately	Missionary product owner and UX lead	Review minimized evidence and grouping with users; any materiality-rule change requires a new explicit product decision.
Workload outside qualified envelope	Any declared capacity limit exceeded, or p95 duration above the approved release budget for 15 minutes	Platform performance owner	Bound jobs, apply tenant-fair backpressure and qualify additional capacity while preserving truth and authority fences.

Phase 28 specification · Part 11/53

Communications and connections · file part 1

Source: docs/prds/sitestacker-parity/phase-28-missionary-workspace-depth/communications.md
Source chunk SHA-256: 9034b315c984bec22ece9a8c4afc197acd28a874bbf76591876b5caf89c71b5d

Previous part · Full index · Next part

Phase 28 — Communications, newsletter signup and personal connections

This is the canonical normative communications requirement volume for Phase 28.
It defines intended behavior; ratification, publication and test descriptions do
not establish implementation, provider qualification or activation. Each REQ,
US and AC identifier is stable and independently traceable. All normative
conditions of a requirement apply together with its acceptance outcomes.

The decision basis is the selected native signup direction in D6, the ratified
D7, D14, D15 and D18 review packets, D42 and D43, and selected D44/D45. Later
rulings supersede earlier proposals within their exact scope: qualified current
account-mailbox proof may admit immediate Join under D42, and confirmation lasts
168 elapsed hours under D45. D6's earlier universal fresh-confirmation and
72-hour proposals are not requirements. Its separately proposed pending-data
24-hour purge was not adopted. A finite native pending/proof/minimal-evidence
retention profile remains an explicit owner qualification gate; the seven-day
confirmation period does not itself define storage retention.

Native membership, external Request newsletter, human-authored newsletter,
individual correspondence, calendar copy and optional AI editing are distinct
source operations. None acquires another's consent, permissions or effects.
The full native newsletter journey remains required; automatic standing digests
are an intentional difference from the comparator, not an implied Send authority.

Governing owner interfaces

Interface	Required authority and result
Native source	Phase 28 owns issue/draft, exact signup instruction and membership, and bounded authored-individual-message authorization. Phase 9 owns canonical contacts/relationships, the qualified Appointment source and genuine interaction facts; Phase 27 owns development purpose and outreach-versus-exchange meaning.
Identity and disclosure	Phase 4 supplies accepted current principal/authenticator/mailbox provenance. Phase 3/10/12 supply exact consent, classification, current capabilities and permitted projections. Shared email, role display and relationship are not authority.
Page, reuse and preferences	Phase 22/23 own exact Page placement/release, Update revisions and media admission; Phase 25 retains separate external-request and donor preference semantics. Exact byte custody/export work consumes its qualified owner without making all Phase 29 a prerequisite.
Content and delivery	Phase 17 owns qualified preparation/rendering, sender/reply/action purposes, restricted execution material and complete source-fenced plan compilation/release into Phase 6. Phase 6 alone owns recipient intent, prepared/submission identity, dispatch, provider outcomes/recovery and body-free communication history. Human-authored lanes are explicit qualified producers, not invented system-message keys.
Personal provider and calendar	Phase 31 owns exact connection, account/grant revision, credential custody, provider adapter and transport facts. A connection or token alone grants no source operation.
Optional AI	The shared Phase 21 D10 tenant AI binding/custody/usage foundation serves the bounded newsletter purpose. The editor exposes a qualified semantic selection/conditional-edit interface; other AI products' context, fallback or permissions do not transfer.

Common release and effect contract

Every confirmation, newsletter, real email test and personal message requires
an actual qualified communication producer, immutable binding,
purpose, recipient resolver, typed facts, current source fence, sender/reply
permission, retention class, exact dispatch profile and proof pack. A Reserved
catalog entry, generic helper, provider SDK, UI placeholder or published issue
is insufficient. The complete bounded plan is validated and committed before any
member is dispatchable; parent/member count and digest and immutable command
identity are checked with release last. A sealed large-issue audience may fan out
through bounded durable occurrences, each complete under that contract. It never
reruns a live expanding audience or creates a second communications ledger.

Source acceptance, preparation and provider-attempt admission are separate.
A permanent attempt fence commits before any external byte; no network call
occurs inside the source transaction. A queue lease or prepared artifact is not
submission. Source cancellation ordered before attempt admission stops the new
effect; admission ordered first preserves possible external truth. Current
source/recipient/contact/disclosure/consent/suppression/sender/grant/utility
checks apply at their owning effect boundary. Positive exact-purpose authority
is required in addition to the canonical contact restrictions; calling authored
mail transactional cannot bypass applicable do-not-contact, do-not-email or
suppression. Topic-only withdrawal retains its actual scope.

Frozen audiences may narrow but may not expand, substitute recipients or
silently follow a changed address. Phase 27 appeal closure or required review
invalidation fences dependent unadmitted solicitation; independently authorized
receipts, service and fulfillment keep their own authority. Resend team/account
suppression and source contact restrictions are distinct evidence. Changing
sender domain or provider cannot automatically clear either restriction.

Only the exact closed Phase 17 Resend profile permits its qualified identical
sealed-envelope retry. Gmail/Graph uncertainty does not inherit that guarantee.
Accepted or ambiguous non-idempotent personal-mail work is never replayed,
rekeyed, cloned or shifted to another account. Acceptance, delivery, engagement,
human exchange and business completion remain distinct. Durable communication
history contains permitted body-free identity/outcome evidence, never personal
subjects/bodies, raw tokens, URLs, credentials or provider payloads. Source drafts,
execution bytes, any qualified readable projection and external mailbox copies
have separate custody and current access.

Exact activation gates

Calendar copy and AI generation keep their Phase 31/shared-AI operation and
recovery owners; neither becomes a Phase 6 message or new notification merely
because it has an external effect. Their explicit requirement-specific contracts
below govern the corresponding admission, uncertainty and retry boundaries.

The atomic compiler and the prepared-artifact/sealed-provider-submission producer
are separate dependencies. The latter's actual implementation allocation and
component proof remain unresolved in the current inspected owner packet; the
compiler cannot be credited with this missing transport capability. Affected
provider paths remain blocked until the exact source handoff, prepared/submission
producer, matching-owner outcomes and adapter qualify. Independent native work
remains usable, and unrelated completion of all Phase 6 is not required.

Required owner amendments include the bounded native subscription lane alongside
Phase 25 external Request and Phase 23's older Phase 32-only subscription wording;
the native confirmation's exact same-Tenant non-constituent recipient descriptor;
actual Phase 4 ordinary verified-mailbox proof and its acceptance-time ordering;
native authored content, media, reply and retention profiles; the personal
connected-account topology alongside tenant Resend; and the native Appointment
plus minimal calendar copy. No fake Party/Auth user, second sender pipeline,
unified personal inbox or blanket whole-phase dependency supplies these seams.

Before activation each affected source/provider profile declares and enforces
finite field/byte/member/admission/backlog/rate/concurrency/retry/fairness bounds,
retention/disposal classes, and measured capacity. Native newsletter scheduling
also requires a finite source horizon and absolute usefulness deadline. Their
unselected numeric values must be qualified by the existing owners, not guessed
from a provider window or borrowed from unrelated Request newsletter retention.
Ratified numeric values appear in the relevant requirements below and are not
provider maxima or measured capacity claims.

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.