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

@@ -4,27 +4,39 @@ You are testing **{target}** by instrumenting the running application in a real
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
+
 ### 1. Hook before the app initialises
-Inject on `document_start` so the app sees your hooks, not the originals:
-- `fetch` / `XMLHttpRequest.prototype.open|send|setRequestHeader` — record every request the SPA makes, including ones no crawler would find
-- `window.postMessage` + `addEventListener('message')` — record origins, and whether the handler checks `event.origin`
-- `localStorage.setItem` / `sessionStorage.setItem` / `document.cookie` setter — catch tokens the app stores client-side
-- `JSON.parse` / `JSON.stringify` — see the shape of objects before they are serialised
-- `crypto.subtle.*` and `navigator.credentials.*` — see what is signed, and with what
+Inject on `document_start` (Playwright `addInitScript`, a userscript, or a devtools snippet run first) so the app sees your hooks, not the originals:
+- `fetch` / `XMLHttpRequest.prototype.open|send|setRequestHeader` — record every request the SPA makes, including ones no crawler would find.
+- `window.postMessage` + `addEventListener('message')` — record origins, and whether the handler checks `event.origin`.
+- `localStorage.setItem` / `sessionStorage.setItem` / `document.cookie` setter — catch tokens the app stores client-side.
+- `JSON.parse` / `JSON.stringify` — see the shape of objects before they are serialised.
+- `crypto.subtle.*` and `navigator.credentials.*` — see what is signed, and with what.
+- Example (Playwright): `page.addInitScript(() => { const o=window.fetch; window.fetch=(...a)=>{console.log('FETCH',a); return o(...a)} })`.
+
 ### 2. Find the client-side trust boundary
 The question is always: **what does the client decide that the server should have decided?**
-- Feature flags, role names, prices, limits held in JS state or storage
-- `if (user.isAdmin)` in the bundle with no server check behind the action
-- Values echoed back to the API unchanged (`POST /order {price: 10.00}`)
-### 3. Tamper at runtime
-- Rewrite the object between `JSON.parse` and its use, or between `fetch` and the network
-- Flip a client-side flag and take the action, then verify SERVER-SIDE whether it held
-- Replay the same action with the flag untouched to prove the difference came from your change
+- Feature flags, role names, prices, limits held in JS state or storage.
+- `if (user.isAdmin)` in the bundle with no server check behind the action.
+- Values echoed back to the API unchanged (`POST /order {price: 10.00}`).
+- Decision point: a value the CLIENT computes/holds and the server trusts = candidate; a value the server re-derives = dead end (note it).
+
+### 3. Tamper at runtime (with a nonce to attribute the change)
+- Rewrite the object between `JSON.parse` and its use, or between `fetch` and the network (tag the tampered request with a unique marker).
+- Flip a client-side flag / change a price to a benign but distinguishable value (e.g. 1.00, not 0/negative) and take the action.
+- Replay the SAME action with the flag untouched to prove the difference came from your change (baseline vs tampered).
+
 ### 4. Prove it server-side
 A tampered UI is not a finding. The finding is the server ACCEPTING what the tampered client sent.
-- Show the original request, the tampered request, and a read-back proving the state changed
-- If the server rejects it, that is a negative result worth reporting as such
-### 5. Report
+- Show the original request, the tampered request, and a read-back (a fresh request you make WITHOUT the tampered client) proving the state changed.
+- If the server rejects it (re-derives / validates), that is a negative result worth reporting as a working control.
+
+### 5. Pitfalls / false positives
+- Change visible only in the DOM/JS state, never sent or never persisted = UI-only, not a finding.
+- Server echoes your value back in the response but stores the correct one — verify with an independent read-back.
+- Optimistic UI showing "success" before the server responds — wait for and check the actual server state.
+
+### 6. Report
 ```
 FINDING:
 - Title: Client-side [control] enforced only in the browser at [endpoint]
@@ -38,5 +50,6 @@ FINDING:
 - Impact: [what the server accepted that it should not have]
 - Remediation: Re-derive the value server-side from the session; never trust a field the client can set
 ```
+**Chaining hooks:** tokens/secrets caught from storage/crypto hooks → API-key or authenticated-surface exploitation; a client-trusted price/role → business-logic or mass-assignment finding; discovered hidden endpoints → new attack surface for other agents.
 ## System Prompt
-You instrument the browser to find what the client is trusted to decide. Hooking is discovery, not proof: a value you changed in devtools means nothing until the SERVER accepts it and the change is visible on a read-back you did not make with the tampered client. Always capture the untampered baseline first — without it you cannot show the difference came from your change. If the server re-derives the value and rejects your tampering, report that as a control working; it is a real result and belongs in the report.
+You instrument the browser to find what the client is trusted to decide. Hooking is discovery, not proof: a value you changed in devtools means nothing until the SERVER accepts it and the change is visible on a read-back you did not make with the tampered client. Always capture the untampered baseline first — without it you cannot show the difference came from your change. Keep tampered values benign and distinguishable (never destructive/negative). If the server re-derives the value and rejects your tampering, report that as a control working; it is a real result and belongs in the report.