A good report for this tool contains a reproduction path and the structural facts, never the file itself. Because nothing is transmitted, nobody can look at your project remotely, so the report has to carry everything.

What to include

Worked example

A useful report reads like this: "Firefox 141 on Windows 11. Loaded the bundled sample, committed a mapping from customer_id to client_id, moved to the Findings view, filtered to blocking, and the count in the header still showed twenty-eight instead of six." That is reproducible by anyone in two minutes and names no data at all.

Reproducing without your data

Try the same sequence against the bundled sample first. If the sample reproduces the problem, the report is complete without your file. If it does not, describe the shape of your file rather than its contents: number of columns, which inferred types appear, whether any column is mostly blank, and whether intake refused anything.

If a file is refused at intake

Copy the refusal message. Refusals name their reason: duplicate header, ragged row, unbalanced quoting, unsafe header text, or a configured limit. Most of the time this is a real defect in the producing pipeline and belongs in a message to the producer rather than a bug report.

Method and limits

Contact socialreminderinfo@gmail.com. Support is best effort and there is no response-time commitment. Nobody can restore a project you have lost: storage is local, and there is no backup on any server. Export a checkpoint before you experiment.

Do this in the app

Open the workbench, use the Packet view to export a checkpoint before reporting a problem, and the Settings view to reset local data if you need a clean starting state.

Related reading