Built with care. Tracked openly.

Distinct blogs, directories, feed categories, post categories and feed-specific display templates.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Route website inquiries to the owning church with spam controls, consent and staff resolution history.

Database contract: contact_forms, submissions, assignment_events, notification_outbox

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Wrong-domain form cannot route private message to other church; duplicate POST creates one inquiry.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Set Up a Contact Us Form on Your Website

Podcast-specific tags, media metadata and subscriber feed generation.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Edit safe page titles, summaries, canonical URLs and social images per published revision.

Database contract: page_versions(seo_title,description,canonical_url,social_image_id), domains

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Private/member content omitted from sitemap and snippets; cross-domain canonical validated.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Search Engine Optimization and Social Sharing

Ordered image feeds and homepage banners with accessible controls.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Upload validated media, label alt text, organize galleries and control public/private publishing.

Database contract: media_assets(owner_org,mime,hash,visibility), galleries, gallery_items

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Executable uploads rejected; private files require scoped access; referenced media deletion guarded.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How do I create an image gallery?

Hero, top-left and top-right menus with independent theme controls.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Build church menus with nested ordered items and responsive accessible display.

Database contract: menus, menu_items(parent_id,position,target_type,target_id)

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Cycles rejected; hidden/private pages not leaked; keyboard mobile navigation works.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Create a Multilevel Menu

Manage event sessions with individual capacities and expiring checkout reservations.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Manage event sessions with individual capacities and expiring checkout reservations.

Database contract: event_sessions, capacity_holds(expires_at), tickets(session_id), checkins

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Concurrent requests cannot oversell; expired holds released; cancel restores correct session.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Set Up Time Slot Reservations for Events

Allow authorized ticket holder or event staff to correct attendee details with audit and reissue policy.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Allow authorized ticket holder or event staff to correct attendee details with audit and reissue policy.

Database contract: attendees(version), attendee_change_events, ticket_versions

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Changing attendee does not change paying donor or tax receipt; stale edits rejected.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Change Attendee Names for Events

Collect donor declarations with effective dates and eligible-gift links, retaining immutable wording and change history for issuer reports.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Collect donor declarations with effective dates and eligible-gift links, retaining immutable wording and change history for issuer reports.

Database contract: gift_aid_declarations(person_id,organization_id,wording_version,effective_from,effective_to,address_snapshot), eligible_gift_links

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Only eligible gifts and valid declarations exported; cancellation affects required period; legal requirements separately verified.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Gift Aid (UK Only)

Resolve explicit donor/issuer receipt language and persist chosen language/template version in each issued snapshot.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Resolve explicit donor/issuer receipt language and persist chosen language/template version in each issued snapshot.

Database contract: receipt_templates(locale,version), donor_receipt_preferences, receipt_documents(template_id,locale)

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: French preference selects French template; missing translation yields visible exception rather than mislabeled document.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Configuring Tax Receipts to Prioritize French Over English

Configure issuer line labels and safe merge values without altering recorded gift amounts or legal disclosure.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Configure issuer line labels and safe merge values without altering recorded gift amounts or legal disclosure.

Database contract: receipt_template_versions, receipt_line_labels, immutable document snapshots

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Unsupported merge token rejected; escaped text cannot inject markup; prior document unchanged.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Customize Line Item Labels in the Tax Receipt Summary

Pledge campaign editor stores church, dates, receiving funds/products, goal, currency, suggested amounts and publication state. Staff record affirmed donor promises; donors record and maintain their own. Giving forms link to pledge options. Reports filter active, fulfilled, overdue and cancelled commitments.

Acceptance: 31 lifecycle, 3 simultaneous campaign-save, 66 rendered-screen/report and 72 HTTPS checks; browser saved pledge 7 revision 2 with amount 1000 and received 603.55 unchanged. Six campaigns, 24 promises, six giving-page links.

Dependency: Inbound SMS pledge capture and live-event presentation remain separate incomplete features COM-008 and EV-010. Integration-specific external pledge synchronization remains INT-040.

Source behavior / boundary: Campaigns collect promises against a defined window of eligible giving funds and commerce products; staff and donors create or revise promises, track received progress and recalculate.

Matthew25 workflow: Pledge campaign editor stores church, dates, receiving funds/products, goal, currency, suggested amounts and publication state. Staff record affirmed donor promises; donors record and maintain their own. Giving forms link to pledge options. Reports filter active, fulfilled, overdue and cancelled commitments.

Database contract: pledge_campaigns/funds/products and immutable campaign_versions; campaign_pledges plus pledge_versions, form_links and progress_events. Received totals query canonical gifts and paid commerce lines, subtract refunds and manual pledge allocations, and exclude fee contributions, tax and shipping.

Who can do what: Church finance staff manage campaigns and all church promises. Donors access only their own promise. Public pages show campaign aggregates only. Tenant context is checked before every private view, action and export.

Validation and recovery: No payment is created by a promise. Affirmative confirmation, request-key idempotency, optimistic versions and campaign/organization locks protect changes. Overlapping eligible items are rejected even under concurrent creation. Dates/scope become immutable after first promise; cancelling retains revisions and never refunds gifts.

Required acceptance tests: 31 lifecycle, 3 simultaneous campaign-save, 66 rendered-screen/report and 72 HTTPS checks; browser saved pledge 7 revision 2 with amount 1000 and received 603.55 unchanged. Six campaigns, 24 promises, six giving-page links.

Actual implementation evidence: Release 0.10.0 server evidence: 31 lifecycle, 3 simultaneous campaign-save, 66 rendered-screen/report and 72 HTTPS checks; browser saved pledge 7 revision 2 with amount 1000 and received 603.55 unchanged. Six campaigns, 24 promises, six giving-page links. Inbound SMS pledge capture and live-event presentation remain separate incomplete features COM-008 and EV-010. Integration-specific external pledge synchronization remains INT-040.

• Guide to Pledges (Promises to Give)

Allow per-form experimental prompt after recurring enrollment; record 0/2/3/4 percent choice and original amount; report/export results without changing billing.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: Givecloud Auto Scale is currently an experiment collecting annual-increase choices; it does not yet automatically increase recurring gifts.

Matthew25 workflow: Allow per-form experimental prompt after recurring enrollment; record 0/2/3/4 percent choice and original amount; report/export results without changing billing.

Database contract: REQUIRED experiment_definitions, form_experiments, experiment_consents(plan_id,percent,original_minor,notice_version), experiment_exports.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Opt-in alone causes no plan amount change; duplicate submission one result; church-specific CSV respects permissions.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• 🧪 Experiments

After gift, collect separate public/private note and approved emoji; moderate public display and keep private note out of widgets and CRM fields unless explicitly mapped.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: After gift, collect separate public/private note and approved emoji; moderate public display and keep private note out of widgets and CRM fields unless explicitly mapped.

Database contract: gift_messages(gift_id,visibility,body,moderation_status), reaction_options, gift_reactions

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Private note never in honor roll; anonymous donor identity hidden; retries produce one reaction.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• GE: Customize Experience

Offer address suggestions through configured provider while allowing validated manual international addresses.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Offer address suggestions through configured provider while allowing validated manual international addresses.

Database contract: address_provider_connections, person_addresses, checkout_address_snapshots

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Provider unavailable does not block manual entry; suggestion does not verify identity.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Address Auto-Complete at Checkout

Accept allowlisted prefill parameters and validate again server-side; never trust URL prices, recipient merchant or identity assertions.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Accept allowlisted prefill parameters and validate again server-side; never trust URL prices, recipient merchant or identity assertions.

Database contract: form_field_definitions, checkout_field_values, checkout_sessions

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Unknown fields ignored; tampered fund/amount rejected; confidential values excluded from share links.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Use URLs to Pre-Fill Custom Fields on Your Donation Page

Copy design and safe configuration into an unpublished new form with fresh identity and version history.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Copy design and safe configuration into an unpublished new form with fresh identity and version history.

Database contract: giving_forms, form_versions, form_fields, duplication_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: New form does not share editable version or publish itself; credential references not copied across churches.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Duplicate a Giving Experience

Publish start/end schedule per church timezone, enforce at checkout and prevent paying to archived funds.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Publish start/end schedule per church timezone, enforce at checkout and prevent paying to archived funds.

Database contract: form_versions(starts_at,ends_at,status), checkout_sessions, fund eligibility

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Just-expired form rejected before authorization; existing settled gifts remain available.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Setting an Active Date for your Classic Forms

Require acknowledgment of versioned privacy notice separately from optional fundraising marketing consent.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Require acknowledgment of versioned privacy notice separately from optional fundraising marketing consent.

Database contract: privacy_notices, checkout_consents(notice_id,person_id,accepted_at), consent_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Privacy acceptance never implies email opt-in; missing mandatory consent blocks completion.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Create a Privacy Policy Checkbox on Classic Forms

Map church donors/constituents, contribution funds and separate fee/shipping/tax gifts; reconcile returned IDs and surface sync limitations.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The documented beta supports constituent and gift sync, but recurring-plan edits, some split designation behavior and later-issued receipts have limitations.

Matthew25 workflow: Map church donors/constituents, contribution funds and separate fee/shipping/tax gifts; reconcile returned IDs and surface sync limitations.

Database contract: REQUIRED integration_connections(organization_id,provider), constituent_links, gift_links, mapping_versions, sync_outbox, attempts, conflicts.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: One-way profile sync cannot overwrite from untrusted remote records; split grouping correct; manual reconciliation for unsupported receipt and recurring updates.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• BETA: Blackbaud Raiser's Edge NXT (Overview)

Connect each church’s Blackbaud account and per-currency hosted payment configuration; independently reconcile ambiguous ACH status and refund amounts.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The documented BBMS beta uses hosted checkout and currency configuration. ACH status, failed-attempt events and refund detail availability have limitations.

Matthew25 workflow: Connect each church’s Blackbaud account and per-currency hosted payment configuration; independently reconcile ambiguous ACH status and refund amounts.

Database contract: REQUIRED merchant_connections, hosted_payment_sessions, payment_events, reconciliation_exceptions, refund_evidence.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Hosted failure not treated as success; pending ACH not receipted as settled; partial refund cannot be inferred from generic Refunded status.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• BETA: Blackbaud Integrated Payments (BBMS)

Use a church-owned direct-debit connection with mandate authorization, pending collection and asynchronous settlement.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Use a church-owned direct-debit connection with mandate authorization, pending collection and asynchronous settlement.

Database contract: merchant_accounts, mandates, payment_events, returns, organization-scoped external IDs

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Mandate revocation stops collection; delayed failures reverse provisional state; no raw bank credentials.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• GoCardless

Configure eligible church gateway accounts and route their supported currencies/payment methods.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Configure eligible church gateway accounts and route their supported currencies/payment methods.

Database contract: merchant_accounts, gateway_capabilities, token references and settlement links

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Unsupported currency rejected; gateway credential and merchant boundaries enforced.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Cayman Gateway

Calculate applicable commerce sales tax using shipping/billing jurisdiction and line classification; store quote and committed transaction separately.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Calculate applicable commerce sales tax using shipping/billing jurisdiction and line classification; store quote and committed transaction separately.

Database contract: tax_connections, tax_quotes, tax_lines, order_tax_snapshots, tax_adjustments

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Donation-only line is not blindly treated as merchandise; refund reverses allocated tax; outage does not silently assume zero.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• TaxCloud

Provide scoped event subscriptions and authenticated actions with durable delivery and revocation.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Provide scoped event subscriptions and authenticated actions with durable delivery and revocation.

Database contract: api_clients, scopes, webhook_subscriptions, event_outbox, delivery_attempts

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Revoked client denied; replay idempotent; church A cannot subscribe to church B.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Zapier Integration

Synchronize opted-in church contacts and mapped tags through retriable jobs.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Synchronize opted-in church contacts and mapped tags through retriable jobs.

Database contract: marketing_connections, external_contact_links, consent_events, sync_jobs

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Unsubscribe stops marketing sync; foreign church consent not reused; duplicate contact handled.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Active Campaign

Map church lists and explicit channel consent; reconcile subscription state without overwriting opt-out.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Map church lists and explicit channel consent; reconcile subscription state without overwriting opt-out.

Database contract: marketing_lists, list_mappings, contact_links, suppression_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Provider failure retried; opted-out contact not re-added by profile update.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Constant Contact

Map church audience, tags and permitted contact fields and propagate opt-out through signed webhook handling.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Map church audience, tags and permitted contact fields and propagate opt-out through signed webhook handling.

