Repository navigation
feat(validator): say which profile produced the recommendations - #113
Merged
Merged
Conversation
D042's second half, and the last app item on #101. A 1.0 will freeze validity — the schemas and the normative prose — and explicitly not the recommended profiles. So the set of warnings is not a stable interface, and the page that hands people that list was presenting it as if it were: Unmet spec recommendations (SHOULD). The document is still valid; these make it easier to find, filter and subscribe to. Nothing there says which rules produced the list, or that a later release can change it. Anyone scoring, badging or tracking this over time had no way to know what to pin. Now: Unmet recommendations from OTE 0.6.0's recommended profile (SHOULD). The document is still valid; these make it easier to find, filter and subscribe to. This list is not frozen the way validity is — a later release can add or drop recommendations — so pin the version if you score or badge on it. It names the version actually *checked*, not the one declared, so the version selector's "see what moving to 0.4 would change" names 0.4's profile. Two findings worth recording, both of which made this smaller than #101 assumed: **No `packages/validate` change was needed.** The guess was that a profile version had to be exposed alongside `recommendedProfileChecked`. There is no such number: each release ships its own profile (`v0.6/feed.recommended.schema.json`), so the version checked *is* the profile version. Inventing a second one would have implied they can drift apart. **The badge does not score on warnings**, so D042 does not reach it — `workers/validator/src/badge.ts` is keyed to validity, discovery and reachability only. Checked rather than assumed, as the rest of #101's app audit was. The sentence lives in `src/lib/report.ts` rather than `main.ts` so it is testable: per CONTRIBUTING.md this app's tests cover `src/lib/` and the UI is checked by hand. Verified in a browser as well as in tests: a valid feed with two unmet recommendations shows the 0.6.0 sentence, and overriding the selector to 0.4.0 reruns it as 0.4.0. 83 validator tests (5 new); lint, typecheck and the full suite green. Co-Authored-By: Claude Opus 5 <[email protected]>
This was referenced Nov 4, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
D042's second half, from #105 — and the last app item on #101.
A 1.0 will freeze validity (the schemas and the normative prose) and explicitly not the recommended profiles. So the set of warnings is not a stable interface — and the page that hands people that list was presenting it as if it were:
Nothing says which rules produced the list, or that a later release can change it. Anyone scoring, badging or tracking this over time had no way to know what to pin.
Now:
It names the version actually checked, not the one declared, so the version selector's "pick one to see what moving to it would change" names that version's profile too.
Two findings that made this smaller than #101 assumed
No
packages/validatechange was needed. The assumption was that a profile version had to be exposed next torecommendedProfileChecked. There is no such number — each release ships its own profile (v0.6/feed.recommended.schema.json), so the version checked is the profile version. Inventing a second one would have implied the two can drift apart.The badge does not score on warnings, so D042 does not reach it.
workers/validator/src/badge.tsis keyed to validity, discovery and reachability only. Checked rather than assumed, like the rest of #101's app audit — worth ticking off on the tracker rather than leaving as open scope.Where the code lives
The sentence is in
src/lib/report.ts, notmain.ts, so it is testable: per CONTRIBUTING.md this app's tests coversrc/lib/and the UI is checked by hand.Spec version
No spec-version change. The repo stays on OTE Spec 0.6.0.
Testing
83 validator tests (5 new);
pnpm lint,typecheckand the full suite green across the workspace.Checked in a browser too, since this is a rendered string: a valid feed with two unmet recommendations shows the 0.6.0 sentence, and switching the selector to 0.4.0 re-renders it as 0.4.0. No console errors beyond a missing
favicon.icofrom the throwaway static server.🤖 Generated with Claude Code