aetherbound-guild/docs/presentation/UI_AND_VISUAL_SYSTEM.md

# Aetherbound Guild: UI And Visual System

> Authority: player-facing landscape composition, information hierarchy,
> reusable UI grammar, semantic color, type, input feedback, responsive
> behavior, and accessibility presentation.
>
> Companion: [SCREEN_AND_STATE_MAP.md](SCREEN_AND_STATE_MAP.md).
>
> Product source: `.agent-taskgraph/spec.md` revision `design-spec-r3`.
>
> Evidence boundary: this is a production specification, not rendered UI,
> final media, runtime proof, device acceptance, or human validation.

## 1. Visual Thesis

**A field guild making consequential plans at the edge of a vivid, unstable
fantasy world.**

The first viewport presents the actual decision surface: generated recruits at
a muster table, physical equipment under comparison, an ordered expedition
line, a dangerous destination, or a battle already resolving. The world and
its actors remain the primary composition. UI surfaces attach to a desk edge,
tool rack, field ledger, route frame, or screen edge instead of floating as a
wall of panels.

The visual language combines hand-painted 2D Japanese fantasy environments,
clean cel-shaped actors, dark ink structure, bright mineral pigments, cool
paper-white labels, enamel action plates, woven position markers, and precise
engine-rendered type. It feels practical and repaired, not royal, luxurious,
or collectible-first.

Generated recruits read as individuals through their sourced name, modular
appearance, profession silhouette, one trait seal, equipment, condition, level,
and survival marks. Presentation never implies that one recruit is an authored
lead who must remain in the party.

### 1.1 Three-Second Reads

| Moment | First read | Second read | Third read | Desired feeling |
|---|---|---|---|---|
| Title | active guild threshold and distant unstable route | current safe run state | Continue and accessibility access | invited, not advertised to |
| Guild desk | next pressure or opportunity | what changed after the last result | available preparation destinations | purposeful freedom |
| Shop | materially different offers | cost and current fit | refresh or return consequence | constrained possibility |
| Recruit review | profession responsibility and trait tradeoff | rolled strengths and limitation | price and party effect | informed attachment without narrative obligation |
| Final-survivor dismissal | disabled Dismiss and `One member must remain` | separate run-abandonment action | retained Recruit and zero-delta result | protected consequence without a dead end |
| Equipment | changed behavior and eligible wearer | conflict or replacement | cost and reversibility | deliberate construction |
| Party line | order from first exposure to last | protection, reach, movement, and target effects | validation and undo | readable planning |
| Risk choice | known pressure and uncertainty | reward class and recovery exposure | committed party snapshot | chosen tension |
| Battle | most urgent event and affected actors | why the current target or protection relation exists | pause, speed, and inspect | trust in automatic resolution |
| Result | earliest meaningful divergence | downstream losses and survivors | next adaptation | diagnosis, not spectacle alone |
| Death | who was lost and what capability disappeared | equipment and party gaps | legal recovery or replacement path | consequence with agency |
| Reward | which future decision changes | current build interaction | claim consequence | earned redirection |
| Postgame | active rule differences | eligibility and record | ordinary run remains available | mastery with transparency |

### 1.2 Anti-Goals

- No detached dark rectangles covering a decorative background.
- No portrait-card wall as the primary roster, planning, or battle view.
- No oversized headings inside compact operational surfaces.
- No rarity color as the main argument for recruiting or choosing an item.
- No one-hue fantasy wash; semantic colors stay distinct from region art.
- No beige parchment monoculture, full-screen blur, ornamental glow spheres,
  decorative gradients, or particle haze.
- No tiny actors whose profession, order, target, health, and death state vanish
  at play size.
- No icon-only unfamiliar resource, trait, status, or destructive action.
- No animated decoration that resembles danger, a legal target, a reward, or a
  successful transaction.
- No font sizing tied to viewport width, negative letter spacing, text baked
  into art, or forced one-line localized controls.
- No nested decorative cards. Repeated offers and items may use bounded rows;
  page sections remain unframed or edge-docked.

## 2. Cross-Workstream Presentation Bindings

Gameplay values use the binding registry in the companion screen map. Media
identity uses the following named bindings until the art and audio authorities
are integrated:

| Binding | Required presentation contract | Source authority |
|---|---|---|
| `BIND:ART_RECRUIT_PRESENTATION` | modular body, face, hair, garment, condition, and survival-mark layers | art/animation catalog |
| `BIND:ART_PROFESSION_PRESENTATION` | silhouette, tool/weapon, pose, emblem, and action-read vocabulary for each profession | art/animation catalog |
| `BIND:ART_EQUIPMENT_PRESENTATION` | inventory object, equipped read, comparison view, and conflict marker | art/animation catalog |
| `BIND:ART_REGION_PRESENTATION` | environment, route material, weather, and readable ground contrast per region | art/animation catalog |
| `BIND:ART_ENEMY_PRESENTATION` | identity, threat source, target projection, status, injury, and death/exit reads | art/animation catalog |
| `BIND:ART_EFFECT_LANGUAGE` | anticipation, target, impact, mitigation, status, death, reward, and recovery event roles | art/animation catalog |
| `BIND:AUDIO_EVENT_CATALOG` | UI commit, shop, order, battle, casualty, result, reward, recovery, and error cues | audio catalog |

