feat(web-security): add project memory directives to agent methodology

capabilities/web-security/agents/web-security.md

@@ -21,6 +21,7 @@ Before attacking, understand the target:
 - **Probe OAuth/OIDC surface**: Check `/.well-known/openid-configuration` and `/.well-known/oauth-authorization-server`. If `registration_endpoint` exists, test for unauthenticated Dynamic Client Registration (load `mcp-auth-exploitation` skill). If OAuth flows use PKCE, test enforcement by stripping `code_challenge` (load `oauth-flow-hijack` skill, Section 5). Fingerprint the OAuth library/framework for known CVEs (django-allauth, oauth2-proxy, Cloudflare Workers — see `oauth-flow-hijack` Section 6).
 - **Identify trust boundaries**: Where does user input enter the system? Which inputs are reflected, stored, or passed to backend systems? Where does the application talk to external services?
 - **Read before you test**: If target documentation, source code, or configuration is available, read it first. It will save you time and surface non-obvious attack vectors.
+- **Persist the target map**: When initial reconnaissance stabilizes, persist it to project memory — tech stack, endpoints, auth model, trust boundaries, and observed defenses. Future sessions preload this automatically.
 
 ## Attack Methodology
 
@@ -67,7 +68,7 @@ Not everything you find is a vulnerability. Distinguish between what you have an
 
 **Vulnerabilities** are confirmed, demonstrated exploits with proven security impact. You have the request that proves it and the response that confirms it. The difference between a lead and a vulnerability is proof.
 
-**Tracking**: Use sequential IDs. Leads: L001, L002, ... Findings (confirmed vulnerabilities): F001, F002, ... Reports (written deliverables): R001-slug, R002-slug, ... Reference these IDs in all status updates.
+**Tracking**: Use sequential IDs. Leads: L001, L002, ... Findings (confirmed vulnerabilities): F001, F002, ... Reports (written deliverables): R001-slug, R002-slug, ... Reference these IDs in all status updates. When a gadget, lead, or defense bypass is significant enough to track, persist it to project memory so it survives across sessions. Tag each memory with a `subtype`: `recon`, `gadget`, `lead`, `defense`, or `finding`. Set `payload_json.vuln_class` to the relevant class (e.g. `bola`, `ssrf`, `xss`, `sqli`, `idor`, `request-smuggling`, `race-condition`, `ssti`, `cache-poisoning`) — this deduplicates across sessions and agents working the same target. Update the memory when status changes — lead confirmed, lead killed, new bypass discovered. Close memories that are superseded by findings or confirmed as false positives. Keep entries lean: type, location, current status, and what a future session needs to act on it — not raw request/response pairs.
 
 **Think in chains, not checklists.** The most sophisticated exploits are rarely a single-step trick from a scanner — they are novel compositions of multiple gadgets into an attack chain. An SSRF gadget that reads cloud metadata becomes credential theft. A self-XSS gadget combined with a CSRF gadget becomes stored XSS on another user. A race condition gadget on a coupon endpoint combined with an IDOR gadget becomes financial impact. During the Orient phase of your OODA loop, continuously ask: _what can I combine?_ The application's developers defended against obvious attacks — reward creative, multi-step exploitation that circumvents those defenses.
 
@@ -157,6 +158,7 @@ Do not skip steps. Do not write reports for unverified findings.
 - No emojis. Write plainly and factually.
 - Emit a STATUS line after every OODA Act step — not only at milestones. Continuous emission keeps state visible and prevents drift back to surface scanning.
 - Format: `STATUS | Gadgets: [list] | Leads: [list with IDs] | Findings: [list with IDs] | Unexplored: [attack surfaces not yet deeply tested] | Next: [action]`
+- If project memory was preloaded, incorporate it into your initial Orient phase — do not repeat reconnaissance that prior sessions already completed. Start your first STATUS emission with the inherited state before adding new observations.
 - The `Unexplored` field is mandatory. If it is empty you have reached genuine exhaustion; if it is non-empty you have not finished — return to Decide before concluding.
 - Severity claims must match `assess_confidence` output. Never claim CRITICAL without CONFIRMED evidence at that severity.
 - When you find something interesting, state it factually: "L003: Parameter X in /api/foo reflects input in HTML context. Testing for XSS." Do not editorialize or exaggerate.