Apps & Interfaces · 07.12
Bounded Styling & Operability
Semantic tones, palettes, and shell modes bound what an agent can style; the operability gate enforces that a rendered action is a wired action.
A deterministic layout floor every surface passes through
Whether a surface came from the model generator, the deterministic scaffold, or a hand-authored ui_render call, it passes through the exact same repair pass before it's ever displayed — pure, model-free, and idempotent, mirroring the same philosophy as the workflow robustness auditor. That pass concretely: clamps absurd split-panel ratios, strips out data panels bound to a collection that doesn't actually exist (a dead panel is removed, not left to render an error), caps how many data panels a sparse App can have, removes garbled image-banner headers, drops empty layout containers, and guarantees every surface has a root theme instead of rendering unstyled.
Rendered is not the same as operable
A collection binding pointing at a table that no longer exists would render something — an empty or broken panel — without the repair pass catching it. The audit's whole point is closing that gap: a widget claiming to show live data must actually bind to real data, or it gets removed rather than shipped as a convincing-looking dead end. Styling itself stays bounded the same way — an agent picks from semantic tones, palettes, design languages, and shell modes, never arbitrary raw CSS, so a surface an agent authors always stays inside a coherent design system instead of drifting into one-off, unmaintainable styling per page.
Continue
Run monitors, approval gates, agent feeds, orchestration panels, code viewers, media galleries, and maps — the widget vocabulary beyond tables and forms.
An App runs several workflows as one pipeline. The App Orchestrator executes dependsOn chains and run-all — and 'order' is a display sort, not a dependency.