Design fixtures may use labeled geometric stand-ins. They may not invent final
silhouettes, asset counts, music, voice scope, prices, formulas, or content
identities.

## 3. Canvas, Safe Areas, And Responsive Tracks

The interface is designed in logical pixels. Layout changes by available height
and aspect, not by scaling the entire canvas.

| Class | Required fixture | Safe area | Structural policy |
|---|---:|---:|---|
| Short landscape phone | `1280x720` | `56` sides, `40` top/bottom plus device insets | compact top rail, full-height decision surface, bottom action dock; detail replaces secondary region |
| Wide landscape phone | `1560x720` | device insets plus `56` | keep short-height control sizes; reveal world laterally |
| Landscape tablet | `1366x1024` and `2048x1536` | `64` all edges plus device insets | main decision area plus persistent contextual rail when useful |
| Reference landscape | `1920x1080` | `96` all edges | canonical composition and two-region comparison |
| Large landscape | `2560x1440` | `128` all edges | constrained UI tracks; reveal environment and longer lists |

The major tracks are stable:

- top status rail: `56-72` high, one row at 100%, two bounded rows at 130%;
- main subject: at least `62%` of usable width and `68%` of usable height;
- context rail: `360-520` wide when docked, or a full-height replacement surface
  on a short phone;
- bottom action dock: `72-96` high, with one primary action aligned to the
  decision rather than centered by habit;
- inspect surface: up to `42%` of width on tablet/reference, full screen on a
  short phone at 130%; and
- settings category rail: `224-272` wide when persistent; a top selector when
  the scaled label set would narrow content below its minimum.

Control and text dimensions do not stretch on large screens. Environment art,
world spacing, and list length absorb extra room. Cutouts and home indicators
may move the action dock inward but never cover a focus outline or consequence.

### 3.1 Responsive Priority

When height or text space is constrained, retain in this order:

1. objective or decision name;
2. current state and selected stable identity;
3. cost, consequence, and reversibility;
4. primary action and Back;
5. comparison delta or urgent causal explanation;
6. supporting history and flavor.

Items 1-5 remain in the first viewport. Item 6 may move to Inspect. No layout
solves overflow by reducing type below its token or actors below their minimum
readable silhouette.

## 4. Information Hierarchy

| Decision surface | Primary | Secondary | Deferred to inspect |
|---|---|---|---|
| Guild desk | upcoming pressure, latest change, preparation readiness | sourced resources and open decisions | complete run history |
| Shop | offer behavior, price, immediate fit | future eligibility and refresh consequence | full discovery provenance |
| Recruit review | profession responsibility, trait benefit/cost, rolled constraint | equipment eligibility, level, survival history | full attribute derivation |
| Dismissal/abandonment | eligibility and affected scope | returned equipment, rebate or run-close consequence | unrelated Recruit history |
| Equipment | changed behavior, wearer, replacement, conflict | secondary derived effects and acquisition | unrelated collection record |
| Party line | position, exposure, target/protection/reach change | alternate order and unresolved warning | cosmetic identity detail |
| Risk | known threat, uncertainty, entry cost, reward class | current coverage and recovery exposure | unrelated progression |
| Battle | urgent event, affected actor, objective, playback state | aggregate party condition | long-form build explanation |
| Result | first divergence, decisive interaction, deaths, next resolution | contribution and complete event list | collection celebration |
| Recovery | viable paths, full transaction, next planning state | longer-term replacement implications | unrelated records |
| Progression | newly opened decisions and prerequisites | path preview and reset consequence | unrelated catalog entries |

The same mechanical noun and icon must be used in preview, battle, result, and
records. A tooltip cannot rename a rule or hide a consequence behind flavor.

## 5. Semantic Palette

Region art supplies local color. UI semantics use a small, stable set that is
readable over both bright and dark scenes.

