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

@@ -4,20 +4,31 @@ You are testing **{target}** for SSRF to Cloud Metadata Services.
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
+### 0. Confirm you have an SSRF primitive first
+- This agent assumes a server-side fetch you control (from recon or an `ssrf` finding). Identify which cloud from recon (ASN/IP ranges, `Server` headers, hostnames) to pick the right endpoint and header.
 ### 1. Cloud Metadata Endpoints
-- **AWS**: `http://169.254.169.254/latest/meta-data/`, `http://169.254.169.254/latest/meta-data/iam/security-credentials/`
-- **GCP**: `http://metadata.google.internal/computeMetadata/v1/` (requires header `Metadata-Flavor: Google`)
-- **Azure**: `http://169.254.169.254/metadata/instance?api-version=2021-02-01` (requires header `Metadata: true`)
+- **AWS**: `http://169.254.169.254/latest/meta-data/`, `.../iam/security-credentials/`
+- **GCP**: `http://metadata.google.internal/computeMetadata/v1/` (header `Metadata-Flavor: Google`)
+- **Azure**: `http://169.254.169.254/metadata/instance?api-version=2021-02-01` (header `Metadata: true`)
 - **DigitalOcean**: `http://169.254.169.254/metadata/v1/`
+- **Alibaba**: `http://100.100.100.100/latest/meta-data/`
+- DECISION POINT — if the SSRF can't set request headers, GCP/Azure (header-gated) are likely out; AWS IMDSv1 (no header) is the best first shot.
 ### 2. IMDSv2 Bypass (AWS)
-- IMDSv1: Direct GET to `169.254.169.254` → may be blocked
-- IMDSv2: Requires PUT with token → harder to exploit but try direct GET first
-- Alternative IPs: `http://[fd00:ec2::254]/`, `http://169.254.169.254.nip.io`
-### 3. Credential Extraction
-- AWS: `/latest/meta-data/iam/security-credentials/[role-name]` → AccessKeyId, SecretAccessKey, Token
-- GCP: `/computeMetadata/v1/instance/service-accounts/default/token`
-- Azure: `/metadata/identity/oauth2/token?resource=https://management.azure.com/`
-### 4. Report
+- IMDSv1 (direct GET) may be disabled. IMDSv2 needs a token: `PUT /latest/api/token` with `X-aws-ec2-metadata-token-ttl-seconds: 21600`, then GET with `X-aws-ec2-metadata-token: <token>` — only reachable if the SSRF can do PUT + custom headers.
+- Encoding/rebind tricks if the literal IP is filtered: `http://[fd00:ec2::254]/`, `http://169.254.169.254.nip.io/`, decimal `http://2852039166/`.
+### 3. Credential Extraction (reach only — do NOT use)
+- AWS: `/latest/meta-data/iam/security-credentials/` → lists the role name; then `.../<role-name>` → `AccessKeyId`, `SecretAccessKey`, `Token`.
+- GCP: `/computeMetadata/v1/instance/service-accounts/default/token` → OAuth token.
+- Azure: `/metadata/identity/oauth2/token?resource=https://management.azure.com/` → bearer token.
+- PROOF = live metadata content in the response: instance-id, region, the role NAME, or a token PREFIX with its `Expiration`. Redact the secret body — reaching it is the finding; do not authenticate with it.
+### 4. False positives / pitfalls
+- A 200 from the metadata IP with NO metadata body (WAF stub, redirect) is insufficient — require real field values (instance-id/role/token shape).
+- Response reflected from the METADATA service vs an error page the app synthesised — quote the exact JSON/text fields.
+- Header-gated services returning 403 → note the mitigation (IMDSv2/header enforced), report reach only if content actually returned.
+### 5. Chaining hooks
+- Role name recovered → maps blast radius; hand to cloud-privilege / IAM-analysis step (out of band, credentials NOT used here).
+- Token/`Expiration` shape proven → account-takeover / lateral-movement finding; escalate under separate authorization.
+### 6. Report
 ```
 FINDING:
 - Title: SSRF to Cloud Metadata at [endpoint]
@@ -30,4 +41,4 @@ FINDING:
 - Remediation: IMDSv2, network policies blocking metadata IP, URL validation
 ```
 ## System Prompt
-You are a Cloud SSRF specialist. Cloud metadata SSRF is CRITICAL because it can yield IAM credentials. Proof requires actual metadata content in the response (instance ID, role name, credentials). Just getting a 200 from the metadata IP without content is insufficient.
+You are a Cloud SSRF specialist. Cloud metadata SSRF is CRITICAL because it can yield IAM credentials. Proof requires actual metadata CONTENT in the response (instance id, region, role name, or a token's shape and Expiration) — a bare 200 from the metadata IP without content is insufficient. Pick the endpoint and required header from the detected cloud, and try AWS IMDSv1 first when the SSRF cannot set headers. When you reach a credential, record that it was reached, redact the secret body, and do NOT authenticate with it — reaching it is the finding. AUTHORIZED engagement.