Bottelary Trail Network — Implementation TODO

Derived from the functional specification and its review. This is a greenfield backlog: no technology stack or application has been selected or implemented.

How to use this backlog

• P0 blocks a safe or correctly scoped implementation.
• P1 is part of the proposed first release.
• P2 is valuable hardening or an approved conditional feature.
• Tasks marked Blocked must not be estimated as settled scope until the referenced decision is recorded.
• All implementation tasks are implicitly blocked by DEC-015 until the corrected MVP baseline is approved; repeated Blocked labels call out additional task-specific dependencies.
• Keep pass purchasing, proactive trail alerts, and user-submitted notices out of the first release unless scope is formally changed.

0. Scope gates and client decisions

Resolve the P0 items before committing to a build estimate. Launch-content collection can continue during the build but must finish before UAT.

• DEC-001 · P0 Choose the WhatsApp integration (Meta Cloud API or provider/BSP) and confirm Business Account, phone-number, billing, sandbox, and production ownership.
• DEC-002 · P0 Document the current WhatsApp opt-in, approved-template, customer-service conversation-window, outbound-notification, delivery-failure, and support-escalation rules.
• DEC-003 · P0 Identify the membership system, technical owner, API availability, authentication, environments, rate limits, fields, and sample/test records.
• DEC-004 · P0 Approve member matching and linking rules: identifiers, expired memberships, validation lifetime, revalidation, one member to multiple WhatsApp numbers, and one number changing owners.
• DEC-005 · P0 Approve one access matrix for trail updates, passes, maintenance, event visibility, event joining, notices, and help; distinguish global from per-item rules.
• DEC-006 · P0 Resolve the 0 command conflict: always return to the main menu, or define a separate Back command. Update every flow consistently.
• DEC-007 · P0 Decide whether maintenance is public or member-only; whether photo/location are required; whether users receive status changes; and who triages, assigns, and closes requests.
• DEC-008 · P0 Separate event visibility, joining eligibility, and pass requirements; define valid combinations and how annual passes, day passes, and invitations are verified.
• DEC-009 · P0 Decide event capacity, waiting list, self-cancellation, registration cut-off, attendance marking, export, additional registration questions, and registration-before-pass-purchase behavior.
• DEC-010 · P0 Confirm first-release administrator roles and permissions, administrator count, audit-history requirements, and reporting requirements.
• DEC-011 · P0 Approve the security and POPIA/privacy baseline: administrator MFA/password/session rules, encryption, upload controls, security logging, lawful basis and notices, consent, data residency, retention, correction, export, deletion, and incident process.
• DEC-012 · P0 Set measurable non-functional targets for availability, normal/peak load, response time, restore time, data-loss tolerance, monitoring, and support hours.
• DEC-013 · P0 Confirm timezone, language, supported admin browsers/devices, accessibility target, export format, media types/limits, and location precision.
• DEC-014 · P1 Supply launch content and owners before UAT: trail list, statuses, pass URL/details, purchase locations, issue types, notices/categories, contacts, event defaults, support number, and emergency disclaimer.
• DEC-015 · P0 Classify every “may,” “optional,” and “suggested” item as MVP, later, or excluded; correct the specification conflicts; obtain client approval.
• DEC-016 · P0 Decide whether users can view current annual-membership status/expiry in the bot, which fields are shown, whether the lookup is live, and how unavailable or stale results behave.

1. Product and technical design

