System Requirements Document for yoga-studio

1. Introduction

Stillwater Yoga is a small neighbourhood yoga studio. This product is its class booking web app: a single printed-object-feeling web application where visitors can read the studio's weekly class schedule, sign up, book or cancel a spot in a class, and buy class packs, where instructors get a dashboard of their own classes with attendee lists, and where the studio owner manages the studio's classes, instructors and members.

The audience is threefold: adult local practitioners (beginners, returning practitioners, prenatal and restorative regulars) who browse and book; a small instructor group of roughly two to six people who need to know who is expected in their classes; and one studio owner who keeps the class offering, the instructor roster and the member records current so that the schedule, bookings and assignments stay accurate.

The product intent is calm, tactile and human — a place with a body, a floor and a window, not a booking utility. The weekly schedule is the spine of the product, and booking, cancellation, class packs, attendee lists and owner management all reuse the same printed-timetable grammar.

2. System Overview

Stillwater Yoga is delivered as a first-party web application with application-owned identity. Anonymous visitors can read the weekly class schedule without an account. Signing up establishes a member identity; logging in verifies returning members, instructors and the studio owner so they can reach durable application state. Booking a spot, cancelling a spot, buying class packs, the instructor dashboard and all owner management destinations require an established, verified identity.

The current actors are the Visitor / Member, the Instructor and the Studio Owner. The Visitor / Member finds a suitable class in the weekly schedule, secures or releases a spot, and purchases class packs. The Instructor reviews their assigned classes and the attendee lists for those classes. The Studio Owner maintains the class offering, the instructor roster and the member records that the schedule and bookings depend on.

Current delivery covers: the public weekly schedule; self-service sign-up and returning login; booking and cancelling a spot; buying class packs; the instructor dashboard of assigned classes with attendee lists; and owner management of classes, instructors and members. Durable backend persistence holds bookings, cancellations, class packs, schedules, instructor assignments and member records.

Narrow exclusions: this document does not add payment processing beyond the accepted purchase of class packs, does not add attendance check-in, waitlists, messaging, reporting suites, or any capability not present in the accepted requirement thread. No blue or indigo primary or accent colour, and no violet-to-pink gradient background, appears anywhere in the product.

2a. Product Interpretation and Delivery Boundary

The studio's public face is the weekly schedule. Anyone can arrive at the Landing page, read what Stillwater Yoga is, and go straight into this week's timetable without creating an account. Reading the schedule is anonymous; acting on it is not. Booking a spot, cancelling a spot and buying class packs all change durable state that must remain bound to the correct person, so those destinations sit behind an established member identity. Instructors and the studio owner reach their own destinations through the same returning verification, and their work is scoped to their own classes or to the studio's records respectively.

Identity is application-owned. A new visitor establishes it themselves on the Sign Up page; a returning member, instructor or owner verifies it on the Login page. Instructor and owner access is provisioned or invited rather than self-selected, so role-restricted destinations are only reachable by the people the studio has placed in those roles.

Everything described in this document is current. Nothing in the accepted requirement thread is deferred to a future horizon, and no capability is claimed here that the studio has not asked for.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state: The studio's identity and the immediate reason to act. A full-bleed photographic hero of the studio floor with the word STILLWATER arranged in wet grey river stones; a deep water-green (#1F4E4A) painted band cutting diagonally across the lower third carrying the headline BREATHE. MOVE. RETURN. in Anton caps, flush left, three stacked lines; the wordmark small in the top-left of the green band; a horizontal row of uppercase Karla navigation labels separated by 1px ink rules. Beneath the band, on the paper ground, the live line "Next class: Today 6:15pm · Hatha · 3 spots left" in Karla with tabular numerals. A thin top ticker of studio news in uppercase Karla scrolls continuously and pauses on hover.
• Primary action: A single accent-orange button "SEE THIS WEEK'S SCHEDULE" with a hand-drawn arrow pointing right at it, leading into the weekly schedule.
• Supporting actions: Navigation labels into the schedule, sign-up and login; the ticker's news items.
• Domain entities: Studio identity, the next upcoming class (name, time, instructor, remaining spots), studio news items.
• Component responsibilities: Hero photograph frame (square-cropped, bled off the right edge, never covering readable text or controls); diagonal painted band; display headline; wordmark; navigation rule row; accent CTA; live next-class line; news ticker.
• States: Loading — the hero photograph and the live next-class line resolve independently; the headline, wordmark, navigation and CTA render immediately. Empty — when no upcoming class exists, the live line reads as a plain statement that no classes are currently scheduled and the CTA still leads to the schedule. Success — the hero, headline, CTA and live line are all present and legible at 375px, 768px and 1280px. Error — if the next-class line cannot be resolved, it is omitted rather than shown stale, and the CTA remains. Recovery — the visitor can always proceed to the schedule regardless of the live line's state.

Sign Up

• Information and state: Self-service enrollment for a visitor who wants to book or buy. Fields for the new member's name, email and password, presented as squared printed blocks with 2px radius. A short statement of what an account enables: booking a spot, cancelling a spot and buying class packs.
• Primary action: Create the member account and continue into the booking or purchase the visitor was pursuing.
• Supporting actions: Move to Login if the visitor already has an account; return to the schedule without enrolling.
• Domain entities: Member identity (name, email, credential).
• Component responsibilities: Enrollment form; field-level validation messaging; submit control; link to Login; link back to the schedule.
• States: Loading — the submit control shows a pending state and cannot be double-submitted. Empty — the form is blank with no error text. Success — the member identity is established and the visitor continues into the intended booking or purchase. Error — an email already in use, a malformed email, or a missing required field is reported against the specific field, and the entered values are preserved. Recovery — the visitor can correct the field and resubmit, or switch to Login.

Login

• Information and state: Returning verification for members, instructors and the studio owner. Fields for email and password. No role selector — the verified identity determines which destinations are reachable.
• Primary action: Verify the returning identity and continue to the destination the person was pursuing, or to the schedule.
• Supporting actions: Move to Sign Up; return to the schedule without verifying.
• Domain entities: Member, instructor and owner identity; the verified session.
• Component responsibilities: Verification form; field-level and form-level error messaging; submit control; link to Sign Up.
• States: Loading — the submit control shows a pending state and cannot be double-submitted. Empty — the form is blank with no error text. Success — the identity is verified and the person reaches their intended destination with their durable state intact. Error — incorrect credentials are reported without revealing which field was wrong, and the entered email is preserved. Recovery — the person can retry, or move to Sign Up.

