This page is about the record, not the outcome. Whether an appeal succeeds is the platform's decision and nobody outside it can promise you anything. What you can control is whether you can show, precisely, what you changed and when — and that turns out to be the part most people assemble badly, under time pressure, from screenshots scattered across a laptop.

If you script the assembly of an evidence bundle, the script reads files and copies them into something you then send outside your company. That means the set of paths it will follow is a security question, not a convenience one.

Checking that a path string starts with your evidence folder is not enough. A symlink inside that folder can point anywhere, and a naive check passes it — the file gets read, hashed, and copied into the bundle. Resolve the real path and check that, and make the evidence directory mandatory rather than optional: without one there is no boundary to enforce, and a default of "wherever the file happens to be" quietly means "anywhere".

We know because our own first version did exactly that, and a pre-publication review caught it before release rather than after.

desiria-review-dossier takes a list of changes you wrote and a folder of evidence, and produces one document you can attach: a dated change log, an index of the evidence with checksums, and — if you point it at a previous submission — what moved since. MIT, runs locally, no account.

github.com/desiria-ja/desiria-review-dossier

What it deliberately does not do: it does not judge your case, advise you on what to fix, act on your account, or predict an outcome. It does not connect to any platform API. It organises what you tell it, and records where each file came from.