Claude Design — Factory Studio master brief¶
Target
This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.
Assignment and output¶
Design an interactive prototype of the ConnectSoft AI Factory Studio using the focused packs in this folder. This document is self-contained project context; no access to the originating conversation is required. The deliverable is a set of inspectable prototype files, a route and state inventory, a component reuse report and an interaction checklist. Every simulated action must be labelled as fixture behaviour. Do not connect production APIs, deploy, or infer backend readiness: no Studio, BFF or platform service exists today.
Product and audience¶
The Factory Studio is the command centre of an organizational AI operating platform: people submit work to governed agents, review exact proposals, publish assets with evidence, operate the Factory and the products it generates, and govern knowledge, usage and data. Seven roles use it (requester, reviewer, asset maintainer, operator, workspace admin, platform admin, observer); see personas and journeys. Operators need dense readable tables, visible scope and freshness, and deliberate gated actions. Reviewers need the exact version and its evidence. Admins need tightening-only controls with evidence of every change.
Source packet¶
All references are local under C:/Git/ConnectSoft/ConnectSoft.DesignPrototypes/:
ConnectSoft AI Software Factory.dc.html— the existing Factory prototype (48 destinations, 15 dedicated views) andWorkflow Studio.dc.html(28 destinations), both mapped in the prototype alignment.ConnectSoft Design System.dc.html,ConnectSoft Component Catalog.dc.html,ConnectSoft Reference Screens.dc.html,ConnectSoft Developer Handoff.dc.html— tokens, components, compositions and developer notes, reconciled in design-system alignment.ConnectSoft Config Platform Prototype.dc.html— the most mature behaviour to reuse: five personas with a grant matrix, digest-bound approvals that go stale, RTL toggle, separation of duties.- The UX model of this site: screens, flows, states, permissions.
Preserve semantic colours, dense operational layout, Inter, Heebo and JetBrains Mono, light and dark, keyboard navigation and Hebrew RTL readiness. Do not import prototype sample metrics as real data.
Shared shell and information architecture¶
Persistent organization, tenant, project and environment switchers that grant nothing; a rail of seven work areas (Workspace, Assets, Intelligence, Quality & releases, Operations & usage, Governance & administration, Software Factory); a command palette; notifications; a breadcrumb with scope badge and a freshness strip; profile with locale en, he (RTL) and ru, theme and reduced motion. /work is the root. Detail routes use stable resource keys, tabs and shareable filters; browser Back restores list and filter context; a scope switch with unsaved changes asks first. See shell and information architecture.
Tables have sticky headers, sortable columns, text alternatives to colour, empty guidance, pagination and horizontal scrolling on narrow screens. Drawers become full-screen sheets on mobile. Charts include accessible data tables. RTL reverses directional layout and icons while identifiers and code remain LTR.
Shared fixtures and permission states¶
One synthetic organization with two tenants, one project, four environments, Published and Draft agent releases, a run in every state, an approval in every state, usage in every status, one operated product with instances, one rollout and one incident — specified in fixtures. Use the seven personas; use Maya (observer) to demonstrate denial. Never display reusable credentials or real customer data.
Global states: loading skeleton preserving layout; empty with the permitted next action; field validation error; dependency degraded with freshness and retry; permission denied with explanation; stale version conflict (412) with the newer version rendered; success with scope and version and the next action. A disabled control explains the missing permission and never becomes clickable through a visual role switch alone.
Ownership of integrated screens¶
The Studio owns sessions, saved views and notifications only. Runs and approvals belong to the Control plane; assets to Asset Publication; evaluation to Observability; delivery to DevOps / GitOps; provisioning to Runtime Cloud; fleet to Product Fleet Operations; policies, audit and secrets to Governance; registry, stores and retention to Data & Event; marketplace to Marketplace. The Studio shows their read models under scope and forwards their commands with the user's token; it never retries, queues or widens. Identity is the canonical Identity Platform; the Studio never shows credentials.
Review and acceptance¶
Every screen in the catalog must appear with its states; every flow with its adverse branches. Exercise success and adverse states keyboard-only at desktop 1440×900 and mobile 390×844; check contrast in light and dark, focus restoration after dialogs, escape behaviour, long identifiers, RTL, reduced motion and chart and table alternatives. Export a route-state coverage list and list any illustrative-only controls. No live backend, production metrics or implementation percentages may be implied. The full list is in acceptance.
Prototype review journey¶
Use this flow to connect the focused packs with consistent fixtures; it describes prototype interactions only.
flowchart TB
accTitle: Connected requester and reviewer journey
accDescr: Select scope, submit a run against a Published release, watch the timeline, decide on an exact proposal, read artifacts and usage by status.
scope["Select organization, tenant, project"] --> submit["Submit a run: release, profile, limits"]
submit --> watch["Watch the run timeline with freshness"]
watch --> approval{"Approval requested?"}
approval -->|"Yes"| card["Reviewer decides on the exact proposal version"]
card --> stale{"Proposal still current?"}
stale -->|"No"| refresh["Newer proposal rendered; decide again"]
refresh --> card
stale -->|"Yes"| resume["Run resumes"]
approval -->|"No"| resume
resume --> artifacts["Read artifacts with lineage"]
artifacts --> usage["See usage by status; uncertain separate"]