[finding] `rowColor.colors` is optional in the schema but required by the only renderer — `rowColor: { field }` alone is a parse-clean no-op

[os-warren]

Noticed while deciding how to colour list rows consistently with a status field (objectstack-ai/duly #12). Not blocking anything — we chose not to author rowColor at all — but it is an ADR-0078 functional-completeness shape that the existing rule family does not cover.

The shape

RowColorConfigSchema (spec/src/ui/view.zod.ts):

field: z.string().describe('Field to derive color from (typically a select/status field)'),
colors: z.record(z.string(), z.string()).optional().describe('Map of field value to color (hex/token)'),

field required, colors optional. The .describe() on field — "derive color from" — reads as though the derivation happens without a map, which is what a select field's own options[].color would let it do.

The grid renderer disagrees (plugin-grid, 17.2.0):

function qt(e){ return useCallback(t => {
 if (!e?.field || !e.colors) return; // ← both, or nothing
 let n = String(t[e.field] ?? ``), r = e.colors[n];
 if (r) return Kt(r);
}, [e?.field, e?.colors]) }

So rowColor: { field: 'status' } parses, publishes, and colours nothing. No error, no warning, no console message.

Why it belongs with the existing rules

This is the same family validateFunctionalCompleteness already gates: a summary with no summaryOperations, a lookup with no reference, a select with no options, a calendar with no calendar block. Every key is known, so #4001's unknown-key rejection cannot see it and the liveness ledger cannot either — which is precisely the gap that rule exists to fill.

Two ways to close it, and they are not equivalent

• A — gate it. Add view/row-color-without-colors (warning) to checkViewCompleteness: a rowColor with a field and no colors never colours a row. Cheap, matches the existing rules exactly.
• B — make the description true. Let the renderer fall back to the bound field's options[].color when colors is absent, the way plugin-timeline already resolves its colorField. This is the better outcome for the case the key is obviously for — colouring by a status select — because it removes the need to hand-copy the option colours into a second map that then drifts from the object. An author who copies them has two sources of truth for one palette.

If B, A is still worth keeping for the non-select case (a text or number field with no options has nothing to derive from).

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): graded → pm:queue · priority:p3 · domain:spec · type Task. finding removed.

Ruled route: A only. Add view/row-color-without-colors (warning) to checkViewCompleteness — the functional-completeness family in packages/spec/src/kernel/functional-completeness.ts, which is why this lands in the spec lane (same landing as #14106) — and tighten the .describe() on RowColorConfigSchema.field so it no longer reads as if derivation happens without a map. Rationale: this is exactly the ADR-0078 shape the rule family exists for (every key known, so neither #4001 nor the liveness ledger can see it), and a rowColor: { field } that parses, publishes and colours nothing is the silent half.

⛔ B (renderer falls back to the bound select's options[].color) is not in scope and is not filed: it is a renderer feature in objectui with one non-blocking mention as its pull (the reporter chose not to author rowColor at all), so it stays un-declared until a consumer asks; if one does, that is an objectui card, and A remains correct for every non-select field regardless. Not clause ② (author-time diagnostic; the schema's accept set does not move).

Size/model suggestion: S mechanical, sonnet; one positive fixture (field only ⇒ warning) and one negative (field + colors ⇒ silent).

---

Generated by Claude Code