Uh oh!
There was an error while loading. Please reload this page.
fix(app-shell): correct two PALETTE_EXCLUSIONS reasons that claimed "no renderer" - #6283
Merged
Merged
Conversation
…no renderer" `element:text_input` and `element:record_picker` are registered renderers (`namespace: 'element'`), so the leading "no renderer" clause in their exclusion reasons was false. The exclusions themselves are decisions and are unchanged; only the stated rationale moves to the true one, which the substantive half of each string already carried. Adds `exclusion-reason-truthfulness.test.ts`, which pins the class: any exclusion whose reason claims "no renderer" must not have a registered one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L
…releasing nothing The reason strings are developer-facing ledger prose read by no runtime code path, so this declares an empty frontmatter — the exemption check-changeset-presence names explicitly, not a workaround. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
This was referenced Aug 25, 2026
os-litant
marked this pull request as ready for review
August 25, 2026 09:38
Uh oh!
There was an error while loading. Please reload this page.
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 freeto 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.
Fixes#6071
What changed
PALETTE_EXCLUSIONSin the Studio page-palette ledger opened two entries with "no renderer" forelement:text_inputandelement:record_picker. Both types do have a registered renderer undernamespace: 'element'(components/renderers/basic/text-input.tsx:161,components/renderers/basic/record-picker.tsx:303), so the leading clause was simply false.⛔ The exclusions themselves are unchanged. They are still the right decisions and still stand. Only the false leading clause moved; the substantive half — record picking is a field widget / bare inputs belong to a form — was correct all along and is kept verbatim. The new wording says why they are excluded truthfully: they render, they are just not page content.
Why a false reason string is worth a PR
This ledger was made explicit (#2943) so a palette decision is recorded where the next reader finds it, and it is read as the decision record. #5837 had to re-derive registration state from source precisely because the stated reason could not be trusted.
core/src/registry/public-blocks.tsalready words these same two exclusions without any renderer claim, so the ledger was also internally inconsistent.block-config.test.tsenforced that every exclusion carries a reason (reason.length > 10). Nothing enforced that the reason is true.The pin, and why it is shaped this way
exclusion-reason-truthfulness.test.tspins the class, not the two strings: an exclusion whose reason claims "no renderer" must not have one. The class assertion is the cheap thing to get wrong, so it carries three explicit guards:ComponentRegistry.get(...)isundefinedfor everything and the negative assertion holds vacuously — a green that measures nothing. Each side-effect import therefore carries a positive probe proving that package's registrations actually ran.A fourth assertion pins the opposite direction: the two corrected entries do have renderers, so if a later change unregistered them their new wording would become false the other way.
Release impact
None. The changeset carries empty frontmatter — the repo's "releases nothing" declaration. The reason strings are developer-facing ledger prose read by no runtime code path, and no exclusion decision moved.
Provenance
domain:uiseat PM (session_01Mn4BZ5AVDM81pvfij1WwM9), not by the agent that wrote the branch. The two commits were pushed by a dev under the previous seat, whose session ended before the PR was opened; the seat changed hands on a maintainer forced-handover. The dispatch ruling that authorised this shape, and the dev's report, are posted on #6071 alongside this PR — they had until now existed only inside the previous session.🤖 Generated with Claude Code
Generated by Claude Code