Product experience

Give Renga one coherent product experience that facilities staff and infrastructure operators share, with the speed and polish of a modern keyboard-first tool. The experience must make Renga’s distinctive model (observed versus desired state, provenance, freshness, and findings) easy to read and act on, and it must give later capabilities such as osquery and virtualization defined places to plug in instead of new top-level pages.

This RFD owns information architecture, shared interaction patterns, the Inbox and triage workflows, visual design tokens, and the user-facing extension points. Domain behavior stays in RFDs 1 through 7; where this RFD needs new domain state, it says so and the owning domain implements it.

The current web UI was built feature by feature and mirrors the data model:

Each new domain has added pages. Without a shared structure, osquery and virtualization would add more.

Facilities staff (placement, assets, warranty, replacements) and operators (freshness, agents, drift, network) use the same objects, lists, and Inbox. Neither group gets a separate application or vocabulary. Saved views are the only role-specific surface. Both groups' actions appear in the same activity history so each can see what the other changed and why.

The interface is designed for frequent, keyboard-driven use and must remain readable for occasional visitors. Copy names things the way people recognize them ("Expected" and "Observed", not "canonical projection").

The top level has six areas that do not grow per feature:

"Who reported this?" has no page. Provenance is available on every value (see Values, provenance, and drift).

The sidebar holds the six areas, pinned saved views, and sites. The mobile menu and the command menu are generated from the same navigation definition so they cannot diverge. Organization and personal settings live under one Settings area.

Existing routes are kept as redirects to their new homes during migration.

The Inbox contains three item types, grouped by default as Requests, Triage, Drift, and Health.

Findings are opened and closed only by reconciliation. People add workflow state on top:

A person cannot mark a finding resolved while the system still observes the condition. An expired exception returns the finding to the open queue. This generalizes the existing expected-component exception to all finding types.

Requests are permanent changes a member proposed but may not apply directly (see Editing hardware components). They carry the proposer, reason, the before and after values, and the effect of approval. When the same request is open on several resources, the request suggests changing the shared definition instead.

The domain implication is one organization-scoped workflow record keyed by finding identity (assignee, snooze, exception, and history) that every finding-producing domain uses, plus a request record with approval state.

Triage is a computed view, not a flag. A resource is in triage while it lacks facts a person usually supplies: a placement, a hardware type, an owner, or a resolution of a suspected duplicate identity. It leaves triage automatically when those facts arrive, whether from a person, a rule, or a collector.

Triage never gates inventory. Untriaged resources appear in every list and count. Virtual machines and other short-lived resources never enter triage; they inherit their placement from their host.

To handle onboarding bursts, triage groups items by pattern and suggests rules such as "hosts reporting from 10.20.0.0/16 belong to Ashburn DC1, Data Hall A". The first release has a small fixed set of rule types, each turning one strong signal into one fact:

Hardware type needs no rule: RFD 6 catalog matching assigns it from reported manufacturer and model, and an ambiguous match becomes a finding.

Every rule:

New rule types are added individually when a recurring case needs one, rather than through a general rule builder.

Places presents site, location, and rack hierarchy and ends in a rack elevation. The elevation draws empty units as faint rows, devices as single blocks spanning their height, front and rear side by side, and full-depth devices on the rear face. A device observed in a rack (for example through LLDP from the rack’s switch) but planned elsewhere is drawn as a dashed block with a one-step resolution. Unplaced resources in the location can be dragged onto free units.

The UI moves to plain Tailwind with design tokens defined as CSS custom properties, and stops using daisyUI. Shared components are built against those tokens.

Each person chooses a theme (light, dark, or match system) and one of five accents: Copper, Petrol, Cobalt, Iris, or Monochrome. Copper is the organization default, and owners may change the default for new members. Each person also chooses a density: comfortable (the default) or compact. Density is expressed only through tokens (row height, padding, table text size, and rack-unit height) consumed by shared components; no screen handles density on its own. On touch devices, tap targets stay at least 44px at either density. Preferences are stored per user so they follow the person across devices.

Status colors are fixed and independent of accent and theme: green for healthy, yellow-ochre for warnings and drift, red for failures, and a neutral for unknown. Warnings use ochre rather than amber so they never resemble the Copper accent. Every status also has a distinct shape.

The page title drops the generator’s " · Phoenix Framework" suffix.

Phones are used in two situations: an operator on call acting on one problem, and facilities staff at a rack finding a device and recording physical work. A short list of tasks is designed and tested to be fully usable at phone width (390px); every other screen remains readable, with wide tables scrolling horizontally and edits linking to the desktop view.

Topology, switch ports, VLANs, prefixes, catalog editing, bulk moves, and settings other than appearance are readable but not editable on a phone. Tablets use the desktop layout with the touch rule from Visual design. The list grows when a recurring phone task appears; additions are amendments to this RFD.

Scanning an asset tag or serial-number barcode with the device camera to open a resource is a natural follow-up for on-floor work. It needs camera permissions and label conventions and is left to a later RFD.

Later capabilities plug into the shared patterns rather than adding top-level areas:

Every future RFD that adds user-facing behavior states which extension points it uses. A proposal that needs a new top-level area must explain why none of these points fit.

Presentation never replaces context-level authorization. Inbox workflow changes, exceptions, requests, approvals, triage rules, revision moves, and appearance defaults are authorized in their contexts and recorded in Activity. Requests exist because a member lacks permission; approving one applies the change as the approver with the requester recorded. Saved views and preferences are scoped to the organization or user that owns them, and a shared view never reveals data its viewer cannot otherwise read.

Actions that later control hosts (queries, terminal access, virtual machine operations) continue to follow RFD 1's control-plane rules; the command menu only surfaces them.

Progress against this proposal is tracked in the RFD 8 implementation checklist.