v2 Admin Spec — Semester Management

Semester Management

Domain 3 of the Enhanced Candidate A navigation structure. Contains: Semesters list + Semester Hub Page (5 tabs: Overview, Setup Checklist, Enrollment, End Checklist, Onboarding Support), Welcome Package, Tags, Operations. Primary workflows served: WF1 (Semester Setup), WF3 (Semester Close)

1. Domain Overview

Semester Management groups everything related to the lifecycle of a semester -- from initial setup through active management to close. Moving Welcome Package, Tags, and Operations here from the former Settings section puts them where they logically belong: these are all semester-scoped configuration items.

Key design decisions:

• Semester Hub Page is the centerpiece -- a multi-tab entity page consolidating all semester configuration, enrollment visibility, end-of-semester tracking, and onboarding support into one place
• Setup Checklist is a borrowed workflow concept (from WS1.3) that tracks completion without enforcing sequence -- the admin can configure items in any order
• End Checklist is a flat, non-gated checklist structurally parallel to Setup Checklist. Automatic items are driven by backend triggers; manual items are admin-completed. Directly addresses the pain point where gated sequencing felt too rigid for 1-3 power users
• Onboarding Support tab groups student-facing onboarding affordances (group chat links, welcome videos, countdown) separate from the operational Setup Checklist
• Tags moved here because tags are created per semester (semester-scoped)
• Operations moved here because bulk actions (promotions, registrations) are semester events

Sidebar items:

Semester Management
  Semesters                     <- from top-level
    [Semester Hub Page] (NEW -- rich multi-tab semester view)
      [Tab: Overview]
      [Tab: Setup Checklist]
      [Tab: Enrollment]
      [Tab: End Checklist]           <!-- v2 change: replaces Close Workflow, see ADR-001 -->
      [Tab: Onboarding Support]      <!-- v2 change: new tab, see Framework v2 §3.2 -->
  Welcome Package               <- from Settings
  Tags                          <- from Settings
  Operations (bulk actions)     <- from Settings (4 cards, down from 5 — Level 0 promote moved to Enrollment tab per ADR-005)

Data tables referenced: semester, user_link_level_tag, lessonsnew, assessment, resources, live_sessions, recordings, tutorials, mcqquestion, quiz, level_tag, users, user_profile, tags, subscriptions, group_members, group_name

Workarounds Eliminated

2. Screen: Semesters List

2.1 Purpose

View all semesters with their status. Entry point to Semester Hub pages.

2.2 Entry Points

• Sidebar: Semester Management > Semesters
• Dashboard: phase prompt click

2.3 Layout

Data table (small dataset, no pagination needed). Uses standard Data Table pattern from 01-global-patterns.md Section 4.1. No filter bar (typically <10 semesters).

2.4 Data Displayed

2.5 Actions

Auto-Transition quick access

A prominent "Auto-Transition" button appears in the toolbar above the table (primary style, with calendar-clock icon). Clicking opens a dialog listing all semesters with their current auto-transition status (on/off) and scheduled activate/deactivate dates. From this dialog the admin can toggle auto-transition for any semester without navigating into its Hub. The same toggle also remains in the Overview tab (§3.5) for in-context control.

2.6 States

2.7 Role Visibility

• Admin: Full view + Create/Edit/Delete actions + Auto-Transition dialog
• View-Only: View table only (no Create, Edit, Delete, or Auto-Transition buttons)
• TA / Support Staff: Hidden (sidebar item not visible, per 01-global-patterns.md Section 3.2)

3. Screen: Semester Hub Page (Rich Entity Page)

3.1 Purpose

Single consolidated view of everything about a semester: configuration, content setup status, enrolled students, end-of-semester tracking, and onboarding support. This is the second most complex entity page in the system (after Student Detail Page with 6 tabs). Directly addresses WF1 (19+ screens --> 8-10) and WF3 (8+ screens --> 4-6).

3.2 Entry Points

