[MajorIncident]

Issue

• Classroom follow-on: Instructor-orchestrated case simulation and staged debrief #313 — Instructor-orchestrated case simulation and staged debrief
• Parent program: Classroom experience program: Standalone, Student, and Instructor #288
• Dependency: Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312 / PR Add Instructor-run live classroom management #314 merged as b141d55050207e4cf7ce842a4452a220a5268968
• Branch: feature/classroom-staged-simulation
• Base: main

Goal

Turn the live Classroom substrate into an Instructor-orchestrated staged simulation:

select staged Case Study
  -> start stage
  -> release only authorized Student case material
  -> teams reason/document in Intake
  -> Ready / observe / coach
  -> debrief checkpoint
  -> optional server-enforced edit freeze
  -> advance class together
  -> preserve same team Intake across stages

Tranche 1 — architecture / server contract

Architecture checkpoint: 808bdfaa74e7e6a11a88173ee43c5c86d9a8da51.

Canonical contract: docs/classroom-staged-simulation.md.

Decisions:

• Classroom follow-on: Instructor-orchestrated case simulation and staged debrief #313 layers class-level exercise orchestration over Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312; it does not create a second collaboration/assignment engine;
• exercise state remains separate from Intake snapshot, collaboration revision, coaching state, exports, and summaries;
• Student staged reads use the stable Student class-session capability so late/unassigned learners can safely receive the current class release;
• Student Intake editing remains assignment-specific workspace-capability authorized;
• future-stage material and Instructor-only facilitation/model material are withheld server-side;
• existing complete Case Study state is source/exemplar material and cannot be the staged Student feed;
• staged cases require an explicit server-only optional simulation definition; official stages must never be inferred from a completed Intake payload;
• active staged Case Study Student full-payload retrieval must be blocked as a progressive-disclosure bypass;
• readiness is workspace/team scoped;
• entering debrief captures immutable per-workspace checkpoints because collaboration does not retain historic snapshots;
• optional edit freeze must be enforced by the Student collaboration write API, not only UI disabling;
• Instructor lifecycle mutation uses optimistic exercise_revision;
• late join enters the current stage; reassignment changes workspace Intake/readiness without changing class stage;
• use synthetic deterministic staged content in tests until authoritative production case material is supplied/reviewed.

Governance checkpoints:

• roadmap: 2a35dc5b81eaa8427bf91d7b8897e09417af18cc;
• workstream: 4cc497e4410d3562c20161199212cc98879e5355;
• API guardrails: af6b6f21a8e4f25f014a8362857a1c15e252775b (restored alongside tested schema work);
• staged Case Study authoring rules: 294fa82164f10c3a0cc14a2f8577abde51b04c31;
• root cold-start rules: 8f158aa58ba70b188e4b4bfe28490499f1279a4c.

No schema/runtime/UI changes are part of this tranche.

Tranche 2 — staged Case Study authoring schema

Implementation checkpoint: af6b6f21a8e4f25f014a8362857a1c15e252775b.
Documentation checkpoint: ccae0a1800b7e2dd269c2da19ad095685698db1e.

Implemented:

• optional simulation is accepted only on protected case-study resources;
• existing non-staged Case Studies remain valid without modification;
• public Standard Templates cannot carry simulation definitions;
• Student and Instructor content use separate namespaces and cannot collide;
• stable stage/content IDs, uniqueness, reference validity, no initial/optional overlap, and no orphan content are enforced;
• v1 rejects unknown fields rather than silently widening the protected contract;
• Student blocks support structured narrative/prompt/evidence/image/table/document-page content;
• protected image/document references use stable assetId, not arbitrary public URLs;
• Instructor blocks support facilitation/debrief/exemplar material;
• server-only manifest preserves a valid simulation definition when one is explicitly authored;
• no production Case Study was staged or inferred from its completed Intake payload.

Validation on implementation head:

• repository quality: 260 tests / 259 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• Template Manifest Guard and Dependency Review green.

Tranche 3 — exercise persistence / repository

Implementation checkpoint: c01dfff2f2bd1f9d7625901860210cc00eee7051.
Documentation checkpoint: 457cb50edd94e355a9e7ec83f11972590da6b4b7.

