Verbatim from workflow wf_d0ca605f-891. Each finding carries either its own register entry id or
the cross-lane merge that absorbed it. This file is the evidence of record the compact register
entries cite.
ui-ux#1 [CRITICAL] merged into GAP-144 - No SCREEN bill of materials — the ruled build-agency, ledger and vendor screens have an owner named in doctrine and no item anywhere
Vision rules. COMBAT_PROGRAM_ADDENDUM.md §9 (RULED Josh 2026-07-26) explicitly assigns the owner: "OWNER: the canon-lane schema pass (the residue batch) + the post-slice runtime + W10's book screens (the build/loadout UI) + the factory" — for SELECTABLE minor/major bonus picks, 2nd/3rd LOADOUT SETS quick-changed at vril sites, SPEC PURPOSES, and companion loadout parity. §10 extends selectable pools to "EVERY skill, trait, weapon, trade, and any proficiency". §2b makes the RUNE FORGE "the player-facing ability creator". OPEN_BRIEFS_2026-07-28.md §7 D-ECONOMY-MEDIUM was RULED option (b) — "ONE presentation-only trade-value lens in the ledger UI" — unblocking EC-medium/EC-vendor. PRE_5090_BUILD_PLAN.md P2.6 admits its own spec hole: "*(Equip/stash/weight SPEC is a Josh gap.)*"
What exists (verified). PRE_5090_BUILD_PLAN_VOL2.md §11 itemises exactly 32 UI items (U11.1–U11.32, verified by id enumeration), of which 13 are screens: front-end U11.6, pause/options U11.5, ability book U11.14, quest log U11.16, fork U11.17, journal U11.18, Grimoire U11.19, screens shell U11.20, map U11.21, travel-beat U11.22, dialogue/subtitle U11.23, photo/codex U11.25, loading U11.26. POSITIVE CONTROL: awk over VOL2 lines 680-830 for inventory|equip|loadout|rune|craft|forge|imprint|bonus|vendor|shop|minigame returns ZERO, while the same terms grep non-zero elsewhere in the same file (rune/loadout at L871-874, L1507; inventory at L105/L1068/L1090) — so the search can match and the UI section genuinely contains none. VOL1 L314's own W7 fold list named "quest-log/map/inventory/ability-book UMG"; VOL2's fold table (L794-807) maps UI-1..10 → U11.1–U11.4 + U11.14–U11.20, dropping inventory in the fold
Delta. ≈13 ruled player-facing screens have no build item and no owner: inventory/equipment, character sheet + the 12×10=120-gate mastery ladder, loadout manager (2/3 sets at vril sites), the Rune Forge creator, gear-imprint crafting, per-proficiency bonus selection, familiar roster (22 rows) + companion stat-build (INT-as-AI), reputation ladder, vendor/barter + the ruled ledger UI, personal dimension (T1_Personal_Dimension_Spec is a 48-byte stub), vehicles/base building, achievements + Games-Master medals, festival calendar. Doctrine points AT W10; W10's itemisation does not contain them. There is no screen roster, no per-screen IA, and no denominator to measure completeness against
Blocking. Every §§7-12 schema-freeze rank (window ranks 13-17, esp. rank 14 "mint the §§7-12 data homes: tier-bonus pools, imprints, loadout sets, role tags, ally stat spreads") freezes columns with no consuming screen specified — the same both-ends failure that produced the P2.6 spec hole. Hits the moment rank 14 starts; retrofitting screen IA after 30+ columns freeze costs a second schema pass
Proposed home. A new VOL2 §11i SCREEN ROSTER table (one row per screen: ruled source, data reads, reveal filter, controller-nav path, wave) authored as part of window rank 20's T1_UI_UX_Spec, with a factory_contract rider so gate 30 R2/R3 resolves each screen's data_home and consumption point
ui-ux#2 [CRITICAL] merged into GAP-144 - Iconography bill of materials has no id source, no count, and no producing pipeline
Vision rules. ASSET_DROPIN_CONTRACT.md §2 declares HUD art as the 11th asset class and requires every class to carry a "Canon id source (registry.column)". PRE_5090_BUILD_PLAN_VOL2.md §11 tag law: "The only gated residue here is final HUD/icon art (+5090-final)" and U11.14 is tagged "BUILD-NOW (+5090-final icons)" — so icons are a declared, scheduled 5090 workload. ROADMAP_POST_5090_TO_SHIP.md P2.6 makes HUD art a phase-exit surface at the AAA reference bar
What exists (verified). ASSET_DROPIN_CONTRACT.md L81: the HUD-art row's id source is the prose "UMG widget binding (authored, not generated)" — no registry.column — and §2's closing note marks it generation_status N/A, so it rides none of the five-state generation machine that the other nine classes ride. POSITIVE CONTROL on the data home: a header scan of all 62 registry CSVs for ^icon|icon$|_icon|sprite|thumbnail|ui_|portrait|hud returns exactly ONE column — T0_Status_Table.icon_class (10 rows) — while the same scan prints the full Status_Table header, proving the scan reads headers. POSITIVE CONTROL on the pipeline: grep -ci icon across all six docs/translation/T99_Translation_*.md returns 0,0,0,0,0,0 while grep -i icon over docs/*.md returns 20+ hits — the search works; no pipeline contract mentions icons
Delta. The countable icon BOM is ~542 distinct icons from live rows alone (Ability 185 + Weapon 72 + Creature 150 + Familiar 22 + Rune 19 + Rarity 13 + Flora 25 + Mineral 19 + Trade 10 + Status 10 + Imprint 5 + Bonus_Option 12), plus per-platform input glyph sets, and NONE of it is counted, id-columned, or assigned a producing lane. Status_Table.icon_class is the mirror defect: the one icon column that exists has no consumer (no icon asset class resolves it, no widget reads it). The only tooth is QA-12, which AI_QA_LOOP_ARCHITECTURE.md §335 defines as a human/critic "polish-wave protocol", not a coverage denominator
Blocking. The 5090 generative window: icons are tagged as a 5090 workload with no prompt-composable id list, so the box arrives with no icon work order — the same posture that left DR-2's per-tier VFX variants needing an emergency sizing pass (248 live/372 clamp). Also blocks rank 13 (ability registry data pass) which is the natural place to add icon_id_ref for 185 rows at near-zero marginal cost
Proposed home. An icon_id_ref column minted on the ability/weapon/status/rune/rarity/trade/creature/flora/mineral registries inside window ranks 13-14, plus a 12th ASSET_DROPIN_CONTRACT row (2D UI/icon class) with a real id source and a /Game/UI/Icons/<class>/T_<icon_id> drop path, and an icon count in the DR-2 variant arithmetic
ui-ux#3 [CRITICAL] merged into GAP-144 - The binding localization law is 100% unimplemented on every player surface and has zero teeth; the game's shipped-language ring is unruled
Vision rules. The localization-from-the-first-string law is binding and repeatedly cited: PRE_5090_BUILD_PLAN.md P2.5 "Route every HUD/interaction/quest string through a String Table from the first widget"; REGISTRY_ROW_STRUCT_SPEC row in DOC_MAP L520 makes FText the display-text type by law; BUILD_PLAN_END_TO_END.md L149/L169 records that FText "is legally load-bearing (ship-everywhere localization) and cannot be cheaply retrofitted once content references the strings". ROADMAP_POST_5090_TO_SHIP.md L302 rests the launch localization tier on that floor: "every player-facing string in a String Table from the first widget"
What exists (verified). POSITIVE CONTROL, game tree C:\dev\Humanity\Humanity\Source: grep -rn "LOCTEXT|NSLOCTEXT|FStringTable|LOCTABLE" = 0 hits, while grep -rn FText = 139 and grep -rn "FText::FromString" = 41 — the search matches, and every player string is a hardcoded literal (HumanityPlayerHUDWidget.cpp:404 "The way ahead is clear.", :417, :432, :612, :623, :644). No Content/Localization directory exists (ls returns nothing while Content/ lists 9 siblings); zero StringTable assets among 309 .uassets (the single ST_ hit, Combat/ST_BossPhases_Greybox, is a StateTree). No localization/culture lines in Config/*.ini. Teeth: harness/gates_config.json carries 34 gates and none is loc/string/UI-named (full roster enumerated). The game's only UI tooth, HumanityUIAutomationTests.cpp "Humanity.UI.RevealTable", ENSHRINES the literals — lines 82-83 list "Press 1, 2 or 3 to choose your path." and "Press F to continue." in its MustPass list. Language ring: MARKETING_WEB_PROGRAM.md §4 rules an i18n language ring for the SITE; ROADMAP_POST_5090_TO_SHIP.md L298 defers only spoken-VO tiering; no doc names the game's shipped text locales
Delta. A law with a named, documented, uncheap retrofit cost has (a) zero compliance on the one shipped surface, (b) zero deterministic tooth in either tree, and (c) an automated test that positively blesses the violating strings. U11.24/P2.5 are queued for the RUNTIME (RTL fonts, UI scale, subtitle standards) and the scaffold, but nothing is queued that FAILS a build when a widget string is a FromString literal, and no brief asks Josh which locales the game ships
Blocking. Every U11 widget item (U11.1-U11.26) — each one authored now adds literals to a corpus the plan says cannot be cheaply retrofitted. It is already biting: W10 shipped 41 violations and the ledger's own residue list (VOL1 L2511 "the STRINGTABLE localization rung") has carried it since 2026-07-24d without a rank
Proposed home. A gate-35 player_string_loc tooth (fails on FText::FromString / TEXT() literal reaching any UMG SetText call, with must-fire/must-not-fire fixtures on the gates_config PASS-on-empty pattern) landed in the same commit as U11.1's UMG framework; the shipped-locale ring added to the next bundled Josh brief (window rank 18)
ui-ux#4 [MAJOR] GAP-145 - Attunements is ratified accessibility canon with no enumerated option roster, no data home, and no tooth on its one non-negotiable requirement
Vision rules. BATCH1_RULINGS.md §4 "Difficulty & accessibility — RATIFIED (architecture + all held items)" — Josh agreed all six smaller items including "colorblind vril-polarity multi-channel readability as an L1 requirement"; "Accessibility = Attunements (always-available, judgment-free)". COMBAT_ENCOUNTER_SYSTEM.md §247 and §415 both state "Vril-polarity multi-channel readability is a non-negotiable L1-playability requirement". PRE_5090_BUILD_PLAN.md §12 #26 names "accessibility breadth (subtitle formatting, UI scaling, remap breadth)" as a spec with "None exist as specs today"
What exists (verified). The entire ratified layer is 11 lines of prose: docs/proposals/DIFFICULTY_SYSTEM.md L82-92 names five option FAMILIES (colorblind/multi-channel readability, timing windows, input remaps, camera and motion options) and enumerates ZERO individual options. DECISION_DOSSIER.md §4 apply-action (5) directed it, back on 2026-07-03, to "land the multi-channel ... polarity-readability requirement as the first real spec item in T1_UI_UX_Spec [DRAFT v0.1] (currently an empty stub)" — that file is still 35 bytes on disk today (ls -la of _source/01_Tier_1_Foundation). POSITIVE CONTROL on the tooth: the 34-gate roster in gates_config.json contains no accessibility/colorblind/shape gate (full roster read); VOL2 CF-7 states the shape channel is "designed, unrendered". POSITIVE CONTROL on the data home: no registry among 62 carries an accessibility/attunement/option column (header scan). Queued coverage is thin and partial: U11.11 lists three input options only (hold-vs-toggle, sensitivity, invert-Y); U11.5's "accessibility tab" has no enumerated contents
Delta. A RULED, non-negotiable L1-playability requirement has no countable option roster (a shipping AAA set is ~25-40 toggles: subtitle size/background/speaker labels, UI scale, motion and camera-shake reduction, photosensitivity, aim assist, per-axis timing assists, menu narration), no settings-persistence schema, no per-option data home, and no automated tooth — the compliance surface is a critic process (QA-12) with no denominator. Window rank 20 routes the DOCTRINE prose here (DESIGN_GAP_REGISTER L529, entry 112); the roster, the schema and the tooth are unowned
Blocking. U11.5 (options framework) and U11.1 (HUD framework) — both build the surfaces the options must reach, and every one of the ~13 unowned screens in gap 1 inherits the UI-scale and colorblind contract. Also blocks the Gate-1 Ch-2-13 P3-exit honestly, since the AI QA loop is the sole player and cannot verify an unenumerated requirement
Proposed home. A T0_Attunement_Option registry (option_id, family, default, persistence key, verify tooth) minted with the rank-20 T1_UI_UX_Spec fill, plus a gate-36 attunement_coverage tooth asserting every ratified family has ≥1 option row and that the shape/audio polarity channel renders independent of color
ui-ux#5 [MAJOR] GAP-146 - The UI chrome string corpus has no canon home, no count, and is outside the Natural Voice Doctrine's own pass
Vision rules. NATURAL_VOICE_DOCTRINE.md header: "Josh ruling, 2026-07-26 — binds every player-facing word", and §1 explicitly claims the HUD: "Requirements/tracking speak plainly ... The HUD's short lines stay short but stay HUMAN." §5 adds a new critic lens ("does a person say this?") to the reveal-table test
What exists (verified). NATURAL_VOICE_DOCTRINE.md §5 scopes the rewrite pass to "the player strings ×4 chapters + boss display names + clue player_texts" — content sidecars only. The actual chrome strings live as C++ literals authored by engine agents: HumanityPlayerHUDWidget.cpp:404/417/432/612/623/644 and HumanityPauseMenuWidget.cpp:34/154. POSITIVE CONTROL on the data home: a header scan of all 62 registries finds no string/label/tooltip/journal column (the same scan does find T0_Status_Table.icon_class, so it reads headers); T0_Voice_Registry covers VO lines, not UI labels. The only governance is the runtime reveal scanner (HumanityUIAutomationTests.cpp "Humanity.UI.RevealTable"), which checks for banned INTERNAL tokens and says nothing about voice, culture, or authorship
Delta. A doctrine that binds "every player-facing word" has no home for the several hundred words the player reads most often (menu and tab labels, tooltips, button prompts, toasts, empty-states, failure and edge-case strings). They are minted in the engine lane, outside the canon authority hierarchy, outside the natural-voice critic surface, uncounted, and — per gap 3 — unlocalizable. This is the both-directions failure: the doctrine consumes a corpus that does not exist as data
Blocking. The natural-voice rewrite pass (named in memory as "the next session's first canon-lane wave") will pass over sidecars and leave the chrome untouched, and every new U11 widget deepens the debt. Bites at U11.5/U11.6/U11.20 — the menu and shell items, which are almost entirely chrome text
Proposed home. A T0_UI_String registry (string_id, surface, loc key, natural-voice status, reveal class) as the single authored home, consumed by the StringTable emitter from gap 3's tooth, and added to the Natural Voice Doctrine §5 pass scope
ui-ux#6 [MAJOR] GAP-147 - No input-glyph substitution system — shipped prompts hardcode keyboard keys and will lie the moment rebinding and gamepad land
Vision rules. PRE_5090_BUILD_PLAN.md §12 #26 requires an "input/control-scheme (gamepad + KBM, the 7-mode + six-option wheel)" spec; VOL2 U11.8 requires "Gamepad bindings + KBM parity" and U11.9 "Rebinding UI + persistence — PlayerMappableKeySettings + UEnhancedInputUserSettings". ROADMAP_POST_5090_TO_SHIP.md L424 puts Steamworks "controller/input via the built Enhanced Input config" on the ship path
What exists (verified). Player-facing prompts hardcode KBM key names: HumanityPlayerHUDWidget.cpp:612 "Press 1, 2 or 3 to choose your path.", :623 "Press F to continue.", HumanityDebugHUD.cpp:418 "[F] skip", :466 "press 1 / 2 / 3". Both HUD literals are in the reveal test's MustPass list (HumanityUIAutomationTests.cpp:82-83), so the test certifies them as correct player strings. POSITIVE CONTROL: no glyph/prompt-token item exists in the 32-item U11 roster (full id enumeration U11.1–U11.32; U11.8/U11.9/U11.12 are bindings, rebind UI and dev-key graduation, none of them prompt rendering), and no registry carries a glyph or key-token column (62-registry header scan)
Delta. U11.9 makes bindings user-remappable and U11.8 adds gamepad, but nothing owns the dynamic key/glyph token that prompt strings must resolve through — so every rebind or controller switch turns a shipped prompt into a false statement, and the one automated test blesses the false form. The per-platform glyph BOM (KBM + Xbox + PlayStation + Switch/Steam Deck × ~30 inputs) is also uncounted, compounding gap 2
Blocking. U11.8 and U11.9 themselves, which ride the EARLY input wave (master W3, per VOL2 cohere H8) — the wave lands before the late UI wave, so the defect ships into W3 and every prompt authored between now and then must be rewritten
Proposed home. A prompt-token convention ({INPUT:Interact}) resolved by a glyph provider, specified in U11.31's T99_Translation_UI.md and enforced by extending the existing FHumanityHudReveal scanner to fail any player string containing a literal key name — the cheapest possible home, since the scanner already walks every UTextBlock
ui-ux#7 [MAJOR] GAP-148 - Typography and glyph BOM for 87 diegetic writing systems plus shipped locales does not exist in any form
Vision rules. T0_Language_Script_Registry [ACTIVE v0.1] is 87 rows and ALL 87 carry a populated layer_1_mechanic AND inscription_application_class (verified by row scan) — i.e. every script is a player-facing L1 read surface, not lore. T0_Inscription_Spine [ACTIVE v0.1] carries 98 rows with script_ids_referenced and trade_9_tier_gate, and COMBAT_PROGRAM_ADDENDUM §3 names the "inscription UI seam". PRE_5090_BUILD_PLAN.md §12 #26 requires "non-Latin/RTL fonts" as part of the missing loc spec
What exists (verified). POSITIVE CONTROL: grep -i "font|typeface" across all 20 _source/01_Tier_1_Foundation/T1_*.md returns ZERO hits, while grep -ci script on T1_Languages_and_Script_Master returns 131 — the search matches and no T1 doc mentions fonts. Across docs/*.md the only game-side hits are VOL2 U11.24 ("non-Latin & RTL font runtime") and §12 #26; HANDOFF_TO_CONTINUO L218 is about the marketing site's SVG icons. No registry carries a font, typeface, glyph, or fallback column (62-registry header scan). The script registry's own decipherment_status distribution (57 FULLY_DECIPHERED, 9 PHONETIC_ONLY, 3 FULLY_UNDECIPHERED, 15 ORAL_NOT_SCRIPT, 1 FAIRY_REALM_NATIVE) is a natural BOM axis and is used for none
Delta. U11.24 queues the RTL/non-Latin font RUNTIME; nothing counts or sources the fonts. Missing: which of the 87 scripts need a real renderable typeface vs stylized art vs a constructed glyph set (the FAIRY_REALM_NATIVE and VRIL_TRACE rows have no real-world font at all), the licensing lane (fonts carry licences exactly like the Sonniss audio library that already needed a licence read), the fallback chain, and the minimum type size that keeps an 87-script decode puzzle legible
Blocking. Q3.7 / MG-3's inscription-decode handlers (the twisted-proverb un-inversion at CH_03 B07 and the Borobudur numerology at CH_05 B03 are both slice content in wave WR3/WR5) — a decode minigame cannot be built or QA'd against a script with no glyph source. Also blocks U11.24 from having anything to load
Proposed home. A typeface_class + glyph_source + licence_ref column trio on T0_Language_Script_Registry (populated in the same pass as window rank 13's data work), with the shipped-UI font stack and fallback chain specified in the rank-20 T1_UI_UX_Spec
ui-ux#8 [MAJOR] GAP-149 - Reveal-gate DATA exists for abilities only, while the plan's own law binds every screen — and the ratified convergence-map lock has nothing to [...]
Vision rules. PRE_5090_BUILD_PLAN_VOL2.md §11 header states the law: "The ability book, Grimoire, and any perception HUD MUST filter by tier/arc so no late-arc name, description, or tier-6 read surfaces for a Neophyte ... A screen that cannot hide is not shippable — the gating IS the feature." BATCH1_RULINGS.md §3 ratifies a specific hard lock: "Convergence-map show-don't-tell lock: CONFIRMED — shows the 22 threads converging as PATTERN only; never names or counts down to the point before the Ch 76-77 reveal (§17.9 / §15 hard lock)"
What exists (verified). U11.15 mints the reveal-ladder field for ONE registry: "Ability-book data contract — reveal-ladder field (tier/arc/first-surface) so U11.14 can filter", scoped to T0_Ability_Tree_Registry's 185-row invariant. The Grimoire (U11.19) reads T0_Cross_Cultural_Link_Graph — 22 columns × 184 rows, whose only visibility-ish column is integrity_visibility — and T0_Thread_Grid, which has SIX columns total (thread_id, chapter_id, progression_stage, content_summary, authoritative_paragraph_anchor, extensions) across 666 rows, with no reveal, first-surface, or spoiler field (both headers read directly). POSITIVE CONTROL: the ability registry's own 36-column header likewise carries no reveal field yet, which is exactly why U11.15 exists — so the field genuinely does not exist anywhere today
Delta. The plan's own shippability law is satisfiable for the ability book and unsatisfiable for every other screen it names. The Grimoire/22-thread convergence surface carries a ratified §17.9/§15 HARD LOCK with zero per-row data to filter on; the codex (150 creature rows), journal, and map screens are in the same position. This is the reveal-discipline class that memory records as "gate-invisible MAJORs"
Blocking. U11.19 (Grimoire) and U11.21 (map) cannot be built shippably — by the section's own definition — and U11.18's journal inherits it. Bites as soon as the W10 book-screen wave starts; also a hard-line surface, so it cannot be deferred to polish
Proposed home. Widen U11.15's reveal-ladder field from a one-registry contract into a shared reveal_class + first_surface_chapter column pair minted on Cross_Cultural_Link_Graph, Thread_Grid, Creature_Roster and the journal home, with the existing gate-13 reveal_discipline tooth extended to assert every screen-read registry carries it
ui-ux#9 [MAJOR] merged into GAP-135 - The journal — a ruled story object and the ratified defeat payout surface — has no data home for its entry corpus
Vision rules. The journal is load-bearing ruled canon on three axes: BATCH1_RULINGS.md §4 ratifies "defeat writes a path-variable journal observation" as canon; DECISION_DOSSIER.md §4 routes hint delivery through "the journal voice (Pillar 6), so reaching for help deepens Layer 2 contact"; the spine makes it a story object (CH_03 healer's-child seed → Ch-13 passing at the departure per the slice's ruled closing beat → Ch-48 "the healer's-child journal's public-release deliberation", START_HERE L159)
What exists (verified). POSITIVE CONTROL: a header scan of all 62 registry CSVs for a journal column returns ZERO, while the same term returns 3 hits inside docs/spine/CH_03.md — the concept is live in the corpus and absent from the data layer. U11.18 ships only the container: "Journal slice stub (empty-state by design) ... an empty journal shell that the Ch-3 healer's-child seed is the first to write." DESIGN_GAP_REGISTER entry 112 covers the DEFEAT read surface specifically ("The only surface the death payout has ever had is the debug HUD") and routes it to the rank-20 doc — it does not create an entry corpus
Delta. The shell is queued and correctly empty; the CONTENT model is absent — no entry rows, no per-chapter authoring obligation, no integrity-path variant axis (the ratified defeat observation is explicitly "path-variable"), no count. Nothing tells the factory that Ch NN owes N journal entries, so the shell stays empty past Ch 13 by default rather than by design
Blocking. The Ch-13 slice-closing beat (the amulet and journal passing to the healer's child at the departure) is Gate-2 content with no data to render, and window rank 2.5's factory contract cannot emit a journal rider against a non-existent data_home (gate 30 R2 would resolve it only as NONE_YET)
Proposed home. A T0_Journal_Entry registry (entry_id, chapter_id, trigger class, integrity_path variant, reveal_class, natural-voice status) minted alongside gap 5's T0_UI_String home, with a per-chapter journal rider added to docs/FACTORY_CONTRACT.md so entries accrue chapter-by-chapter instead of awaiting a sweep
ui-ux#10 [MAJOR] GAP-150 - No UI visual design system — the HUD-art class is one undifferentiated bucket with no tokens and no variation model
Vision rules. Josh's presentation nod binds the look: COMBAT_PROGRAM_ADDENDUM §5/§10 records "every spell and ability and movement needs to be beautiful and fluid art" as standing doctrine, and the fourteenth sitting RULED OPTION (A) FULL PER-TIER VARIANTS, overruling the band-collapse recommendation — the every-surface-beautiful requirement stands at FULL strength (OPEN_BRIEFS_2026-07-28.md item 1). ROADMAP_POST_5090_TO_SHIP.md P2.6 requires the HUD to read "at the AAA reference bar". The realm directive requires realms to be "the GRANDEST displays"
What exists (verified). ASSET_DROPIN_CONTRACT.md L81 collapses all UI art into a single row ("HUD art skin") with generation_status N/A and one verification tooth: "legibility audit (QA-12); before/after captures" — and AI_QA_LOOP_ARCHITECTURE.md §335 defines QA-12 as a per-milestone critic PROCESS, not a spec or a denominator. POSITIVE CONTROL on the doctrine home: window rank 19's presentation doctrine is explicitly scoped "(camera/cut/transition covers)" (PRE_5090_BUILD_PLAN.md L100) — it is not UI; and DOC_MAP.md has no row for T1_UI_UX_Spec at all (grep for UI_UX returns only the VOL2 and Continuo-handoff rows), so the lane's owning doc is not even indexed under the anti-orphan doctrine
Delta. DR-2 sized per-tier VFX variants to 248 live / 372 clamp because the every-surface-beautiful ruling demanded a countable variant space; the UI got the same ruling and no arithmetic at all. Missing: design tokens (type scale, colorblind-safe palette tokens, spacing, frame motif), the diegetic register per region and per realm, and a variation model answering whether ~13-26 screens look identical across 12 earthly regions and 5 realms — the exact failure class Josh named in the concept-art audit
Blocking. Rank 20's T1_UI_UX_Spec fill (it will document the shipped HUD rather than specify a system) and every screen in gap 1 — each built without tokens is a re-skin later. Also blocks the 5090 icon/art pass from having a style constraint block to prompt against
Proposed home. A design-token section inside the rank-20 T1_UI_UX_Spec (palette with colorblind-safe token pairs, type scale, motif grammar) plus a per-region/per-realm variation declaration folded into the ASSET_DROPIN_CONTRACT's new 2D/UI class row from gap 2
ui-ux#11 [MAJOR] GAP-151 - No controller-only navigability contract and no handheld/deck legibility target, despite an Early-Access Steam ship
Vision rules. The ship posture is ruled: Early Access on Steam with the full 14-node slice as the EA base (PRE_5090_BUILD_PLAN.md SLICE RESCOPE, "THE EA BOUNDARY"), and ROADMAP_POST_5090_TO_SHIP.md L424 puts Steamworks "controller/input via the built Enhanced Input config" on the ship path. ENGINE_OPTIMIZATION_DOCTRINE.md RULE SG-3 anticipates the class: "Config/<Platform>/ and -CustomConfig=<Directory> absorb console/handheld classes"; the doctrine's spec ladder is defined at 1080p (L127-152)
What exists (verified). POSITIVE CONTROL: grep -i "ally x|rog ally|steam deck|handheld|720p" across docs/*.md returns 12 hits and every game-side one is operational, not a target platform — the Ally X appears only as a UPS-notification target (5090_SETUP_RUNBOOK L443), a remote-access client (L460, L497), and the walkthrough narration device (5090_WALKTHROUGH_SCRIPT L9); the same grep returns "console/handheld classes" once, in a config-mechanism rule with no UI content. The engine doctrine's three spec classes are GPU-and-resolution rows with no UI-scale, safe-area, or minimum-type-size column. U11.8 covers gamepad BINDINGS and U11.11 three input options; no item requires that every screen be fully operable without a mouse
Delta. A ruled Steam EA ship has no controller-only navigability contract (focus order, back/confirm grammar, no mouse-only affordances) and no handheld legibility target (safe area, minimum type size at 7 inches, Deck-verified layout) — both of which are cheap as constraints declared before ~13-26 screens exist and expensive as a retrofit across all of them. Josh's own handheld is in the room and is documented only as a notification device
Blocking. U11.5, U11.6 and U11.20 — the options, front-end and screens-shell items that set the navigation grammar every later screen inherits. The retrofit cost scales with the gap-1 screen count, so the constraint has to precede the roster, not follow it
Proposed home. A target-class table in the rank-20 T1_UI_UX_Spec (desktop 1080p / handheld 7-inch / controller-only) with a per-screen navigability rider in the gap-1 screen roster, and a QA-loop assertion that every screen completes its primary task under InjectInputForAction with gamepad-only input
ui-ux#12 [MINOR] GAP-152 - No save-slot or New Game+ presentation model behind a ruled prestige mode
Vision rules. The prestige loop is ruled canon: BATCH1_RULINGS.md §4 names The Forgotten One as a "Prestige/NG+ easter egg (SEPARATE, post-Drought unlock, Abyss-crossing rite) ... sole path to 100% / rarest loot / deepest substrate-truth lore" with canon-native progression via the un-pruned seventh vril-seat. PRE_5090_BUILD_PLAN.md §12 #28 asks what carries across it: "mastery, familiars, inventory, world-state, the un-pruned seventh vril-seat". ROADMAP_POST_5090_TO_SHIP.md L423 puts Steam "cloud saves over the existing WorldState SaveGame stack" on the ship path
What exists (verified). P2.7 is tagged "DONE + EXTEND" and is entirely serialization scope — "extend the serialized set to inventory + progression + quest + reputation + integrity; native tags for WS_019/020/021/024; checkpoint actor SaveAsync" — with no slot model and no UI. The only queued save surface is one clause inside U11.6: "Continue (latest save)". POSITIVE CONTROL: the 32-item U11 roster contains no save/load, slot, autosave-indicator, or NG+ item (full id enumeration), and §12 #28 remains an unruled decision that window rank 18's bundled brief does not name (rank 18 lists the 4 open DECISIONS items, composure routing, compang bbox, 5 trade pins, CVD §13.4 wording, the voice-row housekeeping and 3 unbriefed JOSH-calls)
Delta. A single-slot Continue is the whole model. Missing: the slot/profile model, autosave policy and its player-visible indicator, manual-save affordance, the cloud-save conflict surface Steam requires, and the NG+ entry/carry-over presentation — plus the §12 #28 ruling those depend on, which is not on any brief queue
Blocking. U11.6 (front-end/boot flow) — it either invents a slot model or ships a single-slot Continue that later has to be replaced; and Steamworks cloud-save integration at the ship phase, which needs a conflict-resolution surface that does not exist
Proposed home. A save/slot section in the rank-20 T1_UI_UX_Spec covering slot model, autosave indicator and cloud-conflict UI, with the §12 #28 NG+ carry-over question added to the next bundled Josh brief (window rank 18) so the NG+ entry surface has a ruling to build against
Generated by harness/site/structure_site.py — the URL path is the repo path. review root