# Terminal — style guide for coding agents

> Generated from the Aesthetary record for **Terminal**.
> Research: **Partly sourced** · Build guidance: 17 rules recorded.
> 16 sources attached.

## How to use this

Paste this file into your agent as context before asking it to design or build something in this visual language. It states what is established, what is our interpretation, and what nobody has established. Treat all three differently.

**The most important section is "Not researched yet".** Its purpose is to stop you and your agent inventing rules that sound right and are not recorded anywhere.

## What this language is

**Defining:** Monospace throughout, blinking cursor, one phosphor hue on dark, command prompts

**Recognise it by:** Fixed-pitch characters in a grid of cells used for everything including headings and navigation, a block or underscore cursor marking the active position, rank made by rendition (brightness, underline, reverse video) rather than by face, and one phosphor hue on a near-black ground. The diagnostic property is the interaction metaphor, not the typeface: monospace type on a dark ground is Developer Dark or Monospace Minimal. It is Terminal only when the page behaves as a console, with the prompts, typed commands and sequential output of the command-line software a terminal runs, which means the recognition test is partly behavioural and cannot be made from a static screenshot alone.

**Family:** Speculative & Futurist
**Era:** contemporary
**Native medium:** screen

**Scope:** The visual register of the character-cell computer terminal: fixed-pitch text, block or underscore cursor, one phosphor hue on dark, as Aesthetary's console language; the page-as-console behaviour is our reading.

## What it is arguing

Presents the interface as a command environment rather than a document, asserting technical competence and direct access by adopting an interaction model that predates graphical convention.

**It refuses:** Refuses the graphical affordances of contemporary web design — buttons, cards, imagery — in favour of typed exchange.

## What it is not

Commonly confused with these. Getting the difference right matters more than getting the surface right:

- Monospace Minimal
- Developer Dark
- Cassette Futurism
- Teletext

**What separates this language:** A console as a website; interaction metaphor, not just a type choice

_This is the record's own distinguishing line, not a comparison against any one neighbour. Where a per-neighbour difference is recorded it appears beside that name above; where it is absent, nobody has written it._

## Established rules

Grouped by what kind of claim each is. A requirement of the language and our own interpretation are not interchangeable.

**How to read each rule.** Every rule states two separate things, and neither stands in for the other:

- **Kind of claim** (the heading): Seen in the work · Documented · Source not yet verified · Seen in the work · Documented · Source attached.
- **Evidence** (how it is established): Graded by our research brief · No source attached (`DOCUMENTED`) · From our catalogue entry (`SUPPORTED`) · Our reading (`CURATORIAL`) · Not researched yet (`UNKNOWN`) · No grade recorded (no grade in the record). Where a claim has its own canonical label, the Evidence line gives that label instead of the grade.
- **Product area**: which of the twelve areas the rule belongs to (Layout, Typography, Color, Imagery, Surface, Interface, Motion, Motif, Technique, Form, Hierarchy, Density), mapped from its raw area label in bold. "Context" means the rule is about the Aesthetic (its name, origin, lineage) rather than a part of the design. "Not mapped" means the raw area has no single area yet.
- The code in brackets is the `grade` field at `implementationConstraints.tokenRules.value.rules[].provenance.grade` in https://aesthetary.com/data/terminal.json. "From our catalogue entry" means: Stated in Aesthetary’s existing catalogue entry. An outside source is named only where one is linked to the claim.

### Seen in the work

- **grid** — Text occupies a fixed character cell. Every glyph advances the same width and sits on the same line pitch, so columns align without being aligned.
  - Kind of claim: Seen in the work · Evidence: Seen in the work · Product area: Layout

### Documented · Source not yet verified

- **color** — The palette is restricted to what a phosphor display could produce: one foreground hue on a near-black ground, with the ANSI colour set as the only sanctioned extension.
  - Kind of claim: Documented · Source not yet verified · Evidence: Documented · Source not yet verified · Product area: Color

## Found in research

What research established from sources Aesthetary opened and checked. Each line names its area, how it is known, and where it is scoped. "Seen in the work" means the source documents particular works or products rather than the Aesthetic as a whole.

- **Imagery** — Pictures are built from characters: the VT100 added a box-drawing set whose pieces join into unbroken lines, used to draw on-screen forms.
  - Evidence: Documented · Source attached · Claim: `kcc:imagery-1` · Covers DEC VT100 Special Graphics set.
- **Imagery** — The box-drawing set existed to draw on-screen forms, and the terminal supported fill-in-the-blanks form applications.
  - Evidence: Documented · Source attached · Claim: `kcc:imagery-2`
