Loomworks — Deferred Work Candidate — REQ Specification HTML Rendering — v0.2

Version. 0.2 Date. 2026-05-18 Prior version. v0.1 (filed earlier same day) — preserved alongside; framing corrected, not overwritten. Status. Candidate addition to loomworks-queued-directions-and-deferred-work-v0_11.md (or successor). External validation strengthens the candidacy but does not change the decision to defer. Author. Claude.ai (drafting) on Operator direction.

Plain-language summary

An exploratory rendering of a Forge-style REQ specification as a styled HTML document was produced 2026-05-18, filed in v0.1 as deferred work. Later the same day the Operator surfaced a podcast transcript (Thariq Shihipar, Claude Code engineer at Anthropic, on the "How I AI" podcast) advancing a substantively stronger version of the same idea: HTML is replacing markdown as the primary authoring format for plans and specifications in agent-driven workflows, not just as a rendered view. The transcript provides external validation that the question matters and reframes how HTML rendering would actually be used. The reframe does not change the decision to defer; it strengthens it. v0.2 absorbs the reframe, preserves the v0.1 framing as the appropriate position under prior assumptions, and adds new affordances and methodological candidates surfaced by the external material.

What v0.1 said

v0.1 framed the question as: markdown is the authoring format because it is easier to write by hand; HTML is a rendered view generated from the parsed spec, serving reviewers, clients, and non-engineer readers. Under this framing, the natural tooling shape would be a small parser-plus-renderer that emits HTML from a markdown REQ source.

This framing was appropriate to its prior context — specifically, a context where Forge was alive, the markdown-as-parser-input constraint bound the authoring format, and the operator was hand-writing markdown spec content. None of those conditions hold for future Loomworks-native work. Forge is closed history; the parser constraint does not carry forward; the operator's pattern has shifted toward directing Claude.ai to draft spec content rather than hand-authoring it.

What the Thariq transcript reframes

The transcript argues that HTML is becoming the primary authoring format for specs and plans in agent-driven workflows, not because HTML is easier to write — no one is writing either format by hand — but because:

• Engagement is the leverage point. As agents run longer (Thariq cites 8-hour runs costing ~$500 of compute), the operator's role shifts toward "compute allocator." The decision of what to spend compute on happens at the spec/plan phase. The format that holds operator attention through that decision matters disproportionately. Long markdown plans get scrolled past; richer HTML plans get read.
• Mockups and excerpts inline. HTML lets plans embed mockups, code excerpts, helper script snippets, and visual hierarchy alongside requirement content. Markdown forces these into separate files or ASCII approximations.
• Custom micro-UIs for editing. The operator doesn't edit the HTML plan directly. For sections needing detailed work, the operator asks Claude to build a custom throwaway UI specifically for editing that section — "micro software on top of micro software" — and pastes results back. The HTML plan format enables this affordance; markdown does not.
• Collaboration distribution. HTML is uploadable and shareable as a link in ways markdown is not. Recipients are an order of magnitude more likely to actually read it.
• Source of truth for verification. HTML with mockups becomes the artifact a verification agent compares actual output against — "what did I intend to do" versus "what came out."

The premise the v0.1 framing rested on — markdown is easier to write by hand — becomes irrelevant under this reframe. Both formats are agent-generated. The format that wins is the one that supports operator engagement, reviewer access, and verification reference, not the one that minimizes typing friction.

Prior framing preserved

The v0.1 framing — HTML as rendered view of markdown source — remains correct as a fallback when:

• An existing parser pipeline already consumes markdown and cannot be replaced.
• The audience for the HTML is purely downstream of an authoritative markdown source under separate version control.
• The spec content is short enough that mockups, excerpts, and editing-UI affordances add no value over a simple table render.

None of these conditions holds for the general Loomworks-native case going forward.

What v0.2 adds to the candidate

When this material is taken up in a future shaping/render scoping pass, the scope to consider includes:

