Phase 4 — Schedule Screen Amendments

Phase 4 — Schedule Screen Spec Amendments

Version: 1.0 Date: February 26, 2026 Input: Phase 1 Problem Brief, Phase 2 Design Principles, Phase 3 Learnings, Phase 4 Architecture, Phase 4 Learn Screen Amendments, WWDC25 Field Guide, User Capability Map, Today Screen Mockup Implementation Status: Draft — Proposed for integration into Phase 4 Architecture v1.3

Why These Amendments Are Needed

Phase 3 identified the Schedule screen as "the strongest screen in the mockup and the strongest section of the Proposal A spec" with 95% alignment and zero missing elements. That assessment was correct — structurally. The Schedule screen's structural design (what elements exist, how they relate, what states they represent) is sound and should be preserved.

However, the Learn screen amendments revealed a category of spec failure that Phase 3 did not test for: visual treatment guidance. The Learn screen was also structurally correct, yet three rounds of mockup implementation produced flat, generic-looking results because the spec described what to show without describing how it should look — typography sizes, visual weights, dominant elements, state-dependent treatments. Every Learn screen amendment addressed this same root cause.

The Schedule screen spec has the same gap. It describes components (session cards, day strip, filters, deadline cards) but provides no guidance on:

• What the dominant visual element is (squint test target)
• What typography sizes and weights to use
• How the "Live Now" state — the most time-critical state in the entire app — should differ visually from an upcoming session
• How session cards relate to the Visual Design Language patterns established in Section 4.3.5
• What the above-the-fold content should be

Without these amendments, the Schedule screen will face the same implementation problems the Learn screen faced: structurally correct but visually undifferentiated, requiring multiple rounds of revision.

A note on what these amendments preserve: Phase 3's positive assessment was about structure. Every structural decision — the segmented control, session type filters, calendar day strip, deadline cards, recordings toggle, session detail modals — is preserved. These amendments add the visual layer that turns correct structure into a well-designed screen.

Amendment 1: Define Visual Hierarchy and Squint Test Target

Current spec:

The Schedule screen (lines 541-630) lists structural elements but provides no visual hierarchy guidance. There is no typography table, no dominant element designation, and no squint test target.

Compare to the Today screen spec (lines 158-164): "Week Header (dominant visual element)... Line 1 (Large Title size, bold): 'Week 8 of 15'... This header is the visual anchor of the screen. It is the largest text element."

Compare to the Learn screen (post-amendment): Full visual hierarchy table with 7 rows specifying element, treatment, and purpose.

The Schedule screen has neither.

Why this matters:

The Schedule screen serves a fundamentally different purpose from Today and Learn. Today answers "Where am I in the semester?" Learn answers "What am I working on this week?" Schedule answers a time-bound question: "When is my next session, and how do I join it?"

This means the Schedule screen's visual hierarchy should optimize for scanning speed, not emotional anchoring. Students come to Schedule with a specific temporal question and need to find the answer fast. The dominant elements should be: time of day, session type, and the action button — not a week number.

I considered three options for the visual anchor:

Option A: Week number as anchor (matching Today/Learn). This would mean a 58pt "Week 8" header on Schedule. I rejected this because the week number is navigational context on Schedule, not the answer to the student's question. A student opening Schedule at 6:45 PM doesn't need "Week 8" at 58pt — they need to see "QRC — 7:00 PM EST — Join" immediately. Forcing the Today/Learn hero pattern onto Schedule would push session cards further below the fold and privilege the wrong information.

Option B: Today's date as anchor (matching iOS Calendar). Apple Calendar uses the date number as the dominant visual element. This has precedent but the same problem: the date isn't the student's question. QuranFlow students check Schedule to find sessions, not to confirm what day it is.

Option C: The first visible session card as the anchor. The student's question is "what's happening next?" The answer is the next session card. Making session cards the visually dominant content — with prominent time display, color-coded type badges, and clear action buttons — answers the question directly.

I selected Option C because it follows Phase 2's Priority Stack #1 (temporal orientation first) at the right granularity. On Today, temporal orientation means the week. On Schedule, temporal orientation means the session time. The screen's visual weight should flow toward the content, not the navigation chrome above it.

Amendment — Add to spec:

Visual Hierarchy (Schedule — Upcoming View):