• Semesters list: row click
• Dashboard: phase prompt link (e.g., "Spring 2026 -- Setup Phase" click)
• Global search: semester result click (01-global-patterns.md Section 2.3)
• Student Detail > Semester History tab: semester name click (03-student-management.md)
• Setup Checklist / End Checklist deep link return ("Return to Checklist" affordance from content screens -- see Section 3.6 / 3.8)

3.3 Entity Header

Persistent header visible across all tabs (follows Entity Page pattern from 01-global-patterns.md Section 4.11):

Header action: Clone Content from Previous

A secondary-style "Clone from Previous" button in the header allows the admin to re-run or retry the auto-clone at any time (useful if auto-clone was skipped on create, partially failed, or a later-approved prior semester is preferred as the source). Opens the same semester selector dialog used by Setup Checklist's per-group clone. Confirmation: "Clone content from [Previous Semester]? Existing content in [Current Semester] will NOT be overwritten."

Breadcrumb: Semester Management > Semesters > [Semester Name]

3.4 Tab Structure

Tab behavior follows 01-global-patterns.md Section 4.11: lazy-load on first activation, state preserved when switching, URL updates with tab name (e.g., /semesters/123#setup-checklist, /semesters/123#end-checklist, /semesters/123#onboarding-support), sticky tab bar on scroll.

3.5 Tab: Overview

Data Displayed

Dates section (card layout with inline documentation -- info icon tooltips on each field, per 01-global-patterns.md Section 6.1):

Status Controls section (toggle switches with inline documentation):

Automation section (read-only summary cards):

Actions

States

3.6 Tab: Setup Checklist

Borrowed from Workflow framework (WS1.3): tracks completion without enforcing sequence. The admin can configure items in any order. Enhanced with Candidate C elements: deep links to content screens with semester pre-filtered, inline content previews, and "return to checklist" affordance.

Layout

Grouped checklist with overall progress bar at top. Each group is a collapsible section. Each item shows status, count, and action link.

Overall Progress

Top of tab: progress summary card.

Checklist Structure

Items grouped by content type. Within each group, one item per level (where applicable) or one aggregate item (where content is not level-scoped).

Group: Video Lessons

Group: Assessments (Submissions)

Group: Resources

Group: Live Sessions

Group: Recordings

Group: Tutorials

Group: Quizzes

Group: MCQ Questions

Group: Configuration

Group: Custom Items

Admin-defined checklist items specific to this semester. Empty by default.

Inline Content Preview (from Candidate C)

Each item with "Configured" status includes an expandable preview:

• Collapsed (default): Shows status badge + count only (e.g., "12 videos")
• Expanded (click to expand): Shows the first 3 items inline without navigating away:
  • Video Lessons: thumbnail + title for the first 3 videos
  • Resources: file icon + title for the first 3 resources
  • Assessments: prompt title for the first 3 assessment prompts
  • Email Templates: template name + trigger for the first 3 templates
  • Other content types: title/name for the first 3 items
• "View all X items -->" link at bottom of expanded preview: navigates to the full content screen with semester pre-filtered (same as "Configure -->" link)

"Return to Checklist" Affordance (from Candidate C)

When navigating from a checklist deep link to a content screen:

Actions

States

3.7 Tab: Enrollment

Purpose

View and manage all students enrolled in this semester. Provides at-a-glance enrollment visibility without navigating to Student Management. Also serves as the Registration Tracker view during the registration window (via the Registration filter preset) and as the entry point for Level 0 bulk promotion.

Data Displayed

Summary bar (horizontal bar above table): "X students enrolled | Y in Level 0 | Z in Level 1 | ... | W in Year 2 | N new this semester"

Source: counts from user_link_level_tag grouped by level_tag_id where semester_id = this semester. "New this semester" count = students whose user_link_level_tag.created_at falls within the semester's registration window (registration_open_date to registration_close_date, or fall back to semester.start_date - 30 days to semester.start_date if those fields don't exist). Includes both first-time enrollees and returning students re-enrolling.