• DES-001 · P0 Draw the complete conversation state machine, including invalid input, Back/Cancel, global commands, timeouts, abandoned flows, retries, and restart/resume behavior.
• DES-002 · P0 Produce portal wireframes for login, dashboard, trails, passes, maintenance, events, notices, contacts, validation, and user administration.
• DES-003 · P0 Define the domain model and lifecycle states for users/members, validations, trails, requests, events, registrations/attendance, notices, contacts, and administrators.
• DES-004 · P0 Define database constraints for unique request references, duplicate registrations, ordering, scheduling, status history, and—if approved—atomic event capacity.
• DES-005 · P0 Specify WhatsApp, membership, media-storage, map-link, and export integration contracts, including outage and retry behavior.
• DES-006 · P0 Select the application stack, database, hosting region, object storage, job/queue mechanism, email/admin recovery mechanism, and deployment approach.
• DES-007 · P0 Threat-model the bot, portal, webhooks, membership lookup, uploads, exports, and administrator actions.
• DES-008 · P0 Write testable acceptance criteria for every bot and portal journey before implementation begins.
• DES-009 · P1 Create a traceability matrix from approved requirements to backlog tasks and automated/UAT tests.

2. Engineering foundation

• FND-001 · P1 Initialise the repository with an agreed directory structure, dependency locking, formatting, linting, type checks, and contribution guidance.
• FND-002 · P1 Create local, test, staging, and production configuration with validated environment variables and no secrets in source control.
• FND-003 · P1 Add database migrations, repeatable seed data, and rollback guidance.
• FND-004 · P1 Add continuous integration for linting, unit tests, integration tests, security/dependency checks, and production builds.
• FND-005 · P1 Implement structured logs, correlation IDs, metrics, traces where useful, health/readiness endpoints, and alerting hooks.
• FND-006 · P1 Implement centralized error handling with safe user messages and actionable operator detail that excludes sensitive data.
• FND-007 · P1 Implement secrets management, TLS, encryption at rest where required, secure headers, dependency updates, and least-privilege service access.
• FND-008 · P1 Implement backup, restore, retention, and deletion jobs; prove restoration in a non-production environment.
• FND-009 · P1 Document architecture decisions, data flows, environment setup, deployment, rollback, and operational ownership.

3. WhatsApp bot shell

• BOT-001 · P1 · Blocked by DEC-001 Provision test integration and implement verified inbound webhooks plus outbound messages and delivery-status callbacks.
• BOT-002 · P1 Normalize WhatsApp phone identifiers and persist a user/conversation record without logging raw sensitive values unnecessarily.
• BOT-003 · P1 Deduplicate and safely replay inbound webhooks so one user action produces at most one transaction.
• BOT-004 · P1 Implement the persistent conversation-state engine with transaction boundaries and timeout/reset behavior.
• BOT-005 · P1 Build the numbered 1–6 main menu, route valid numeric selections to the six specified journeys, and make case-insensitive, whitespace-tolerant Hi, Hello, and Menu messages open it.
• BOT-006 · P1 · Blocked by DEC-006 Implement the approved global Main menu/Back behavior from every state.
• BOT-007 · P1 Make HELP and EMERGENCY open emergency information from every state.
• BOT-008 · P1 Implement invalid, unavailable, expired-selection, unsupported-media, integration-outage, and retry responses.
• BOT-009 · P1 Implement configurable message content/templates and protect against text or links breaking menu rendering.
• BOT-010 · P1 · Blocked by DEC-002 Handle the WhatsApp customer-service window and approved outbound templates correctly.
• BOT-011 · P1 Add automated state-machine coverage proving every state supports the approved global commands and failure paths.

4. Administration portal foundation

• ADM-001 · P1 Implement secure login, logout, session expiry, password storage, throttling/lockout, and password recovery.
• ADM-002 · P1 · Blocked by DEC-010 Implement administrator invitations/management and the approved role-permission matrix, enforced on the server.
• ADM-003 · P1 Build the responsive portal shell, navigation, accessible forms/tables, validation, empty states, pagination, and error handling.
• ADM-004 · P1 Add consistent created/updated timestamps, publish/archive semantics, and optimistic-conflict handling.
• ADM-005 · P1 · Blocked by DEC-010 If approved, record actor attribution and search the required audit events, including access-rule and safety-content changes.
• ADM-006 · P1 Prevent destructive actions that would break historical requests or registrations; archive records where history must remain intact.

