docs(phase6c): pilot readiness standard, pilot curriculum manifest, ROOT 11 scope

Adds the four required Phase 6C documents:

- ROOT_PILOT_READINESS_STANDARD.md — the explicit 8-point sufficiency bar
  used to judge every module this phase, replacing any fixed activity-count
  assumption.
- ROOT11_DEVOPS_PLATFORM_SCOPE.md — evaluates all 7 proposed ROOT 11 modules
  individually (READY TO AUTHOR NOW / PARTIAL-LESSON-ONLY / REQUIRES FUTURE
  LAB ENVIRONMENT), with what current infra supports vs. what GitOps/CI-CD/
  IaC/observability would each require.
- ROOT_PILOT_CURRICULUM.md — the authoritative pilot manifest: instructor-led
  as the first pilot's delivery mode, honest READY/PARTIAL/DEFERRED/NOT IN
  PILOT status per course and module, and what is intentionally excluded
  (ROOT 01-04 never authored, ROOT 08 non-capstone-gating and deferred, ROOT
  11 modules 2-7, three practice-bank modules instructor-led-only this pilot).
- PHASE6C_CURRICULUM_COMPLETION.md — the phase's own record of what was
  upgraded, why, the bug found and fixed, and the pilot readiness conclusion.

Updates ROOT_CURRICULUM_COVERAGE_MATRIX.md with the verified before/after
module counts (21->22 modules, 6->16 READY) and per-module upgrade rationale,
and ROOT_CAPSTONE_READINESS.md with a re-review confirming the unlock gate's
6 stages, and ROOT 08/09's non-gating status, are unchanged by this phase's
curriculum expansion.

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

docs/ROOT_PILOT_READINESS_STANDARD.md

@@ -0,0 +1,83 @@
+# ROOT_ Pilot Readiness Standard
+
+Phase 6C §2 — the explicit bar a module must clear to be called READY for the first paid ROOT_
+pilot. Extends `docs/COURSE_AUTHORING_STANDARD.md` with a pass/fail checklist rather than
+general authoring guidance, and replaces ad hoc judgment calls with a documented rule every
+module in `docs/ROOT_PILOT_CURRICULUM.md` is checked against.
+
+## The standard is about sufficiency, not a fixed activity count
+
+Phase 6A/6B's gold-standard pattern (lesson → demonstration → knowledge check → guided exercise
+→ lab → reflection) is a strong DEFAULT for an operational skill module, not a mechanical
+checklist to force onto every module regardless of subject. The actual test is:
+
+> **Does the learner have enough instruction and scaffolding to reasonably perform the practical
+> work, understand why it matters, and check their own understanding — without an instructor
+> filling a gap the content itself should have closed?**
+
+A module can be READY with fewer activities if the subject genuinely doesn't need all six. A
+module can have all six activities and still not be READY if any of them fails its own bar
+below (a "lab" with no framing, a "knowledge check" that only tests recall of the immediately
+preceding paragraph).
+
+## The READY checklist
+
+A module is READY only if ALL of the following are true:
+
+1. **Concept instruction exists and is substantive.** A `lesson` (or equivalent) activity
+   explains the underlying mental model — what problem this solves, how it actually works, what
+   goes wrong when it's misunderstood — not a restated scenario description or a bullet list of
+   commands with no explanation of why.
+2. **The learner sees the reasoning demonstrated, not just described**, wherever the subject
+   involves diagnosing or configuring something non-trivial. This can be a `demonstration`
+   activity, OR — for a purely conceptual/orientation module where there's nothing to
+   diagnose — folded into the lesson itself with a worked example. A module that skips this
+   entirely for an operational/troubleshooting subject is not READY.
+3. **The learner can check their own understanding** before attempting independent work — a
+   `knowledge_check` (or, for an orientation module with no lab, a reflection that serves the
+   same self-check purpose) that tests INTERPRETATION and REASONING (see
+   `docs/COURSE_AUTHORING_STANDARD.md` §9's examples), not trivia.
+4. **The learner is not dropped into a lab cold.** Where a `lab` activity exists, either a
+   `guided_exercise` bridges lesson to lab, OR the lesson/demonstration already gave the learner
+   everything they need to attempt the lab's specific task without guessing at the mechanism
+   being tested. A bare lab reference with a one-line "go do this" intro and no prior teaching
+   of the concept it tests is NOT READY, regardless of how good the lab's own hints are — Labs
+   are the laboratory, not the whole course (Phase 6A's own founding principle).
+5. **The module closes with operational context**, where the subject has real production
+   consequences — a `reflection` connecting what was practiced to why it matters beyond passing
+   validation (see `docs/COURSE_AUTHORING_STANDARD.md` §15's Real Ops takeaway examples). A
+   purely conceptual orientation module (e.g. Capstone Readiness) may satisfy this through its
+   own closing content rather than a separate reflection activity.
+6. **Instructor notes exist wherever a live class would benefit from them** — at minimum on the
+   lesson and any demonstration/guided-exercise activity: timing, a likely misconception, and
+   (for a demonstration) a demo plan. Not required on every activity type (a bare lab activity
+   with no `content_path` has nothing to attach notes to).
+7. **Self-paced sufficiency**: nothing in the module says or implies "your instructor will
+   explain this" for content available to self-paced students. If an activity is genuinely
+   instructor-only (rare in this content model — everything self-paced students can reach uses
+   the same file), it must be excluded from self-paced delivery structurally, not by a
+   disclaimer.
+8. **Every reference resolves** — `scenario_id` points at a real scenario file,
+   `assessment_definition_id` at a real definition, `content_path` at a real file that actually
+   loads (`infra/scripts/validate-course-content.js` proves this mechanically; a human read-
+   through confirms the CONTENT itself, not just that the file exists).
+
+## What does NOT make a module READY
+
+- Having a `lab` activity. A scenario reference is necessary, never sufficient.
+- Having headings that look like a lesson. Prose volume is not instruction quality.
+- Existing in the database with `status = 'ready'`. That field is the AUTHOR's claim — this
+  document is the actual bar it's checked against, and `docs/ROOT_PILOT_CURRICULUM.md` is where
+  every claim gets verified against this checklist by a human, not just by the field's value.
+- Passing `e2e-phase6c.js`'s structural checks alone. Automated tests prove the DATA MODEL is
+  correct (references resolve, completion derives correctly) — they cannot judge whether a
+  lesson's explanation is actually good. That judgment is made once, explicitly, per module,
+  and recorded in the pilot manifest.
+
+## DEFERRED / NOT IN PILOT is not a failure
+
+A module that doesn't meet this bar is not a defect to apologize for — it's an honest status.
+`docs/ROOT_PILOT_CURRICULUM.md` uses DEFERRED (real content exists, not yet pilot-quality) and
+NOT IN PILOT (deliberately excluded — e.g. ROOT 01-04, most of ROOT 11) as first-class,
+legitimate outcomes. Marking something READY that isn't is a worse outcome than an honestly
+smaller pilot.