Filter presets (chip bar above filter fields)

When the Registration preset is active, a sub-filter toggle appears in the filter bar labeled "New This Semester Only". When checked, the view further narrows to level_tag.name = 'Level 0' AND user_link_level_tag.is_first_semester = 1 (first-time enrollees awaiting level assessment).

The Registration preset is selectable regardless of semester phase; its filter criteria work year-round (see §9 open questions on whether to restrict visibility to the registration window).

Filter bar (standard pattern from 01-global-patterns.md Section 4.2):

Data table:

Pagination: Standard pagination (01-global-patterns.md Section 4.1): 25 records per page.

Actions

States

3.8 Tab: End Checklist

Replaces the v1 gated 5-step Close Workflow with a flat 5-step checklist structurally parallel to the Setup Checklist (§3.6). Each step has a defined scope (which students it applies to), an auto-completion trigger, and — where automation may fail or the admin needs to intervene — a manual fallback interface accessed by clicking the step. There is no ordering gate between steps; they may complete in any order as their trigger conditions fire. Progress bar across the top mirrors the Setup Checklist UX.

Layout

Flat list of 5 numbered steps plus a "Custom Items" section at the bottom. Progress bar at top. Each step row shows: step number, title, scope badge, status indicator, auto-complete trigger note, and "Open" link to the step's detail view. No sub-groups — 5 steps is a short enough list that grouping adds friction.

Inline Documentation Block (01-global-patterns.md Section 6.3)

Collapsible "How does this work?" block at top of tab:

"The End Checklist tracks the 5 tasks required to close a semester. Steps auto-complete as their conditions are met (e.g., the submission close date passes; every student has a final status assigned). For any step, you can click Open to see the current state and — if automation didn't fire or you need to intervene — manually complete individual students. Steps do not need to complete in order; they complete whenever their conditions are met. Add custom items below for anything this semester requires beyond the defaults. When all 5 steps (and any custom items) are complete, the semester closes automatically at midnight EST on the end date."

Overall Progress

Checklist Structure

