CADR and Genera interface style guide

CADR/LM-3 System 303

Runtime observation, Experimental System 303.0, 2026-07-18. The image supports the comparison of sparse popup geometry, column headings, outlined current item, surrounding Listener, bottom mode line, and pointer-documentation/status region. MIT and other identified rightsholders retain any interest in the screen; this scholarly use is reviewed under the repository's case-specific fair-use policy, and no affiliation or endorsement is implied.

The visible hierarchy is created almost entirely by position, rules, whitespace, font changes, and the current-item outline. There is no desktop wallpaper, toolbar, icon dock, rounded card, or shaded widget chrome. The menu occupies only the area its items need and leaves the underlying application legible.

Symbolics Genera 8.5

Runtime observation, Genera 8.5, 2026-07-18. The image supports comparison of the menu title, column organization, typography, current-item box, border and shadow, framed screen, scrollbar, bottom label, and pointer-documentation/status relationship. Symbolics retains any copyright interest; this limited scholarly use is reviewed under the repository's case-specific fair-use policy, and no affiliation or endorsement is implied.

Genera remains visually economical, but the hierarchy is stronger. The popup has a title, differentiated headings, a heavier lower-right edge, and more proportional letterforms. The enclosing Listener has a decorated frame, scrollbar, and label. These are not grounds for adding modern bevels or arbitrary ornament: the decoration still communicates window extent, pane role, exposure, selection, or operation.

Genera Dynamic Windows form language

Runtime observation, Genera 8.5, 2026-07-18. This capture is used only to analyze the typographic and spatial language of an Accepting Values form. Its volatile garbage-collector values are not release defaults or configuration advice. Symbolics retains any copyright interest; this limited scholarly use is reviewed under the repository's case-specific fair-use policy.

This form is especially important evidence against reducing Genera to a terminal. It is spatial, mouse-sensitive, typed, and redisplay-aware, yet most controls remain text. Bold and italic raster styles, indentation, blank rows, semantic grouping, inline alternatives, and bottom-line documentation do the work that contemporary toolkits often assign to filled cards, colored badges, switches, and tooltips.

Treat every pixel as deliberate

Historical raster output has hard edges. A rule is one device pixel because one pixel is an actual drawing unit, not a hairline that a compositor may place between device pixels.

For an exact-pixel presentation:

• lay out on an integer coordinate grid;
• scale the final surface only by an integer factor;
• disable interpolation for bitmap layers;
• avoid fractional transforms, fractional line heights, and half-pixel borders;
• use square joins and caps unless a source-grounded component says otherwise; and
• repaint transient highlights reversibly or from retained state rather than accumulating alpha overlays.

Apply the same rule to historical screenshots and other one-bit raster evidence. Render them at their intrinsic pixel dimensions or at an explicitly chosen integer multiple. Do not fit them proportionally to a narrower content column: that makes source pixels unequal and introduces artifacts in bitmap text and stipples. A narrow viewport should scroll the unscaled image.

For an accessible responsive website, use the same grid inside components but let the page reflow. Historical screen dimensions are reference compositions, not a reason to force a 768-pixel-wide viewport on a phone.

Use monochrome as the foundation

The ordinary observed profiles are white surfaces with black ink. Reverse video is an operational state, especially in status areas, selections, cursors, and some labels—not a mandate to make the entire application black.

Recommended base tokens:

:root {
  --lm-paper: #fff;
  --lm-ink: #000;
  --lm-rule: #000;
  --lm-focus: #000;
  --lm-rule-width: 1px;
  --lm-radius: 0;
}

Do not add green phosphor, amber bloom, chromatic aberration, scanlines, vignetting, or static noise unless the project is explicitly simulating a particular physical monitor. None of those effects defines the software interface documented here.

Prefer roles over arbitrary ornament

Every visible distinction should answer a question:

• What window or pane owns this content?
• What is selected?
• What can the pointer act on?
• What mode or buffer is active?
• What will each mouse button do here?
• Is this value current, defaulted, invalid, or merely explanatory?
• Is this region temporary, scrollable, or awaiting input?