- **Surface** — The surface is a monochrome CRT: one phosphor colour, offered as green, white or amber (sometimes blue), with a non-glare screen on DEC's VT200 series.
  - Evidence: Documented · Source attached · Claim: `kcc:surface-1`
- **Surface** — Discernible scanlines, and brightness-dependent variation in apparent font weight, shaped how VT text looked.
  - Evidence: Documented · Source attached · Claim: `kcc:surface-2` · Covers DEC VT100/VT220; specialist reconstruction.
- **Surface** — High-intensity phosphors produced afterglow and screen burn; the retro imitation of this look is a later visual shorthand, not the original.
  - Evidence: Documented · Source attached · Claim: `kcc:surface-3` · Covers encyclopedia support only; separates the device from its later imitation.
- **Interface** — The cursor marks the active position; the VT100 offers two cursor representations, and text-mode displays used an underscore or block cursor.
  - Evidence: Documented · Source attached · Claim: `kcc:interface-1` · Covers VT100; the block/underscore form follows from text mode.
- **Interface** — The prompt belongs to command-line software, not to the terminal: it is a character sequence signalling readiness for a command and is often user-modifiable.
  - Evidence: Documented · Source attached · Claim: `kcc:interface-2` · Covers CLI convention.
- **Interface** — Beyond the command line, the terminal supports fill-in-the-blanks forms, which can be drawn with the box-drawing characters.
  - Evidence: Documented · Source attached · Claim: `kcc:interface-3` · Covers VT100/VT200 era.
- **Interface** — The command-line environment may not provide GUI enhancements such as different fonts or extended edit windows.
  - Evidence: Documented · Source attached · Claim: `kcc:interface-4`
- **Motion** — New lines scroll up from the bottom, either as fast as they arrive (jump scroll) or at a capped smooth rate of at most six lines per second.
  - Evidence: Seen in the work · Claim: `kcc:motion-3` · Covers DEC VT100.
- **Motion** — Blinking cursors are attributed to Charles Kiesling Sr.'s US Patent 3531796; the VT100 offered two cursor representations.
  - Evidence: Documented · Source attached · Claim: `kcc:motion-1`
- **Motion** — Text can carry a blink attribute.
  - Evidence: Documented · Source attached · Claim: `kcc:motion-2`
- **Motion** — On heavy-phosphor monochrome screens, scrolled text left an afterglow or 'ghost image'.
  - Evidence: Documented · Source attached · Claim: `kcc:motion-4` · Covers encyclopedia support only.
- **Motif** — The maker supplies a functional line-drawing set whose pieces join into unbroken lines.
  - Evidence: Seen in the work · Claim: `kcc:motif-1`
- **Technique** — Screen content is composed by the host through encoded control functions (ANSI X3.64 escape sequences) interleaved with text.
  - Evidence: Seen in the work · Claim: `kcc:technique-3`
- **Technique** — Characters are dot-matrix glyphs from ROM placed in fixed cells (VT220: 7 x 10 dots in a 10 x 10 cell at 80 columns); the text mode addresses the screen as a regular grid of tiles.
  - Evidence: Documented · Source attached · Claim: `kcc:technique-1` · Covers DEC VT220; the DEC handbook gives 7 x 9 for the same terminal.
- **Technique** — DEC VT terminals used a technique called dot stretching, which a specialist reconstruction calls an extreme example of the medium instructing typographic form.
  - Evidence: Documented · Source attached · Claim: `kcc:technique-2` · Covers DEC VT100/VT220.
- **Form** — Three-dimensional form belongs to the device (a monitor/system unit plus keyboard), which is the historical subject; the approved scope is the on-screen register.
  - Evidence: Documented · Source attached · Claim: `kcc:form-1`
- **Hierarchy** — Rank can be made with per-character rendition attributes: bold (or increased intensity), underline, blink and reverse video.
  - Evidence: Seen in the work · Claim: `kcc:hierarchy-1` · Covers DEC VT100/VT200 family; the 'Advanced video' attributes.
- **Hierarchy** — The maker states the purpose of these attributes as formatting, prompting and highlighting portions of text.
  - Evidence: Seen in the work · Claim: `kcc:hierarchy-2` · Covers VT200 family, DEC handbook.
- **Hierarchy** — A whole line can be set double-width, or double-height double-width, which halves the characters that fit on that line.
  - Evidence: Seen in the work · Claim: `kcc:hierarchy-3` · Covers DEC VT100 and later; not all terminals.