Implemented:

• additive classroom_exercises, optional-release, workspace-readiness, and immutable-checkpoint persistence;
• one non-completed exercise per class initially;
• exercise lifecycle/status/stage/phase/editing-policy state with optimistic exercise_revision;
• exercise inherits owning-class expiry;
• staged definition identity is pinned by simulation version + definition fingerprint so later APIs can fail closed on definition drift;
• optional release first-write increments exercise revision once; replay is unchanged/idempotent; stale different release conflicts;
• Student readiness resolves through stable class-session authority to the participant's current workspace;
• readiness remains team/workspace scoped across reassignment; Waiting cannot mark a workspace Ready;
• debrief checkpoint capture is class/workspace scoped, immutable, first-write-wins, and snapshot-isolated;
• no ordinary exercise operation copies or merges Intake snapshots;
• deterministic in-memory repository mirrors the Neon contract.

Final validation on documentation head 457cb50edd94e355a9e7ec83f11972590da6b4b7 after definition-identity hardening:

• repository quality: 265 tests / 264 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, Template Manifest Guard: green.

Exact next tranche: Tranche 4 exercise APIs/authorization only — Instructor create/read/lifecycle/release/debrief/checkpoint/advance/complete, Student class-session current release + workspace readiness, staged-definition drift checks, and active-staged-case full-payload bypass closure. Build the full authorization matrix. Do not expose a claimed edit-freeze guarantee until Tranche 5 enforces it on Student collaboration PUT, and do not add exercise UI yet.

Tranche 4 — exercise APIs / authorization

Implementation/security-test checkpoint: 5afc0041db89348d97ca0986cab89491765d0e00.
Documentation checkpoint: 2282925ce7f5f52609f85bb0a8610856ecf87653.

Implemented:

• Instructor POST/GET/PATCH /api/classes/exercise for staged draft creation/read plus start/pause/resume/optional release/begin-debrief/advance/complete;
• optimistic exercise_revision lifecycle and immutable stage ordering;
• Student class-session GET /api/classes/exercise/student with cumulative Student-safe release only;
• Student current-workspace readiness endpoint with server-observed workspace revision and reassignment race guard;
• pinned simulation version/fingerprint validation on staged reads/mutations;
• immutable debrief checkpoint capture before later live edits;
• Student full protected Case Study payload bypass blocked for a case with a staged exercise record, including after completion;
• Instructor full protected access and unrelated resources remain compatible;
• staged responses remain no-store/no-referrer;
• no edit-freeze security claim yet: Tranche 4 returns editFreezeEnforced: false until the collaboration write guard lands.

Validation:

• repository quality: 273 tests / 272 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, Template Manifest Guard: green.

Exact next tranche: Tranche 5 server-enforced Student editing policy — enforce the staged exercise editing policy on classroom-student collaboration PUT before revision mutation, preserve GET/presence/coaching/readiness and Standalone/no-exercise behavior, define the temporary-lock response contract, and add direct authorization/regression tests. No exercise UI yet.

Tranche 5 — server-enforced Student editing policy

Implementation checkpoint: 261b28d488538964ccd73132ed568d73628f6411.
Documentation checkpoint: 1a0b316fabfb46f07267acbc6393b3a1ad2c7edc.

Implemented:

• classroom-student snapshot writes resolve the current staged exercise editing policy while primary/Standalone collaboration bypasses Classroom policy;
• frozen Student PUT /api/workspaces/session returns 423 Locked with stable code classroom-editing-locked;
• rejected frozen writes do not mutate snapshot or collaboration revision;
• production SQL repeats the freeze predicate atomically inside the UPDATE, closing Instructor-freeze-vs-Student-save races;
• both live Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312 participant aliases and legacy Classroom membership aliases are covered;
• workspace GET, presence, Instructor observation/coaching, staged Student reads/readiness remain available during freeze;
• debrief applies each stage's authored defaultDebriefEditPolicy;
• revision-safe Instructor set-editing supports explicit debrief freeze/unfreeze;
• Pause/Resume preserve current editing policy rather than implicitly unlocking;
• Standalone and classes without a staged exercise remain writable;
• staged payloads now truthfully expose editFreezeEnforced: true and authoritative studentEditingEnabled.

