Classroom experience program: Standalone, Student, and Instructor #288

Goal

Evolve Intake into three explicit experience roles without weakening the existing browser-first standalone product:

• Standalone — today's local-first Intake experience, with Templates and optional ad-hoc collaboration.
• Student — class-aware individual or group workspaces, Templates + Case Studies, and instructor coaching.
• Instructor — class roster, rapid switching between student/team workspaces, read-only live observation, and field-level coaching.

This is a long-running workstream. The repository, issues, and PRs must remain sufficient to restart the work from cold context; no implementation decision may exist only in chat history.

Architectural invariants

1. Experience role is not intake mode. standalone | student | instructor is independent from General / IT / Pharma / Major Incident.
2. Experience role is not serialized Intake state. It must not enter kt-intake-full-v2, Save/Load files, summaries, or curated Intake payloads.
3. Standalone remains local-first and backend-optional. A classroom outage must not break ordinary Intake use.
4. Student/team workspaces extend the existing collaboration model. Do not create a second competing snapshot/presence engine.
5. Instructor observation is read-only with respect to student Intake snapshots.
6. Coaching is a separate persistence/revision channel. Student edits, collaboration conflicts, template loads, and file restores cannot erase coaching.
7. Students cannot enumerate other class workspaces.
8. Instructor credentials and student class-join credentials are distinct from Case Study unlock passwords.
9. Case Study visibility and Case Study confidentiality are separate concerns. The first resource split may hide Case Studies from Standalone; the final secure-delivery slice must remove protected Case Study payloads from the general client bundle.
10. Every slice updates durable documentation, tests, and the workstream status before handoff.

Bootstrap PR

• Document and govern the Classroom Experience program #297 — Durable architecture, roadmap, restart ledger, and repository governance

Implementation issues

• Classroom 1/8: Experience-role foundation and entry/resume flow #289 — Experience-role foundation and entry/resume flow
• Classroom 2/8: Split Templates and Case Studies by experience role #290 — Split Templates and Case Studies by experience role
• Classroom 3/8: Class domain model, credentials, and workspace membership APIs #291 — Class domain model, credentials, and workspace membership APIs
• Classroom 4/8: Student class join, assignment, and resume experience #292 — Student class join, assignment, and resume experience
• Classroom 5/8: Instructor class dashboard and read-only live workspace observer #293 — Instructor class dashboard and read-only live workspace observer
• Classroom 6/8: Field-level coaching feedback channel and student feedback UI #294 — Field-level coaching feedback channel and student feedback UI
• Classroom 7/8: Server-gated Case Study catalog and payload delivery #295 — Server-gated Case Study catalog and payload delivery
• Classroom 8/8: Browser E2E, accessibility, and CI protection for role/classroom journeys #296 — Browser E2E, accessibility, and CI protection for role/classroom journeys
• Add critical-path Playwright and accessibility regression suite #279 — Existing Playwright/accessibility infrastructure used by Classroom 8/8: Browser E2E, accessibility, and CI protection for role/classroom journeys #296

Recommended dependency graph

Architecture/governance
        |
       #289
      /    \
   #290    #291
            |
           #292
            |
           #293
            |
           #294

#290 + #291 --------> #295
#279 + all slices ---> #296

#290 may stack on #289 while #291 is implemented independently on top of #289. Once #291 is available, #292–#294 form a natural vertical stack. #295 requires the resource semantics from #290 and authorization boundary from #291. #296 should accumulate browser coverage as slices land rather than waiting until the end.

PR rules for this program

Every classroom PR must state:

• parent issue (Classroom experience program: Standalone, Student, and Instructor #288) and child issue;
• exact base branch / prerequisite PR when stacked;
• invariants touched;
• API/storage/security impact;
• automated and manual evidence;
• rollback boundary;
• what a cold AI should do next if the PR is left open.

A stacked PR must not pretend to be independently mergeable when its base has not landed.

Existing foundation to reuse

• src/intakeModes.js / src/intakeModeController.js
• src/templateKinds.js, src/templates.js, src/templatesDrawer.js
• src/collaboration.js
• api/workspaces/* and Neon-backed workspace/presence persistence
• kt-collaboration-profile-v1 local identity preference
• canonical npm run quality repository gate
• Add critical-path Playwright and accessibility regression suite #279 for real-browser/accessibility test infrastructure

Definition of program complete

All child slices are merged, Standalone remains backward-compatible, Student and Instructor critical journeys have browser coverage, protected Case Study data is no longer shipped to unauthorized clients, security/retention/credential behavior is documented, and a fresh AI session can continue maintenance using repository documentation alone.

Foundation completion

The original #288 Classroom foundation is complete as of PR #308 / merge 6c58336ac1677764641c09eadb201abcad8eeac1.

Delivered:

• all Classroom 1/8: Experience-role foundation and entry/resume flow #289–Classroom 8/8: Browser E2E, accessibility, and CI protection for role/classroom journeys #296 slices merged;
• Add critical-path Playwright and accessibility regression suite #279 Playwright/axe browser foundation merged;
• Standalone remains backward-compatible and backend-optional;
• Student/Instructor authorization isolation has Node/API and real-browser coverage;
• Instructor observation is read-only and coaching is a separate persistence/revision channel;
• protected Case Studies are server-gated and absent from public static assets;
• the branch-protected tests status now includes the required browser regression suite;
• repository docs support cold restart without prior chat context.

This closes the foundation program, not the long-term facilitated teaching vision.

Approved follow-ons:

• Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312 — Instructor-run live class, roster, one-code Student admission, and dynamic team management.
• Classroom follow-on: Instructor-orchestrated case simulation and staged debrief #313 — Instructor-orchestrated staged Case Study simulation and debrief, built on Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312.

The next implementation work should begin with #312 from current main; #313 follows once live class/team assignment is a stable substrate.