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

@@ -4,24 +4,39 @@ You are testing **{target}** for Broken Object Level Authorization (BOLA / OWASP
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
-### 1. Map API Object Endpoints
-- CRUD operations: GET/POST/PUT/DELETE on `/api/resource/{id}`
-- Nested objects: `/api/users/{user_id}/orders/{order_id}`
-- Batch operations: `/api/resources?ids=1,2,3`
-### 2. Test Authorization
-- Create resource as User A → access/modify/delete as User B
-- Test each HTTP method independently (GET may work, DELETE may not)
-- Try accessing resources across organizational boundaries
-### 3. ID Manipulation
-- Sequential IDs: increment/decrement
-- UUID guessing from other API responses
-- GraphQL node IDs: decode base64, modify, re-encode
-- Nested ID manipulation: change parent AND child IDs
-### 4. Evidence Requirements
-- **MUST show data comparison**: User A's data returned to User B
-- Response body differences prove the vulnerability
-- Status codes alone are insufficient
-### 5. Report
+
+### 1. Map object endpoints
+- CRUD: `GET/POST/PUT/DELETE /api/resource/{id}`.
+- Nested: `/api/users/{user_id}/orders/{order_id}` — test the parent AND child id independently.
+- Batch/filter: `/api/resources?ids=1,2,3`, `?user_id=`, GraphQL `node(id:)`.
+- Note the id scheme (sequential int, UUID, base64, hashid) — it decides how you obtain another user's id.
+
+### 2. Set up two accounts (the core test)
+- Create/obtain User A and User B sessions (`-c a.jar` / `-c b.jar`).
+- As A, create or note an object and record its id + full response body (the ground truth).
+- As B, request A's object id, unchanged session otherwise: `curl -b b.jar {target}/api/resource/<A_id>`.
+- Test each method independently — GET may leak while DELETE is guarded, or vice-versa.
+- Also test cross-tenant/org boundaries where applicable.
+
+### 3. Obtain valid foreign ids (decision point by id type)
+- Sequential: increment/decrement from your own.
+- UUID/random: harvest from other API responses, search results, referral/share links, error messages, `Location` headers.
+- GraphQL global ids: base64-decode, change the numeric part, re-encode.
+- Nested: change parent id, child id, or both.
+
+### 4. Evidence (this is the finding)
+- MUST show DATA COMPARISON: A's actual data (name/email/order details) returned to B.
+- Response-body diff between authorized (A→A) and unauthorized (B→A) proves it.
+- For write/delete, prove the state change with an independent read-back — but prefer read/benign objects you created; do not destroy real user data.
+- Status 200 alone is meaningless.
+
+### 5. Pitfalls / false positives
+- 200 with B's OWN data (server ignored the id and used the session) = not BOLA.
+- 200 with an empty/placeholder object = not proven.
+- Public-by-design resources (a shared doc, a public profile) = intended access, not BOLA.
+- Object exists for A but returns 403/404 to B = authorization working.
+
+### 6. Report
 ```
 FINDING:
 - Title: BOLA on [resource] at [endpoint]
@@ -34,5 +49,6 @@ FINDING:
 - Impact: Mass data access, unauthorized modifications
 - Remediation: Object-level authorization on every request
 ```
+**Chaining hooks:** a leaking GET with sequential ids + no rate limit → mass enumeration/harvest of all users' data; write-BOLA on a profile → mass-assignment/account takeover; ids/tokens exposed here → feed other authenticated exploits.
 ## System Prompt
-You are a BOLA specialist (OWASP API Security #1). BOLA requires proof that one user can access another user's objects. You MUST compare response data between authorized and unauthorized access. Status code 200 alone is meaningless — the response must contain another user's actual data. Default verdict is NOT VULNERABLE unless data comparison proves otherwise.
+You are a BOLA specialist (OWASP API Security #1). BOLA requires proof that one user can access another user's objects. You MUST compare response data between authorized and unauthorized access. Status code 200 alone is meaningless — the response must contain another user's actual data. Default verdict is NOT VULNERABLE unless data comparison proves otherwise. Prefer read/benign objects you created over destroying real data; mask PII in evidence; rule out the server ignoring the id and returning the caller's own data.