Database contract: audience_mappings, subscriber_links, webhook_inbox, suppression_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Webhook replay safe; unsubscribed person never auto-resubscribed.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Mailchimp

Map congregation and giving exports to church-owned Servant Keeper identifiers with preview and reconciliation.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Map congregation and giving exports to church-owned Servant Keeper identifiers with preview and reconciliation.

Database contract: integration_connections, field_mappings, export_jobs, external_links

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: No multi-church profile leakage; unrecognized mapping returns visible exception.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• ServantKeeper

Version recurring-to-pledge mappings and reconcile cancel/recreate behavior when changing paid pledge schedules.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Version recurring-to-pledge mappings and reconcile cancel/recreate behavior when changing paid pledge schedules.

Database contract: recurring_external_links, pledge_mapping_versions, sync_jobs, replacement_links

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Old pledge remains traceable; cancelled/recreated mapping does not double count; retries no duplicate pledge.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Enhanced DP Pledges for Automated Pledge Updates

Inventory merchant-scoped tokens and recurring mandates, obtain processor transfer procedure, reconcile test samples, then cut over with rollback boundary.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Inventory merchant-scoped tokens and recurring mandates, obtain processor transfer procedure, reconcile test samples, then cut over with rollback boundary.

Database contract: migration_batches, token_mapping_rows, mandate_migration_events, cutover_state

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: No raw card export; foreign vault references rejected; original mandate preserved until verified replacement.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Switching Gateways: What to Keep in Mind

Track platform subscription plans, invoices, payment methods and cancellation separately from church donations and donor fees.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Track platform subscription plans, invoices, payment methods and cancellation separately from church donations and donor fees.

Database contract: platform_plans, organization_subscriptions, platform_invoices, invoice_lines, billing_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Platform invoice never becomes charitable receipt; cancellation effective date preserved; no merchant pooling.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Guide to Givecloud Billing

Store each staff member’s church-scoped dashboard shortcuts in MySQL and render only currently authorized destinations.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Store each staff member’s church-scoped dashboard shortcuts in MySQL and render only currently authorized destinations.

Database contract: staff_dashboard_preferences(account_id,organization_id), ordered_shortcuts

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Preference persists without localStorage; revoking access removes shortcut target.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Adding and Removing Pins on Your Dashboard

Allow scoped moderation to archive and reactivate a fundraiser while preserving gifts, links and review history.

Acceptance: See individual specification below.

Dependency: Extended worker fault/load tests remain operational acceptance.

Source behavior / boundary: End, archive and reactivate fundraisers; Extended worker fault/load tests remain operational acceptance.

Matthew25 workflow: Owners end fundraising; church reviewers archive, suspend and reactivate. Deadline worker closes expired pages while preserving history and recurring authorizations.

Database contract: fundraising_pages lifecycle and audit; worker_runs captures scheduled process outcome; approved deadline or cause fallback drives close.

Who can do what: Owner closes own page; church staff restores only eligible verified pages.

Validation and recovery: Ending a page blocks new checkout but cannot silently cancel already authorized recurring plans.

Required acceptance tests: Close rejects new gift, old recurring authorization remains; reactivation requires future deadline.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Extended worker fault/load tests remain operational acceptance.

• How to Archive a Peer-to-Peer Fundraising Page
• How to Reactivate a Peer-to-Peer Fundraising Page

Attribute verified offline gifts to approved fundraisers with donor public-display consent.

Acceptance: 0.12.0: 70 lifecycle, 162 rendering/filter, 90 HTTPS checks and 10 regression suites passed. Finance staff select or enter a received gift for the same church cause. Linking is idempotent and does not create a charge, donation or tax letter. Default recognition is anonymous; public name or message requires donor authorization confirmation.

Dependency: Attributed-gift reversal/reassignment with retained relationship history and broader POS workflow integration remain unfinished.

Source behavior / boundary: Offline progress and donor recognition; Staff offline cash/check contribution attribution with date/source and optional acknowledgement remains.

Matthew25 workflow: Finance staff select or enter a received gift for the same church cause. Linking is idempotent and does not create a charge, donation or tax letter. Default recognition is anonymous; public name or message requires donor authorization confirmation.

Database contract: Church, currency, designated campaign and receiving fund checked before attribution. Positive unrefunded balance required. Existing attribution cannot be moved to another fundraiser. Audit retains recognition choices and authorization confirmation.

Who can do what: Church finance staff controls offsets; donor/finance controls identity.

Validation and recovery: Offsets never create receipts, ledger journals or processor records.

Required acceptance tests: Offset changes displayed total with unchanged financial row counts; refund reduces actual gift contribution.

Actual implementation evidence: 0.12.0 evidence in /srv/matthew25/work/verification-{fundraising,render,live,regressions}-0.12.0.json. Attributed-gift reversal/reassignment with retained relationship history and broader POS workflow integration remain unfinished.

• How to Manually Record a Contribution for a Peer-to-Peer Fundraiser
• Peer-to-Peer: Edit Honor Roll Donors on Fundraising Page

Allow daily billing with explicit church timezone, cycle limit or end date. Preserve local schedule across DST without duplicate occurrence.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Allow daily billing with explicit church timezone, cycle limit or end date. Preserve local schedule across DST without duplicate occurrence.

Database contract: REQUIRED recurring_plans(cadence,anchor_date,timezone,max_cycles,end_date), recurring_occurrences(plan_id,sequence,due_at,status); unique plan/sequence.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Daily runs across DST, cutoff date and fixed cycle limit; paused plans produce no charge.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Adding Daily Donation Frequency

Upload and map new commitments; validate donor, item, currency and same-merchant token; support explicit manual commitments without a token; preview then process durable per-row results.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: Givecloud can bulk-create automatic plans using existing valid Givecloud payment methods, or manual plans without them; outside-gateway vault IDs are not interchangeable.

Matthew25 workflow: Upload and map new commitments; validate donor, item, currency and same-merchant token; support explicit manual commitments without a token; preview then process durable per-row results.

Database contract: REQUIRED import_jobs, import_rows(raw_values,normalized_values,error,status), recurring_plans, merchant_scoped_payment_tokens, external_links.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Foreign donor token rejected; no token cannot create automatic collection; replay import creates no duplicate; mixed valid/invalid rows reconcile.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Bulk Create Recurring Payment Plans (RPPs)

Preview before/after amounts, dates, cadence, cost contributions and cancellations; blank means unchanged; zero explicitly removes fee contribution. Apply authorized changes with old-version checks and row-level results.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: Givecloud bulk updates accept recurring profile IDs, treat blank fields as unchanged, and distinguish zero DCC. Reactivation and CRM propagation have documented restrictions.

Matthew25 workflow: Preview before/after amounts, dates, cadence, cost contributions and cancellations; blank means unchanged; zero explicitly removes fee contribution. Apply authorized changes with old-version checks and row-level results.

Database contract: REQUIRED recurring_change_jobs/rows(plan_id,expected_version,before_json,after_json,result), recurring_plan_events, crm_sync_jobs.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Unknown ID is a visible row error; stale row rejected; blank preserves value; zero removes costs; cancelled plan not silently reactivated.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Update Recurring Payment Plans (RPP) via Import

Track expected cash/check gifts as commitments and match each occurrence to an actually received gift; never book expected amounts as paid.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Track expected cash/check gifts as commitments and match each occurrence to an actually received gift; never book expected amounts as paid.

Database contract: REQUIRED recurring_plans(collection_mode), recurring_occurrences, occurrence_gift_links(unique donation_id), missed_occurrence_reasons.

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Expected unpaid occurrence excluded from receipts; one gift cannot fulfill twice; cancelling future schedule preserves prior gifts.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Managing Recurring Cash, Check, and Offline Payments

Replace coarse role assumptions with named capabilities for each write/read/refund/export/import/publishing operation and report.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Replace coarse role assumptions with named capabilities for each write/read/refund/export/import/publishing operation and report.

Database contract: roles, capability_definitions, role_capabilities, organization_user_roles, permission_change_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Finance view does not imply refund permission; care access remains separate; revoked permissions apply immediately.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Givecloud Account: User Permissions

Enroll staff authentication factor, require challenge for privileged login, store hashed recovery codes and auditable resets.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Enroll staff authentication factor, require challenge for privileged login, store hashed recovery codes and auditable resets.

Database contract: account_factors(encrypted_secret), recovery_codes(hash,used_at), authentication_challenges, sessions

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Replay challenge rejected; recovery code one use; factor removal requires reauthentication.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Setup Two Factor Authentication on your Givecloud Account

Provide time-limited staff assistance with visible impersonation banner, constrained capabilities and full actor/subject audit.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Provide time-limited staff assistance with visible impersonation banner, constrained capabilities and full actor/subject audit.

Database contract: support_sessions(staff_account_id,subject_person_id,organization_id,reason,expires_at), assistance_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Cannot access donor other-church history; cannot authorize charge or alter PIN as donor; expiry enforced.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How To Login As the Supporter/Donor In Givecloud

Screen eligible payment identities via approved provider; retain match evidence and human disposition without claiming a name match is conclusive.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Screen eligible payment identities via approved provider; retain match evidence and human disposition without claiming a name match is conclusive.

Database contract: screening_jobs, match_candidates, review_decisions, payment_holds

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Potential match held for review; timeout not silently cleared; reviewer decisions audited.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How Givecloud Leverages OFAC Sanctions List

Verify selected high-risk checkout contact with expiring, rate-limited challenges before payment authorization.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Verify selected high-risk checkout contact with expiring, rate-limited challenges before payment authorization.

Database contract: verification_challenges(hash,attempts,expires_at,purpose), delivery_jobs, risk_decisions

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Code reuse and brute force blocked; challenge tied to same checkout/contact; provider outage visible.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• One-Time Code Verification for Donations

Offer eligible pickup or shipping per item and preserve fulfillment method on order lines.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Offer eligible pickup or shipping per item and preserve fulfillment method on order lines.

Database contract: fulfillment_methods, pickup_locations, order_fulfillment_groups, status_events

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Pickup has no shipping charge; mixed delivery groups priced correctly; cancellation releases reserved stock.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• Shipping: In-Store Purchases and Pick-up

Grant authenticated, expiring access to purchased downloadable or streamable content after verified payment.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Grant authenticated, expiring access to purchased downloadable or streamable content after verified payment.

Database contract: digital_assets, purchase_entitlements, access_tokens(hash,expires_at), access_logs

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Guessed asset IDs denied; refunded entitlement revoked; private file never directly public.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Sell Downloadable or Streamable Content

Enforce configured item minimum/maximum per order and membership eligibility before reserving stock.

Acceptance: See individual specification below.

Dependency: Implementation and source restriction reconciliation still required.

Source behavior / boundary: The linked Givecloud help article documents this capability. Detailed compatibility and configuration restrictions must be reconciled before parity acceptance.

Matthew25 workflow: Enforce configured item minimum/maximum per order and membership eligibility before reserving stock.

Database contract: product_purchase_limits, cart_lines, inventory_reservations

Who can do what: Church-scoped staff capability; donors can change only their own authorizations. Every query and external mapping includes the receiving organization.

Validation and recovery: Validate before commit; preserve prior version and audit; retry external operations with stable idempotency keys; surface unresolved rows without reporting success.

Required acceptance tests: Client quantity tampering rejected; bundles consume component stock once.

Actual implementation evidence: Not implemented. Proposed data structures are design requirements, not installed tables.

• How to Edit the Quantity Selection Limit

Configure maturity rules and track eligible, mature and ended beneficiary records while preserving sponsorship history.

Acceptance: See individual specification below.

Dependency: Additional maturity alerts and broad-load operational checks remain.

Source behavior / boundary: Maturity and finite-term lifecycle; Additional maturity alerts and broad-load operational checks remain.

Matthew25 workflow: Mature profiles are excluded from new enrollment without automatically cancelling their existing sponsors. Staff graduate/archive profiles; due finite terms close via the scheduled worker.

Database contract: Program maturity age, beneficiary DOB/status, relationship ends_on/ended_on, versioned recurring authorization and worker_runs evidence.

Who can do what: Church staff controls program policy; non-public CLI worker processes due church-timezone terms.

Validation and recovery: Future terms cannot starve due work; maturity does not silently terminate valid support; repeat worker runs are idempotent.

Required acceptance tests: Actual CLI closed an expired isolated term, left a future term active and did not duplicate closure on replay.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Additional maturity alerts and broad-load operational checks remain.

• Sponsorships: Add or Edit the Age of Maturity for your Sponsees
• Getting Started with Child Sponsorship