| Token | Color | Meaning | Required non-color cue |
|---|---|---|---|
| `ink-950` | `#182127` | primary text, deepest structural edge | solid weight |
| `ink-760` | `#34424A` | docked instrument and inactive surface | inset border |
| `mist-050` | `#F3F6F2` | primary text field and selected ledger surface | raised plane |
| `mist-180` | `#D7E0DD` | secondary surface and divider | woven grain |
| `route-teal` | `#13818A` | legal flow and navigation path | paired continuous lines |
| `work-gold` | `#D6A72E` | primary decision and selected destination | key-notch edge |
| `safe-jade` | `#27845E` | health, retained state, safe completion | upward leaf-chevron |
| `danger-coral` | `#C94E52` | urgent harm, invalid destructive consequence | split triangle |
| `focus-cobalt` | `#4169B1` | focus, inspect, information action | double square contour |
| `uncertain-plum` | `#855579` | uncertainty and incomplete forecast | broken ring |
| `neutral-silver` | `#88969B` | disabled or not applicable | cross-pin and text reason |
| `focus-white` | `#FFFFFF` | controller/keyboard outer focus | paired outer and ink inner line |

Semantic color occupies no more than one quarter of a large component surface.
Health, danger, uncertainty, eligibility, selection, and completion use shape,
text, and pattern in addition to hue. Body text meets `4.5:1` contrast and
large text plus meaningful component boundaries meet `3:1` in all approved
region fixtures.

Rarity, when supplied by content, is secondary metadata. It may change a small
corner stamp or texture but never the size, brightness, or order of an offer.

## 6. Typography, Numbers, And Localization

Display text uses a licensed Japanese/Latin-capable humanist sans only for the
product name, region arrival, and run ending. Functional UI uses a highly
legible Japanese/Latin sans with tabular numerals. Font selection remains
pending glyph, license, fallback, and device rendering review.

Reference tokens at `1920x1080`, 100%:

| Style | Size / line | Use |
|---|---:|---|
| Display | `46 / 58` | product name or region arrival only |
| Screen title | `32 / 40` | page or major decision name |
| Section title | `24 / 32` | one bounded content region |
| Body | `20 / 29` | consequence and explanation |
| UI label | `18 / 24` | actions, tabs, fields, position markers |
| Caption | `16 / 22` | noncritical metadata |
| Battle label | `18 / 22` | attached event, value, timer, status |

Letter spacing is `0`. All numeric values use tabular numerals. A changed value
uses a named `before -> after`, signed delta, or before/after bar. A percentage
never appears without the affected rule and sourced base consequence.

At 115% and 130%, font and control tokens increase independently of viewport.
Labels may wrap to two lines. Screen titles, buttons, tabs, generated names,
prices, consequences, and state labels do not ellipsize. Noncritical history
may truncate only when an adjacent Inspect action exposes the complete
accessible string.

English (`en`) and Simplified Chinese (`zh_CN`) share hierarchy and action order. Chinese
mechanical text remains engine-rendered, uses localized punctuation, and is
tested without inserting spaces between ideographs. Dates, numbers, and unit
order use locale formatting, while stable diagnostic IDs remain ASCII.

## 7. Shape, Material, And Icon Grammar

| Meaning | Shape/material |
|---|---|
| Global navigation | squared enamel tab with one clipped corner |
| Recruit identity | upright woven marker plus unframed full or half figure |
| Profession | stamped tool silhouette backed by a square field |
| Trait | single hexagonal seal with benefit edge and cost notch |
| Equipment | physical object silhouette on a shallow metal tray |
| Artifact | shared-rule emblem on a full-width ledger strip, visually separate from equipment |
| Party position | numbered stitched marker joined to one horizontal cord |
| Known threat | angular forecast sheet with a pointed time edge |
| Uncertainty | broken outer contour and explicit confidence text |
| Safe completion | closed contour, receipt stamp, and named result |
| Destructive consequence | split edge and warning sentence; not a solid red fill |
| Locked | cross-pin plus named requirement; never an unexplained lock icon |

Cards have at most `8 px` corner radius. Cards are reserved for repeated shop
offers, repeated reward choices, and transaction reviews. A card contains rows
and dividers, not more cards. Page sections remain edge-docked or unframed.

Familiar tools use familiar symbols from the implementation's approved icon
library: Back, close, settings, pause, play, speed, inspect, compare, filter,
sort, search, undo, speaker, controller, download, and warning. Unfamiliar
profession, trait, status, resource, or threat icons always pair with localized
text and expose a tooltip or touch Inspect action.

Icon envelopes are `24`, `32`, and `48` logical pixels with a consistent
reference stroke. Filled/outline alone may not distinguish two state meanings.

## 8. Core Components

### 8.1 Action Control

One primary action appears in each decision region. The label uses an explicit
verb and includes cost or outcome when sourced: `Recruit - [price]`, not
`Confirm`.

| Variant | Composition | Behavior |
|---|---|---|
| Primary | gold enamel edge, ink label, leading familiar icon | performs or opens the named decision |
| Inspect | mist surface, cobalt double contour | opens reversible detail |
| Safe commit | jade completion edge and closed contour | states retained result |
| Risk commit | mist surface with coral split and uncertainty mark | states exposure and next state |
| Destructive | neutral surface, coral split, full consequence nearby | requires explicit review gesture |
| Disabled | intact material with cross-pin and reason | remains inspectable; no press or success cue |
| Pending | stable width, progress label, controls locked to operation ID | cannot submit twice |

