System Requirements Document for giant-cafe

1. Introduction

giant-cafe is an AI agent that builds and runs a cafe for its owner. The product's intent, taken directly from the requester's own words, is an agent that can "build me my cafe with all the finances and the interiors and also reaching out customer feedback and many more" — that is, a single operating system in which the cafe is established, its money is tracked and reviewed, its interior is planned and managed, and its guests are reached out to and heard.

The audience is the independent cafe operator: the Cafe Owner who commissions the build-out and owns the outcome, the Cafe Manager who runs the day-to-day money, room, and guest voice, and the Customer who receives the cafe's outreach and supplies the feedback that closes the loop. The product is deliberately warm and craft-forward rather than enterprise-cold: it is a cheerful workshop for running a cafe, not an admin panel. The requester also asked for "all the billings and also the cost of menu and various items", so the cafe's billing records and the costs of its menu and other items are first-class parts of the money side of the product.

2. System Overview

giant-cafe is delivered as a first-party web application with an anonymous public entry, application-owned identity, and a protected operating workspace. The AI agent is the connective tissue of the product: it performs the cafe-building work (setup, finances, interiors, feedback outreach) and surfaces the results as reviewable, editable state that the owner and manager act on.

Actors. The accepted active-human catalog is exactly three roles: Cafe Owner, Cafe Manager, and Customer. Outbound feedback recipients (guests contacted by the cafe's outreach) are external recipients, not a fourth persona. The AI agent is a system actor, not a persona.

Accepted behavior. The agent establishes the cafe's core details; tracks and reviews the cafe's financial information, including the cafe's billing records and the costs of its menu and other items; plans and manages the cafe's interior design; and reaches out to customers for feedback and collects it. The owner and manager review and direct this work from a protected workspace; the customer receives outreach and submits feedback through a customer-facing destination.

Ownership. All twelve destinations are application-owned custom pages. Identity is application-owned: the Cafe Owner self-enrolls, returning users verify, the Cafe Manager is provisioned by an authorized owner or manager, and the Customer reaches the feedback destination through an invitation context. Background automation and external recipients are part of the delivery shape.

Narrow exclusions. This document does not add point-of-sale hardware integration, payroll, tax filing, supplier procurement, e-commerce, or any other adjacent capability that the source did not accept. "Many more" is preserved as an accepted expectation of further related cafe capabilities, not as a license to invent specific modules.

2a. Product Interpretation and Delivery Boundary

The requester asked for an AI agent that builds their cafe — finances, interiors, customer feedback, and more — and then asked for all the billings and the cost of the menu and various items. That is the whole current product. Everything in this document traces to one of those named areas or to the minimum mechanics needed to make them usable by a real owner, manager, and customer.

Delivery. giant-cafe is a first-party web application. The public entry (Landing) is anonymously reachable and explains what the agent does and who it is for. Identity is application-owned because the accepted journeys require durable, privately owned cafe records: an owner's cafe details, finances, and interior plans must persist and be resumable, and a customer's submitted feedback must remain bound to the correct guest. First-use enrollment is self-service for the Cafe Owner; the Cafe Manager is provisioned from inside the protected application by an authorized owner or manager; the Customer reaches the feedback destination through an invitation context rather than self-enrolling.

Current vs. future. All twelve pages and all requirements in this document are current. No future-horizon requirements were stated by the user; the "many more" expectation is recorded as an accepted open expectation rather than as a scheduled future feature set.

Access boundary. Landing is anonymous. Login and Sign Up are anonymous entry surfaces — a protected destination cannot own the interaction that establishes access to itself. Cafe Setup, Dashboard, Finances, Billing, Menu Costs, Interiors, Feedback Outreach, and Feedback are role-restricted to the Cafe Owner and Cafe Manager. Share Feedback is role-restricted to the Customer and is reached through the invitation context the cafe sends.

2b. Source Content Inventory

No reference directive in this project declares content_source authority, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains that giant-cafe is an AI agent that builds and runs a cafe — its finances, its billings, the cost of its menu and items, its interiors, and its customer feedback — and who it is for (independent cafe owners and their managers). Presents the hero headline "Build your cafe, run its money, hear its guests." and three live instrument readouts: "Revenue today £1,284", "Guest sentiment 4.7/5", "Interior tasks 3 open".
• Primary actions: Pill CTA "Start with your cafe" (routes to Sign Up); secondary text link "See how it works" (scrolls to the capability explanation on this page).
• Supporting actions: Navigate to Login for returning owners, managers, and customers.
• Domain entities: Capability summary (finances, interiors, feedback outreach), instrument readout values, audience description.
• Component responsibilities: Full-bleed three-panel colour-block hero (tomato red 42% left, cream 33% centre, deep teal 25% right) sliding up in a 60ms stagger; oversized Fraunces headline stacked across five lines with the final word "guests." overlapping the teal panel edge in tomato red; teal pill CTA with cream label; teal panel carrying the three instrument readouts in Jost 600 tabular figures separated by cream hairlines; curved section transitions into the capability explanation.
• States: Loading — panels and headline render immediately as static composition; instrument readouts show their values without a network dependency. Empty — not applicable; the page is static content. Success — CTA routes to Sign Up, secondary link scrolls. Error — if a readout value is unavailable it renders as a muted placeholder rather than a broken figure. Recovery — the page remains fully usable with placeholder readouts; no action is blocked.

Login

• Information/state: Anonymous returning-verification surface for Cafe Owner, Cafe Manager, and Customer. Collects the credentials that re-establish an existing identity.
• Primary actions: Submit credentials to verify and continue to the destination appropriate to the verified role (owner/manager → Dashboard; customer → Share Feedback).
• Supporting actions: Navigate to Sign Up for a first-time Cafe Owner; return to Landing.
• Domain entities: Identity credential, verified role, post-verification destination.
• Component responsibilities: Credential form with inline validation; role-aware post-verification routing; error region for failed verification.
• States: Loading — submit control shows a pending state while verification runs. Empty — form renders with empty fields. Success — identity verified, routed to the correct destination. Error — invalid credentials show an inline message and preserve entered values. Recovery — the user can retry immediately or navigate to Sign Up; no lockout is invented.

Sign Up

• Information/state: Anonymous first-use enrollment surface for the Cafe Owner. Establishes the owner's application-owned identity so their cafe records can be privately owned and resumed.
• Primary actions: Create the owner identity and continue into Cafe Setup.
• Supporting actions: Navigate to Login for an existing identity; return to Landing.
• Domain entities: Owner identity, enrollment input, resulting authenticated session.
• Component responsibilities: Enrollment form with inline validation; duplicate-identity handling; continuation into the protected workspace.
• States: Loading — submit control shows a pending state. Empty — form renders with empty fields. Success — identity created and the owner lands in Cafe Setup. Error — invalid or already-used input shows an inline message with entered values preserved. Recovery — the owner can correct and resubmit, or switch to Login.

Cafe Setup

• Information/state: Role-restricted to the Cafe Owner. The initial cafe-building activity: the agent establishes the cafe's core details and the owner confirms or edits them. Shows what the agent has established and what still needs the owner's input.
• Primary actions: Enter or confirm the cafe's core details; accept the agent's proposed setup; save the cafe so it becomes the workspace the rest of the product operates on.
• Supporting actions: Edit any agent-proposed value before saving; continue to Dashboard once the cafe exists.
• Domain entities: Cafe profile (name and core identifying details), agent-proposed setup values, setup completion state.
• Component responsibilities: Oversized page-title band; setup form with agent-proposed values pre-filled and editable; save/confirm control; completion indicator; continuation link into Dashboard.
• States: Loading — agent-proposed values show a pending state while they are prepared. Empty — a first-time owner sees an empty setup form with the agent's proposals as suggestions. Success — the cafe is saved and the owner is offered continuation to Dashboard. Error — a failed save shows an inline message and preserves all entered values. Recovery — the owner can retry the save; nothing already entered is lost.

Dashboard

• Information/state: Role-restricted to the Cafe Owner and Cafe Manager. The protected summary and continuation point for ongoing finance, billing, menu-cost, interior, and feedback work. Surfaces the current state of each area and what needs attention.
• Primary actions: Open Finances, Billing, Menu Costs, Interiors, Feedback Outreach, or Feedback to continue that work.
• Supporting actions: Return to Cafe Setup to revise the cafe's core details; provision a Cafe Manager.
• Domain entities: Cafe identity, finance summary figures, billing summary state, menu-cost summary state, interior task state, feedback and outreach summary state.
• Component responsibilities: Oversized page-title band; row of three to four instrument cards (squircle, hand-drawn walnut stroke icon, 12px uppercase Jost eyebrow, Fraunces 600 tabular number counting up once on first paint, hairline sparkline); full-width summary panels; left rail navigation with the active item marked by a tomato-red vertical bar and the cafe name set in Fraunces 600.
• States: Loading — instrument cards show their eyebrow and a pending figure. Empty — a newly created cafe shows zeroed figures and a prompt to begin in Finances, Billing, Menu Costs, Interiors, or Feedback Outreach. Success — current figures and task counts render. Error — a failed summary load shows a muted panel with a retry control. Recovery — retry reloads the summary; navigation to each workspace remains available regardless.

Finances

• Information/state: Role-restricted to the Cafe Owner and Cafe Manager. The revisitable workspace for the cafe's financial information: what the agent has tracked, what the owner or manager has entered, and how the figures stand.
• Primary actions: Add or update a financial entry; review the tracked financial position.
• Supporting actions: Filter or scan entries by period; return to Dashboard.
• Domain entities: Financial entry (amount, category, date, description), tracked financial position, period.
• Component responsibilities: Oversized page-title band; instrument cards with Fraunces 600 tabular figures that count up once on first paint; aligned label/value finance table with hairline row rules; schematic diagrammatic line art in Jost rather than stock charts; entry form.
• States: Loading — instrument cards and table show pending states. Empty — no entries yet: the table shows an empty state with a prompt to add the first entry. Success — entries and figures render, with the new or updated entry visible in the table. Error — a failed entry save or load shows an inline message and preserves entered values. Recovery — retry the save or reload; existing entries are never discarded by a failed operation.

Interiors

• Information/state: Role-restricted to the Cafe Owner and Cafe Manager. The workspace for planning and managing the cafe's interior design: the agent's proposed direction alongside the owner's or manager's own choices.
• Primary actions: Add or update an interior plan item; accept or revise the agent's proposed interior direction.
• Supporting actions: Review material and swatch references; return to Dashboard.
• Domain entities: Interior plan item (element, material, description, status), material swatch, interior task state.
• Component responsibilities: Oversized page-title band; two-column spread with a moodboard column of swatch and material tiles beside a spec column; flat material swatch tiles (terrazzo, oak, brass, linen); task status indicators.
• States: Loading — moodboard and spec columns show pending tiles. Empty — no interior items yet: both columns show an empty state with a prompt to add the first item or accept the agent's proposal. Success — items and swatches render with current status. Error — a failed save shows an inline message and preserves entered values. Recovery — retry the save; existing items remain intact.

Feedback Outreach

• Information/state: Role-restricted to the Cafe Owner and Cafe Manager. The workspace for reaching out to customers and managing requests for cafe feedback: who has been contacted, what was asked, and which requests are outstanding.
• Primary actions: Create and send a feedback outreach request to customers.
• Supporting actions: Review the status of outstanding and completed outreach; return to Dashboard.
• Domain entities: Outreach request (recipient, message, sent state), recipient list, outreach status.
• Component responsibilities: Oversized page-title band; outreach composer; status list of sent and outstanding requests; live-feedback beacon with a single slow 2.4s opacity breathe loop.
• States: Loading — the status list shows a pending state. Empty — no outreach sent yet: the list shows an empty state with a prompt to compose the first request. Success — the request is sent and appears in the status list as outstanding. Error — a failed send shows an inline message and preserves the composed message. Recovery — retry the send; the composed content is not lost.

Share Feedback

• Information/state: Role-restricted to the Customer, reached through the invitation context the cafe sends. The customer-facing destination for submitting feedback requested by the cafe. Shows the cafe's request and the feedback form.
• Primary actions: Submit feedback about the cafe.
• Supporting actions: Review what was asked before submitting; see acknowledgement that the feedback was received.
• Domain entities: Feedback submission (rating or sentiment, comment, category), invitation context, acknowledgement state.
• Component responsibilities: Cafe-identified request header; feedback form with rating and comment input; category selection; submission control; acknowledgement confirmation.
• States: Loading — the request context and form show a pending state. Empty — the form renders with no feedback entered. Success — the feedback is submitted and an acknowledgement confirms receipt. Error — a failed submission shows an inline message and preserves the entered feedback. Recovery — the customer can retry the submission without re-entering their feedback.

Feedback

• Information/state: Role-restricted to the Cafe Owner and Cafe Manager. The workspace for collecting and reviewing customer feedback: the guest voice as it arrives, organized so it can be acted on.
• Primary actions: Review collected feedback; act on a feedback item.
• Supporting actions: Scan by category; return to Dashboard.
• Domain entities: Feedback item (quote, category, sentiment, received date), category tab (tomato red for complaints, mustard for suggestions, sage for praise).
• Component responsibilities: Oversized page-title band; masonry grid of paper quote cards, each with a coloured category tab, a Fraunces pull-quote at 21px, and a walnut hairline rule; live-feedback beacon with a single slow 2.4s opacity breathe loop.
• States: Loading — the quote wall shows pending card placeholders. Empty — no feedback received yet: the wall shows an empty state with a prompt to send outreach. Success — feedback cards render in the masonry grid with their category tabs. Error — a failed load shows a muted panel with a retry control. Recovery — retry reloads the wall; existing cards are not lost.

3. Functional Requirements

FR-1 — AI agent builds the cafe. As a Cafe Owner, I should have an AI agent that builds my cafe for me, so that establishing the cafe does not require me to assemble every detail myself. (provenance: explicit; lifecycle: the owner initiates from Cafe Setup, the agent produces proposed cafe details, the owner confirms or edits them, and the saved cafe becomes the workspace the rest of the product operates on; failure/recovery: a failed save preserves all entered and proposed values and can be retried; continuation: the owner continues to Dashboard.)

FR-2 — Agent handles the cafe's finances. As a Cafe Owner, I should have the agent handle my cafe's finances, so that the money side of the cafe is tracked and reviewable in one place. (provenance: explicit; lifecycle: the owner or manager initiates from Finances, the agent tracks and presents the financial position, the human reviews it, and the tracked position persists for later review; failure/recovery: a failed entry save or load preserves entered values and can be retried; continuation: the user returns to Dashboard or continues adding entries.)

FR-3 — Agent handles the cafe's interiors. As a Cafe Owner, I should have the agent handle my cafe's interiors, so that the room's design is planned and managed rather than left to scattered notes. (provenance: explicit; lifecycle: the owner or manager initiates from Interiors, the agent proposes an interior direction, the human accepts or revises it, and the resulting plan persists; failure/recovery: a failed save preserves entered values and can be retried; continuation: the user returns to Dashboard or continues editing the plan.)

FR-4 — Agent handles customer feedback outreach. As a Cafe Owner, I should have the agent reach out to my customers for feedback, so that the guest voice is actively solicited rather than waited for. (provenance: explicit; lifecycle: the owner or manager initiates from Feedback Outreach, the agent sends the request to customers, the customer receives it and responds on Share Feedback, and the response arrives in Feedback; failure/recovery: a failed send preserves the composed message and can be retried; continuation: the user monitors outreach status and reviews arriving feedback.)

FR-5 — Additional related cafe capabilities. As a Cafe Owner, I should be able to expect additional related cafe capabilities beyond finances, interiors, and feedback, so that the agent can grow with the cafe's needs. (provenance: explicit; lifecycle: this is an accepted expectation of further related capability, not a scheduled feature set; no specific additional module is committed by this requirement; continuation: any future capability is added under a future horizon and does not alter current pages or acceptance.)

FR-6 — Cafe Owner self-service enrollment. As a Cafe Owner, I should be able to enroll myself on first use, so that I can begin building my cafe without waiting for someone else to create my access. (provenance: required_inference; lifecycle: the owner initiates from Sign Up while anonymous, establishes an application-owned identity, and lands in Cafe Setup; failure/recovery: invalid or already-used input shows an inline message with values preserved and can be corrected or switched to Login; continuation: the owner proceeds into Cafe Setup.)

FR-7 — Returning verification. As a Cafe Owner, Cafe Manager, or Customer, I should be able to verify my identity on return, so that I can resume my own durable cafe records or feedback. (provenance: required_inference; lifecycle: the returning user initiates from Login while anonymous, verification succeeds, and the user is routed to the destination appropriate to their role; failure/recovery: invalid credentials show an inline message with values preserved and can be retried immediately; continuation: owner/manager continue to Dashboard, customer continues to Share Feedback.)

FR-8 — Cafe Manager provisioning. As a Cafe Owner or Cafe Manager, I should be able to provision access for a Cafe Manager, so that day-to-day operational work can be shared. (provenance: required_inference; lifecycle: an authorized owner or manager initiates from inside the protected application, the manager identity is provisioned, and the manager can subsequently verify on return and reach Dashboard; failure/recovery: a failed provisioning shows an inline message and can be retried; continuation: the provisioned manager verifies at Login and continues into the protected workspace.)

FR-9 — Customer invitation context. As a Customer, I should receive an invitation context from the cafe that lets me submit the feedback it asked for, so that my response is bound to the correct cafe and to me. (provenance: required_inference; lifecycle: the cafe's outreach produces the invitation context, the customer opens Share Feedback with that context, submits feedback, and receives an acknowledgement; failure/recovery: a failed submission preserves the entered feedback and can be retried; continuation: the customer sees the acknowledgement confirming receipt.)

FR-10 — Cafe setup and confirmation. As a Cafe Owner, I should be able to enter or confirm my cafe's core details, so that the agent has a real cafe to operate on. (provenance: required_inference; lifecycle: the owner initiates from Cafe Setup, the agent proposes values, the owner confirms or edits them, and the cafe is saved; failure/recovery: a failed save preserves all values and can be retried; continuation: the owner continues to Dashboard.)

FR-11 — Financial entry and review. As a Cafe Owner or Cafe Manager, I should be able to add or update a financial entry and review the tracked position, so that the cafe's money stays current. (provenance: required_inference; lifecycle: the user initiates from Finances, enters or updates an entry, the tracked position updates, and the entry persists; failure/recovery: a failed save preserves entered values and can be retried; continuation: the user continues reviewing or returns to Dashboard.)

FR-12 — Interior plan management. As a Cafe Owner or Cafe Manager, I should be able to add or update an interior plan item and accept or revise the agent's proposed direction, so that the room's design stays current. (provenance: required_inference; lifecycle: the user initiates from Interiors, adds or updates an item or accepts the proposal, and the plan persists; failure/recovery: a failed save preserves entered values and can be retried; continuation: the user continues editing or returns to Dashboard.)

FR-13 — Outreach composition and sending. As a Cafe Owner or Cafe Manager, I should be able to compose and send a feedback outreach request to customers, so that the cafe actively solicits the guest voice. (provenance: required_inference; lifecycle: the user initiates from Feedback Outreach, composes the request, sends it, and the request appears as outstanding; failure/recovery: a failed send preserves the composed message and can be retried; continuation: the user monitors status and reviews arriving feedback in Feedback.)

FR-14 — Feedback submission by the customer. As a Customer, I should be able to submit feedback about the cafe, so that my experience is heard. (provenance: required_inference; lifecycle: the customer initiates from Share Feedback with the invitation context, enters and submits feedback, and receives an acknowledgement; failure/recovery: a failed submission preserves the entered feedback and can be retried; continuation: the customer sees the acknowledgement.)

FR-15 — Feedback collection and review. As a Cafe Owner or Cafe Manager, I should be able to collect and review customer feedback, so that the guest voice can be acted on. (provenance: required_inference; lifecycle: submitted feedback arrives in Feedback, the owner or manager reviews it by category, and acts on an item; failure/recovery: a failed load shows a muted panel with a retry control; continuation: the user returns to Dashboard or continues reviewing.)

FR-16 — Protected workspace summary and continuation. As a Cafe Owner or Cafe Manager, I should be able to see the current state of the cafe's finances, interiors, and feedback in one place and continue into any of them, so that ongoing work has a single continuation point. (provenance: required_inference; lifecycle: the user initiates from Dashboard, sees current figures and task counts, and opens the workspace they need; failure/recovery: a failed summary load shows a muted panel with a retry control while navigation remains available; continuation: the user opens Finances, Interiors, Feedback Outreach, or Feedback.)

4. User Personas

Cafe Owner

Product context. The Cafe Owner is the person who asked for an AI agent to build their cafe. They are the origin of the cafe in giant-cafe: they enroll themselves, establish the cafe's core details, and own the outcome of the money, the room, and the guest voice. They are the only role that can create the cafe in the first place.

Primary goal. To have a cafe that is actually established and running — its finances tracked, its billings and menu costs current, its interior planned, and its customers heard — without having to assemble all of that from scattered tools.

Distinct accepted responsibilities. The owner self-enrolls on first use (FR-6), establishes the cafe's core details with the agent (FR-1, FR-10), reviews and directs the cafe's finances (FR-2, FR-11), accepts or revises the agent's interior direction (FR-3, FR-12), directs feedback outreach (FR-4, FR-13), reviews collected feedback (FR-15), and can provision a Cafe Manager (FR-8). They hold the expectation of further related cafe capabilities (FR-5).

Relevant inputs and decisions. The cafe's core identifying details; whether to accept or edit the agent's proposed setup and interior direction; financial entries; the content of outreach requests; whether to provision a manager.

Interactions with other accepted participants. The owner provisions the Cafe Manager, who then shares the operational work. The owner's outreach reaches the Customer, whose response arrives back in the owner's Feedback workspace. The owner is the only role that can create the cafe; the manager cannot.

Observable success. The cafe exists and is saved; finances show current tracked figures; billing records and menu and item costs are current; the interior plan reflects the owner's accepted or revised direction; outreach has been sent and feedback has arrived and been reviewed.

Cafe Manager

Product context. The Cafe Manager is the recurring operational role. Running a cafe's finances, interiors, and customer feedback is day-to-day work, and the manager is provisioned by an authorized owner or manager rather than self-enrolling. They work inside the same protected workspace as the owner but do not create the cafe.

Primary goal. To keep daily operations on track — the money current, the room's setup up to date, and customer feedback followed up on.

Distinct accepted responsibilities. The manager verifies on return (FR-7), reviews the protected summary and continues into work (FR-16), adds or updates financial entries and reviews the tracked position (FR-11), maintains the cafe's billing records (FR-17), reviews and updates the costs of the menu and other items (FR-18), adds or updates interior plan items (FR-12), composes and sends feedback outreach (FR-13), reviews collected feedback and acts on it (FR-15), and can provision another Cafe Manager (FR-8).

Relevant inputs and decisions. Day-to-day financial entries; interior item updates; outreach message content; which feedback items to act on.

Interactions with other accepted participants. The manager is provisioned by the owner or another manager and works alongside the owner in the same protected workspace. The manager's outreach reaches the Customer, whose feedback the manager then reviews.

Observable success. Financial entries are current; interior items reflect the room as it stands; outreach has been sent and its status is visible; feedback has been reviewed and acted on.

Customer

Product context. The Customer is the guest whose voice the cafe is trying to hear. They do not enroll themselves and do not work inside the protected cafe workspace; they arrive through the invitation context the cafe's outreach sends and interact with a single customer-facing destination.

Primary goal. To easily share their experience of the cafe and see that it was received.

Distinct accepted responsibilities. The customer receives the cafe's outreach, opens Share Feedback with the invitation context (FR-9), submits feedback about the cafe (FR-14), and sees an acknowledgement confirming receipt.

Relevant inputs and decisions. Their rating or sentiment, their comment, and the category of their feedback; whether to submit at all.

Interactions with other accepted participants. The customer is reached by the owner's or manager's outreach and their submitted feedback arrives in the owner's and manager's Feedback workspace. The customer never sees the protected workspace.

Observable success. The feedback is submitted and an acknowledgement confirms it was received.

5. Core User Flows

Flow 1 — Cafe Owner: enroll and establish the cafe

1. The Cafe Owner arrives at Landing anonymously and reads what giant-cafe does: an AI agent that builds and runs a cafe's finances, interiors, and customer feedback.
2. The owner selects the pill CTA "Start with your cafe" and lands on Sign Up.
3. On Sign Up, the owner enters their enrollment details and submits. The application creates the owner's identity and an authenticated session.
4. The owner lands on Cafe Setup. The agent presents proposed core details for the cafe.
5. The owner reviews the proposals, edits any value that is wrong, and confirms. The cafe is saved.
6. Observable result: the cafe exists and is now the workspace the rest of the product operates on.
7. Failure/recovery: if the save fails, an inline message appears and every entered and proposed value is preserved; the owner retries the save.
8. Continuation: the owner continues to Dashboard.

Flow 2 — Cafe Owner: provision a Cafe Manager

1. From Dashboard, the Cafe Owner opens the manager provisioning control.
2. The owner provisions access for the Cafe Manager.
3. Observable result: the manager identity exists and can verify on return.
4. Failure/recovery: a failed provisioning shows an inline message and can be retried.
5. Continuation: the owner returns to Dashboard; the manager verifies at Login and continues into the protected workspace.

Flow 3 — Cafe Owner or Cafe Manager: track the cafe's finances

1. The user verifies at Login and is routed to Dashboard.
2. On Dashboard, the user sees the finance instrument card with its current figure and opens Finances.
3. On Finances, the user reviews the tracked financial position in the aligned label/value table and the instrument cards.
4. The user adds or updates a financial entry and saves it.
5. Observable result: the new or updated entry appears in the table and the tracked position reflects it.
6. Failure/recovery: a failed save shows an inline message and preserves the entered values; the user retries.
7. Continuation: the user continues reviewing entries or returns to Dashboard.

Flow 4 — Cafe Owner or Cafe Manager: plan the cafe's interiors

1. The user verifies at Login and is routed to Dashboard.
2. On Dashboard, the user sees the interior task count and opens Interiors.
3. On Interiors, the user reviews the agent's proposed interior direction in the moodboard column of swatch and material tiles beside the spec column.
4. The user accepts the proposal or revises it, and adds or updates an interior plan item.
5. Observable result: the interior plan reflects the accepted or revised direction and the item's status is current.
6. Failure/recovery: a failed save shows an inline message and preserves entered values; the user retries.
7. Continuation: the user continues editing or returns to Dashboard.

Flow 5 — Cafe Owner or Cafe Manager: reach out for customer feedback

1. The user verifies at Login and is routed to Dashboard.
2. On Dashboard, the user opens Feedback Outreach.
3. On Feedback Outreach, the user composes a feedback request and sends it to customers.
4. Observable result: the request appears in the status list as outstanding, and the live-feedback beacon breathes while the request is live.
5. Failure/recovery: a failed send shows an inline message and preserves the composed message; the user retries.
6. Continuation: the user monitors outreach status and moves to Feedback to review responses as they arrive.

Flow 6 — Customer: receive outreach and submit feedback

1. The Customer receives the cafe's feedback outreach, which carries the invitation context.
2. The customer opens Share Feedback with that context. If they are not already verified, they verify at Login and are routed back to Share Feedback.
3. On Share Feedback, the customer sees the cafe's request and the feedback form.
4. The customer enters their rating or sentiment, their comment, and a category, then submits.
5. Observable result: an acknowledgement confirms the feedback was received.
6. Failure/recovery: a failed submission shows an inline message and preserves the entered feedback; the customer retries without re-entering it.
7. Continuation: the customer's feedback is now available in the cafe's Feedback workspace.

Flow 7 — Cafe Owner or Cafe Manager: review collected feedback

1. The user verifies at Login and is routed to Dashboard.
2. On Dashboard, the user sees the guest sentiment figure and opens Feedback.
3. On Feedback, the user reviews the masonry wall of quote cards, each with its coloured category tab — tomato red for complaints, mustard for suggestions, sage for praise.
4. The user acts on a feedback item.
5. Observable result: the feedback has been reviewed and the action taken is reflected in the cafe's operations.
6. Failure/recovery: a failed load shows a muted panel with a retry control; the user retries and existing cards are not lost.
7. Continuation: the user returns to Dashboard or continues reviewing.

Flow 8 — Cafe Owner or Cafe Manager: resume work from the protected summary

1. The user verifies at Login and is routed to Dashboard.
2. On Dashboard, the user sees the current finance figures, interior task count, and feedback and outreach state in the instrument cards.
3. The user opens whichever workspace needs attention — Finances, Interiors, Feedback Outreach, or Feedback.
4. Observable result: the user is in the correct workspace with its current state loaded.
5. Failure/recovery: if the summary fails to load, a muted panel with a retry control appears while navigation to each workspace remains available.
6. Continuation: the user completes the work in that workspace and returns to Dashboard.

6. Visuals Colors and Theme

Muse: Charles & Ray Eames. Headline direction: "Build your cafe, run its money, hear its guests."

Warm modernism for the giant-cafe operating system: an ordered modular grid softened by mid-century colour harmonies and organic-modern shapes, so the product reads as a cheerful workshop rather than a cold admin panel.

Colour tokens (light mode).

Pure white #FFFFFF is forbidden as a ground. Blue and indigo primary buttons are forbidden. Dark-mode-first surfaces are forbidden — the product lives in warm daylight.

Typography.

• Headings: Fraunces at 500–600 weight with its soft 'wonk' axis engaged for display sizes. Tight leading (0.95–1.05), normal tracking. Numbers inside cards switch to Fraunces 600 with tabular figures for finance figures.
• Body: Jost.
• Labels and eyebrows: Jost 600 uppercase at 12–13px with 0.12em tracking.
• Scale: 1.333 modular — 12 / 14 / 16 / 21 / 28 / 37 / 50 / 66 / 88.
• Display sizes: clamp(44px, 9vw, 96px) on the landing headline; clamp(28px, 4.5vw, 40px) for page titles; 21px for section heads; 16px body; 14px UI; 12px labels.
• Line-height: 1.5 body, 1.05 display.
• Inter, Roboto, Arial, Helvetica, Poppins, and system-ui are forbidden for headings and body.

Shape language. Organic-modern and modular. Cards are 20px-radius rounded rectangles with 1px walnut hairlines and a soft 0 2px 0 rgba(43,38,34,0.06) offset shadow — no blur-bloom. Buttons are pill-shaped for actions and 10px-radius for toolbar controls. Section boundaries use gentle arcs (border-radius: 50% 50% 0 0 / 12% 12% 0 0) so the page reads as stacked curved panels rather than flat bands. Chart containers use a squircle (radius 28px) with a subtle woven dot texture in the background at 4% opacity.

Layout. Modular panel grid — 12 columns on desktop, 6 on tablet, 2 on mobile — with a persistent left rail (72px icon rail on mobile collapsed, 240px labelled rail on desktop) showing Cafes, Finances, Interiors, Feedback, Outreach. Content sits in gallery-like sequences: an oversized page-title band, then a row of 3–4 instrument cards, then full-width data panels. Finance tables use aligned label/value pairs with hairline row rules. Interiors uses a two-column spread: a moodboard column of swatch and material tiles beside a spec column. Feedback uses a wall of quote cards in a masonry grid, each with a coloured category tab.

Imagery. Warm photography of real cafe life — a barista's hands on a portafilter, a sunlit counter, a chalkboard menu, coffee and pastry still-lifes — shot on cream and walnut grounds with natural light and shallow depth of field. Interiors uses material swatches (terrazzo, oak, brass, linen) as flat tiles. Finance uses schematic diagrammatic line art rendered in Jost instead of stock charts. No 3D renders, no gradient blobs, no generic icon sets — icons are hand-drawn 2px strokes in walnut. Emoji and filled icon sets are forbidden.

7. Signature Design Concept

The colour-block stage. The public entry is a full-bleed warm-cream stage split into three vertical colour panels that slide in from the bottom on load in a 60ms stagger: a wide tomato-red panel on the left at 42%, a cream breathing panel in the centre at 33%, and a deep-teal panel on the right at 25%.

The centre cream panel holds the oversized Fraunces headline — "Build your cafe, run its money, hear its guests." — set at clamp(44px, 9vw, 96px), stacked across five lines, left-aligned, with its final word ("guests.") overlapping the teal panel edge in tomato red. Beneath the headline sits a pill CTA, "Start with your cafe", in teal with a cream label, and a secondary text link, "See how it works".

The teal panel carries a vertical stack of three live instrument readouts in Jost 600 tabular figures — "Revenue today £1,284", "Guest sentiment 4.7/5", "Interior tasks 3 open" — separated by cream hairlines. These are the product's three accepted areas rendered as instruments, not as marketing claims.

There is no centred headline, no gradient blob, and no floating device mockup. The composition is the product's own operating surface, staged as a poster.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief.

• Focal subject: the three-panel colour-block stage — tomato red, cream, and deep teal — with the oversized Fraunces headline set across all three panels.
• Input → transformation → outcome thesis: on load, the three panels slide up from the bottom edge in a 60ms stagger; the headline resolves across the panels with its final word breaking onto the teal panel in tomato red; the three instrument readouts settle into their stack. The outcome is a composed first frame that presents the product's three accepted areas as live instruments.
• Motion vocabulary: 400ms ease-out fade-up of 12px as sections enter the viewport; 60ms stagger on the hero panels; numbers in finance cards count up once on first paint (600ms, cubic-bezier(0.22,1,0.36,1)); hover states are quick 120ms colour fills with no bounce and no particles; a single slow 2.4s opacity breathe loop on the live-feedback beacon.
• Composed first frame: the three panels at rest, the headline fully legible across all three, the pill CTA and secondary link in place, and the three instrument readouts stacked in the teal panel separated by cream hairlines.
• Reduced-motion state: everything stops. The panels appear in their final positions without sliding, the headline and readouts are static, the count-up resolves immediately to its final value, and the live-feedback beacon holds a steady opacity. All readable text and controls remain whole and inside the viewport at 375px, 768px, and 1280px.

9. Non-Functional Requirements

NFR-1 — Warm-daylight surfaces. The product must never use pure white #FFFFFF as a ground; backgrounds are #F4EDE1 and surfaces are #FBF7F0. (provenance: explicit creative direction; rationale: the product lives in warm daylight and must not read as a cold admin panel.)

NFR-2 — Forbidden template look. The generic indigo/blue-on-white SaaS template is forbidden for this project. (provenance: explicit creative direction.)

NFR-3 — Typography fidelity. Headings must use Fraunces at 500–600 weight with the soft 'wonk' axis engaged for display sizes; body must use Jost. Inter, Roboto, Arial, Helvetica, Poppins, and system-ui are forbidden for headings and body. (provenance: explicit creative direction.)

NFR-4 — Accent discipline. Tomato red #E2542B is the single hot accent, reserved for the primary CTA, live-feedback pings, and active tab underlines. Mustard #D9A227 and sage #9BB39A are permitted only inside chart series and category chips, never as button fills. (provenance: explicit creative direction.)

NFR-5 — Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, and cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. (provenance: explicit creative direction; rationale: this rule takes precedence where a direction asks readable text or a control to be cropped.)

NFR-6 — Reduced motion. Everything stops under prefers-reduced-motion. Moving and scrollable content stops and shows whole items: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling. (provenance: explicit creative direction.)

NFR-7 — Icon style. Icons are hand-drawn 2px strokes in walnut. Emoji and filled icon sets are forbidden. (provenance: explicit creative direction.)

NFR-8 — Identity continuity. Application-owned identity is required so that an owner's cafe details, finances, and interior plans persist and are resumable, and so that a customer's submitted feedback remains bound to the correct guest. (provenance: required_inference; rationale: the accepted journeys create durable, privately owned records that must remain bound to the correct participant.)

NFR-9 — Access boundary integrity. A protected destination must not own the interaction that establishes access to itself. Landing, Login, and Sign Up are anonymously reachable; Cafe Setup, Dashboard, Finances, Interiors, Feedback Outreach, and Feedback are role-restricted to the Cafe Owner and Cafe Manager; Share Feedback is role-restricted to the Customer and reached through the invitation context. (provenance: required_inference; rationale: the accepted journeys require an anonymous entry boundary distinct from the protected workspace.)

NFR-10 — No differentiated permissions beyond the accepted roles. Application identity and session continuity do not establish differentiated permissions. The only role-based restriction established by the accepted scope is the boundary between the protected cafe workspace (Cafe Owner and Cafe Manager) and the customer-facing feedback destination (Customer). (provenance: required_inference; rationale: no authoritative source establishes finer-grained control or visibility over shared product state.)

10. Tech Stack

• Frontend: React — a first-party web application with the twelve accepted custom pages.
• Backend: Python / FastAPI — serves the agent's cafe-building work, financial tracking, interior planning, outreach, and feedback collection.
• Storage: appropriate persistent storage for cafe records, financial entries, billing records, menu and item costs, interior plan items, outreach requests, and feedback submissions, with identity records bound to the correct participant.
• Containerization: Docker / docker-compose for local and deployment packaging.
• Deployment: Kubernetes only when deployment scale requires it.

No source-specified technology was overridden; the stack above preserves the accepted delivery shape (custom UI, application-owned identity, background automation, external recipients).

11. Assumptions and Constraints

Assumptions.

• A-1. The AI agent is a system actor that performs cafe-building work and surfaces it as reviewable state; it is not a persona and does not replace the owner's or manager's decisions. (required_inference)
• A-2. "Many more" is an accepted expectation of further related cafe capabilities, not a commitment to any specific additional module. No additional module is added to current pages or acceptance. (explicit)
• A-3. The Cafe Manager is provisioned from inside the protected application by an authorized owner or manager rather than self-enrolling. (required_inference)
• A-4. The Customer reaches Share Feedback through the invitation context the cafe's outreach sends, rather than self-enrolling. (required_inference)
• A-5. Outbound feedback recipients are external recipients, not a fourth persona. (required_inference)
• A-6. The instrument readouts on Landing ("Revenue today £1,284", "Guest sentiment 4.7/5", "Interior tasks 3 open") are the creative direction's specified hero content and render as static composition values on the public entry. (explicit creative direction)

Constraints.

• C-1. Pure white grounds, blue/indigo primary buttons, gradient-blob heroes, centred headline-plus-single-blue-CTA heroes, dark-mode-first surfaces, photorealistic 3D product renders, abstract gradient blobs, emoji, and filled icon sets are excluded. (explicit creative direction)
• C-2. Inter, Roboto, Arial, Helvetica, Poppins, and system-ui are excluded for headings and body. (explicit creative direction)
• C-3. Mustard and sage are excluded as button fills. (explicit creative direction)
• C-4. No point-of-sale hardware integration, payroll, tax filing, supplier procurement, or e-commerce is added; the source did not accept them. (source boundary)
• C-5. The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit creative direction)

12. Glossary

• AI agent — the system actor that performs the cafe-building work: establishing the cafe, tracking finances, planning interiors, and reaching out for customer feedback. It is not a persona.
• Cafe Owner — the accepted persona who self-enrolls, establishes the cafe, and owns the outcome of its finances, interiors, and guest voice.
• Cafe Manager — the accepted persona provisioned by an authorized owner or manager who carries out recurring operational work in the protected workspace.
• Customer — the accepted persona who receives the cafe's feedback outreach and submits feedback through Share Feedback.
• Instrument card — a squircle card carrying a hand-drawn walnut stroke icon, a 12px uppercase Jost eyebrow, a Fraunces 600 tabular number that counts up once on first paint, and a hairline sparkline.
• Invitation context — the context carried by the cafe's outreach that lets a Customer reach Share Feedback with their response bound to the correct cafe and to them.
• Protected workspace — the role-restricted area comprising Cafe Setup, Dashboard, Finances, Billing, Menu Costs, Interiors, Feedback Outreach, and Feedback, available to the Cafe Owner and Cafe Manager.
• Outreach request — a feedback request composed and sent by the owner or manager to customers from Feedback Outreach.
• Feedback item — a submitted piece of customer feedback, rendered in Feedback as a paper quote card with a coloured category tab.
• Category tab — the coloured tab on a feedback quote card: tomato red for complaints, mustard for suggestions, sage for praise.
• Live-feedback beacon — the indicator with a single slow 2.4s opacity breathe loop that signals live feedback activity.