Squint Test target (Phase 2, C2): When the screen blurs, the student should identify a vertical rhythm of session cards with colored type badges on the left edge and time values standing out. On a day with a live session, the green "Join" button should be the single most identifiable element. On a normal day, the time column and type badges create the visual structure.

Above-the-fold rule: On first load (current week, current day selected), the student must see at least 2 session cards without scrolling. If no sessions exist today, the "no sessions" message and the next session preview must be visible without scrolling.

Squint Test comparison across tabs:

The Schedule screen is intentionally different from Today and Learn. It does not use the 58pt hero typography pattern because its purpose is scanning, not anchoring. The session cards themselves are the content, and the visual design should get the student to them as fast as possible.

Amendment 2: Merge Week Navigator and Day Strip to Reduce Chrome

Current spec (lines 561-568):

Two separate navigation elements stacked vertically:

1. Week Navigator: "< Week 8 >" with left/right arrows (~44pt height)
2. Calendar Day Strip: Horizontal row of 7 day circles (~56pt height)

Problem:

Five layers of navigation chrome appear between the navigation bar and the first session card:

Navigation Bar                     ~44pt
Segmented Control                  ~36pt
Week Navigator                     ~44pt
Calendar Day Strip                 ~56pt
Session Type Filters               ~40pt
────────────────────────────────────────
Total chrome above first card:    ~220pt

On the 390x844pt iPhone 15 viewport (minus 54pt status bar, minus 83pt tab bar = 707pt usable), this chrome consumes 31% of usable screen height before a single session card appears. On an iPhone SE (667pt total, ~530pt usable), it consumes 42%.

The Learn screen amendments removed the journey map from "This Week" view specifically because it pushed the video list below the fold. The same principle applies here: navigation controls should not displace the content they're navigating to.

I considered four approaches:

Option A: Remove the calendar day strip entirely. Sessions are listed below with day information on each card, so the strip is technically redundant. But the day strip serves an important function: it shows which days have sessions (dot indicators) without scrolling. On a week where sessions cluster on Tuesday and Thursday, the strip communicates this pattern instantly. I rejected full removal because this visual summary has legitimate value.

Option B: Remove the week navigator, keep the day strip. The day strip already represents a specific week's days. Swiping the strip left/right to change weeks is a standard iOS calendar gesture. The week context could be shown as a small label integrated into the strip. This saves one full layer (~44pt). However, it relies on gesture discovery — the arrows in the week navigator make week-changing obvious. I considered this but worried about accessibility for QuranFlow's older user demographic who may not discover swipe gestures.

Option C: Combine week navigator and day strip into a single visual row. The week label ("Week 8") sits at the left edge, the day circles fill the remaining width, and small arrow buttons at the outer edges handle week navigation. This preserves discoverability while saving ~30-40pt of vertical space.

Option D: Keep everything but make the day strip and filters more compact. Reduce padding, use smaller touch targets. This risks violating the 44pt minimum (Phase 2, standard platform patterns; WWDC25 Field Guide Part 2).

I selected Option C because it preserves all functionality, saves meaningful vertical space, keeps the week-navigation arrows visible for accessibility, and follows standard iOS calendar patterns (Apple Calendar uses a similar combined week/day header).

Amendment — Replace week navigator and calendar day strip specs with:

Week + Day Header (combined single row):

A single row combining week context and day selection:

• Left edge: Week label — "Wk 8" in 13pt bold, tabular, muted foreground. Doubles as tap target to return to current week.
• Center: 7 day circles (Sat through Fri), each 36pt diameter within a 44pt touch target area. Current day: filled circle in primary accent color with white day label. Days with sessions: small dot below the circle (4pt, primary color). Other days: outlined circle with muted day label.
• Right edge: Subtle forward arrow (16pt, muted). Left arrow at left edge of the day circles.
• Total row height: 56pt (including top/bottom padding).
• Week advancement: Tapping arrows or swiping the day strip horizontally navigates to adjacent weeks. A brief "Week 9" label flashes during the transition to confirm the change.

Rationale: This saves approximately 40pt of vertical space compared to two separate rows. More importantly, it makes the day strip the primary temporal navigation element (which it functionally is — students select days, not weeks) while keeping week context visible.

What this changes in the spec:

