Skip to content

feat(validator): say which profile produced the recommendations - #113

Merged
hhkaos merged 1 commit into
mainfrom
feat/105-d042-profile-version
Nov 4, 2026
Merged

hhkaos merged 1 commit into
mainfrom
feat/105-d042-profile-version

Conversation

@hhkaos

@hhkaos hhkaos commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

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:

Unmet spec recommendations (SHOULD). The document is still valid; these make it easier to find, filter and subscribe to.

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:

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 "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/validate change was needed. The assumption was that a profile version had to be exposed next to 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 the two 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, 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, not main.ts, so it is testable: per CONTRIBUTING.md this app's tests cover src/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, typecheck and 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.ico from the throwaway static server.

🤖 Generated with Claude Code

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]>
@hhkaos
hhkaos merged commit b07277e into main Nov 4, 2026
1 check passed
@hhkaos
hhkaos deleted the feat/105-d042-profile-version branch November 4, 2026 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant