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

The questions#

The two remaining #oq/now items on the human-facing artifact cluster:

1. HTML as the New Markdown — HTML is heavier to diff and version than markdown; what happens to plan history and review when artifacts are single-file websites?
2. Disposable Micro-Apps — could micro-apps be templated/reused rather than regenerated, and at what point does that defeat the "disposable" framing and turn into durable tooling?

Answer 1: The artifact is a compiled view — version the content, regenerate the presentation#

The diff/version worry treats the HTML file as the record. The corpus's own patterns say it isn't one: an HTML artifact conflates a content layer (decisions, rules, plan data) with a presentation layer (the rendering that buys human legibility), and only the content layer needs history. Markdown never forced the distinction because its presentation was trivial; HTML does, and every working practice in the corpus already separates the two:

• Copy-back-to-markdown is the pattern stated as such: the micro-app is "a transient editing surface over durable text… the source of truth round-trips through markdown, while the rich UI exists only for the duration of the edit" — named explicitly as the patch for "HTML's worst weakness (diffing/versioning)" (Disposable Micro-Apps).
• Extract-don't-author: design_system.html is extracted from the repos — the code is the versioned truth, the artifact is re-derivable on demand, and that derivation is what makes it "harder to falsify" (Living Design System). Its version history is the code's version history.
• The compiled-store precedent: this vault's own architecture regenerates derived views (index tables, MOC lists) from source-of-truth frontmatter and forbids hand-editing the generated output (LLM-as-Compiler Knowledge Base). An HTML plan is the same object one level up: compiled output. Nobody diffs compiled output; they diff the source.

So "what happens to plan history" has a direct answer: it lives in the content layer or it evaporates by design. Decisions that must persist round-trip into versionable form (markdown blocks, config, repo files — the copy-back loop); the presentation is regenerated per need at abundance prices (Compute Allocator). And review reattaches to decisions rather than diffs: Thariq's own July technique — order the plan by likelihood of change, "lead with the decisions I'm most likely to tweak… bury the mechanical refactoring at the bottom" — is review restructured for a medium where the reviewable delta is the decision list, not a line diff (HTML as the New Markdown, Unknowns as the Agentic Bottleneck).

What is genuinely lost: blame/history of the presentation itself, and cheap text-diff review of artifact evolution. The loss is acceptable for exactly the reason the medium works — presentation is regenerable, so its history is worthless; the alignment the plan produced is recorded in the decisions extracted from it. The moment a presentation choice becomes load-bearing (a layout stakeholders depend on), it is no longer disposable presentation — it has crossed into Answer 2's durable class and earns real versioning. Residual: the corpus documents one expert practitioner; no source shows multi-author, team-scale HTML-plan review (tracked by that page's remaining #oq/source).

Answer 2: The correct reuse unit is the generator, not the artifact#

The templating question dissolves once the reuse unit is named precisely. The corpus holds the two endpoints — per-task regeneration whose value is fit ("design the ideal interface for this problem" — Disposable Micro-Apps) and the keep-it artifact whose value is consistency ("generated once, reused as context indefinitely" — Living Design System) — and the mechanism that connects them is already measured in the wild:

When a micro-app pattern recurs, what gets templated is the generator prompt, not the HTML. That is precisely what a skill is — "the authoring format" for a reusable workflow (Loop Engineering) — and skills are the systematization primitive whose adoption is measured at 5.4%→26.6% of weekly-active Codex users, near-universal internally (Agentic Work Systematization). A "rule-editor skill" regenerates a fresh, fitted micro-app for each new rule set: the app stays disposable (per-task fit preserved), the skill is the durable asset (consistency gained). Templating the artifact itself would sacrifice the fit that justified the micro-app; templating the generator sacrifices nothing. So the disposable framing is not defeated by reuse — it is stratified: disposable artifact, durable generator.

An artifact itself should graduate to durable only under three conditions, and the corpus's one durable exemplar exhibits all three (Living Design System):

1. Recurrence — the same surface is needed across tasks, not once (the design system is handed to Claude "whenever you start new work").
2. Sync pressure — it must track an evolving source (extracted from the codebase; its open questions are precisely re-extraction cadence and maintenance cost).
3. Audience beyond the author — non-technical stakeholders self-serve from it (Claire Vo's component page).

Graduation is not free. A durable artifact inherits the obligations disposables never pay: maintenance/sync cost (living-design-system's own "at what project size does maintaining the artifact cost more than the consistency it buys"), skill-rot risk as conventions drift (Agentic Work Systematization's debt-surface question), and a permanent seat under the artifact-sprawl bloat ceiling — the axis the human-facing harness's bloat relocated onto (Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling?). This is also the survivor-taxonomy line applied to human-facing artifacts: durable ones join the harness classes that must be deliberately maintained; disposable ones are free precisely because nothing persists.

The failure mode is the un-chosen middle: ad-hoc micro-apps kept around without graduation — unmaintained, out of sync, accumulating. That is tool sprawl plus rot, paying durable's maintenance debt while keeping neither disposable's fit nor durable's consistency — the workflow-fragmentation worry on Disposable Micro-Apps realized. The discipline is binary by design: regenerate it, or maintain it; never merely keep it.

One consolidated takeaway#

Both questions are the same lifecycle decision viewed from different ends. Treat every HTML artifact as compiled output: its content versions in the durable layer (markdown, config, repo), its presentation regenerates on demand, and review binds to decisions, not diffs. Reuse concentrates in the generator (skill), not the generated (app); an artifact earns durability only through recurrence, sync pressure, and audience — and with durability it earns maintenance. Everything else should be thrown away on purpose, because the only bad state in this economy is the artifact nobody regenerates and nobody maintains.