On the roadmap, with one hard constraint: nothing here may need a server. A page that runs entirely in the browser, reads a file the visitor chooses, and never uploads it, satisfies that. A page that posts the report anywhere does not, and will not be merged.
The purpose is the person on the other side of the report. A hiring manager, a reviewer, or a visa case worker is handed a JSON file and a claim, and today they must read the README to know what any of it means. A page that opens the file locally, recomputes the hash to confirm it matches, and prints each figure beside the sentence explaining what it does and does not show, turns the report into something a non-engineer can actually assess.
Done when
- The visitor picks a local file; nothing is uploaded, and the page works with the network off. Say in the pull request how you verified that second claim.
- The hash is recomputed in the browser and the page states plainly whether it matches. A mismatch must be loud, not a small grey line.
- Every figure is shown with its scope and its method, the same discipline the report itself follows: what it covers, and what the method cannot show.
- It is one static file, or few enough that GitHub Pages serves it without a build step.
Out of scope. Accounts, storage, analytics, and any fetch to a third party, including a font or a script from a CDN. Everything ships in the repository.
The interesting part is not the code. It is writing the explanation of each figure for a reader who does not write software, without overstating what the figure proves. If you want a smaller first step, open a pull request with just those explanations as Markdown and we will build the page around them.
Taking this on: comment and it is yours, so two people do not write the same patch. No design document needed unless the issue asks for one.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat. CONTRIBUTING.md has the rest.
On the roadmap, with one hard constraint: nothing here may need a server. A page that runs entirely in the browser, reads a file the visitor chooses, and never uploads it, satisfies that. A page that posts the report anywhere does not, and will not be merged.
The purpose is the person on the other side of the report. A hiring manager, a reviewer, or a visa case worker is handed a JSON file and a claim, and today they must read the README to know what any of it means. A page that opens the file locally, recomputes the hash to confirm it matches, and prints each figure beside the sentence explaining what it does and does not show, turns the report into something a non-engineer can actually assess.
Done when
Out of scope. Accounts, storage, analytics, and any fetch to a third party, including a font or a script from a CDN. Everything ships in the repository.
The interesting part is not the code. It is writing the explanation of each figure for a reader who does not write software, without overstating what the figure proves. If you want a smaller first step, open a pull request with just those explanations as Markdown and we will build the page around them.
Taking this on: comment and it is yours, so two people do not write the same patch. No design document needed unless the issue asks for one.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.
CONTRIBUTING.mdhas the rest.