Building the Application Frontend

A working, testable frontend should be minimal, production-minded with clear pathways to connect CrewAI flows and crews in subsequent modules.

AI-assisted workflow with @frontend.eng

• Ask @frontend.eng to create a minimal frontend-funcional-spec.md, a React/TypeScript scaffold with one critical workflow, and stubbed services that return mocked data; keep the spec in the repo root and update it as code changes occur.

• Prompt template:

  • “Create frontend-funcional-spec.md for ‘Critical Research Workflow’ with Inputs, Run, Results, and History sections; generate a React/TypeScript app with a single route and a basic form + results page; add a lightweight FSM with idle → running → done; create stub services for startRun/getRunStatus; include a Spec Sync checklist to update after each commit.”

Implement with stubbed backend

• Services: implement startRun and getRunStatus stubs that return fixed mock payloads; skip streaming, tool-call details, and costs for now.
• Controls: Run and Reset only; avoid pause/cancel/retry-diff until later; show simple statuses: idle, running, done.
• State: a tiny finite-state machine with three states: idle → running → done; errors show an inline message with a Retry button using the same inputs.
• Accessibility: basic keyboard navigation and semantic headings; defer advanced accessibility and resilience until observability phase.

Make crew status obvious

• Status banner: show a banner at the top with current status and a short label, e.g., “Crew: running” or “Crew: done”; when idle, show “Crew: idle”.
• Status indicator: include a small colored pill or icon next to the label (gray for idle, blue for running, green for done, red for error) to make state legible at a glance without reading text.
• Last updated: display a “last updated” timestamp near the status label so users can tell stubs are working and the UI is responsive.
• Consistent phrasing: use the same wording for statuses in the banner, buttons, and inline messages to reduce cognitive load and avoid mismatches.

Keep the spec updated

• After each change, update the Spec Sync checklist in frontend-funcional-spec.md with item, status, and a one-line note on what changed; keep Contracts in sync with any prop or payload shape edits.
• Before merging, run a quick “spec-to-impl” pass: ensure names in code match names in the spec and remove any TODOs already addressed.

Testing and delivery

• Happy path only: one seeded example input; confirm the app accepts input, calls stubs, and renders a simple result; no edge cases required yet.
• Deliverables: a minimal running UI for one critical workflow, a short Loom or screenshots showing input → run → result, and a README with how to run locally and where CrewAI integration will connect next.