The output is correct, checkable and hashed. It is not something anybody is proud to attach to an application.
The reader is often not an engineer: a hiring manager, a recruiter, a case worker at an immigration authority. They get Markdown or JSON, thirteen figures and a hash. The information is all there and the presentation asks them to do the work of understanding it.
What to build. A one-page rendering somebody would attach to an application without apologising for it: the figures grouped so the eye lands on the claim, each with its scope and its method available but not shouting, the hash and the verification command in a place a sceptical reader will find them.
Done when
- It fits on one page and prints. This is a document that gets printed and stapled to things.
- Every figure keeps its scope and its method. The design must not make the caveats disappear; a beautiful report that hides what a number cannot show would be a worse tool than the ugly one.
- It is generated from the report JSON, so it cannot say anything the report does not.
- No web font, no CDN, no network. It must render identically on a machine with no internet.
- The verification instruction is written for somebody who has never used a terminal, or it says plainly that verification needs one.
Out of scope. Anything that ranks, scores or grades the person. The report describes; it does not assess.
A note on taste. The rest of this project is deliberately plain, and that is not going to change. What is wanted here is not decoration but hierarchy: the thing being claimed, then the evidence, then the method, in that order, so a reader who spends fifteen seconds still leaves with the right impression and a reader who spends fifteen minutes finds everything.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
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.
The output is correct, checkable and hashed. It is not something anybody is proud to attach to an application.
The reader is often not an engineer: a hiring manager, a recruiter, a case worker at an immigration authority. They get Markdown or JSON, thirteen figures and a hash. The information is all there and the presentation asks them to do the work of understanding it.
What to build. A one-page rendering somebody would attach to an application without apologising for it: the figures grouped so the eye lands on the claim, each with its scope and its method available but not shouting, the hash and the verification command in a place a sceptical reader will find them.
Done when
Out of scope. Anything that ranks, scores or grades the person. The report describes; it does not assess.
A note on taste. The rest of this project is deliberately plain, and that is not going to change. What is wanted here is not decoration but hierarchy: the thing being claimed, then the evidence, then the method, in that order, so a reader who spends fifteen seconds still leaves with the right impression and a reader who spends fifteen minutes finds everything.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
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.