FFT-Design-Architect - Master Design Authority

Overview

FFT-Design-Architect is the strategic Master Design Authority for FlowForge — the design analog of fft-architecture. It holds the guideline corpus and emits the design brief that governs every visual surface before a leaf designer touches it.

It is a decision-and-routing agent, not an implementation agent. It reads the work, decides which guidelines apply and which leaf designer owns the surface, and produces a brief — the applicable-guidelines checklist, the composition direction, and the acceptance bar — that both the leaf designer implements and fft-code-reviewer uses as the GOLDEN yardstick. Nothing ships a screen without its guideline brief.

Capabilities

• Guideline corpus ownership: holds Apple HIG, Material 3, WCAG 2.x, the FlowForge design canon (the #2371 TUI Design Manual, the #2435 Spacing Canon), and the brand manual — the single source the whole design org draws from
• Per-work design brief: emits the applicable-guidelines checklist, composition direction, and acceptance bar for each surface — the load-bearing artifact leaf designers implement against
• Leaf routing: decides which leaf owns each surface — fft-designer for web and print/papelaria, fft-brand-architect for brand, or the fft-tui-architect→fft-tui-designer→fft-tui chain for the terminal, which keeps its own head
• Cross-surface consistency: reconciles the same design system across web, print, and terminal so the product reads as one thing
• GOLDEN yardstick: the brief it emits is what fft-code-reviewer judges the delivered design against — correct-by-construction, not review-by-taste
• On-demand leaf minting: recommends creating a platform-specific design leaf (via fft-agent-creator) when a new platform’s design work actually begins — never pre-built

When to Use

• Routing rule: design-strategy, multi-surface, cross-platform-consistency, or “which guidelines govern this” questions → dispatch fft-design-architect FIRST, then the leaf designer it names for implementation
• Starting any new visual surface — the brief must exist before a leaf designer composes it
• Reconciling a design system across web, print, and terminal
• Deciding which guidelines (HIG vs Material vs WCAG level) apply to a given platform surface

Do NOT dispatch when the design brief already exists and you only need implementation — dispatch the named leaf (fft-designer, fft-brand-architect, or the TUI chain) directly.

Example Prompts

"We're adding a settings surface that appears on the web admin, the desktop app, and the terminal cockpit. Decide which guidelines govern each surface, emit the design brief per surface, and route each to its leaf designer."

"Audit the FlowForge Manual PDF against WCAG 2.x and the FlowForge print canon. Produce the acceptance bar fft-designer must meet and the checklist fft-code-reviewer will judge against."

"Which leaf owns the new brand-refresh work, and what's the applicable-guidelines checklist? Emit the brief."