UI

Purpose

The v1 pain is invisibility: a case lives in one terminal, nobody else can watch, take over, or answer a gate (Platform Details PG-5). The UI is the one place where a case is visible to many, operated by one, and where every human decision the platform needs is asked and recorded. It is a section of serdica-ui administration, not a separate application — authentication, roles and deployment come with the host.

P The chat is the workspace (D119). A case is worked the way a coding assistant or a chat CLI is worked: one thread per case, in which the agent's steps, its tool calls, its questions, its plan and every human decision appear as cards in time order, and a person types into a composer at the bottom. Nothing about a case happens anywhere else — a decision taken outside the thread is invisible to the ledger and to the other viewers, which is v1's whole failure (PG-26). What makes it more than a chat is that every card says where it is about: environment · system · object, as a chip, so that a reader always knows what is where without opening a query.

P Two surfaces, one application. The operator surface is the administration section — eight workspaces behind role-dependent front doors (§ 1). The client surface is what the customer sees: their requests, one request in their own vocabulary, the acceptance gate their representative owns, and — as the target state — a self-service intake (§ 5b). The adaptive case walkthrough is the operational UX reference: all 68 catalogue cases use five patterns — Queue, Case workspace, Decision, Result / acceptance, Learning review — on their actual module flows. Each contains the selected case's data and working local interactions. Case Journeys § 2 explains the consolidation and stage/state distinction.

P One operations UI across the presentation. The homepage accordion and this page embed the same operations preview, generated from the walkthrough's components, style and local action handlers. The full walkthrough adds the chosen module path and developer inspection. The eight workspace responsibilities below describe entry points and administration; they do not require eight different case interfaces. Control/Metrics/Studio keep their administrative purposes.

P In a case, the current thread card is the focus; the operator/agent conversation and composer remain visible; detailed evidence is folded. A module stage may produce several cards: working, waiting, at a decision, or checked. The same Decision pattern serves plan, stage sign-out, target authority and recovery, with different packets and authorised actors. The prototype's catalogue, module-stage and state selectors sit outside the product frame; real users receive the current server-projected card. Amber indicates a decision/wait, green a checked result, blue current work and links, and red a failed condition.

0. Design principles

P Eight rules, in the order they were argued; every screen in § 5 can be checked against them.

1. Roles → front doors → workspaces

P The roles are those of Trust and Data § 3; the workspaces are the platform's, not a module's — a Support case and a Configuration case are worked in the same chat with a different stage ladder.

2. The case chat — the vocabulary

P Layout. Three columns. Left: the case header (id, state, type, contract class, clocks), the stage ladder of its module with the gate each stage carries, and the sessions (live · stopped · resumed) with the controller and the viewer count. Centre: the thread of cards, oldest first, a status line and the composer. Right: Where — source, systems touched with mode, papers, linked cases and knowledge, and — when the case is at a gate — the grant that an approval would issue.

P Card kinds. Eleven; the left colour bar names the kind, the small caps label repeats it for the colour-blind.

P Where-chips. ENV · SYSTEM · OBJECT in monospace, followed by a mode chip: read (green), write or send (amber — gated), ddl (red — HW-ddl). Objects are handles (policy ••••7731, annex ••••0028/3), never raw identifiers; the case keeps the mapping (Trust and Data § 4). Clicking any chip opens Where (screen 05): the full map by environment, system and mode of everything the case touched — the trace of what the agent actually did, typed by nobody.

P The plan gate follows the plan mode of the coding CLIs. The agent proposes a numbered plan — each step with its where-chips and the gate it will need — states why, and lists the alternatives it rejected. The person picks one of four: approve the plan (a write or send step asks again when it runs, and the grant is issued then); approve and pre-approve a step — one decision for plan and write where policy permits, and shown disabled with the reason where it does not (an approved shape, not irreversible, and never H5 on a customer-facing environment); reply with a different approach — free text to the agent, which re-plans and returns with the next plan version; refuse with a reason, which parks the case. A reply re-opens planning, not the gate. Evidence, the statement, reversibility, blast radius, policy checks, the shape's training count and the grant are one click deeper under Details.

P Composer and permission mode. The composer's second line always states the permission the typist has: you control session 3 · the agent asks, you decide for the controller; Approver(PROD, write) · read + decide for a role holder who is not controlling; viewers have no composer. Slash commands: /steer ⟨text⟩ (a steer to the running agent) · /answer (the open question) · /stop and /resume (the session) · /handover ⟨module⟩ (opens Hd) · /consult ⟨node⟩ (a read-only consult) · /park ⟨reason⟩ · /where and /papers (open the rail sections) · /try ⟨version⟩ (run this case on a draft prompt — how prompts are trained case by case, § 4 W9) · /help.

P Status line. State · stage → next stage · tool calls · elapsed · human minutes so far · runtime budget left (minutes). Internal runtime effort/budget is shown in hours and minutes. Approved commercial offer prices and monetary terms are customer-visible with their currency; they are distinct from model/runtime cost.

3. Intake — a brief before a case

