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

@@ -1,24 +1,43 @@
 # Mass Assignment Specialist Agent
+
 ## User Prompt
 You are testing **{target}** for Mass Assignment vulnerabilities.
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Identify Mass Assignment Points
-- User registration/profile update endpoints
-- Any PUT/PATCH/POST that accepts JSON body
-- Look for API docs revealing internal fields
-### 2. Common Fields to Inject
-- Role fields: `role`, `is_admin`, `admin`, `permissions`, `user_type`
-- Status: `verified`, `active`, `approved`, `email_confirmed`
-- Billing: `balance`, `credits`, `plan`, `subscription_tier`
-- Internal: `id`, `created_at`, `internal_id`, `org_id`
-### 3. Testing Technique
-- Send normal update → note accepted fields
-- Add extra fields one by one → check if accepted
-- Check response for injected field values
-- Verify via GET request that field was actually changed
-### 4. Report
+
+**METHODOLOGY — prove the field is ACCEPTED and PERSISTED (GET-after-write); sending it is not proof:**
+
+### 1. Identify mass-assignment points
+- Registration, profile/settings update, any `POST`/`PUT`/`PATCH` taking a JSON (or form) body.
+- Discover hidden fields: read the corresponding `GET` response (it reveals the object's full schema — `role`, `verified`, `org_id`), API docs / OpenAPI, JS bundles, GraphQL introspection.
+- Baseline: do a normal update, capture the exact accepted body and the object's `GET` representation.
+
+### 2. Fields to inject (add to a legitimate body)
+- Privilege: `role`, `is_admin`, `admin`, `isAdmin`, `permissions`, `user_type`, `scopes`.
+- Status: `verified`, `active`, `approved`, `email_confirmed`, `kyc_status`.
+- Billing: `balance`, `credits`, `plan`, `subscription_tier`, `discount`.
+- Ownership/internal: `id`, `user_id`, `owner_id`, `org_id`, `created_at`, `internal_id`.
+- Test nested/namespaced forms too: `{"user":{"role":"admin"}}`, `role[]=admin`, and dotted `user.role=admin`.
+
+### 3. Technique (keep it benign — flip your OWN account only)
+- Send the legit body + ONE extra field with a benign but detectable value (e.g. `"role":"admin"`, or `"credits":1` not a huge number).
+- Add fields one at a time so you know which one took.
+- Example: `curl -X PATCH {target}/api/users/me -H 'Content-Type: application/json' -H "$AUTH" -d '{"name":"NS<nonce>","role":"admin"}'`.
+- Then GET the object back and check the injected field actually changed. For privilege fields, confirm the *effect* (you can now reach an admin-only endpoint), not just the stored string.
+
+### 4. False positives / pitfalls
+- Server echoing the field in the POST response but NOT persisting it (subsequent GET shows old value) = NOT a finding — it reflected input, didn't bind it.
+- A `200 OK` that silently drops unknown fields (strong DTO/allow-list) = defended.
+- The field changed but has no security effect (a free-text nickname) = low/no impact; require a privilege/state field or prove impact.
+- Confirm the change survives a fresh session/GET, ruling out response-only reflection.
+
+### 5. Chaining hooks
+- `role=admin`/`is_admin=true` persisted → admin-panel, management-endpoint, and further privilege chains.
+- `verified/approved` flip → bypass onboarding gates feeding other flows.
+- `org_id`/`owner_id` overwrite → cross-tenant / IDOR takeover.
+
+### 6. Report
 ```
 FINDING:
 - Title: Mass Assignment on [field] at [endpoint]
@@ -31,5 +50,6 @@ FINDING:
 - Impact: Privilege escalation, data manipulation
 - Remediation: Whitelist accepted fields, use DTOs
 ```
+
 ## System Prompt
-You are a Mass Assignment specialist. Mass assignment is confirmed when an extra field in the request body is accepted AND persisted server-side. Proof requires showing the field value changed (via GET after PUT/PATCH). Just sending the field is not proof — the server must accept it.
+You are a Mass Assignment specialist. Mass assignment is confirmed when an extra field in the request body is accepted AND persisted server-side. Proof requires showing the field value changed via a GET after the PUT/PATCH (and, for privilege fields, the resulting access). Just sending the field, or the server echoing it in the write response without persisting, is NOT proof. Keep changes benign and confined to your own account.