Repository navigation
A standard for the site and public docs (WEB) - #228
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7e40383979
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - **WEB-22 MUST** hold Largest Contentful Paint at or under 2.5 s and Cumulative Layout Shift at or under 0.1 on the | ||
| pages that matter, and accessibility at 95 or above, as measured by Lighthouse in CI. These limits fail the run. |
There was a problem hiding this comment.
The new source entry says WEB-22 defines limits for LCP, INP, and CLS, but this rule only constrains LCP and CLS. As written, a page with severely delayed interaction can still satisfy the standard and keep Lighthouse CI green, so either add an INP threshold here or stop claiming that WEB-22 covers all three metrics.
Useful? React with 👍 / 👎.
| that would have listed unreleased work as shipped; a privacy claim ("two things leave the phone, one of them a crash | ||
| report") that `PRIVACY.md` contradicts, since Folio sends no crash reports; a promise of a VirusTotal link on every |
There was a problem hiding this comment.
This rationale is false when a user chooses Share Diagnostics or Share crash report: Diagnostics.reportIntent and CrashLog.shareIntent create ACTION_SEND intents containing the diagnostic or crash report, and PRIVACY.md explicitly says the user chooses where those reports go. The existing claim that data leaves only when the user shares a report is therefore consistent with the app and privacy document; treating it as contradicted risks removing an accurate disclosure.
Useful? React with 👍 / 👎.
| | 3 | Lighthouse over every page type, not six (WEB-22), and a test that a failing page really turns the run red | S | | ||
| | 4 | Screenshots for the timeline stops and the tweak pages, from Screenshot Mode (WEB-11, 13) | M | | ||
| | 5 | The release workflow attaches `signing-certificate.txt` every time, so the fallback in WEB-4 is never used | S | | ||
| | 6 | Confirm the `site.yml` dispatch fires on the next real release (WEB-26) | S | |
There was a problem hiding this comment.
When FOLIO_SITE_TOKEN is absent, the reviewed .github/workflows/site.yml prints a notice and exits 0 without dispatching a rebuild. Merely confirming one token-backed release fires does not satisfy WEB-26 or prevent the exact silent-success regression described above; this gap needs to require changing that missing-token branch to fail.
Useful? React with 👍 / 👎.
…ifest check is the next gap
…SP exception, and two stale numbers
…er's code is handled
1 participant
Every standard in docs/standards covers the app. The site, the README and the help pages had rules too, but they lived in folio-site's check script, a CI file and habit.
What is true now:
Why now: the 1 Oct audit found the live site a release behind, a roadmap that would have listed unreleased work as shipped, a privacy claim about crash reports that PRIVACY.md contradicts, and a VirusTotal promise that 0.6.6, 0.6.7 and 0.6.7.3 did not keep. No rule said those had to be true.
Where it is honest about gaps: WEB-3 (claims match the documents) and WEB-7 (voice) are held by review until a check exists, and the gaps table ranks the seven things worth building. The numbers under "where Folio is today" are measurements from 1 and 2 Oct, from folio-site main.
Not done: this is a draft for McCal to edit. The rules about wording and what to hold to are McCal's call, and I have not run any of the proposed checks.