- **Hierarchy** — Quite a few terminals implemented 'bold' as a brighter colour rather than a different font.
  - Evidence: Documented · Source attached · Claim: `kcc:hierarchy-4` · Covers ANSI-escape terminals generally; encyclopedia support only.
- **Density** — The VT100 screen in 80-column mode is 80 characters by 24 lines; double-width characters halve a line's capacity.
  - Evidence: Seen in the work · Claim: `kcc:density-1` · Covers DEC VT100; 132-column mode had 14 lines without the Advanced Video Option.
- **Density** — The 132-column mode was sold for seeing full report and spreadsheet formats, i.e. maximum density was a feature.
  - Evidence: Seen in the work · Claim: `kcc:density-2` · Covers VT200 family.

## Positions by area

The overall position recorded for each area. "No overall position recorded" means rules exist for the area but no position above them; the rules still apply. It is not the same as "Not established", which means nobody has researched the area.

- **Layout** — Specified
- **Typography** — Specified
- **Color** — Specified
- **Imagery** — Specified
- **Surface** — Specified
- **Interface** — Specified
- **Motion** — Specified
- **Technique** — Specified
- **Form** — Outside this language. The area does not apply; this is not a gap in the research.

## Design grammar — web primitives

A starting grammar for a website in Terminal: fixed character cells, one phosphor hue on a near-black ground, a block cursor, rank by rendition rather than by face, and frames drawn with the line-drawing set.

Three kinds of line: **On the record** names a rule this record holds (its wording is under Established rules) and states what it becomes on the web. **Web translation** is Aesthetary's choice for the web, derived from the rules it cites; change it if you have a reason, keep the cited rule. **Not specified by the source** means the research reached this but the sources say nothing about it; **Not researched yet** means the research has not reached it yet. Either way, follow the instruction and do not invent a rule. Structured version: `designGrammar` in data/terminal.json.

### Colour

| Role | Value | Contrast | Use | Kind |
| --- | --- | --- | --- | --- |
| ground | `#060A07` | — | The tube: near-black. | On the record |
| phosphor | `#53E08C` | 11.5:1 | Text: the one hue. | Web translation |
| bright | `#8CFFB6` | 14.5:1 | Bold, drawn as brightness. | Web translation |
| mid | `#3DBA72` | 7.6:1 | Rules and secondary text. | Web translation |
| dim | `#2E9B5E` | 5.2:1 | Glosses and metadata. | Web translation |

Other accents the record supports:

- Green (recorded as "green phosphor"): `#53E08C`
- Amber (recorded as "amber phosphor"): `#FFB547`
- White (recorded as "white phosphor"): `#E8EDE9`

- **On the record · Documented · Source not yet verified** · `token_rule:te-r2` → Use one foreground hue on a near-black ground; the ANSI colour set is the only extension.
- **On the record · Documented** · `claim:kcc:surface-1` → Choose the one phosphor from green, white or amber (sometimes blue).
- **Web translation** — Make bold a brighter tint of the same hue. _Why:_ Quite a few terminals implemented bold as a brighter colour rather than a different font. (`claim:kcc:hierarchy-4`)

### Typography

Family: monospace, supplied by the reader's machine (the record names the class, never a face). Stack: `ui-monospace, "SF Mono", Menlo, Consolas, "DejaVu Sans Mono", monospace`

| Role | Size | Weight | Line height | Case | Tracking | Measure | Setting | Use |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| line | 1rem | 400 | 1.6 | not specified | not specified | 80ch | — | Everything: headings, navigation and text are one size. |
| double | 1rem, scaled 2 x wide | 400 | 1.6 | not specified | not specified | 40ch | transform: scaleX(2) | A whole line set double-width, for a title. |

- **On the record · From our catalogue entry / Our reading** · `claim:typography-block`, `claim:dcc:gestalt` → Set monospace for everything, headings and navigation included.
- **On the record · Seen in the work** · `token_rule:te-r1` → Put every glyph in a fixed cell: the same advance, the same line pitch.
- **On the record · Seen in the work** · `claim:kcc:hierarchy-1` → Rank with rendition attributes: bold (or brightness), underline, blink, reverse video.
- **On the record · Seen in the work** · `claim:kcc:hierarchy-3` → Set a whole line double-width for a title; it holds half the characters.
- **Not specified by the source** — The sources do not specify a typeface. _Instead:_ Use the system monospace; the dot-matrix ROM glyphs are the device's, and a pixel font imitating them is a choice to declare.