Stage beneficiary and sponsor records, validate identifiers and relationships, review duplicate candidates, then import with row-level outcomes.

Acceptance: See individual specification below.

Dependency: XLSX/mapping UI, bulk images, sponsor relationship imports and verified provider recurring-token migration remain.

Source behavior / boundary: Sponsorship source imports; XLSX/mapping UI, bulk images, sponsor relationship imports and verified provider recurring-token migration remain.

Matthew25 workflow: Staff preview CSV profiles and timelines, inspect errors, authorize the queued import and retry conflicts. Reference-based partial updates preserve omitted fields; source-key replay avoids duplicate profiles, updates and notices.

Database contract: tenant_import_batches extended types, rows with polymorphic result links, church-specific integration_external_records, normalized dates/custom values, immutable update revisions.

Who can do what: Congregation staff only; worker rechecks current author permission and church ownership before applying.

Validation and recovery: Unknown program/bundle/choice, duplicate source rows, wrong profile mapping and invalid dates fail preview or guarded application. No imported payment tokens or new charges are fabricated.

Required acceptance tests: Thirteen import checks passed for preview isolation, normalized choices, idempotent replays, partial updates and immutable timeline edits. Existing worker recovery checks remain covered.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. XLSX/mapping UI, bulk images, sponsor relationship imports and verified provider recurring-token migration remain.

• How do I Import my Sponsorship Database?
• Sponsorship Import Template

Matthew25 release requirement: Event-triggered email. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify event-triggered email through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Template personalization. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify template personalization through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Branded message templates. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify branded message templates through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Staff notifications. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify staff notifications through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Supporter notifications. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify supporter notifications through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Daily/weekly/monthly insights. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify daily/weekly/monthly insights through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: SMS keyword giving. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify sms keyword giving through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Text pledges. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify text pledges through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Custom text responses. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify custom text responses through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Suppression and unsubscribe. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify suppression and unsubscribe through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Website page editor. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify website page editor through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Reusable custom templates, richer formatting, video blocks and broader site design controls still require implementation.

Source behavior / boundary: Church website editor; official articles reviewed where listed. Reusable custom templates, richer formatting, video blocks and broader site design controls still require implementation.

Matthew25 workflow: Church staff compose ordered hero, text, quotation, image, gallery, button, giving, store, event and contact sections; save an immutable draft; preview; publish or remove it.

Database contract: site_pages separates draft_version, published_version, scheduled_version and optimistic row version; site_page_versions stores immutable title, slug, access, metadata and block snapshots; media_assets stores sanitized images and SHA-256.

Who can do what: Church congregation staff edit. Public visitors read approved public snapshots; private pages and direct image URLs require current congregation or paid membership entitlement.

Validation and recovery: Reject foreign church references, executable URLs, stale versions, invalid images and archiving referenced media. Saving a draft cannot alter published content.

Required acceptance tests: Save draft, confirm unchanged published view, publish, then revoke a membership and deny both resource page and image.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Reusable custom templates, richer formatting, video blocks and broader site design controls still require implementation.

• How to Design your Website: The Basics
• Unpublish or remove a page from your Givecloud Site
• How to Set a Page Online or Offline

Matthew25 release requirement: Website menus. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify website menus through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Vendor hero/top-left/top-right placement and additional typography/layout controls are separate remaining requirements.

Source behavior / boundary: Menus and hierarchy; official articles reviewed where listed. Vendor hero/top-left/top-right placement and additional typography/layout controls are separate remaining requirements.

Matthew25 workflow: Staff create ordered header and footer links to church pages or validated destinations, hide links, and nest them up to six levels. Published page links follow approved slugs and viewer entitlement.

Database contract: site_menus is church/placement unique; site_menu_items stores page or URL, parent, order, status, version; church-bound FKs and cycle checks guard hierarchy.

Who can do what: Church congregation staff configure; each visitor sees only allowed destinations.

Validation and recovery: Reject self-parent, cross-church parent, cross-menu placement and cycles; inaccessible page links disappear without exposing their titles.

Required acceptance tests: Create nested navigation, deny a cycle and foreign reference, verify signed-out menu omits protected resources.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Vendor hero/top-left/top-right placement and additional typography/layout controls are separate remaining requirements.

• Set Up and Edit Menus on Your Givecloud Website
• How to Create a Multilevel Menu

Matthew25 release requirement: Blog publishing. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify blog publishing through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Multiple feeds, categorization, podcast metadata, alternative feed templates and banner carousels remain distinct unimplemented requirements.

Source behavior / boundary: News and ministry stories; official articles reviewed where listed. Multiple feeds, categorization, podcast metadata, alternative feed templates and banner carousels remain distinct unimplemented requirements.

Matthew25 workflow: Staff create news posts in the same revision workflow; church news lists published stories and links to immutable approved content.

Database contract: site_pages.kind post, published snapshot, summary, SEO metadata, published_at and organization ownership.

Who can do what: Church staff publish; readers follow per-post visibility.

Validation and recovery: Draft or scheduled stories must not appear in public news or sitemaps; edited draft metadata must not leak.

Required acceptance tests: Six churches render published stories and exclude upcoming Advent drafts; live browser saved and published an additional story section.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Multiple feeds, categorization, podcast metadata, alternative feed templates and banner carousels remain distinct unimplemented requirements.

• How do I create a Blog/Feed?

Matthew25 release requirement: Scheduled content publishing. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify scheduled content publishing through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Runtime cron is installed; extended-load and failure-notification coverage remain wider operational acceptance.

Source behavior / boundary: Scheduled publication; official articles reviewed where listed. Runtime cron is installed; extended-load and failure-notification coverage remain wider operational acceptance.

Matthew25 workflow: Staff schedule a selected saved revision in the church timezone. The background worker publishes that pinned revision when its UTC timestamp is due; later edits remain drafts.

Database contract: site_pages.scheduled_version and publish_at reference immutable site_page_versions; worker_runs records each worker outcome.

Who can do what: Staff schedule only their church; CLI worker has no public entry point.

Validation and recovery: SKIP LOCKED and per-worker locks prevent duplicate work; stale controls reject, failed publications are audited and unscheduled for review.

Required acceptance tests: Run actual CLI worker against a due fictional page; confirm exact revision, clear schedule and prove a repeat run does not republish.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Runtime cron is installed; extended-load and failure-notification coverage remain wider operational acceptance.

Matthew25 release requirement: Custom domain verification. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify custom domain verification through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Secure domain certificates. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify secure domain certificates through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Content revision rollback. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify content revision rollback through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Full product acceptance remains open.

Source behavior / boundary: Content revision rollback; official articles reviewed where listed. Full product acceptance remains open.

Matthew25 workflow: Staff select an earlier revision, which is copied to a new immutable revision and published. The original version history remains unchanged.

Database contract: site_page_versions persists content and editor/time; site_pages independent row/content versions prevent publication state from overwriting concurrent draft edits.

Who can do what: Church congregation staff only; actor and church are audited.

Validation and recovery: Stale rollback controls, foreign page IDs and unavailable revisions fail transactionally. Old published slugs gain a safe redirect when changed.

Required acceptance tests: Publish revised content, restore the original snapshot into a new revision, confirm original title and address.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Full product acceptance remains open.

Matthew25 release requirement: Managed redirects. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify managed redirects through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Temporary 302, delayed-message redirect, product/default-option destinations and broader URL routing remain pending.

Source behavior / boundary: Managed redirects; official articles reviewed where listed. Temporary 302, delayed-message redirect, product/default-option destinations and broader URL routing remain pending.

Matthew25 workflow: Changed published page slugs create permanent redirects automatically. Staff may add same-church published-page redirects; reverse stale rules are disabled during rename.

Database contract: site_redirects stores church, source/target slug, status, and version; unique source key prevents competing active rules.

Who can do what: Church congregation staff configure, public GET follows approved redirects.

Validation and recovery: Reject loops, self-targets and unpublished destinations. Redirect targets cannot transfer visitors to arbitrary external hosts.

Required acceptance tests: Rename a published page, resolve the old address, reject a redirect cycle and restore earlier content.

Actual implementation evidence: 0.6.0: 26 transactional site checks, 15 worker lifecycle checks, 89 live HTTPS checks; mobile 390px and desktop 1440px publication/contact flow verified. Temporary 302, delayed-message redirect, product/default-option destinations and broader URL routing remain pending.

• How to Set Up URL Redirects on Your Website

Matthew25 release requirement: WordPress embedding. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify wordpress embedding through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Durable church inbox, customizable form fields, recipient notifications, CC/BCC and bot protection.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Church inbox, assignment, fixed fields and anti-abuse implemented; configurable fields and notification delivery remain.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Permanent, temporary and delayed-message redirects, including product destinations.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Source-derived subrequirements retained for complete parity.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Distinct blogs, directories, feed categories, post categories and feed-specific display templates.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Source-derived subrequirements retained for complete parity.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Podcast-specific tags, media metadata and subscriber feed generation.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Source-derived subrequirements retained for complete parity.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Ordered image feeds and homepage banners with accessible controls.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Source-derived subrequirements retained for complete parity.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Hero, top-left and top-right menus with independent theme controls.

Acceptance: Exercise the complete configured lifecycle, church boundary, privacy rules and failure recovery.

Dependency: Source-derived subrequirements retained for complete parity.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: DonorPerfect synchronization. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donorperfect synchronization through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: DonorPerfect field mappings. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donorperfect field mappings through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Historical CRM giving. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify historical crm giving through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: CRM duplicate matching. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify crm duplicate matching through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Split gift / individual gift mapping. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify split gift / individual gift mapping through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Salesforce synchronization. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify salesforce synchronization through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: SafeSave connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify safesave connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Stripe connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify stripe connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Authorize.net connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify authorize.net connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Braintree connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify braintree connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Vanco connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify vanco connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Paysafe connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify paysafe connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: NMI connector. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify nmi connector through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple gateway accounts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple gateway accounts through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: API credentials and scopes. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify api credentials and scopes through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Outbound webhooks. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify outbound webhooks through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Self-service imports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify self-service imports through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Import preview and recovery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify import preview and recovery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Scoped exports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify scoped exports through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Analytics tags. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify analytics tags through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Conversion funnels. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify conversion funnels through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Recommendation experiments. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify recommendation experiments through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Trained recommendation models. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify trained recommendation models through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Satisfaction surveys. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify satisfaction surveys through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Supporter segmentation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify supporter segmentation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Immutable audit history. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify immutable audit history through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Background job recovery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify background job recovery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Server-side release history. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify server-side release history through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Rollback verification. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify rollback verification through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Combined personal giving history. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify combined personal giving history through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church-specific donation letters. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church-specific donation letters through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Recurring commitments dashboard. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify recurring commitments dashboard through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Payment token management. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify payment token management through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Donor contact self-service. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donor contact self-service through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Purchased ticket access. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify purchased ticket access through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Email-link sign-in. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify email-link sign-in through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: External social sign-in. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify external social sign-in through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: OpenID Connect sign-in. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify openid connect sign-in through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Cross-domain identity handoff. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify cross-domain identity handoff through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Event registrations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify event registrations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor provides ticket registration pages and optional additional donations.

Matthew25 workflow: Publish a church event with timezone, location, capacity and priced ticket products; collect names and answers for every purchased seat; issue private tickets after payment.

Database contract: ministry_events, commerce_products/event_id, commerce_order_lines snapshots, event_tickets with unique order-line ordinal and opaque token.

Who can do what: Church congregation staff manage events and attendance; purchasers manage their own unused tickets.

Validation and recovery: Unpublished, closed, ended, full or cancelled events cannot accept new registration.

Required acceptance tests: Verify two distinct attendees, required response validation, six branded event pages and private purchaser portal.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Create a Page to Sell Multiple Event Tickets

Matthew25 release requirement: Ticket inventory and capacity. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify ticket inventory and capacity through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor documents both per-variant stock and an overall event sales limit.

Matthew25 workflow: Ticket variants share a parent event capacity; held reservations and valid issued tickets both count.

Database contract: ministry_events.capacity, commerce_reservations.event_id and event_tickets.status are read under the event lock.

Who can do what: Staff may not reduce capacity below valid tickets plus holds.

Validation and recovery: Concurrent buyers serialize on the event row; refunds revoke tickets and release future admission capacity.

