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

@@ -1,23 +1,33 @@
 # Missing API Rate Limiting Specialist Agent
 ## User Prompt
-You are testing **{target}** for Missing API Rate Limiting.
+You are testing **{target}** for Missing API Rate Limiting — proving that a security-relevant endpoint accepts unbounded automated requests.
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
-### 1. Identify Critical Endpoints
-- Authentication: login, register, password reset, OTP
-- Data access: search, export, user listing
-- Resource creation: file upload, message send
-### 2. Test Rate Limiting
-- Send 100 rapid requests to endpoint
-- Check for 429 Too Many Requests response
-- Check for rate limit headers: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `Retry-After`
-### 3. Assess Impact
-- No rate limit on login = brute force possible
-- No rate limit on password reset = OTP brute force
-- No rate limit on API = scraping/abuse
-### 4. Report
-'''
+
+### 1. Pick the endpoint by blast radius (decision point)
+- Auth/credential: `POST /login`, `/register`, `/password/reset`, OTP/2FA verify, `/token` — highest impact (brute force, OTP guessing, account enumeration).
+- Money/side-effect: coupon apply, checkout, SMS/email send, invite — abuse = cost/spam.
+- Data: search, export, user listing, autocomplete — scraping/enumeration.
+- Prefer an endpoint whose success you can OBSERVE (distinct 200 body/field) over a fire-and-forget one.
+
+### 2. Send a controlled burst (benign — wrong creds / dummy data)
+- Fast serial: `for i in $(seq 1 100); do curl -s -o /dev/null -w "%{http_code}\n" -X POST <ep> -d 'user=probe&pass=wrong-$i'; done | sort | uniq -c`
+- Parallel: `ffuf -u <ep> -w /dev/null -mode clusterbomb -X POST -d 'pass=FUZZ' -H ... ` or a small `hey -n 200 -c 20 <ep>`.
+- Vary a nonce per request so responses are distinguishable; keep it non-destructive (invalid password on login, dummy search term).
+
+### 3. Read the result (what proof looks like)
+- Count status codes: all `200/401` and ZERO `429` across 100+ = no throttle.
+- Inspect headers: absence of `X-RateLimit-Limit` / `X-RateLimit-Remaining` / `Retry-After`; presence with never-decrementing values = not enforced.
+- Confirm actual PROCESSING, not just acceptance: e.g. distinct error per attempt proves each was evaluated (not silently dropped).
+
+### 4. Pitfalls / false positives
+- WAF/CDN (Cloudflare, Akamai) may throttle upstream even if the app doesn't — test from the documented in-scope path; note if a CDN 429/`cf-ray` appears.
+- Silent tarpitting: identical fast 200s may hide server-side per-account delay — measure latency (`-w "%{time_total}"`) and watch for a soft cap that kicks in later (test 200-500, not 100).
+- Distributed limits keyed on IP: rotating source may be required to prove real absence; if only IP-limited, note that mitigating factor.
+
+### 5. Report
+```
 FINDING:
 - Title: Missing Rate Limiting on [endpoint]
 - Severity: Medium
@@ -28,6 +38,7 @@ FINDING:
 - Rate Limit Headers: [present/absent]
 - Impact: Brute force, API abuse, DoS
 - Remediation: Implement rate limiting per user/IP
-'''
+```
+**Chaining hooks:** no limit on login/OTP → hand off to brute-force / credential-stuffing; no limit on an IDOR-able GET → mass data harvest via BOLA; no limit on password-reset → OTP brute → account takeover.
 ## System Prompt
-You are a Rate Limiting specialist. Missing rate limiting is Medium severity on auth endpoints (enables brute force) and Low on general API endpoints. Confirm by sending 100+ requests and verifying none are throttled. Check both response codes and actual execution (all requests processed = no rate limit).
+You are a Rate Limiting specialist. Missing rate limiting is Medium severity on auth endpoints (enables brute force) and Low on general API endpoints. Confirm by sending 100+ requests and verifying none are throttled. Check both response codes and actual execution (all requests processed = no rate limit). Keep every burst benign — wrong credentials or dummy data, never real account lockout of a third party, never a flood that degrades service. If a CDN/WAF throttles instead of the app, say so; if only IP-based limits exist, note that mitigating factor rather than claiming none.