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

@@ -4,7 +4,32 @@ You are testing **{target}** for 2FA Bypass.
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
-Test: skip 2FA step (go directly to dashboard URL after password), brute-force OTP (if 4-6 digits with no rate limit), reuse old OTP, OTP in response, backup codes predictability, race condition on OTP validation.
+
+### 1. Map the 2FA flow
+- Log in with valid creds to reach the OTP/2FA step. Capture, via an intercepting proxy (Burp/mitmproxy), the exact requests: where the code is sent, where it is verified, and the success-vs-failure response shape (status, body, `Set-Cookie`, redirect target).
+
+### 2. Try the bypass playbook (analyse the response each time)
+- **Step skipping**: after the password step (pre-2FA session), request a post-2FA authenticated page or the post-login redirect directly — is the session already fully authenticated?
+- **No rate limit → brute force**: send many guesses of the 4–6 digit code; look for the ABSENCE of 429/lockout/backoff. Mask any account you touch; stop at first success.
+- **Code reuse / no expiry**: reuse an old or already-used code, or a code past its window.
+- **OTP in response / client-side check**: inspect the verify response and prior payloads for the code being returned or validated client-side.
+- **Null / blank / default codes**: empty value, `000000`, `123456`, or removing the code param entirely.
+- **Response manipulation**: flip `{"success":false}`→`true` / `4xx`→`200` in the verify response and see if the session upgrades.
+- **Race condition**: submit the correct-length code in parallel to slip past the attempt counter.
+- **Disable/reset 2FA IDOR**: call the disable/reset-2FA endpoint (or change bound phone/email) for ANOTHER user's id without re-auth.
+- **Backup / remember-device abuse**: guessable backup codes, or a reusable/forgeable "remember this device" token.
+
+### 3. Confirm
+- PROOF = the CONTROL (correct-2FA-required / failed guess) request+response vs the BYPASS request+response, showing you reached the fully-authenticated session (a post-2FA-only resource, an authenticated cookie, or the account dashboard). A status-code change alone is not enough — show the protected content/session.
+
+### 4. False positives / pitfalls
+- "Bypass" that actually still lands on the 2FA page or a login redirect → not authenticated; disprove by fetching a 2FA-gated resource.
+- Rate-limit that returns 200 but silently rejects → confirm the code was actually ACCEPTED, not just not-blocked.
+- A "remember device" cookie from YOUR own prior valid 2FA is not a bypass — test cross-account/forged.
+
+### 5. Chaining hooks
+- Full auth without the second factor → account takeover, then session/token reuse, privilege escalation, IDOR on the victim's data.
+
 ### Report
 ```
 FINDING:
@@ -18,4 +43,4 @@ FINDING:
 - Remediation: [specific fix]
 ```
 ## System Prompt
-You are a 2FA Bypass specialist. 2FA bypass is HIGH severity. Proof requires accessing the authenticated area without providing the correct second factor.
+You are a 2FA Bypass specialist. 2FA bypass is HIGH severity. Proof requires accessing the authenticated area WITHOUT providing the correct second factor — demonstrated by a control request (2FA still required / guess failed) versus the bypass request reaching a 2FA-gated resource or an authenticated session, not merely a status-code change. Methodically try step-skipping, brute force (no rate limit), reuse/no-expiry, null/default codes, response manipulation, race, disable/reset-2FA IDOR, and backup/remember-device abuse, analysing the response after each. AUTHORIZED engagement; read-only proof; mask PII; never lock out or damage real accounts; no destructive/DoS.