Untitled Project
Personal Training OS — Requirements
1. Page structure and navigation
NAV-001
1.1. Personal Training OS page NAV-001

The system shall be created as a Notion page titled "Personal Training OS".
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • NAV-003
    1.3. Link below Inbox NAV-003

    When the Personal Training OS page is created, the system shall place a link to it directly below the "Inbox" link on the Personal Dashboard.
    • DES-VIEWS
      1.2. Dashboard page and linked views DES-VIEWS

      A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
    • TC-17
      1.17. Page placement TC-17

      The Personal Training OS page is a child of Personal Dashboard, linked below Inbox.
  • NAV-004
    1.4. Entry points to all databases NAV-004

    The system shall present, from its top-level page, entry points to every database.
    • DES-VIEWS
      1.2. Dashboard page and linked views DES-VIEWS

      A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
NAV-002
1.2. Child of Personal Dashboard NAV-002

The system shall exist as a child page under the "Personal Dashboard" page.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • TC-17
    1.17. Page placement TC-17

    The Personal Training OS page is a child of Personal Dashboard, linked below Inbox.
  • NAV-001
    1.1. Personal Training OS page NAV-001

    The system shall be created as a Notion page titled "Personal Training OS".
NAV-003
1.3. Link below Inbox NAV-003

When the Personal Training OS page is created, the system shall place a link to it directly below the "Inbox" link on the Personal Dashboard.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • TC-17
    1.17. Page placement TC-17

    The Personal Training OS page is a child of Personal Dashboard, linked below Inbox.
  • NAV-001
    1.1. Personal Training OS page NAV-001

    The system shall be created as a Notion page titled "Personal Training OS".
NAV-004
1.4. Entry points to all databases NAV-004

The system shall present, from its top-level page, entry points to every database.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
2. Identity model (People)
PEO-001
2.1. Create People database PEO-001

The system shall create a People database.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-002
    2.2. People as primary identity model PEO-002

    The system shall use People as the primary identity model for the entire system.
    • DES-PEOPLE
      1.4. People identity hub DES-PEOPLE

      People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-003
    2.3. Seed Primary User and Secondary User PEO-003

    When the People database is created, the system shall seed two people, Primary User and Secondary User.
    • DES-PEOPLE
      1.4. People identity hub DES-PEOPLE

      People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-004
    2.4. Optional Notion User and external IDs PEO-004

    Where a person record supports automation, the People database shall provide optional Notion User and external ID fields for that person.
    • DES-PEOPLE
      1.4. People identity hub DES-PEOPLE

      People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-005
    2.5. Secondary User first-class across areas PEO-005

    The system shall allow Secondary User to be referenced from Goals, Races, Metrics/Check-ins, Nutrition Log, and future training structures, not solely as a placeholder.
    • DES-PEOPLE
      1.4. People identity hub DES-PEOPLE

      People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
    • TC-07
      1.7. Secondary User is first-class TC-07

      Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
  • PEO-006
    2.6. Person relation on attributable databases PEO-006

    Every database that records person-attributable data shall relate to People via a Person relation rather than free text.
    • DES-PEOPLE
      1.4. People identity hub DES-PEOPLE

      People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
    • DES-RELATIONS
      1.22. Relationship map and rollups DES-RELATIONS

      Ownership and cardinality of all relations, ensuring Metrics and Nutrition relate to People and that shoe mileage and hockey load are derivable via rollups rather than manual tally. See design-schema section 17.
    • TS-005
      5.5. Relates to People TS-005

      Each Training Session shall relate to People via a Person relation.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
      • TC-07
        1.7. Secondary User is first-class TC-07

        Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
  • PEO-001
    2.1. Create People database PEO-001

    The system shall create a People database.
PEO-002
2.2. People as primary identity model PEO-002

The system shall use People as the primary identity model for the entire system.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-001
    2.1. Create People database PEO-001

    The system shall create a People database.
PEO-003
2.3. Seed Primary User and Secondary User PEO-003

When the People database is created, the system shall seed two people, Primary User and Secondary User.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-001
    2.1. Create People database PEO-001

    The system shall create a People database.
PEO-004
2.4. Optional Notion User and external IDs PEO-004

Where a person record supports automation, the People database shall provide optional Notion User and external ID fields for that person.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • PEO-001
    2.1. Create People database PEO-001

    The system shall create a People database.
PEO-005
2.5. Secondary User first-class across areas PEO-005

The system shall allow Secondary User to be referenced from Goals, Races, Metrics/Check-ins, Nutrition Log, and future training structures, not solely as a placeholder.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • TC-07
    1.7. Secondary User is first-class TC-07

    Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
  • PEO-001
    2.1. Create People database PEO-001

    The system shall create a People database.
PEO-006
2.6. Person relation on attributable databases PEO-006

Every database that records person-attributable data shall relate to People via a Person relation rather than free text.
  • DES-PEOPLE
    1.4. People identity hub DES-PEOPLE

    People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.
  • DES-RELATIONS
    1.22. Relationship map and rollups DES-RELATIONS

    Ownership and cardinality of all relations, ensuring Metrics and Nutrition relate to People and that shoe mileage and hockey load are derivable via rollups rather than manual tally. See design-schema section 17.
  • TS-005
    5.5. Relates to People TS-005

    Each Training Session shall relate to People via a Person relation.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TC-07
      1.7. Secondary User is first-class TC-07

      Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
3. Architecture (databases up front)
ARCH-001
3.1. Create all databases up front ARCH-001