P The Inbox is the first screen an Operator opens, and nothing in it is raw. An arrival from any door — the ticket system, the shared mailbox, the customer's help desk, the client app's Start a request, a monitor — is normalised by platform.intake (Agents § 5c, Stage Classification § 4) into a brief:

P Authorised intake opens automatically; triage and the configured H1 policy record classification, and the clock service uses the applicable arrival time. The operator may Open case, Correct & route (a revision and evaluation example), Merge into #… after confirming the same source request, or Dismiss policy noise. Missing initiation authority waits visibly. A shared policy handle alone does not make two different requests duplicates.

4. Workflows

P Thirteen workflows; each names its trigger, its actors, the screens it crosses and where it ends. Together they cover every human action the platform asks for — anything not listed here is either the agent's own work or a defect of this page.

P Three properties hold across all thirteen: every human action is a verdict or a human card in some case's thread (or a row in AUDIT_LEDGER for Control), so nothing is decided off-record; every workflow that changes an environment passes through a grant issued by a gate and executed by the effect applier, never by the agent; and every workflow is role-checked by the front door, not by a hidden button.

5. Screen inventory

P Case content and response path. The 68 case journeys bind five adaptive patterns to module stages, backend and agent work. One request uses its existing question/action card for external work: who must act, a plain-language instruction, when requested, the evidence needed, Report completed, Cannot perform and Add evidence. Reporting calls the scoped response API, not the acceptance API, and changes the display to “Checking your result”. An ordinary business answer uses the same API with response_kind=answer. A required action still waiting is waiting_for_you; an external organisation waiting is in_progress with the waiting party and age stated in the summary. Cases and Where show the full obligation/member matrix; Acceptance states instructions, preview or delivery scope. No new screen or client-visible technical transcript is introduced.

5a. The operator surface

5b. The client surface

P The customer is not a second class of operator; they see a different application built from the same case (D91). Four screens; What you may start is a panel of screen 18 (D91):

P Three fields the client surface carries that a channel cannot (D97). Origin — every request shows whether it arrived by mail, from the ticket system, from the customer's help desk, or was started in place; one case model, four doors, and the list reads the same whichever was used. Modules involved — the parts of the platform a request actually engaged, so a support case that grew a configuration sub-case says so instead of going quiet. Initiator — who started it and when, because a client who starts work is a different fact from a client who was written to.

P Screen 18 shows the initial client entitlement, so the wireframe fixes all three outcomes rather than the happy one: granted opens the case, may request opens an authorisation request that parks visibly, not granted refuses with the clause and keeps the description for the commercial counterpart (Agents § 5c, Trust and Data § 3b). The kind list offers only what this role may start or request, and a refusal is shown with its reason — never hidden, never silently re-routed to a module the person happens to be allowed to start.

P Screen 18 is the target state and is not the first build (D81, formerly non-goal N-9). What is excluded is building a self-service form before the operator surface and the gate protocol exist, because a form over gates no work type has earned puts a customer in front of an untrained system. The wireframe exists now so that the intake contract is designed for rather than discovered.

P What is deliberately absent from every client screen, and why the absence is a design rule and not an omission:

P The Customer representative role may start support, may request configuration, may not start the customer-specific development module (id source), and views and accepts through CG-11 (D97). Acceptance records the person's name and the artefact hash; a later change re-opens the acceptance rather than reusing it.

6. The shared interactive screens

P The case chat is the working surface. Select an example below. Case chat shows DC-02 with Mira D., the Ablera operator/controller, the main agent and the investigation. Configuration sub-plans shows CF-05 with the Abacus stage and separate partner-template task conversations. Operator approval shows Georgi S. deciding the target packet in context. The customer has a conversation with their Ablera contact and sees the scoped result. These are illustrative names, messages and role assignments, not recorded live sessions.

P The sample data progresses with the work. In the main SD-1598-based example, the initial take distinguishes possible causes of the blank fifth year; investigation finds five existing policies but only four print-register entries; the selected solution is one missing entry, not a family retransfer. Application names Bulstrad IT and its receipt; verification checks the five-to-five join and regenerated document. Learning retains the discriminator and a family-inventory tool candidate. Other cases carry their own authored findings and checks from Case Journeys, rather than this case's data or generic placeholder text.

Open the full preview · DC-02 case chat · CF-05 stage and sub-plans · CF-01 temporary-exception route

P Conversations have scope. The main case conversation stays with the root. A stage conversation exposes its task, plan and relevant messages. A bounded sub-plan has its own parent/task identity and selected input revision, not a separate customer request. In CF-05, each partner template is an independently checked work item; a row or a message is not automatically another agent. Selecting a conversation changes the visible context, not the case's authority.

P Parent confirmation and human approval are separate. The child proposes a plan to its immediate parent; the parent confirms permitted preparation. The stage joins the child results into its own H2/H3 packet. The main root presents any unresolved human decision. A parent-confirmed read/preparation task cannot apply a target change, and an operator's chat message is not a gate decision. The prototype shows both the parent confirmation in the sub-plan conversation and the human packet in context.