Schedule

• Information and state: The weekly class schedule as a printed timetable. A persistent left rail on desktop holds the day-of-week strip vertically, stacked like a hand-lettered timetable; on mobile it becomes a horizontal scrolling day strip under the header. Rows are 72–88px tall and ruled by 1px ink lines; each row shows the time in tabular Karla, the class name in Anton caps, the instructor in Karla, and capacity as a row of small filled squares rather than a soft progress pill. The active day tab carries the accent. A circled "spots left" counter uses the accent. Small hand-drawn marks (a scribbled arrow, a circled date) appear as accents over the schedule. This page is anonymously readable.
• Primary action: Select a class row to book a spot in it.
• Supporting actions: Switch days via the day rail or the mobile day strip; move to Sign Up or Login when the visitor wants to act on a class; move to Class Packs.
• Domain entities: Class (name, day, time, instructor, capacity, spots remaining), day of the week, instructor name.
• Component responsibilities: Day rail / mobile day strip; timetable rows; tabular time column; capacity square row; per-row accent CTA; circled spots-left counter; hand-drawn accent marks; empty-week messaging.
• States: Loading — the timetable skeleton shows ruled rows in the printed grammar while class data resolves. Empty — a day or week with no classes shows a plain ruled statement that no classes are scheduled, with the day rail still navigable. Success — every class for the selected day is listed with time, name, instructor and capacity squares, and each row's CTA is reachable. Error — if the schedule cannot be loaded, a plain ruled message states so and offers a retry. Recovery — retry reloads the selected day; switching days re-attempts the load. Day changes swap the schedule with a hard horizontal wipe (clip-path, 180ms, no fade).

Class Booking

• Information and state: A focused destination for securing a spot in one selected class. The selected class is restated in the same row grammar as the schedule: time in tabular Karla, class name in Anton caps, instructor in Karla, capacity squares, and the circled spots-left counter in accent. The member's own booking state for that class is shown. Access is role-restricted to an established member identity.
• Primary action: Confirm the booking, which stamps the row: the capacity square fills and a small accent stamp scale-pops to 1.06 then settles at 1.0 in two frames, with a small accent mark that stays on the row.
• Supporting actions: Return to the schedule; move to Class Packs when the member has no usable pack; move to Cancel Booking for an existing booking.
• Domain entities: Class, member, booking (confirmed spot), class pack balance.
• Component responsibilities: Selected-class row; capacity squares; spots-left counter; confirm control; booking stamp; pack-balance notice; link to Cancel Booking.
• States: Loading — the selected class and the member's booking state resolve before the confirm control becomes actionable. Empty — a class with no remaining spots shows the capacity squares full and the confirm control unavailable with a plain explanation. Success — the booking is confirmed, the capacity square fills, the accent stamp fires, and the member's confirmed spot is visible. Error — a class that filled between selection and confirmation, or a booking that cannot be recorded, is reported plainly and the member is returned to the schedule with the current capacity. Recovery — the member can choose another class from the schedule, or cancel an existing booking to free a spot.

Cancel Booking

• Information and state: A focused destination for releasing a member's existing class spot. The member's current bookings are listed in the printed row grammar, each showing the class time, class name, instructor and the member's confirmed state. Access is role-restricted to an established member identity.
• Primary action: Confirm the cancellation of a specific booking, which leaves a faint hand-drawn strike-through on the member's name rather than deleting the record.
• Supporting actions: Return to the schedule; move to Class Booking to secure a different spot.
• Domain entities: Booking, class, member.
• Component responsibilities: Booking list in row grammar; per-booking cancel control; cancel confirmation using the accent; hand-drawn strike-through mark; empty-state messaging.
• States: Loading — the member's bookings resolve before any cancel control becomes actionable. Empty — a member with no bookings sees a plain ruled statement and a route back to the schedule. Success — the spot is released, the strike-through appears, and the class's capacity squares reflect the freed spot. Error — a cancellation that cannot be recorded is reported plainly and the booking remains confirmed. Recovery — the member can retry the cancellation or return to the schedule.

Class Packs

• Information and state: A destination for buying class packs for future bookings. Available packs are presented as squared printed blocks with 2px radius, each showing what the pack contains and its price. The member's current pack balance is shown. Access is role-restricted to an established member identity.
• Primary action: Buy a class pack, using the single accent CTA on the screen.
• Supporting actions: Return to the schedule to book with the pack; move to Class Booking.
• Domain entities: Class pack (contents, price), member, pack balance.
• Component responsibilities: Pack blocks; pack balance display; purchase control; purchase confirmation; error messaging.
• States: Loading — pack options resolve before the purchase control becomes actionable. Empty — when no packs are offered, a plain ruled statement says so and routes the member back to the schedule. Success — the pack is purchased and the member's balance reflects it immediately. Error — a purchase that cannot be completed is reported plainly and no balance change occurs. Recovery — the member can retry the purchase or return to the schedule.

Instructor Dashboard

• Information and state: The instructor's own workspace, showing their assigned classes and, for each, the attendee list. It keeps the printed rules but compresses to a denser 8-column grid with a sticky left column of sections. Each assigned class shows its day, time, class name and capacity in the same row grammar; the attendee list for a class names the members expected. Access is role-restricted to an instructor identity.
• Primary action: Open a class to read its attendee list.
• Supporting actions: Move between the instructor's assigned classes; move between sections via the sticky left column.
• Domain entities: Class, instructor assignment, attendee (member) list, booking.
• Component responsibilities: Assigned-class list; class row grammar; attendee list per class; sticky section column; empty-state messaging.
• States: Loading — assigned classes resolve before attendee lists are requested. Empty — an instructor with no assigned classes sees a plain ruled statement; a class with no attendees shows an empty attendee list rather than a blank panel. Success — every assigned class is listed with its current attendee list, reflecting bookings and cancellations. Error — a class whose attendee list cannot be loaded is marked plainly and can be retried individually. Recovery — retry the affected list; the rest of the dashboard remains usable.

