Skip to content

AL-2149 — [P28-C20] Enable and browse approved regional ministry listings #2149

Open

Description

@cobmojo

AL-2149 — [P28-C20] Enable and browse approved regional ministry listings

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

Parent

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

What to build

Staff enable one initially-Off discovery control; Maya browses a complete authorized list of current public ministries by broad region with truthful empty, unavailable and Off states.

Source of truth and acceptance ownership

Primary requirement references: REQ28-C46, REQ28-C47, REQ28-C48. Stories: US28-C46, US28-C47, US28-C48.

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

Acceptance criteria

  • AC28-C46-02 — On consumes only the current qualified source corpus and grants no new publication, location or access right. Saved On with unavailable source qualification still denies unsafe release and explains the actual safe setup state.
  • AC28-C46-03 — Off removes discovery entry points and blocks server release for this consumer, including stale caches and delayed responses. Re-enable recomputes current eligibility rather than reviving an old corpus.
  • AC28-C46-04 — Save derives organization/actor from trusted context, checks the expected revision, retains required evidence and offers authoritative readback. A stale On request cannot undo a newer Off.
  • AC28-C46-05 — The interface distinguishes Off, missing setup, denied management permission and source/renderer failure. It adds no per-region switch, personal exception, device-location request or policy matrix.
  • AC28-C47-01 — No arbitrary default Site, cross-organization join or cross-locale fallback widens the corpus. Hidden and Shared-by-link entries contribute no regional totals, ordering or visible regions.
  • AC28-C47-03 — The browser receives no raw private coordinates for rounding; internal addresses are not geocoded, device location is not requested, and invented centroid pins do not imply a person's actual location.
  • AC28-C47-04 — An unknown region has no sensitive-location fallback. Otherwise admitted unmappable entries remain useful in the applicable list-only presentation without a fabricated map position.
  • AC28-C48-03 — The list is a complete usable alternative with keyboard and screen-reader support. Opening an admitted public page and returning preserves current selection/position subject to refreshed authority.

Implementation decisions and slice boundaries

  • P28 consumer explicitly qualifies Tenant/LegalEntity/environment/Site/locale broad-region purpose; do not remove P22 directory map exclusion or fork a second publication authority.
  • Only Listed source rows; no Hidden/link-only existence, raw coordinates, operational geocoding, device location, arbitrary default Site/locale or location inference. Unknown unmappable region stays list-only if otherwise admitted.
  • One setting controls list+map, preserve explicitexistingconfig and stale-On-after-Off fencing; toggles never alter public Page reach. Parent phase remains incomplete until C21 map exists.

Binding normative decisions

REQ28-C46 — Enable regional discovery deliberately with one control

Story US28-C46: As authorized organization staff, I want one clear regional-discovery control, so that we can offer the list and map deliberately without changing public publication.

Decision basis: Selected D13 list/map/control; D46 explicitly selected initial new-organization default; completeness configuration safeguards.

New organizations shall start with Phase 28 regional discovery Off until authorized staff enable the qualified capability. Existing legitimate choices shall be preserved. Missing or unknown legacy configuration shall not imply On.

REQ28-C47 — Use one safe published corpus for regional browsing

Story US28-C47: As a missionary, I want regional browsing to contain only approved public ministry information, so that exploration cannot reveal private people or locations.

Decision basis: D13 selected geography journey and reviewed source boundary; D46; current public-publication and privacy owners.

Both views shall use one currently Listed, disclosure-safe public-ministry corpus bound to the exact organization, legal entity, environment, Site and locale. The bounded Phase 28 broad-region consumer must be independently qualified; another phase's map exclusion is not silently removed.

REQ28-C48 — Explore regions with a complete list and usable map

Story US28-C48: As a missionary, I want to explore approved ministries using a list or a world map, so that I can use the view that works for my device and accessibility needs.

Decision basis: D13 selected list plus world map; reviewed low-bandwidth and accessibility design; D46 availability scope.

List and Map shall share one explicit regional selection and the same admitted corpus. The initial presentation may favor the lightweight list as a reversible design choice; the selected release scope includes a functioning map.

Testing, migration and operating obligations

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

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

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

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

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

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

Related source owners (references are not automatically blockers): #1308. Current source contract takes precedence over superseded issue wording.

Blocked by

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

Related approved slices

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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    ReadyBlake-approved for the agent factory to pick up (oldest first)complexity:mediumModerate complexitytype:featureNew functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions