ADR-017: Status exposed as a CSS class, not a data attribute

An item block renders through the standard Asciidoctor HTML5 converter, which emits only id, class, and style on the block element. Every other block attribute is discarded: [#REQ-001, item, role=requirement, data-status=draft] renders <div id="REQ-001" class="openblock requirement">, and neither an inline anchor carrying the attribute nor a tree processor setting it on the node changes that. Projects therefore had no supported way to decorate an item from its own metadata — adding a status badge or state icon meant copying the value into the block’s authored content, or post-processing the generated HTML outside the extension.

Two project constraints bound the solution. CON-003 requires that all generated content use standard AsciiDoc constructs rather than raw HTML, so that every backend — including the PDF and DOCX pipelines — keeps working. The PDF build is a shipped deliverable: the Pages workflow generates requirements.pdf, architecture.pdf, and test-plan.pdf alongside the HTML site on every push.

Chosen option: the extension emits tracer-status-<slug> on the item block for every item that declares a status. role= is already a CSS class in the rendered output, so no converter work is involved and the class flows through every backend that reads roles. The class is inert — the extension renders no icon, badge, text, or color — so the site stylesheet is both the decoration and the switch.

The <slug> is the status value lowercased with each run of non-alphanumeric characters collapsed to a single -. The tracer-status- prefix distinguishes the class from the matrix’s status-done/status-partial/status-missing coverage classes, which describe coverage rather than item status, and doubles as a guard against digit-leading values (status="2.1" → tracer-status-2-1). An absent, empty, or punctuation-only status emits no class.

Emission is unconditional and has no configuration option. An unstyled class renders nothing, so always-emit costs no visual change, while a configuration switch would require document-attribute plumbing into the substitution pass and a partial-handling rule. Per-page control already exists: the UI layout puts page.attributes.role on the <body> element, so a page header :page-role: show-status-glyphs scopes stylesheet rules to that page.

In the same change, item headers accept any role-class prefix rather than only .tracer, so an emitted or hand-written class in the header does not break item recognition. This generalization also repaired superseded-item stripping, which matched only the .tracer header form and therefore left a superseded item written with a status class visible in the build.

Default decoration lives in the antora-ui-conemso theme, not in the extension and not in generated CSS. The theme is what these sites render with and already carries a Tracer-aware rule, so it draws a glyph after the title for five common statuses: draft, review, approved, deprecated, and superseded. Any other value renders no glyph until the project adds a rule, which keeps the theme from defining a status vocabulary the extension deliberately leaves free-form. The extension’s playbook pins move to the theme release that carries the glyphs.