Decision needed: demo-301's site branch — which size mitigations (S1–S6)?

[obotclaw[bot]]

This discussion was drafted by Claude Code using Fable 5 (unreviewed), per @jwildfire's 2026-08-14 direction to surface each open decision in Q&A.

The question. #143 requires the size call before demo-301 becomes the keynote's fork template. Measured 2026-08-14: the 302.58 MiB checkout figure is exact, but 34% of it is a byte-identical duplicate tree, a fresh clone transfers 90.91 MiB, and the branch is not currently growing (the scheduled pipeline has been failing). Full measurements and per-option costs: the decision artifact.

The options. S1 drop the duplicate root output/ · S2 shrink input/ on main · S3 snapshot retention · S4 stop committing rendered charts · S5 orphan-branch publishing · S6 accept as is for the demo.

Recommendation: S1 + S2 now, S3 with the Actions fix — not S4, not S5.

Please record your call in this thread — which of S1–S6, and whether S2 waits on the Raw_DATACHG/Raw_DATAENT fidelity audit the artifact flags as its precondition.

[obotclaw[bot]]

Decided 2026-08-15 — all six calls adopted as recommended. @jwildfire answered in the local Operations Dashboard rather than here, so this thread is not the record; the artifact is.

His words are quoted verbatim in the new Decisions section at the top of what the fork actually costs, and the call now appears in the Decisions log.

What was settled: stop publishing the current snapshot twice, shrink the synthetic data extracts that make up most of what a fork downloads, and put a retention limit on published snapshots so the branch stops growing without bound. Not adopted: moving rendered charts out of the published tree, republishing from a single-commit orphan branch, or accepting the current size and spending the effort elsewhere.

Follow-through against #143, milestone 2026q3, nothing implemented yet: #189 drops the duplicate root copy, #190 shrinks what a fork downloads, #191 bounds the branch's growth.

The second half of his answer — that the real issue is moving to a more robust database instead of leaning on GitHub — is a much larger question than branch size, and is recorded as a prep topic for the goal #79 elicitation interview: #79 (comment)

---

This comment was drafted by Claude Code using Opus 5 and reviewed by @jwildfire