• Remove: Separate "Week Navigator" section (lines 561-563)
• Remove: Separate "Calendar Day Strip" section (lines 565-568)
• Replace with: "Week + Day Header" as a single combined element
• Preserve: All functionality (week browsing, day selection, session dot indicators, current day highlighting)

Amendment 3: Session Type Filters — Progressive Disclosure

Current spec (lines 570-572):

"Horizontal pill buttons: All | Level Classes | QRCs | Office Hours. 'All' selected by default."

Problem:

On a typical QuranFlow day, a student has 1-3 sessions. Session type filters for a list of 1-3 items provide no filtering value — the student can see all sessions at a glance. The filters consume a full row of screen real estate (~40pt) that could instead show more of the session cards.

The spec already addresses dense days separately (lines 588): "If more than 7 sessions are displayed for a single day, sessions are grouped by type." This grouping mechanism handles the dense-day case without requiring persistent filters.

Phase 2 Content Principle 1 (Progressive Disclosure): "No screen shows more than 7 items without disclosure mechanism." The filters exist for the 7+ case, which has its own handling.

I considered three options:

Option A: Remove filters entirely. Dense-day grouping handles large lists. For 1-3 sessions, no filter is needed. Simple, saves space. But a student who wants to see "all QRCs this week" (across multiple days) loses that ability. This is a real use case — a student deciding which QRC to attend might want to see all QRC options for the week.

Option B: Keep filters always visible. This is the current spec. Wastes space on normal days (1-3 sessions) but is always discoverable. Consistent, but contributes to the chrome problem.

Option C: Show filters contextually. Filters appear when the visible session list has 4+ items, or are accessible via a filter icon in the navigation bar. On days with 1-3 sessions, the full space goes to session cards.

I selected a modified Option B — keep the filters visible, but with reduced visual weight. Here's my reasoning: QuranFlow's students are "busy adults, many older" who "don't read emails/manuals" (Phase 1). Progressive disclosure that hides filters behind an icon risks the same discoverability problem that plagued the original app's hamburger menu. For an audience that may not discover gestures or hidden UI, visible-but-subtle beats hidden-but-tidy.

Amendment:

Session Type Filters:

Horizontal pill buttons remain visible below the Week + Day Header. Treatment:

• Default state: 12pt, medium weight, muted foreground, transparent background with subtle border (border-border/40). "All" is selected by default with primary-color text and a subtle primary tint background.
• Active filter: Primary color text, subtle primary tint background (oklch(0.95 0.03 285)), rounded-full.
• Row height: 32pt total (pills are 28pt with 2pt vertical margin). This is smaller than a standard 44pt row because the pills are horizontally arrayed and each individual pill exceeds 44pt in width (satisfying the tap target requirement on the dimension that matters — width, not height, since horizontal scrolling is the interaction).
• Scrollable: The filter row scrolls horizontally if more types are added in the future, but for the current 4 options (All | Level Classes | QRCs | Office Hours) they fit within 390pt.

Net effect on chrome height:

This saves 52pt — enough for approximately one additional session card to appear above the fold.

Amendment 4: Session Card Visual Treatment (State-Dependent)

Current spec (lines 574-587):

The spec lists what each session card contains (type badge, time, title, coach name, gender indicator, status indicator, action buttons) but provides no visual treatment guidance.

Problem:

Session cards are to the Schedule screen what the submission CTA is to the Learn screen and the Primary Action Card is to the Today screen: the core interactive content element. The Learn screen amendments (Amendment 8) added explicit state-dependent visual treatment for the submission CTA because without it, every state looked the same. The Schedule screen has the same gap.

The Today screen mockup already implements a session card component (today.tsx lines 161-234) with specific visual decisions: a time column with divider, color-coded type badges, and a "Live Now" state with green pulsing dot and "Join" button. This implementation should be codified in the spec so the Schedule screen extends it consistently.

Amendment — Add session card visual treatment:

Session Card Pattern:

Session cards follow the Card Pattern from Section 4.3.5 (bg-card, rounded-xl, border border-border/60) with the following internal structure:

┌─────────────────────────────────────────────┐
│  TIME     │  [TYPE BADGE]                   │
│  7:00 PM  │  Sisters' QRC with Ust. Radwa   │
│  EST      │  Brothers · 12 attending   [>]  │
└─────────────────────────────────────────────┘

