Live
Powered by

System events

Purpose

## System is the canonical workflow and delivery ledger inside the athlete daily log. It is coordinator-owned and written by Coach Luca-driven workflows.

What belongs here

Use ## System for:

  • save events
  • send events
  • evidence checks
  • external-system audits
  • repair or migration passes
  • operator-triggered interventions
  • meaningful workflow failures or blockers

Do not use ## System for athlete-facing coaching guidance.

Do not use it for detailed role analysis that belongs in a domain section.

Event style

  • Write ## System as a two-column markdown table with Time and Message.
  • Keep rows in chronological order.
  • Time is required for every row.
  • Use HH:MM format only.
  • Include channel, target, provider message ID, or external object ID in Message when those details matter to future audit.
  • Use plain factual wording.
  • When adding a new ## System event, read the full existing ## System table, merge the new row into the full row set, sort the entire table by HH:MM, and rewrite the full ## System section.
  • Do not append rows blindly.
  • Do not insert rows by anchor or partial patching inside the existing table.
  • Do not leave older rows stranded below newer rows after an update.

Use this exact table shell:

| Time | Message |
| --- | --- |

Add one row per event.

Save event

  • | 08:55 | morning plan generated and saved in canonical daily log |

Send event

  • | 08:55 | morning plan sent via Telegram to <athlete-name>, chat <chat-id>, message <message-id> |

Evidence check

  • | 16:44 | reviewed the athlete's completed TrainingPeaks ride file <workout-id> and saved endurance, recovery, and evening-summary composition notes in the canonical daily log |

External object update

  • | 10:56 | updated TrainingPeaks workout <workout-id> so each step name now carries the intended %FTP target explicitly |

Workflow failure or blocker

  • | 13:42 | logged a Coach Luca execution failure for the missed athlete follow-up after the athlete reply |

Placement rule

If the same fact would fit both ## System and a role section:

  • put the process fact in ## System
  • put the coaching interpretation in the relevant role section

Normalization rule:

  • treat ## System as one canonical table, not a sequence of local insertions
  • after every write, the visible order in the file must still be chronological
  • if the table is malformed or out of order, repair it as part of the current write instead of preserving the disorder

Generated events are logged on the athlete-local calendar day when the event actually happened, not on the day of the evidence being analyzed. If a morning workflow reviews yesterday's intake, workout, or message history, the save and send rows still belong in today's ## System table.

Example:

  • TP file review happened -> add a row in ## System
  • what that file means for tomorrow's ride -> ## Endurance and or ## Recovery