Files
aetherbound-guild/docs/presentation/UI_AND_VISUAL_SYSTEM.md
T

911 lines
50 KiB
Markdown

# 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 |
| New run setup | four equally weighted provisional Recruit offers | selected `0/2..2/2` and comparison | Review Company then Create Run | consequential choice without a recommended build |
| 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 | protected rear-left through numbered positions to exposed front-right | 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 |
| New run setup | four stable provisional identities, Profession job, Trait benefit/cost, selected count | individual level, one starting item, rolled distribution, Contract/difficulty | unrelated catalog and future progression |
| Shop | offer behavior, price, immediate fit | future eligibility and refresh consequence | full discovery provenance |
| Recruit review | profession responsibility, trait benefit/cost, rolled constraint | individual level/XP, one current item, 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.
The first-Market variant marks at least two sourced base-Profession Recruit
offers as affordable without marking either `recommended`. A persistent opening
status reads owned Company separately from Line capacity and updates only from
authoritative hire receipts: `Company 2 | Line capacity 4`, `Company 3 | Line
capacity 4`, then `Company 4 | Line capacity 4`. Each hire keeps its own review,
cost, receipt, and focus return; no combined `Hire two` action exists.
### 8.4 Provisional Recruit Selector
`SYS-005` uses a dedicated provisional variant, not the Shop offer row. It
renders exactly four stable positions from `BIND:PROVISIONAL_RECRUIT_OFFERS` and
never shows price, refresh, lock, rarity promotion, or purchase language.
Each overview marker has stable dimensions and contains:
- generated name and stable offer ID;
- Recruit figure/portrait at the common marker scale;
- base Profession icon, localized job sentence, and target/reach read;
- Trait seal with one benefit and one cost;
- one decision-relevant rolled distribution read;
- `No Coin cost`;
- a Select checkbox with a checkmark that does not imply Party-line order; and
- a separate Inspect icon with accessible label.
Touch activation on Select toggles Company selection; tapping the marker only
focuses it and opens no destructive state. Controller focus enters offers in
stable source order; Select toggles the focused offer, while Inspect opens and
closes its full details without changing selection. Compare is a separate
command: it pins offer `A`, then offer `B`, and opens an aligned Profession,
Trait, attribute, individual level, and one-starting-item comparison. The A/B
pair may use any two
offer IDs and never changes the two Company checkboxes.
The selected-count component has fixed dimensions and explicit states:
| State | Label and control state | Result |
|---|---|---|
| none | `Choose two - 0/2`; Review Company disabled | Inspect, Compare, Back, and first selection remain legal |
| one | `Choose one more - 1/2`; one stable ID checked | selecting a second enables review |
| two | `Company selected - 2/2`; both stable IDs checked; Review Company enabled | either selection may be cleared or replaced before review |
| third attempt | `Two already selected`; current two remain unchanged | focus moves to the selected-count explanation; no automatic eviction |
| invalid source | expected four/received count or affected stable ID; all Select controls disabled | Retry Same Set or Return to Run Ledger |
| loading | four fixed skeleton positions, named operation, no identity or selection | resolved stable ID stays in its original position |
Review replaces details without discarding the four-offer strip. The selected
two occupy the main Company comparison; the two unchosen stable IDs remain in a
quiet `Not retained` summary. `Revise Recruits` returns to the same four
positions, selected IDs, A/B comparison, and focus. Create Run is the only
primary action and enters a fixed-size pending state, so a spinner or long
localized status cannot shift Revise, Cancel, or offer markers.
On a short landscape phone, the four markers form a fixed `2 x 2` layout; the
selected marker's details replace the context rail. On tablet/reference they
form one four-marker row above one comparison region. At 130%, generated names
may wrap to two lines and the Profession/Trait text moves to Inspect, but all
four identities, checked state, `0/2..2/2`, Select, Inspect, Compare, Back, and
Review Company remain visible. English (`en`) and Simplified Chinese (`zh_CN`)
share offer order and control geometry.
No offer starts selected, pulses as preferred, receives a larger portrait,
sorts by a hidden score, or gains a tutorial arrow. Teaching may highlight the
Select and Inspect controls as a group, never one Recruit.
### 8.5 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, level, condition |
| Roster | generated name, profession, level, one-item state, trait tradeoff, readiness, deployed state |
| Planning figure | full silhouette, level, one equipped-item 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.6 Equipment Row And Comparison
An item row shows object, name, form from `BIND:EQUIPMENT_RULES`, current wearer,
one behavior sentence, eligibility, and relevant sourced delta. Every Recruit
has one universal slot; form does not create another slot. Comparison aligns
current and candidate by mechanical field; unchanged fields remain visible but
quiet. Conflicts name the wearer, Profession, position or shared rule.
Apply does not enable until the one-slot replacement, returned prior item or
null, invalidated reference, and reversibility are known. Raw power score,
rarity, or price is never the sole or largest comparison read.
### 8.7 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.8 Party-Line Editor
One horizontal cord runs from `Protected rear` at left to `Exposed front` at
right. The rightmost occupied marker is authoritative position `0`; larger
position numbers extend leftward toward the rear. Every prepared Recruit
occupies a stable numbered marker joined to that cord. The component renders
the count from `BIND:PARTY_CAPACITY`; it never labels capacity as owned Company.
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 Rear/Front indicators, position `0` pinned at the right
edge indicator, 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.
Protection connectors point from the protected Recruit toward contributing
actors ahead of it on the right. Front and rear use icon, localized text, edge
shape, and position number; color or reading direction alone is insufficient.
English, Simplified Chinese, touch, controller, and screen-reader fixtures keep
the same spatial orientation rather than mirroring the line by locale or input.
### 8.9 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.10 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.11 Battle Actor And Event Projection
The battlefield owns at least `68%` of usable area. Player actors stage from
protected rear at left to exposed position `0` front at right and face the
enemy across the central action gap. Enemy staging faces toward that front.
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.12 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.13 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.14 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.15 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.16 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.17 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.
- `SYS-005` begins with Contract/difficulty review, then gives the main surface
to four equally weighted provisional Recruit markers and a stable `0/2..2/2`
selection status. Inspect/Compare uses the context region; Review Company is
the only primary action after `2/2`.
- The creation review keeps the four-offer strip, expands the selected two,
labels the unchosen two `Not retained`, and separates `Revise Recruits` from
Create Run. Pending/error states cannot rearrange or replace offer IDs.
### 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.
- The first-Market variant keeps Company count and Line capacity separate and
exposes two individual affordable-hire reviews; no visual treatment chooses
either base-Profession offer for the player.
- 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 from protected Rear at left to
exposed Front at right. Position `0` is the rightmost front; larger position
numbers extend left toward the rear.
- Available recruits use a lower muster strip; selected recruit expands in the
context rail without changing marker positions.
- Protection/target/reach connectors use distinct patterns, name their numbered
endpoints, 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`
- Player actors stage rear-left to front-right, with position `0` and the enemy-
facing action gap at the right; actors and event projections dominate the
scene while 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.
In `SYS-005`, focus enters Contract/difficulty, then the four offers in stable
source order, selected count, Compare, Review Company, and Back. Inspect returns
to the invoking offer; comparison returns to its last pinned offer; Revise
returns to the first selected offer still present. Offer focus order never
changes because of selection, generated-name length, loading completion, or a
tutorial highlight.
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.
- Provisional Company checkboxes, A/B comparison pins, and Create Run are three
separate state machines; changing one never silently changes another.
- All drag operations have tap-select/tap-destination and controller paths.
- Reorder controls preserve stable IDs and announce old/new numbered positions,
front/rear meaning, and movement left/rear or right/front.
- 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], [front/rear meaning], [name], [profession], [condition]`;
position `0` is announced as exposed front/right and larger positions as
progressively rear/left. Battle events announce source, action, target,
outcome, and time/order.
- `SYS-005` announces `four offers`, the current checked count, each offer's
stable position and checked state, Profession job, Trait benefit/cost,
no-Coin cost, Compare A/B state, and whether Review Company is available.
- 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.
- [ ] `SYS-005` visibly holds four unique stable provisional offers, separate
Inspect/Compare/Select controls, exactly-two gating, review/revision,
no-Coin and unchosen-not-retained consequences, complete invalid/loading/
error/interruption states, and no tutorial-selected build.
- [ ] The `0:00-3:00` path commits one choose-two run creation and then two
separate affordable first-Market hires, ending at Company/Line capacity
labels `Company 4 | Line capacity 4` without combining purchases or
preselecting an offer.
- [ ] 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 protected rear at left to
exposed position `0` front at right on landscape phone and tablet; larger
numbers extend left and protection contributors remain explicit.
- [ ] 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.