The system shall create the full set of databases at build time regardless of immediate use.
  • DES-ARCH
    1.1. Full architecture created up front DES-ARCH

    Create all fifteen databases at build time with schema in place, regardless of immediate use. See design-schema section 3.
  • ARCH-003
    3.3. Create even if used later ARCH-003

    Where a database will be used later but not immediately, the system shall still create it now with its schema in place.
    • DES-ARCH
      1.1. Full architecture created up front DES-ARCH

      Create all fifteen databases at build time with schema in place, regardless of immediate use. See design-schema section 3.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-002
      5.2. Automation fields on sessions TS-002

      Each Training Session shall carry the standard automation fields.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-003
      5.3. Session Type TS-003

      Each Training Session shall provide a Session Type such as Run, Race, Workout, or Hockey Game.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-004
      5.4. Status TS-004

      Each Training Session shall provide a Status such as Planned or Completed.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-005
      5.5. Relates to People TS-005

      Each Training Session shall relate to People via a Person relation.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
      • TC-07
        1.7. Secondary User is first-class TC-07

        Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
    • TS-006
      5.6. Distance field TS-006

      Each running Training Session shall provide a Distance field.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-007
      5.7. Run Type field TS-007

      Each running Training Session shall provide a Run Type field such as easy, very easy, long, tempo, intervals, or 5K pace.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TS-008
      5.8. Shoe and Route relations TS-008

      Each Training Session shall provide a Running Shoe relation and a Running Route relation.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
      • TC-14
        1.14. Session relationships wired TC-14

        The 11-mile run relates to Person, Running Shoe, Running Route, and Training Block.
    • HIST-001
      7.1. Seed 5-mile hill repeats HIST-001

      The system shall add a completed Training Session for the 5-mile hill repeats run on an example date.
      • DES-HIST
        1.6. Historical run seeds DES-HIST

        Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
      • TC-13
        1.13. Historical runs correct TC-13

        11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
    • HIST-002
      7.2. Seed 11-mile long run HIST-002

      The system shall add a completed Training Session for the 11-mile long run on an example date.
      • DES-HIST
        1.6. Historical run seeds DES-HIST

        Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
      • TC-13
        1.13. Historical runs correct TC-13

        11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
  • RACE-001
    8.1. Create Races database RACE-001

    The system shall create a Races database.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
    • RACE-002
      8.2. Person and automation fields on races RACE-002

      Each Race shall relate to People and carry the standard automation fields where meaningful.
      • DES-RACES
        1.9. Races schema and seeds DES-RACES

        Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
    • RACE-003
      8.3. Seed Example Half Marathon RACE-003

      When the Races database is created, the system shall seed the Example Half Marathon on an example date for Primary User, Type Half Marathon, Goal sub-2 ideal finish strong acceptable, Goal Time 2:00:00, Status Training/Registered.
      • DES-RACES
        1.9. Races schema and seeds DES-RACES

        Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
      • DES-D2
        2.2. Times stored as text with optional numeric seconds DES-D2

        Notion has no duration type, so Goal Time / Result Time are text H:MM:SS with an optional numeric seconds field where math is needed.
      • DES-D5
        2.5. Compound seed statuses kept literal DES-D5

        The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
      • TC-12
        1.12. Race seeds correct TC-12

        Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
    • RACE-004
      8.4. Seed Example 5K RACE-004

      When the Races database is created, the system shall seed the Example 5K on an example date for Primary User, Type 5K, Status Registered/Planned.
      • DES-RACES
        1.9. Races schema and seeds DES-RACES

        Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
      • DES-D5
        2.5. Compound seed statuses kept literal DES-D5

        The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
      • TC-12
        1.12. Race seeds correct TC-12

        Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
    • RACE-005
      8.5. Runs relate to Race RACE-005

      Where a Race has associated training runs, the system shall allow those Training Sessions to relate to the Race.
      • DES-RACES
        1.9. Races schema and seeds DES-RACES

        Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • LIB-001
    11.1. Create Exercise Library LIB-001

    The system shall create an Exercise Library database cataloguing individual exercises and drills.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
    • LIB-002
      11.2. Record required equipment LIB-002

      Where an exercise requires equipment, the Exercise Library shall record the required equipment drawn from the available set.
      • DES-EXLIB
        1.14. Exercise Library with constrained equipment DES-EXLIB

        Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • TMP-001
    11.3. Create Workout Templates TMP-001

    The system shall create a Workout Templates database composed of exercises from the Exercise Library.
    • DES-TEMPLATES
      1.15. Workout Templates doable by construction DES-TEMPLATES

      Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.
    • TC-20
      1.20. Training materials present TC-20

      At least one running, one strength, and one hockey Workout Template exist, plus Hockey Drills.
  • TMP-002
    11.4. Create Exercise Log TMP-002

    The system shall create an Exercise Log database recording performed exercises, relatable to Training Sessions and People.
    • DES-EXLOG
      1.16. Exercise Log DES-EXLOG

      Exercise Log relating to Training Sessions and Exercise Library, with Person and Date rolled up from the session, plus sets/reps/weight/distance/duration/RPE. See design-schema section 9.
  • SHO-001
    12.1. Create Running Shoes SHO-001

    The system shall create a Running Shoes database.
    • DES-SHOES
      1.10. Running Shoes with mileage rollup DES-SHOES

      Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
    • SHO-002
      12.2. Seed an example running shoe SHO-002

      When the Running Shoes database is created, the system shall seed an example running shoe.
      • DES-SHOES
        1.10. Running Shoes with mileage rollup DES-SHOES

        Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
    • SHO-003
      12.3. Session to Shoe relation SHO-003

      Each Training Session shall provide a Running Shoe relation.
      • DES-SHOES
        1.10. Running Shoes with mileage rollup DES-SHOES

        Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
    • SHO-004
      12.4. Total mileage rollup SHO-004

      The system shall compute total mileage per shoe via a rollup or formula that sums Distance across the Training Sessions related to that shoe.
      • DES-SHOES
        1.10. Running Shoes with mileage rollup DES-SHOES

        Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
      • TC-05
        1.5. Shoe mileage rollup equals 16 TC-05

        an example running shoe Total Miles = 16 (sum of Distance from the two linked runs, 11 + 5).
      • TC-06
        1.6. Rollup updates on new run TC-06

        Linking a new run to the shoe increases Total Miles; unlinking returns it to the prior value.
    • SHO-005
      12.5. Garmin gear can improve mileage SHO-005

      Where Garmin gear data becomes available later, the system shall allow that data to improve or override shoe mileage.
      • DES-SHOES
        1.10. Running Shoes with mileage rollup DES-SHOES

        Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • RTE-001
    13.1. Create Running Routes RTE-001

    The system shall create a Running Routes database.
    • DES-ROUTES
      1.11. Running Routes DES-ROUTES

      Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
    • RTE-002
      13.2. Seed generic routes RTE-002

      When the Running Routes database is created, the system shall seed generic routes Outdoor Run, Treadmill Run, Race Route, and Unknown/To Assign.
      • DES-ROUTES
        1.11. Running Routes DES-ROUTES

        Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
    • RTE-003
      13.3. Session to Route relation RTE-003

      Each running Training Session shall provide a Running Route relation.
      • DES-ROUTES
        1.11. Running Routes DES-ROUTES

        Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
  • MET-001
    14.1. Create Metrics/Check-ins MET-001

    The system shall create a Metrics/Check-ins database up front.
    • DES-METRICS
      1.17. Metrics / Check-ins (daily wide) DES-METRICS

      Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
    • DES-D4
      2.4. Metrics as daily-wide rows DES-D4

      Metrics/Check-ins are one wide row per person per day, optimized for manual entry; high-frequency wearable streams would use a long-format companion added when an integration lands.
    • MET-002
      14.2. Automation fields on metrics MET-002

      Each Metrics/Check-ins record shall carry the standard automation fields.
      • DES-METRICS
        1.17. Metrics / Check-ins (daily wide) DES-METRICS

        Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
    • MET-003
      14.3. Metrics sources MET-003

      The Metrics/Check-ins database shall be automation-ready for Garmin, Apple Health, Apple Watch, and Manual.
      • DES-METRICS
        1.17. Metrics / Check-ins (daily wide) DES-METRICS

        Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
    • MET-004
      14.4. Metrics relate to People MET-004

      Each Metrics/Check-ins record shall relate to People.
      • DES-METRICS
        1.17. Metrics / Check-ins (daily wide) DES-METRICS

        Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • NUT-001
    15.1. Create Nutrition Log NUT-001

    The system shall create a Nutrition Log database up front.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
    • NUT-002
      15.2. Automation fields on nutrition NUT-002

      Each Nutrition Log record shall carry the standard automation fields.
      • DES-NUTRITION
        1.18. Nutrition Log DES-NUTRITION

        Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
    • NUT-003
      15.3. Nutrition sources NUT-003

      The Nutrition Log database shall be automation-ready for MyFitnessPal and Manual.
      • DES-NUTRITION
        1.18. Nutrition Log DES-NUTRITION

        Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
    • NUT-004
      15.4. CSV and API import later NUT-004

      Where bulk historical data exists, the system shall support later CSV or API imports into the Nutrition Log.
      • DES-NUTRITION
        1.18. Nutrition Log DES-NUTRITION

        Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
    • NUT-005
      15.5. Nutrition relates to People NUT-005

      Each Nutrition Log record shall relate to People.
      • DES-NUTRITION
        1.18. Nutrition Log DES-NUTRITION

        Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • WKR-001
    16.1. Create Weekly Reviews WKR-001

    The system shall create a Weekly Reviews database now.
    • DES-WEEKLY
      1.19. Weekly Reviews DES-WEEKLY

      Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
    • WKR-002
      16.2. Manual at first WKR-002

      The system shall allow Weekly Reviews to be filled in manually initially.
      • DES-WEEKLY
        1.19. Weekly Reviews DES-WEEKLY

        Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
    • WKR-003
      16.3. Automatable later WKR-003

      Where automation is added later, the system shall allow Weekly Reviews to be populated automatically.
      • DES-WEEKLY
        1.19. Weekly Reviews DES-WEEKLY

        Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
  • GOL-001
    17.1. Create Goals GOL-001

    The system shall create a Goals database.
    • DES-GOALS
      1.13. Goals DES-GOALS

      Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
    • GOL-002
      17.2. Goals relate to People including Secondary User GOL-002

      Each Goal shall relate to People, including Secondary User.
      • DES-GOALS
        1.13. Goals DES-GOALS

        Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
    • GOL-003
      17.3. Goal to Race relation GOL-003

      Where a Goal is tied to a race, the system shall allow it to relate to a Race.
      • DES-GOALS
        1.13. Goals DES-GOALS

        Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
      • TC-15
        1.15. Goal linked to Race TC-15

        The Sub-2:00 goal has a Race relation to the Example Half Marathon.
  • BLK-001
    17.4. Create Training Blocks BLK-001

    The system shall create a Training Blocks database representing multi-week training phases.
    • DES-BLOCKS
      1.12. Training Blocks DES-BLOCKS

      Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.
    • BLK-002
      17.5. Sessions relate to Block BLK-002

      The system shall allow Training Sessions to relate to a Training Block.
      • DES-BLOCKS
        1.12. Training Blocks DES-BLOCKS

        Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.
  • DRL-001
    18.1. Create Hockey Drills DRL-001

    The system shall create a Hockey Drills database.
    • DES-DRILLS
      1.20. Hockey Drills DES-DRILLS

      Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.
    • DRL-002
      18.2. Drill equipment excludes net DRL-002

      Where a Hockey Drill requires equipment, the system shall reference only available equipment such as stick, shooting pad, cones, and balance boards, and not a net.
      • DES-DRILLS
        1.20. Hockey Drills DES-DRILLS

        Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.
    • TC-20
      1.20. Training materials present TC-20

      At least one running, one strength, and one hockey Workout Template exist, plus Hockey Drills.
  • RES-001
    18.3. Create Resources RES-001

    The system shall create a Resources database for reference material.
    • DES-RESOURCES
      1.21. Resources DES-RESOURCES

      Resources reference database with Type, URL, Topic, and Notes. See design-schema section 16.