The touch target is at least `48x48`; primary and destructive actions target
`56` high on touch layouts. Press feedback begins within `50 ms`; confirmed
local feedback begins within `100 ms` of authoritative receipt. Pending state
does not change component dimensions.

### 8.2 Status Rail

The top rail contains only information needed by the current decision:

- Guild: `BIND:RUN_PHASE`, relevant `BIND:RUN_RESOURCES`, readiness, save health;
- Shop: spendable value, refresh status, offer validity;
- Party: capacity binding, validation, selected pressure;
- Battle: objective, playback state, urgent condition, save/snapshot state; and
- Result: outcome receipt and unresolved next transaction.

Each resource has localized name on focus/tap, icon, exact value, recent delta,
and pending/confirmed state. Unknown and zero are visually and semantically
different.

### 8.3 Shop Offer Row

Recruit offer order is: figure or portrait, generated name, profession, trait
benefit/cost, two decision-relevant rolled reads, price, and Inspect. Item offer
order is: object, name, behavior, eligibility/conflict, price, and Inspect.

Rows share stable height per text scale. Selection adds an external contour and
comparison region; it does not push adjacent rows. Sold, expired, unaffordable,
and selected states keep the original stable ID visible.

### 8.4 Recruit Identity

The component has four canonical scales supplied by
`BIND:ART_RECRUIT_PRESENTATION`:

| Scale | Required reads |
|---|---|
| Marker | stable portrait/silhouette, profession emblem, trait seal, condition |
| Roster | generated name, profession, trait tradeoff, readiness, deployed state |
| Planning figure | full silhouette, equipment read, order number, health/condition |
| Battle actor | profession/tool silhouette, target/protection relation, health, urgent status, death/exit |

The generated name and stable ID are text. Profession is never inferred from
color alone. Trait shows exactly one benefit edge and one cost notch before its
expanded mechanical sentence. Survival history uses a small set of sourced
marks and never becomes a fixed personal-story track.

### 8.5 Equipment Row And Comparison

An item row shows object, name, equipment position from `BIND:EQUIPMENT_RULES`,
current wearer, one behavior sentence, eligibility, and relevant sourced delta.
Comparison aligns current and candidate by mechanical field; unchanged fields
remain visible but quiet. Conflicts name the other item or rule.

Apply does not enable until replacement, returned item, invalidated reference,
and reversibility are known. Raw power score, rarity, or price is never the sole
or largest comparison read.

### 8.6 Dismissal And Run Abandonment

Dismiss is a destructive text-and-icon action below routine Recruit actions.
Its state comes from `BIND:DISMISSAL_ELIGIBILITY`, which uses the total live
Recruits across deployed and reserve rather than only the prepared party.

When that total equals one:

- Dismiss retains its stable control dimensions and destructive icon but uses
  the policy-disabled cross-pin state;
- `LOC:DISMISS_LAST_LIVE_RECRUIT` renders beside it with the invariant meaning
  `One member must remain`;
- touch activation on the disabled control announces or expands the reason and
  changes no state;
- controller focus reaches the control, announces action plus disabled reason,
  and does not open a confirmation; and
- `Review run abandonment` is a separate secondary action with its own focus
  stop, route, accessible name, and `OUT-006` destructive review.

The abandonment action is not painted inside the disabled control and does not
target the selected Recruit. `OUT-006` uses a full run-level consequence sheet,
default focus on Cancel, a run identifier rather than a Recruit identifier, and
one explicit `Abandon run` confirmation. No dismissal-rebate read appears in
that review.

If `REC-003` becomes stale and commit-time eligibility reports one live
Recruit, the sheet closes without a success transition. Recruit Detail keeps
the Recruit visible, returns focus to disabled Dismiss, announces `One member
must remain`, and shows a neutral zero-delta receipt: no Recruit removed, no
equipment moved, no rebate granted. This rejection uses no success color,
ownership motion, or transaction sound.

At 130% on a short landscape phone, Dismiss, its two-line reason, and the
separate abandonment action occupy three stable rows. They do not overlap the
Recruit name, Back, or safe-area inset. The Simplified Chinese (`zh_CN`) fixture
may wrap each label to two lines without merging the two actions.

### 8.7 Party-Line Editor

One horizontal cord runs from `First exposed` at left to `Last` at right. Every
prepared recruit occupies a stable numbered marker joined to that cord. The
component renders the count from `BIND:PARTY_CAPACITY`; it never labels an
assumed maximum.