Classes

• Information and state: The owner-facing browse and management destination for the studio's class offering. Classes are listed in the printed row grammar with day, time, class name, assigned instructor and capacity. Access is role-restricted to the studio owner.
• Primary action: Open a class to create or edit it on Class Details.
• Supporting actions: Create a new class; filter or scan the offering by day; move to Instructors and Members.
• Domain entities: Class, instructor assignment, capacity, schedule.
• Component responsibilities: Class list in row grammar; create control; per-class entry point to Class Details; empty-state messaging.
• States: Loading — the class list resolves before entries become actionable. Empty — a studio with no classes yet sees a plain ruled statement and the create control. Success — every class in the offering is listed with its current assignment and capacity. Error — a class list that cannot be loaded is reported plainly with a retry. Recovery — retry reloads the list.

Class Details

• Information and state: The focused owner workspace for creating or editing a class and its assignment. Fields cover the class name, day, time, capacity and assigned instructor, drawn from the instructor roster. Access is role-restricted to the studio owner.
• Primary action: Save the class, creating it or applying the edits.
• Supporting actions: Return to Classes; assign or change the instructor; remove a class from the offering.
• Domain entities: Class, instructor assignment, capacity, schedule.
• Component responsibilities: Class detail form; instructor selection from the roster; save control; removal control; validation messaging.
• States: Loading — an existing class's details resolve before the form becomes editable. Empty — a new class form starts blank with the instructor selection available. Success — the class is created or updated and the change is reflected in the schedule and in the assigned instructor's dashboard. Error — a missing required field, an invalid time, or a save that cannot be recorded is reported against the specific field and the entered values are preserved. Recovery — the owner can correct the field and resave, or return to Classes without saving.

Instructors

• Information and state: The owner-facing roster and management destination for instructors. Instructors are listed with their name and the classes currently assigned to them. Access is role-restricted to the studio owner.
• Primary action: Open an instructor to create or edit their record on Instructor Details.
• Supporting actions: Add a new instructor; move to Classes and Members.
• Domain entities: Instructor, class assignment.
• Component responsibilities: Instructor roster list; add control; per-instructor entry point to Instructor Details; empty-state messaging.
• States: Loading — the roster resolves before entries become actionable. Empty — a studio with no instructors yet sees a plain ruled statement and the add control. Success — every instructor is listed with their current class assignments. Error — a roster that cannot be loaded is reported plainly with a retry. Recovery — retry reloads the roster.

Instructor Details

• Information and state: The focused owner workspace for creating or editing an instructor record. Fields cover the instructor's name and contact details, alongside the classes currently assigned to them. Access is role-restricted to the studio owner.
• Primary action: Save the instructor record, creating it or applying the edits.
• Supporting actions: Return to Instructors; review and adjust the instructor's class assignments; remove an instructor from the roster.
• Domain entities: Instructor, class assignment.
• Component responsibilities: Instructor detail form; assignment list; save control; removal control; validation messaging.
• States: Loading — an existing instructor's record resolves before the form becomes editable. Empty — a new instructor form starts blank. Success — the record is created or updated and the change is reflected in the roster and in any class the instructor teaches. Error — a missing required field or a save that cannot be recorded is reported against the specific field and the entered values are preserved. Recovery — the owner can correct the field and resave, or return to Instructors without saving.

Members

• Information and state: The owner-facing browse and management destination for member records. Members are listed with their name and their current standing — bookings held and class pack balance. Access is role-restricted to the studio owner.
• Primary action: Open a member to create or edit their record on Member Details.
• Supporting actions: Add a new member; move to Classes and Instructors.
• Domain entities: Member, booking, class pack balance.
• Component responsibilities: Member list; add control; per-member entry point to Member Details; empty-state messaging.
• States: Loading — the member list resolves before entries become actionable. Empty — a studio with no members yet sees a plain ruled statement and the add control. Success — every member is listed with their current bookings and pack balance. Error — a member list that cannot be loaded is reported plainly with a retry. Recovery — retry reloads the list.

Member Details

• Information and state: The focused owner workspace for creating or editing a member record. Fields cover the member's name and contact details, alongside their current bookings and class pack balance. Access is role-restricted to the studio owner.
• Primary action: Save the member record, creating it or applying the edits.
• Supporting actions: Return to Members; review the member's bookings and pack balance; remove a member record.
• Domain entities: Member, booking, class pack balance.
• Component responsibilities: Member detail form; booking and pack summary; save control; removal control; validation messaging.
• States: Loading — an existing member's record resolves before the form becomes editable. Empty — a new member form starts blank. Success — the record is created or updated and the change is reflected in the member list. Error — a missing required field or a save that cannot be recorded is reported against the specific field and the entered values are preserved. Recovery — the owner can correct the field and resave, or return to Members without saving.

3. Functional Requirements

FR-1 — Read the weekly class schedule without an account (explicit) As a Visitor / Member, I should see the weekly class schedule so that I can find a class that suits me.

• Trigger: the visitor opens the Schedule page, or selects a day from the day rail or mobile day strip.
• Observable result: the selected day's classes are listed as printed timetable rows, each showing the time in tabular figures, the class name in Anton caps, the instructor, and capacity as a row of small filled squares, with the circled spots-left counter in accent.
• Access state: anonymous; no identity required to read the schedule.
• Failure/recovery: if the schedule cannot be loaded, a plain ruled message states so and offers a retry; switching days re-attempts the load.
• Continuation: the visitor selects a class row to book, or moves to Sign Up or Login to act.

FR-2 — Sign up as a new member (required_inference) As a Visitor / Member, I should sign up so that I can book a spot and buy class packs under my own identity.

• Trigger: the visitor chooses to book or buy and has no account, or opens Sign Up directly.
• Input: the new member's name, email and password.
• Observable result: a member identity is established and the visitor continues into the booking or purchase they were pursuing.
• Access state: anonymous entry; the Sign Up page itself requires no identity.
• Failure/recovery: an email already in use, a malformed email, or a missing required field is reported against the specific field with the entered values preserved; the visitor can correct and resubmit, or switch to Login.
• Continuation: the visitor proceeds to Class Booking or Class Packs.