ARCH-002
3.2. Linked references to existing game databases ARCH-002

The system shall provide linked or embedded references to the existing Team A games and Team B games databases without recreating them.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
ARCH-003
3.3. Create even if used later ARCH-003

Where a database will be used later but not immediately, the system shall still create it now with its schema in place.
  • DES-ARCH
    1.1. Full architecture created up front DES-ARCH

    Create all fifteen databases at build time with schema in place, regardless of immediate use. See design-schema section 3.
4. Automation readiness (cross-cutting)
AUTO-001
4.1. Build automation fields in now AUTO-001

The system shall build automation fields into key databases at creation time.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • AUTO-003
      4.3. Source vocabulary AUTO-003

      The Source field shall be a select whose options include Garmin, MyFitnessPal, Apple Health, Apple Watch, Strava, Calendar, Manual, Notion, and Hockey DB.
      • DES-AUTO
        1.3. Standard Automation Block DES-AUTO

        A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • AUTO-004
      4.4. Manual default source AUTO-004

      When a record is created by hand rather than an integration, the system shall default its Source to Manual.
      • DES-AUTO
        1.3. Standard Automation Block DES-AUTO

        A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
      • TC-09
        1.9. Manual source default TC-09

        A hand-created session has Source = Manual.
    • AUTO-005
      4.5. Manual override blocks overwrite AUTO-005

      While a record's Manual Override is set, the system shall not permit an automated sync to overwrite that record's fields.
      • DES-AUTO
        1.3. Standard Automation Block DES-AUTO

        A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • AUTO-006
      4.6. Sync populates provenance fields AUTO-006

      When an automated import creates or updates a record, the system shall populate Source, Source ID, Imported At, and Last Synced At for that record.
      • DES-AUTO
        1.3. Standard Automation Block DES-AUTO

        A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • AUTO-007
      4.7. Failure surfaces in Sync Status AUTO-007

      If an automated sync fails or is incomplete for a record, then the system shall reflect the failure in that record's Sync Status.
      • DES-AUTO
        1.3. Standard Automation Block DES-AUTO

        A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • TS-002
      5.2. Automation fields on sessions TS-002

      Each Training Session shall carry the standard automation fields.
      • DES-TS
        1.5. Training Sessions core schema DES-TS

        Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • RACE-002
      8.2. Person and automation fields on races RACE-002

      Each Race shall relate to People and carry the standard automation fields where meaningful.
      • DES-RACES
        1.9. Races schema and seeds DES-RACES

        Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
    • MET-002
      14.2. Automation fields on metrics MET-002

      Each Metrics/Check-ins record shall carry the standard automation fields.
      • DES-METRICS
        1.17. Metrics / Check-ins (daily wide) DES-METRICS

        Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
    • NUT-002
      15.2. Automation fields on nutrition NUT-002

      Each Nutrition Log record shall carry the standard automation fields.
      • DES-NUTRITION
        1.18. Nutrition Log DES-NUTRITION

        Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • AUTO-001
    4.1. Build automation fields in now AUTO-001

    The system shall build automation fields into key databases at creation time.
AUTO-002
4.2. Standard automation field set AUTO-002

Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-003
    4.3. Source vocabulary AUTO-003

    The Source field shall be a select whose options include Garmin, MyFitnessPal, Apple Health, Apple Watch, Strava, Calendar, Manual, Notion, and Hockey DB.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-004
    4.4. Manual default source AUTO-004

    When a record is created by hand rather than an integration, the system shall default its Source to Manual.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
    • TC-09
      1.9. Manual source default TC-09

      A hand-created session has Source = Manual.
  • AUTO-005
    4.5. Manual override blocks overwrite AUTO-005

    While a record's Manual Override is set, the system shall not permit an automated sync to overwrite that record's fields.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-006
    4.6. Sync populates provenance fields AUTO-006

    When an automated import creates or updates a record, the system shall populate Source, Source ID, Imported At, and Last Synced At for that record.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-007
    4.7. Failure surfaces in Sync Status AUTO-007

    If an automated sync fails or is incomplete for a record, then the system shall reflect the failure in that record's Sync Status.
    • DES-AUTO
      1.3. Standard Automation Block DES-AUTO

      A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • TS-002
    5.2. Automation fields on sessions TS-002

    Each Training Session shall carry the standard automation fields.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • RACE-002
    8.2. Person and automation fields on races RACE-002

    Each Race shall relate to People and carry the standard automation fields where meaningful.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • MET-002
    14.2. Automation fields on metrics MET-002

    Each Metrics/Check-ins record shall carry the standard automation fields.
    • DES-METRICS
      1.17. Metrics / Check-ins (daily wide) DES-METRICS

      Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • NUT-002
    15.2. Automation fields on nutrition NUT-002

    Each Nutrition Log record shall carry the standard automation fields.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
AUTO-003
4.3. Source vocabulary AUTO-003

The Source field shall be a select whose options include Garmin, MyFitnessPal, Apple Health, Apple Watch, Strava, Calendar, Manual, Notion, and Hockey DB.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
AUTO-004
4.4. Manual default source AUTO-004

When a record is created by hand rather than an integration, the system shall default its Source to Manual.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • TC-09
    1.9. Manual source default TC-09

    A hand-created session has Source = Manual.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
AUTO-005
4.5. Manual override blocks overwrite AUTO-005

While a record's Manual Override is set, the system shall not permit an automated sync to overwrite that record's fields.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
AUTO-006
4.6. Sync populates provenance fields AUTO-006

When an automated import creates or updates a record, the system shall populate Source, Source ID, Imported At, and Last Synced At for that record.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
AUTO-007
4.7. Failure surfaces in Sync Status AUTO-007

If an automated sync fails or is incomplete for a record, then the system shall reflect the failure in that record's Sync Status.
  • DES-AUTO
    1.3. Standard Automation Block DES-AUTO

    A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.
5. Training Sessions (core)
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
TS-001
5.1. Create Training Sessions TS-001

The system shall create a Training Sessions database as the central log of all training activity.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-002
    5.2. Automation fields on sessions TS-002

    Each Training Session shall carry the standard automation fields.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-003
    5.3. Session Type TS-003

    Each Training Session shall provide a Session Type such as Run, Race, Workout, or Hockey Game.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-004
    5.4. Status TS-004

    Each Training Session shall provide a Status such as Planned or Completed.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-005
    5.5. Relates to People TS-005

    Each Training Session shall relate to People via a Person relation.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TC-07
      1.7. Secondary User is first-class TC-07

      Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
  • TS-006
    5.6. Distance field TS-006

    Each running Training Session shall provide a Distance field.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-007
    5.7. Run Type field TS-007

    Each running Training Session shall provide a Run Type field such as easy, very easy, long, tempo, intervals, or 5K pace.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-008
    5.8. Shoe and Route relations TS-008

    Each Training Session shall provide a Running Shoe relation and a Running Route relation.
    • DES-TS
      1.5. Training Sessions core schema DES-TS

      Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
    • TC-14
      1.14. Session relationships wired TC-14

      The 11-mile run relates to Person, Running Shoe, Running Route, and Training Block.
  • HIST-001
    7.1. Seed 5-mile hill repeats HIST-001

    The system shall add a completed Training Session for the 5-mile hill repeats run on an example date.
    • DES-HIST
      1.6. Historical run seeds DES-HIST

      Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
    • TC-13
      1.13. Historical runs correct TC-13

      11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
  • HIST-002
    7.2. Seed 11-mile long run HIST-002

    The system shall add a completed Training Session for the 11-mile long run on an example date.
    • DES-HIST
      1.6. Historical run seeds DES-HIST

      Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
    • TC-13
      1.13. Historical runs correct TC-13

      11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