When an extra border, color, shadow, icon, or badge answers none of those questions, remove it.

Keep information dense but structured

Density does not mean eliminating all whitespace. Both systems use blank space to separate logical groups and reserve output regions. The characteristic economy comes from small raster text, shallow controls, compact labels, and the absence of decorative padding.

Use:

• one text line for an ordinary command or mode row;
• one or two character cells of indentation for hierarchy;
• one blank row between major form groups;
• one-pixel pane separators;
• content-sized transient windows; and
• tables whose columns follow the information rather than a generic card grid.

Make documentation part of the interface

Pointer documentation belongs in a stable bottom region. It changes as the pointer crosses menus, presentations, scroll margins, and controls. This is different from a tooltip that floats over and obscures the content.

One accessible implementation mapping is:

<main class="lm-screen" aria-describedby="pointer-doc">
  <!-- application -->
</main>
<footer class="lm-who-line">
  <div id="pointer-doc" aria-live="polite">Select this buffer.</div>
  <div class="lm-status">USER:  TAY   Package: CL-USER   Run</div>
</footer>

Update the same documentation for keyboard focus. Hover-only documentation does not reproduce the keyboard-and-pointer relationship and is inaccessible.

Typography

The public font artifacts and source establish a role-based bitmap vocabulary:

For a browser, the most faithful implementation uses a font converted from the tracked public CADR font sources under their recorded license. A normal outline monospace fallback can reproduce structure but not exact raster rhythm.

Suggested logical roles:

[data-lm-profile="cadr"] {
  --lm-font-body: "CADR CPTFONT", ui-monospace, monospace;
  --lm-font-menu: "CADR MEDFNT", var(--lm-font-body);
  --lm-font-menu-strong: "CADR MEDFNB", var(--lm-font-menu);
  --lm-body-size: 12px;
  --lm-body-leading: 12px;
  --lm-cell-x: 8px;
  --lm-cell-y: 12px;
}

The quoted family names are project-local CSS aliases, not standardized installed font names. Map them to the files actually supplied by the site.

Window geometry and chrome

The CADR TV window is a sheet with explicit outside and inside geometry. Borders, labels, scroll margins, and other decorations consume margins around the client area. That architecture should remain visible in an implementation.

Use:

• a one-pixel outer rule for ordinary windows;
• optional top or bottom labels measured as part of the window, not floating above it;
• square corners;
• no ambient shadow on an ordinary CADR popup;
• narrow scroll regions in the window margin;
• a mode line or label that spans the application width; and
• a separate who-line region below the main application screen.

Do not reproduce a contemporary title bar with close/minimize/maximize buttons. Window operations live in global or contextual menus and keyboard commands.

Menus

The observed System 303 menu is a temporary, content-sized rectangle:

• three columns with short headings;
• centered or consistently aligned labels;
• no filled cells;
• the current item enclosed by a one-pixel rectangle;
• pointer documentation in the who line;
• no persistent menubar; and
• exact restoration of the underlay when dismissed.

A CADR menu component implementing the observed relationships:

[data-lm-profile="cadr"] .lm-menu {
  position: absolute;
  display: grid;
  grid-auto-flow: column;
  grid-template-rows: auto repeat(var(--rows), 1lh);
  color: var(--lm-ink);
  background: var(--lm-paper);
  border: 1px solid var(--lm-rule);
  border-radius: 0;
  box-shadow: none;
  padding: var(--cadr-menu-padding);
  font: normal var(--lm-body-size)/1 var(--lm-font-menu);
}

[data-lm-profile="cadr"] .lm-menu [aria-current="true"],
[data-lm-profile="cadr"] .lm-menu [role="menuitem"]:focus-visible {
  outline: 1px solid var(--lm-focus);
}

--cadr-menu-padding is deliberately undefined. Measure it from the selected release/application reference instead of treating one convenient inset as a system-wide CADR constant.

The historical menu can be momentary, tracking while a button is held. A website may also support click-to-open for accessibility, but should preserve Escape/Abort, focus movement, current-item documentation, and underlay restoration.