FR-3 — Log in as a returning member, instructor or owner (required_inference) As a Visitor / Member, Instructor or Studio Owner, I should log in so that I can reach the durable state tied to my identity.

• Trigger: a returning person opens Login, or is directed there when reaching a role-restricted destination.
• Input: email and password.
• Observable result: the identity is verified and the person reaches the destination they were pursuing, with their bookings, pack balance, assigned classes or studio records intact.
• Access state: anonymous entry; the Login page itself requires no identity.
• Failure/recovery: incorrect credentials are reported without revealing which field was wrong, and the entered email is preserved; the person can retry or move to Sign Up.
• Continuation: the member proceeds to the schedule, booking, cancellation or packs; the instructor proceeds to the Instructor Dashboard; the owner proceeds to Classes, Instructors or Members.

FR-4 — Provision or invite instructor and owner access (required_inference) As a Studio Owner, I should have instructor and owner access provisioned or invited rather than self-selected, so that role-restricted destinations are only reachable by the people the studio has placed in those roles.

• Trigger: the studio places a person in the instructor or owner role.
• Observable result: that person can verify their identity on Login and reach the destinations their role owns; a self-service sign-up does not grant instructor or owner access.
• Access state: role-restricted destinations remain unavailable until the role is provisioned and the identity verified.
• Failure/recovery: a person without the role who reaches a role-restricted destination is returned to Login.
• Continuation: the instructor reaches the Instructor Dashboard; the owner reaches Classes, Instructors and Members.

FR-5 — Book a spot in a class (explicit) As a Visitor / Member, I should book a spot in a class so that I hold a confirmed place in it.

• Trigger: the member selects a class row on the Schedule page and confirms on Class Booking.
• Input: the selected class and the member's confirmation.
• Observable result: the booking is confirmed; the class's capacity square fills, a small accent stamp scale-pops to 1.06 then settles at 1.0 in two frames, and a small accent mark stays on the row.
• Access state: role-restricted to an established member identity.
• Failure/recovery: a class that filled between selection and confirmation, or a booking that cannot be recorded, is reported plainly and the member is returned to the schedule with the current capacity; the member can choose another class or cancel an existing booking to free a spot.
• Continuation: the member's confirmed spot appears in their bookings and in the instructor's attendee list for that class.

FR-6 — Cancel a spot in a class (explicit) As a Visitor / Member, I should cancel a spot in a class so that I release a place I can no longer attend.

• Trigger: the member opens Cancel Booking and confirms the cancellation of a specific booking.
• Observable result: the spot is released, a faint hand-drawn strike-through is left on the member's name rather than deleting the record, and the class's capacity squares reflect the freed spot.
• Access state: role-restricted to an established member identity.
• Failure/recovery: a cancellation that cannot be recorded is reported plainly and the booking remains confirmed; the member can retry or return to the schedule.
• Continuation: the freed spot becomes available on the schedule, and the instructor's attendee list for that class reflects the change.

FR-7 — Buy class packs (explicit) As a Visitor / Member, I should buy class packs so that I have credit for future bookings.

• Trigger: the member opens Class Packs and buys a pack.
• Input: the selected pack.
• Observable result: the pack is purchased and the member's pack balance reflects it immediately.
• Access state: role-restricted to an established member identity.
• Failure/recovery: a purchase that cannot be completed is reported plainly and no balance change occurs; the member can retry or return to the schedule.
• Continuation: the member returns to the schedule to book with the pack.

FR-8 — See my own classes and their attendee lists (explicit) As an Instructor, I should get a dashboard of my classes with attendee lists so that I know who is expected in each class I teach.

• Trigger: the instructor opens the Instructor Dashboard.
• Observable result: each of the instructor's assigned classes is listed with its day, time, class name and capacity, and each class's attendee list names the members expected.
• Access state: role-restricted to an instructor identity.
• Failure/recovery: a class whose attendee list cannot be loaded is marked plainly and can be retried individually while the rest of the dashboard remains usable.
• Continuation: the instructor reads the attendee list for each class; the lists reflect bookings and cancellations as they happen.

FR-9 — Manage classes (explicit) As a Studio Owner, I should manage classes so that the studio's offering and the schedule stay current.

• Trigger: the owner opens Classes and creates a class or opens an existing one on Class Details.
• Input: class name, day, time, capacity and assigned instructor.
• Observable result: the class is created or updated, and the change is reflected in the schedule and in the assigned instructor's dashboard.
• Access state: role-restricted to the studio owner.
• Failure/recovery: a missing required field, an invalid time, or a save that cannot be recorded is reported against the specific field with the entered values preserved; the owner can correct and resave, or return to Classes without saving.
• Continuation: the owner returns to Classes, or assigns a different instructor.

FR-10 — Manage instructors (explicit) As a Studio Owner, I should manage instructors so that the roster and the class assignments stay accurate.

• Trigger: the owner opens Instructors and adds an instructor or opens an existing one on Instructor Details.
• Input: the instructor's name and contact details, and their class assignments.
• Observable result: the instructor record is created or updated, and the change is reflected in the roster and in any class the instructor teaches.
• Access state: role-restricted to the studio owner.
• Failure/recovery: a missing required field or a save that cannot be recorded is reported against the specific field with the entered values preserved; the owner can correct and resave, or return to Instructors without saving.
• Continuation: the owner returns to Instructors, or adjusts the instructor's class assignments.

FR-11 — Manage members (explicit) As a Studio Owner, I should manage members so that the member records that bookings and packs depend on stay accurate.

• Trigger: the owner opens Members and adds a member or opens an existing one on Member Details.
• Input: the member's name and contact details.
• Observable result: the member record is created or updated, and the change is reflected in the member list alongside that member's bookings and pack balance.
• Access state: role-restricted to the studio owner.
• Failure/recovery: a missing required field or a save that cannot be recorded is reported against the specific field with the entered values preserved; the owner can correct and resave, or return to Members without saving.
• Continuation: the owner returns to Members, or reviews the member's bookings and pack balance.