Each marker has a fixed aspect ratio and minimum size. At dense target widths,
all order markers remain visible while the selected recruit expands into the
context rail; nonselected figures use simplified but distinct silhouettes. If
future sourced capacity cannot fit at minimum size, the cord scrolls by whole
positions with sticky First/Last indicators and a full miniature order strip.

Selecting a recruit then a destination previews only sourced changes:

- expected exposure and likely targets;
- protection given or received;
- reach and healing access;
- movement behavior; and
- replacement behavior after death or exit.

Changed relations draw direct shaped connectors above the cord and list the
same changes in text. Undo and Reset are familiar icon controls with tooltips.
Drag is optional; tap-select/tap-destination and controller move are complete.

### 8.8 Active Artifact Ledger

Artifacts are presented as run-wide rule modifiers, never as equipment attached
to a recruit. Each ledger row shows sourced emblem, name, changed rule,
acquisition receipt, active/inactive state, interactions, conflicts, and
lifecycle from `BIND:ARTIFACT_RULES`. Inspect uses the same vocabulary in Shop,
Reward, Guild, Battle, Result, and Records. Missing rules block dependent
commitment instead of reducing an artifact to rarity or flavor.

### 8.9 Risk Choice

Risk options are aligned by known pressure, uncertainty, entry cost, reward
class, recovery exposure, and current coverage. Options use different threat
silhouettes and comparison rows rather than promotional art or rarity frames.

The selected option expands in place. The commitment surface remains attached
to it and displays the accepted party snapshot. Unknown information is a
sourced uncertainty state, not an empty value or hidden tooltip.

### 8.10 Battle Actor And Event Projection

The battlefield owns at least `68%` of usable area. Party and enemy actors
occupy one readable horizontal encounter space with depth offsets and authored
staging from media bindings. Order remains legible through numbered ground
marks and target/protection connectors; the planning cord itself is not drawn
as a large HUD over combat.

Actor-attached information is limited to:

- health or other sourced survival state;
- urgent status icon and short label;
- current target relation when relevant; and
- order marker for allied recruits.

Only the greatest immediate danger expands automatically. Other values remain
compact and are available through Inspect. Event projections originate at the
acting subject, name affected targets, include time/order, and keep actors
visible.

### 8.11 Playback And Inspect Tools

Pause, play, speed, and inspect use symbol-first controls with tooltips and
accessible labels. Speed is a segmented symbol control populated by
`BIND:BATTLE_SPEEDS`; changing it never looks like a combat action. Retreat is
inside Pause and separated from Resume by layout and review.

Inspect freezes or preserves playback according to sourced rules and opens:

1. selected event and source;
2. target and order reason;
3. equipment, profession, trait, or status contribution;
4. immediately preceding cause; and
5. downstream event when already known.

On short phones or at 130%, this becomes a full-screen linear view. Closing it
restores the exact prior playback state.

### 8.12 Causal Timeline

Result uses a two-track timeline: expected responsibilities from the accepted
party snapshot above, actual events below. The first meaningful divergence has
the strongest contour and direct connectors to affected recruits, enemy event,
equipment, and order relation. Totals and rankings are secondary.

Every event has a stable icon, timestamp/order, source, target, outcome, and
accessible text. `Cause unavailable` is an error state. A neutral result may
state that no preventable divergence was detected.

### 8.13 Death And Party Gap

Loss presentation is quiet and explicit. The affected recruit remains visible
at a respectful readable scale with generated name, stable ID, profession,
trait, level, survival marks, equipment disposition, and committed receipt.
The adjacent party cord shows the new gap and sourced replacement behavior.

The Acknowledge action does not suggest reversal. Recovery and replacement are
separate next decisions supplied by their bindings. No celebratory particles,
rarity framing, or generic red overlay accompanies death.

### 8.14 Reward Choice

Rewards appear as actual object, profession, recruit, or rule presentations
supplied by content and media bindings. Equal-size decision regions prevent
object scale from implying value. Each option names:

- the next decision it changes;
- current eligible target or party interaction;
- conflict or opportunity cost;
- claim destination; and
- skip outcome when legal.

Claim animation begins only after receipt. The final state is a persistent
named ownership change, not particles alone.

### 8.15 Recovery Choice

Recovery options are unframed paths leaving the causal result: reconfigure,
replace, restore, or end the run only when supplied by `BIND:RECOVERY_OPTIONS`.
Each shows full cost, retained state, recruits affected, and next destination.
Unavailable paths remain inspectable with reason.

### 8.16 Empty, Error, Notice, And Receipt

| Component | Required content | Forbidden behavior |
|---|---|---|
| Empty state | what is empty, why, legal next action | decorative illustration with no action |
| Loading state | named operation, blocked scope, progress when known | generic spinner over active controls |
| Inline error | plain cause, retained state, retry/alternate | raw internal exception or vanished content |
| Binding error | binding name in diagnostics, player-facing affected feature, safe exit | invented zero/default value |
| Notice | one changed fact and optional Inspect | stacking duplicate transient messages |
| Receipt | stable operation, committed result, timestamp/order, duplicate behavior | success feedback before authority confirms |
| Confirmation | target, before, after, cost, risk, undo policy | vague `Are you sure?` alone |

