ced4568andClaude Sonnet 5
de6c5b3286
root-12-real-ops gains a Detect -> Triage -> Diagnose -> Mitigate ->
Recover -> Verify -> Learn incident-response framing lesson at the
front of the existing 4-incident module, and a post-incident reflection
at the end — the incidents themselves are unchanged, still deliberately
un-guided ('you are responsible for this environment,' not 'complete
this exercise'). No fixes revealed; instructor notes carry the deeper
solution guidance the student-facing lesson intentionally withholds.
root-capstone-m02-capstone-readiness — a new READY orientation module:
what the Capstone measures, how the timed/randomized draw works, time
management and troubleshooting strategy under a clock, and a genuine
self-assessment checklist. Never publishes the current draw or answers.
See docs/ROOT_CAPSTONE_READINESS.md for why this module's completion is
deliberately independent of the real capstone's server-side unlock gate.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.6 KiB
Post-Incident Reflection: What Real Ops Actually Feels Like
You just worked through four incidents that "own it, don't just complete it" framing described. Take a few minutes to reflect on the module as a whole, not just any single incident.
Reflection questions
- Which of the four incidents took the longest to even understand what was actually wrong, before you got to fixing anything? What made diagnosis slower there than the others?
rootnode-runaway-monitorandrootnode-enforce-limitsare the same underlying incident, split into "fix it now" and "prevent it forever." Which one did you find more satisfying to solve, and why do you think real teams sometimes skip the second one under time pressure?- If you were handing these four incidents off to a teammate mid-shift, what's the one-sentence summary you'd give for each, so they could pick up without re-diagnosing from scratch?
- Compare how this module felt to the earlier, more guided modules in ROOT_. What specifically was different about the experience, not just the difficulty?
Real Ops takeaway
"It's fixed" and "it won't happen again" are two different jobs, and skipping the second one
is how the same incident recurs. rootnode-enforce-limits exists as its own scenario
specifically to make this point structurally, not just rhetorically — the immediate fix and the
prevention work are genuinely separate efforts, and a real team's incident isn't actually closed
until both are done.
Being handed an unfamiliar, under-specified problem is the actual job. Every other module in ROOT_ told you roughly what concept you were about to practice. This one didn't — and that gap is deliberate, because real production incidents don't come with a syllabus telling you which concept they're testing. The framework from this module's opening lesson is what you reach for instead of a hint system.
This module is complete. If a Capstone is part of your program, its readiness module is next.
Instructor Notes
Discussion questions for a live classroom: question 2 is the module's core point — spend real time on it rather than treating it as a quick check-the-box question.
Approximate timing: 10-12 minutes live discussion; 8 minutes self-paced writing.
Optional extension: ask students to identify which incident from this module most closely resembles something they'd expect to encounter in an actual job, and why — grounds the module in something beyond the classroom.
Expected takeaway: Real operational work is less about knowing every possible failure mode in advance and more about having a repeatable process for approaching the ones you've never seen before.