Internal layout:

• Time column (fixed width, 64pt): The most scannable element. Time in 15pt bold tabular figures (high contrast foreground). Timezone abbreviation below in 10pt medium weight, muted foreground. When session is live: time replaced by "Live" label with pulsing dot (see Amendment 5).
• Vertical divider: 1px line, border-border/80, 40pt height. Separates time from content. This consistent left edge creates a visual rhythm that makes scanning a list of sessions fast.
• Content area (flexible):
  • Row 1: Type badge (Status Badge Pattern — 10pt semibold uppercase, rounded pill, color-coded) + coach name (12pt, medium, muted) when applicable.
  • Row 2: Session title — 13pt, semibold, foreground, single line truncated.
  • Row 3 (optional): Metadata — gender indicator ("Sisters" / "Brothers"), RSVP count ("12 attending"), in 12pt muted text. Only shown when relevant data exists.
• Action area (fixed width, right-aligned): ChevronRight icon (16pt, muted) for upcoming sessions. "Join" button for live sessions. Countdown text for soon-to-be-live sessions.

Type badge colors (matching Today screen mockup):

These are the established colors from the Today screen mockup. Codifying them here ensures the Schedule screen matches.

Session card grouping decision:

I considered two approaches:

Option A: Individual cards (one card per session). This is what the Today screen uses for its 1-3 session preview. Each card has its own rounded corners and border. Visually distinct, easy to tap, familiar from the Today screen.

Option B: Grouped card (all sessions in one card with dividers). This is the pattern used for video lists in the Learn screen and week rows in "All Weeks." More compact, creates a cohesive unit.

I selected Option A (individual cards) for the Upcoming view because:

1. It matches the session card pattern already established on the Today screen (visual consistency).
2. Individual cards make each session a distinct tappable unit, important for the "Join" action.
3. The spacing between cards (8pt gap) creates breathing room that aids scanning.
4. Grouped cards work best for homogeneous rows (video list, week list). Session cards are heterogeneous — different types, different action states, interspersed deadline cards.

For the Recordings view, I recommend Option B (grouped card) because recordings are a review list (homogeneous, no urgent actions, compact scanning), matching the Learn screen's "All Weeks" week-list pattern.

Touch interaction: active:scale-[0.99] on press (slightly less than the standard 0.97 because session cards are wide — aggressive scaling on wide elements looks jumpy), 150ms ease-out transition, touch-manipulation.

Amendment 5: "Live Now" State — Full Visual Treatment

Current spec (line 614):

"Session card shows 'Live Now' with pulsing indicator"

Problem:

The "Live Now" state is the most time-critical state in the entire QuranFlow app. A student seeing this state needs to join their session right now — every second of delay matters. This is more urgent than any other state on any screen: more urgent than "Feedback Ready" (which can wait hours), more urgent than "Submission Due" (which can wait days).

Yet the spec gives it a single line. This is the same pattern that caused the Learn screen's Quranic text treatment to be consistently underimplemented — the most important element getting the least specification.

The Today screen mockup (today.tsx lines 189-203) already implements a "Live Now" treatment: pulsing green dot, "Live" label, green "Join" button. This establishes the pattern but the Schedule screen needs to amplify it because Schedule is where the student goes specifically to join sessions.

Amendment — Replace "Live Now" spec with:

"Live Now" Session Card — Elevated Treatment:

When a session is currently live (within its scheduled time window), its card receives elevated visual treatment to command immediate attention:

• Card border: 1px solid border in green accent (oklch(0.70 0.15 155 / 0.4)) replacing the standard border-border/60. Subtle but distinct from neighboring cards.
• Time column replacement: The time value is replaced by a "Live" indicator:
  • Pulsing dot (6pt diameter, oklch(0.55 0.18 150), CSS animation: 1.5s ease-in-out infinite pulse between 100% and 40% opacity)
  • "LIVE" label: 10pt, bold, uppercase, oklch(0.40 0.12 155)
  • Start time below in 11pt muted (so the student still knows what time it started)
• Join button (replaces chevron): High-contrast action button:
  • Background: oklch(0.50 0.15 155) (rich green)
  • Text: "Join" in 13pt bold white, with small Video icon (14pt) to left
  • Rounded-lg, px-3.5 py-2
  • Shadow: 0 2px 8px oklch(0.50 0.15 155 / 0.25) — subtle glow draws the eye
  • This button is the highest-urgency interactive element on the screen