The canonical 5 steps per STAKEHOLDER-ANSWERS-2026-04-21.md §1 (Lejla's definition):

Step 1 — All Submissions Reviewed

• Scope: All enrolled students (all levels, including Mastery)
• Type: Automatic (manual fallback via "Open" view)
• Auto-complete trigger: Submission close date has passed AND zero pending submissions remain for this semester
• On click ("Open" action): Deep links to the Submissions screen (03-student-management.md §4) filtered to this semester, pending-only. Admin (or TA for own students) reviews and grades from there. When the pending list is empty, Step 1 marks itself Complete automatically. Sets ?from=end-checklist&semester=[id] for return banner.
• Status display: Complete: green checkmark + "Reviewed on [date]" / Pending: amber circle + "[N] students with pending submissions"

Step 2 — Pass/Fail

• Scope: Level 1–4 students only (Mastery students are excluded — their final_status is set to mastery_passed automatically at Step 5)
• Type: Semi-automatic (TAs or admins set final_status per student; progress auto-tracked)
• Auto-complete trigger: 100% of enrolled Level 1–4 students have a final_status assigned (pass or fail)
• On click ("Open" action): Deep links to Students list (03-student-management.md §2) filtered to this semester, Level 1–4, final_status IS NULL. TAs can set status for their own assigned students; admins can set for any student. Per-student action: "Set Pass/Fail" → selector (Pass / Fail). Bulk action: "Set Pass/Fail for Selected". Sets ?from=end-checklist&semester=[id] for return banner.
• Mastery handling: Mastery students do not appear in the Step 2 queue. Their status is deferred to Step 5 auto-pass.
• Status display: Complete: green checkmark + "All L1–L4 students assigned ([N] pass, [M] fail)" / Pending: amber circle + "[N] L1–L4 students without status"

Step 3 — Send Pass/Fail Emails

• Scope: All enrolled students, branched by track:
  • L1–L4 students with final_status = 'pass' → "End of Semester — Pass (L1–L4)" template
  • L1–L4 students with final_status = 'fail' → "End of Semester — Fail (L1–L4, Opt-in Repeat)" template. Contains opt-in-to-repeat link. Students are NOT automatically re-enrolled; they must follow the link. Opt-in is fully self-service — no admin approval required (confirmed STAKEHOLDER-ANSWERS-2026-04-22 §C Q2). The link directs the student to the repeat-discount checkout (see 08-billing-payments.md), which cross-references the per-semester repeat-eligible list. Students who need manual addition to that list (e.g., skipping a semester before repeating) are handled via the per-student "Mark as Repeat-Eligible" action on Student Detail (see 03-student-management.md §3.10 Actions tab).
  • Mastery students → "End of Semester — Mastery Elective Prompt" template. Prompts signup for same or different elective next semester.
• Type: Automatic send + manual per-student fallback
• Auto-complete trigger: All students have been sent their appropriate email (per their track). Status is tracked per-student in communication_logs.
• On click ("Open" action): Deep links to the End Checklist Email Queue (11-communication.md §2.6) for this semester, filtered to the "work to do" subset (Unsent + Failed + Bounced). Each row shows: student name, level, final_status, email template that applies to their track, send status, and a per-student "Send Now" button to trigger the correct template manually. Bulk action: "Send Pending Emails". Sets ?from=end-checklist&semester=[id]&filter=unsent for return banner.
• Email templates: Three system-seeded templates live in Communication > Automation Emails (see 11-communication.md §2.4.5). Trigger conditions are fixed; template content is admin-editable.
• Status display: Complete: green checkmark + "Emails sent: [N] pass, [M] fail, [K] mastery" / Pending: amber circle + "[N] students not yet emailed"

Step 4 — Set Up Automatic Payments

• Scope: Level 1–4 students with final_status = 'pass' (failing students are excluded — they opt in via the Step 3 email link and re-enroll manually; Mastery students are excluded — they self-enroll in their next elective)
• Type: Automatic + manual per-student fallback
• Auto-complete trigger: All eligible passing L1–L4 students have payment_setup_status = 'created' (or 'exempted' where applicable)
• On click ("Open" action): Deep links to the End Checklist Payment Setup Queue (08-billing-payments.md) for this semester, showing passing L1–L4 students with their per-student payment_setup_status (Pending / Created / Failed / Exempted). Per-student action: "Set Up Payment" → triggers Stripe subscription creation for next semester start date using the student's existing payment method and plan. Bulk action: "Set Up Payments for Selected". Sets ?from=end-checklist&semester=[id] for return banner.
• Payment setup definition: Creates a Stripe subscription for the passing student starting on the first day of the next semester. Failed setups (e.g., expired card) show Failed status for admin triage.
• Status display: Complete: green checkmark + "[N] payments set up" / Pending: amber circle + "[N] eligible students without payment setup"

Step 5 — Semester Close

• Scope: Semester-level (no per-student action)
• Type: Fully automatic
• Auto-complete trigger: System clock reaches midnight EST on semester.end_date. At that moment: (a) semester.is_current is flipped off, (b) Mastery students' final_status is set to mastery_passed, (c) semester transitions to historical / read-only state.
• On click ("Open" action): Read-only confirmation view showing "Semester closes automatically at midnight EST on [end_date]. No admin action required." Shows a countdown when <24 hours remain.
• Status display: Complete: green checkmark + "Closed on [timestamp]" / Pending: amber circle + "Closes at [timestamp]"

Leavers — No checklist step

Per STAKEHOLDER-ANSWERS-2026-04-21.md: "On leavers — no checklist step needed. They handle their own enrollment and payment; they'll simply stay inactive going forward." No admin action is required during semester close for leavers; they remain inactive until they independently re-enroll.

Custom Items

Admin-defined items specific to this semester. Empty by default. Same UX as Setup Checklist custom items (§3.6).

Actions

"Return to End Checklist" Affordance

Same pattern as Setup Checklist's "Return to Checklist" banner (§3.6). When a step's "Open" link is followed, the target screen shows a persistent banner: "← Return to End Checklist for [Semester Name]." Triggered by ?from=end-checklist&semester=[id]. Clicking returns to this tab with scroll position preserved.

States

3.9 Tab: Onboarding Support

Purpose

Configure student-facing onboarding affordances for this semester: Telegram/WhatsApp group chat links, on-app welcome videos, and a semester-start countdown timer. This tab is admin-facing configuration; student-facing rendering is in the student app (backend-bound).

Layout

Three stacked cards on a single tab — one per sub-feature. Each card is self-contained with its own fields, controls, and state.

Card 1: Group Chat Links

Manages Telegram and/or WhatsApp group links that students see in the app. Each link has a label, URL, and access scope.

Data displayed (list within card):

Access Scope options (determined at link creation / edit — see §9 open question on final scope model):

• All students — visible to every enrolled student in this semester
• By role — visible to students holding a selected role (e.g., mastery, regular). Role dropdown populated from user roles.
• By level — multi-select checkboxes: Level 0 / Level 1 / Level 2 / Level 3 / Level 4 / Year 2
• Per student — multi-select autocomplete of individual students enrolled in this semester

Actions:

States:

Card 2: Welcome Videos

Configures welcome videos that appear on the student home screen when they open the app (especially on first launch in this semester).

Notes:

• [backend]: actual video playback and delivery to the student app is production-only. This card is a UI affordance only — the mockup allows configuration but does not play videos to students.
• Videos are semester-scoped; a student sees videos assigned to their current semester.

Data displayed (list within card):

Actions:

States:

Card 3: Countdown Timer

A single on/off timer that counts down to the semester start, surfaced on the student onboarding/home screen.

Fields:

Actions:

States:

4. Screen: Welcome Package

4.1 Purpose

Manage resources included in the new student welcome package for each semester. These are files (PDFs, documents, media) sent or made available to students upon enrollment. Relocated from Settings to Semester Management because welcome packages are semester-scoped.

Transition hint (01-global-patterns.md Section 6.4): "Formerly under Settings" -- shown for first 30 days after launch.

4.2 Entry Points

• Sidebar: Semester Management > Welcome Package
• Semester Hub > Setup Checklist: "Configure -->" link (with ?from=checklist&semester=[id] for return affordance)

4.3 Layout

Semester selector (dropdown at top, defaults to current/active semester) + resource list with upload capability. Uses standard Data Table pattern for the resource list.

4.4 Data Displayed

4.5 Actions

4.6 States

4.7 Role Visibility

• Admin: Full CRUD (Upload, Edit, Delete, Reorder, Clone)
• View-Only: View list + Preview/Download. No Upload, Edit, Delete, Reorder, or Clone buttons.
• TA / Support Staff: Hidden (sidebar item not visible)

5. Screen: Email Management (MOVED)

Email Management has moved to Communication > Automation Emails. See 11-communication.md for the full specification of automation email templates, sequence view, trigger conditions, template library, preview, test-send, and clone-from-previous functionality.

This section header is preserved in 04-semester-management.md for cross-reference traceability only. All Email Management functionality, entry points, and data responsibilities now live under the Communication domain.

Impact on this domain:

• Sidebar item Semester Management > Email Management is removed.
• Setup Checklist (§3.6) "Email Templates" deep link retargets to Communication > Automation Emails with ?semester=[id].
• Overview tab (§3.5) "View All Emails" link retargets to Communication > Automation Emails filtered to the current semester.
• Semester scoping is preserved in Communication > Automation Emails as a filter (not as a parent domain constraint).

6. Screen: Tags

6.1 Purpose

Create and manage tags for user segmentation. Tags are semester-scoped and sync bidirectionally with InfusionSoft (CRM). Used for marketing segmentation, student categorization, and automated workflow triggers. Relocated from Settings.

Transition hint: "Formerly under Settings" -- shown for first 30 days.

Auto-applied enrollment tags: Per-semester enrollment records carry an enrollment_type field (Continuing / New / Repeat / Year 2 — see 03-student-management.md Students list + Student Detail Enrollment section) which is the canonical source of truth for how a student is enrolled in that semester. To keep InfusionSoft in sync for marketing segmentation, a matching tag (new-[semester], repeat-[semester], continuing-[semester], year2-[semester]) is auto-created by the system and applied to students when their enrollment record is written. Admin can see these tags in this list (typically badged "System" and not deletable), and they sync to InfusionSoft like any other tag. Do NOT use the repeat-[semester] tag in place of the enrollment_type field for in-app filtering — the field is the canonical signal; the tag is a CRM projection.

6.2 Entry Points

• Sidebar: Semester Management > Tags
• Semester Hub > Setup Checklist: "Configure -->" link (with return affordance)

6.3 Layout

Semester selector (dropdown at top, defaults to current/active semester) + tags list. Uses standard Data Table pattern. No filter bar needed (typically <30 tags per semester).

6.4 Data Displayed

6.5 Actions

6.6 States

6.7 Role Visibility

• Admin: Full CRUD (Create, Edit, Delete, Retry Sync)
• View-Only: View list only. No Create, Edit, Delete, or Retry buttons.
• TA / Support Staff: Hidden (sidebar item not visible)

7. Screen: Operations (Bulk Actions)

7.1 Purpose

Perform bulk data operations that are semester-scoped. Provides a centralized place for high-volume administrative actions that would be tedious to perform one-by-one. Relocated from Settings.

Transition hint: "Formerly under Settings" -- shown for first 30 days.

7.2 Entry Points

• Sidebar: Semester Management > Operations

7.3 Layout

Action cards -- each bulk operation is a card with icon, title, description, and action button. Cards arranged in a responsive grid (2 columns on desktop, 1 on narrow screens). No data table -- this is a launcher page.

7.4 Available Operations

Card 1: Bulk Year 1 --> Year 2 Promotion

Card 2: Bulk User Registration

Card 3: Upload Backend Resources

Card 4: Data Migration

7.5 States

7.6 Role Visibility

• Admin: All operation cards visible and actionable
• View-Only / TA / Support Staff: Hidden (sidebar item not visible -- bulk operations are admin-only)

8. Cross-Domain Integration Points

This section documents how Semester Management connects to other domains. Each integration is specified in detail in the target domain's spec document; this section provides a summary for reference.

8.1 Dashboard (02-dashboard.md)

8.2 Student Detail Page (03-student-management.md)

8.3 Content Domain (05-content.md)

8.4 Scheduling Domain (06-scheduling.md)

8.5 Teacher Management Domain (07-teacher-management.md)

8.6 Billing & Payments Domain (08-billing-payments.md)

v2 note — see ADR-001 and STAKEHOLDER-ANSWERS-2026-04-21: In v1, the Step 2→3 gate explicitly ordered promotions before billing. In v2, this is mitigated by Step 4's scope being defined as "L1–L4 passing students only" — only students with final_status = 'pass' are eligible. Since Step 4 completion depends on final_status being set (which is Step 2's purpose), the ordering is enforced by scope rather than by UI gating. The manual per-student fallback in Step 4 is scope-filtered too: admins can only manually set up payments for students already marked Pass.