Mode line and who line

The System 303 capture separates three bottom functions:

1. the application label/mode line at the bottom of its window;
2. a mouse-documentation line; and
3. a status line showing user, keyboard/process context, and other state.

Do not compress these into a floating toast. Use stable horizontal bands. Reverse video is appropriate only where it matches the chosen release and band. In the reviewed System 303 capture, both who-line rows use ordinary black-on-white video. In the reviewed Genera 8.5 captures, the pointer-documentation row is white on black and the status row immediately beneath it returns to black on white. Do not apply the Genera documentation row's reverse video to the complete who-line region.

Scrollbars and cursors

CADR scroll controls are window-margin behavior, not generic browser scrollbars. They may expose position and navigation through a thin edge region. Use a narrow track, raster car/marker, and context-sensitive pointer documentation. Avoid rounded thumbs, translucent overlays, disappearing scrollbars, and inertial overscroll.

Do not render the margin as a passive position meter. The inspected TV lineage defines button-sensitive relative and absolute gestures; the inspected Genera Dynamic Windows margin divides the control into start box, middle shaft, car, and end box, with relative jumps, proportional positioning, motion tracking, and optional auto-repeat. A web adaptation should make at least these operations available without a wheel:

• one-line movement from directional end controls;
• relative page movement by selecting the shaft outside the car;
• proportional movement by dragging the car; and
• Arrow, Page Up/Down, Home, and End operation when the shaft has keyboard focus.

This keyboard and primary-button mapping is an accessibility adaptation, not a claim that the historical three-button gesture table used modern scrollbar conventions. Retain the thin hard-edged margin, proportional car geometry, immediate repaint, and pointer documentation while exposing the adaptation clearly.

For the selected Genera Documentation Examiner profile, place the vertical viewer scrollbar in its left margin and the horizontal scrollbar in its bottom margin. The reviewed Listener, Terminal, Converse, and Notifications displays likewise put their vertical scrolling margin on the left of the pane it controls. Do not move the bar to the browser-conventional right edge merely because the implementation uses HTML.

The selected Dynamic Windows source gives a default 14-pixel margin: two pixels of outside whitespace, a 10-pixel elevator strip, and two more pixels of whitespace. The two end targets are empty 10-by-10 one-pixel outlined boxes, not arrow icons. Inside the central strip, the source draws two one-pixel cables at its outer edges with 50%-GRAY; the space between them remains white. The car has a one-pixel outline, a 33%-GRAY interior, and a minimum length of eight pixels along its axis. Use the exact minimal stipple cells with no interpolated scaling:

50%-GRAY cable    33%-GRAY car
.#                #..
#.                .#.
                  ..#

The cells are periodic masks: phase and drawing ALU still matter in a historical raster implementation. For a monochrome web reproduction, repeat the cable pattern along only the two cable lines, keep its cell anchored to device pixels through zoom, and retain the car's one-pixel black outline. Filling the complete shaft with a checkerboard or placing modern triangles in the end boxes changes the observed visual grammar.

Text cursors and blinkers are rectangular raster objects. A block or thin rectangle that follows the current character cell is more authentic than a glowing caret. Blinking should respect reduced-motion preferences.

Grays, stipples, and color

The ordinary monochrome profile uses one-bit repeating masks. The five named CADR patterns are:

50%-GRAY   25%-GRAY   75%-GRAY   33%-GRAY   HES-GRAY
.#         #...       .###       #..        #...
#.         ..#.       ##.#       .#.        ....
           .#..       #.##       ..#        ..#.
           ...#       ###.                  ....

Treat # as a mask bit, not inherently as black. The foreground, destination, and Boolean raster operation determine the visible result.

If using the optional CADR-COLOR-4 profile, expose a sixteen-entry mutable indexed palette. Do not declare a permanent “CADR palette”: source-defined routines replace the color map, and the same pixel index can display a different RGB value later.

CADR component recipe

A compact CADR-style page usually needs:

screen
├─ application window
│  ├─ content/terminal area
│  ├─ optional narrow scroll margin
│  └─ bottom label or mode line
├─ temporary menu or typeout overlay
└─ who-line screen
   ├─ pointer documentation
   └─ user/process/file/status fields

Start with this hierarchy before adding application-specific panels.

Typography and character styles

Genera's native character style is a semantic (family, face, size) triple. It is resolved through a device-specific font map. This supports more visual hierarchy than a single terminal face without becoming a modern CSS property bundle.

Useful screen roles from the selected profile:

Faces include roman, bold, italic, bold-italic, uppercase, bold-extended, condensed, and extra-condensed. Use actual raster variants where available. Synthetic browser weight or oblique transforms blur and distort the designed pixel forms.

Suggested logical CSS roles:

[data-lm-profile="genera"] {
  --lm-font-fixed: "Local Genera CPTFONT", ui-monospace, monospace;
  --lm-font-ui: "Local Genera JESS13", var(--lm-font-fixed);
  --lm-font-sans: "Local Genera HL12", sans-serif;
  --lm-font-serif: "Local Genera TR12", serif;
  --lm-font-display: "Local Genera EUREX21I", var(--lm-font-serif);
  --lm-fixed-size: 12px;
  --lm-ui-size: 13px;
  --lm-cell-x: 8px;
  --lm-cell-y: 12px;
}

These aliases are examples; use the actual family names exported by the selected font package. The public Genera Fonts reproduction provides the reviewed 89-font Genera 8.5 resident profile as Unicode BDF and OTB fonts. It preserves the one-bit glyphs, advances, bearings, baselines, and line metrics rather than substituting a generic pixel font. Its publication notice relies on the U.S. “typeface as typeface” rule and deliberately separates the historical font-shape payload from the BSD-licensed project tooling.

Choose an actual resident size instead of enlarging a smaller bitmap to fill a different historical role. In the selected resident profile, CPTFONT is a 12-pixel cell, JESS13 a 13-pixel font, HL12 a 14-pixel cell, HL14 a 15-pixel cell, and SWISS20 a 20-pixel cell. Thus a 20-pixel sans-serif display heading should use SWISS20, not scale HL12 to 20 CSS pixels. Use the matching bold or italic raster object rather than browser synthesis. This rule preserves resident design sizes; it does not imply that every Genera application used these five fonts in these exact web roles.

The reproduction repository is the public distribution path. This repository still keeps its direct licensed-world extraction products under ignored build/fonts/genera/; do not copy those local intermediates into docs/ or a web application.

Program frames and panes

A Genera Dynamic Windows application commonly separates:

• title or status pane;
• display pane;
• command menu pane;
• interactor or Listener pane;
• Accept Values pane; and
• typeout or temporary output region.

Use one-pixel dividers and content-specific character styles. The panes are parts of one program state, not independent dashboard cards. Avoid separate rounded containers, unrelated shadows, and large gutters around every pane.

The enclosing TV window may add:

• a thin outer border;
• one or more functional decoration rules;
• a narrow scroll margin;
• a bottom label;
• gray-patterned scroll cables, car, or deexposed area; and
• a lower-right drop shadow for a temporary menu.

Do not apply every decoration to every surface. The live System Menu has a shadow; the underlying Listener is a framed application surface, not another floating card.

The /\/\/\ edge seen on some Dynamic Windows panes is a ragged border, and it has a specific meaning: retained content continues beyond that viewport edge. Top and bottom report vertical continuation; left and right report horizontal continuation. The side renderer exists and is enabled by default, but it is less often visible because ordinary text panes commonly remain at horizontal origin zero and do not overflow their right edge. A source-visible Notifications configuration turns the side pair off explicitly.