• Card background: Standard bg-card (no background tint). The green border and Join button provide sufficient differentiation without overwhelming the warm color palette.

"Starting Soon" State (within 15 minutes of session start):

This transitional state bridges "Upcoming" and "Live Now":

• Card border: Standard border-border/60 (no change from normal)
• Time column: Standard time display but with an additional line: "in 12 min" in 11pt, semibold, primary color below the timezone. This countdown updates every minute.
• Join button appears: Same green "Join" button as "Live Now" state (the Zoom link becomes active 15 minutes before). This is the critical change — the action becomes available.
• Card background: Standard bg-card

The transition from "Starting Soon" to "Live Now" should be seamless — the card gains its green border and the time column switches to the pulsing "LIVE" indicator.

"Ended" State:

• Card opacity: Reduced to 60% opacity on the entire card
• Time column: Standard time, struck-through or with "Ended" label below in 11pt muted
• Action area: No chevron, no Join button. If a recording is available, show a small "Recording" link (12pt, primary color) instead.
• Purpose: Ended sessions fade visually so active/upcoming sessions dominate the list. They remain visible (rather than disappearing) so the student's mental model of the day isn't disrupted.

Visual priority stack for session states:

Live Now          ████████████████  (green border, pulsing dot, Join button)
Starting Soon     ███████████       (Join button appears, countdown text)
Upcoming          ████████          (standard card, chevron)
Ended             ████              (60% opacity, no action)

The student's eye should be drawn first to any "Live Now" card, then to "Starting Soon" cards, then to upcoming cards. Ended cards recede.

Amendment 6: Deadline Card Visual Treatment and Urgency States

Current spec (lines 590-592):

"Submission Deadline -- Friday 11:59 PM EST. Styled differently from session cards (dashed border, muted background)."

Problem:

Deadline cards are mentioned but underspecified. "Dashed border, muted background" is better than nothing, but:

• What happens as the deadline approaches? A deadline 5 days away and a deadline 3 hours away should not look the same.
• Where do deadline cards appear in the session list? Before all sessions that day? At the chronological position? At the end?
• How does the deadline card relate to the submission status on the Learn tab?

Phase 2 Content Principle 2 (Grouping by Time and Progress) establishes that temporal items should reflect their urgency through position and visual treatment.

Amendment:

