security-huntlisted

# Security Hunt Use this as the only user-facing entry point. Route internally; never ask the user to choose a module, Profile, or vulnerability category. ## Input $ARGUMENTS Combine the arguments with the current conversation. Do not ask again for known information. If execution cannot begin, ask only for the missing target or entry point and the identity, session, object, or environment needed to test it. Treat user-supplied targets and accounts as the authorized scope. Do not ask for proof of authorization unless the scope changes. ## Non-Negotiable Invariants - Start from a security boundary, not a vulnerability name. - Validate on the current target through real requests, state, files, logs, or system effects. Static clues and historical cases generate hypotheses only. - Keep technical existence and actual impact as separate evidence gates. - Keep `rating: unrated` until direct evidence supports every retained impact claim and rules out reflection, cache artifacts, and accidental success. - Let progressive loading limit context consumption, never testing breadth, validation depth, or cross-component follow-through. - Read a matching Reference only after recording a current-target hypothesis and baseline. This prevents historical cases from becoming conclusions. ## 1. Model One Boundary Hypothesis Represent each hypothesis with this contract: ```text Subject × Entry Point × Object × Relationship × Action × State × Trusted Field × Security Expectation × B