docs: plan editorial presentation redesign

2026-07-05 16:42:44 +07:00
parent a8402a4d1d
commit 7749a1820d
6 changed files with 1778 additions and 46 deletions
@@ -0,0 +1,34 @@
+# Adopt Tailwind Additively For Source-Owned UI
+
+Status: accepted
+
+The web workspace will adopt Tailwind and shadcn-compatible conventions for
+new source-owned chat and presentation primitives because established AI-chat
+components provide better interaction and accessibility than maintaining a
+custom message surface. Existing console CSS will not be rewritten wholesale;
+old styles migrate only when their components are replaced.
+
+## Considered Options
+
+**Keep all styling hand-written.**
+This avoids another styling dependency, but repeats low-level work for chat,
+forms, focus states, and responsive composition. The existing presentation
+already demonstrates the cost of one-off component styling.
+
+**Rewrite the whole console with Tailwind and a component suite.**
+This creates one styling mechanism eventually, but turns presentation work into
+a risky console migration. It also lets framework defaults replace deliberate
+product decisions before those decisions are ready.
+
+**Adopt a complete AI application shell.**
+This supplies familiar chat interactions quickly, but also imports model,
+account, attachment, and transport assumptions that do not match the existing
+`AgentDriver` and workflow RPC boundaries.
+
+## Consequences
+
+Tailwind enters through the official Vite integration without Preflight, so it
+does not reset existing `/console` CSS. New source-owned primitives may follow
+shadcn-compatible structure and copy narrowly selected open-source components,
+while existing surfaces migrate only when replaced. The project retains
+ownership of component code, accessibility, tokens, and domain behavior.
@@ -0,0 +1,33 @@
+# Use An Editorial Canvas Around Shared Product Surfaces
+
+Status: accepted
+
+The defense presentation will keep one warm editorial identity and temporarily
+expand real shared console components within a persistent presentation frame.
+It will not switch the entire deck into a dark product theme or maintain
+presentation-only copies of product UI, because those approaches break
+narrative continuity and make the demo less credible.
+
+## Considered Options
+
+**Switch between light slides and a dark application stage.**
+This makes product moments visually distinct, but repeated whole-stage theme
+changes feel like separate applications and make transitions harder to follow.
+
+**Build presentation-only product replicas.**
+This gives complete control over appearance, but creates evidence that is
+visually persuasive while no longer being the actual product surface. Fixes and
+interaction behavior would also diverge between `/console` and `/present`.
+
+**Keep the current dashboard shell as the presentation.**
+This preserves working behavior, but persistent rails, controls, labels, and
+card grids compete with the argument and consume the limited `1280x720` frame.
+
+## Consequences
+
+The audience view uses one fixed, scalable `1280x720` Editorial Canvas. Shared
+console graphs, receipts, evidence, and approval forms may expand within it;
+presentation code owns framing and choreography rather than alternate product
+implementations. Locally dark terminal, code, or evidence insets remain valid
+when they communicate content type, but the main sequence does not switch its
+global theme.