Notices reserve layout space or overlay noncritical world space. They never
cover the primary action, Back, playback tools, target projection, or focus.

## 9. Canonical Layout Families

### 9.1 Title And Run Screens: `SYS-003..007`

- Full-bleed working guild threshold; the product name occupies no more than
  one fifth of frame height.
- Continue and verified run summary sit together at lower-left on clear ground.
- Run ledger uses one unframed vertical list and one details rail.
- Accessibility, Settings, and run selection are compact tools, always visible.
- Save recovery uses an aligned lineage comparison, not competing alert cards.

### 9.2 Guild Desk And Forecast: `HUB-001/002`

- Current pressure is represented in the world and repeated in concise text.
- Shop, Roster, Equipment, Party Line, and Risk are stable edge destinations.
- The prepared party occupies a shallow muster strip that reflects current
  profession, condition, equipment, and order.
- Latest result change uses one attached receipt strip and disappears only after
  inspection, not on a timer.

### 9.3 Shop And Recruit: `SHP-001..003`

- Left/main: scrollable offer rows on a physical requisition surface.
- Right/context: selected offer at planning scale with tradeoff, fit, and cost.
- Filters are icon+text tools; option sets use menus, not clouds of rounded text.
- Refresh is visually secondary and always displays sourced consequence.
- Recruit and Buy actions appear only inside their review state.

### 9.4 Roster And Recruit Detail: `REC-001..003`

- Roster uses a muster wall or line of markers plus one selected planning figure.
- Filters prioritize deployed state, profession, trait, readiness, and condition.
- Detail organizes Identity, Mechanics, Equipment, Position, and History as tabs
  or a compact category rail; no biography-first hero page.
- Dismissal is isolated below routine preparation actions. At one total live
  Recruit it stays visible, policy-disabled, and paired with `One member must
  remain`; a separate secondary action opens `OUT-006`.
- A stale final-survivor confirmation closes back to Recruit Detail with no
  ownership motion, rebate cue, or success state.

### 9.5 Equipment: `EQP-001/002`

- Selected recruit remains visible; eligible inventory forms one scroll track.
- Current and candidate objects align around the recruit, not inside nested
  panels.
- Behavior delta is the first comparison read; eligibility and conflicts are
  adjacent to Apply.
- At 130% on phone, item list and comparison become two explicit views with a
  persistent selected-item summary.
- `ART-001` uses a separate full-width shared-rule ledger; it never reuses the
  per-recruit equipment silhouette or Apply flow.

### 9.6 Party Line And Readiness: `PTY-001/002`

- The ordered cord spans the main surface with clear First and Last endpoints.
- Available recruits use a lower muster strip; selected recruit expands in the
  context rail without changing marker positions.
- Relation connectors use distinct patterns and remain under a text summary.
- Readiness replaces editing with a frozen party snapshot and grouped warnings.
- Save Order is the only primary action; undo/reset are icon tools.

### 9.7 Risk Board: `RSK-001/002`

- Choices occupy distinct parts of a region scene and align to one comparison
  band below.
- The band compares known threat, uncertainty, cost, reward class, recovery
  exposure, and coverage in that order.
- Commitment slides from the selected option and keeps party snapshot visible.

### 9.8 Battle: `BAT-001..006`

- Actors and event projections dominate the scene; UI follows edges.
- Objective and next urgent event sit top-left; pause/speed/inspect sit top-right.
- Actor markers attach to subjects and collapse when not urgent.
- Inspect uses the context rail or a full-screen linear surface at 130%/phone.
- Retreat exists only inside Pause and uses a separated destructive review.
- Resume Review is static: verified timestamp, speed, pending event, and Resume.

### 9.9 Result And Recovery: `OUT-001..006`

- Causal timeline owns the center; outcome and unresolved transaction remain in
  a compact top strip.
- Affected recruits remain visible beside the event that changed them.
- Death review isolates one loss at a time with a persistent multi-loss index.
- Reward objects or rules use equal decision regions under the diagnosis.
- Recovery paths are distinct exits with complete transactions, not three
  decorative cards.
- Run abandonment is a separate run-level sheet invoked from Guild desk or
  Result; it never reuses a Recruit dismissal sheet or selected-Recruit art.

### 9.10 Progression, Records, And Postgame: `PRO-001..PST-003`

- Progression emphasizes the decision each unlock opens and its prerequisite,
  not a giant ornamental branching illustration.
- Records use one category rail, one entry list, and one large detail subject.
- Unknown content differentiates not encountered, partially known, and
  deliberately undisclosed.