TS-002
5.2. Automation fields on sessions TS-002

Each Training Session shall carry the standard automation fields.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
TS-003
5.3. Session Type TS-003

Each Training Session shall provide a Session Type such as Run, Race, Workout, or Hockey Game.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
TS-004
5.4. Status TS-004

Each Training Session shall provide a Status such as Planned or Completed.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
  • PEO-006
    2.6. Person relation on attributable databases PEO-006

    Every database that records person-attributable data shall relate to People via a Person relation rather than free text.
    • PEO-001
      2.1. Create People database PEO-001

      The system shall create a People database.
TS-005
5.5. Relates to People TS-005

Each Training Session shall relate to People via a Person relation.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TC-07
    1.7. Secondary User is first-class TC-07

    Secondary User exists in People and is selectable as Person on sessions/goals/metrics.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
TS-006
5.6. Distance field TS-006

Each running Training Session shall provide a Distance field.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
TS-007
5.7. Run Type field TS-007

Each running Training Session shall provide a Run Type field such as easy, very easy, long, tempo, intervals, or 5K pace.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
TS-008
5.8. Shoe and Route relations TS-008

Each Training Session shall provide a Running Shoe relation and a Running Route relation.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TC-14
    1.14. Session relationships wired TC-14

    The 11-mile run relates to Person, Running Shoe, Running Route, and Training Block.
6. Calendar import behavior
CAL-001
6.1. Calendar is source of planned runs CAL-001

The system shall use calendar events as the source for planned running sessions.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-003
      6.3. Source is Calendar CAL-003

      When a Training Session is created from a calendar event, the system shall set Source to Calendar.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-004
      6.4. Source ID is event ID CAL-004

      When a Training Session is created from a calendar event, the system shall set Source ID to the calendar event ID.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-005
      6.5. External URL from event link CAL-005

      Where the calendar event provides a link, the system shall set External URL to the calendar event link.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-006
      6.6. Future events are Planned CAL-006

      When a calendar event is a future event, the system shall set the Training Session Status to Planned.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-007
      6.7. Session Type Run or Race CAL-007

      When creating a Training Session from a calendar event, the system shall set Session Type to Run or Race as appropriate.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-008
      6.8. Distance from title when obvious CAL-008

      Where the distance is obvious from the event title, the system shall populate the Training Session Distance.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-009
      6.9. Run Type when explicit CAL-009

      Where the run type is explicitly stated in the event, the system shall set Run Type accordingly.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
    • CAL-010
      6.10. No inference when implicit CAL-010

      If the run type is not explicitly stated in the event, then the system shall leave Run Type unset.
      • DES-CAL
        1.7. Calendar import mapping DES-CAL

        Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-001
    6.1. Calendar is source of planned runs CAL-001

    The system shall use calendar events as the source for planned running sessions.
CAL-002
6.2. Event creates a Training Session CAL-002

When a calendar event represents a run or race, the system shall create a Training Session for it.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-003
    6.3. Source is Calendar CAL-003

    When a Training Session is created from a calendar event, the system shall set Source to Calendar.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-004
    6.4. Source ID is event ID CAL-004

    When a Training Session is created from a calendar event, the system shall set Source ID to the calendar event ID.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-005
    6.5. External URL from event link CAL-005

    Where the calendar event provides a link, the system shall set External URL to the calendar event link.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-006
    6.6. Future events are Planned CAL-006

    When a calendar event is a future event, the system shall set the Training Session Status to Planned.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-007
    6.7. Session Type Run or Race CAL-007

    When creating a Training Session from a calendar event, the system shall set Session Type to Run or Race as appropriate.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-008
    6.8. Distance from title when obvious CAL-008

    Where the distance is obvious from the event title, the system shall populate the Training Session Distance.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-009
    6.9. Run Type when explicit CAL-009

    Where the run type is explicitly stated in the event, the system shall set Run Type accordingly.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-010
    6.10. No inference when implicit CAL-010

    If the run type is not explicitly stated in the event, then the system shall leave Run Type unset.
    • DES-CAL
      1.7. Calendar import mapping DES-CAL

      Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-003
6.3. Source is Calendar CAL-003

When a Training Session is created from a calendar event, the system shall set Source to Calendar.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-004
6.4. Source ID is event ID CAL-004

When a Training Session is created from a calendar event, the system shall set Source ID to the calendar event ID.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-005
6.5. External URL from event link CAL-005

Where the calendar event provides a link, the system shall set External URL to the calendar event link.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-006
6.6. Future events are Planned CAL-006

When a calendar event is a future event, the system shall set the Training Session Status to Planned.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-007
6.7. Session Type Run or Race CAL-007

When creating a Training Session from a calendar event, the system shall set Session Type to Run or Race as appropriate.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-008
6.8. Distance from title when obvious CAL-008

Where the distance is obvious from the event title, the system shall populate the Training Session Distance.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-009
6.9. Run Type when explicit CAL-009

Where the run type is explicitly stated in the event, the system shall set Run Type accordingly.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
  • CAL-002
    6.2. Event creates a Training Session CAL-002

    When a calendar event represents a run or race, the system shall create a Training Session for it.
    • CAL-001
      6.1. Calendar is source of planned runs CAL-001

      The system shall use calendar events as the source for planned running sessions.
CAL-010
6.10. No inference when implicit CAL-010

If the run type is not explicitly stated in the event, then the system shall leave Run Type unset.
  • DES-CAL
    1.7. Calendar import mapping DES-CAL

    Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.
7. Historical runs
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
HIST-001
7.1. Seed 5-mile hill repeats HIST-001

The system shall add a completed Training Session for the 5-mile hill repeats run on an example date.
  • DES-HIST
    1.6. Historical run seeds DES-HIST

    Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
  • TC-13
    1.13. Historical runs correct TC-13

    11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
  • TS-001
    5.1. Create Training Sessions TS-001

    The system shall create a Training Sessions database as the central log of all training activity.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
HIST-002
7.2. Seed 11-mile long run HIST-002

The system shall add a completed Training Session for the 11-mile long run on an example date.
  • DES-HIST
    1.6. Historical run seeds DES-HIST

    Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.
  • TC-13
    1.13. Historical runs correct TC-13

    11-mile long run = 11 mi / Long; 5-mile hill repeats = 5 mi / Hills.
8. Races
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
RACE-001
8.1. Create Races database RACE-001

The system shall create a Races database.
  • DES-RACES
    1.9. Races schema and seeds DES-RACES

    Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • RACE-002
    8.2. Person and automation fields on races RACE-002

    Each Race shall relate to People and carry the standard automation fields where meaningful.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • RACE-003
    8.3. Seed Example Half Marathon RACE-003

    When the Races database is created, the system shall seed the Example Half Marathon on an example date for Primary User, Type Half Marathon, Goal sub-2 ideal finish strong acceptable, Goal Time 2:00:00, Status Training/Registered.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
    • DES-D2
      2.2. Times stored as text with optional numeric seconds DES-D2

      Notion has no duration type, so Goal Time / Result Time are text H:MM:SS with an optional numeric seconds field where math is needed.
    • DES-D5
      2.5. Compound seed statuses kept literal DES-D5

      The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
    • TC-12
      1.12. Race seeds correct TC-12

      Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
  • RACE-004
    8.4. Seed Example 5K RACE-004

    When the Races database is created, the system shall seed the Example 5K on an example date for Primary User, Type 5K, Status Registered/Planned.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
    • DES-D5
      2.5. Compound seed statuses kept literal DES-D5

      The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
    • TC-12
      1.12. Race seeds correct TC-12

      Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
  • RACE-005
    8.5. Runs relate to Race RACE-005

    Where a Race has associated training runs, the system shall allow those Training Sessions to relate to the Race.
    • DES-RACES
      1.9. Races schema and seeds DES-RACES

      Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • RACE-001
    8.1. Create Races database RACE-001

    The system shall create a Races database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
RACE-002
8.2. Person and automation fields on races RACE-002