FR-12 — Durable persistence of studio state (required_inference) As a Visitor / Member, Instructor and Studio Owner, I should have my bookings, cancellations, class packs, schedules, instructor assignments and member records persisted durably, so that the state I see is the state the studio actually holds.

• Trigger: any accepted action that changes studio state — a booking, a cancellation, a pack purchase, or an owner edit to a class, instructor or member.
• Observable result: the change survives the session and is visible to every participant whose view depends on it: the member's bookings and balance, the schedule's capacity, the instructor's attendee lists, and the owner's records.
• Access state: reads of durable member-specific state require an established identity; the public schedule remains anonymously readable.
• Failure/recovery: a change that cannot be persisted is reported to the actor who attempted it and is not shown as applied.
• Continuation: the affected participant sees the persisted state on their next view.

4. User Personas

Visitor / Member

Product context. An adult local practitioner — a beginner, a returning practitioner, a prenatal or restorative regular — who comes to Stillwater Yoga's web app to find a class and take a place in it. They arrive most often without an account, read the weekly schedule, and only then decide whether to act.

Primary goal. To hold a confirmed spot in the classes they want, and to have usable class packs for future bookings.

Distinct accepted responsibilities. Reading the weekly class schedule anonymously; signing up to establish their own member identity; booking a spot in a chosen class; cancelling a spot they can no longer attend; buying class packs. Their work is the only work in the product that begins anonymously and converts into an identity.

Relevant inputs and decisions. Which day and which class suit them; whether a class still has spots; whether to book now or buy a pack first; whether to release a spot they cannot use. They read the circled spots-left counter and the capacity squares to make these decisions.

Interactions with other accepted participants. Their booking is what populates the instructor's attendee list, and their cancellation is what removes them from it and frees a spot on the schedule. Their member record is what the studio owner maintains on the Members and Member Details pages.

Observable success. A confirmed spot visible in their bookings with the accent stamp on the row; a pack balance that reflects their purchase; a released spot with the hand-drawn strike-through left in place rather than the record vanishing.

Instructor

Product context. One of a small group of roughly two to six instructors teaching at Stillwater Yoga. They do not manage the studio's offering and do not browse other instructors' classes; they need to know who is expected in the classes they themselves teach.

Primary goal. To have accurate, up-to-date class and attendee information for the classes they teach.

Distinct accepted responsibilities. Reviewing their assigned classes on the Instructor Dashboard and reading the attendee list for each of those classes. Their work is read-only and scoped to their own assignments.

Relevant inputs and decisions. Which of their classes is coming up; how many members are expected against the class capacity; whether an attendee list has changed since they last looked.

Interactions with other accepted participants. Their assigned classes are set by the studio owner on Class Details. Their attendee lists are produced by members' bookings and cancellations, so the lists change without the instructor acting.

Observable success. Every assigned class listed with its current attendee list, reflecting bookings and cancellations as they happen, with any list that failed to load marked plainly and retryable on its own.

Studio Owner

Product context. The single owner of Stillwater Yoga, running a tiny operational back office. They are the only person who maintains the studio's records, and everything the schedule, bookings and instructor assignments depend on flows from their work.

Primary goal. A current, accurate studio operation reflected in the schedule, bookings and instructor assignments.

Distinct accepted responsibilities. Managing classes — creating and editing the class offering and its instructor assignments; managing instructors — maintaining the roster and their class assignments; managing members — maintaining member records. They also provision or invite instructor and owner access.

Relevant inputs and decisions. The class name, day, time and capacity; which instructor teaches which class; an instructor's name and contact details; a member's name and contact details. They decide when a class is added to or removed from the offering and when an instructor joins or leaves the roster.

Interactions with other accepted participants. Their class edits appear immediately in the schedule that members read and in the instructor's dashboard. Their instructor assignments determine whose dashboard shows which class. Their member records are the records behind members' bookings and pack balances.

Observable success. A class created or edited on Class Details showing correctly in the schedule and in the assigned instructor's dashboard; an instructor record reflected in the roster and in the classes they teach; a member record reflected in the member list alongside that member's bookings and pack balance.

5. Core User Flows

Flow 1 — A visitor reads the weekly schedule and books a spot (Visitor / Member)

1. The visitor arrives at the Landing page with no account. The full-bleed hero shows the studio floor with STILLWATER arranged in wet river stones, the headline BREATHE. MOVE. RETURN. set into the diagonal water-green band, and the live line "Next class: Today 6:15pm · Hatha · 3 spots left" in tabular Karla.
2. The visitor presses the single accent-orange button "SEE THIS WEEK'S SCHEDULE", following the hand-drawn arrow.
3. On the Schedule page the visitor reads the printed timetable: the vertical day rail on desktop (a horizontal scrolling day strip on mobile), rows ruled by 1px ink lines, times in tabular Karla, class names in Anton caps, instructors in Karla, and capacity as rows of small filled squares. The circled spots-left counter is in accent.
4. The visitor switches days using the day rail. The schedule swaps with a hard horizontal wipe (clip-path, 180ms, no fade). The visitor finds a class with spots remaining and selects its row.
5. Because booking changes durable state bound to a person, the visitor is directed to Sign Up. They enter their name, email and password and submit. The member identity is established and they continue into the booking they were pursuing.
6. On the Class Booking page the selected class is restated in the same row grammar, with the member's own booking state and the circled spots-left counter. The member confirms.
7. The booking is confirmed: the capacity square fills, a small accent stamp scale-pops to 1.06 then settles to 1.0 in two frames, and a small accent mark stays on the row. The member's confirmed spot is visible.
8. Failure and recovery: if the class filled between selection and confirmation, or the booking cannot be recorded, a plain message states so and the member is returned to the schedule showing the current capacity. They can choose another class, or cancel an existing booking to free a spot.
9. Continuation: the member's confirmed spot appears in their bookings and in the instructor's attendee list for that class.

Flow 2 — A returning member cancels a spot (Visitor / Member)

