# Product

## Register

product

## Users

The primary users are the thesis author during defense preparation, demo
operators during a live presentation, and technical reviewers who need to see
how `lda.chat` works without reading raw workflow JSON. Secondary users are
future developers and agents using the console to inspect workflow lifecycle
records, source capabilities, runs, traces, and interrupt/resume boundaries.

Users are usually under time pressure: a defense, demo, review session, or
debugging pass. The interface should help them move quickly from a high-level
story to concrete evidence without forcing them to decode raw protocol payloads
first.

## Product Purpose

The console is the product-facing visual surface for `lda.chat`. It exists to
show that the workflow substrate is inspectable, operable, and explainable: an
operator can connect to a workflow server, inspect lifecycle records, view graph
structure, start or resume prepared workflows, and inspect raw/evaluated
evidence.

Presentation mode is not a generic slide deck. It is a cinematic product demo
surface for explaining the thesis: external planners propose actions, the
workflow substrate owns typed lifecycle state and deterministic execution, and
the resulting runs remain auditable through traces and evidence records.

Chat is a framing device, not the core product. It may introduce or narrate a
prepared workflow, but the main surfaces are the workflow graph, operation
blocks, presentation evidence receipt/inspector, lifecycle explorer, typed
interrupt/resume panel, and run trace.

Success means a viewer can answer three questions quickly:

- What does `lda.chat` own that an external AI agent does not own?
- How does a workflow move from authoring to deployment to execution?
- Where is the proof that a specific run happened and can be inspected?

## Brand Personality

The product should feel precise, competent, and cinematic.

The console should feel like a real technical product: calm, readable, and
trustworthy. The presentation route may be more theatrical: large text, clear
beats, animated panels, graph zooms, and staged evidence reveals. The showmanship
must support understanding, not cover missing substance.

The desired feel is closer to a polished developer tool plus a live product
walkthrough than a generic AI chat app.

## Anti-references

Do not make the console look like a generic AI chatbot. Avoid hand-rolled chat
components as the design foundation; if chat becomes important, adopt or adapt a
mature open-source assistant UI pattern instead of inventing message bubbles,
tool-call affordances, and composer behavior from scratch.

Do not let chat dominate presentation mode. Chat can slide in, collapse, or move
off-screen, but the workflow graph and evidence views carry the thesis.

Do not use playful or decorative styling inside the professional chat surface:
no funny display fonts, doodle shapes, novelty bubbles, or unclear controls.

Do not build a sleep-inducing slide deck that only lists architecture claims.
The presentation should tell a story through staged transitions and concrete
workflow evidence.

Do not overclaim the presence of a bundled autonomous AI-agent brain. The product
surface may demonstrate a prepared or scripted agent-like interaction, but the
core contribution remains the workflow substrate.

## Design Principles

1. **Evidence first.** Every impressive visual should have a path back to a
   workflow record, operation, run trace, or captured protocol response.
2. **Graph over transcript.** Use chat sparingly; prefer graph, lifecycle,
   operation, and evidence views for explaining the system.
3. **Cinematic, not cluttered.** Use large text, few items, and staged motion for
   presentation mode. Avoid dense panels unless the viewer deliberately opens
   them.
4. **Professional where users operate.** The `/console` surface should prioritize
   familiar product patterns, predictable components, readable tables, and clear
   failure states.
5. **Agent-facing, not agent-theater.** Show how external agents or scripted demo
   flows operate `wf`; do not imply that the UI itself proves a new planning
   algorithm.
6. **Adopt standard primitives.** Prefer proven component libraries and mature
   chat UI patterns over custom controls when the interaction is standard.

## Accessibility & Inclusion

Target WCAG 2.2 AA for normal product UI. Presentation mode should remain usable
on a 720p projector or screen, with large text, high contrast, and no dependency
on color alone to distinguish models, stages, or outcomes.

Motion should respect `prefers-reduced-motion`. Presentation animations may be
cinematic, but they must not block comprehension, hide important content, or make
manual navigation difficult.

Keyboard navigation matters for defense use: arrow keys should move beats,
Escape should close overlays, and clickable graph nodes or drawers should remain
reachable through standard focus behavior.