Required acceptance tests: Independent processes compete for a one-seat event; one succeeds, cancellation releases it for reuse.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Track Stock and Inventory for Your Products

Matthew25 release requirement: Attendee custom fields. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify attendee custom fields through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor event registrations support custom fields through configured registration options.

Matthew25 workflow: Staff define required text or choice questions; checkout captures each attendee response; the purchased question definitions stay with the immutable order.

Database contract: ministry_events.attendee_fields JSON definitions, order snapshot definitions, event_tickets.answers and version.

Who can do what: Purchaser can correct own unused attendees; church event staff can review scoped answers.

Validation and recovery: Unknown choices, missing required answers, invalid email, and edits to used/refunded tickets are rejected.

Required acceptance tests: Capture vegetarian meal selection; reject missing response; preserve old question meaning after event edits.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Create a Page to Sell Multiple Event Tickets

Matthew25 release requirement: Event sponsorship packages. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify event sponsorship packages through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: QR ticket admission. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify qr ticket admission through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: The official feature page advertises QR tickets and check-in.

Matthew25 workflow: Paid registration yields an opaque private ticket URL and locally generated QR image. Authorized event staff confirm entry; scans alone never mutate attendance.

Database contract: event_tickets.token, status, inside and entry count; event_admissions appends direction, actor, time and unique request key.

Who can do what: Ticket owner and church staff can view; only congregation-authorized staff can admit.

Validation and recovery: Reject invalid/voided tickets, repeated single-entry admission and entry outside the event window.

Required acceptance tests: Render QR tickets through HTTPS; transaction checks cover replay and re-entry. Physical phone camera scan remains to verify.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

Matthew25 release requirement: Repeat-entry policies. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify repeat-entry policies through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor lists ticket admission/check-in; exact repeat-entry behavior needs further source reconciliation.

Matthew25 workflow: Choose single admission or repeated entry after check-out. Current ticket row serializes concurrent scans.

Database contract: ministry_events.entry_policy, event_tickets.inside/entries, append-only event_admissions.

Who can do what: Church event staff only.

Validation and recovery: Reject entry while inside, exit while outside, and a second single-policy entry after leaving.

Required acceptance tests: Replay one request without adding an entry; reject duplicate; exit and allow re-entry only after policy permits it.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

Matthew25 release requirement: Attendance reporting. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify attendance reporting through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor lists attendee reporting.

Matthew25 workflow: Church event page summarizes capacity, issued valid seats and attendees with entry history; authorized CSV includes responses and admission counts.

Database contract: Queries are bounded to ministry_events.organization_id and associated event_tickets; export creates audit evidence.

Who can do what: Congregation staff can export their church event; donors cannot access attendee lists.

Validation and recovery: Foreign event IDs are denied and spreadsheet formula prefixes are neutralized.

Required acceptance tests: Download actual attendee CSV for each of six churches and enforce cross-tenant ticket denial.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

Matthew25 release requirement: Virtual event video. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify virtual event video through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Moderated event conversation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify moderated event conversation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Live event pledges. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify live event pledges through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Event sales-tax calculation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify event sales-tax calculation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Ticket/product bundles. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify ticket/product bundles through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Event discount codes. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify event discount codes through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Campaign discovery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify campaign discovery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: General church giving funds. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify general church giving funds through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Designated project funds. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify designated project funds through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Campaign pages and stories. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify campaign pages and stories through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Outcome-based donation choices. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify outcome-based donation choices through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Form visual editor. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify form visual editor through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church brand settings. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church brand settings through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Partner-branded campaigns. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify partner-branded campaigns through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Hosted donation pages. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify hosted donation pages through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Inline donation forms. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify inline donation forms through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Popup donation forms. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify popup donation forms through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Embeddable donor recognition. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify embeddable donor recognition through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Embeddable progress tracking. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify embeddable progress tracking through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Guided checkout. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify guided checkout through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: QR giving entry. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify qr giving entry through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Currency-aware checkout. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify currency-aware checkout through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Translated giving forms. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify translated giving forms through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Personalized suggested amounts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify personalized suggested amounts through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Tribute donations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify tribute donations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Ecard delivery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify ecard delivery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Anonymous public recognition. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: 0.12.0: 70 lifecycle, 162 rendering/filter, 90 HTTPS checks and 10 regression suites passed. Donors and authorized finance staff control public recognition on received fundraising gifts and future recurring checkouts independently from the private donor identity.

Dependency: Broader giving-experience recognition widgets and donor-wide bulk privacy management remain unfinished.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Donor messages. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donor messages through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Business contributions. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify business contributions through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple-fund allocations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple-fund allocations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Custom donation fields. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify custom donation fields through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Campaign sharing links. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify campaign sharing links through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Short campaign links. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify short campaign links through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Abandonment reminders. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify abandonment reminders through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Countdown and fundraising goals. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify countdown and fundraising goals through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Video thank-you messages. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify video thank-you messages through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Custom next-action links. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify custom next-action links through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Referral attribution. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify referral attribution through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Shared network identity. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify shared network identity through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Phone and PIN access. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify phone and pin access through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Verification and account recovery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify verification and account recovery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple phone numbers. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple phone numbers through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple email addresses. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple email addresses through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple mailing addresses. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple mailing addresses through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Receipt identity and salutations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify receipt identity and salutations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Household relationships. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify household relationships through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented portions and remaining limits are recorded in the detailed specification. Full release acceptance is not met.

Source behavior / boundary: Matthew25 congregation extension; do not equate church households with Givecloud purchased memberships.

Matthew25 workflow: Congregation staff create a household, select a church campus, link consented congregants with relationship labels, end relationships, and archive or restore the household. No relationship shares financial or care access.

Database contract: INSTALLED: church_households(id,organization_id,name,campus_id,status,version); household_members(id,organization_id,household_id,person_id,relationship,status,joined_at,ended_at). Composite foreign keys constrain campus, household and congregation to the same church.

Who can do what: Organization congregation staff; household membership does not authorize access. Global profile edits remain donor/platform controlled.

Validation and recovery: Lock household while updating; reject stale versions, foreign campuses, archived household additions and nonconsented members. Retain ended links.

Required acceptance tests: Update relationship twice produces one row; foreign-church campus rejected; end relationship retains record; archive/restore round-trip.

Actual implementation evidence: 0.3.0 server workflow; transaction tests cover duplicate links, history and tenant constraints. Global household-sharing invitations remain a distinct unfinished extension. Follow-up: authenticated live route passed; mobile campus/household creation and full-cost estimate checked at 390px without overflow.

Matthew25 release requirement: Business donor contacts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Twelve corporate profiles and twelve relationships seeded; local ownership and loss of editing authority when another church connects were checked.

Dependency: Relationship roles, seasonal addresses, stronger corporate identity verification, shared-profile change approval and bidirectional relationship reporting remain.

Source behavior / boundary: Business supporter identity and organization receipt name.

Matthew25 workflow: Create company/foundation donors with exact legal receipt identity, mailing address, phone and email. Link local employer, family, board or other relationships with role, dates, notes and history.

Database contract: Global persons/contact tables retain corporate receipt identity; church membership and organization_person_profiles remain separate from donor_relationships. Multiple phone/email/address rows continue to use the common profile editor.

Who can do what: Staff may maintain a church-owned unclaimed corporate contact profile only while it belongs to one church and has no login. Shared or claimed identities retain owner/platform editing boundaries.

Validation and recovery: Creating an organization prospect does not invent marketing consent. Foreign roster links, self-relations, invalid date ranges and stale updates are rejected.

Required acceptance tests: Twelve corporate profiles and twelve relationships seeded; local ownership and loss of editing authority when another church connects were checked.

Actual implementation evidence: 0.9.0 corporate contact profiles and church relationships verified. Relationship roles, seasonal addresses, stronger corporate identity verification, shared-profile change approval and bidirectional relationship reporting remain.

• How do I keep track of supporter types?
• DonorPerfect donor management

Matthew25 release requirement: Duplicate profile review and merge. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify duplicate profile review and merge through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church-specific profile consent. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church-specific profile consent through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Multiple congregation memberships. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify multiple congregation memberships through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Membership classification. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify membership classification through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church-local member numbers. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church-local member numbers through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church role permissions. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church role permissions through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Campuses and ministry groups. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify campuses and ministry groups through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Server transactions, HTTP workflows and access checks verified. Full product release acceptance remains incomplete.

Source behavior / boundary: Matthew25 congregation extension.

Matthew25 workflow: Manage multiple campus addresses and phones; assign households and volunteer shifts to an active campus. Ministry groups retain their existing roster and attendance workflows.

Database contract: INSTALLED church_campuses(id,organization_id,name,address_line1,address_line2,city,region,postal_code,country,phone,status,version). Unique organization/name and composite id/organization key.

Who can do what: Congregation managers and organization administrators only.

Validation and recovery: Validate country and E.164 phone; optimistic version; archived campuses cannot be newly assigned; referenced history remains.

Required acceptance tests: Persist all address fields; reject stale save and cross-church campus; archived campus excluded from new selection.

Actual implementation evidence: 0.3.0 implemented, server tests passed for persistence/stale/cross-church constraints; existing groups in 0.2.0. Follow-up: authenticated live route passed; mobile campus/household creation and full-cost estimate checked at 390px without overflow.

Matthew25 release requirement: Group attendance. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify group attendance through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Volunteer assignments. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify volunteer assignments through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Server transactions, HTTP workflows and access checks verified. Full product release acceptance remains incomplete.

Source behavior / boundary: Matthew25 congregation extension.

Matthew25 workflow: Coordinator creates bounded-capacity shifts, invites connected congregants, and records acceptance, cancellation and completed service minutes. Donors respond for themselves. Shift cancellation releases pending places without removing history.

Database contract: INSTALLED volunteer_shifts(organization_id,campus_id,starts_at,ends_at,capacity,status,version); volunteer_assignments(organization_id,shift_id,person_id,status,hours_minutes). Unique shift/person.

Who can do what: Coordinator writes assignments and completion; donor only own accept/decline/cancel.

Validation and recovery: Lock shift before capacity calculation; invitations, accepted and completed places consume capacity. Reject overbooking, wrong person, inactive member and stale shift edit.

Required acceptance tests: Capacity-one invitation blocks second reservation; donor cannot alter others or certify hours; authorized completion records minutes; cancelled shifts reject signup.

Actual implementation evidence: 0.3.0 server actions and screens implemented; assignment capacity and permission tests passed. Concurrent HTTP test still required. Follow-up: concurrent HTTP overbooking test exposed a repeatable-read snapshot bug; changed reserved-place reads to locking current reads and the race passed. Authenticated HTTP rendering also passed.

Church staff create dated calls, visits, emails, meetings and notes. Authors or church administrators revise or archive them; staff can include archived entries and read original and revised content.

Acceptance: Unauthorized staff revision rejection and immutable original retention passed. Twelve showroom notes across six churches each retain two revisions; all six live profiles show archived history only when requested.

Dependency: Advanced configurable note privacy groups and bulk interaction import remain additional native CRM scope.

Source behavior / boundary: Staff record supporter interactions; note authors and account owners may revise or delete notes.

Matthew25 workflow: Church staff create dated calls, visits, emails, meetings and notes. Authors or church administrators revise or archive them; staff can include archived entries and read original and revised content.

Database contract: crm_notes holds the current church/person/author, category, date, body, active-or-archived status and version; crm_note_versions stores immutable JSON content, actor and timestamp. Legacy originals are snapshotted on first revision.

Who can do what: Congregation permission and current church context required. Only author, church administrator or platform administrator can revise another note; donors never see internal notes.

Validation and recovery: Optimistic versions reject stale updates. Archive preserves prior content and revisions rather than destructively erasing interaction history. All text is escaped in display.

Required acceptance tests: Unauthorized staff revision rejection and immutable original retention passed. Twelve showroom notes across six churches each retain two revisions; all six live profiles show archived history only when requested.

Actual implementation evidence: Release 0.10.0 server evidence: Unauthorized staff revision rejection and immutable original retention passed. Twelve showroom notes across six churches each retain two revisions; all six live profiles show archived history only when requested. Advanced configurable note privacy groups and bulk interaction import remain additional native CRM scope.

• How to Add Notes to a Supporter Profile

Matthew25 release requirement: Communication preferences. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify communication preferences through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Consent controls implemented; delivery services are not connected.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Directory visibility. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify directory visibility through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Server transactions, HTTP workflows and access checks verified. Full product release acceptance remains incomplete.