P The composer is an operation. Mira, the illustrated controller, can send a message to the main agent against the selected task/sub-plan. It is appended to the conversation with an acknowledgement that scope must be reconciled. The existing POST /cases/{caseId}/commands carries command=steer, text and the exact task/plan context. The server checks controller rights, visibility in the controlling case or its accepted descendants and the current revision. Georgi's illustrated approver view can decide its packet but has no general controller composer. Customer replies use their scoped response/result actions.

P Same components, different presentation. The homepage retains its expandable accordion with case-chat, configuration-plan, approval and learning examples. The UI chapter exposes the example chooser. The full walkthrough adds the route, stage-state selection and developer contracts. All use the same conversation renderer, operator identities, plan cards and local action handlers. The shared five patterns organize queue, work, decisions, results and learning; they do not replace chat with five isolated summary cards.

7. Rules the screens enforce

P Approval is a permission, not a second person (Trust and Data § 3). A decision card the viewer may decide shows the decision actions; one they may not shows who can, and a notify action. An Operator who holds the role for the gate and the target decides their own case in one action; where the organisation wants four eyes on a target it withholds the role from its operators — a role-set choice, not a platform rule. Nothing on screen lets a viewer widen their own role.

P Many viewers, one controller (Agent Runtime). The case header always shows the controller and the viewer count; Hand over is a recorded handover; Take over needs the operator role and notifies the previous controller. Viewers have no composer.

P The thread shows stated reasoning, not chain-of-thought — each agent's declared reasoning for a step, its tool calls and their result summaries, and every memory read and write (Architecture § 1). Raw model reasoning is neither a dependable API nor appropriate operational output.

P Every decision card is a packet, not a chat — the mechanism (with the validator's verdict), the kind and the rejected alternatives, the exact change with expected counts, the revert path and effect classes, the replay, what remains uncertain (Stage Solution Take § 3). A decision binds the shown artefact and revision; an eligible effect grant is issued only when all required decisions pass. A changed artefact re-opens affected gates. Cards show named check summaries; raw database rows remain in the protected evidence store.

P Every card says where. A card without a where-chip is a defect of the card, not a style choice; the Where rail is derived from the cards, never typed.

P A brief before a case. The brief names its source; authorised intake already opened the case. Opening it is a read. An operator corrects classification when needed, creating a recorded revision (SG-11).

P Held batches are cases so that their age is visible on the first screen — the direct answer to the 12-week HDesk plateau (Baseline § 5). They appear in Cases and in Decisions alike.

P Hours only. Human minutes, elapsed time, budgets in minutes, clocks in hours and business days; no currency on any screen (D117).

8. Realtime and auth

F SignalR is the estate's proven realtime transport — hub + one-use Redis ticket + HMAC group alias + Rabbit fan-out + transactional outbox, working tested code on the health path (verified 01.09.2026, Platform Details PG-5). P The case chat subscribes per case/session with its own ticket shape and role set; the list screens poll or subscribe to the workflow-generic change event. Authentication is Authority; the roles are the six LT_USER_ROLES rows, issued as role claims by Authority (Trust and Data § 3, D134).

Challenges

• P Visual design follows serdica-ui's administration look; the wireframes fix shell, regions, vocabulary and data, not styling — settled with the T1 skeleton.
• P Thread volume — a configuration stage runs for hours and produces thousands of events; the chat needs collapse-by-agent and follow-mode, and the SignalR payload must stay a reference to ledger rows, not the rows. Tool cards carry summaries; results stay one click deeper.
• P Where-chip resolution — a handle that does not resolve (a policy number with a typo, an object in an environment the connector cannot reach) must render as a red not found chip and park the brief as question, never as a silent blank.
• P The curator duty is a duty of the Operator role per branch of the tree, not a seventh role, until the measured proposal throughput (Metrics) says otherwise.
• P Control's policy tables render the catalogue rows retention.per_class, gates.auto_confirm, gates.escalation_intervals and budget.* (Whitelabel Catalogue § 5; D109 / D112 / D117); what stays open is where the T1 skeleton fixes their storage.

P Implementation alignment. Intake, classification and routing follow Agents § 5c. A permitted arrival opens before an operator clicks it; Inbox is an inspection/correction queue. Gate commands carry the shown artefact hash and expected version; stale decisions return conflict. The same Acceptance screen states preview or delivery, target and revision; preview acceptance cannot close outstanding deployment. Reconnection reloads committed resources by ledger cursor. The backend enforces customer/role filtering on every read and command.

P Client-led Configuration. Reuse the existing request/Acceptance card for H1 business scope and H3 business results when CASE_TYPES.GATE_PLAN assigns required_role=customer_representative. It shows the business projection and exact revision, never a technical SQL packet. The same card uses CG-11 for preview/delivery. Each command names the gate id, scope, hash and version. Scope/result/preview confirmation continues work; only completed-delivery acceptance closes the case. This removes a vendor queue without adding a screen or implying write authority.

P Offer view. Assessment & Offers presents the requested scope, effort/assumptions, owner-approved commercial terms and delivery proposal, missing items and exact offer revision. O3 is customer acceptance with scope offer; it is unavailable while required terms are missing and never authorises implementation. Offer workflow.