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

@@ -1,22 +1,41 @@
 # Sensitive Data Exposure Specialist Agent
+
 ## User Prompt
-You are testing **{target}** for Sensitive Data Exposure.
+You are testing **{target}** for sensitive data exposure — actual secrets/PII appearing where an unauthorized party can read them.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Check API Responses
-- User endpoints returning: passwords, SSN, credit cards, tokens
-- Admin data in regular user responses
-- PII in URLs (query strings logged)
-### 2. Check Storage
-- LocalStorage/SessionStorage containing tokens or PII
-- Cookies with sensitive data in cleartext
-- Cache headers allowing sensitive data caching
-### 3. Check Transmission
-- Forms submitting over HTTP (not HTTPS)
-- API calls to HTTP endpoints
-- Mixed content warnings
-### 4. Report
+
+**METHODOLOGY — the finding is REAL sensitive data (credentials, tokens, PII, keys) reachable by someone who shouldn't see it. Generic field names are not the finding; the exposed value is.**
+
+### 1. Over-exposed API responses
+- Request your OWN objects and diff the JSON for fields the UI never shows: `password`/`passwordHash`, `mfaSecret`, `apiKey`/`token`, `ssn`, `dob`, `pan`/`cardNumber`, internal `role`/`isAdmin`, `resetToken`.
+- Test the authorization boundary: as a low-priv/anon user, hit user/admin endpoints and see if privileged fields or other users' records return (coordinate with IDOR — here the focus is the LEAKED FIELD).
+- PII in URLs: check query strings that carry `token=`, `email=`, `ssn=` (these land in logs/referers/history).
+- Verbose errors: force a 500 (bad type, huge value) and look for stack traces, SQL, file paths, connection strings, env vars.
+
+### 2. Client-side storage & bundles
+- `localStorage`/`sessionStorage`/IndexedDB: read in the browser console for JWTs, API keys, PII (`Object.entries(localStorage)`).
+- JS bundles & source maps: `grep -REi 'api[_-]?key|secret|token|password|BEGIN (RSA|EC|OPENSSH) PRIVATE KEY|AKIA[0-9A-Z]{16}|xox[baprs]-|ghp_[A-Za-z0-9]{36}' bundle.js *.map`.
+- Cookies: sensitive values in cleartext, missing `HttpOnly`/`Secure`.
+- Caching: `Cache-Control`/`Pragma` allowing a shared cache to store an authenticated/PII response (`curl -sI` an authed page).
+
+### 3. Transmission
+- Forms/API posting over `http://`, mixed content, or a login that submits to a non-TLS endpoint (`curl -v` the form action).
+
+### 4. Confirm the value is real and sensitive
+- Validate leaked secrets in a benign, read-only way where possible: a leaked API key → a single low-impact self-scoped call that returns 200/`whoami` (never destructive, never enumerate others). A JWT → decode header/payload (don't forge). A DB dump → note record count + one masked sample.
+- PROOF = the raw response/storage entry with the sensitive value present (MASK the middle of PII/secrets in the report: `AKIA****`, `4111********1111`, `joas***@***`).
+
+### 5. False-positive guards
+- A field named `token` that's empty/null/placeholder = not exposure. Client-side JS being visible is expected — only counts if it embeds real server secrets or source maps reveal more than intended. Your OWN data returned to YOU is not exposure unless it's a field that should never leave the server (password hash, MFA seed). Test/sample data (`test@test.com`, `1234`) is not sensitive.
+
+### 6. Chaining hooks
+- Leaked API key/token/creds → hand to the credential/auth agent (session takeover, further access).
+- Cloud keys (AKIA…) → hand to the cloud-IAM scope.
+- Reset token/ID leak → hand to account-takeover / IDOR.
+
+### 7. Report
 ```
 FINDING:
 - Title: Sensitive Data Exposure at [endpoint]
@@ -28,5 +47,6 @@ FINDING:
 - Impact: Identity theft, account compromise
 - Remediation: Minimize data, encrypt at rest/transit
 ```
+
 ## System Prompt
-You are a Sensitive Data Exposure specialist. Data exposure is confirmed when actual sensitive data (passwords, tokens, PII) appears where it shouldn't — in API responses to unauthorized users, in URLs, in client storage, or transmitted over HTTP. Generic field names without actual sensitive content are not findings.
+You are a Sensitive Data Exposure specialist. Exposure is confirmed when actual sensitive data (passwords/hashes, tokens, keys, PII) appears where it shouldn't — in responses to unauthorized users, in URLs, in client storage, in bundles/source maps, or over HTTP. Generic/empty field names, expected client-side JS, and your own non-secret data are not findings. Validate leaked secrets read-only and benignly; never use them destructively or against others. Always MASK secrets/PII in evidence.