Do not place the pattern on all four edges as decoration. Start with straight rules, then make only the edge whose overflow predicate is true ragged. Use the source profile's ten-pixel repeat at native or integer-scaled pixels; do not let browser zoom resample a bitmap border independently of the pane. Preserve partial-repeat phase at the right for horizontal edges and at the bottom for vertical edges. The ragged renderer replaces the ordinary straight rule on that edge. In a layered web implementation, first cover or omit the straight rule beneath the active ragged strip, including the rule's boundary pixel, then draw the zigzag. A transparent zigzag laid over the rule, or a mask that stops at the inside of the containing block, incorrectly shows both borders at once. Restore the straight rule when the continuation predicate becomes false. The complete predicates, drawing contract, application inventory, and reviewed horizontal example are in Ragged window borders in Symbolics Genera.

Dynamic Windows menus

The Genera System Menu preserves the three-column organization but adds:

• a title strip;
• typographically distinct column headings;
• a more explicit border;
• a lower-right shadow;
• proportional menu lettering; and
• the same outlined current-item and bottom documentation relationship.

Source analysis establishes 50%-gray stipple use in Dynamic Windows drop shadows. For a crisp web approximation, tile a 2-by-2 mask and offset it only to the lower and right sides:

.#
#.

Do not use a blurred CSS shadow. An implementation can use an absolutely positioned pseudo-element with background-size: 2px 2px, a hard integer offset, and no blur. The offset and extent must come from the selected application/release evidence; this guide has not established one universal Genera shadow measurement.

[data-lm-profile="genera"] .lm-menu {
  position: absolute;
  isolation: isolate;
  overflow: visible;
  color: var(--lm-ink);
  background: var(--lm-paper);
  border: 1px solid var(--lm-rule);
  border-radius: 0;
  box-shadow: none;
}

[data-lm-profile="genera"] .lm-menu::after {
  content: "";
  position: absolute;
  z-index: -1;
  inset:
    var(--genera-menu-shadow-top)
    var(--genera-menu-shadow-right)
    var(--genera-menu-shadow-bottom)
    var(--genera-menu-shadow-left);
  background-image:
    url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='2' height='2' viewBox='0 0 2 2' shape-rendering='crispEdges'%3E%3Cpath d='M1 0h1v1H1zM0 1h1v1H0z'/%3E%3C/svg%3E");
  background-size: 2px 2px;
}

[data-lm-profile="genera"] .lm-menu__title {
  border-bottom: 1px solid var(--lm-rule);
  font-family: var(--lm-font-ui);
  font-style: italic;
  line-height: 1;
  padding-inline: var(--genera-menu-title-inset);
}

Define the four --genera-menu-shadow-* values and --genera-menu-title-inset only after measuring the chosen reference. Keep them integer, hard-edged, and subordinate to the menu. Leaving them undefined is intentional: a convenient default would turn an unverified number into a de facto historical claim. The inline two-pixel SVG contains only the documented diagonal 50%-gray mask; it is implementation code, not a recovered Genera asset.

Accepting Values and semantic forms

A Genera Accepting Values form should read like the observed structured technical document:

• group heading followed by indented rows;
• prompt and current value on one line when space permits;
• alternatives written inline;
• selected/default alternatives distinguished by real bold;
• validation constraints in italic;
• action presentations such as Abort and End printed in the content flow;
• keyboard navigation among queries and choices;
• pointer-sensitive highlighting and documentation; and
• redisplay only of affected regions.

Recommended semantic HTML:

<form class="lm-av" aria-describedby="lm-pointer-doc">
  <fieldset class="lm-av__group">
    <legend>Garbage collector status:</legend>

    <div class="lm-av__query">
      <span id="ephemeral-label">Ephemeral GC:</span>
      <span role="radiogroup" aria-labelledby="ephemeral-label">
        <button type="button" role="radio" aria-checked="false">Off</button>
        <button type="button" role="radio" aria-checked="true">On</button>
      </span>
    </div>
  </fieldset>

  <div class="lm-av__actions">
    <button type="button">Abort</button>
    <button type="submit">End</button>
    <span>uses these values</span>
  </div>
</form>

Style the buttons as printed presentations rather than filled rectangles:

.lm-av button {
  appearance: none;
  color: inherit;
  background: transparent;
  border: 0;
  border-radius: 0;
  padding: 0;
  font: inherit;
}

