Two-register split for HTML deliverables — board vs console

TFD-018 — Two-register split for HTML deliverables

Decision

Talent Factory HTML deliverables ship in one of two named registers, codified at the design-system level and selected per artefact:

Register Class on <body> Aesthetic When to use
register-board register-board Fraunces serif on warm cream #F7F4EC, oversized italic numerals, § NN section markers, real inline SVG diagrams, print-ready Deposited dossiers for CE/CA/VP — A100/A270/A290, decision memos, sommaires de mandat. Anything that gets printed, signed, or tabled at a board meeting.
register-console register-console Segoe UI sans on cool #F9FAFB, stat-cards, fast-scan tables, sidebar nav Operational consoles, recurring vigies, dashboards with drill-down. Anything consumed live on screen, not deposited.

Both registers share the STM brand palette (navy #002B5C, green #009A44, yellow #FFE400, blue #009EE0, teal #007489). The split is typography + layout + content density, not color.

Default

When in doubt for a DAE deposit, choose register-board. Boards remember the document on paper, not the dashboard on screen.

Why

Three independent observations converged:

  1. Uma's audit of POC v1 vs v2 (REQ-CONS-008/output/uma-audit.md) tested both styles on the same Transesco content. v2 editorial wins for board/exec register (43/50 vs 37/50); v1 console wins for ops dashboard register (38/50 vs 22/50). Forcing one style sacrifices half the use case.

  2. The dashboard canon (OneDrive-STM/agent-ea/DAE-0007.../sommaire-executif-transgesco.html) is genuinely better for live consoles than v2 editorial — sidebar nav + CMMI bars + priority items + filters. Killing it to force editorial uniformity would regress operational deliverables.

  3. Print-fitness diverges from interactivity. Editorial register is built for paper (break-inside, color-adjust:exact, no JS-driven interactions). Console register is built for screen (sidebar filters, drill-down, live filters). One stylesheet cannot serve both well.

Implementation

Already shipped as of 2026-05-14:

  • Canonical templates at production-lines/digital-talent/talents/agent-ea-v2/.claude/commands/templates/:
    • template-dae-index.html, template-page1-solution.html, template-page2-feuille-de-route.html, template-page3-analyse-couts.html → register-board (4 files)
    • template-dae-index-LITE.html, template-page1-solution-LITE.html, template-page2-feuille-de-route-LITE.html, template-page3-analyse-couts-LITE.html → register-console (4 files)
  • SVG component library at templates/svg-components/ — 8 reusable partials with <!-- DATA CONTRACT --> headers
  • README at templates/README.md documents the register choice rule
  • Catalog browser is register-neutral; works with both

Register selection rule

The talent that emits the deliverable picks the register at generation time:

Deliverable type Default register Override
HLSD (A100/A270/A290) for client deposit register-board —
Decision memos, sommaire de mandat register-board —
Recurring vigie (weekly/monthly) register-console —
Ops dashboard, live status register-console —
Internal R&D evaluations, JCT-internal register-console —
Intranet pages (factory) register-console —

Override via /ea-livrable-assembler --register {board|console} (assembler skill v3.1+).

Consequences

  • Edward (agent-ea v2) must know the register before generating. Default = register-board. Override via skill arg or CLAUDE-{slug}.md frontmatter register: field.
  • Wesley maintains both template families. Changes to one register should be evaluated for symmetric impact on the other.
  • Uma owns the design system at quality-assurance/ux-designer-uma/design-systems/. Required entries (per audit §7):
    • deliverable-registers.md — this decision + the per-register skeletons
    • svg-component-catalog.md — the 8 partials' visual canon
    • typography-and-tokens.md — the two type stacks
    • accessibility-baseline.md — WCAG AA checklist gating every deposit
    • print-stylesheet.md — canonical @media print block
  • Quinn plumbs regression tests per register (pixel-diff at 1180/900/600px, axe-core contrast, SVG validity, print render).
  • Future talents (Maya, etc.) producing HTML deliverables MUST pick a register at start. No third register without a follow-up TFD.

Out of scope

  • A third register (e.g., register-mobile) — open a new TFD if needed.
  • Changing the STM brand palette — separate decision domain.
  • Talent-specific template families (e.g., a Maya-only template stack) — talents share these two registers unless they justify divergence in their own role.md.

References

  • REQ-CONS-008 — the request that surfaced the split (agent-ea v2 self-publishing)
  • uma-audit.md (REQ-CONS-008/output/) — empirical evidence
  • TFD-017 — JCT portail architecture (the deployment substrate)
  • project_docs-design-system (memory) — prior palette decision (Anthropic warm cream + Trustworthy Blue) now scoped to internal factory docs only