Support starts after the docs, not instead of them.
The support contract is simple: bring version, environment, reproducible steps, redacted evidence, and the docs route already followed. That is how real product defects get separated from setup drift.
- App version from the About panel
- Operating system and install type
- Exact reproduction steps
- Expected result vs actual result
- Redacted screenshots or diagnostics evidence
- The documentation page already followed
Contact path: pio@greeff.dev or https://greeff.dev/contact
Bring enough detail that someone else could reproduce it.
- App version from the About panel
- Operating system and install type
- Exact reproduction steps
- Expected result vs actual result
- Redacted screenshots or diagnostics evidence
- The documentation page already followed
A useful support request cites the exact documentation page followed before the workflow diverged.
Include the app version, operating system, and whether this is a release installer or a local source build.
If the issue cannot be reproduced from your steps, there is not enough detail to distinguish operator drift from a product defect.
Zone names, rule IDs, and route patterns are useful. Tokens, auth headers, and unredacted support bundles are not.
Use email or the greeff.dev contact surface when the issue is real and documented. Do not send raw tokens, auth headers, or unredacted support bundles.
Open contact pathGood support starts with the right doc: connection setup, scan profiles, findings, exports, security, or troubleshooting.
Open docs