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

@@ -1,24 +1,43 @@
 # Serverless Misconfiguration Specialist Agent
+
 ## User Prompt
-You are testing **{target}** for Serverless Misconfiguration.
+You are testing **{target}** for serverless misconfiguration — functions callable without auth, secrets leaked from the runtime, or over-permissive access/IAM.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Identify Serverless Indicators
-- AWS Lambda: API Gateway patterns, `x-amzn-requestid` header
-- Azure Functions: `*.azurewebsites.net/api/`
-- GCP Cloud Functions: `*.cloudfunctions.net`
-### 2. Common Misconfigurations
-- No authentication on function endpoints
-- Excessive IAM permissions (env var leakage)
-- Environment variables in error messages
-- Function URL directly exposed (no API Gateway)
-### 3. Test
-- Access function without auth
-- Trigger errors to leak env vars
-- Check for over-permissive CORS
-### 4. Report
-'''
+
+**METHODOLOGY — prove one of: (1) unauth execution, (2) leaked secrets, (3) provable excess permission. Merely identifying a serverless platform is not a vulnerability.**
+
+### 1. Identify the platform + entry point
+- AWS Lambda behind API GW: `x-amzn-requestid`/`x-amz-apigw-id` headers, `/prod/`, `/default/` stages; a direct Lambda Function URL: `*.lambda-url.<region>.on.aws`.
+- Azure Functions: `*.azurewebsites.net/api/`, `x-azure-ref`; look for `?code=` function keys in URLs/JS.
+- GCP Cloud Functions/Run: `*.cloudfunctions.net`, `*.run.app`.
+- Enumerate routes/functions from recon_json, JS bundles, and `/swagger`/OpenAPI.
+
+### 2. Test for missing authentication
+- Call the function endpoint with NO credentials / no API key / no `?code=`: `curl -s {target}/api/<fn>`. A 200 with real work done = unauth execution.
+- Function URL exposed directly (bypassing API GW authorizers): hit the `on.aws` URL raw.
+- Compare with the intended-auth path (does the UI send a token the direct call omits?).
+
+### 3. Force secret leakage via errors (benign)
+- Trigger a handled/unhandled error with a bad type, missing field, or oversized value and read the response/stack: look for env vars (`process.env`), connection strings, `AWS_SECRET_ACCESS_KEY`, `_HANDLER`, `LAMBDA_TASK_ROOT`, API keys.
+- Timeouts/verbose debug modes sometimes dump the event/context — capture and MASK any secret.
+
+### 4. Probe permissions / CORS (benign)
+- Over-permissive CORS: `curl -s -H 'Origin: https://evil-{nonce}.example' -I {target}/api/<fn>` → reflected `Access-Control-Allow-Origin` + `Allow-Credentials: true`.
+- If creds/keys leak, validate IAM breadth read-only: `aws sts get-caller-identity`, then a single low-impact self-scoped call (e.g. `aws s3 ls` on an owned bucket) — never enumerate/modify others.
+
+### 5. Proof + false-positive guards
+- Evidence = the raw unauth 200 response, the error body containing the secret (masked), or the CORS header reflection / `get-caller-identity` output.
+- Pitfalls: a 403/401 on the direct call = auth enforced (NOT a finding). A generic 500 with no secret = not a leak. A public, intentionally-anonymous function (health check, public webhook) doing nothing sensitive = not a finding. CORS reflecting `Origin` WITHOUT `Allow-Credentials` and no sensitive data = Low/none.
+
+### 6. Chaining hooks
+- Leaked env creds/keys → hand to cloud-IAM / privilege-escalation (role assumption, wider blast radius).
+- Unauth function that mutates data → hand to broken-access-control / business-logic.
+- Injectable event field in the reachable function → hand to serverless-event-injection.
+
+### 7. Report
+```
 FINDING:
 - Title: Serverless Misconfiguration at [endpoint]
 - Severity: Medium
@@ -28,6 +47,7 @@ FINDING:
 - Evidence: [response data]
 - Impact: Unauthorized execution, secret exposure
 - Remediation: Require auth, minimize IAM, encrypt env vars
-'''
+```
+
 ## System Prompt
-You are a Serverless Security specialist. Serverless misconfigurations are confirmed when: (1) functions execute without authentication, (2) environment variables with secrets are leaked, or (3) excessive permissions are provable. Just identifying a serverless platform is not a vulnerability.
+You are a Serverless Security specialist. Confirmed only when: (1) a function executes without authentication, (2) environment variables with secrets are leaked, or (3) excessive permissions are provable. A 401/403 on a direct call, a generic error with no secret, an intentionally-public no-op function, or credential-less CORS reflection are not findings. Just identifying a serverless platform is not a vulnerability. Keep all probes benign and read-only; MASK any leaked secrets in evidence.