Each Race shall relate to People and carry the standard automation fields where meaningful.
  • DES-RACES
    1.9. Races schema and seeds DES-RACES

    Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • RACE-001
    8.1. Create Races database RACE-001

    The system shall create a Races database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
RACE-003
8.3. Seed Example Half Marathon RACE-003

When the Races database is created, the system shall seed the Example Half Marathon on an example date for Primary User, Type Half Marathon, Goal sub-2 ideal finish strong acceptable, Goal Time 2:00:00, Status Training/Registered.
  • DES-RACES
    1.9. Races schema and seeds DES-RACES

    Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • DES-D2
    2.2. Times stored as text with optional numeric seconds DES-D2

    Notion has no duration type, so Goal Time / Result Time are text H:MM:SS with an optional numeric seconds field where math is needed.
  • DES-D5
    2.5. Compound seed statuses kept literal DES-D5

    The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
  • TC-12
    1.12. Race seeds correct TC-12

    Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
  • RACE-001
    8.1. Create Races database RACE-001

    The system shall create a Races database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
RACE-004
8.4. Seed Example 5K RACE-004

When the Races database is created, the system shall seed the Example 5K on an example date for Primary User, Type 5K, Status Registered/Planned.
  • DES-RACES
    1.9. Races schema and seeds DES-RACES

    Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
  • DES-D5
    2.5. Compound seed statuses kept literal DES-D5

    The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.
  • TC-12
    1.12. Race seeds correct TC-12

    Example Half Marathon = Half Marathon / Goal 2:00:00; Example 5K = 5K.
  • RACE-001
    8.1. Create Races database RACE-001

    The system shall create a Races database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
RACE-005
8.5. Runs relate to Race RACE-005

Where a Race has associated training runs, the system shall allow those Training Sessions to relate to the Race.
  • DES-RACES
    1.9. Races schema and seeds DES-RACES

    Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.
9. Hockey
HOK-001
9.1. Both teams equal HOK-001

The system shall treat both teams, Team A and Team B, equally.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • HOK-003
    9.3. Linked views for both teams HOK-003

    The system shall present linked views for both teams on the dashboard.
    • DES-VIEWS
      1.2. Dashboard page and linked views DES-VIEWS

      A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
HOK-002
9.2. Existing game databases are source of truth HOK-002

The system shall keep the existing hockey game databases as the source of truth for game data.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • DES-D3
    2.3. Two hockey-game relations (Team A, Team B) DES-D3

    Notion relations are single-target and the two game databases are separate sources of truth, so Training Sessions carry two relation properties disambiguated by Team.
  • HOK-004
    9.4. Count only after Attended HOK-004

    The system shall only count a hockey game toward training after it is marked Attended.
    • DES-HOCKEY
      1.8. Hockey game session and counts formula DES-HOCKEY

      Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
    • HOK-006
      9.6. Default not counted until Attended HOK-006

      By default the system shall set a hockey game to not count toward training until it is marked Attended.
      • DES-HOCKEY
        1.8. Hockey game session and counts formula DES-HOCKEY

        Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
      • TC-01
        1.1. Hockey not-attended does not count TC-01

        A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
    • HOK-007
      9.7. Attended marks it counting HOK-007

      When a hockey Game Training Session is marked Attended, the system shall set Counts Toward Training? to true.
      • DES-HOCKEY
        1.8. Hockey game session and counts formula DES-HOCKEY

        Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
      • TC-02
        1.2. Hockey attended counts TC-02

        A hockey session with Attendance = Attended has Counts Toward Training (auto) = true.
    • HOK-008
      9.8. Not attended excluded from load HOK-008

      If a hockey game is not marked Attended, then the system shall exclude it from training-load calculations.
      • DES-HOCKEY
        1.8. Hockey game session and counts formula DES-HOCKEY

        Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
      • TC-01
        1.1. Hockey not-attended does not count TC-01

        A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
    • TC-01
      1.1. Hockey not-attended does not count TC-01

      A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
    • TC-03
      1.3. Completed run counts TC-03

      A non-hockey session with Status = Completed has Counts Toward Training (auto) = true.
    • TC-04
      1.4. Planned session does not count TC-04

      A non-hockey session with Status = Planned has Counts = false; setting Status = Completed flips it to true.
  • HOK-005
    9.5. Game Training Session fields HOK-005

    A hockey Game Training Session shall provide Attendance Status, Counts Toward Training?, Team, linked source game, RPE, Notes, and Recovery notes.
    • DES-HOCKEY
      1.8. Hockey game session and counts formula DES-HOCKEY

      Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • TC-16
    1.16. Source-of-truth game link TC-16

    A hockey session can relate to a Team A/Team B game without altering the source game DB.
  • HOK-001
    9.1. Both teams equal HOK-001

    The system shall treat both teams, Team A and Team B, equally.
HOK-003
9.3. Linked views for both teams HOK-003

The system shall present linked views for both teams on the dashboard.
  • DES-VIEWS
    1.2. Dashboard page and linked views DES-VIEWS

    A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.
  • HOK-002
    9.2. Existing game databases are source of truth HOK-002

    The system shall keep the existing hockey game databases as the source of truth for game data.
HOK-004
9.4. Count only after Attended HOK-004

The system shall only count a hockey game toward training after it is marked Attended.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • HOK-006
    9.6. Default not counted until Attended HOK-006

    By default the system shall set a hockey game to not count toward training until it is marked Attended.
    • DES-HOCKEY
      1.8. Hockey game session and counts formula DES-HOCKEY

      Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
    • TC-01
      1.1. Hockey not-attended does not count TC-01

      A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
  • HOK-007
    9.7. Attended marks it counting HOK-007

    When a hockey Game Training Session is marked Attended, the system shall set Counts Toward Training? to true.
    • DES-HOCKEY
      1.8. Hockey game session and counts formula DES-HOCKEY

      Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
    • TC-02
      1.2. Hockey attended counts TC-02

      A hockey session with Attendance = Attended has Counts Toward Training (auto) = true.
  • HOK-008
    9.8. Not attended excluded from load HOK-008

    If a hockey game is not marked Attended, then the system shall exclude it from training-load calculations.
    • DES-HOCKEY
      1.8. Hockey game session and counts formula DES-HOCKEY

      Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
    • TC-01
      1.1. Hockey not-attended does not count TC-01

      A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
  • TC-01
    1.1. Hockey not-attended does not count TC-01

    A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
  • TC-03
    1.3. Completed run counts TC-03

    A non-hockey session with Status = Completed has Counts Toward Training (auto) = true.
  • TC-04
    1.4. Planned session does not count TC-04

    A non-hockey session with Status = Planned has Counts = false; setting Status = Completed flips it to true.
  • HOK-002
    9.2. Existing game databases are source of truth HOK-002

    The system shall keep the existing hockey game databases as the source of truth for game data.
HOK-005
9.5. Game Training Session fields HOK-005

A hockey Game Training Session shall provide Attendance Status, Counts Toward Training?, Team, linked source game, RPE, Notes, and Recovery notes.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • HOK-004
    9.4. Count only after Attended HOK-004

    The system shall only count a hockey game toward training after it is marked Attended.
    • HOK-002
      9.2. Existing game databases are source of truth HOK-002

      The system shall keep the existing hockey game databases as the source of truth for game data.
HOK-006
9.6. Default not counted until Attended HOK-006

By default the system shall set a hockey game to not count toward training until it is marked Attended.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • TC-01
    1.1. Hockey not-attended does not count TC-01

    A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
  • HOK-004
    9.4. Count only after Attended HOK-004

    The system shall only count a hockey game toward training after it is marked Attended.
    • HOK-002
      9.2. Existing game databases are source of truth HOK-002

      The system shall keep the existing hockey game databases as the source of truth for game data.
HOK-007
9.7. Attended marks it counting HOK-007

When a hockey Game Training Session is marked Attended, the system shall set Counts Toward Training? to true.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • TC-02
    1.2. Hockey attended counts TC-02

    A hockey session with Attendance = Attended has Counts Toward Training (auto) = true.
  • HOK-004
    9.4. Count only after Attended HOK-004

    The system shall only count a hockey game toward training after it is marked Attended.
    • HOK-002
      9.2. Existing game databases are source of truth HOK-002

      The system shall keep the existing hockey game databases as the source of truth for game data.