Validation:

• repository quality: 274 tests / 273 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, Template Manifest Guard: green.

Exact next tranche: Tranche 6 Instructor exercise console inside the existing live Instructor dashboard. Add staged Case Study selection/draft creation, Instructor-only stage/facilitation material, lifecycle/release/debrief/freeze/advance/complete controls, team readiness/progress, optimistic-conflict refresh, and existing observer/coaching navigation. Keep Student staged-case UI and production official-case staging deferred.

Planned implementation tranches

1. Architecture / server contract — current checkpoint.
2. Staged Case Study authoring schema — optional server-only simulation, validation/cross-references, public-boundary tests; no production stage guesses.
3. Exercise persistence/repository — additive exercise/release/workspace-state/checkpoint model + deterministic parity.
4. Exercise APIs — Instructor lifecycle, Student current release, readiness, full-payload bypass closure.
5. Server-enforced editing policy — temporary Classroom write lock with Standalone unaffected.
6. Instructor exercise console — select/start/pause/release/debrief/freeze/advance + readiness/progress.
7. Student case reference — current stage/released content beside Intake, ready/debrief/freeze transitions.
8. Checkpoint/debrief views — preserved pre-debrief reasoning and facilitation support.
9. Integrated browser/security/accessibility acceptance.
10. Final docs/security/merge readiness.

Security / rollback

• first runtime changes remain additive;
• Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312 classes/rosters/assignments work without an exercise;
• Standalone remains backend-optional;
• existing collaboration remains the live Intake source of truth;
• existing non-staged protected Case Studies remain compatible;
• staged Student responses never contain future or Instructor-only material;
• staged feature can be disabled without destructive schema rollback.

Cold restart

Read:

• AGENTS.md;
• docs/classroom-staged-simulation.md;
• docs/classroom-architecture.md;
• docs/classroom-api.md;
• docs/classroom-roadmap.md;
• docs/classroom-workstream.md;
• api/AGENTS.md;
• templates/AGENTS.md;
• Classroom follow-on: Instructor-orchestrated case simulation and staged debrief #313.

Tranche 6A — Instructor exercise console foundation

Implementation spans 2624f1e... through d20a303....

Implemented:

• Instructor GET /api/classes/exercise exposes a server-filtered availableCaseStudies list containing staged Case Study summaries only;
• discovery omits complete simulation definitions, protected source state, future Student content, and Instructor-only material;
• new src/classroomExerciseInstructor.js owns memory-only exercise discovery/current-state reads;
• the existing live Instructor dashboard contains the Class exercise console shell;
• Instructor capability/exercise context remain outside Intake state/storage/export/summary/public manifests.

Tranche 6B — staged Case Study selection and draft creation

Implementation spans 6a69426... through 5f3fb56...; deterministic synthetic browser-fixture support is at c3440eb....

Implemented:

• accessible staged Case Study selector populated only from server-filtered discovery;
• Create draft POST sends only the selected caseStudyId;
• successful create and created: false idempotent reuse both hydrate the server-owned draft in memory;
• once an exercise exists, selector/create are disabled;
• 409 create conflicts are not retried: the console performs an authoritative GET and renders the represented current exercise;
• controller public state continues to sanitize protected Case Study content and never exposes the Instructor capability;
• deterministic browser acceptance uses a synthetic staged case only, creates the draft, reloads the Instructor page, and proves server-backed draft resume;
• no official KT case stage content was added or inferred;
• the existing four-browser integration test had a 26.1s historical green runtime under a 30s global timeout and tipped over after the new exercise bootstrap read; its test-specific budget is now 45s without removing any assertions.

Tranche 6C — Start/Pause/Resume and current-stage Instructor context

Implementation spans 53ce2b7... through 2888beb..., followed by documentation synchronization on the same branch.

Implemented:

• draft-only Start, active-only Pause, and paused-only Resume controls;
• every lifecycle PATCH sends the current positive exerciseRevision;
• 409 lifecycle conflicts perform authoritative GET refresh and never replay stale Instructor intent;
• current stage title, Student objective, suggested timing, and only stage-referenced Instructor facilitation content render after Start;
• Pause is explicitly class pacing, separate from the later Student editing-freeze/debrief control;
• deterministic browser fixture mirrors Start/Pause/Resume revision semantics;
• focused controller coverage proves revision progression and conflict refresh;
• real-browser Instructor journey proves Start -> Pause -> Resume -> reload with server-backed current stage;
• the unrelated four-browser acceptance budget is raised narrowly from 30s to 45s after prior runs timed out in teardown; no product assertion is removed.

Tranche 6D — optional evidence release and team readiness/progress

Implementation spans 1de00a1... through green implementation head 2c8145b...; durable documentation checkpoint is 7ee2956....

Implemented:

• release controls project only the current stage's explicit optional Student content; future-stage optional evidence never appears as a release control;
• release-content uses the current exerciseRevision;
• an already-recorded release is idempotent, while a genuinely stale new release 409s and authoritative-refreshes without replay;
• current-stage workspaceState renders Ready/Working progress;
• progress rows reuse the existing Instructor observer/coaching selectWorkspace() path;
• exercise release/readiness state stays memory-only, local-only, and summary-excluded;
• deterministic browser coverage proves release -> Released, Ready progress, existing observer navigation, and state after reload;
• the expanded rail exposed a real nested-scroll usability defect; the inner workspace list no longer owns a competing scroll region, restoring genuine clickability without forced test actions.

Validation on 2c8145b31f96403f59ff3b41d9396fd2a3ac86ed:

• repository quality: 285 tests / 284 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, and Template Manifest Guard: green.

Tranche 6E — Begin Debrief, checkpoint review, editing policy, and compact class rail

Implementation spans 044e4f82... through green implementation head 61aa582...; durable documentation checkpoint is 41c2bdd....

Implemented:

• revision-safe Begin debrief from active current-stage work, with 409 authoritative refresh and no stale replay;
• server-captured immutable checkpoint status is rendered as workspace + captured revision only; checkpoint snapshot bodies are deliberately removed from controller public state and are not turned into editable Intake copies;
• authoritative studentEditingEnabled is shown separately from Pause/Resume;
• debrief-only Freeze editing / Allow editing use revision-safe set-editing; the existing server 423 write guard remains the actual enforcement boundary;
• observer/coaching remains available through debrief and editing freeze;
• browser acceptance proves work -> debrief -> checkpoint capture -> default freeze -> allow -> freeze -> reload;
• the Instructor class/team rail now has an accessible Collapse/Open control; narrow screens default to a compact collapsed header and can reopen normally, while desktop collapse reclaims Intake width;
• mobile coaching/observer acceptance opens the collapsed panel through the real control before team switching—no forced-click workaround.

Validation on 61aa582e9faee9a7e500796634c5cc06e256ff14:

• repository quality: 288 tests / 287 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, and Template Manifest Guard: green.

Mobile workspace UX follow-on: align Notes and the Instructor class rail around the same compact-mobile principle. Prefer an always-discoverable collapsed header/launcher rather than hiding either surface; evaluate making Notes default-collapsed on narrow screens and reducing its collapsed chrome.

Tranche 6F — Advance/Complete and Instructor-console lifecycle completion

Implementation spans e855df09... through green implementation head e2f5534...; durable documentation checkpoint is f36be4da....

Implemented:

• Advance to next stage appears only from active non-final debrief and follows the protected authored stage order; the client never submits an arbitrary next-stage ID;
• Advance is revision-safe, returns the represented exercise to work, restores authoritative Student editing for work, and renders only the new current stage's objective/timing/Instructor facilitation;
• Complete exercise appears only from active final-stage debrief and is revision-safe;
• Completed now renders as a terminal state ahead of the persisted debrief phase label, hides further lifecycle/edit-policy mutations, retains final-stage checkpoint review, and explicitly states that completion releases no additional Student/exemplar material;
• 409 lifecycle conflicts authoritative-refresh and never replay stale intent; focused coverage proves this for Advance;
• the deterministic browser case now has two synthetic authored stages and preserves prior-stage checkpoints;
• real-browser acceptance proves Stage 1 debrief -> Advance -> Stage 2 work -> Stage 2 debrief -> Complete -> reload while observer/coaching remains available.