Source behavior / boundary: Matthew25 donor-controlled congregation directory extension.

Matthew25 workflow: Each connected donor chooses whether to list their name, preferred phone and preferred email separately for each church. Only connected congregants and congregation staff see the list.

Database contract: INSTALLED directory_choices(person_id,organization_id,show_name,show_phone,show_email,consent_id,version); immutable consent_events with directory notice version. Directory joins active membership and active person.

Who can do what: Only the donor can change their directory choices; staff cannot opt a donor in. Addresses, gifts and care notes never enter the directory response.

Validation and recovery: Turning off name also turns off phone/email; leaving suppresses entry dynamically; church A choices never propagate to church B.

Required acceptance tests: Independent channel flags; opt-out removes contacts; departed donor cannot opt in; second church unchanged; unconnected account denied.

Actual implementation evidence: 0.3.0 server tests cover consent flags and church isolation; live UI validation pending.

Matthew25 release requirement: Account invitations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify account invitations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Private invitation enrollment and replay rejection tested; public SMS enrollment still requires a messaging provider.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Staff create donor plans with goals, dates, owner, stage, strategy and outcome, using a reusable sequence or individual moves. Completed plans require every outstanding task to be closed.

Acceptance: 41 lifecycle checks and browser save: Grace plan 4 changed from two to three completed moves; net received stayed 500 dollars.

Dependency: Group/segment enrollment, bulk plan assignment, prospect scoring and advanced automation remain.

Source behavior / boundary: Benchmark: Cultivation plans and outcomes. Native implementation and remaining scope are separated below.

Matthew25 workflow: Staff create donor plans with goals, dates, owner, stage, strategy and outcome, using a reusable sequence or individual moves. Completed plans require every outstanding task to be closed.

Database contract: cultivation_plans owns church/person/template, owner role, goal currency, dated lifecycle and optimistic version; cultivation_moves links canonical crm_tasks rather than copying task state.

Who can do what: Congregation staff owns plans; finance alone links or reads received-gift recognition. Donors cannot read staff plans.

Validation and recovery: Request keys prevent repeat creation, stale versions reject overwrites, parent locks protect completion and task reopening, cancellation closes unfinished moves.

Required acceptance tests: 41 lifecycle checks and browser save: Grace plan 4 changed from two to three completed moves; net received stayed 500 dollars.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Group/segment enrollment, bulk plan assignment, prospect scoring and advanced automation remain.

• DonorPerfect moves management

Staff define active or archived templates and up to 60 active calls, emails, visits, meetings or custom moves with offsets, priority, instructions and display order. New plans copy the sequence.

Acceptance: Template copy, offset dates, duplicate plan submission and lifecycle protection passed; six templates and 108 populated moves are available.

Dependency: Additional template import and bulk-edit tooling remains broader roadmap scope.

Source behavior / boundary: Benchmark: Reusable cultivation sequences. Native implementation and remaining scope are separated below.

Matthew25 workflow: Staff define active or archived templates and up to 60 active calls, emails, visits, meetings or custom moves with offsets, priority, instructions and display order. New plans copy the sequence.

Database contract: cultivation_templates and cultivation_template_steps preserve archived versions; instantiated plans retain the original instructions and due dates in their own moves/tasks.

Who can do what: Church congregation staff only; templates and assigned accounts must belong to the same church.

Validation and recovery: Reject foreign templates, stale changes, invalid due dates and reactivation above the active-step limit. Editing a template does not rewrite existing plans.

Required acceptance tests: Template copy, offset dates, duplicate plan submission and lifecycle protection passed; six templates and 108 populated moves are available.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Additional template import and bulk-edit tooling remains broader roadmap scope.

• DonorPerfect moves management

Due active plan and grant tasks generate one daily staff reminder. Staff create a private read-only calendar subscription and can revoke it immediately. Task changes appear on the next calendar refresh.

Acceptance: Reminder replay prepared six previews then zero duplicates; actual scheduled worker succeeded. HTTPS creation, calendar body and immediate revocation passed.

Dependency: Bidirectional Google/Microsoft calendar APIs, per-user delivery preferences and live email-provider acceptance remain.

Source behavior / boundary: Benchmark: Staff reminders and subscribed calendars. Native implementation and remaining scope are separated below.

Matthew25 workflow: Due active plan and grant tasks generate one daily staff reminder. Staff create a private read-only calendar subscription and can revoke it immediately. Task changes appear on the next calendar refresh.

Database contract: crm_task_reminders uniquely keys task/account/day and links outgoing_messages; hashed crm_calendar_tokens and worker_runs retain delivery and execution evidence. Calendar events use church timezone and stable task identifiers.

Who can do what: Current staff role, active account, active church and current assignment are checked for reminders and feeds. Private interaction notes and donor contact details are excluded from calendar/reminder content.

Validation and recovery: Paused/completed/cancelled plans, archived/declined grants, changed assignment, expired reminder date and lost permissions suppress queued notices. Secrets are stored hashed and rendered once.

Required acceptance tests: Reminder replay prepared six previews then zero duplicates; actual scheduled worker succeeded. HTTPS creation, calendar body and immediate revocation passed.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Bidirectional Google/Microsoft calendar APIs, per-user delivery preferences and live email-provider acceptance remain.

• DonorPerfect moves management

Finance staff maintain funder type, interests, geography, award range and guidelines; track application stages, assigned owner, requested and awarded amounts, submission/decision dates and receiving fund.

Acceptance: Three application stages per church, full lifecycle and all six live grant pages passed; awards and actual receipts are shown separately.

Dependency: Automated external grant discovery is a separate provider capability.

Source behavior / boundary: Benchmark: Foundation research and grant applications. Native implementation and remaining scope are separated below.

Matthew25 workflow: Finance staff maintain funder type, interests, geography, award range and guidelines; track application stages, assigned owner, requested and awarded amounts, submission/decision dates and receiving fund.

Database contract: grant_funder_profiles uses a church business donor; grant_applications stores immutable identity once funded, reference, stage, currency and optimistic version. Application documents have independent revisions.

Who can do what: Church finance staff only. Funder, receiving fund and assigned finance account are validated inside the church.

Validation and recovery: Reject invalid chronology, unrecorded award decisions, declined applications with awards, and rewriting a funded grant into a pre-award state. Archiving cancels outstanding tasks.

Required acceptance tests: Three application stages per church, full lifecycle and all six live grant pages passed; awards and actual receipts are shown separately.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Automated external grant discovery is a separate provider capability.

• DonorPerfect grant management

Attach inquiry, proposal, decision and reporting deadlines to assigned tasks. Link actual received funder gifts to the approved grant and designated fund; reports show refund-adjusted receipts separately from awards.

Acceptance: Actual grant payment/refund checks passed; 24 obligations and six received installments seeded across six churches.

Dependency: Grant expense budgets, restricted-fund spending reconciliation, indirect costs and full ROI reporting remain.

Source behavior / boundary: Benchmark: Grant obligations and received funding. Native implementation and remaining scope are separated below.

Matthew25 workflow: Attach inquiry, proposal, decision and reporting deadlines to assigned tasks. Link actual received funder gifts to the approved grant and designated fund; reports show refund-adjusted receipts separately from awards.

Database contract: grant_requirements links canonical tasks; grant_gifts references actual donations with unique allocation per gift in this reporting dimension. Refunds are calculated from authoritative gift balances.

Who can do what: Finance permission required for tasks, gift linking, documents and CSV export. Grant receipts never create a second donation or donor tax acknowledgement.

Validation and recovery: Wrong donor/fund, pre-award funding links, over-recognition and erasing funded history are rejected. Documents and financial history survive closure.

Required acceptance tests: Actual grant payment/refund checks passed; 24 obligations and six received installments seeded across six churches.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Grant expense budgets, restricted-fund spending reconciliation, indirect costs and full ROI reporting remain.

• DonorPerfect grant management

Record employer ratios, gift minimums, claim/annual maximums, deadlines and instructions. Claims retain policy snapshots; approval and actual employer receipts remain distinct. Allocate one employer payment across claims without counting money twice.

Acceptance: Two independent concurrent processes allocated one gift once and rejected the conflicting allocation. Actual worker changed a fully received claim back to approved after an employer refund; net receipt is 450 dollars against 500 approved.

Dependency: Licensed employer search services, employee self-submission and provider certification remain.

Source behavior / boundary: Benchmark: Employer programs and matching receipts. Native implementation and remaining scope are separated below.

Matthew25 workflow: Record employer ratios, gift minimums, claim/annual maximums, deadlines and instructions. Claims retain policy snapshots; approval and actual employer receipts remain distinct. Allocate one employer payment across claims without counting money twice.

Database contract: matching_gift_programs, extended matching_gifts, matching_gift_receipts and refund-triggered development_reconcile_jobs preserve original policy, actual funding, proportional refund recognition, request/response dates and external references.

Who can do what: Finance staff only, scoped original donor and employer gifts, church merchant and original financial records.

Validation and recovery: Parent gift locks and read-committed transactions prevent overallocation; bounded retries handle serialization failures. Refunded employer money reduces each claim proportionally; original donor refunds reduce current eligibility and flag overfunding.

Required acceptance tests: Two independent concurrent processes allocated one gift once and rejected the conflicting allocation. Actual worker changed a fully received claim back to approved after an employer refund; net receipt is 450 dollars against 500 approved.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Licensed employer search services, employee self-submission and provider certification remain.

• DonorPerfect donor management

Attach PDF, image, text, CSV, Word or Excel documents to donor, gift, pledge, cultivation, grant or matching records. Upload new immutable revisions and archive or restore each revision without deleting its bytes.

Acceptance: 18 seeded PDF downloads matched stored hashes. Live multipart uploads created two text revisions, preserved old bytes and archived the first; cross-church and donor downloads failed.

Dependency: Maximum document size is 1.9 MB; malware scanning and larger asynchronous file workflows need operational expansion.

Source behavior / boundary: Benchmark: Donor and development document vault. Native implementation and remaining scope are separated below.

Matthew25 workflow: Attach PDF, image, text, CSV, Word or Excel documents to donor, gift, pledge, cultivation, grant or matching records. Upload new immutable revisions and archive or restore each revision without deleting its bytes.

Database contract: crm_documents stores church/person/polymorphic target, random series, monotonic revision, sanitized filename/MIME, SHA-256 and server-side BLOB; Office containers reject macros and images discard metadata.

Who can do what: Each download rechecks its target-specific congregation or finance permission and church context. Anonymous users, donors and foreign church requests cannot read staff documents.

Validation and recovery: Reject wrong types, oversized uploads, wrong target/series, unsupported Office structure and byte-integrity mismatch. Archived revisions remain retrievable only by authorized staff.

Required acceptance tests: 18 seeded PDF downloads matched stored hashes. Live multipart uploads created two text revisions, preserved old bytes and archived the first; cross-church and donor downloads failed.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Maximum document size is 1.9 MB; malware scanning and larger asynchronous file workflows need operational expansion.

• DonorPerfect donor management

Create company/foundation donors with exact legal receipt identity, mailing address, phone and email. Link local employer, family, board or other relationships with role, dates, notes and history.

Acceptance: Twelve corporate profiles and twelve relationships seeded; local ownership and loss of editing authority when another church connects were checked.

Dependency: Relationship roles, seasonal addresses, stronger corporate identity verification, shared-profile change approval and bidirectional relationship reporting remain.

Source behavior / boundary: Benchmark: Church relationships and corporate profiles. Native implementation and remaining scope are separated below.

Matthew25 workflow: Create company/foundation donors with exact legal receipt identity, mailing address, phone and email. Link local employer, family, board or other relationships with role, dates, notes and history.

Database contract: Global persons/contact tables retain corporate receipt identity; church membership and organization_person_profiles remain separate from donor_relationships. Multiple phone/email/address rows continue to use the common profile editor.

Who can do what: Staff may maintain a church-owned unclaimed corporate contact profile only while it belongs to one church and has no login. Shared or claimed identities retain owner/platform editing boundaries.

Validation and recovery: Creating an organization prospect does not invent marketing consent. Foreign roster links, self-relations, invalid date ranges and stale updates are rejected.

Required acceptance tests: Twelve corporate profiles and twelve relationships seeded; local ownership and loss of editing authority when another church connects were checked.

Actual implementation evidence: 0.9.0: 41 lifecycle, 3 concurrent allocation, 4 actual worker, 84 screen rendering and 118 live HTTPS checks; 213 prior regression checks. Browser administrator phone/PIN and saved task verified. Relationship roles, seasonal addresses, stronger corporate identity verification, shared-profile change approval and bidirectional relationship reporting remain.