1. The member opens Login and enters their email and password. Their identity is verified and their durable state — bookings and pack balance — is intact.
2. The member opens Cancel Booking, where their current bookings are listed in the printed row grammar with class time, class name, instructor and their confirmed state.
3. The member selects the booking they can no longer attend and confirms the cancellation, using the accent confirm.
4. The spot is released. A faint hand-drawn strike-through is left on the member's name rather than the record being deleted, and the class's capacity squares reflect the freed spot.
5. Failure and recovery: if the cancellation cannot be recorded, a plain message states so and the booking remains confirmed. The member can retry or return to the schedule.
6. Continuation: the freed spot becomes available on the schedule, and the instructor's attendee list for that class reflects the change.

Flow 3 — A member buys a class pack (Visitor / Member)

1. The member opens Class Packs with a verified identity. Available packs are shown as squared printed blocks with 2px radius, each stating what the pack contains and its price, alongside the member's current pack balance.
2. The member selects a pack and buys it using the single accent CTA on the screen.
3. The pack is purchased and the member's balance reflects it immediately.
4. Failure and recovery: if the purchase cannot be completed, a plain message states so and no balance change occurs. The member can retry or return to the schedule.
5. Continuation: the member returns to the Schedule to book with the pack, or moves to Class Booking.

Flow 4 — An instructor reviews their classes and attendee lists (Instructor)

1. The instructor opens Login and verifies their identity. Because their instructor access was provisioned or invited by the studio, they reach the destinations their role owns.
2. On the Instructor Dashboard their assigned classes are listed in the printed row grammar — day, time, class name and capacity — on the denser 8-column grid with the sticky left column of sections.
3. The instructor opens a class to read its attendee list, which names the members expected.
4. The instructor moves between their assigned classes and between sections using the sticky left column.
5. Failure and recovery: if a class's attendee list cannot be loaded, that class is marked plainly and can be retried on its own while the rest of the dashboard remains usable.
6. Continuation: the instructor reads the current attendee list for each class. The lists reflect members' bookings and cancellations as they happen, so the instructor sees changes without acting.

Flow 5 — The studio owner manages the class offering (Studio Owner)

1. The owner opens Login and verifies their identity, reaching the destinations their owner role owns.
2. On Classes the studio's offering is listed in the printed row grammar with day, time, class name, assigned instructor and capacity.
3. The owner creates a new class or opens an existing one, arriving at Class Details.
4. On Class Details the owner enters or edits the class name, day, time and capacity, and assigns an instructor drawn from the roster. They save.
5. The class is created or updated, and the change is reflected in the schedule that members read and in the assigned instructor's dashboard.
6. Failure and recovery: a missing required field, an invalid time, or a save that cannot be recorded is reported against the specific field with the entered values preserved. The owner corrects the field and resaves, or returns to Classes without saving.
7. Continuation: the owner returns to Classes, or adjusts the instructor assignment.

Flow 6 — The studio owner manages the instructor roster (Studio Owner)

1. With a verified owner identity, the owner opens Instructors, where the roster is listed with each instructor's name and the classes currently assigned to them.
2. The owner adds a new instructor or opens an existing one, arriving at Instructor Details.
3. On Instructor Details the owner enters or edits the instructor's name and contact details, and reviews the classes currently assigned to them. They save.
4. The record is created or updated, and the change is reflected in the roster and in any class the instructor teaches.
5. Failure and recovery: a missing required field or a save that cannot be recorded is reported against the specific field with the entered values preserved. The owner corrects the field and resaves, or returns to Instructors without saving.
6. Continuation: the owner returns to Instructors, or adjusts the instructor's class assignments. The instructor, once provisioned, can verify on Login and see those classes on their dashboard.

Flow 7 — The studio owner manages member records (Studio Owner)

1. With a verified owner identity, the owner opens Members, where member records are listed with each member's name and their current standing — bookings held and class pack balance.
2. The owner adds a new member or opens an existing one, arriving at Member Details.
3. On Member Details the owner enters or edits the member's name and contact details, and reviews that member's current bookings and pack balance. They save.
4. The record is created or updated, and the change is reflected in the member list.
5. Failure and recovery: a missing required field or a save that cannot be recorded is reported against the specific field with the entered values preserved. The owner corrects the field and resaves, or returns to Members without saving.
6. Continuation: the owner returns to Members, or reviews the member's bookings and pack balance.

6. Visuals Colors and Theme

Muse and headline. Stefan Sagmeister — handmade stillness: breath, water and type built from real material. The headline idea is type you can touch: the studio's name physically arranged in wet river stones, class names built from coiled rope, BREATHE lettered in chalk on a dark wood floor. The register is calm, tactile and human — quiet, but not clinical, and never corporate. It must feel like a place with a body, a floor, a window — not a booking utility.

Colour tokens (light mode).

Proportion roughly 70% paper/natural, 20% ink and water green, 10% accent. No blue anywhere. No gradient backgrounds — colour arrives as flat paint, rope, water or paper. The accent appears only as the painted 6px block sliding in on row hover, the single CTA on a screen, the circled spots-left counter, the active day tab, and the cancel confirm.

Typography.

• Headings: Anton, display scale, all-caps, tracking -0.02em, leading 0.86. Headlines behave like painted signage, stacked in 2–3 short lines that fill the measure edge to edge. Never more than six words per headline.
• Small headings and labels: Karla 700 uppercase at 12–13px with +0.14em tracking — the quiet voice under the loud one.
• Body: Karla.
• Numerals in the schedule use Karla tabular figures so times line up like a printed timetable.
• Scale, 1.333 modular: display clamp(44px, 9vw, 128px) (44px mobile → 96px at 768px → 128px at 1280px); h2 28/40/56; h3 20/24/28; body 16/17/18; label 12/12/13; caption 13/13/14.
• Line-height: 0.86 display, 1.6 body, 1.25 labels.

Shape language. Hard edges and honest rectangles — almost no border radius except 2px on inputs and buttons, so controls read as printed blocks rather than app pills. Rules are 1px solid #171512, or 2px for section breaks. Photographic frames sit square and flush, sometimes deliberately rotated 1.5–2.5 degrees off-axis like a print pasted slightly crooked. Painted brush-stroke bands (a real scanned texture, not a CSS gradient) separate sections, and hand-cut paper shapes — a circle, an arc, a wave — sit behind or beside type, never over it. Nothing glows, nothing floats, no soft shadow blur beyond a 2px hard offset.