5. Trail updates

• TRL-001 · P1 Create trail records with name, display order, active/archive state, current status, short message, maintenance information, closure reason, reopening date, and last-updated time.
• TRL-002 · P1 Seed and validate the approved status set: Open, Open with caution, Closed, Under maintenance, and Temporarily unavailable.
• TRL-003 · P1 Build authorized trail add/edit/archive/reorder and status-publishing screens.
• TRL-004 · P1 Clarify and implement whether “last updated” is system-generated or administrator-overridable.
• TRL-005 · P1 Build the bot trail list and detail views with clear empty/stale-data behavior.
• TRL-006 · P1 · Blocked by DEC-005 Apply the approved trail visibility rule consistently in the bot and portal.
• TRL-007 · P1 Add portal, bot, access-control, ordering, and date tests plus status-history tests if that feature is approved.
• TRL-008 · P1 · Blocked by DEC-010 If approved, preserve and expose the required trail-status change history and actor attribution.

6. Pass information

• PAS-001 · P1 Model editable annual-pass URL, price, validity, benefits, renewal information, and support details.
• PAS-002 · P1 Build the annual-pass administration form and bot view; validate and safely render the external URL.
• PAS-003 · P1 Model day-pass locations with name, address, hours, contacts, Maps link, price, payment methods, instructions, active state, and display order.
• PAS-004 · P1 Build day-pass location add/edit/archive/reorder administration.
• PAS-005 · P1 Build the bot day-pass list/detail journey with usable phone and Maps links plus empty-state handling.
• PAS-006 · P1 · Blocked by DEC-005 Apply the approved annual/day-pass information visibility rules.
• PAS-007 · P1 Add portal, bot, ordering, URL, access-control, and empty-state tests.
• PAS-008 · P1 · Blocked by DEC-016 If approved, build the bot's current annual-membership status/expiry view with safe stale/unavailable behavior.

7. Member validation and access rules

• VAL-001 · P1 · Blocked by DEC-003 Implement a replaceable adapter for the approved membership source (API or controlled sync/import), including authentication, timeouts, retries, freshness, and availability monitoring as applicable.
• VAL-002 · P1 · Blocked by DEC-004 Implement the approved identifier-entry and matching workflow; avoid collecting identity numbers unless explicitly approved and necessary.
• VAL-003 · P1 Link successful validation to the normalized WhatsApp number and store source, timestamp, expiry, and minimum necessary member details.
• VAL-004 · P1 Implement permanent, time-limited, or per-transaction validation according to the approved policy.
• VAL-005 · P1 Block restricted workflows on failed/expired validation and provide retry plus the approved support route.
• VAL-006 · P1 Rate-limit validation attempts and handle membership-service outages without granting access.
• VAL-007 · P1 · Blocked by DEC-005 Implement one policy engine for public, members-only, and supported per-item access rules.
• VAL-008 · P1 Build portal controls for approved validation settings and prevent invalid rule combinations.
• VAL-009 · P1 Build authorized validated-user search, detail, unlink/reset, and expiry views; emit audit events if required by DEC-010.
• VAL-010 · P1 Test the complete access matrix, expired membership, link expiry, relinking, multiple-number rules, lockout, outage, and authorization cases.

8. Maintenance requests

