Track gear usage and lifecycle — shoe mileage, bike components, climbing shoe sessions. Designed in SYNTHESIS §7.

Tables

equipment_catalog (shared product database, JSON-seeded)

• Brand, model, name, equipment_type, sport_types, year, image_url
• Types: running_shoes, climbing_shoes, approach_shoes, road_bike, mtb, harness, helmet, etc.
• Seeded from packages/seed-data/equipment-catalog.json
• Community submissions via PRs to the JSON file

equipment (athlete's personal gear)

• FK to athletes and optionally to equipment_catalog
• Self-referencing parent_id for component hierarchy (chain/cassette/tire as children of a bike — Intervals.icu pattern)
• Lifecycle: acquired_date, retired_date, retire_threshold + retire_unit
• Pre-existing usage: initial_distance_m (user adds shoes they've already run 200km in)
• Cumulative counters (updated on activity sync): total_distance_m, total_duration_s, total_activities
• Retirement thresholds: 800km for running shoes, 500 sessions for climbing shoes

activity_equipment (junction table)

• Links equipment to activities (most activities have 0-2 items)
• Also: climb_logs.equipment_id for per-ascent shoe tracking

UX flow

Athlete taps "Add Equipment" → searches catalog by name → sees product image and brand → selects → equipment row created with catalog_id FK. Custom/unlisted gear has no catalog_id.

Auto-assignment

sport_zone_priorities.default_equipment_id auto-assigns gear per sport type (e.g., all cycling activities get the road bike).

Depends on

Schema Migration, Seed Data Pipeline (equipment-catalog.json)

Reference

See docs/api-research/SYNTHESIS.md §7 (equipment_catalog, equipment, activity_equipment).