### Grid and layout

The screen is a grid of character cells, 80 columns by 24 lines on the VT100; columns align because every cell is the same, not because a grid is drawn.

Module 1ch x 1 line · gutter 0 · margin 1ch

| Viewport | Columns |
| --- | --- |
| reading | 80 |
| double-width lines | 40 |

Tokens: measure `80ch`

- **On the record · Seen in the work** · `token_rule:te-r1` → Let text occupy fixed character cells, so columns align without being aligned.
- **On the record · Seen in the work** · `claim:kcc:density-1` → Take the screen as 80 characters by 24 lines.
- **On the record · Seen in the work** · `claim:kcc:density-2` → Treat density as a feature: the 132-column mode sold for seeing whole reports.
- **Web translation** — Cap the reading measure at 80ch and let the page run on below. _Why:_ The screen is 80 columns; a web page scrolls where the screen scrolled up line by line. (`claim:kcc:density-1`, `claim:kcc:motion-3`)

### Shape and geometry

Tokens: radius `0` · rule `1px solid #3DBA72`

- **On the record · Seen in the work** · `claim:kcc:motif-1` → Draw lines and boxes with the line-drawing set, joined unbroken.
- **Web translation** — No radius and no shadow anywhere. _Why:_ Everything on the screen is a cell or a joined line; there is nothing to round. (`token_rule:te-r1`, `claim:kcc:imagery-1`)

### Imagery

- **On the record · Documented** · `claim:kcc:imagery-1` → Build pictures from characters; the line-drawing set draws on-screen forms.
- **On the record · Documented** · `claim:kcc:interface-3` → Use box-drawn fill-in-the-blanks forms beyond the command line.
- **On the record · Documented** · `claim:kcc:surface-3`, `claim:kcc:surface-2` → Leave out afterglow, screen burn and bloom: they are the later imitation, not the screen. Faint static scanlines are the most the documented surface supports.

### Components

Anatomy, tokens and states below are Web translation: Aesthetary's specification for the screen. Each value line after them says whether it restates a rule this record holds.

#### Button

A label in reverse video: the ground colour on a phosphor block, in brackets when it is waiting.

- Anatomy: phosphor block; label in the ground colour; no radius, no shadow
- Tokens: background `#53E08C` · color `#060A07` · radius `0` · padding `0 1ch`
- State, default: Reverse video: dark label on the phosphor.
- State, hover: Underline added under the label.
- State, focus: 2px phosphor outline, 3px outside.
- State, active: Normal video: phosphor label on the ground.
- State, disabled: Dim phosphor label in brackets, no block.
- Accessibility: 11.5:1 either way round.
- Accessibility: At least 44px tall.
- Accessibility: The label is words; no action is a glyph alone.
- **Web translation** — Mark the action with reverse video. _Why:_ Rendition attributes are how the screen ranks, and highlighting is their stated purpose; reverse is the strongest of them. (`claim:kcc:hierarchy-1`, `claim:kcc:hierarchy-2`)

#### Card

A box drawn in line-drawing characters, its title set into the top rule.

- Anatomy: top rule with the title in it; body in fixed cells; bottom rule
- Tokens: border `1px solid #3DBA72 (the line-drawing set, drawn as rules)` · radius `0` · padding `1ch`
- State, default: Mid-phosphor rules around bright text.
- State, hover: The title goes to reverse video.
- State, focus: 2px phosphor outline.
- Accessibility: Rules are borders, not box-drawing glyphs in the text, so screen readers do not read them.
- Accessibility: The title is a real heading.
- **On the record · Documented** · `claim:kcc:imagery-1` → Draw frames with the line-drawing set, whose pieces join into unbroken lines.
- **Web translation** — Draw the lines as CSS borders on the cell grid. _Why:_ The set exists to draw on-screen forms; borders give the same unbroken line without glyphs for a screen reader to speak. (`claim:kcc:imagery-2`, `claim:kcc:motif-1`)

#### Input

A command line: the prompt, what you type, and a block cursor at the active position.