• DonorPerfect donor management

Staff archive a church donor record with a reason and can restore it. Active CRM lists, directory listings, cultivation reminders and fundraising mail exclude church-archived records. Staff can filter and inspect archived records.

Acceptance: Six-church shared Reese Donovan example is archived only at Grace; lifecycle tests and HTTPS pages verify other churches remain active. Existing global login and received totals remain intact.

Dependency: Global identity deletion is deliberately a different governed workflow; church archive is fully reversible.

Source behavior / boundary: Supporter archive and restoration hide inactive donor records without losing their retained history.

Matthew25 workflow: Staff archive a church donor record with a reason and can restore it. Active CRM lists, directory listings, cultivation reminders and fundraising mail exclude church-archived records. Staff can filter and inspect archived records.

Database contract: organization_person_profiles stores archived_at, archive_reason and optimistic version. Shared person, contacts, account, membership, immutable gifts, tax letters, subscriptions and recurring authorizations are preserved. Audit captures both operations.

Who can do what: Church congregation staff may archive only their own roster. One church cannot disable a shared donor login or alter another church archive state or consent.

Validation and recovery: Message dispatch rechecks church archive status; restoring a record reuses existing consent and does not fabricate opt-in. Donors can still cancel outstanding promises. Stale profile edits reject overwrite.

Required acceptance tests: Six-church shared Reese Donovan example is archived only at Grace; lifecycle tests and HTTPS pages verify other churches remain active. Existing global login and received totals remain intact.

Actual implementation evidence: Release 0.10.0 server evidence: Six-church shared Reese Donovan example is archived only at Grace; lifecycle tests and HTTPS pages verify other churches remain active. Existing global login and received totals remain intact. Global identity deletion is deliberately a different governed workflow; church archive is fully reversible.

• How to Archive/Un-archive a Supporter

Matthew25 release requirement: Card payments. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify card payments through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Bank debit / ACH. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify bank debit / ach through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: PayPal checkout. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify paypal checkout through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Apple Pay. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify apple pay through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Google Pay. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify google pay through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Donor-advised fund grants. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donor-advised fund grants through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Organization merchant routing. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify organization merchant routing through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented portions and remaining limits are recorded in the detailed specification. Full release acceptance is not met.

Source behavior / boundary: Givecloud documents multiple gateway options. User requires each Matthew25 church to have its own merchant account.

Matthew25 workflow: Church administrator registers processor account identity and environment. Verified connection must route every intent, recurring mandate, refund and settlement to the receiving church. Cross-church checkout requires separate authorized transactions.

Database contract: INSTALLED merchant_accounts(id,organization_id,provider,external_account_ref,environment,currency,status,verification_evidence,version). Unique provider/reference/environment prevents assignment to a second church. REQUIRED: payment_intents, payment_methods, mandates, refunds, settlements with composite merchant/organization keys.

Who can do what: Church administrator configures their routing; finance views their own records; platform onboarding must validate recipient ownership.

Validation and recovery: Registration creates unconfigured status only. No collection without verified provider credentials. Never assume a vault token works at another merchant.

Required acceptance tests: Two churches cannot share the same account record; token from merchant A cannot pay merchant B; webhook mismatch quarantined; recurring cancellation routed to original merchant.

Actual implementation evidence: 0.3.0 registry and unconfigured guard tested. Provider integration, tokenization, callbacks and real routing remain unimplemented.

• Supported Payment Gateways

Matthew25 release requirement: Zero / partial / full fee coverage. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify zero / partial / full fee coverage through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented portions and remaining limits are recorded in the detailed specification. Full release acceptance is not met.

Source behavior / boundary: Givecloud supports configured percentage/fixed cost coverage and form-level DCC visibility. Defaults differ among checkout types.

Matthew25 workflow: Finance versions cost policy; donor must choose none, half, full or custom in the future checkout. Current finance estimator persists each exact quote without creating a donation.

Database contract: INSTALLED fee_policies(rate_basis_points,fixed_minor,formula,explanation,created_by); fee_quotes(organization_id,person_id,policy_id,base_minor,suggested_minor,contribution_minor,selection,currency,policy_snapshot,expires_at). REQUIRED payment consent must link quote and amount.

Who can do what: Finance configures and previews; production checkout must obtain donor authorization for total including costs.

Validation and recovery: Integer arithmetic: gross-up ceil((base*bps+fixed*10000)/(10000-bps)); simple ceil((base*bps+fixed*10000)/10000). Reject invalid rate, negative/oversized contribution, expired checkout quote.

Required acceptance tests: 100 USD at 2.9%+0.30: gross-up 3.30, half 1.65, simple 3.20; custom 1.23 exact; none zero; policy edit preserves snapshot.

Actual implementation evidence: 0.3.0 finance estimator tested; donor checkout and payment integration unfinished. Follow-up: authenticated live route passed; mobile campus/household creation and full-cost estimate checked at 390px without overflow.

• How to set up Donor Covers Cost (DCC)
• GE: Payment & DCC

Matthew25 release requirement: Custom cost contribution. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify custom cost contribution through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented portions and remaining limits are recorded in the detailed specification. Full release acceptance is not met.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Adaptive cost suggestions. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify adaptive cost suggestions through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Source behavior / boundary: Givecloud Smart DCC presents tiered operational-cost choices using a proprietary, changing algorithm; it is not an exact processor-fee calculation.

Matthew25 workflow: Matthew25 must offer clearly labeled optional fundraising support with explicit zero option. Log model/rule version, presented tiers and donor selection; deploy a trained model only after validation against consented data.

Database contract: REQUIRED recommendation_models(version,training_window,metrics,status), cost_offers(organization_id,model_id,base_minor,tiers_json,selected_minor), experiments and outcomes; never mix actual expense with support contribution.

Who can do what: Finance enables policy; donors decide; model training excludes church-private profile and care data.

Validation and recovery: Fallback to reviewed deterministic rules when model unavailable; label estimates; no claim to reproduce Givecloud proprietary model or uplift.

Required acceptance tests: Offer/acceptance/rejection recorded once; no-cost path available; model rollback preserves historical offers; excluded private fields absent.

Actual implementation evidence: Unimplemented. Custom arithmetic estimator does not implement Smart DCC.

• The Power of Smart DCC

Matthew25 release requirement: Fee explanation and consent. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify fee explanation and consent through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented portions and remaining limits are recorded in the detailed specification. Full release acceptance is not met.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Processor expense reconciliation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify processor expense reconciliation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Fraud detection. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify fraud detection through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Configurable risk restrictions. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify configurable risk restrictions through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Refund allocation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify refund allocation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Payment disputes. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify payment disputes through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Settlement batches. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify settlement batches through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Signed payment callbacks. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify signed payment callbacks through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Idempotent payment handling. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify idempotent payment handling through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Personal campaign creation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: 0.12.0: 70 lifecycle, 162 rendering/filter, 90 HTTPS checks and 10 regression suites passed. Church-controlled personal fundraiser setup with immutable publication revisions. Effective closing date is the earlier of approved page deadline and church campaign deadline. Existing recurring authorizations remain controlled by the donor.

Dependency: Remaining source-specific creation options and overall feature parity remain unfinished.

Source behavior / boundary: Personal fundraising pages; Staff-assisted owner selection and remaining source options still require acceptance.

Matthew25 workflow: Church-controlled personal fundraiser setup with immutable publication revisions. Effective closing date is the earlier of approved page deadline and church campaign deadline. Existing recurring authorizations remain controlled by the donor.

Database contract: Cause mutations use explicit cause IDs and optimistic versions. Once pages exist, changing the designated campaign is refused. Public pages require an active church and current fundraiser verification policy.

Who can do what: Owners edit their own pages; church congregation staff review only their church.

Validation and recovery: Reject stale edits, foreign causes, denied fundraiser identities and closed-page checkout.

Required acceptance tests: Create, submit, approve, edit draft without changing live content, capture gift and close page.

Actual implementation evidence: 0.12.0 evidence in /srv/matthew25/work/verification-{fundraising,render,live,regressions}-0.12.0.json. Remaining source-specific creation options and overall feature parity remain unfinished.

• Guide to Peer-to-Peer Fundraising
• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Team fundraising. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify team fundraising through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Additional team-specific vendor articles and settings remain to be reconciled.

Source behavior / boundary: Team fundraising; Additional team-specific vendor articles and settings remain to be reconciled.

Matthew25 workflow: Personal fundraiser owners request membership in a same-cause team; leaders approve. Gifts preserve the team attribution at checkout even after a member leaves.

Database contract: fundraising_team_requests has requested/active/declined/left history and optimistic versions; order/plan/gift links snapshot team and page.

Who can do what: Only the personal owner requests; team owner or church staff approves.

Validation and recovery: Lock page IDs in consistent order, deny cross-church/cause requests and unauthorized approvals.

Required acceptance tests: Approve membership, capture personal and team progress, leave and retain historical attribution.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Additional team-specific vendor articles and settings remain to be reconciled.

• Guide to Peer-to-Peer Fundraising
• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Fundraiser goals and avatars. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify fundraiser goals and avatars through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Full product acceptance remains open.

Source behavior / boundary: Goals, dates and recognition; Full product acceptance remains open.

Matthew25 workflow: Public pages show net gifts, donor counts, approved images and closing dates; donor-entered optional fee coverage does not increase the goal.

Database contract: fundraising_gifts links actual donation allocations; refunds reduce net progress; fundraising_offsets explicitly represent outside progress separately.

Who can do what: Public aggregate only; donor recognition is anonymous by default and contact data stays private.

Validation and recovery: Exclude unpaid orders, reversed gifts and fees; stale drafts cannot change approved goal or date.

Required acceptance tests: Browser gift of $25.25 plus $1.07 fee increases goal by $25.25; refund and team totals tested.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Full product acceptance remains open.

• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Fundraiser lists and filters. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: 0.12.0: 70 lifecycle, 162 rendering/filter, 90 HTTPS checks and 10 regression suites passed. Staff and public fundraiser lists with cause, occasion, type, status, creation dates and title/goal/date sorting. Staff also filter saved draft titles, owner and review state. Public searches use only approved snapshots. Filtered CSV matches staff lists and preserves published versus saved details.

Dependency: More advanced analytics, additional vendor-specific filters, historical comparison and exports beyond the synchronous 5,000-page bound remain outside this increment.

Source behavior / boundary: Fundraiser discovery and exports; Expanded staff filters, sorting and exports matching every filter remain unfinished.

Matthew25 workflow: Staff and public fundraiser lists with cause, occasion, type, status, creation dates and title/goal/date sorting. Staff also filter saved draft titles, owner and review state. Public searches use only approved snapshots. Filtered CSV matches staff lists and preserves published versus saved details.

Database contract: Shared authorized query specification; rows, counts and pagination use identical scope. Stable sort tie-breakers. CSV reads one MySQL transaction snapshot, separates received gifts and external offsets, and escapes formula prefixes.

Who can do what: Public sees only approved accessible pages; church congregation staff exports.

Validation and recovery: Draft titles and denied owners cannot leak into search; foreign church requests fail.

Required acceptance tests: Six church search/list/export HTTPS checks; reject private and foreign pages.

Actual implementation evidence: 0.12.0 evidence in /srv/matthew25/work/verification-{fundraising,render,live,regressions}-0.12.0.json. More advanced analytics, additional vendor-specific filters, historical comparison and exports beyond the synchronous 5,000-page bound remain outside this increment.

• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Content moderation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify content moderation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Additional role granularity remains platform-wide scope.

Source behavior / boundary: Moderation and abuse reports; Additional role granularity remains platform-wide scope.

Matthew25 workflow: Church reviewers approve or decline saved revisions, suspend pages, review encouragement, publish updates and handle private reports.

Database contract: Immutable page versions, fundraising_reports with assigned state; fundraising_updates and donor messages have review status and audit trail.

Who can do what: Church reviewers moderate; owners cannot reveal another donor identity.

Validation and recovery: Stale moderation rejected; denied owners hidden; abuse details never public.

Required acceptance tests: Approve, suspend, deny, review message and submit private report with boundary checks.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Additional role granularity remains platform-wide scope.

• Creating Guidelines and Moderating Peer-to-Peer Fundraising Pages

Matthew25 release requirement: Fundraiser verification. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify fundraiser verification through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Full product acceptance remains open.

