Repository navigation
[Feature] Annual renewal system #283
Description
Current delivery plan — 2026-10-15
Delivery plan: #558; launch verification: #564. Preserve the original requirements and design discussion below, with these implementation constraints:
- Use the independent CARES registration model introduced in Give CARES registrations their own table #478, not CARES fields on a collection entry. Collection removal must not silently destroy registration history.
- The January 21 design comment specifies January 1 prompts, a grace period through March 31, and reactivation by confirming. Reconcile the older body's “current calendar year = active” shortcut with that decision in one documented state rule used by profile, coverage and reports.
- Store enough confirmation history to prove consecutive confirmed years; elapsed days between registration and last confirmation is insufficient. Decide how to represent existing registrations with incomplete history, without fabricating past confirmations. Record that decision before migration.
- Implement individual and bulk confirmation end to end, owner-only and safe on repeated requests, with clear active/pending/lapsed presentation and retained history.
- Test year and March 31/April 1 boundaries, skipped years, legacy history, bulk failure, repeat confirmations and unauthorized access using a controlled clock.
Blocked by: None externally. Historical-data policy and the precise timezone/date boundary must be recorded before implementation is considered ready. Keep the admin-only gate while building this flow.
Earlier requirements and design
Overview
Members confirm their CARES registrations annually to maintain active status.
Parent: #276
Phase 2 - Activities
Requirements
- FR8.1: Track last confirmation date per registration
- FR8.2: Prompt members to confirm at start of calendar year
- FR8.3: Unconfirmed registrations marked as "lapsed" (not deleted)
- FR8.4: Consecutive confirmations earn longevity recognition
Logic
- Registration is "active" if
cares_last_confirmedis within current calendar year - Unconfirmed registrations become "lapsed" but data is retained
- Longevity seals count consecutive confirmed years
- 2+ consecutive years = longevity recognition
UX
- Dashboard notification for registrations needing confirmation
- Bulk "confirm all" option
- Individual confirmation per species
- Visual distinction for lapsed vs active registrations
Acceptance Criteria
- Annual confirmation prompt appears for registered species
- Confirmation updates
cares_last_confirmeddate - Lapsed registrations are visually distinguished
- Longevity indicator shows for 2+ consecutive years
- Bulk confirmation option available
Activity
jra3 commentedon Jan 21, 2026
UI/UX Design
Notification Delivery
Primary: Dashboard banner on member's CARES profile section
Secondary: Email notification (optional, if email system exists)
Timing
cares_last_confirmed< current yearRenewal UI
On CARES profile section, show renewal banner when species need confirmation:
Style:
bg-yellow-50 border-l-4 border-yellow-400Bulk Confirmation
Lapsed Visual Treatment
Species not confirmed by end of Q1 (March 31):
Re-Activation
Lapsed registrations can be renewed at any time:
cares_last_confirmedto current dateLongevity Milestones
Badge progression shown on species cards:
Hover shows: "Maintained for X consecutive years since [year]"
feat: add CARES annual renewal system (#283)
Give CARES registrations their own table
Give CARES registrations their own table
Give CARES registrations their own table (#478)