Repository navigation
App completion roadmap: reports, collections, CARES and Member guidance #558
Description
Goal and evidence
Complete the underdeveloped Member and committee journeys identified from the site map, source at d162221, and development history as of 2026-10-15. The next investment is finishing these flows through the existing domain boundaries, rather than another broad architectural rewrite.
The report form captures more than its report displays; collection creation/persistence has received recent fixes but some controls remain incomplete; CARES has substantial implemented code but is still admin-only. Newcomer guidance lags the October lifecycle changes. External enrichment has an unresolved operational choice. These are source/history findings, not usage analytics.
Recommended delivery order
1. HAP/CAP report completeness — start here
- Complete Program-aware Submission reports for HAP and CAP #559 — Display all applicable captured details with Program-appropriate labels.
- Add supplements fields to approved submission editor #158 — Add normalized supplements to approved details edits, with atomic data/audit persistence.
These can ship independently. Finish this phase when a HAP/CAP Member and reviewer can see the complete report, and a committee correction survives reload without changing points or Witness state.
2. Collection usability — three independent slices
- Allow the first keeper to add a Species to their collection with Species preselected #561 — Let the first keeper add a Species with the Species preselected.
- Make collection photo removal work end to end #560 — Replace the collection photo removal stub with a working, ownership-checked flow.
- Let Members view removed entries in their collection history #562 — Let owners inspect removed entries without expanding public visibility.
Suggested order is entry, maintenance, history. There are no artificial blocking edges between these fixes. Finish when the complete add/edit/remove/view-history journey is demonstrated.
3. CARES — complete behind the gate, then launch
- [PRD] CARES Program Tracking #276 — Existing CARES program umbrella, refreshed with current implementation status.
Work within that umbrella:
- [Feature] Annual renewal system #283 Annual re-confirmation and [Feature] Article submission #281 article entry establish trustworthy registration/activity data. [Feature] BAP-CARES integration prompt #282 adds the BAP opt-in prompt behind the gate and can proceed independently.
- [Feature] CARES liaison report export #284 delivers liaison reporting after [Feature] Annual renewal system #283 and [Feature] Article submission #281.
- Verify the complete CARES journey and prepare the Member launch #564 verifies the whole journey and prepares launch after [Feature] Article submission #281, [Feature] Annual renewal system #283, [Feature] CARES liaison report export #284 and [Feature] BAP-CARES integration prompt #282.
Do not interpret old unchecked boxes on #279/#285 as absent features: reconcile against the existing profile/browser first. CARES registration uses the independent model from #478. Keep the admin-only gate until the documented release checks and decision are complete. #286 standings are optional follow-up.
4. First-time Member guidance — can run alongside phases 1–2
- Add a current first-Submission guide for BAP, HAP and CAP #563 — Current BAP/HAP/CAP participation guide reachable from Home and the form.
Use CONTEXT.md and accepted ADRs for lifecycle behavior. Publish examples against the completed report experience; establish any undocumented club logistics before presenting them as instructions.
5. External enrichment — make the decision in parallel
- Decide: enable Wikipedia/GBIF enrichment in prod or remove the External Data page #461 — Verify the live configuration and choose supported sync or removal of the admin surface.
#249 is conditional on #461 choosing supported sync. Use Fly-era operations and an observed manual sync, not the historical EC2 cron recipe. Do not enable providers or implement both alternatives as part of this planning task.
Architecture and verification
- Extend existing lifecycle operations so approved details, supplement rows and audit records form one transaction; preserve the separation between details and Species/points corrections.
- Reuse collection ownership/privacy queries and shared media conventions; do not infer object ownership from a client-provided storage key.
- Use one CARES confirmation/state rule across profiles, coverage and reporting; retained evidence must support claimed consecutive years.
- Each implementation issue specifies focused behavioral tests. Verify UI journeys on public staging with chikin-farm; remote browser tests cannot use localhost.
- Existing in-progress Member-save transaction changes are separate work; this plan does not assume they have merged.
Decisions still to record
- CARES: treatment of incomplete historical confirmations and precise date boundaries (the prior March 31 grace-period decision is preserved), PDF storage/access policy, and liaison report period/field semantics.
- External enrichment: the operating model, owner and conditional implementation scope.
Tickets with unresolved decisions carry needs-triage; specified slices carry ready-for-agent. Phase order expresses priority, while native dependencies represent actual prerequisites. No production rollout or new implementation is performed by this filing pass.
Activity