Source behavior / boundary: Fundraiser verification and guidelines; Full product acceptance remains open.

Matthew25 workflow: Settings require accepted guidelines and optionally verified donors; prior net donors can qualify automatically, with separate page review policy.

Database contract: fundraising_settings and fundraiser_verifications are church-bound; verification pending/verified/denied remains independent of page status.

Who can do what: Church reviewer verifies; donors accept the current church guidelines.

Validation and recovery: Denied identity blocks publication even when page was previously approved.

Required acceptance tests: Unverified draft remains private, verification releases review, denied owner removes public visibility.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Full product acceptance remains open.

• Creating Guidelines and Moderating Peer-to-Peer Fundraising Pages

Matthew25 release requirement: Milestone notices. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify milestone notices through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Actual SMTP delivery and independent concurrent milestone stress acceptance remain.

Source behavior / boundary: Milestones and fundraiser messages; Actual SMTP delivery and independent concurrent milestone stress acceptance remain.

Matthew25 workflow: Confirmed gifts and goal thresholds generate deduplicated owner notifications; staff receive submission and abuse notices.

Database contract: fundraising_milestones unique page/threshold/goal; outgoing_messages dedupe church/person/event and private preview boundary.

Who can do what: Only owner/staff recipients; donor contacts excluded from public messages.

Validation and recovery: Payment replay cannot duplicate progress or milestones; showroom records cannot send real mail.

Required acceptance tests: Replay capture and verify single milestone plus preview-only notifications.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Actual SMTP delivery and independent concurrent milestone stress acceptance remain.

• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Rich campaign media. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify rich campaign media through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Inline accessible video playback and complete vendor media behavior remain.

Source behavior / boundary: Fundraiser images and video; Inline accessible video playback and complete vendor media behavior remain.

Matthew25 workflow: Owners upload sanitized JPEG/PNG images or choose authorized media and provide a validated YouTube/Vimeo URL.

Database contract: Immutable media_assets bytes/hash, published snapshot media reference; video URL is validated and displayed as an external watch link.

Who can do what: Only owned or church-public media selectable; direct private media requires page access.

Validation and recovery: Reject foreign media, oversized/pixel-bomb files, executable URLs and archiving published images.

Required acceptance tests: Image authorization and publication regression checks passed.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Inline accessible video playback and complete vendor media behavior remain.

• How to Set Up Peer-to-Peer Fundraising - For Classic Items

Matthew25 release requirement: Social campaign sharing. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify social campaign sharing through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Future recurring recognition preference editing and every vendor sharing channel need reconciliation.

Source behavior / boundary: Sharing and donor management; Future recurring recognition preference editing and every vendor sharing channel need reconciliation.

Matthew25 workflow: Approved pages expose social/share links, public metadata and a personal management area. Donors control recognition for their own received gifts.

Database contract: Order and recurring plan recognition snapshots, fundraising_gifts display name/anonymous/message status/version.

Who can do what: Only donor or church finance staff changes received-gift recognition; owner cannot disclose donor details.

Validation and recovery: Reject foreign gift IDs and stale edits.

Required acceptance tests: Anonymous gift remains anonymous in live browser; unauthorized recognition edits rejected.

Actual implementation evidence: 0.7.0: 33 fundraising lifecycle, 67 live HTTPS, 26 site and 103 prior regression checks. Browser capture/order 603 at desktop and 390px. Future recurring recognition preference editing and every vendor sharing channel need reconciliation.

• How to Personalize Your Peer-to-Peer Fundraising Page

Matthew25 release requirement: Received offline gifts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify received offline gifts through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Manual giving entry. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify manual giving entry through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Individual acknowledgments. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify individual acknowledgments through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Annual donor statements. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify annual donor statements through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Organization issuer details. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify organization issuer details through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Historic donor address snapshots. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify historic donor address snapshots through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Goods/services value disclosures. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify goods/services value disclosures through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Intangible religious benefit handling. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify intangible religious benefit handling through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Noncash acknowledgment handling. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify noncash acknowledgment handling through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Jurisdiction-specific receipt rules. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify jurisdiction-specific receipt rules through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Receipt correction and replacement. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify receipt correction and replacement through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Individual and annual printable letters implemented. Broader replacement/delivery workflows remain.

Source behavior / boundary: Givecloud supports receipt revision, voiding, reissue, and prior-version history. Earlier versions are marked void.

Matthew25 workflow: Authorized finance staff preview corrected issuer/donor snapshot, give reason, void prior document and issue linked replacement. Amount correction must originate in gift accounting, not freeform receipt edits.

Database contract: EXISTING receipt_documents and receipt_gift_links. REQUIRED replacement_of_id, revision_reason, rendered_document_hash, document_versions and delivery records; remove one-document-per-donation assumption with safe migration.

Who can do what: Issuer finance and donor read own; only issuer finance revises; replacement inherits same donor and church.

Validation and recovery: Lock source gifts and prior receipt; atomic void/reissue; preserve originals and download VOID status; invalid refund state blocks issue.

Required acceptance tests: Address correction does not change gift total; old version remains downloadable as void; double submission does not create duplicate current receipt.

Actual implementation evidence: Existing gift void and annual invalidation only. Full replacement workflow unimplemented.

• How to Revise, Void or Reissue a Tax Receipt

Matthew25 release requirement: Private receipt downloads. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify private receipt downloads through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Mail-ready donor letters. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify mail-ready donor letters through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Email receipt delivery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify email receipt delivery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Print and postal dispatch tracking. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify print and postal dispatch tracking through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Accounting codes. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify accounting codes through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Separate fee contribution coding. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify separate fee contribution coding through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Contribution reports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Payment reports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Line-item reports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Failed-payment reports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Refund reports. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Current reporting/export implementation passed 30 lifecycle, 3 concurrency, 102 screen/filter/reconciliation and 91 live HTTPS checks. See 0.11.0 release evidence.

Dependency: Full vendor filter parity, additional payment method/risk metadata, per-attempt history, settlement reconciliation and remaining advanced reporting require further implementation and provider certification.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Balanced financial journal. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify balanced financial journal through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Settlement reconciliation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify settlement reconciliation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Recurring gift enrollment. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify recurring gift enrollment through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Weekly and alternate-week schedules. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify weekly and alternate-week schedules through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Monthly and annual schedules. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify monthly and annual schedules through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Quarterly and semiannual schedules. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify quarterly and semiannual schedules through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Fixed installment limits. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify fixed installment limits through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Recurring gift editing. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify recurring gift editing through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Pause and resume. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify pause and resume through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Cancellation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify cancellation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Payment expiry notifications. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify payment expiry notifications through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Failed-payment retries. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify failed-payment retries through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Payment account updater. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify payment account updater through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Recurring authorization history. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify recurring authorization history through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Post-gift recurring invitation. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify post-gift recurring invitation through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Source behavior / boundary: Givecloud offers a monthly invitation after a one-time gift; administrators can customize text and suppress above a threshold, while suggested upsell amounts are not manually editable.

Matthew25 workflow: After confirmed original gift, show eligible recurring offer. Acceptance creates a separate explicit authorization with first collection date and receiving merchant; declining leaves original gift untouched.

Database contract: REQUIRED upsell_rules(organization_id,form_id,message,threshold_minor), upsell_offers(original_gift_id,rule_version,shown_amounts,status), recurring_authorizations(person_id,merchant_account_id,terms_snapshot,consented_at).

Who can do what: Church finance sets rule; donor accepts only for their own payment method; callbacks authorize only original receiving merchant.

Validation and recovery: No second charge from page refresh; suppress for excluded methods such as DAF; original gift remains intact if recurring authorization fails.

Required acceptance tests: Double submit makes one authorization; decline creates none; threshold suppresses; original receipt unchanged.

Actual implementation evidence: Unimplemented; dependencies include selected processor, tokenization and recurring scheduler.

• GE: Customize Experience

Matthew25 release requirement: Large-gift upsell suppression. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify large-gift upsell suppression through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Church-controlled upsell amounts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify church-controlled upsell amounts through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Employer match discovery. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify employer match discovery through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Employer match tracking. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify employer match tracking through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Email opt-in after giving. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify email opt-in after giving through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Beneficiary profiles. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify beneficiary profiles through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Bulk image matching, richer formatted biographies and remaining extended profile options still require complete source reconciliation.

Source behavior / boundary: Rich beneficiary profiles; Bulk image matching, richer formatted biographies and remaining extended profile options still require complete source reconciliation.

Matthew25 workflow: Church staff create or revise reference, full name and public alias, birth/enrollment dates, optional gender, biography, private notes, image, program, payment bundle, capacity and publication state.

Database contract: sponsorship_beneficiaries has church/reference uniqueness, program and bundle ownership, image reference, optimistic version and active/graduated/archived history. Public names and birth-date-derived age are separate from staff data.

Who can do what: Church congregation staff edit; public or active-sponsor access is computed per profile and field.

Validation and recovery: Reject foreign bundles/images, stale versions, invalid dates and reducing capacity below occupied places. Archiving preserves relationships and payments.

Required acceptance tests: Create and revise a profile, reject stale/cross-program changes, preserve partial import fields, inspect signed-out and sponsor views.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Bulk image matching, richer formatted biographies and remaining extended profile options still require complete source reconciliation.

• Getting Started with Child Sponsorship
• Sponsorships: Managing a Child's Profile and Timeline History

Matthew25 release requirement: Beneficiary discovery filters. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify beneficiary discovery filters through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Interactive geographic map/pin discovery and the full vendor sort/filter vocabulary remain.

Source behavior / boundary: Shareable beneficiary discovery; Interactive geographic map/pin discovery and the full vendor sort/filter vocabulary remain.

Matthew25 workflow: Visitors search public names and biographies, choose a program and use shareable public custom-choice filters. Staff also filter status, capacity availability and maturity; CSV exports use the same selected filters.

Database contract: sponsorship_fields and normalized value_choices link public filter definitions to beneficiaries; scoped parameterized predicates drive listing and exports.

Who can do what: Private field definitions cannot be queried through public filters. Church staff alone exports full sponsor contact details.

Validation and recovery: Hide offline, graduated, mature and fully occupied profiles according to settings. Search never includes private surnames or care notes.

Required acceptance tests: Public choice filtering, private-filter rejection, all six churches and filtered profile/sponsor CSVs verified.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Interactive geographic map/pin discovery and the full vendor sort/filter vocabulary remain.

• How to Display a Filtered Sponsorship List
• Sponsorships: Custom Fields

Matthew25 release requirement: Beneficiary field privacy. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify beneficiary field privacy through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Full role granularity is still platform-wide acceptance scope.

Source behavior / boundary: Beneficiary field privacy; Full role granularity is still platform-wide acceptance scope.

Matthew25 workflow: Church staff define text/date/single-choice/multiple-choice fields with public, active-sponsor or staff visibility, optional public filtering, rich choice descriptions/links and geographic coordinates.

Database contract: sponsorship_fields, choices, values and normalized choice links retain archived definitions and values; changing a populated field type is rejected.

Who can do what: Public reads public only; active sponsors gain their beneficiary sponsor fields; staff role controls private care fields.

Validation and recovery: Ending sponsorship immediately revokes private field and attachment access. Notifications contain a portal link without copying private timeline data.

Required acceptance tests: Anonymous, unrelated donor, active donor, ended donor and staff access checks passed, including direct PDF URLs.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Full role granularity is still platform-wide acceptance scope.

• Sponsorships: Custom Fields

Matthew25 release requirement: Sponsorship commitments. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify sponsorship commitments through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Staff-assisted cash/check enrollment, deferred initial collection, every billing-day option and production-provider acceptance remain.

Source behavior / boundary: Sponsorship commitments and payment choices; Staff-assisted cash/check enrollment, deferred initial collection, every billing-day option and production-provider acceptance remain.

Matthew25 workflow: Programs provide beneficiary-specific bundles with priced one-time or recurring options, optional fixed monthly day and finite terms. Donors review exact amount, optional processing contribution and receipt policy before authorizing their church merchant.

Database contract: Bundles/options plus immutable relationship option_snapshot and receipt_eligible; relationship links its merchant-bound recurring plan; order/gift links preserve attribution and tax-letter treatment on subsequent captures.

Who can do what: Donor authorizes their own collection; finance staff manages payment options; showroom driver cannot reach a real processor.

