Repository navigation
feat(l0): flag text that cannot follow a theme - #6
Merged
Merged
Conversation
ymote
force-pushed
the
feat/theme-portability-lint
branch
2 times, most recently
from
August 30, 2026 05:47
0284d03 to
d98d217
Compare
An emoji is painted from the colour font with its colours baked in, so `draw_text.color` never reaches it. A card that uses one as an icon renders correctly under exactly the polarity its author had on screen, and is invisible under the other — white plates on cream, in the case that surfaced it. This cost real measurement time to find. Four separate judge verdicts said "white icons vanish on cream" while an experiment assumed the palette was at fault and spent two rounds tuning it; the icons were never icon widgets, they were `TextRow(text: "🍽")`, and no palette can tint them. `UiL0Report` gains a `lints` channel, separate from `diagnostics` on purpose: a lint that could refuse a card would be a rule, and this is not a rule. The card is valid and will realize. It is just not portable, and nothing else in the pipeline can tell you so. Swept over the 967-card corpus it flags 81 cards and 138 glyphs — mostly 🌳, ☕ and 🍽 standing in for icons — and refuses none of them. Latin, CJK, accents, em dashes and ellipses are monochrome and carry no lint. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ymote
force-pushed
the
feat/theme-portability-lint
branch
from
August 30, 2026 06:06
d98d217 to
4e6e755
Compare
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.
An emoji is painted from the colour font with its colours baked in, so
draw_text.colornever reaches it. A card using one as an icon renders correctly under exactly the polarity its author had on screen, and is invisible under the other.How this surfaced
Four separate blind judge verdicts said "white icons vanish on cream" during a palette-transfer experiment. Two rounds were spent tuning the palette on the assumption it was at fault. The icons were never icon widgets — they were:
No palette can tint that. The experiment was measuring a defect it could not fix.
What's added
UiL0Reportgains alintschannel, separate fromdiagnosticson purpose: a lint that could refuse a card would be a rule, and this is not a rule. The card is valid and will realize — it just isn't portable, and nothing else in the pipeline can say so.Only the pictographic blocks are swept (plus U+FE0F, the "render in colour" selector). Latin, CJK, accents, em dashes and ellipses are monochrome and take the theme's ink correctly.
Measured on the corpus
🌳(44),☕(43),🍽(27)Two tests: an emoji card is flagged but stays valid; ordinary Latin/CJK/accented text carries no lint.
examples/lint_check.rsruns it over any set of cards.Note: 3 pre-existing failures in
tests/profile.rs(catalog/TOML drift) are unrelated and present onmainbefore this change.🤖 Generated with Claude Code