- Postgame setup keeps active modifiers, eligibility, slot, and ordinary New Run
  access visible before commitment.

### 9.11 Settings: `SET-001..009`

- Settings is a quiet unframed workspace with category navigation and a live
  preview where useful.
- Binary values use switches or checkboxes; small mutually exclusive sets use a
  segmented control; larger option sets use menus; numbers use sliders with
  displayed values; remapping uses dedicated input rows.
- Reset and deletion sit at the bottom of their own category, separated from
  routine controls.
- Caller and Back destination remain visible: Title, Guild, or paused Battle.

## 10. Interaction And Focus

### 10.1 Focus Order

Focus begins at screen heading, then the current state summary, primary content,
context rail, primary action, and secondary tools. The primary action is not
automatically focused after a destructive warning. Modal focus begins on
Cancel. Focus never follows moving actors or animation.

Controller focus uses a `3 px` white outer and `2 px` ink inner contour plus a
small cobalt corner mark. Touch selection uses the same contour and a selected
label. Pointer hover may preview focus but cannot reveal unique content.

A policy-disabled destructive control remains focusable so its reason is
readable. It is skipped only after the same reason has been announced by an
adjacent required notice. Focus order never treats the separate abandonment
action as activation of disabled Dismiss. After a stale dismissal rejection,
focus returns to Dismiss, announces the zero-delta reason once, then moves to
the separate abandonment action on the player's next navigation input.

### 10.2 Ordering And Selection

- Selection and commitment are separate states.
- All drag operations have tap-select/tap-destination and controller paths.
- Reorder controls preserve stable IDs and announce old/new positions.
- Lists retain focus through sort/filter when the stable ID remains visible;
  otherwise focus moves to Clear Filters or the first result with an
  announcement.
- Double tap/press is not required for any essential action.

### 10.3 Feedback And Haptics

Visual feedback always carries meaning without audio or vibration. Haptics, when
available and enabled, distinguish focus movement, legal selection, confirmed
receipt, and blocked action. They never announce battle information that lacks
a visual and text equivalent.

## 11. Motion, Effects, And Low Power

Motion communicates source, direction, urgency, commitment, and final state.
Layout dimensions do not animate.

| Event | Normal | Reduced motion | Reduced flashes | Low power |
|---|---|---|---|---|
| Select | `90 ms` edge lift and contour | instant contour and marker | unchanged geometry, no luminance spike | final selected state only |
| Recruit/equip receipt | source travels to roster/wearer, then stamped receipt | direct crossfade to final state plus receipt | no bright burst | final state and receipt only |
| Reorder | marker follows cord, relation connectors redraw | immediate position swap with numbered before/after | no flash | immediate final order |
| Risk commit | selected path tightens and scene advances | final selected route plus direction arrow | solid edge instead of pulse | static committed state |
| Event warning | authored anticipation and target projection | stepped poses and persistent geometry | capped luminance; no full-screen white | essential source/target frames only |
| Impact | short response and exact value/status change | no shake or hit pause | contour/value change; reduced particles | final actor state and event row |
| Death | readable exit followed by stable loss marker | direct final pose/marker | no fade-to-white | final pose/marker |
| Reward | ownership path then receipt | direct placement and receipt | no sparkle burst | receipt plus final placement |

Reduced motion removes camera travel, parallax, continuous UI motion, and
nonessential ambient loops. Reduced flashes removes full-screen flashes,
alternating high-contrast frames, and rapid particle bursts. Low power lowers
ambient update frequency, effect density, and nonessential layer animation; it
does not change event order, timing rules, target clarity, decisions, or
receipts.

Only one nonessential ambient focal process and two background loops run on a
short phone. They freeze under overlays and never resemble event warnings.

## 12. Audio-Independent And Visual Accessibility

- Master mute changes no mechanic, event order, target visibility, transaction,
  or available decision.
- Captions name event, source, direction, and outcome using
  `BIND:AUDIO_EVENT_CATALOG`; environmental captions remain visually quieter
  than dangerous battle events.
- Output loss raises one nonblocking notice and keeps captions plus event
  geometry active.
- Mono compatibility is verified by ensuring no necessary cue depends on stereo
  position alone.
- Color-independent patterns distinguish safe, harmful, uncertain, selected,
  disabled, and complete.
- High contrast simplifies region textures behind labels and actors without
  replacing region identity.
- Screen-reader order follows the focus order. Party positions are announced as
  `position [index], [name], [profession], [condition]`; battle events announce
  source, action, target, outcome, and time/order.
- A pauseable full-screen event log provides all urgent automatic battle
  information in chronological text.
- Controls retain at least `48x48` targets at every scale and do not overlap
  device insets, captions, notices, or each other.
