examples/app-showcase's task Grid view declares a rowColor block that colours nothing:
examples/app-showcase/src/ui/views/task.view.ts:231
rowColor: { field: 'priority' },RowColorConfigSchema requires field and leaves colors optional, and the only renderer that reads the block needs both: objectui plugin-grid's useRowColor.ts opens with if (!config?.field || !config.colors) return undefined;, so the row-className resolver returns before it reads a record. Every row in the showcase's Grid view renders in the default colour, while the metadata parses and publishes clean.
The showcase app exists to demonstrate the platform's capabilities, so a demonstrated capability that does not actually take effect is worth more here than elsewhere — this is the same shape ADR-0078's Phase 1 first run found in showcase_field_zoo.f_summary.
How this was found
The spec-side author-time diagnostic view/row-color-without-colors (added by PR for #14111 — that card is not addressed by this one and remains open on its own terms) names exactly this instance the next time os validate runs over the app. The diagnostic is a warning, so os build prints it as an advisory and still succeeds; no CI context turns red because of it.
Why it was not fixed in that PR
Adding the map is not mechanical: which colour each priority value should get is a design choice about the demo app, not a shape pinned by existing evidence. It also lands in a different tree (examples/) from the ruled spec-side change.
Suggested fix
Give the block a colors map keyed on the priority field's declared option values, or drop the rowColor block if the demo does not want row colouring:
rowColor: {
field: 'priority',
colors: { /* one entry per declared priority option value */ },
},Out of scope for this card
packages/lint/src/showcase-shape.fixtures.ts carries the same rowColor: { field: 'priority' } line, but that file is a deliberately frozen snapshot (its header records the 2026-08-13 maintainer ruling that it must not be re-synced with the live app). It is not part of this fix.
Generated by Claude Code
Generated by Claude Code
examples/app-showcase's task Grid view declares arowColorblock that colours nothing:examples/app-showcase/src/ui/views/task.view.ts:231RowColorConfigSchemarequiresfieldand leavescolorsoptional, and the only renderer that reads the block needs both: objectuiplugin-grid'suseRowColor.tsopens withif (!config?.field || !config.colors) return undefined;, so the row-className resolver returns before it reads a record. Every row in the showcase's Grid view renders in the default colour, while the metadata parses and publishes clean.The showcase app exists to demonstrate the platform's capabilities, so a demonstrated capability that does not actually take effect is worth more here than elsewhere — this is the same shape ADR-0078's Phase 1 first run found in
showcase_field_zoo.f_summary.How this was found
The spec-side author-time diagnostic
view/row-color-without-colors(added by PR for #14111 — that card is not addressed by this one and remains open on its own terms) names exactly this instance the next timeos validateruns over the app. The diagnostic is a warning, soos buildprints it as an advisory and still succeeds; no CI context turns red because of it.Why it was not fixed in that PR
Adding the map is not mechanical: which colour each
priorityvalue should get is a design choice about the demo app, not a shape pinned by existing evidence. It also lands in a different tree (examples/) from the ruled spec-side change.Suggested fix
Give the block a
colorsmap keyed on thepriorityfield's declared option values, or drop therowColorblock if the demo does not want row colouring:Out of scope for this card
packages/lint/src/showcase-shape.fixtures.tscarries the samerowColor: { field: 'priority' }line, but that file is a deliberately frozen snapshot (its header records the 2026-08-13 maintainer ruling that it must not be re-synced with the live app). It is not part of this fix.Generated by Claude Code
Generated by Claude Code