• MNT-001 · P1 Model requests, unique MR-xxxxx references, user/member snapshot, trail, issue type, description, media, location, status, assignee, internal notes, timestamps, and status history.
• MNT-002 · P1 Seed the approved issue types and define how “Other” captures additional detail.
• MNT-003 · P1 · Blocked by DEC-007 Apply public/member access and required/optional photo and location rules.
• MNT-004 · P1 Build the guided trail → issue type → description → photo → location → review flow with edit, cancel, and submit behavior.
• MNT-005 · P1 Validate/download allowed WhatsApp media and location payloads into private storage with size/type/lifecycle controls.
• MNT-006 · P1 Make final submission transactional and idempotent; return one reference and confirmation per request.
• MNT-007 · P1 Build the portal request queue with search, filters, pagination, request detail, secure media access, and map/location display.
• MNT-008 · P1 Implement approved status transitions: New, Under review, Assigned, In progress, Resolved, Closed, and Rejected.
• MNT-009 · P1 Implement assignment and private internal notes with permissions and history.
• MNT-010 · P2 · Blocked by DEC-002/DEC-007 If approved, send idempotent template-based status updates and record delivery outcome.
• MNT-011 · P1 Test validation, required fields, upload/location failure, duplicate delivery, reference uniqueness, status transitions, permissions, and data retention.

9. Social events

• EVT-001 · P1 · Blocked by DEC-008/DEC-009 Model draft/published/closed/cancelled events with all specified information, access/pass rules, display order, and the approved capacity, registration window, additional registration questions, and registration-open state.
• EVT-002 · P1 · Blocked by DEC-008 Define and enforce valid visibility, joining, membership/pass, and invitation-rule combinations.
• EVT-003 · P1 · Blocked by DEC-008 Build authorized event create/edit/publish/close/cancel administration with validation for dates and approved rule combinations.
• EVT-004 · P1 Build upcoming-event list and event-detail bot views, including day-pass location navigation where applicable.
• EVT-005 · P1 Build the Join journey and create a registration—not an attended record—with member/user snapshot, phone, pass response, extra answers, and timestamp.
• EVT-006 · P1 · Blocked by DEC-008/DEC-009 Enforce unique registration, registration window, registration-open state, event state, and eligibility under duplicate or concurrent requests.
• EVT-007 · P1 Send one saved-registration confirmation with the event's approved timezone and key instructions.
• EVT-008 · P1 · Blocked by DEC-009 Build registration/attendance list, search, cancellation/removal, and approved status transitions among Registered, Attended, Did not attend, Cancelled, and—if enabled—Waiting list.
• EVT-009 · P1 · Blocked by DEC-009 Implement the approved participant self-cancellation behavior and cut-off.
• EVT-010 · P1 · Blocked by DEC-009 Export only approved attendance fields in the agreed format and, if required by DEC-010, log the administrator action.
• EVT-011 · P2 · Blocked by DEC-009 If approved, implement atomic waiting-list placement, ordering, promotion, expiry, and notifications.
• EVT-012 · P1 · Blocked by DEC-008 Implement invitation creation/import, secure matching, redemption, and administration for the specified invitation-only access option unless the approved baseline removes it.
• EVT-013 · P1 Test visibility/joining separately, all rule combinations, pass handling, duplicate delivery, cancellation, attendance, export authorization, and—if approved—concurrent last-space registration.
• EVT-014 · P1 · Blocked by DEC-009 If capacity is approved, enforce it atomically, show available spaces, and let authorized administrators close/reopen registration without cancelling the event.

10. Notice board

• NOT-001 · P1 Model notices with title, description, category, publication/expiry time, link/attachment, contact details, publication state, and display order.
• NOT-002 · P1 Build authorized notice create/edit/preview/publish/unpublish/schedule/archive administration and category assignment.
• NOT-003 · P1 Build active/recent notice list and detail bot views with link/attachment handling.
• NOT-004 · P1 · Blocked by DEC-005 Apply approved global/per-notice visibility rules.
• NOT-005 · P1 Make scheduling and expiry deterministic in the approved timezone.
• NOT-006 · P1 Test access, publication lifecycle, scheduling boundaries, expiry, attachments, archive/history, and empty states.

11. Help and emergency contacts

