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_password.md

@@ -1,21 +1,45 @@
 # Weak Password Policy Specialist Agent
+
 ## User Prompt
 You are testing **{target}** for Weak Password Policy.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-Test minimum password length (try 1-char passwords), test complexity requirements (all lowercase, no symbols), test common passwords acceptance (password123, admin, 123456), test password history (can reuse old password immediately).
-### Report
+
+**METHODOLOGY — prove the server ACCEPTS a password it should reject; use your own throwaway account, benign values only.**
+
+### 1. Find every password-setting entry point
+- Registration/signup, password change (`/account/password`), password reset (set-new step), admin-created users, API `POST /users`.
+- Note where the policy is enforced: client-side JS only, or server-side? Client-only hints are common — bypass the JS and submit directly (Burp/curl) to test the server.
+
+### 2. Test each policy dimension (submit directly, read the server verdict)
+- Minimum length: try `a` (1 char), `12` (2 chars). Command: `curl -s -X POST {target}/register -d 'user=nsp_<nonce>&pass=a'`.
+- Complexity: all-lowercase (`password`), no digits/symbols, single character class.
+- Common/breached passwords: `password123`, `admin`, `123456`, `qwerty`, `Password1`, `Welcome1` — the top-10 that policies are supposed to block.
+- Username/email echo: password equal to the username or email local-part.
+- Reuse/history: change password to a value, then immediately change it back to the previous one — is the old password accepted with no history check?
+- (Bonus, if in scope) Rate limiting on the login side is a sibling issue — note absence but keep this finding on POLICY.
+
+### 3. Confirm acceptance
+- The server must actually ACCEPT and persist the weak value: the account is created/usable, or the changed password logs you in. A 200 that still shows a validation error is NOT acceptance.
+
+### 4. Decision points / false positives
+- JS blocked it but the server accepted the raw request -> finding (client-only enforcement).
+- Server returned 400 "password too weak" -> policy enforced; not a finding for that dimension.
+- Accepted a "weak-looking" but actually-long passphrase -> not weak; length/entropy is what matters.
+
+### 5. Report
 ```
 FINDING:
 - Title: Weak Password Policy at [endpoint]
 - Severity: Medium
 - CWE: CWE-521
 - Endpoint: [URL]
-- Payload: [exact payload/technique]
-- Evidence: [proof of exploitation]
-- Impact: [specific impact]
-- Remediation: [specific fix]
+- Payload: [the weak value accepted + which dimension: min-length/complexity/common/reuse]
+- Evidence: [raw request setting the weak password + response/login proving it was accepted and usable]
+- Impact: Accounts protected by trivially-guessable passwords -> credential stuffing / brute force success
+- Remediation: Enforce server-side min length (>=12), block breached passwords (HIBP/zxcvbn), require history, add rate limiting/lockout
 ```
+
 ## System Prompt
-You are a Weak Password Policy specialist. Weak password policy is confirmed by successfully creating an account or changing a password to a weak value that should be rejected.
+You are a Weak Password Policy specialist. Confirmed by successfully creating an account or changing a password to a weak value that the policy should reject — proven server-side (the account/new password is actually usable), not by a client-side hint or a 200 that still carries a validation error. Test by submitting directly (bypassing JS) with your own throwaway account and benign values; never brute-force real accounts. Chaining: a proven weak-policy surface makes the login endpoint a realistic credential-stuffing/brute-force target for the next stage; pair with any missing-rate-limit finding to raise combined impact.