Validation and recovery: Capture and retries are idempotent; refund adjusts net support without silently ending the relationship. Ended plans cannot bypass capacity by resuming.

Required acceptance tests: Browser $50 monthly plus $0.91 costs activates relationship; recurrence, refunds, fixed billing, receipt eligibility and nonreceipt rejection verified.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Staff-assisted cash/check enrollment, deferred initial collection, every billing-day option and production-provider acceptance remain.

• Sponsorships: Setting Up Payment Options
• How to Start a Sponsorship on Behalf of a Supporter

Matthew25 release requirement: Sponsorship capacity. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify sponsorship capacity through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: High-volume provider fault and throughput certification remain operational acceptance.

Source behavior / boundary: Concurrent sponsorship capacity; High-volume provider fault and throughput certification remain operational acceptance.

Matthew25 workflow: Checkout reserves a profile place until payment resolves; successful capture activates it. Expired unattempted or definitively cancelled checkout releases capacity, while an ambiguous processor request retains the place.

Database contract: Beneficiary parent lock plus current locking reads of active/reserved relationships serialize capacity. Order request keys and donation links prevent duplicate reservations and credit.

Who can do what: All checks apply server-side under church ownership and donor identity.

Validation and recovery: Do not oversell the last place or release an uncertain payment. Late payment on an ended relationship is recorded and flagged without reopening it.

Required acceptance tests: Two separate simultaneous PHP processes produced one reservation and one rejection; expiry and replay passed. All committed fixtures removed.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. High-volume provider fault and throughput certification remain operational acceptance.

• Getting Started with Child Sponsorship

Matthew25 release requirement: Beneficiary updates. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify beneficiary updates through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Extended attachment types, fine-grained update permissions and richer publishing tools remain.

Source behavior / boundary: Beneficiary timeline and attachments; Extended attachment types, fine-grained update permissions and richer publishing tools remain.

Matthew25 workflow: Staff post dated, tagged public/sponsor/staff updates; edits append immutable revisions, and archive hides content while preserving history. PDF/image attachments inherit current update visibility.

Database contract: sponsorship_updates, update_versions and BLOB attachments store exact bytes and SHA-256; sanitized images remove metadata; files remain server-side.

Who can do what: Active sponsor or church staff required for private PDF; staff-only content never copied into notices.

Validation and recovery: Reject foreign uploads, unsupported/oversized files and byte-integrity mismatch. Archived updates or ended relationships revoke download access.

Required acceptance tests: Twelve seeded private PDFs hash-match actual HTTPS downloads; signed-out and wrong-sponsor requests denied.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Extended attachment types, fine-grained update permissions and richer publishing tools remain.

• Sponsorships: Managing a Child's Profile and Timeline History

Matthew25 release requirement: Sponsor activity timeline. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify sponsor activity timeline through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Saved reports, sponsor-specific status/date filters, larger asynchronous exports and complete activity-event display remain.

Source behavior / boundary: Sponsor activity and reports; Saved reports, sponsor-specific status/date filters, larger asynchronous exports and complete activity-event display remain.

Matthew25 workflow: Church staff see current and ended sponsors, sources, start/end reasons, recurring status, net support and dated updates; filtered exports include addresses/contact data, next dates and custom profile fields.

Database contract: Relationships preserve end reason/date/notes; sponsorship_gifts links actual donations for refund-aware totals; recurring plans retain authorizations and audit history.

Who can do what: Church-scoped staff reports; donor sees only their own relationships and authorized updates.

Validation and recovery: Exports honor the same profile filters and escape spreadsheet formulas; refunds never double-count support.

Required acceptance tests: Six churches exported filtered profiles and filtered sponsors with addresses and next-payment dates; donor/foreign access rejected.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Saved reports, sponsor-specific status/date filters, larger asynchronous exports and complete activity-event display remain.

• Sponsorships: Managing a Child's Profile and Timeline History
• Sponsorship Reporting

Matthew25 release requirement: Sponsor self-management. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify sponsor self-management through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Sponsor transfer, reinstatement, supported source-specific controls and payment-method recovery remain.

Source behavior / boundary: Sponsor self-management; Sponsor transfer, reinstatement, supported source-specific controls and payment-method recovery remain.

Matthew25 workflow: Sponsors view relationships, updates and payment history, follow recurring controls and end their sponsorship when enabled. Ending suspends future collection while retaining past gifts and letters.

Database contract: Relationship state remains separate from recurring plan state; end transition is audited and optionally notified. Program defines behavior for paused/past-due/cancelled commitments.

Who can do what: Donor may end their own relationship under program policy; church finance staff can end with reason, date, notes and notice.

Validation and recovery: Unauthorized or stale changes fail. Old ended plans cannot be resumed to evade capacity. Pending processor captures remain accountable.

Required acceptance tests: End releases capacity, pauses plan, revokes private access and retains gift/letter history. Cancellation policy also closes the relationship.

Actual implementation evidence: 0.8.0: 38 lifecycle, 13 import, 4 concurrency, 4 actual worker and 77 live HTTPS checks; 162 prior regression checks. Browser monthly enrollment, donor phone/PIN and 390/1440 layouts verified. Sponsor transfer, reinstatement, supported source-specific controls and payment-method recovery remain.

• How to End a Sponsorship

Matthew25 release requirement: Physical merchandise. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify physical merchandise through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Physical items have price variants and tracked quantities.

Matthew25 workflow: Staff publish a product, define priced options, receive inventory, and record pickup or shipping after confirmed payment. Returns explicitly restore previously refunded units.

Database contract: commerce_products, commerce_variants, commerce_stock_movements, commerce_order_lines, commerce_fulfillments retain product versions, financial snapshots, stock deltas and actor references.

Who can do what: Finance manages products, stock and fulfillment; purchaser sees only own orders within the selected church.

Validation and recovery: Insufficient stock, stale versions, repeated fulfillment and unconfirmed money cannot silently produce inventory changes.

Required acceptance tests: Purchase one item, submit two simultaneous last-item checkouts, capture twice, fulfill partially, refund and restock once.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Track Stock and Inventory for Your Products

Matthew25 release requirement: Digital merchandise. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify digital merchandise through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor supports downloadable or streamable products.

Matthew25 workflow: Staff upload versioned PDF, text, image or ZIP resources. A paid purchase links to its immutable file version; authenticated downloads check purchase ownership, refund state and SHA-256.

Database contract: commerce_downloads stores server-side binary, MIME type, filename, digest and version; commerce_order_lines snapshot fixes the granted version.

Who can do what: Finance uploads; donor or authorized church finance retrieves purchases.

Validation and recovery: Unsupported uploads, cross-church IDs, unpaid and fully refunded purchases are denied. Streaming-specific controls remain separate scope.

Required acceptance tests: Read a purchased file through authenticated HTTPS; deny foreign purchasers and verify revoked access after refund.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• Automating Membership Through Product Purchase

Matthew25 release requirement: Product variants. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify product variants through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Inventory is tracked separately for product variants.

Matthew25 workflow: Staff maintain variant title, SKU, price, weight and state; order review snapshots the selected option and current amount.

Database contract: commerce_variants has a church-unique SKU, product ownership FK, price, tracked/unlimited quantity, weight and version.

Who can do what: Church finance edits; public sees only active options under published products.

Validation and recovery: Cross-church products, stale edits, invalid decimal money and quantity limits are rejected.

Required acceptance tests: Seed and render multiple tote colors; purchased option survives later product edits.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Track Stock and Inventory for Your Products

Matthew25 release requirement: Product categories. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify product categories through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Stock movements. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify stock movements through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Stock levels and updates are part of inventory administration.

Matthew25 workflow: Opening inventory, adjustments, captured sales and accepted returns append movements and reselect the resulting balance.

Database contract: commerce_stock_movements uses unique event keys, signed deltas, result quantity, actor, variant and church; balances live on locked commerce_variants.

Who can do what: Finance writes inventory; shoppers see available stock only.

Validation and recovery: Reserved inventory cannot be removed; duplicate capture or return cannot move stock twice.

Required acceptance tests: Verify opening, capture, refund without automatic restock, explicit return, duplicate return refusal and canonical remaining quantity.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Track Stock and Inventory for Your Products

Matthew25 release requirement: Checkout stock reservations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify checkout stock reservations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Finite inventory and combined event limits prevent additional sales after capacity.

Matthew25 workflow: Each prepared checkout holds item quantities and event seats until capture or definitive cancellation. Unsubmitted checkouts expire; unresolved processor attempts retain their holds.

Database contract: commerce_reservations links church, order, variant, optional event, quantity, expiry and held/consumed/released state.

Who can do what: Only donor-owned carts can prepare reservations; staff reconcile unresolved payments.

Validation and recovery: Lock current rows before counts; a second contender must see the first reservation even under repeatable-read isolation.

Required acceptance tests: Two independent PHP processes compete for the last physical item and separately the last event seat; exactly one succeeds.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Track Stock and Inventory for Your Products

Matthew25 release requirement: Inventory replenishment. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify inventory replenishment through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Discount rules. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify discount rules through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Shipping calculations. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify shipping calculations through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor offers flat rates, order-value thresholds, address-specific services and live carrier quotes.

Matthew25 workflow: Church rates support destination country/region, base charge, started-kilogram charge, free threshold and pickup. Each accepted rate/address is snapshotted. Live carrier quotes remain an unimplemented dependency-backed adapter.

Database contract: commerce_shipping_rates and commerce_orders.shipping_snapshot retain service, country, region, weight policy and immutable delivery destination.

Who can do what: Finance maintains rates; purchaser selects applicable delivery method and supplies address.

Validation and recovery: Missing address and unsupported destinations fail before authorization. Shipping-tax configuration remains open.

Required acceptance tests: Verify item weights, threshold behavior, destination matching, pickup and immutable charged shipping line.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• How to Set Up Shipping Costs

Matthew25 release requirement: Carrier fulfillment integration. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify carrier fulfillment integration through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Unified donation and purchase cart. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify unified donation and purchase cart through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Memberships, tickets, donations and merchandise can be purchased together.

Matthew25 workflow: One church cart accepts several products and an optional fund-designated gift, computes a review, and collects one total into that church merchant account.

Database contract: commerce_carts/items, commerce_orders/lines, payment_orders.purpose, donation rows only for charitable lines, and balanced multi-account ledger journals.

Who can do what: Purchaser authorizes own checkout; finance reconciles receiving church.

Validation and recovery: Cross-merchant mixing, foreign variants/funds, total mismatch, duplicate capture and excess refund are rejected.

Required acceptance tests: Verify $40 items less $4 discount plus $2.16 tax, $6 shipping and $10 donation equals $54.16, with only $10 recorded as charitable giving.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• Membership Renewals with Givecloud
• How to Create a Page to Sell Multiple Event Tickets

Matthew25 release requirement: Donation add-on at checkout. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify donation add-on at checkout through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Membership levels and codes. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify membership levels and codes through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Paid membership renewal. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify paid membership renewal through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Dependency: Implemented behavior and remaining acceptance details are recorded in the individual specification; full product parity is not complete.

Source behavior / boundary: Vendor supports manual membership renewal, fixed/rolling terms and workaround recurring products; recurring charges do not automatically extend expiry.

Matthew25 workflow: Native paid renewals extend a rolling term from its current end; refunding the renewal removes that term. Fixed dates, lifetime terms, early access and reminder options remain to implement.

Database contract: benefit_levels, benefit_memberships and benefit_terms separate financial purchase history, active entitlement windows and revoked terms.

Who can do what: Donor purchases or ends own benefits; finance manages levels and refunds.

Validation and recovery: No double extension on callback replay; expired/refunded terms cannot grant benefits.

Required acceptance tests: Buy twice, confirm 24-month coverage, refund renewal and retain first 12 months, then refund initial purchase and remove privileges.

Actual implementation evidence: 0.5.0: verification-commerce-0.5.0.json; verification-commerce-race-0.5.0.json; verification-live-0.5.0.json; live browser purchase/refund/restock confirmed for showroom order 515. Individual limits and untested integrations remain stated in this specification.

• Membership Renewals with Givecloud

Matthew25 release requirement: Member benefit discounts. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify member benefit discounts through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.

Matthew25 release requirement: Protected member content. Implement a complete authorized workflow with persistent relational records, scoped visibility, validation and recoverable changes; this entry is not a completion claim.

Acceptance: Verify protected member content through the real user workflow, canonical database re-read, access-control checks and failure/retry behavior.

Specification gap: Individual data, workflow, permission and recovery contracts are not yet complete for this requirement.