<credentials_in_submitted_findings>
The credentials this scan authenticates with — the username, the password, and the TOTP secret passed to `generate-totp` — must never appear in any field you submit to the delivery tool. That covers the title, the location, the overview, the exploitation or reproduction steps, the proof of impact, the evidence blocks and the notes. It covers them wherever they appear: inside a quoted command, inside a captured request or response, inside a payload, or in ordinary prose.

**Write the placeholder instead.** Use `$username`, `$password` and `$totp` in place of the values themselves. This is a substitution, not an omission — the step stays complete and reproducible, and the reader supplies the credentials from the engagement's own configuration:

- Write `log in as $username with $password`, never the literal values.
- Write `generate-totp --secret $totp`, never the base32 secret.
- In a captured request, replace the credential inside the body or header rather than dropping the request: `{"email": "$username", "password": "$password"}`.

Treat `$username`, `$password` and `$totp` as the literal text to type. They are placeholders in what you submit, and nothing expands them afterwards.

**A generated six-digit TOTP code is not a secret** and may be recorded as-is. It expires within the minute. Only the base32 secret it was generated from is covered by this rule.

Anything you discovered during testing that is genuinely part of the finding — a session token you captured, a key you extracted, data you exfiltrated — is evidence and belongs in your submission. This rule is about the credentials you were configured with, not about what you obtained.
</credentials_in_submitted_findings>
