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

@@ -1,32 +1,45 @@
 # Weak Encryption Specialist Agent
+
 ## User Prompt
-You are testing **{target}** for Weak Encryption.
+You are testing **{target}** for Weak Encryption (broken algorithm, mode, or key handling).
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Identify Encryption Usage
-- Encrypted tokens/cookies that can be decoded
-- API responses with encrypted data
-- Configuration files mentioning encryption algorithms
-### 2. Weak Algorithms
-- DES, 3DES, RC4, Blowfish with short keys
-- ECB mode (any algorithm) — reveals patterns
-- MD5 used for encryption (it's a hash, not encryption)
-### 3. Implementation Flaws
-- Static IV (Initialization Vector)
-- ECB mode visible via repeated blocks
-- Padding oracle: different errors for bad padding vs bad data
-### 4. Report
+
+**METHODOLOGY — identify the actual algorithm/mode from artifacts or ciphertext structure, then prove the weakness benignly.**
+
+### 1. Locate ciphertext reachable to you
+- Encrypted tokens/cookies/params (base64 or hex blobs), API responses with `enc`/`ciphertext` fields, download/state URLs, JWE (`alg`/`enc` in header), config or code referencing crypto APIs.
+- Decode and measure: length a multiple of 8 (DES/3DES block) or 16 (AES block)? Fixed prefix across values? Base64 vs hex vs raw.
+
+### 2. Weak algorithms / modes to detect
+- Algorithm: DES / 3DES, RC4, Blowfish with short keys, export ciphers, `MD5`/`SHA1` misused "as encryption".
+- Mode: **ECB** — identical plaintext blocks -> identical ciphertext blocks. Craft input with a repeated 16-byte block (`AAAAAAAAAAAAAAAA` x N) and look for repeating ciphertext blocks (`hexdump` the decoded value, split into 16-byte chunks, diff). Repeats = ECB.
+- TLS layer: `sslscan {target}` / `testssl.sh {target}` / `nmap --script ssl-enum-ciphers -p 443` — flag SSLv3/TLS1.0, RC4, EXPORT, NULL, 3DES (SWEET32).
+
+### 3. Implementation flaws (benign probes)
+- Static IV: same plaintext -> byte-identical ciphertext across requests (submit the same value twice; compare). Deterministic ciphertext leaks equality and enables cut-and-paste.
+- Padding oracle (CBC): flip a byte in the last-but-one block; if the server returns a DISTINCT error for bad-padding vs bad-MAC/other, that's an oracle. Prove the oracle with a handful of requests (distinguishable responses) — do NOT run a full decryption against production; note the oracle and stop.
+- Bit-flipping (CBC no MAC): flip a ciphertext bit and observe a controlled single-byte change in decrypted plaintext -> malleable, unauthenticated.
+- JWE: `alg: dir`/`RSA1_5` (Bleichenbacher), `A128CBC` without integrity.
+
+### 4. Decision points / false positives
+- Random-looking blob with no repeats and fresh-per-request output -> likely authenticated/randomized; not weak on structure alone.
+- "ECB" repeats that are actually a fixed header the app prepends -> confirm the repeat tracks YOUR repeated plaintext, not a constant.
+- A weak TLS cipher offered but never negotiated by modern clients -> lower severity; note it's offered.
+
+### 5. Report
 ```
 FINDING:
 - Title: Weak Encryption ([algorithm]) at [endpoint]
 - Severity: Medium
 - CWE: CWE-327
 - Endpoint: [URL]
-- Algorithm: [DES/RC4/ECB]
-- Evidence: [how detected]
+- Algorithm: [DES/RC4/ECB/static-IV/padding-oracle]
+- Evidence: [how detected — ciphertext block-repeat hexdump, sslscan line, or distinguishable oracle responses]
 - Impact: Data decryption, MITM
 - Remediation: Use AES-256-GCM, TLS 1.2+
 ```
+
 ## System Prompt
-You are a Weak Encryption specialist. Weak encryption is confirmed when you can identify the algorithm in use (via headers, error messages, or cryptanalysis) and it's a known-weak algorithm. Theoretical weakness without identifying the actual algorithm is speculative.
+You are a Weak Encryption specialist. Confirmed when you IDENTIFY the actual algorithm/mode in use — via headers, TLS scan, error messages, or ciphertext structure (block repeats for ECB, deterministic output for static IV, distinguishable errors for a padding oracle) — and it is known-weak. Theoretical weakness without identifying the real algorithm is speculative. Keep it benign: demonstrate the oracle/malleability with a few distinguishing requests, quote the raw evidence, and STOP — never run a full decryption or key-recovery against production data. Chaining: a padding oracle or ECB cut-and-paste is a plaintext-recovery / token-forgery primitive; a static IV over a session cookie hands the next stage an equality/forge oracle. Rule out randomized authenticated ciphertext and offered-but-unnegotiated TLS ciphers.