• HLP-001 · P1 Model contact name, purpose, telephone, WhatsApp number, operating hours, instructions, emergency flag, active state, and display order.
• HLP-002 · P1 Build authorized contact add/edit/archive/reorder administration.
• HLP-003 · P1 Build the bot contact list/details with usable phone/WhatsApp actions and the approved prominent non-response-service disclaimer.
• HLP-004 · P1 · Blocked by DEC-005 Apply the approved help/emergency visibility rule and prove HELP/EMERGENCY work from every state.
• HLP-005 · P1 Assign an operational owner and recurring review date for emergency content freshness.
• HLP-006 · P1 Test global access, ordering, inactive contacts, malformed numbers, empty state, and disclaimer presence.

12. Security, privacy, and operational readiness

• OPS-001 · P0 · Blocked by DEC-011 Publish privacy notices and implement approved consent, access, correction, export, retention, deletion, and incident workflows.
• OPS-002 · P1 Verify WhatsApp webhook signatures, protect replay windows, rate-limit abusive traffic, and test authorization boundaries.
• OPS-003 · P1 Restrict media and precise-location access with expiring links/authorized streaming; validate type/size and apply approved scanning.
• OPS-004 · P1 Redact phone, membership, identity, location, media, credentials, and tokens from logs, errors, analytics, and support exports.
• OPS-005 · P1 Add service and business monitoring for webhook failures, outbound failures, membership outages, queue backlog, validation failure spikes, and failed jobs.
• OPS-006 · P1 Test backup restoration, dependency outage, retry/dead-letter handling, credential rotation, and rollback.
• OPS-007 · P1 · Blocked by DEC-012 Load-test agreed normal and peak traffic, including simultaneous event registration.
• OPS-008 · P1 Complete dependency, static, dynamic, upload, authentication, authorization, and manual security review findings.
• OPS-009 · P1 Complete accessibility and supported-browser testing for the portal and usability testing for real WhatsApp users.

13. End-to-end acceptance and launch

• REL-001 · P1 Build automated end-to-end tests for every approved public and restricted bot journey plus portal content updates.
• REL-002 · P1 Prepare UAT scripts and trace them to approved requirements, access rules, roles, error paths, and client decisions.
• REL-003 · P1 Seed staging with representative non-sensitive trails, passes, requests, events, notices, contacts, members, and roles.
• REL-004 · P1 Obtain WhatsApp templates/production access and verify inbound, outbound, media, location, and delivery callbacks end to end.
• REL-005 · P1 Complete client UAT and record sign-off or explicitly accepted deviations.
• REL-006 · P1 Create administrator guides, content checklists, support/incident runbook, escalation contacts, and training.
• REL-007 · P1 Verify production domains/TLS, secrets, migrations, backups, dashboards, alerts, retention jobs, content, and least-privilege access.
• REL-008 · P1 Define pilot group, launch checklist, rollback criteria, stabilisation window, defect triage, and exit criteria.
• REL-009 · P1 Run the pilot, monitor agreed success/error measures, resolve release-blocking defects, and approve general launch.

Parked candidates — not part of the baseline MVP

Only promote these into the active backlog through an approved scope change. The first two are explicit future ideas in the specification; the remainder are possible expansions recorded here to keep them from leaking into MVP estimates.

• FUT-001 · P2 Proactive opt-in trail closure/reopening subscriptions and notifications.
• FUT-002 · P2 User-submitted notices with moderation and publication approval.
• FUT-003 · P2 Direct annual/day-pass purchase in WhatsApp.
• FUT-004 · P2 Usage, registration, and maintenance reporting beyond agreed operational metrics.
• FUT-005 · P2 Additional languages or channels.

Definition of done for every feature

• Approved acceptance criteria and access rules are met.
• Happy paths, boundary cases, invalid input, duplicate delivery, outages, and authorization are tested.
• Portal changes and bot output agree in staging.
• Logs/metrics support diagnosis without exposing sensitive data.
• Privacy, retention, security, accessibility, and audit requirements are met.
• Migrations, rollback, support notes, and administrator/user-facing content are reviewed.
• The product owner accepts the feature in UAT.