- `LOC:DISMISS_LAST_LIVE_RECRUIT` and
  `LOC:OPEN_RUN_ABANDONMENT_REVIEW` are tested in English (`en`) and Simplified
  Chinese (`zh_CN`) at 100/115/130%. The first communicates the one-member
  requirement; the second communicates voluntary closure of the whole run.

## 13. State Grammar

Every reusable actionable component implements these semantics consistently:

| State | Visual/text contract | Input result |
|---|---|---|
| Available | full subject, action verb, sourced cost/effect | opens inspect/review or commits only where explicitly allowed |
| Focused | double contour, corner marker, complete accessible name | first activation selects or invokes the stated tool |
| Selected | raised edge/check, selected label, stable dimensions | enables review; activation alone does not spend |
| Pending | operation name and progress, unchanged geometry | duplicate input ignored; Cancel only if source allows |
| Active | active label and persistent state marker | inspectable; does not restart |
| Unaffordable | current and required values plus shortfall | inspectable; commit disabled |
| Incompatible | conflicting stable subject/rule and correction path | inspectable; commit disabled |
| Policy-disabled | intact control, cross-pin, visible rule, separate legal alternative | activation announces reason only; alternative has its own focus and action |
| Locked | named prerequisite and where to meet it | opens requirement when legal |
| Temporarily unavailable | reason and restoring event | inspectable; no success feedback |
| Complete | named result and receipt mark | opens result; cannot claim again |
| Recoverable error | plain cause, retained state, Retry/Alternate | retries with operation identity |
| Blocking error | affected binding/integrity boundary and safe exit | cannot continue dependent workflow |

State words in localized copy must remain semantically distinct. Disabled
opacity alone is insufficient, and disabled text still meets contrast targets.

## 14. Design Tokens And Handoff

```text
space: 4, 8, 12, 16, 24, 32, 48, 64
radius: 0, 4, 8
control_min: 48
touch_primary_min: 56
stroke: 1, 2, 3
safe_phone: 56x40 + device insets
safe_tablet: 64 + device insets
safe_reference: 96
context_rail: 360, 420, 520
motion_select: 90ms
motion_commit: 180ms
motion_receipt: 360ms
focus_outer: 3px white
focus_inner: 2px ink
text_scale: 100%, 115%, 130%
```

The later prototype and runtime theme must declare stable component IDs, screen
IDs, localized strings, semantic tokens, focus order, icon IDs, operation IDs,
and binding references in structured data. Screen-specific styling may select a
region material but may not redefine state, color semantics, transaction rules,
focus, or accessibility behavior.

Every gallery frame must record:

- screen ID and state;
- viewport and safe-area fixture;
- language and text scale;
- input mode and focus target;
- motion, flash, audio, contrast, and power settings;
- resolved and intentionally unresolved bindings; and
- source revision plus whether the frame is static or interactive.

## 15. Presentation Acceptance Checklist

- [ ] The actual shop, recruit, equipment, artifact, party, risk, battle, result, death,
      reward, recovery, progression, Settings, and postgame decisions dominate
      their pages.
- [ ] Generated recruits remain replaceable run participants and still read as
      distinct mechanical identities at roster, planning, and battle scales.
- [ ] At one total live Recruit across deployed and reserve, Dismiss is visible
      and disabled with `One member must remain`; explicit abandonment is a
      separate run-level action and review.
- [ ] A stale final-survivor dismissal confirmation closes with no Recruit or
      equipment mutation, no rebate, a readable reason, and deterministic focus.
- [ ] The ordered party is immediately readable from First to Last on landscape
      phone and tablet without moving controls or shrinking labels below tokens.
- [ ] Automatic battle prioritizes urgent cause, affected actors, objective,
      playback state, and inspect; no control implies insertion of an attack or
      skill into the timeline.
- [ ] Result names the earliest meaningful divergence before totals or rewards.
- [ ] Every action exposes state, target, cost, consequence, reversibility,
      pending state, receipt, and safe return where applicable.
- [ ] Every screen remains functional at required phone/tablet fixtures,
      English, Simplified Chinese, and 130% text/UI scale.
- [ ] Touch, controller, and keyboard/mouse support the same complete verbs; no
      essential action depends on drag, hover, double tap, or pointer precision.
- [ ] English, Simplified Chinese, and 130% fixtures keep disabled Dismiss, its
      reason, and the separate abandonment action visible without overlap.
- [ ] Reduced motion, reduced flashes, mute/captions, high contrast, screen
      reader order, and low power preserve decisions and causal information.
- [ ] Cards remain limited to repeated items and reviews; world/actors are the
      primary surface and components do not nest decorative containers.
- [ ] Gameplay values and media identities remain sourced bindings until their
      owning authorities integrate them.
- [ ] No design fixture is described as implementation, final media, device,
      comprehension, fun, packaging, store, or release acceptance.