Deadline cards are interspersed with session cards at their chronological position (e.g., a Friday 11:59 PM deadline appears after Friday's last session). They use a distinct visual treatment to prevent confusion with session cards:

Base treatment (deadline > 24 hours away):

• Dashed border (1px, border-border/60, dash pattern: 6px dash, 4px gap)
• Background: transparent (no fill — the dashed border alone differentiates from solid-border session cards)
• Content: Clock icon (16pt, muted) + "Submission Deadline" label (12pt, semibold, muted foreground) + date and time with timezone (13pt, medium, foreground)
• No action button — tapping navigates to Learn tab's Submission section
• Height: compact single row (~52pt)

Approaching treatment (deadline within 24 hours):

• Dashed border color shifts to amber (oklch(0.72 0.12 75 / 0.6))
• Background: subtle amber tint (oklch(0.97 0.02 75))
• Label changes to: "Due Tomorrow" or "Due Today" (12pt, semibold, oklch(0.45 0.12 60))
• Time rendered in bold (13pt, bold, foreground)

Imminent treatment (deadline within 3 hours):

• Dashed border color: amber, solid instead of dashed (urgency overrides the "dashed = deadline" signal)
• Background: warmer amber tint (oklch(0.95 0.04 75))
• Label: "Due in [N] hours" (12pt, bold, oklch(0.40 0.12 55))
• If submission is not yet submitted: small CTA "Submit Now" link (12pt, semibold, primary color) on the right

Passed treatment (deadline has passed):

• 50% opacity, standard dashed border
• Label: "Deadline Passed" with date
• If submission was made: "Submitted" badge (green pill)
• If not submitted: "Missed" in amber, muted

What about students who already submitted? If the current week's submission is already sent, the deadline card shows a subtle "Submitted" checkmark and uses the base (muted) treatment regardless of time proximity. The urgency states only apply when the submission is still pending.

Amendment 7: Recordings View — From Underspecified to Implementable

Current spec (lines 594-607):

The Recordings view receives approximately 10 lines of specification. It lists what recording cards contain but provides no visual treatment, grouping strategy, or progressive disclosure approach.

Problem:

The User Capability Map identifies recordings as a previously hidden feature (buried in the hamburger menu, Task 3E.1). Phase 4 correctly surfaces recordings in the Schedule tab, but an underspecified recordings view risks reproducing the "tedious filter system" the current app has. The PM Discussion notes: "Filter system frustrating — year, month selection... memory-dependent... up to 20 sessions per week to sift through."

The recordings view needs enough specification to prevent the same filtration problems from recurring.

Amendment — Replace recordings view spec with:

Recordings View:

The Recordings view uses the same Week + Day Header as the Upcoming view (shared navigation element). Below the header, recordings are presented in a grouped card with dividers (matching the Learn screen's "All Weeks" week-list pattern), grouped by day within the selected week.

Day group header: Within the grouped card, each day that has recordings gets a header row:

• Day name and date: "Tuesday, Feb 24" — 12pt, bold, muted foreground
• Recording count: "3 recordings" — 11pt, muted, right-aligned
• This header row has a slightly different background tint (oklch(0.96 0.005 85)) from the recording rows to create visual separation

Recording row layout:

• Left: Session type badge — Same color-coded pill as session cards (Status Badge Pattern). This provides instant visual scanning of recording types.
• Center:
  • Line 1: Session title — 13pt, semibold, foreground
  • Line 2: Date, time, and duration — 12pt, muted (e.g., "Feb 24, 7:00 PM EST · 45 min")
• Right:
  • Unwatched: "New" badge (small accent pill, 10pt) + chevron
  • Watched: Checkmark icon (16pt, green, muted) + chevron
  • Partially watched: Small progress indicator (thin bar showing percentage, below the title line)

Why grouped card instead of individual cards: Recordings are a review activity, not an urgent action. The grouped card creates a compact, scannable list (matching the video list pattern in Learn and the week list in "All Weeks"). Individual cards would create excessive visual weight for a secondary feature.

Session type filters: The same filter pills from the Upcoming view carry over to the Recordings view. "All" is selected by default. This directly addresses Capability Map Task 3E.2 ("Filter by type").

Empty state: "No recordings for this week yet. Recordings appear here after live sessions end." Displayed as a muted centered text block (13pt, muted foreground) within a single card container.

Progressive disclosure for dense weeks: If a week has more than 10 recordings, the grouped card shows the first 7 rows with a "Show all [N] recordings" footer link. This follows Phase 2 Content Principle 1 (7-item rule).

Amendment 8: Session Type Explanation for New Students

Current spec:

Session type badges show "Level Class" (blue), "QRC" (green), and "Office Hours" (purple). No mechanism exists for a new student to understand what these types mean.

Problem:

The Capability Map (Task 3D.2) explicitly identifies this gap:

"New students don't understand differences [between session types]... No explanation of what each type offers"

The onboarding flow (Step 5) mentions "Attend live sessions for practice and Q&A" generically but doesn't distinguish the three types. A Week 1 student seeing "QRC — Sisters Reading Circle" has no context for what "QRC" means, what to expect, or whether they should attend.

I considered three approaches:

Option A: Add explanations to the onboarding flow (Step 5). The semester overview step could list each session type with a one-line description. This front-loads the information. But Phase 1 established that QuranFlow students "don't read emails/manuals" — front-loaded information may not be retained.

Option B: Add a first-time tooltip on the Schedule screen. The first time a student visits the Schedule tab, a brief overlay explains the three types. This is in-context and just-in-time. But tooltips are easily dismissed and forgotten, and adding custom tooltip UI adds implementation complexity without clear reuse.

Option C: Add type explanations to the Session Detail modal. When a student taps a session card and sees the modal, include a one-line description of the session type. This is the most natural in-context learning — the student is already curious about the session when they tap it. It requires no custom UI (just a text line in the modal).

I selected Option C because it follows the principle of just-in-time information: the explanation appears at the moment the student is engaging with a specific session, not before. This is also the most maintainable — a single text line in an existing modal.

Amendment — Add to Session Detail modal spec (line 620):

Session Detail Modal includes a one-line type explanation below the type badge:

This explanation appears in 13pt body text, muted foreground, directly below the session type badge in the modal header. After the student's third visit to Schedule (tracked locally), the explanation collapses to show only on tap of a small (i) icon next to the type badge — progressive disclosure that serves Week 1 students without patronizing Week 8 students.

Amendment 9: Define Shared Pattern References

Problem:

Section 4.3.5 (Visual Design Language) defines shared patterns: Card Pattern, Section Header Pattern, Status Badge Pattern, Gradient CTA Pattern, Touch Interaction Pattern. The Schedule screen spec doesn't reference these patterns, leaving the implementer to guess which patterns apply where.

The Learn screen amendments exposed this problem: when patterns aren't explicitly referenced, implementations diverge from the established visual language.

Amendment — Add pattern references to the Schedule screen spec:

Pattern application in the Schedule screen:

Why the "Join" button is NOT a Gradient CTA: The Gradient CTA Pattern (Section 4.3.5) specifies "maximum one gradient CTA per screen" and is used for the single most important weekly action (Today's Primary Action Card, Learn's Submission CTA). The Schedule screen's "Join" button is a utility action — it appears on individual session cards and there may be multiple live sessions at once. Using the Gradient CTA pattern would create multiple competing gradient cards, violating the one-per-screen rule. The green solid-fill treatment is appropriate for "Join" because green universally signals "go/proceed" and creates sufficient urgency without the promotional weight of a gradient card.

Summary of All Amendments

What These Amendments Do NOT Change

The following Phase 4 decisions are preserved:

• The [Upcoming | Recordings] segmented control (correct and functional)
• Session type filters with All | Level Classes | QRCs | Office Hours (correct, only visual weight adjusted)
• Calendar day strip with day selection and dot indicators (merged with week navigator, functionality preserved)
• Session cards showing type badge, time, title, coach, gender, status, actions (visual treatment added, content unchanged)
• Dense day handling with 7+ session grouping by type (unchanged)
• Deadline cards interspersed with sessions (position and urgency states specified)
• Session Detail modal with full info, Zoom link, calendar integration, RSVP (type explanation added)
• Recordings view with type filter, chronological sort, watch status (visual treatment and grouping specified)
• All 5 states defined in the states table (lines 611-617) (visual treatment added for Live Now)
• All behaviors (lines 619-625)
• All connections to other screens (lines 627-629)
• The tab bar structure (Today | Learn | Schedule | Profile)
• Timezone selector in the navigation bar (unchanged — correctly specified)

These amendments refine HOW the Schedule screen presents its content, not WHAT content it presents. The structural design praised in Phase 3 is fully preserved.

Open Questions for Discussion

Q1: Should the "Starting Soon" session be pinned to the top of the list?

The current spec shows sessions in chronological order. If a student opens the Schedule tab at 6:48 PM and their QRC starts at 7:00 PM, should the "Starting Soon" card remain in its chronological position (potentially below ended morning sessions) or be pinned to the top of the visible list?

Argument for pinning: The student opened Schedule to join their session. Scrolling past ended sessions to find the urgent one adds friction at the worst possible moment.

Argument against pinning: Reordering the list breaks the temporal mental model. The student expects sessions in time order. A pinned card appearing above earlier sessions could be confusing.

My recommendation: Pin "Live Now" and "Starting Soon" cards to the top of the list, with a subtle visual separator and "Happening Now" section header (using the Section Header Pattern) between the pinned cards and the chronological list below. This prioritizes the urgent action while maintaining temporal order for everything else. But this is a meaningful interaction design decision that deserves team input.

Q2: Should the Recordings view group by day or show a flat chronological list?

Amendment 7 specifies grouping by day within the selected week. An alternative is a flat reverse-chronological list (most recent first) with date labels but no explicit grouping. The grouped approach matches the Upcoming view's mental model (organized by day). The flat approach is simpler and may be sufficient given that the week navigator already scopes the time range.

My recommendation: Group by day, as specified in Amendment 7. It creates structural consistency between the two views and helps students find "the recording from Tuesday's class" without scanning every row. But if implementation complexity is a concern, a flat list with date labels is an acceptable simplification.

End of Phase 4 Schedule Screen Amendments