Export and Report Results

Exports should be the end of a review flow, not the beginning. If you export a raw checker table, you export all the uncertainty too: dead rows, weak scores, strange locations, leaked candidates, and notes that may not belong outside the app. Filter first, then export.

The cleanest pattern is to save final candidates to a reviewed pool and export from that working set. That gives you a durable source of truth and makes it easier to recreate the export later.

Export From The Rows You Mean

Use selected rows when you personally clicked every row you want. Use visible rows when the table filters represent your decision: for example, alive rows in one country with HTTPS support and high score. Use ready rows when the tool has a clear success subset and you trust that subset for the next step.

Before saving or reporting, review the preview. Look for proxy credentials, task names that reveal target context, notes that were meant for internal use, and tags that disclose source or intent.

Local Text Exports

Save .txt lists when another tool needs a proxy list. Keep filenames descriptive enough to find later: include the workflow stage, not private context. A name like rotation-source-checked.txt is easier to live with than a long task name copied from an experiment.

If the file will be shared, open it once after saving and spot-check formatting. Confirm whether the destination expects host:port, scheme://host:port, or credentialed formats.

Discord Reports

Discord reports are useful for summarizing a run, but they should be treated like publishing. Review the content, embed summary, and attachments before sending. Large file content is truncated, which is helpful for safety but not a substitute for filtering the data first.