.lm-av [aria-checked="true"] {
  font-weight: 700;
}

.lm-av button:focus-visible,
.lm-av button:hover {
  outline: 1px solid currentColor;
  outline-offset: 0;
}

The HTML roles preserve accessibility even though the visual treatment rejects modern pill-shaped controls.

Presentations and object-sensitive output

Genera output can retain the semantic identity of displayed objects. A value in a report is not merely colored text: pointer gestures can select it, insert it as input, translate it to a command, or open a context-dependent operation menu.

For a web implementation:

• render semantic values as focusable elements only when they have an action;
• keep ordinary output ordinary text;
• show the current presentation with a reversible outline, underline, or style change;
• update the stable pointer-documentation line with the effective action;
• use a context menu built from the object's type and active command context; and
• ensure keyboard users can reach the same operations.

Avoid making every noun blue and underlined like an ordinary hyperlink. The original language depends on context, transient highlighting, and documentation rather than one permanent “clickable” color.

Genera stipples and color

Genera defines twelve active TV grays and twenty-five active named texture masks, including hatches, rain, tracks, dashes, bricks, tiles, hearts, diamonds, parquet, and weaves. Use them sparingly for:

• drop shadows;
• scroll cables and cars;
• disabled or deexposed regions;
• diagram fill;
• selection feedback; and
• application-specific patterned areas.

The exact cells are cataloged in Gray patterns, textures, and stipples in Symbolics Genera. Do not replace all flat white regions with decorative textures merely because the library contains them.

On a color device, a gray-level request may become a direct achromatic color rather than a stipple. Native colors, raster ALUs, stipples, Dynamic Windows patterns, CLIM inks, and character styles are adjacent but distinct systems. A faithful design should likewise avoid one overloaded “theme color” variable that erases their roles.

Genera component recipe

screen
├─ framed TV/program window
│  ├─ optional title/status pane
│  ├─ display pane
│  ├─ optional command menu or Accept Values pane
│  ├─ interactor/typeout pane
│  ├─ narrow scroll margin
│  └─ bottom window label
├─ temporary titled menu with hard stippled shadow
└─ bottom status area
   ├─ one or two pointer-documentation lines
   └─ user/package/input state

Not every application needs every pane. Preserve the role separation, then remove unused surfaces.

Three-button semantics

The exact command depends on application and context, but an implementation can preserve the broad interaction grammar:

Do not hard-code this table as a claim about every application. Use the complete binding dossiers when reproducing a specific program.

On hardware with one pointer button:

• primary click maps to Select;
• context-menu key or secondary click maps to Right;
• an explicit keyboard shortcut exposes the same operation menu;
• Middle-only functions receive a documented alternate binding; and
• touch uses a visible action affordance rather than an undiscoverable long press alone.

Keyboard

Lisp-machine software assumes a rich keyboard with Control, Meta, Super, Hyper, Shift, and named function keys. For a modern web interface:

• expose commands through a searchable command surface as well as shortcuts;
• display Lisp-machine notation such as C-M-J, S-Right, or Select Q;
• keep multi-stage prefix state visible;
• preserve Abort, Help, End, and Refresh as semantic commands;
• do not rely on browser-reserved chords without a remapping layer; and
• provide a keymap reference generated from the actual active command tree.

The dedicated CADR and Genera modifier studies, with their Hyper companions, should guide application-specific choices.

Menus are semantic and temporary

A menu item has a label, semantic value or command, documentation, enabled state, and sometimes a submenu or style. Preserve that model in application data rather than binding behavior to DOM text.

Dismissal should:

• invoke nothing on Abort or outside cancellation;
• restore focus to the prior owner;
• remove transient highlighting and documentation; and
• restore the underlying screen without visual debris.

More processing and typeout

Long output should stop at a page boundary or use an explicit typeout/scroll region. Do not silently turn every report into an infinite document. Show **MORE** or an equivalent profile-specific continuation state and accept keyboard and pointer continuation.

Audible and visible rejection