Layout. Asymmetric editorial grid on 12 columns with a 2px black rule system. A persistent left rail on desktop holds the day-of-week strip vertically, stacked like a hand-lettered timetable; on mobile it becomes a horizontal scrolling day strip under the header. The weekly schedule is the spine: rows 72–88px tall, each row = time (tabular) | class name in Anton caps | instructor in Karla | a capacity bar drawn as a row of small filled squares | a single accent CTA. Booking, cancel and pack pages reuse the same row grammar so the whole app feels like one printed object. Owner and instructor dashboards keep the same rules but compress to a denser 8-column grid with a sticky left column of sections. Every text block is a single column capped at 68ch.

Imagery. Art-directed photography of handmade typography and real material, shot for this studio: the word STILLWATER spelled in wet river stones on a studio floor; a class name built from coiled rope; the word BREATHE lettered in chalk on a dark wood floor; a hand-painted paper sign taped to the studio window. Alongside these, one or two warm, unpolished photographs of the room — light on a wooden floor, a stack of folded blankets, a rolled mat, a window with condensation — always square-cropped, sometimes tilted, sometimes bled off the right edge. No stock yoga silhouettes, no lotus icons, no gradient blobs, no 3D renders. Small hand-drawn marks (a scribbled arrow, a circled date) appear as accents over the schedule.

Readability rule. Headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, and no other element covers 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 edge by design and is judged by whether it actually moves and whether every item becomes fully readable as it passes. Under prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row.

7. Signature Design Concept

The printed timetable as the studio's front door.

