Web-App System

Design The Product Around The Next Safe Decision

INTO web apps should feel sparse, senior, evidence-led, and practical. The interface exists to help operators see work, understand evidence, govern AI output, and take the next safe action.

Use Mature Components Without Importing Their Personality

Component libraries can supply anatomy, accessibility patterns, and interaction discipline. INTO owns the typography, density, state language, containment, icon behavior, and product atmosphere.

Show The INTO-ified shadcn Layer

A modern INTO web app is not a generic shadcn demo and not an editorial web page with app labels. It uses mature component anatomy, then applies INTO typography, restrained petrol action, glass command focus, evidence states, and quiet operational density.

Lead With One Composed Product Scene

Future INTO apps should demonstrate complete workflows, not isolated component inventories. The first viewport should prove place, state, evidence, owner, AI activity, risk, and the next safe action.

example-webapp-workshop-ui

OPERATIONS CONSOLE

Client Readiness

Search records, inspect evidence, or run a governed action Ctrl K

Audit log Review export

Owner: Avery Evidence: 82% AI agents: 4 active Client visible: blocked

Readiness cockpit

The screen gives the operator the full decision frame: what is blocked, what evidence exists, what AI proposes, what action is permitted, and how to recover.

Decision Hold client-visible export until the pricing note and security review are cited.

AI proposal Route B is ready if Finance accepts the variance note and Orion approves execution.

Recovery Assign reviewer, attach two sources, then re-run export preview.

3 blocked decisions 12 evidence links 1 client export held

example-webapp-agent-map

Research Source packet ready Needs citation check

Operations Route B prepared Awaiting approval

Finance Import variance found Saffron caution

Client Export locked Internal only

Agent activity is visible, but execution waits for human approval

example-webapp-timesheet-ui

TIMESHEET / APPROVAL

Week exception review

4 ready 1 blocked

Consulting hours awaiting review.

Person	Mon	Tue	Wed	Thu	Fri	State
Avery	6.0	7.5	4.0	6.5	5.0	Ready
Orion	8.0	7.0	7.5	0	4.0	Missing note

Total55.5h ExceptionThursday zero needs reason Request fix

example-webapp-polling-ui

FORECAST / POLL

Route confidence

Live Evidence linked

Which route should move to client-visible review?

Route A24%

Route B58%

Route C18%

17 responses 6 abstained Evidence packet linked

example-webapp-product-proof-gate

PRODUCT PROOF GATE

One dominant viewport first. Show the actual product job before component variants. Supporting examples earn their place only when they prove a different workflow or state.

Every specimen must contain pressure. Include blocked, partial, permission, conflict, sync, review, or recovery states. Perfect dashboards hide the work.

Mobile proof is mandatory. Desktop specimens require a 390px mobile equivalent that preserves the next useful decision instead of squeezing the full layout.

Dense, Legible, Token-Led

Web-app surfaces use brand tokens plus app-specific aliases for shell dimensions, control heights, row heights, focus ring, and surface states. Density is earned by alignment and hierarchy, not smaller text.

Density Modes Preserve The Baseline

Compact and comfortable density use the same 0.5rem structural baseline. Compact tightens repeated work by reducing gaps and padding; it does not shrink text below the published floors or remove labels, focus, captions, helper text, or recovery states.

• Compact tightens by roughly one baseline step for gaps and padding compared with comfortable mode.
• Density is a component prop such as density="compact" or density="comfortable", not a per-screen pile of arbitrary classes.
• Mixed-density screens keep the primary decision comfortable and repeated support surfaces compact.

App Shell, Navigation, And Command Bar

The shell keeps place, action, and evidence visible. It uses landmarks, current-path signals, and quiet command surfaces before adding containers.

example-webapp-app-shell

Workspace / Client Readiness

Search Command User

CLIENT / Q2 READINESS

Three workstreams need approval before client rollout.

Owner: Avery. Updated 14 May 2026. Evidence coverage: 82%. Client-visible export is blocked.

Create review

Search workstreams Status: needs review Owner: all

Intake Review Approve Execute

BLOCKER Data import needs owner Assign

READY CRM handoff approved Schedule

AI REVIEW Route change awaiting evidence Review

Self-Audit Before Implementation

The web-app system must be complete enough that a coding AI can build required applications without inventing interface logic, state behavior, or visual hierarchy.

No final screen, implementation guide, or QA checklist is complete until this audit table passes for the target app.

AI Software Platform System

Use brand/ai-software-platform-system.md as the complete source specification for INTO-branded AI products, project systems, content operations, render pipelines, agent workspaces, dashboards, and collaborative operating tools.

Required Specification Coverage

Color Usage By Key Element

AI Platform Component Library

AI Interface Patterns Are Named Surfaces

