docs(phase6b): document curriculum expansion

PHASE6B_ROOT_CURRICULUM_EXPANSION.md — the phase summary: what was
authored per course, the is_required extension, the capstone unlock
fix, verified scenario coverage before/after (44 -> 88 of 98, 89.8%,
by direct query not estimate), and honest known limitations/Phase 6C
recommendations.

ROOT_CAPSTONE_READINESS.md — the readiness module and the server-side
unlock fix in full detail, including why the module's completion and
the real assessment's unlock gate are deliberately independent systems.

Updated ROOT_CURRICULUM_INVENTORY.md (Phase 6B coverage numbers),
ROOT_PROGRAM_ARCHITECTURE.md (ROOT 08/09 PARTIAL, new module lists per
course), COURSE_CONTENT_MODEL.md (is_required completion rule, a new
content-versioning section per this phase's own requirement),
COURSE_AUTHORING_STANDARD.md (classifying near-duplicate/advanced
scenarios), ENGINEERING_SOP.md (new Phase 6B section),
REMOTE_AND_SELF_PACED_ARCHITECTURE.md (cross-reference), and
platform/README.md (e2e-phase6b.js, the Phase 6B rehearsal, isolation-
per-suite regression guidance).

Co-Authored-By: Claude Sonnet 5 <[email protected]>

docs/COURSE_CONTENT_MODEL.md

@@ -84,6 +84,16 @@ decided, and it never invents new state for anything that's independently verifi
 Course and module completion are pure aggregates over their activities' completion (`total`/
 `completed`/`pct`/`complete` — see `totals()`), never separately stored.
 
+### Optional vs. required activities (Phase 6B)
+
+`module_activities.is_required` (defaults `true`) lets a module distinguish CORE teaching from
+GUIDED/INDEPENDENT-practice duplicates and ADVANCED/optional extras — see
+`docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`'s classification scheme, used throughout ROOT 09. A
+module's `complete` flag is true once every REQUIRED activity is done; an incomplete optional
+activity never blocks it, though `total`/`pct` still count every activity, required or not.
+Every Phase 6A activity has `is_required = true` (the column's default) — this is purely
+additive, nothing that was complete before Phase 6B becomes incomplete now.
+
 ## 5. Prerequisite/locking rule
 
 A course or module lists `prerequisites` (an array of other course/module ids). It's locked if
@@ -109,6 +119,40 @@ stop, regardless of its `status`. Use `draft` for genuinely unfinished authoring
 want a student to see at all yet; use `status = planned` for an honest "not built yet" that's
 fine to be visible.
 
+## 6b. Content versioning (Phase 6B §21)
+
+Follows the exact same convention `assessment_definitions`/`programs` already established — a
+plain incrementing `version` integer, bumped by hand, informational rather than enforced:
+
+- **A typo-only edit** (fixing a spelling mistake, a broken link, rewording a sentence without
+  changing its meaning) does NOT require a version bump — nothing about what a student is being
+  taught or held to changed.
+- **A semantic edit** (changing a learning objective, swapping a lab's `scenario_id`, changing
+  `completion_behavior`, adding/removing/reordering activities in a way that changes what
+  "complete" means) SHOULD bump `version` on the affected row(s) — see
+  `023_phase6b_curriculum.sql`'s own `version = version + 1` on every row it semantically
+  changes (resequencing, prerequisite changes, `is_required` changes).
+- **What happens to existing completions**: nothing, automatically. Unlike an assessment
+  session (which snapshots the definition version it was drawn against, because a session is a
+  point-in-time timed attempt), a course/module/activity's completion is derived LIVE every time
+  it's read (`course-progress.js`) from the CURRENT row plus the student's progress/achievements/
+  activity_completions — there is no snapshot to invalidate. A `manual_marker` completion
+  (`activity_completions`) is keyed by `activity_id`, which is stable across a version bump
+  (the id doesn't change, only its content/metadata does) — so a student's prior "I did this"
+  record stays valid even after a semantic edit, exactly like editing a scenario's own
+  Markdown description doesn't retroactively un-complete it in `progress`.
+- **Scenario references across versions**: a `lab` activity's `scenario_id` is just a string
+  reference into `scenarios/data/*.json` — if that scenario file itself changes, the activity
+  automatically reflects the new content next time it's loaded (same as every other consumer of
+  `curriculum.js`'s cache). If an activity's `scenario_id` itself is changed to point at a
+  DIFFERENT scenario, that's a semantic edit (bump the version) and — depending on intent — may
+  warrant a new `activity_id` instead of mutating the existing one, so a student's prior
+  completion of the OLD scenario isn't silently reinterpreted as completion of the new one.
+- **What this deliberately does NOT build**: no content-revision history table, no diffing, no
+  "students who saw v1 vs v2" cohort tracking. If a future phase needs that level of rigor
+  (e.g. for compliance/audit reasons), it's a real, separate feature — not something to bolt
+  onto a plain integer column.
+
 ## 7. Why this doesn't touch Phase 1-5 systems
 
 No column was added to `scenarios/*.json`, `assessment_definitions`, `achievements`,