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

Version. 0.1 Date. 2026-05-18 Status. Candidate addition to loomworks-queued-directions-and-deferred-work-v0_11.md (or successor). Single-observation note. No build action implied at present. 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. The exercise surfaced design choices and structural affordances that HTML enables over markdown — semantic IDs per REQ, live dependency cross-references, card layouts replacing tables, letterpress-styled typography, NFR threshold emphasis. The work does not warrant further development at present. It is filed here as candidate review material for a future scoping pass on shaping and render for application development engagements.

Why it's deferred rather than picked up

The REQ-spec-as-HTML question is a genuine design question with real choices to make, but it is downstream of decisions that have not yet been taken. Specifically, whether the HTML format would be:

• An alternative authoring format — competing with markdown. Probably wrong; markdown is easier to write and edit by hand, and the parser already exists.
• A rendered view generated from the parsed spec — the natural shape. The author writes markdown; tooling produces HTML for reviewers, clients, and non-engineer readers. The two formats serve different audiences.
• A Loomworks render output kind — when an application-development engagement produces a REQ specification, the engagement's Render Room emits the HTML alongside or instead of the markdown form.

The third framing is the one that matters for Loomworks proper. It is also the one that depends on decisions not yet made about how shaping and render work for application-development engagements as a class.

What the exploratory artifact demonstrated

The 2026-05-18 example (req-spec-html-rendering-example-v0_1.html) is a hand-written single-file HTML rendering of a small fictional Loomworks spec — eight REQs across two cycles, with full scoping sections. It demonstrated:

• REQ as card, not table row. Variable-length descriptions and acceptance criteria render more cleanly as cards than as table rows. Visual hierarchy matches reading order.
• Stable element IDs per REQ. Each REQ is addressable via id="REQ-NNN". Deep linking, dependency cross-references, and tooling addressability all become free consequences.
• Live dependency cross-references. Dependencies become clickable links with CSS :target highlighting on the destination.
• Typography and palette as semantic carrier. Letterpress styling (cartridge, vellum, brass, iron-oxide, press-ink) signals "this is a contract artifact, not a database export." Plex Serif + Inter typography split between content and labels.
• NFR threshold emphasis. Measurable values within NFRs become visually privileged so the testable part of the requirement lands first.
• Phase boundaries as structural breaks. Heavy press-ink rule with iron-oxide capstone marks phase transitions as more than heading-level changes.

Affordances deliberately not included in the example

These were considered and set aside as not warranting inclusion in a "what would it look like" demonstration:

• Live dependency graph at the document head — valuable, but doubles visual weight; better as a separate companion artifact.
• Filter-by-phase or filter-by-cycle controls — useful in long specs but adds JS machinery for what is mostly a reading artifact; the browser's built-in find handles the same need.
• Induction-status indicators per REQ (pending, ready, blocked, superseded) — natural place to surface induction state when the HTML is generated from a live spec rather than hand-written. Not included because the example is static.
• Inline comments and review markers — real-time-collaboration territory; separate concern from the document format itself.

Trigger for revisiting

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.

Until one of those triggers fires, this is a parked exploration with a single concrete reference artifact.

Methodological residue

The exercise was a small instance of a more general pattern that may be worth naming separately at some point — exploratory rendering as scoping fuel. Producing a concrete worked example of how a thing could look, even when no commitment to building it is in scope, produces design observations that pure discussion does not. The cost is low; the residue is durable. If the pattern fires again across other shaping/render questions, it becomes a candidate methodology fragment.

Cross-references

• req-spec-html-rendering-example-v0_1.html — the 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; the application-development-engagement render question is downstream of this work.
• Conversation history (this chat, 2026-05-18) — full trajectory from the question through the worked example to the deferred-work decision.

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