Validation on e2f5534aa0e85bccc2bee0e73275c9b77d000f3d:

• repository quality: 290 tests / 289 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, and Template Manifest Guard: green.

Tranche 7A — Student current-stage case-reference foundation

Implementation spans e307ca2... through green implementation head 91d7029...; durable documentation checkpoint is 4605fff....

Implemented:

• dedicated src/classroomExerciseStudent.js owns the Student staged-exercise reference rather than expanding assignment authority;
• staged reads use only the stable live Student class-session capability with GET /api/classes/exercise/student; rotating workspace capabilities remain collaboration-only;
• classroomStudent.js now exposes separate stable session lifecycle hooks, so team reassignment rotates workspace authority without disconnecting the staged exercise reference;
• the Student controller projects only case summary, current stage/objective, phase/edit-policy state, and cumulative released Student-safe content; unknown future-stage and Instructor-only fields are discarded from DOM/public state;
• bearer capabilities and staged content remain memory-only and outside Intake persistence, browser storage, summaries, exports, URLs, and public manifests;
• Work/Paused/Debrief/frozen/Completed states are announced, and frozen debrief keeps released case material reviewable;
• the case reference polls authoritative exercise state and resumes server-backed after reload;
• mobile defaults to a compact collapsed reference. Real-browser testing exposed the existing fixed team/Notes workspace dock covering that control; Student narrow layouts now place the dock in normal document flow instead of floating over Intake, and the browser uses a normal click rather than a forced workaround;
• browser acceptance proves Stage 1 briefing + optional evidence are visible while Stage 2 and Instructor-only facilitation are absent, and proves the staged endpoint uses the stable Student session token.

Validation on 91d7029bec5cddaf251d02301a4fd1ce97dc908c:

• repository quality: 295 tests / 294 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 26 passed / 8 intentional skips / 0 failed;
• CI, CodeQL, Dependency Review, and Template Manifest Guard: green.

Tranche 7B — Student Ready / Resume Working

Implemented:

• readiness is available only during active work with a current assignment;
• Student uses only the stable class-session capability for PUT /api/classes/exercise/student/ready, sending exactly { ready: boolean };
• no workspace ID/token or client-claimed collaboration revision is sent;
• Ready displays the server-captured collaboration revision; Resume Working clears readiness;
• assignment/phase conflicts authoritative-refresh without replaying stale intent;
• focused and browser coverage prove Ready -> Resume Working and stable-session credential use;
• implementation spans e43b84c... through 247479f..., with browser acceptance through d311b7b....

Tranche 7C — frozen-debrief Student Intake projection

Implemented:

• authoritative frozen debrief state projects the Student Intake read-only while the server HTTP 423 guard remains the actual security boundary;
• original control state is restored on Allow Editing, advance/completion, staged-context loss, or disconnect;
• paused frozen debrief remains read-only;
• Leave Class remains available;
• Notes freeze with Intake because Notes are serialized into the collaborative snapshot;
• integrated browser acceptance uses the real Instructor Begin Debrief -> frozen Student Intake -> Allow Editing -> restored Student Intake path;
• implementation spans 8d70e84... through 50435c3...;
• durable Student-tranche documentation head: 636419a9a49cda92e57036ad990e814550aa1081.

Completed Tranche 8A — immutable checkpoint inspection versus current live work

• normal exercise reads expose checkpoint metadata only; snapshot bytes require explicit Instructor inspection;
• GET-only /api/classes/exercise/checkpoint?workspaceId=... is Instructor/class/stage scoped and never mints workspace authority or mutates live Intake;
• checkpoint snapshot bytes stay transient and out of exercise controller public state, persistence, summary/export, URLs, and resume state;
• the existing read-only Instructor observer renders Checkpoint at debrief start · Revision N and pauses live observation/coaching while historical evidence is displayed;
• View current live Intake performs a fresh observer read and restores current revision/coaching context;
• focused API/client tests cover explicit authorization, metadata-only listing, Student credential rejection, no snapshot leak, and checkpoint -> live restoration;
• dedicated two-browser acceptance compares the immutable pre-debrief checkpoint to later live Student work; integrated fixture tests are serialized within their file to avoid deterministic-fixture races;
• implementation spans 0ce4b8d... through 8530128..., with browser isolation/stabilization through 04587bf...;
• repository quality baseline: 302 tests / 301 pass / 0 fail / 1 intentional skip.