Invalid keys, disabled choices, and impossible operations often beep or preserve the current state rather than silently doing nothing. A modern implementation can use:

• a short optional sound;
• a one-frame reversible flash;
• a stable status-line explanation; and
• aria-live error text.

Never use screen shake or a long blocking animation.

Documentary keybinding animations

An instructional site may animate a verified key or pointer transition even though decorative animation is outside both historical profiles. Keep that documentary layer visually subordinate:

• use complete native-resolution runtime frames at their original pixel size or an integer multiple;
• pause long enough to inspect the before and after states instead of simulating smooth modern motion;
• name the exact chord in adjacent selectable text rather than painting a modern keycap overlay over the historical screen;
• distinguish continuous recordings from ordered action-boundary clips;
• use frames from one coherent interaction; never animate unrelated endpoints and call the result a demonstration;
• never invent pointer trajectories, redisplay timing, or intermediate screens; and
• honor reduced-motion preferences by exposing the same states as ordinary stills or text.

Do not fractionally scale GIF frames. Optimized GIF subrectangles may encode only changed pixels after the first frame, but their logical canvas must retain the exact runtime dimensions. The publication and rights rules remain those of the screenshot review, not those of decorative web animation.

Level 1: structural conformance

Preserve:

• pane hierarchy;
• one-pixel rules;
• monochrome palette;
• square geometry;
• mode/who-line structure;
• semantic menus and presentations;
• dense spacing; and
• pointer/focus documentation.

This level does not claim typographic or pixel-level visual conformance. A substituted font must be disclosed rather than presented as CADR or Genera typography.

Level 2: visual conformance

Add:

• the public CADR Fonts or Genera Fonts reproduction matching the selected release profile;
• integer-grid glyph placement;
• exact source-grounded stipple cells;
• historical cursor and scroll-margin shapes;
• profile-specific menu typography and shadows; and
• exact bitmap icons whose rights permit distribution.

Do not substitute a direct local extraction from the licensed world for the bounded, reviewed Genera Fonts publication corpus.

Level 3: behavioral conformance

Add:

• three-button and modifier-aware gesture dispatch;
• command/prefix trees;
• momentary menus;
• semantic presentation records;
• object-sensitive operation menus;
• input correction and completion;
• More/typeout behavior;
• stable pointer documentation;
• pane redisplay; and
• Abort/failure semantics.

At this level, use the subsystem reimplementation specifications rather than this style guide as the normative behavioral source.

Profile

• Is the design explicitly CADR, Genera, or a labeled hybrid?
• Is the release baseline named?
• Are source-grounded facts separated from implementation mappings?
• Can every visible stylistic choice be traced to the selected CADR or Genera profile rather than a generic historical-computing convention?

Typography

• Are body, menu, heading, label, and status roles distinct?
• Are raster fonts placed at integer coordinates?
• Does each large text role use a native resident size rather than a fractionally scaled smaller bitmap?
• Is font synthesis disabled where exact variants exist?
• Does the font package match the selected source/runtime and raw/Unicode profile?
• Are direct Genera extraction intermediates kept local rather than substituted for the reviewed public reproduction?

Geometry

• Are rules one pixel at the final raster scale?
• Are corners square?
• Are windows and menus content-sized rather than card-sized?
• Are labels, scroll margins, and who-line regions inside the layout model?
• Do Genera margin bars use empty outlined end boxes, two patterned cables, and the outlined patterned car rather than a filled modern scrollbar track?
• Are ragged viewport edges shown only for the continuation predicates that are currently true?

Interaction

• Does hover and focus update a stable documentation line?
• Can every pointer operation be performed by keyboard?
• Do menus preserve current item, enabled state, documentation, Abort, and focus restoration?
• Are semantic objects represented in the interaction model rather than inferred from displayed strings?

Restraint

• Is every shadow, stipple, bold face, and reverse-video region functional?
• Are scanlines, glow, gradients, rounded corners, and decorative animation absent unless separately justified?
• Does the design remain usable with bitmap fonts disabled?