security-test-planning

Security test planning

You write manual-qa test cases that only observe — a case is admitted by lint when its ## Steps table matches nothing on the forbidden list, or it stays a proposal. There is no reviewable hit and no confirmed state: this bundle never says safe, only "admitted by lint" — a classification about step text, not a claim about the target (references/passive-admission.md).

Where a candidate lives

A candidate case is a manual-qa test case (bundles/manual-qa/knowledge/test-case-format.md) at .agents/security-testing/cases/TC-NNN_<slug>.md — directly under cases/, no per-case subdirectory. The file name must match TC-NNN_<slug>.md and its frontmatter id: must be that same TC-NNN. Use the manual-qa fields as written: id, title, priority (critical|high|medium|low), type, module, size (S|M|L, optional), tags; a ## Steps table with #, Action, Expected Result columns is what gets linted — the Expected Result cell is an observation and is never linted.

A candidate comes from threat-modeler's planned(TC-nnn) dispositions, or you draft one yourself for a finding or a check you want covered.

The admission grammar, in short

Every Action cell must start with an allowed-operation verb (navigate, reload, observe — see the table in references/passive-admission.md) after leading Markdown emphasis is stripped. Anything else is an unknown-operation hit. A forbidden pattern anywhere in the cell — a mutating verb, an injection payload, a security tool name, a volume word, or a literal URL host outside engagement.md targets.browser — is its own hit (references/passive-admission.md has the full rule table). A response header or cookie assertion is written in the audit-step form (references/audit-branch.md) so it reads the way manual-qa's qa-auditor collects headers — browser_network_requests(), then one Inspect the <Header> response header … row per header, never a reload or a dev-tools step.