- Anatomy: prompt, a character sequence; typed text in phosphor; block or underscore cursor
- Tokens: prompt `"$ "` · caret `block` · color `#53E08C` · background `transparent` · border `none`
- State, default: Prompt, then the cursor waiting.
- State, focus: The cursor blinks; a 1px mid-phosphor rule under the line.
- State, error: The next output line begins "error:" in bright phosphor.
- State, disabled: Dim prompt, no cursor.
- Accessibility: An accessible name on the field ("Type a command").
- Accessibility: Output lands in an aria-live region.
- Accessibility: Errors are words.
- **On the record · Our reading** · `claim:dcc:te-r3` → Let a prompt precede input, output follow in sequence, and the cursor mark the position.
- **On the record · Documented** · `claim:kcc:interface-1` → Use a block or underscore cursor at the active position.
- **Web translation** — Treat the prompt as software, not hardware: its text is yours to set. _Why:_ The prompt belongs to command-line software and is often user-modifiable. (`claim:kcc:interface-2`)

#### Navigation

A list of commands you can type or follow, the current one in reverse video.

- Anatomy: command names in bright phosphor; a dim gloss after each; current in reverse video
- Tokens: color `#53E08C` · gloss `#2E9B5E` · current `reverse video`
- State, default: Bright command, dim gloss.
- State, hover: Underline.
- State, focus: 2px phosphor outline.
- State, current: Reverse video on the command name.
- Accessibility: aria-current on the current item.
- Accessibility: Every command is also a link: typing is never the only way.
- **Web translation** — Offer navigation as the commands the prompt would accept, each also a link. _Why:_ The page as a console is our reading; the command environment may not provide GUI enhancements, so links stand in without breaking it. (`claim:interface-scope-reading`, `claim:kcc:interface-4`)

### Motion

Durations, easing and the rest of this specification are Web translation: Aesthetary's choice for the screen.

- Durations: blink 1s cycle, scroll at most 6 lines a second (smooth scroll)
- Easing: all `steps(1)`
- Transforms: none: lines arrive, the cursor blinks.
- Entrance: Output appears line by line from the bottom, or all at once (jump scroll).
- Hover: Underline, instant.
- Reduced motion: The cursor stays solid; output appears at once.
- **On the record · Documented** · `claim:kcc:motion-1` → Blink the cursor.
- **On the record · Documented** · `claim:kcc:motion-2` → Text may carry a blink attribute.
- **On the record · Seen in the work** · `claim:kcc:motion-3` → Scroll new lines up from the bottom, as they arrive or at no more than six lines a second.
- **Web translation** — Stop blinking text after four beats; keep only the cursor blinking. _Why:_ Blink is an attribute of the screen; the web limits moving content to five seconds unless the reader can stop it (WCAG 2.2.2). (`claim:kcc:motion-2`)

### Deliberately not added

- **A typeface** (typography): The record names the monospace class; the device's ROM glyphs are not a web face.
- **Which phosphor** (color): Green, white and amber are all documented; green is this room's.
- **A button, a card, navigation** (components): The screen had rendition, forms and a cursor. These three components are translations; the command line is our reading of the page as a console.

## Not researched yet

Nobody has established a position for this language on:

- Motif

**Do not fill these in.** An absent position is absent research, not permission and not a blank for you to complete. If the work needs a decision in one of these areas, make it on other grounds and do not attribute it to this language.

## Grade your own work

10 checks: 3 mechanically testable, 6 needing a person to look, 0 needing a source Aesthetary does not hold, 1 with no recorded position. Scores do not add up. A failure against a required rule and a departure from something we invented are not the same result, and no total should let them cancel.

### Recognition — does this read as the intended Aesthetic?

- **[visual_human · recognition signature · Evidence: No grade recorded]** Strip every logo, word and borrowed image out of your work, then show it to someone who knows the collection. Do they land on this Aesthetic? The signature to hold is: Fixed-pitch characters in a grid of cells used for everything including headings and navigation, a block or underscore cursor marking the active position, rank made by rendition (brightness, underline, reverse video) rather than by face, and one phosphor hue on a near-black ground. The diagnostic property is the interaction metaphor, not the typeface: monospace type on a dark ground is Developer Dark or Monospace Minimal. It is Terminal only when the page behaves as a console, with the prompts, typed commands and sequential output of the command-line software a terminal runs, which means the recognition test is partly behavioural and cannot be made from a static screenshot alone.
  - _If it fails:_ The work may be competent and still read as a different Aesthetic, or as none. Nothing below matters until this passes.

### Fidelity — are its defining rules present?

- **[unassessable · no recorded position · Evidence: Not researched yet (`UNKNOWN`)]** Nothing is recorded as a requirement of this Aesthetic. There is no rule here that your work must hold — which means nothing you do can fail this dimension, and nothing you do can satisfy it either. That is missing research, not freedom.
  - _If it fails:_ Not applicable. An empty dimension is an absence of research, never a pass and never a failure.