Use brand/ai-interface-patterns.md for the canonical rules. This hybrid section shows how the patterns compose visually; the Markdown owns the detailed purpose, anatomy, states, motion, depth, color, accessibility, and anti-patterns.

Component Variants And States Are Explicit

A reusable app component does not exist in this system until its variants, states, mobile fallback, and accessibility contract are named.

Dashboards And Tables Lead With Work

Dashboards summarize decisions only when the user can act. Tables are first-class operational surfaces with captions, sorting, filtering, selection, and recovery states.

Data Tables Are Operational Work Surfaces

A data table is not a spreadsheet skin. It needs comparison, state, selection, permission, sorting, row action, expansion, pagination, and mobile record behavior defined before code.

Data Views, Timelines, And Pipelines Have Jobs

Choose the view by the operator's decision. Do not turn every dataset into a dashboard or every workflow into cards.

Form Fields Carry Instruction, Validation, And Recovery

The form primitive defines labels, helper text, validation, dirty state, permission copy, conflict recovery, and mobile save behavior before a reusable field component is built.

Forms, States, Drawers, And Modals

Forms are decision tools. Every field needs a label, helper or error state when needed, save/cancel behavior, and keyboard recovery.

Overlays Need Consequence, Focus, And Mobile Sheet Behavior

Modals, drawers, and sheets are one primitive family with different interruption levels. Each instance names the object, consequence, focus behavior, close route, and mobile fallback before implementation.

AI Workspaces Separate Input, Evidence, And Action

AI surfaces use INTO restraint. The interface exposes evidence and approval gates instead of decorative AI styling.

For prompt input, streaming text, citations, agent trace, tool call display, model awareness, confidence, disclosure, refusal, feedback, and attachment/artifact behavior, route to brand/ai-interface-patterns.md before composing the workspace. This section proves the workspace zones; the pattern library owns each AI-native control and state.

AI Workspace Shells Keep Evidence And Approval Beside The Work

The AI workspace shell owns zones, hierarchy, responsive behavior, and governance. Detailed AI-native controls still route to brand/ai-interface-patterns.md.

Collaboration, Review, And Shared Work

Shared work should make ownership, comments, approvals, evidence, permissions, conflicts, notifications, and client visibility explicit only where they change the task.

Reference AI Product Screens

These example screens are implementation contracts, not moodboards. They prove that the component system can support planning, content operations, and video generation without inventing new interaction logic.

• Each example must include desktop and 390px mobile behavior, not only a desktop composition.
• Each example must show one next useful decision and at least one failure or recovery state.
• Each example must use component contracts from this document and the full source spec, not local styling inventions.

React, Tailwind, And Shadcn-Style Implementation

The implementation bias is open, copied, token-first component ownership: use mature primitives for anatomy and accessibility, then restyle through INTO tokens, type, radius, density, and state rules.

Design QA Checklist

Reference Applications Must Be Buildable

The three reference applications are not moodboards. Each one needs enough primitives, states, responsive behavior, and QA proof for a coding AI to implement without guessing.

• Each reference app needs a desktop specimen, 390px mobile specimen, state inventory, keyboard path, and failure/recovery path.
• Final examples must show real data and one next useful decision, not placeholders or generic dashboards.
• If a reference app cannot satisfy this table, repair the system or app spec before building screens.

Responsive Behavior Is A Component Contract

Breakpoints, touch floors, gestures, data-collapse decisions, shell transitions, and density reflow are specified before screen implementation so mobile preserves the work instead of shrinking it.

Mobile Keeps Read, Approve, And Light Edit

The mobile interface is not a squeezed dashboard. It preserves the operator's primary task and moves dense tables into stacked record summaries.

GSAP And PixiJS Are Capabilities, Not Decoration

Use GSAP for precise interface sequencing and PixiJS for simple 2D canvas renderings only when static HTML, CSS, or SVG would make the interaction less clear or less performant.

gsap.matchMedia().add({
  reduceMotion: "(prefers-reduced-motion: reduce)"
}, ({ conditions }) => {
  return conditions.reduceMotion
    ? gsap.set(node, { autoAlpha: 1 })
    : gsap.to(node, { autoAlpha: 1, y: 0 });
});

const app = new Application();
await app.init({ resizeTo: container, backgroundAlpha: 0 });
container.appendChild(app.canvas);
app.ticker.add((ticker) => update(ticker.deltaTime));

Operational UX Is Part Of Styling

Core product surfaces must define lifecycle, permissions, audit trail, command palette, bulk actions, inline editing, sync, import/export, version history, null data, and destructive actions.

Keyboard, Semantics, And Recovery Are Mandatory

Dense operator tools need explicit keyboard models, screen-reader semantics, validation recovery, and null-data rules before they are implementation-ready.

Component-Specific Accessibility Checklist

Contrast Verification

Rules For AI Implementers

Agents must route here before using legacy app drafts or external component references.