HOK-008
9.8. Not attended excluded from load HOK-008

If a hockey game is not marked Attended, then the system shall exclude it from training-load calculations.
  • DES-HOCKEY
    1.8. Hockey game session and counts formula DES-HOCKEY

    Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.
  • TC-01
    1.1. Hockey not-attended does not count TC-01

    A hockey session with Attendance = Did Not Attend has Counts Toward Training (auto) = false.
10. Equipment
EQP-001
10.1. Templates reflect available equipment only EQP-001

The system shall reflect currently available equipment only in workout templates and exercise library defaults.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • EQP-002
    10.2. Available equipment set EQP-002

    The system shall treat bodyweight, outdoor running, dumbbells, resistance bands, treadmill, stationary bike, foam roller, yoga mat, hockey stick, balance boards, shooting pad, cones, bench, and gym access as available.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • EQP-003
    10.3. Treadmill constraints EQP-003

    Where the treadmill is referenced, the system shall record its constraints of no incline and fastest pace 8:00 per mile.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • EQP-004
    10.4. Stickhandling ball pending EQP-004

    The system shall mark the stickhandling ball as pending and not currently usable.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
    • TC-10
      1.10. Equipment availability correct TC-10

      Kettlebells, Net, Barbell, Medicine ball = Not available; Stickhandling ball = Pending; the rest Available.
  • EQP-005
    10.5. No unavailable equipment assumptions EQP-005

    The system shall not assume availability of kettlebells, net, barbell, or medicine ball in any template.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
    • DES-D1
      2.1. Equipment as constrained multi-select, not a database DES-D1

      Availability is enforced by restricting Exercise Library / Hockey Drills equipment option lists rather than modeling an Equipment database, since the requirements mandate exactly fifteen databases and Equipment is not one.
    • EQP-006
      10.6. No template requires unavailable equipment EQP-006

      If a Workout Template would require unavailable equipment, then the system shall not present it as a currently-doable template.
      • DES-TEMPLATES
        1.15. Workout Templates doable by construction DES-TEMPLATES

        Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.
      • TC-11
        1.11. Templates use available gear only TC-11

        The seeded Workout Templates reference only Available equipment.
    • TC-10
      1.10. Equipment availability correct TC-10

      Kettlebells, Net, Barbell, Medicine ball = Not available; Stickhandling ball = Pending; the rest Available.
  • EQP-001
    10.1. Templates reflect available equipment only EQP-001

    The system shall reflect currently available equipment only in workout templates and exercise library defaults.
EQP-002
10.2. Available equipment set EQP-002

The system shall treat bodyweight, outdoor running, dumbbells, resistance bands, treadmill, stationary bike, foam roller, yoga mat, hockey stick, balance boards, shooting pad, cones, bench, and gym access as available.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • EQP-001
    10.1. Templates reflect available equipment only EQP-001

    The system shall reflect currently available equipment only in workout templates and exercise library defaults.
EQP-003
10.3. Treadmill constraints EQP-003

Where the treadmill is referenced, the system shall record its constraints of no incline and fastest pace 8:00 per mile.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • EQP-001
    10.1. Templates reflect available equipment only EQP-001

    The system shall reflect currently available equipment only in workout templates and exercise library defaults.
EQP-004
10.4. Stickhandling ball pending EQP-004

The system shall mark the stickhandling ball as pending and not currently usable.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • TC-10
    1.10. Equipment availability correct TC-10

    Kettlebells, Net, Barbell, Medicine ball = Not available; Stickhandling ball = Pending; the rest Available.
  • EQP-001
    10.1. Templates reflect available equipment only EQP-001

    The system shall reflect currently available equipment only in workout templates and exercise library defaults.
EQP-005
10.5. No unavailable equipment assumptions EQP-005

The system shall not assume availability of kettlebells, net, barbell, or medicine ball in any template.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • DES-D1
    2.1. Equipment as constrained multi-select, not a database DES-D1

    Availability is enforced by restricting Exercise Library / Hockey Drills equipment option lists rather than modeling an Equipment database, since the requirements mandate exactly fifteen databases and Equipment is not one.
  • EQP-006
    10.6. No template requires unavailable equipment EQP-006

    If a Workout Template would require unavailable equipment, then the system shall not present it as a currently-doable template.
    • DES-TEMPLATES
      1.15. Workout Templates doable by construction DES-TEMPLATES

      Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.
    • TC-11
      1.11. Templates use available gear only TC-11

      The seeded Workout Templates reference only Available equipment.
  • TC-10
    1.10. Equipment availability correct TC-10

    Kettlebells, Net, Barbell, Medicine ball = Not available; Stickhandling ball = Pending; the rest Available.
  • EQP-005
    10.5. No unavailable equipment assumptions EQP-005

    The system shall not assume availability of kettlebells, net, barbell, or medicine ball in any template.
    • EQP-001
      10.1. Templates reflect available equipment only EQP-001

      The system shall reflect currently available equipment only in workout templates and exercise library defaults.
EQP-006
10.6. No template requires unavailable equipment EQP-006

If a Workout Template would require unavailable equipment, then the system shall not present it as a currently-doable template.
  • DES-TEMPLATES
    1.15. Workout Templates doable by construction DES-TEMPLATES

    Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.
  • TC-11
    1.11. Templates use available gear only TC-11

    The seeded Workout Templates reference only Available equipment.
11. Exercise Library, Templates, Log
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
LIB-001
11.1. Create Exercise Library LIB-001

The system shall create an Exercise Library database cataloguing individual exercises and drills.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • LIB-002
    11.2. Record required equipment LIB-002

    Where an exercise requires equipment, the Exercise Library shall record the required equipment drawn from the available set.
    • DES-EXLIB
      1.14. Exercise Library with constrained equipment DES-EXLIB

      Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • LIB-001
    11.1. Create Exercise Library LIB-001

    The system shall create an Exercise Library database cataloguing individual exercises and drills.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
LIB-002
11.2. Record required equipment LIB-002

Where an exercise requires equipment, the Exercise Library shall record the required equipment drawn from the available set.
  • DES-EXLIB
    1.14. Exercise Library with constrained equipment DES-EXLIB

    Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
TMP-001
11.3. Create Workout Templates TMP-001

The system shall create a Workout Templates database composed of exercises from the Exercise Library.
  • DES-TEMPLATES
    1.15. Workout Templates doable by construction DES-TEMPLATES

    Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.
  • TC-20
    1.20. Training materials present TC-20

    At least one running, one strength, and one hockey Workout Template exist, plus Hockey Drills.
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
TMP-002
11.4. Create Exercise Log TMP-002

The system shall create an Exercise Log database recording performed exercises, relatable to Training Sessions and People.
  • DES-EXLOG
    1.16. Exercise Log DES-EXLOG

    Exercise Log relating to Training Sessions and Exercise Library, with Person and Date rolled up from the session, plus sets/reps/weight/distance/duration/RPE. See design-schema section 9.
12. Running Shoes
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
SHO-001
12.1. Create Running Shoes SHO-001

The system shall create a Running Shoes database.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-002
    12.2. Seed an example running shoe SHO-002

    When the Running Shoes database is created, the system shall seed an example running shoe.
    • DES-SHOES
      1.10. Running Shoes with mileage rollup DES-SHOES

      Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-003
    12.3. Session to Shoe relation SHO-003

    Each Training Session shall provide a Running Shoe relation.
    • DES-SHOES
      1.10. Running Shoes with mileage rollup DES-SHOES

      Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-004
    12.4. Total mileage rollup SHO-004

    The system shall compute total mileage per shoe via a rollup or formula that sums Distance across the Training Sessions related to that shoe.
    • DES-SHOES
      1.10. Running Shoes with mileage rollup DES-SHOES

      Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
    • TC-05
      1.5. Shoe mileage rollup equals 16 TC-05

      an example running shoe Total Miles = 16 (sum of Distance from the two linked runs, 11 + 5).
    • TC-06
      1.6. Rollup updates on new run TC-06

      Linking a new run to the shoe increases Total Miles; unlinking returns it to the prior value.
  • SHO-005
    12.5. Garmin gear can improve mileage SHO-005

    Where Garmin gear data becomes available later, the system shall allow that data to improve or override shoe mileage.
    • DES-SHOES
      1.10. Running Shoes with mileage rollup DES-SHOES

      Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-001
    12.1. Create Running Shoes SHO-001

    The system shall create a Running Shoes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
