The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable

Two-question synthesis on the lifecycle of human-facing HTML artifacts. (1) The diff/version problem dissolves once the artifact is recognized as a compiled *view*, not a record: version the content layer (markdown/config/repo — the copy-back round-trip and the extract-from-code pattern already do this), regenerate the presentation on demand, and let review reattach to decisions rather than diffs (the plan-ordered-by-likelihood-of-change technique puts the reviewable delta at the top). What's genuinely lost — blame history of the presentation itself — is acceptable precisely because presentation is regenerable at abundance prices; the moment a presentation choice is load-bearing, it graduates to durable tooling. (2) The templating question resolves by naming the correct reuse unit: not the artifact but the *generator* — a recurring micro-app becomes a skill that regenerates a fresh, fitted app each time (keeping disposable's per-task fit while gaining reuse's consistency), which is exactly the systematization move measured in the wild (skills 5.4%→26.6% of weekly-active users). An artifact itself graduates from disposable to durable only under recurrence + sync-pressure + audience (the design_system.html profile), at which point it stops being free: it inherits maintenance cost, sync cadence, and a seat under the artifact-sprawl bloat ceiling. The failure mode is the un-chosen middle — ad-hoc apps kept around unmaintained, which is sprawl plus rot with neither fit nor consistency