Frontend UX direction

This is the TASK-017 design direction for the fixture portal. It was written before implementation so the redesign starts from reviewer jobs rather than CSS tweaks.

Diagnosis

• /issues/ replaces the old portal roadmap and should not become another local

backlog. It should explain the Forgejo issue workflow, label taxonomy, and agent trigger contract while sending live planning back to Forgejo.

• /confluence/ has the right product shape: tree on the left, page workspace on the

right, and immutable source evidence nearby. Its main debt is naming: fixture prefixes dominate display names that should help a reviewer understand the architecture hierarchy quickly.

• /confluence/fixture-datacenter-sbb/ keeps tree context visible, which should stay,

but the title and facts still lead with fixture scaffolding and long paths.

• /evidence/ lists where screenshots live but does not render the screenshots.

Evidence review needs direct visual proof first and paths second.

• /mockups/ is useful as a design comparison artifact, not as the product UI.

It should move out of primary attention once a durable direction is chosen.

• The shared navigation wrapped into a tall pill stack on mobile, pushing useful

work below the first screen. It also gave every route equal weight, including temporary design mockups.

Useful Existing Portal Patterns

The existing RWS architecture portal demonstrates useful patterns to carry over:

• A real shared shell with active navigation instead of route-by-route chrome.
• A Confluence-like workbench with a tree, selected content, and an inspector.
• Progressive disclosure for large hierarchies and generated model data.
• Stronger RWS-blue and yellow accents that feel institutional rather than like a

generic dashboard.

Do not blindly copy its theme switcher, mobile header height, or heavier issue workflow visualizations. This workbench needs to feel more operational: source fidelity, evidence proof, task state, and review handoff are more important than broad portal exploration.

Information Architecture

• Status: triage entry point and route discovery.
• Source: primary architecture reviewer anchor; tree, page, metadata, findings,

and source evidence.

• Review: findings, compliance, and preview review should eventually group into

one review area or section navigation instead of three equal top-level routes.

• Issues: workflow contract, not a local backlog. Show Forgejo entry points,

label semantics, implementation trigger, safety gates, and evidence flow.

• Evidence: visual proof gallery with manifest/readiness metadata nearby.
• Mockups: internal design-decision route; remove from top-level emphasis after

the visual direction is selected.

Page Hierarchy And Navigation

• First viewport should answer: where am I, what needs review, what is blocked,

what proof exists, and where do I go next.

• Use compact page headers on task routes. Large hero panels are reserved for

discovery pages, not operational queues.

• Use row-based lists and split panes for workbench data. Cards are summaries only.
• Keep breadcrumbs as route context, but avoid repeated explanatory paragraphs

once a page has moved into operational mode.

• On mobile, global navigation should stay below roughly one compact band plus two

rows of route links; the active work/source/evidence content must start quickly.

Density, Spacing, And Typography Rules

• Use an architecture operations ledger visual language: compact rows, restrained

borders, smaller radii, RWS-blue/yellow accents, and minimal decorative effects.

• Cap task page headings around 2rem to 4rem, not the previous oversized

5rem treatment.

• Prefer 8px to 16px internal spacing for task rows and 10px to 14px

radii for work surfaces.

• Metadata, paths, and immutable IDs stay visible but visually subordinate to

human-readable titles, state, owner, review state, dependencies, and proof.

• Replace pill spam with structured rows, short status labels, and evidence tags.

Remove Or De-emphasize

• Duplicate local planning registers on /issues/.
• Giant action panels and hero blocks on operational routes.
• Decorative gradients and large rounded cards that do not improve scanning.
• Fixture prefixes in source display names.
• Evidence pages that only list screenshot paths.
• Mockup route prominence after a direction is selected.

Acceptance Criteria

• Desktop /issues/ at 1440px shows Forgejo issue entry points, trigger label,

delivery mode, and safety boundary in the first viewport.

• Mobile /issues/ at 390px keeps navigation compact and exposes the issue

workflow before the label reference.

• /issues/ does not render a local backlog or duplicate issue state.
• Issue labels expose richer work semantics: type, status, priority, automation

intent, gate, and area.

• Desktop and mobile source pages keep tree context visible and stop leading with

fixture-prefixed display names in the next implementation slice.

• Evidence renders screenshots inline in the next implementation slice, with

route, viewport, commit or generation time, and manifest path available.

• All inspected routes avoid page-level horizontal overflow and keep visible focus.

First Redesign Slice

The first proof slice is /issues/ plus shared navigation. It implements the issue workflow contract, reduces mobile nav height, documents the label model, and makes Forgejo the live planning surface. Evidence screenshots and source display-name cleanup remain the next coherent slices.