• HTML as the authoring format for Loomworks-generated REQ-style specifications, not as a rendered view. Claude.ai or the engagement's render specialist produces HTML; the operator reviews and directs through Claude.ai or via micro-UIs Claude.ai builds on demand.
• Inline mockups and code excerpts as standard sections of the spec, not external assets. The HTML rendering example produced 2026-05-18 (req-spec-html-rendering-example-v0_1.html) does not yet include these and would be revised under the reframe.
• Custom micro-UI affordance. The engagement should be able to spawn purpose-built editing surfaces for specific spec sections on operator demand. This is not a standard Render Room capability today; it would require new affordances.
• Verification source of truth. The HTML spec serves as the reference artifact a verification agent compares actual implementation output against. This connects to Loomworks's existing validation discipline and may bear on the engagement's relationship to the Companion's verification function.
• Compute-allocator framing. The operator's engagement with the spec is the leverage point at which compute-spend decisions are made. The format's role in supporting that engagement is methodological, not cosmetic. This frame is worth carrying forward.

What did not change

The decision to defer.

The external validation strengthens rather than weakens the case for deferring. The question matters more than v0.1 acknowledged; the answer is also more elaborate than v0.1 anticipated. Picking it up at this point would mean committing to a meaningful shaping/render arc without the surrounding application-development-engagement scoping that should precede it. The right trigger remains a future consolidation pass on shaping and render for application development engagements as a class.

The reference artifact (req-spec-html-rendering-example-v0_1.html) also does not change. It is a fine specimen of the v0.1 rendered-view framing. A v0.2 of that artifact under the reframe would include inline mockups, code excerpts, helper scripts, and the custom-micro-UI affordance — but producing that would cross from filing-a-note to doing-the-build, and the operator has indicated the work is not warranted now.

Methodological candidates surfaced (single-instance, not promoted)

Three candidates surfaced from the Thariq transcript that connect to existing methodology discipline. None has fired across multiple internal instances yet, so each is filed as single-instance and not promoted:

• Compute-allocator framing. As agent builds become long-running, the operator's role at the spec/plan phase is allocating substantial compute commitment. Connects to Operator-Authority and substrate-friction-discipline.
• Throwaway-software-as-cognitive-interface. Custom UIs built on demand to edit specific sections of a plan, used briefly, discarded. The pattern generalizes beyond spec editing.
• Engagement-with-artifact as quality leverage. The operator's actual engagement with the spec catches more issues than spec-correctness review does. Markdown plans that aren't read get approved; HTML plans that are read get caught. Connects to plain-terms discipline (methodology nouns must remain first-class) and to the Operator-questioning-as-discipline-check candidate already on the v0.21 list.

If any of these fires again in a different internal context, it becomes a candidate for v0.21 consolidation. Today they live in this note as single-instance external observations.

Trigger for revisiting (unchanged)

This note should surface when:

• The shaping and render boundaries are next consolidated, particularly for application-development engagements as a class.
• A specific engagement requires producing a REQ-style specification as a client-visible artifact rather than an internal one.
• The question of "what kinds of artifacts can Loomworks engagements render?" comes up in scoping.

Source

Podcast: "How I AI" with Claire Vo, episode "Why this Claude Code engineer uses HTML files as AI specs" — Thariq Shihipar (Anthropic, Claude Code). Transcript surfaced 2026-05-18.

The transcript is an external source, treated as stimulus rather than authority. The intellectual claims are taken at face value where they map onto Loomworks's existing discipline; the marketing register of the podcast format is filtered out.

Cross-references

• loomworks-deferred-work-req-spec-html-rendering-v0_1.md — prior version, preserved.
• req-spec-html-rendering-example-v0_1.html — worked example produced 2026-05-18.
• loomworks-queued-directions-and-deferred-work-v0_11.md — register this candidate should fold into on next version.
• loomworks-standing-note-shaping-render-boundary-v0_1.md — relevant standing note context.
• phase-22-cr-rendering-room-ui-v0_1.md, phase-27-cr-rendering-room-redesign-v0_1.md, phase-35-cr-render-content-kinds-v0_2.md, phase-36-cr-incremental-rerender-and-naming-v0_1.md — rendering-room build history.
• loomworks-claude-code-as-render-specialist-investigation-v0_1.md — adjacent investigation; the Thariq material may bear on that direction.
• Conversation history (this chat, 2026-05-18) — full trajectory.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Deferred Work Candidate — REQ Specification HTML Rendering — v0.2 — 2026-05-18