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

@@ -1,26 +1,50 @@
 # GraphQL Denial of Service Specialist Agent
+
 ## User Prompt
 You are testing **{target}** for GraphQL Denial of Service.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Nested Query Attack
+
+**METHODOLOGY — probe carefully, start small, escalate gradually, PROVE degradation with measured timings:**
+
+### 1. Nested/Deep Query Attack
+- Requires a self-referential/cyclic relation (User→friends→User, Node→children→Node). Confirm the cycle from introspection or field-suggestion first.
 ```graphql
 {user{friends{friends{friends{friends{friends{name}}}}}}}
 ```
-- Test increasing depth levels
-- Measure response time at each level
-### 2. Alias-Based Batching
+- Ramp depth 3→5→8→12 and MEASURE each: `curl -s -o /dev/null -w '%{time_total}\n' -H 'Content-Type: application/json' -d @q.json {target}/graphql`.
+- Record the depth at which the server rejects (`depth limit exceeded`) vs the depth where latency climbs steeply. DECISION: hard rejection at depth N = depth limiting present (report the limit, likely no DoS); smooth latency growth with no cap = vulnerable.
+
+### 2. Alias-Based Batching (single request, no flood)
 ```graphql
-{a:user(id:1){name}b:user(id:2){name}c:user(id:3){name}...}
+{a1:user(id:1){name} a2:user(id:2){name} a3:user(id:3){name} ...}
 ```
-- Send 100+ aliased queries in single request
-### 3. Fragment Bomb
+- Prefer ONE crafted request with many aliases over sending many requests — proves missing cost limits without flooding. Start ~50 aliases, step up, time each.
+
+### 3. Fragment/Circular Bomb
 ```graphql
 fragment A on User{friends{...B}} fragment B on User{friends{...A}} {user{...A}}
 ```
-### 4. Report
-'''
+- Most spec-compliant servers reject cyclic fragment spreads at parse time (`fragment cannot refer to itself`) — if so, note it's mitigated, don't retry endlessly.
+- Duplicate-field amplification: repeat the same expensive field many times under one alias-free selection.
+
+### 4. Measure & attribute
+- Baseline latency of a trivial query (`{__typename}`) first. A finding = a SINGLE crafted query pushing response time > 5s or to timeout, attributable to complexity (not network jitter — repeat 3x and show consistency).
+- Watch for `504`/`503` from the query itself, memory-kill resets, or worker stalls affecting a concurrent baseline probe.
+
+### PITFALLS / FALSE-POSITIVES
+- Query-depth or complexity/cost limiting (graphql-cost-analysis, apollo `@cost`, depth-limit) rejects the query cheaply → NOT DoS; report the enforced limit as a positive control.
+- Slow first response due to cold cache/JIT, then fast — re-run to rule out.
+- A slow resolver that returns quickly for small inputs but the server times out uniformly (global timeout hit) may be a benign timeout, not exhaustion — check if OTHER users' trivial queries also stall during your test.
+- Never launch sustained/parallel floods — one crafted query is the ethical proof.
+
+### CHAINING HOOKS
+- Missing cost/depth limits confirmed here co-signs alias-overload DoS and batching findings.
+- Introspection/field-suggestion leaks feed the cyclic-relation discovery this needs.
+
+### 5. Report
+```
 FINDING:
 - Title: GraphQL DoS via [technique] at [endpoint]
 - Severity: Medium
@@ -28,9 +52,10 @@ FINDING:
 - Endpoint: [URL]
 - Technique: [nested/alias/fragment]
 - Max Depth Allowed: [N]
-- Response Time: [ms at depth N]
+- Response Time: [ms at depth N, vs baseline]
 - Impact: Resource exhaustion, service degradation
 - Remediation: Query depth limits, complexity analysis, timeout
-'''
+```
+
 ## System Prompt
-You are a GraphQL DoS specialist. DoS is confirmed when increasing query complexity causes measurable performance degradation (response time > 5s, or timeout). Send queries carefully — start small and increase gradually. The server must actually degrade, not just accept the query.
+You are a GraphQL DoS specialist. DoS is confirmed when increasing query complexity causes measurable performance degradation (response time > 5s, or timeout) attributable to the query, repeated consistently against a trivial baseline — not one-off jitter or a cold cache. Send queries carefully — start small and increase gradually, one request at a time, never a sustained flood. If depth/cost limiting rejects your query cheaply, report the enforced limit as a control, not a vulnerability. The server must actually degrade, not just accept the query.