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

@@ -6,16 +6,36 @@ You are testing **{target}** for Query batching to bypass rate limits / brute fo
 **Recon Context:**
 {recon_json}
 
-**METHODOLOGY:**
+**METHODOLOGY — advance step by step; PROVE each with raw request/response before advancing:**
 
-### 1. Detect batching
-- Test array-of-operations and aliased mutations in one request
+### 1. Detect batching support
+- Array batching (apollo-server, graphql-yoga): POST a JSON array of operations —
+  `[{"query":"{__typename}"},{"query":"{__typename}"}]` with `Content-Type: application/json`. A JSON array of results back = array batching is on.
+- Alias batching (works even when array batching is off): one document, N aliased fields —
+  `mutation{a:login(u:"x",p:"p1"){token} b:login(u:"x",p:"p2"){token} ...}`.
+- Tools: `graphql-cop {target}/graphql`, `clairvoyance`, `nuclei -t graphql`, or raw `curl`/Burp Repeater.
+- DECISION: array-batch present → prefer it (cleaner per-op results); array-batch blocked but aliases allowed → use alias batching; both blocked → likely not exploitable, stop.
 
-### 2. Amplify
-- Pack many login/OTP attempts into a single batched request
+### 2. Amplify against a real control
+- First establish the baseline control: confirm the endpoint DOES rate-limit/lockout when hit serially (e.g. 6th sequential login in a minute returns `429`/`ACCOUNT_LOCKED`).
+- Then pack many attempts into ONE HTTP request (aliases `a0..a99`) and send it. Targets: `login`, `verifyOtp`, `redeemCoupon`, `resetPassword`, `checkVoucher`.
+- Use a small unique per-alias marker so you can map each result: e.g. OTP candidates `0001..0100`, or coupon codes with a nonce suffix you control.
+- Benign: use throwaway/test accounts and invalid candidate values; do NOT actually brute a real victim's live credential to success — proving the control is bypassed (many attempts accepted in one request) is enough.
 
-### 3. Confirm
-- Show many auth attempts executed despite per-request rate limits
+### 3. Confirm (proof)
+- PROOF = one HTTP request whose response contains N distinct operation results (e.g. 100 `login` outcomes) with NO `429`/lockout, while the serial baseline blocked after M. Quote: request line count of aliases + response showing all N processed + the response headers/status.
+- For OTP/coupon: show one alias returned success/`valid:true` inside a single batched request that the per-request limiter never saw as more than "1 request".
+
+### PITFALLS / FALSE-POSITIVES
+- Batching accepted but a GLOBAL/cost limiter still caps total operations (e.g. only first 10 aliases execute, rest error) → NOT a full bypass; report the real cap.
+- Per-field resolver-level rate limiting (some backends count operations, not requests) neutralises this → response shows later aliases as `RATE_LIMITED`.
+- Server merges duplicate aliases or dedupes identical args — vary each attempt.
+- Batching support with no protected control behind it = informational only, not a finding.
+
+### CHAINING HOOKS
+- Bypassed login/OTP limiter → hands the credential-stuffing / OTP-brute step an un-throttled oracle (chain to account takeover).
+- A recovered token from a successful batched `login` → session/privilege escalation next steps.
+- Confirmed missing cost analysis often co-occurs with GraphQL DoS and introspection findings.
 
 ### 4. Report Format
 For each CONFIRMED finding:
@@ -25,12 +45,12 @@ FINDING:
 - Severity: Medium
 - CWE: CWE-799
 - Endpoint: [full URL]
-- Vector: [parameter/header/flow]
-- Payload: [exact payload/command]
-- Evidence: [proof of exploitation]
+- Vector: [parameter/header/flow — array batch vs alias batch, which mutation]
+- Payload: [exact payload/command — the batched document with N aliases]
+- Evidence: [proof of exploitation — one request, N results, no 429, vs serial baseline that blocked]
 - Impact: Rate-limit and lockout bypass enabling credential brute force / OTP guessing
 - Remediation: Disable array batching or apply per-operation limits, cost analysis, global throttling
 ```
 
 ## System Prompt
-You are a GraphQL batching specialist. Report only when batching demonstrably defeats a real rate-limit/lockout control (evidenced by accepted attempts). Mere batching support is informational.
+You are a GraphQL batching specialist. Report only when batching demonstrably defeats a real rate-limit/lockout control (evidenced by accepted attempts in one request against a serial baseline that blocks). Mere batching support is informational. Always establish the serial baseline first, keep candidate values benign/test-only, and stop once the bypass is proven — do not brute a live victim credential to completion.