SHO-002
12.2. Seed an example running shoe SHO-002

When the Running Shoes database is created, the system shall seed an example running shoe.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-001
    12.1. Create Running Shoes SHO-001

    The system shall create a Running Shoes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
SHO-003
12.3. Session to Shoe relation SHO-003

Each Training Session shall provide a Running Shoe relation.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • SHO-001
    12.1. Create Running Shoes SHO-001

    The system shall create a Running Shoes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
SHO-004
12.4. Total mileage rollup SHO-004

The system shall compute total mileage per shoe via a rollup or formula that sums Distance across the Training Sessions related to that shoe.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
  • TC-05
    1.5. Shoe mileage rollup equals 16 TC-05

    an example running shoe Total Miles = 16 (sum of Distance from the two linked runs, 11 + 5).
  • TC-06
    1.6. Rollup updates on new run TC-06

    Linking a new run to the shoe increases Total Miles; unlinking returns it to the prior value.
  • SHO-001
    12.1. Create Running Shoes SHO-001

    The system shall create a Running Shoes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
SHO-005
12.5. Garmin gear can improve mileage SHO-005

Where Garmin gear data becomes available later, the system shall allow that data to improve or override shoe mileage.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
13. Running Routes
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
RTE-001
13.1. Create Running Routes RTE-001

The system shall create a Running Routes database.
  • DES-ROUTES
    1.11. Running Routes DES-ROUTES

    Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
  • RTE-002
    13.2. Seed generic routes RTE-002

    When the Running Routes database is created, the system shall seed generic routes Outdoor Run, Treadmill Run, Race Route, and Unknown/To Assign.
    • DES-ROUTES
      1.11. Running Routes DES-ROUTES

      Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
  • RTE-003
    13.3. Session to Route relation RTE-003

    Each running Training Session shall provide a Running Route relation.
    • DES-ROUTES
      1.11. Running Routes DES-ROUTES

      Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
  • RTE-001
    13.1. Create Running Routes RTE-001

    The system shall create a Running Routes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
RTE-002
13.2. Seed generic routes RTE-002

When the Running Routes database is created, the system shall seed generic routes Outdoor Run, Treadmill Run, Race Route, and Unknown/To Assign.
  • DES-ROUTES
    1.11. Running Routes DES-ROUTES

    Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
  • RTE-001
    13.1. Create Running Routes RTE-001

    The system shall create a Running Routes database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
RTE-003
13.3. Session to Route relation RTE-003

Each running Training Session shall provide a Running Route relation.
  • DES-ROUTES
    1.11. Running Routes DES-ROUTES

    Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.
14. Metrics / Check-ins
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
MET-001
14.1. Create Metrics/Check-ins MET-001

The system shall create a Metrics/Check-ins database up front.
  • DES-METRICS
    1.17. Metrics / Check-ins (daily wide) DES-METRICS

    Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • DES-D4
    2.4. Metrics as daily-wide rows DES-D4

    Metrics/Check-ins are one wide row per person per day, optimized for manual entry; high-frequency wearable streams would use a long-format companion added when an integration lands.
  • MET-002
    14.2. Automation fields on metrics MET-002

    Each Metrics/Check-ins record shall carry the standard automation fields.
    • DES-METRICS
      1.17. Metrics / Check-ins (daily wide) DES-METRICS

      Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • MET-003
    14.3. Metrics sources MET-003

    The Metrics/Check-ins database shall be automation-ready for Garmin, Apple Health, Apple Watch, and Manual.
    • DES-METRICS
      1.17. Metrics / Check-ins (daily wide) DES-METRICS

      Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • MET-004
    14.4. Metrics relate to People MET-004

    Each Metrics/Check-ins record shall relate to People.
    • DES-METRICS
      1.17. Metrics / Check-ins (daily wide) DES-METRICS

      Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • MET-001
    14.1. Create Metrics/Check-ins MET-001

    The system shall create a Metrics/Check-ins database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
MET-002
14.2. Automation fields on metrics MET-002

Each Metrics/Check-ins record shall carry the standard automation fields.
  • DES-METRICS
    1.17. Metrics / Check-ins (daily wide) DES-METRICS

    Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • MET-001
    14.1. Create Metrics/Check-ins MET-001

    The system shall create a Metrics/Check-ins database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
MET-003
14.3. Metrics sources MET-003

The Metrics/Check-ins database shall be automation-ready for Garmin, Apple Health, Apple Watch, and Manual.
  • DES-METRICS
    1.17. Metrics / Check-ins (daily wide) DES-METRICS

    Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
  • MET-001
    14.1. Create Metrics/Check-ins MET-001

    The system shall create a Metrics/Check-ins database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
MET-004
14.4. Metrics relate to People MET-004

Each Metrics/Check-ins record shall relate to People.
  • DES-METRICS
    1.17. Metrics / Check-ins (daily wide) DES-METRICS

    Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.
15. Nutrition Log
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
NUT-001
15.1. Create Nutrition Log NUT-001

The system shall create a Nutrition Log database up front.
  • DES-NUTRITION
    1.18. Nutrition Log DES-NUTRITION

    Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-002
    15.2. Automation fields on nutrition NUT-002

    Each Nutrition Log record shall carry the standard automation fields.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-003
    15.3. Nutrition sources NUT-003

    The Nutrition Log database shall be automation-ready for MyFitnessPal and Manual.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-004
    15.4. CSV and API import later NUT-004

    Where bulk historical data exists, the system shall support later CSV or API imports into the Nutrition Log.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-005
    15.5. Nutrition relates to People NUT-005

    Each Nutrition Log record shall relate to People.
    • DES-NUTRITION
      1.18. Nutrition Log DES-NUTRITION

      Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-001
    15.1. Create Nutrition Log NUT-001

    The system shall create a Nutrition Log database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
  • AUTO-002
    4.2. Standard automation field set AUTO-002

    Each key database shall include Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, and Raw Data/Notes where meaningful.
    • AUTO-001
      4.1. Build automation fields in now AUTO-001

      The system shall build automation fields into key databases at creation time.
NUT-002
15.2. Automation fields on nutrition NUT-002

Each Nutrition Log record shall carry the standard automation fields.
  • DES-NUTRITION
    1.18. Nutrition Log DES-NUTRITION

    Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-001
    15.1. Create Nutrition Log NUT-001

    The system shall create a Nutrition Log database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
NUT-003
15.3. Nutrition sources NUT-003

The Nutrition Log database shall be automation-ready for MyFitnessPal and Manual.
  • DES-NUTRITION
    1.18. Nutrition Log DES-NUTRITION

    Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-001
    15.1. Create Nutrition Log NUT-001

    The system shall create a Nutrition Log database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
NUT-004
15.4. CSV and API import later NUT-004

Where bulk historical data exists, the system shall support later CSV or API imports into the Nutrition Log.
  • DES-NUTRITION
    1.18. Nutrition Log DES-NUTRITION

    Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
  • NUT-001
    15.1. Create Nutrition Log NUT-001

    The system shall create a Nutrition Log database up front.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
NUT-005
15.5. Nutrition relates to People NUT-005

Each Nutrition Log record shall relate to People.
  • DES-NUTRITION
    1.18. Nutrition Log DES-NUTRITION

    Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.
16. Weekly Reviews
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
WKR-001
16.1. Create Weekly Reviews WKR-001

The system shall create a Weekly Reviews database now.
  • DES-WEEKLY
    1.19. Weekly Reviews DES-WEEKLY

    Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
  • WKR-002
    16.2. Manual at first WKR-002

    The system shall allow Weekly Reviews to be filled in manually initially.
    • DES-WEEKLY
      1.19. Weekly Reviews DES-WEEKLY

      Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
  • WKR-003
    16.3. Automatable later WKR-003

    Where automation is added later, the system shall allow Weekly Reviews to be populated automatically.
    • DES-WEEKLY
      1.19. Weekly Reviews DES-WEEKLY

      Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
  • WKR-001
    16.1. Create Weekly Reviews WKR-001

    The system shall create a Weekly Reviews database now.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
WKR-002
16.2. Manual at first WKR-002

The system shall allow Weekly Reviews to be filled in manually initially.
  • DES-WEEKLY
    1.19. Weekly Reviews DES-WEEKLY

    Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
  • WKR-001
    16.1. Create Weekly Reviews WKR-001

    The system shall create a Weekly Reviews database now.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