### Implementation — were those rules translated appropriately into this medium?

- **[visual_human · Seen in the work · Evidence: Seen in the work]** Your work may depart from this — but knowingly, not by accident. Text occupies a fixed character cell. Every glyph advances the same width and sits on the same line pitch, so columns align without being aligned.
  - _If it fails:_ A defensible departure, and you should be able to say why you made it.
- **[visual_human · Documented · Source not yet verified · Evidence: Documented · Source not yet verified]** Your work may depart from this — but knowingly, not by accident. The palette is restricted to what a phosphor display could produce: one foreground hue on a near-black ground, with the ANSI colour set as the only sanctioned extension.
  - _If it fails:_ A defensible departure, and you should be able to say why you made it.

### Avoidance — known failure modes, neighbour drift, cloning

- **[visual_human · neighbour drift · Evidence: No grade recorded]** Could your work be mistaken for Monospace Minimal? That language is: Mono carries the entire voice; everything else is restrained to let it
  - _If it fails:_ Not necessarily wrong, but you are closer to Monospace Minimal than to this Aesthetic.
- **[visual_human · neighbour drift · Evidence: No grade recorded]** Could your work be mistaken for Cassette Futurism? That language is: A future imagined in 1979; beige plastic, not chrome
  - _If it fails:_ Not necessarily wrong, but you are closer to Cassette Futurism than to this Aesthetic.
- **[visual_human · neighbour drift · Evidence: No grade recorded]** Could your work be mistaken for Teletext? That language is: Broadcast grid rather than console; colour blocks, not phosphor lines
  - _If it fails:_ Not necessarily wrong, but you are closer to Teletext than to this Aesthetic.

### Accessibility — the Aesthetic preserved without its inaccessible practice

- **[mechanical · recorded accessibility cost · Evidence: No grade recorded]** This Aesthetic accepts "Accessibility" as a cost. Your reader did not. Does your work carry that cost in the decorative layer only — display, demonstration, atmosphere — while every passage meant to be read holds a contrast ratio of at least 4.5:1?
  - _If it fails:_ You have inherited a historical cost that the language never required you to pass on. The Aesthetic survives at AA on reading matter; reproducing the cost is a choice, not fidelity.
- **[mechanical · recorded accessibility cost · Evidence: No grade recorded]** This Aesthetic accepts "Discoverability" as a cost. Your reader did not. Does your work carry that cost in the decorative layer only — display, demonstration, atmosphere — while every passage meant to be read holds a contrast ratio of at least 4.5:1?
  - _If it fails:_ You have inherited a historical cost that the language never required you to pass on. The Aesthetic survives at AA on reading matter; reproducing the cost is a choice, not fidelity.
- **[mechanical · recorded accessibility cost · Evidence: No grade recorded]** This Aesthetic accepts "Conversion for non-technical audiences" as a cost. Your reader did not. Does your work carry that cost in the decorative layer only — display, demonstration, atmosphere — while every passage meant to be read holds a contrast ratio of at least 4.5:1?
  - _If it fails:_ You have inherited a historical cost that the language never required you to pass on. The Aesthetic survives at AA on reading matter; reproducing the cost is a choice, not fidelity.

## Rules for the agent

1. Do not invent rules for any area listed under **Not researched yet**.
2. Do not treat an absent position as permission to do anything you like — say that the language has no position, and decide on other grounds.
3. Keep our interpretations separable from the language's own requirements. If asked to justify a choice, cite which kind of claim it came from.
4. If you need something this record does not contain, say so rather than producing a confident answer from the aesthetic's name.
5. When you self-score against "Grade your own work", score only checks marked `mechanical`. Declare `visual_human` and `evidence_dependent` checks unjudged rather than guessing, and never score an `unassessable` one.
6. Evidence "Not researched yet" (`UNKNOWN`) is never a failure. It means nobody researched the dimension, so departing from what is written there costs nothing and must not be reported as a defect. "No grade recorded" is not a grade either: do not treat it as our decision or as an outside source.
7. In **Design grammar**, a "Web translation" line is our choice for the web and may be changed with a reason; the rules it cites may not. Never present a translation as a property of the language.

## Provenance

- Record: `terminal` · status `draft` · research `partly_researched`
- Full structured record: https://aesthetary.com/data/terminal.json
- Human-readable record: https://aesthetary.com/a/terminal.html
- This file is a snapshot. The record may have changed since; check the page above.

_Aesthetary is an alpha. Where a page says nothing, nobody has done the work yet._