Spike: inventory "what changes over time?" across clinics

[WestonVoglesonger]

Goal

Before choosing a data model, tool, or data-entry mechanism, catalog everything that changes per cohort across the clinics (DAIDD, MMED, and future clinics), how often it changes, where it currently lives, and who edits it. This is the foundation the data-entry (#TBD) and substrate (#TBD) decisions depend on.

Motivated directly by the planning note: "More exploration on 'What changes over time?' and then, given that, the most satisfactory solution to user entry of data."

Known starting set (from repo recon)

• Schedule — the worst. On MMED it's code: schedule/<year>/index.md is a wall of {%- assign … -%} Liquid + inline HTML, edited live during the clinic. A broken tag silently fails the build.
• Per-cohort facts — hardcoded in _config.yml (e.g. MMED: year: 2026, summary: …June 15-26, 2026…Muizenberg…, applink: https://forms.gle/…). Main site is stale at year: 2023.
• Personnel / faculty — currently via perl + TSV (shadow.pl, faculty.tsv) and schedule/<year>/shadow.md.
• Applications — open/closed, deadline, application link.

Deliverable

A catalog (table) of every change-unit: what it is, cadence (per cohort / mid-clinic / rarely), current storage + tooling, who edits, and how breakable it is today. Output feeds the data-entry and substrate spikes.

[WestonVoglesonger]

Part of #58 (epic). Related spikes: #53 #54 #55 #56 #57. The #TBD cross-refs in the body resolve to these — to be tidied during refinement.

[WestonVoglesonger]

What changes (full git history: main 1154 / MMED 1193 / DAIDD 578 commits). The schedule dominates and is the real problem; everything else is rare or low-risk.

Changes	How often	Lives in	Breaks the build?
Schedule	live, many×/day during the clinic	schedule/index.md — a Liquid+HTML wall (MMED: 344 commits, ~29% of all history)	Yes — one bad tag downs the site mid-clinic
Personnel / roster	per-cohort + live tweaks	_team/*.md, main _data/team/*.yml, retired faculty.tsv	Sometimes (YAML typos)
Per-cohort facts (year, dates, applink)	once a year	_config.yml	Rare edit, but high blast radius via {{ site.* }}
Landing / apply / content / projects	per-cohort	Markdown	No — stale links / 404s, not build failures

Key finding: the team already built a structured-data schedule (shadow.md + faculty.tsv + perl + Make) and abandoned it — the local toolchain was too fragile to run live (they committed test renders to the deployed branch because they couldn't build offline). That's the argument for the new model: edit flat data files directly (IDE / web editor), validate in CI, no local toolchain — the exact thing that killed the last attempt is gone. The fixed renderer isn't edited live, so a bad edit fails validation, not the build.

Two model constraints: cohorts aren't contiguous (no MMED 2020, no DAIDD 2024 — needs a cohort key that tolerates gaps); the schedule links to slides/Drive that live outside git, so we capture the link, not the target.

Start with the schedule → designing the entry mechanism in #54.