The Landing page is a full-bleed photographic hero, not a centred text block: a close, slightly overhead shot of the studio floor where the word STILLWATER has been arranged in wet grey river stones, water still pooling in the gaps and catching light. The photograph occupies the entire first screen at 1280px. A deep water-green (#1F4E4A) painted band cuts diagonally across its lower third, and the headline BREATHE. MOVE. RETURN. sits inside that band in Anton caps at clamp(44px, 9vw, 128px), flush left, three stacked lines filling the measure, in paper #F7F3EA. There is no logo lockup centred at the top — the wordmark sits small in the top-left of the green band, and navigation is a horizontal row of uppercase Karla labels separated by 1px ink rules.

Beneath the band, on the paper ground, a single accent-orange button SEE THIS WEEK'S SCHEDULE carries a hand-drawn arrow pointing right at it, and to its right the live line "Next class: Today 6:15pm · Hatha · 3 spots left" sits in Karla with tabular numerals. That live line is the concept's hinge: the hero is not a poster, it is the studio's actual next class, and the timetable is one press away.

At 375px the photograph crops to the stones and the first word only; the green band becomes a full-width block below it with the headline at 44px, and the CTA stacks under the live line, everything fully inside the viewport.

The concept carries through the whole product as one printed object. The Schedule page is the same idea at working scale: a vertical day rail down the left (a horizontal scroll strip on mobile), rows ruled by 1px ink lines, class names in Anton caps, times in tabular Karla, and capacity shown as a row of small filled squares that stamp in one by one when someone books. Booking, cancellation and class packs reuse that row grammar. The booking stamp — a two-frame stop-motion scale from 1.06 to 1.0 with a small accent-orange mark that stays on the row — and the faint hand-drawn strike-through left on a cancelled name are the concept's two physical gestures, and they are the only places the accent is spent on state.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the full-bleed photograph of the studio floor with STILLWATER arranged in wet grey river stones, water still pooling in the gaps and catching light, with the deep water-green painted band cutting diagonally across its lower third.
• Input → transformation → outcome thesis: as the visitor arrives, the hero photograph is already whole and the green band is already in place; the headline BREATHE. MOVE. RETURN. reveals in 3–4 discrete steps — a 4-frame flicker of opacity and position over 240ms with steps() timing, never a smooth cubic-bezier glide — and the live next-class line resolves into its final tabular form. The outcome is a composed first frame in which the studio's name, its headline and its actual next class are all legible at once, with the single accent CTA and its hand-drawn arrow the only thing asking to be pressed.
• Motion vocabulary: stop-motion, frame-based. Discrete stepped reveals; a hard horizontal wipe (clip-path, 180ms, no fade) when day tabs swap the schedule; a 6px accent block sliding in from the left edge on class-row hover; the two-frame booking stamp (scale 1.06 → 1.0, steps() timing, 240ms); the thin top ticker of studio news in uppercase Karla scrolling continuously and pausing on hover.
• Composed first frame: the stones photograph filling the screen, the diagonal water-green band across the lower third, the wordmark small in the band's top-left, the navigation row of uppercase Karla labels separated by 1px ink rules, the three-line Anton headline flush left inside the band, and beneath the band on paper the accent CTA with its hand-drawn arrow beside the live next-class line.
• Reduced-motion state: under prefers-reduced-motion every one of the above is removed. The hero photograph, band, wordmark, navigation, headline, CTA and live line are shown whole and static; the news ticker stops entirely and wraps to whole lines; day changes swap instantly with no wipe; the booking stamp and row-hover slide do not fire, and the booked state and the cancelled strike-through appear immediately in their final form.

9. Non-Functional Requirements

NFR-1 — Anonymous schedule readability (explicit) The weekly class schedule must be readable without an account, because visitors see the weekly class schedule before they sign up. Rationale: the accepted journey begins anonymously and converts to an identity only at the point of booking or buying.

NFR-2 — Identity-bound durable state (required_inference) Bookings, cancellations, class packs, schedules, instructor assignments and member records must be persisted durably and bound to the correct participant, so that a member's spot and balance, an instructor's attendee lists and the owner's records remain correct across sessions. Rationale: the accepted journeys change state that must survive the session and remain attached to the right person.

NFR-3 — Role-scoped access to protected destinations (required_inference) Class Booking, Cancel Booking, Class Packs, Instructor Dashboard, Classes, Class Details, Instructors, Instructor Details, Members and Member Details must be reachable only by an established, verified identity holding the relevant role. Rationale: these destinations change or expose durable state that must remain bound to the correct participant, and instructor and owner access is provisioned rather than self-selected.

NFR-4 — Legibility at every viewport (explicit) Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: the creative direction's readability rule is binding and takes precedence over any cropping gesture for readable text and controls.

NFR-5 — Reduced-motion compliance (explicit) Under prefers-reduced-motion, all stepped reveals, wipes, stamps, hover slides and the news ticker must be removed, and every item must be shown whole — wrapping into rows or sitting in a horizontally scrollable row. Rationale: the creative direction requires it, and the ticker's content must remain fully readable when it stops.

NFR-6 — No blue or indigo, no gradient backgrounds (explicit) No blue or indigo primary or accent colour, and no violet-to-pink gradient background, may appear anywhere in the product. Colour arrives as flat paint, rope, water or paper. Rationale: the creative direction forbids it and the generic indigo/blue-on-white SaaS template is forbidden for this project.

NFR-7 — Accent rationing (explicit) The accent #E4572E is limited to one CTA per screen, the spots-left counter, the active day tab, the cancel confirm, the row-hover block and the booking stamp mark. Rationale: the creative direction rations the accent hard so it reads as a physical mark rather than decoration.

NFR-8 — Schedule row consistency (explicit) The weekly schedule's row grammar — time in tabular figures, class name in Anton caps, instructor in Karla, capacity as small filled squares, a single accent CTA — must be reused on booking, cancellation and class-pack surfaces so the whole app reads as one printed object. Rationale: the creative direction makes the schedule the spine of the product.

10. Tech Stack

• Frontend: React web application. The product is a class booking web app, and the creative direction's asymmetric editorial grid, printed-timetable rows, stepped stop-motion motion and full-bleed photographic hero are all web-surface concerns.
• Backend: Python with FastAPI, serving the schedule, booking, cancellation, class-pack, instructor-dashboard and owner-management operations.
• Storage: A durable relational store for schedules, classes, instructor assignments, members, bookings, cancellations and class packs, satisfying NFR-2.
• Containerization: Docker with docker-compose for local and single-host deployment of the web app and its API and store.
• Kubernetes: Not required. The studio is small — one owner, two to six instructors — and nothing in the accepted requirements establishes a deployment scale that needs orchestration.

11. Assumptions and Constraints

Assumptions

• A-1 (narrow, required_inference). A member's identity is established by self-service sign-up, and instructor and owner access is provisioned or invited by the studio rather than self-selected. This is the minimum identity continuity the accepted journeys need; no other account-management capability is implied.
• A-2 (narrow, required_inference). A class has a capacity, and the schedule shows remaining spots against it, because the accepted booking and cancellation journeys require a spot to be securable and releasable and the creative direction specifies a capacity square row and a spots-left counter.
• A-3 (narrow, required_inference). A class pack carries a balance that a member's bookings draw on, because the accepted requirement is to buy class packs for future bookings.
• A-4 (narrow, required_inference). A cancelled booking leaves a visible record with a hand-drawn strike-through rather than being deleted, because the creative direction specifies that cancelling leaves a faint hand-drawn strike-through on the member's name rather than deleting it.
• A-5 (narrow). The studio's class offering is weekly and recurring, because the accepted requirement is that visitors see the weekly class schedule.

Constraints

• C-1. The product is a web app for a small yoga studio called Stillwater Yoga. It is not a mobile-native app and not a multi-studio platform.
• C-2. The current scope is exactly: the weekly class schedule; sign up; book or cancel a spot in a class; buy class packs; the instructor dashboard of their classes with attendee lists; and owner management of classes, instructors and members. No adjacent capability — attendance check-in, waitlists, messaging, reporting suites, or any other conventional studio-management module — is in scope.
• C-3. No blue or indigo primary or accent colour, and no violet-to-pink gradient background, anywhere in the product. The generic indigo/blue-on-white SaaS template is forbidden.
• C-4. Headings use Anton, body and labels use Karla. Inter, Roboto, Poppins, system-ui or any neutral default is not used for headings.
• C-5. Shapes stay squared and printed: almost no border radius except 2px on inputs and buttons. No fully rounded pill buttons and no large soft radii.
• C-6. Motion is stepped, stamped and frame-based. No smooth eased fades and no bouncy springs.
• C-7. No stock yoga silhouettes, no lotus icons, no meditating figures on a beach, no generic wellness gradients, no gradient blobs and no 3D renders.
• C-8. Display headlines never exceed six words and never collide with a control.

12. Glossary

• Stillwater Yoga — the small neighbourhood yoga studio this web app serves.
• Visitor / Member — a person browsing Stillwater Yoga's weekly class schedule who signs up, books or cancels a spot in a class, and buys class packs.
• Instructor — a person who teaches classes at the studio and uses the Instructor Dashboard to see their own classes and their attendee lists.
• Studio Owner — the person who manages the studio's classes, instructors and members.
• Class — a scheduled yoga session with a name, day, time, capacity and assigned instructor.
• Weekly class schedule — the printed-timetable view of the studio's classes for the week, organised by day and readable without an account.
• Spot — a single place in a class, bounded by that class's capacity.
• Booking — a member's confirmed spot in a specific class.
• Cancellation — the release of a member's confirmed spot, leaving a faint hand-drawn strike-through on the member's name rather than deleting the record.
• Class pack — a purchased bundle of credit that a member uses for future bookings.
• Attendee list — the list of members expected in a class, shown to that class's instructor on the Instructor Dashboard.
• Capacity squares — the row of small filled squares that shows a class's capacity and how much of it is taken, in place of a soft progress pill.
• Booking stamp — the two-frame stop-motion mark (scale 1.06 → 1.0, steps() timing, 240ms) with a small accent-orange mark that stays on the row when a spot is booked.
• Day rail — the vertical day-of-week strip down the left of the schedule on desktop, which becomes a horizontal scrolling day strip on mobile.
• News ticker — the thin top ticker of studio news in uppercase Karla that scrolls continuously and pauses on hover.