WKR-003
16.3. Automatable later WKR-003

Where automation is added later, the system shall allow Weekly Reviews to be populated automatically.
  • DES-WEEKLY
    1.19. Weekly Reviews DES-WEEKLY

    Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.
17. Goals and Training Blocks
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
GOL-001
17.1. Create Goals GOL-001

The system shall create a Goals database.
  • DES-GOALS
    1.13. Goals DES-GOALS

    Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
  • GOL-002
    17.2. Goals relate to People including Secondary User GOL-002

    Each Goal shall relate to People, including Secondary User.
    • DES-GOALS
      1.13. Goals DES-GOALS

      Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
  • GOL-003
    17.3. Goal to Race relation GOL-003

    Where a Goal is tied to a race, the system shall allow it to relate to a Race.
    • DES-GOALS
      1.13. Goals DES-GOALS

      Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
    • TC-15
      1.15. Goal linked to Race TC-15

      The Sub-2:00 goal has a Race relation to the Example Half Marathon.
  • GOL-001
    17.1. Create Goals GOL-001

    The system shall create a Goals database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
GOL-002
17.2. Goals relate to People including Secondary User GOL-002

Each Goal shall relate to People, including Secondary User.
  • DES-GOALS
    1.13. Goals DES-GOALS

    Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
  • GOL-001
    17.1. Create Goals GOL-001

    The system shall create a Goals database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
GOL-003
17.3. Goal to Race relation GOL-003

Where a Goal is tied to a race, the system shall allow it to relate to a Race.
  • DES-GOALS
    1.13. Goals DES-GOALS

    Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.
  • TC-15
    1.15. Goal linked to Race TC-15

    The Sub-2:00 goal has a Race relation to the Example Half Marathon.
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
BLK-001
17.4. Create Training Blocks BLK-001

The system shall create a Training Blocks database representing multi-week training phases.
  • DES-BLOCKS
    1.12. Training Blocks DES-BLOCKS

    Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.
  • BLK-002
    17.5. Sessions relate to Block BLK-002

    The system shall allow Training Sessions to relate to a Training Block.
    • DES-BLOCKS
      1.12. Training Blocks DES-BLOCKS

      Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.
  • BLK-001
    17.4. Create Training Blocks BLK-001

    The system shall create a Training Blocks database representing multi-week training phases.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
BLK-002
17.5. Sessions relate to Block BLK-002

The system shall allow Training Sessions to relate to a Training Block.
  • DES-BLOCKS
    1.12. Training Blocks DES-BLOCKS

    Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.
18. Hockey Drills and Resources
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
DRL-001
18.1. Create Hockey Drills DRL-001

The system shall create a Hockey Drills database.
  • DES-DRILLS
    1.20. Hockey Drills DES-DRILLS

    Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.
  • DRL-002
    18.2. Drill equipment excludes net DRL-002

    Where a Hockey Drill requires equipment, the system shall reference only available equipment such as stick, shooting pad, cones, and balance boards, and not a net.
    • DES-DRILLS
      1.20. Hockey Drills DES-DRILLS

      Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.
  • TC-20
    1.20. Training materials present TC-20

    At least one running, one strength, and one hockey Workout Template exist, plus Hockey Drills.
  • DRL-001
    18.1. Create Hockey Drills DRL-001

    The system shall create a Hockey Drills database.
    • ARCH-001
      3.1. Create all databases up front ARCH-001

      The system shall create the full set of databases at build time regardless of immediate use.
DRL-002
18.2. Drill equipment excludes net DRL-002

Where a Hockey Drill requires equipment, the system shall reference only available equipment such as stick, shooting pad, cones, and balance boards, and not a net.
  • DES-DRILLS
    1.20. Hockey Drills DES-DRILLS

    Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.
  • ARCH-001
    3.1. Create all databases up front ARCH-001

    The system shall create the full set of databases at build time regardless of immediate use.
RES-001
18.3. Create Resources RES-001

The system shall create a Resources database for reference material.
  • DES-RESOURCES
    1.21. Resources DES-RESOURCES

    Resources reference database with Type, URL, Topic, and Notes. See design-schema section 16.
19. Traceability (key relationships)
REL-001
19.1. Session relationships REL-001

The system shall relate Training Sessions to People, Training Blocks, Races, Running Shoes, Running Routes, Exercise Log, and the source game for hockey.
  • DES-TS
    1.5. Training Sessions core schema DES-TS

    Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.
  • TC-14
    1.14. Session relationships wired TC-14

    The 11-mile run relates to Person, Running Shoe, Running Route, and Training Block.
REL-002
19.2. Metrics and Nutrition relate to People REL-002

The system shall relate Metrics/Check-ins and Nutrition Log to People.
  • DES-RELATIONS
    1.22. Relationship map and rollups DES-RELATIONS

    Ownership and cardinality of all relations, ensuring Metrics and Nutrition relate to People and that shoe mileage and hockey load are derivable via rollups rather than manual tally. See design-schema section 17.
  • TC-08
    1.8. Person filter isolates data TC-08

    Filtering by Person = Primary User vs Secondary User returns only that person's rows.
REL-003
19.3. Rollups for mileage and load REL-003

The system shall provide rollups such that shoe mileage and hockey training load are derivable without manual tallying.
  • DES-SHOES
    1.10. Running Shoes with mileage rollup DES-SHOES

    Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.
20. Non-functional requirements
NFR-PRIV-001
20.1. Health data kept private NFR-PRIV-001

The system shall keep personal health and fitness data for Primary User and Secondary User within the private Notion workspace and shall not expose it publicly.
  • DES-NFR-PRIV
    3.1. Privacy - private workspace and least scope DES-NFR-PRIV

    Data lives in the private Notion workspace (not public); integrations request only the minimum scopes. See design-schema automation contract.
NFR-PRIV-002
20.2. Least-scope integrations NFR-PRIV-002

Where a third-party integration is added, the system shall request only the minimum data scopes required for that integration.
  • DES-NFR-PRIV
    3.1. Privacy - private workspace and least scope DES-NFR-PRIV

    Data lives in the private Notion workspace (not public); integrations request only the minimum scopes. See design-schema automation contract.
NFR-BKP-001
20.3. Backup and recovery NFR-BKP-001

The system shall support periodic export of its data so that training records are recoverable after accidental loss.
  • DES-NFR-DATA
    3.2. Backup, portability, retention DES-NFR-DATA

    Periodic Notion export provides backup and recovery; data stays API-accessible and exportable for portability; no automatic deletion so history is retained indefinitely.
  • TC-19
    1.19. Backup and recovery TC-19

    The OS data can be exported from Notion and is restorable.
NFR-PORT-001
20.4. Data portability NFR-PORT-001

The system shall keep its data API-accessible and exportable so it can be migrated off Notion if required.
  • DES-NFR-DATA
    3.2. Backup, portability, retention DES-NFR-DATA

    Periodic Notion export provides backup and recovery; data stays API-accessible and exportable for portability; no automatic deletion so history is retained indefinitely.
NFR-PERF-001
20.5. Responsive rollups at expected volume NFR-PERF-001

The dashboard and key rollups shall remain responsive at the expected single-user data volume of low hundreds of records.
  • DES-NFR-UX
    3.3. Performance and mobile usability DES-NFR-UX

    Single-user, low-hundreds data volume keeps rollups responsive; the Notion mobile apps provide low-effort cross-device capture.
NFR-USE-001
20.6. Mobile low-effort capture NFR-USE-001

The system shall be usable on the Notion mobile apps so that data capture is low-effort across devices.
  • DES-NFR-UX
    3.3. Performance and mobile usability DES-NFR-UX

    Single-user, low-hundreds data volume keeps rollups responsive; the Notion mobile apps provide low-effort cross-device capture.
  • TC-18
    1.18. Mobile capture TC-18

    A session/check-in can be logged with low effort in the Notion mobile app.
NFR-RET-001
20.7. Indefinite history retention NFR-RET-001

The system shall retain historical training data indefinitely, with no automatic deletion, to preserve long-term trends.
  • DES-NFR-DATA
    3.2. Backup, portability, retention DES-NFR-DATA

    Periodic Notion export provides backup and recovery; data stays API-accessible and exportable for portability; no automatic deletion so history is retained indefinitely.