Goal
Carl: "have more clinics and have those clinics be semi-autonomous — this is something we should design to," and "decentralized." Make this a first-class criterion — but this spike must produce a decision + a prototype, not just a scoring rubric.
What Carl said (June 15–17), which constrains the design
- "Separate the sharing of data from the sharing of templates/style."
- "Do not use the theme to share the data."
- Sub-sites should reuse the main repo's layouts "without constantly synchronising versions"; "wants out of submodules ('hacky')"; not anti-server, just no database administration.
- His proposed sync: "github actions triggered between sites" / a "scheduled hash-check … if different, synchronise."
Finding that drives this spike
The existing jekyll-theme-ici3d gem bundles _data into the gem — templates + personnel on one channel, the exact submodule coupling we're removing, and a direct violation of "don't use the theme to share data." It has drifted (57 vs 69 person records, ~3 yrs stale) and a branch pins ~> 0.1.3 (never published). The "two-channel split" is contradicted by the only artifact that exists.
Define 'semi-autonomous'
- Each clinic owns its content, edits, and merge/deploy cadence.
- Minimal central coupling — no submodule, no manual version-sync chore.
- Shared theme/style and shared personnel data consumed safely (see below).
- Standing up a new clinic is cheap and templated.
The pin-vs-float trilemma (resolve it; don't wave past)
"No version pinning + shared renderer + can't break" is not simultaneously satisfiable: an unpinned shared theme + scheduled hash-rebuild lets an upstream push break/alter N clinics that edited nothing, mid-clinic. Decide:
- Two real channels: templates via a pinned, data-stripped
remote_theme/gem; personnel via a separate published data artifact with a named system-of-record (reconcile the 57 → the live 69).
- Safe, not just decoupled: pin by default + a low-friction bump (Dependabot-style PR that runs validate+build) instead of a blind scheduled hash-rebuild; add render-tests + a canary clinic; name an owner for the shared machinery.
- Prototype before Phase 2: two toy clinic repos consuming one shared theme + one shared data artifact; prove an upstream change can't silently break either.
Topology is upstream of all this (gate on #58)
Most of this machinery only exists under split. Under monorepo the pub/sub, the scheduled rebuild, and the trilemma disappear. Carl leans decentralized/split, so plan for split-done-right — but record the monorepo alternative and get his explicit call first.
Cross-project signal: on imuGAP/FlepiMop Carl prefers upstreaming into a package, tolerates copy-paste over submodules, and likes remote-URL/skeleton sharing — arguing for a low-tech pinned remote_theme + auto-bump PR over bespoke sync machinery a thin team can't maintain (the current gem already rotted once).
Deliverable
The topology decision (with #58), the two-channel sharing design, and the two-toy-clinic prototype proving the chosen mechanism is safe at N clinics. Part of #58.
Goal
Carl: "have more clinics and have those clinics be semi-autonomous — this is something we should design to," and "decentralized." Make this a first-class criterion — but this spike must produce a decision + a prototype, not just a scoring rubric.
What Carl said (June 15–17), which constrains the design
Finding that drives this spike
The existing
jekyll-theme-ici3dgem bundles_datainto the gem — templates + personnel on one channel, the exact submodule coupling we're removing, and a direct violation of "don't use the theme to share data." It has drifted (57 vs 69 person records, ~3 yrs stale) and a branch pins~> 0.1.3(never published). The "two-channel split" is contradicted by the only artifact that exists.Define 'semi-autonomous'
The pin-vs-float trilemma (resolve it; don't wave past)
"No version pinning + shared renderer + can't break" is not simultaneously satisfiable: an unpinned shared theme + scheduled hash-rebuild lets an upstream push break/alter N clinics that edited nothing, mid-clinic. Decide:
remote_theme/gem; personnel via a separate published data artifact with a named system-of-record (reconcile the 57 → the live 69).Topology is upstream of all this (gate on #58)
Most of this machinery only exists under split. Under monorepo the pub/sub, the scheduled rebuild, and the trilemma disappear. Carl leans decentralized/split, so plan for split-done-right — but record the monorepo alternative and get his explicit call first.
Deliverable
The topology decision (with #58), the two-channel sharing design, and the two-toy-clinic prototype proving the chosen mechanism is safe at N clinics. Part of #58.