8.7 Communication Domain (11-communication.md)

9. Assumptions and Open Questions

ADR-001 open questions resolved 2026-04-21: All ADR-001 open questions are now resolved per docs/v2-review/STAKEHOLDER-ANSWERS-2026-04-21.md §1. See that document for the canonical 5-step End Checklist definition.

This domain relies on several assumptions documented in 00-spec-index.md. Summary of semester-management-specific assumptions:

New open questions for v2 (carry into 00-spec-index.md on next update):

• SQ1: How many Setup Checklist items per semester are typically applicable? If many items are consistently N/A, consider configurable templates per semester type. Assumed: all items applicable by default.
• SQ3: Should the auto-transition feature (Overview tab, §3.5) support registration auto-close in addition to semester activation/deactivation? Assumed: no -- registration close is a separate manual decision.
• SQ4: How should the Setup Checklist handle content that spans multiple levels (e.g., a resource available to all levels)? Assumed: content appears under each applicable level item (may result in some double-counting in progress, but avoids missing items).
• SQ6 (End Checklist defaults) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md §1. Lejla's 5-step End Checklist (All Submissions Reviewed, Pass/Fail, Send Pass/Fail Emails, Set Up Automatic Payments, Semester Close) replaces the prior TBD scaffold. See §3.8 for the canonical definition.
• SQ7 (End Checklist trigger conditions) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md §1. Each of the 5 canonical steps has a defined auto-completion trigger documented in §3.8.
• SQ8 (Automatic vs. semi-automatic) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md §1. Step 1 (Automatic w/ manual fallback), Step 2 (Semi-automatic — per-student set by TA/admin), Step 3 (Automatic send w/ per-student manual fallback), Step 4 (Automatic w/ per-student manual fallback), Step 5 (Fully automatic). See §3.8.
• SQ9 (W4 risk without gate) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md §1. Step 4's scope is defined as "L1–L4 passing students only" — the scope filter (students with final_status = 'pass') enforces promotion-before-billing ordering without requiring a UI gate. Manual per-student fallback is also scope-filtered.
• SQ10 (End Checklist audit trail) : V1 gate overrides were logged to Reporting > Logs with admin name, reason, timestamp. What audit trail equivalent (if any) does the End Checklist need? Candidate: log every manual Set Pass/Fail, every manual Send Now, every manual Set Up Payment, every custom item creation.
• SQ11 (NEW — Onboarding Support access control for group links) : The spec lists four access-scope options for group chat links (All / By role / By level / Per student). Stakeholder to confirm which are actually needed and whether a simpler single model (e.g., By level only) is sufficient for launch.
• SQ12 (NEW — Welcome videos scope) : Are welcome videos general tutorials (e.g., "How to use the app") reused across semesters, or semester-specific welcome content? If general, they should live at the system level; if semester-specific, this tab is the right home. Spec assumes semester-specific.
• SQ13 (NEW — Countdown target default) : Should the countdown target default to the semester start_date at midnight local time (current spec), at the student's local time, or at EST? Timezone handling TBD.
• SQ14 (Registration preset visibility / scope) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md §2 (defaults #11–12). The Registration preset shows all students enrolling in the semester (both new first-time enrollees and returning students re-enrolling), with a sub-filter toggle ("New This Semester Only") for first-time Level 0 students. Available year-round whenever Level 0 exists. See §3.7.
• SQ15 (Level 0 promote target) — Resolved 2026-04-21 per STAKEHOLDER-ANSWERS-2026-04-21.md — Level 2 confirmed by stakeholder. Lejla: "Level 0 is a placeholder for students whose level hasn't been assessed yet, and our default has always been to place them at Level 2." See §3.7 Bulk-Promote Level 0 action.
• SQ16 (NEW — One-to-One Schedules) : Stakeholder requested a "One-to-One Schedules" Setup Checklist item distinct from TA Schedules. Spec does not yet include a separate item. Needs clarification: is this the same as TA Schedules, or distinct (e.g., 1:1 appointment slots vs. class-level availability)?
• SQ17 (NEW — Submission Close Date field) : Stakeholder mentioned a "Submission Close Date" field in semester setup. Spec currently has Start Date / End Date / Registration Start / Content Availability Date, but no Submission Close Date. Needs clarification: is this a new semester-level date field, per-level, per-assessment, or deprecated?

10. Framework v2 Change Summary