Completed Tranche 9 — integrated staged security / late-join / reassignment acceptance

• late join after exercise Start receives the represented current stage/release, not draft/future/Instructor material;
• active-stage reassignment preserves class exercise stage while destination workspace Intake/readiness becomes authoritative and stale source authority is rejected;
• readiness remains workspace-scoped across reassignment;
• frozen Student collaboration PUT is browser-proven HTTP 423 classroom-editing-locked with zero snapshot/revision mutation;
• Student staged/full-payload routes are browser-proven to withhold future-stage, Instructor-only, exemplar/model, and complete staged Case Study material;
• mobile Student case-reference and mobile Instructor staged-console states pass serious/critical axe scans;
• final staged acceptance implementation head 89a5321a750606cff6fbf34ccf75ef40dc3def07: repository quality 302 tests / 301 pass / 0 fail / 1 intentional skip; Browser E2E 28 passed / 10 intentional skips / 0 failed / 0 flaky; all required gates green.

Completed Tranche 10 — final documentation/security/merge-readiness audit

• audited the complete Classroom follow-on: Instructor-orchestrated case simulation and staged debrief #313 branch from merged Classroom follow-on: Instructor-run live class, roster, and dynamic team management #312 base through Tranche 9: 198 commits / 46 changed files before documentation-only reconciliation;
• corrected stale README, Classroom API, and roadmap descriptions to the implemented end state;
• re-audited Instructor/Student capability separation, non-enumeration, progressive disclosure, full-payload bypass closure, optimistic lifecycle revisions, immutable checkpoints, server-enforced freeze, reassignment stale-authority cutoff, schema retention/cascade behavior, capability non-persistence, and Standalone compatibility;
• verified public/static boundaries: Standard-only public manifest, server-only protected manifest, authored templates/*.json excluded from Vercel source upload, generated dist/ as public output;
• confirmed no production official Case Study contains an authored staged simulation; synthetic staged content remains test-only;
• PR has no unresolved review threads or review objections and is mergeable.

Final audited head: 8974519108d6735383b8358373d005188501a785

Final validation:

• repository quality: 302 tests / 301 pass / 0 fail / 1 intentional skip;
• required Browser E2E: 28 passed / 10 intentional project-scoped skips / 0 failed;
• CI: green;
• CodeQL: green;
• Dependency Review: green;
• Template Manifest Guard: green.

Status: ready for review. Do not merge automatically. Production official-case staging remains deferred until authoritative instructional material is supplied and reviewed.

Post-merge roadmap

The staged-simulation engine is complete, but production-Classroom work continues as separate follow-ons:

• Classroom follow-on: Protected staged case assets and rich Student case rendering #316 — P0: protected staged assets + rich Student rendering. This is the immediate blocker because the schema accepts image/table/document-page content while the current Student renderer reduces released content to title/body.
• Classroom follow-on: Author and validate the first production staged KT Case Study #317 — author and validate the first source-faithful production staged KT Case Study after Classroom follow-on: Protected staged case assets and rich Student case rendering #316.
• Classroom follow-on: Universal Intake target identity and staged guidance/coaching #318 — wire stage intakeTargetIds to stable Intake targets and close the deferred dynamic Possible Cause coaching-identity gap.
• Classroom follow-on: Instructor class debrief comparison and progress view #319 — Instructor cross-team debrief comparison/progress view using checkpoint/live evidence.
• Classroom UX follow-on: Join sharing and compact mobile workspace chrome #320 — lower-priority QR/share join convenience and compact mobile Notes/Class/Case chrome.

Recommended order: merge #315 → #316 → #317, with #318/#319 as facilitation-completeness work and #320 able to proceed in parallel.

No official production Case Study staging should be added as a shortcut before #316 and authoritative source review.