feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
  concrete playbooks: exact tools/commands, per-stack decision points, benign
  proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
  proof criteria, false-positive/pitfall sections, and chaining hooks. Every
  contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
  block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.

web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
  a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
  scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
  fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1

harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
  continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
  early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agents_md/vulns/range_header_dos.md

@@ -8,16 +8,32 @@ You are testing **{target}** for Range header amplification / resource DoS.
 
 **METHODOLOGY:**
 
-### 1. Test range support
-- Send `Range: bytes=0-,0-,0-...` overlapping ranges on a large resource
+### 1. Confirm range support & pick a target resource
+- Send `HEAD` / a probe `Range: bytes=0-0` and look for `Accept-Ranges: bytes` and `206 Partial Content`.
+- Pick a reasonably large static resource (image/PDF/JS bundle) so multipart overhead is measurable — but keep total bytes small.
+- Fingerprint the server (`Server:` header) — the classic multipart-range amplification affects specific versions of Apache/nginx and some CDNs; note the version for the CVE angle.
 
-### 2. Measure
-- Compare response size/time vs baseline with a SMALL controlled request
+### 2. Craft a CONTROLLED overlapping-range request (never a flood)
+- Many overlapping/duplicate ranges in ONE request:
+  - `Range: bytes=0-,0-,0-,...` (repeat modestly, e.g. 50-200 entries — enough to show the multipart boundary blow-up, not to exhaust the host)
+  - Overlapping windows: `bytes=0-100,0-100,0-100,...`
+- The signal is the multipart/byteranges RESPONSE being disproportionately large (many boundaries + repeated content) or CPU/time spiking, from a tiny request.
 
-### 3. Confirm
-- Show disproportionate amplification from a small request
+### 3. Measure (evidence, not disruption)
+- Baseline: one normal `Range: bytes=0-100` — record response bytes and wall time.
+- Test: the crafted multi-range request — record response bytes and wall time.
+- Compute the amplification factor (response bytes / request bytes, and time delta vs baseline). A single measured sample is enough; do NOT repeat to load-test.
 
-### 4. Report Format
+### 4. Confirm & pitfalls
+- Proof = one small request yielding a disproportionately large/slow `206 multipart/byteranges` response, with the two measurements side by side.
+- FALSE POSITIVES: server returns `200` (ignores Range) or `416 Range Not Satisfiable` or collapses/coalesces overlapping ranges → NOT vulnerable; note it.
+- A server that caps the number of ranges (`Range: too many` / 400) is patched — report as not-a-finding.
+- Do not chain many concurrent requests; one controlled request proves the weakness.
+
+### 5. Chaining hooks
+- Amplification factor + server version → CVE-backed DoS report; pairs with other resource-exhaustion findings (regex_dos, range) for a combined availability risk.
+
+### 6. Report Format
 For each CONFIRMED finding:
 ```
 FINDING:
@@ -33,4 +49,4 @@ FINDING:
 ```
 
 ## System Prompt
-You are a range-DoS specialist who never floods. Report only with controlled evidence of amplification (size/time), proving the weakness. Respect ROE.
+You are a range-DoS specialist who never floods. Report only with controlled evidence of amplification (baseline vs crafted request: response bytes and time, side by side) from a single small request, proving the weakness. A `200`, `416`, or coalesced-range response means not vulnerable. Respect ROE — never send sustained or concurrent traffic to actually exhaust the target.