Shorten runbook descriptions to a brief summary

README.md

@@ -28,21 +28,13 @@ Terminus-2, runbook kept private). Browse them side by side in the **[interactiv
 | [openfoam_scalar_transport_boundary_probe__02](https://intelligencelab-rsr-27b-trajectories.static.hf.space/openfoam_scalar_transport_boundary_probe__02.html) | Physical science & simulation (OpenFOAM) | 56 → 23 | 1.9 h → 28 min | 4 of 4 |
 
 <details>
-<summary><b>tree_sitter_markdown_inline__05</b>: runbook and step lists</summary>
+<summary><b>tree_sitter_markdown_inline__05</b>: overview and step lists</summary>
 
 [Open this task side by side](https://intelligencelab-rsr-27b-trajectories.static.hf.space/tree_sitter_markdown_inline__05.html)
 
 Data, query & formal (tree-sitter). The expert never marked the task complete: it kept working until the 2-hour limit ended the run, and the work it left in place passed. Runbook: `runbook_01`, checked by the leak judge; 4 of 4 replays passed, in 13, 15, 15, 34 steps, and the one shown took 34.
 
-**Runbook summary.** Create an editable project in /app/workspace and a /app/workspace/reconstruct.py that reads a scenario JSON from stdin and prints a JSON summary matching the oracle reference_summary for the tree_sitter_markdown_inline demo. The reference_summary is a fingerprint of three output files (generate.log, parse.txt, parse_metrics.json) produced by a tree-sitter markdown parse of a fixed input.
-
-**Runbook milestones**
-
-1. Understand the reference output structure and signature computation
-2. Understand the parameter-to-input mapping and the reference_summary computation rules
-3. Write reconstruct.py that produces the correct output for public scenarios
-4. Create project.json and ensure the workspace is a complete editable project
-5. Ensure robustness for hidden scenarios centered on 'table'
+**Runbook, in brief.** A short plan for rebuilding the tree-sitter Markdown demo: learn what the reference outputs look like, write a script that reproduces them, and check that it generalizes beyond the public examples.
 
 **Expert** — Base Qwen3.8-27B · continue-until-timeout: 64 steps, 153 commands
 
@@ -77,22 +69,13 @@ Data, query & formal (tree-sitter). The expert never marked the task complete: i
 </details>
 
 <details>
-<summary><b>cmake_generated_header_config__06</b>: runbook and step lists</summary>
+<summary><b>cmake_generated_header_config__06</b>: overview and step lists</summary>
 
 [Open this task side by side](https://intelligencelab-rsr-27b-trajectories.static.hf.space/cmake_generated_header_config__06.html)
 
 Systems & infrastructure (CMake). The expert never marked the task complete: it kept working until the 2-hour limit ended the run, and the work it left in place passed. Runbook: `runbook_02`, checked by the leak judge; 4 of 4 replays passed, in 24, 27, 27, 29 steps, and the one shown took 27.
 
-**Runbook summary.** Create /app/workspace/reconstruct.py that reads a scenario JSON from stdin (with parameters build_type, configured_version, consumer_project) and prints JSON to stdout matching the oracle output shape. The output is a summary of a CMake build with parameter-dependent values embedded in CMakeCache.txt (SILR_PARAM_* entries, CMAKE_BUILD_TYPE) and CMakeConfigureLog.yaml (random build IDs, number counts). The solution must work for hidden scenarios, not just the two public ones.
-
-**Runbook milestones**
-
-1. Understand the oracle output structure and how parameters affect it
-2. Understand the exact number extraction pattern for CMakeCache.txt
-3. Understand the CMakeConfigureLog.yaml differences (number_count and cmtc_XXXXX IDs)
-4. Build reconstruct.py that handles both public and hidden scenarios
-5. Write reconstruct.py with the correct mechanism
-6. Ensure hidden scenarios work correctly
+**Runbook, in brief.** A short plan for reproducing the CMake configuration demo: work out which outputs change with the scenario parameters, write a script that reproduces them, and check that it generalizes beyond the public examples.
 
 **Expert** — Base Qwen3.8-27B · continue-until-timeout: 59 steps, 94 commands
 
@@ -127,21 +110,13 @@ Systems & infrastructure (CMake). The expert never marked the task complete: it
 </details>
 
 <details>
-<summary><b>openfoam_scalar_transport_boundary_probe__02</b>: runbook and step lists</summary>
+<summary><b>openfoam_scalar_transport_boundary_probe__02</b>: overview and step lists</summary>
 
 [Open this task side by side](https://intelligencelab-rsr-27b-trajectories.static.hf.space/openfoam_scalar_transport_boundary_probe__02.html)
 
 Physical science & simulation (OpenFOAM). The expert never marked the task complete: it kept working until the 2-hour limit ended the run, and the work it left in place passed. Runbook: `runbook_01`, checked by the leak judge; 4 of 4 replays passed, in 23, 23, 33, 51 steps, and the one shown took 23.
 
-**Runbook summary.** Reconstruct a parametric OpenFOAM scalar-transport boundary probe. Build /app/workspace/reconstruct.py that reads a scenario JSON from stdin and prints a JSON object matching the oracle output structure (containing 'summary' and 'parameter_effect'). The output must generalize to hidden parameter combinations (inlet_scalar, mesh, velocity, steps, probe_location), not just the two public cases.
-
-**Runbook milestones**
-
-1. Understand the reference output structure and identify parameter-dependent fields
-2. Determine the parameter_effect digest formula
-3. Determine the formulas for parameter-dependent values in blockMesh.log
-4. Build reconstruct.py that generalizes to any parameter combination
-5. Validate against public feedback
+**Runbook, in brief.** A short plan for reproducing the OpenFOAM boundary-probe demo: work out which results depend on the scenario parameters, write a script that reproduces them, and check that it generalizes beyond the public examples.
 
 **Expert** — Base Qwen3.8-27B · continue-until-timeout: 56 steps, 72 commands