QuranFlow iOS App — Requirements Traceability Matrix

Part of the production handoff package, alongside FEEDBACK-SYNTHESIS.md (the synthesized stakeholder asks) and handoff/PRODUCT-SPEC.md (the screen-by-screen functional spec). This document's job is narrower and mechanical: prove that every stakeholder ask landed somewhere — designed, deferred, or rejected — so nothing silently fell through between the four feedback sources (Coaches' Questionnaire, IT Revamp Discussion transcript, App Wishlist, Mock App Feedback) and the finalized Sakīna mockup at ../mockup/.

Sources checked against: FEEDBACK-SYNTHESIS.md, ../mockup/REVIEW.md (adjudicated design decisions), ../mockup/src/main.jsx (finalized screen inventory — artboard labels are cited as design evidence below), spot-checked against the individual ../mockup/src/sak-*.jsx files, and — where the synthesis summarized rather than quoted — the raw source files in /feedback for new app/ (the Coaches' Questionnaire responses, the App Wishlist, the IT Revamp transcript, and the Mock App Feedback doc).

1. How to read this document

Every ask gets exactly one status:

"Designed" is a claim about the mockup, not about shipped code — the mockup is the design evidence; implementation fidelity is verified separately during build QA.

2. The matrix

Coach review workspace

Feedback loop

Schedule / time

Communication

Appointments

Attendance / data

Support / launch

Student experience

Coach prep / compensation

Strategy items

3. Backlog — deferred items restated for pickup

Each entry: what was asked, why it's valid, and what's unresolved so the next pass doesn't start from zero.

1. Student-centric QRC/live-session scheduling algorithm. The IT call surfaced a real tension: today's live-class schedule is built around teacher availability, then students adapt. The program lead proposed inverting this — collect student availability first, then shape the schedule (and staffing) around it. The unresolved question is cost vs. value: a student-first model may require recruiting additional coaches for odd-hour slots (e.g., late evening for one region, early morning for another) or accepting scheduling strain on existing coaches. No decision was made on whether the value (fewer missed sessions, less "student adapts to us" friction) justifies that staffing cost. Pick this up as a staffing/ops modeling exercise before it becomes a design task — the app can display whatever schedule results, but the policy has to be decided first.

2. 20 appointment credits per semester (make-up sessions for Year 2). Raised in the IT discussion as a Year-2 lifecycle feature — a bank of credits a student can spend to book make-up 1:1s beyond their normal recurring slot. Not designed because the credit-consumption rules (what burns a credit, whether unused credits roll over, interaction with the recurring-vs-flex booking split already built in F5) weren't specified. Needs a small spec pass before it's a screen.

3. AI feedback summaries. An AI-generated summary of a coach's audio/text feedback, shown to both coach and student as a quick-reference overview. Flagged by Yasmine and others in the questionnaire and listed as an explicit backlog item in FEEDBACK-SYNTHESIS.md. Depends on production feedback-text/transcript data existing at volume; treat as a v2 layer on top of the already-built SakSubmissionFeedback object, not a new screen.

4. AI post-session survey analysis. The IT call decision was: automated post-session survey loop (did the student attend? if not, why?) with AI-aggregated trends — called out as "a priority even ahead of the app." The survey trigger and delivery is straightforward (push a short survey after a missed or attended session); the AI-aggregation/trend layer is the deferred part. Needs a decision on where aggregated trends surface (coach dashboard? program admin?) before designing that view.

5. Lesson asset banks for coaches (slides, games, practice exercises per lesson). Raised by Radwa specifically to address uncompensated prep time — "that would be time off the clock for the teacher." Not a student-facing screen; would live in the Coach app as a per-lesson resource shelf. Needs content production (someone has to build the actual assets) before it's a design problem.

6. Peer community channel revival. The IT call's messaging decision (1:1 + announcements) explicitly replaced the open community board, but Ibrahim separately wants students able to stay in touch with each other, remind one another what was covered, and share notes. This is a distinct ask from the rejected-and-replaced community board — it's peer-to-peer, not coach-broadcast-to-many. Revisit as a moderated peer channel (not a return to the unmoderated board) if student isolation becomes a retention problem.

7. Embedded Zoom. Multiple coaches (questionnaire) wanted Zoom launched/embedded from within the app rather than a separate login — "an online portal... Zoom embedded so I don't have to log in separately." Currently the mockup's live-class flow (SakLiveClass, section 03) implies an "Open Zoom" action but does not embed the Zoom SDK. Real engineering lift (Zoom SDK integration, auth passthrough); scope as its own workstream.

8. Desktop coach portal. Ibrahim Abou Arab explicitly asked for "a dedicated teachers' portal (desktop/laptop)... prefer working on a larger screen, with a keyboard and more structured workspace," and the questionnaire's device-split question shows 5 coaches mobile-only, 4 both, 1 (Ibrahim) desktop-only. The Coach app in this mockup is phone-first — all four Coach-app artboards (SakCoachQueue, SakCoachReview, SakCoachStudent, SakCoachSchedule) are 390×844 device frames. Ibrahim's desktop preference is unmet in v1. This is not merely "make it responsive" — a desktop review workspace (keyboard shortcuts for note-taking, multi-pane layout for assignment text + audio + notes side by side) is a genuinely different information density than the phone screens, closer to what Radwa also described ("a website for text and pdf files for weekly lessons and submissions and level notes"). Scope as a real second surface, not a CSS breakpoint.

9. Assessment rubrics in-app (First Assessment guideline, End of Course Assessment guideline), surfaced to the coach before they begin reviewing/assessing a student. Two distinct wishlist items (Wishlist "First Assessment Guideline", "End of Course Assessment Guideline"). Not designed — no Coach-app artboard shows a rubric reference screen. Needs the actual rubric content finalized by the program side before it's a design task.

10. Multi-week-behind state, designed explicitly. Mock App Feedback asked to eliminate the dedicated "Behind" screen in favor of a notification — done, no "Behind" artboard survives in main.jsx. But the reviewer also asked to "design the multi-week-behind case explicitly" — i.e., what does Today/Learn look like for a student who is 2, 3, 4+ weeks behind, not just one week? That state is not represented among the section 06 "States" artboards (which cover rest day, first week, empty archive, all-caught-up, mic permission — but not multi-week-behind). Needs its own state design: likely a variant of SakToday/SakLearn with a catch-up plan rather than a simple "N weeks behind" label, to avoid the punitive tone the original "Behind" screen had.

11. Coach access to all levels/mastery courses + lesson-breakdown preview, and the related Year 2 weekly assignments & lesson overviews for appointment prep (both from the Wishlist). Neither is represented on a Coach-app artboard. Bundle with item 9 (assessment rubrics) as a single "coach reference library" feature — all four are read-only content-access asks a coach needs while prepping or reviewing, and likely share one implementation (a coach-facing curriculum browser).

12. Coach re-recording a portion of the student's take within feedback, to demonstrate correct pronunciation (Wishlist, Year 1). Distinct from the built "Voice reply" (a new, separate reply) and from SakRecPractice (the student re-recording). This is the coach recording a clip of the student's own audio, re-performed, attached inline to a specific note. Needs a small addition to FbNoteRow/SakCoachReview — a "record demonstration" action per note.

4. Known launch-day requirements checklist

These are cross-cutting requirements that don't belong to any single screen and must be verified as engineering/QA gates, not designed as artboards:

• Report Issue accessible from every screen — the sheet design (SakReportIssue, F4) is proven once; confirm the entry point (and auto-attached screen/app-version/account context) is wired on every screen in the shipped app, not just the ones shown on the canvas.
• Timezone correctness through DST transitions — the mockup fixes the display rule (one local-time zone banner, no bare "EST"/"EDT" suffixes anywhere; REVIEW.md B3). Verify the underlying scheduling engine correctly recalculates local-time display across US/Europe/Turkey/Egypt when any region crosses a DST boundary — this was a live, recurring bug in the current app (calendar showing 7 PM for an 8 PM class) and must be tested explicitly at each region's DST transition date, not just at ship time.
• Announcement toggle default is ON — confirmed in the mockup (sak-settings.jsx:51-52); verify the same default ships in production notification-preference initialization for new accounts.
• Comment-truncation class of bugs — the current app's text-comment field truncates content (multiple coach reports). The redesign de-emphasizes free text in favor of voice reply, but any remaining text-input surface (coach private/shared notes, the 1:1 message composer, the self-reflection field if later built) must be explicitly tested for truncation — this is a bug class, not a single screen's bug, and needs its own QA pass across every text field in the shipped app.