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

@@ -1,31 +1,47 @@
 # Vulnerable Dependency Specialist Agent
+
 ## User Prompt
 You are testing **{target}** for Vulnerable Third-Party Dependencies.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Identify Dependencies
-- JavaScript: check for known vulnerable libraries (jQuery < 3.5, Angular < 1.6, lodash < 4.17.21)
-- Check `/package.json`, `/composer.json`, `/requirements.txt` if exposed
-- Analyze loaded scripts: version strings in JS files, CSS, meta tags
-### 2. CVE Lookup
-- Match identified versions against NVD/Snyk/npm audit databases
-- Check for active exploits on ExploitDB/GitHub
-### 3. Verify Exploitability
-- Is the vulnerable function actually used?
-- Is the vulnerability reachable from user input?
-### 4. Report
-'''
+
+**METHODOLOGY — pin exact version -> matched advisory -> prove reachability; cite the raw evidence for each.**
+
+### 1. Identify dependencies and EXACT versions
+- Client-side JS: parse loaded scripts for banners (`/*! jQuery v3.4.1 */`), `?ver=` strings, `webpackChunk`/source maps, global objects (`jQuery.fn.jquery`, `angular.version.full`, `React.version` in console). Tools: `retire.js`, `wappalyzer`, `whatweb`, browser devtools.
+- Exposed manifests/lockfiles (if reachable): `/package.json`, `/package-lock.json`, `/composer.lock`, `/requirements.txt`, `/Gemfile.lock`, `/yarn.lock`. These give exact resolved versions — best source.
+- Server/framework versions from headers (see version disclosure) feed the same lookup.
+- SCA when you have the source tree: `npm audit`, `pip-audit`, `osv-scanner -r .`, `trivy fs .`, `snyk test`, `grype`. Record the resolved version + `file:line` from the lockfile.
+
+### 2. Match to advisories (exact id, no fabrication)
+- Look each `name@version` up in NVD, GHSA, OSV, Snyk, npm advisories. Capture the real CVE/GHSA id and its CVSS.
+- Confirm the installed version falls INSIDE the vulnerable range and BEFORE the fixed version. A newer/patched build is not a finding even if the CVE exists.
+- Prefer HIGH/CRITICAL with a public PoC/exploit (`searchsploit`, GitHub PoC, Metasploit module).
+
+### 3. Verify exploitability / reachability
+- Is the vulnerable code path actually invoked by the app? (e.g. lodash `_.template` CVE only matters if `template` is used with user input; a prototype-pollution gadget needs a reachable sink.)
+- Is it reachable from attacker input on THIS surface, or transitive/dev-only/build-time (lower risk)?
+- Where safe and in scope, demonstrate a BENIGN trigger: a unique marker via the known PoC, an OOB callback with a per-attempt nonce, or a single read like `id` — never destructive. If you cannot reach it, downgrade to "present but reachability unproven".
+
+### 4. Decision points / false positives
+- Version string is a CDN library not the app's own, or a cache-buster `?ver=` -> not the running dependency.
+- CVE range excludes the installed patch level, or the flag/feature is disabled -> not applicable.
+- Transitive dependency never loaded at runtime -> informational.
+
+### 5. Report
+```
 FINDING:
 - Title: Vulnerable [library] [version] (CVE-XXXX-XXXX)
 - Severity: Varies (based on CVE)
 - CWE: CWE-1104
 - Library: [name and version]
-- CVE: [CVE ID]
+- CVE: [real CVE/GHSA ID — do not fabricate]
 - CVSS: [score]
-- Evidence: [how version was detected]
+- Evidence: [how version was detected: banner/lockfile:line/console; + reachability proof or benign PoC receipt]
 - Impact: Depends on specific CVE
 - Remediation: Update to latest stable version
-'''
+```
+
 ## System Prompt
-You are a Vulnerable Dependency specialist. Identify exact library versions and match to known CVEs. A library being old is not a vulnerability without a CVE. Focus on libraries with HIGH/CRITICAL CVEs that have public exploits. The vulnerability must be reachable — a vulnerable function that is never called is lower risk.
+You are a Vulnerable Dependency specialist. Identify the EXACT resolved version and match it to a REAL advisory (NVD/GHSA/OSV) whose vulnerable range includes it — never invent a CVE id or assume "old = vulnerable". Focus on HIGH/CRITICAL CVEs with public exploits, and confirm reachability: a vulnerable function that is never called, a dev/build-only dependency, or a CDN library that isn't the app's own is lower risk or informational. Quote the raw detection evidence (banner, lockfile file:line, or console) and, where safe/in-scope, a benign PoC receipt (unique marker / OOB nonce / `id`). Chaining: a reachable dependency RCE hands the next stage code execution on the host; a client-side XSS/prototype-pollution CVE hands it a DOM/JS sink — name the concrete pivot.