[P0] Studio package publish accepts a dangling `highlightFields` reference — the authoring gate never sees what the app builder produces

[yinlianghui]

Finding from the promo-video lane (steedos-labs/video-studio#5, "Studio modeling — clicked changes pass the same gate as code"). Filed as a finding only; not claiming it. Blocks promo video https://github.com/steedos-labs/video-studio/issues/5 — the film's one claim is "a change made by clicking in Studio is refused by the same gate that refuses code", and on the pinned stack there is nothing Studio can produce that the gate refuses.

Measured (hotcrm main @ 5e08628, @objectstack/* 17.2.0, console Studio; dev server, then snapshot-restored — zero residue)

1. In a writable package (New package (writable base)), click-create an object, then a Number field. The field starts as API name field_10 / label New field.
2. In the object's Settings, add that field to Highlight fields (highlightFields) — default list columns… via + Add field… → the list now references field_10.
3. Back on the Form, set the label to Health Score → the API name auto-derives to health_score. highlightFields still says field_10. A dangling reference, produced purely by clicking in the natural order (name the field after placing it).
4. Publish: POST /api/v1/packages/<pkg>/publish-drafts → HTTP 200, outcome:"published", failedCount:0, probes:{"issues":[],"checked":{"seeds":0,"views":0,"widgets":0}}. UI shows Published all drafts in this package (one atomic release).
5. After publish highlightFields is still ["field_10"]; the app's list renders without any error — the bad reference is silently ignored at runtime.

Why the gate stays quiet

list-view-field-unknown (error-level, in AUTHORING_RULES) checks view.columns. The Studio app builder does not mint view items at all — GET /api/v1/meta/view lists 89 views, 0 belonging to the new package — and highlightFields is an object-level property that probes.checked does not cover (views:0). So the reference-integrity rule has nothing to inspect on the only artifacts Studio authors. The same stack's objectstack validate would presumably flag a code-authored object with an unknown highlightFields entry, which is exactly the asymmetry the video was supposed to deny.

Minimal capability the film needs (no wish list)

Publishing a Studio draft whose highlightFields (or any field-name list on an object) names a field that does not exist on that object must fail the publish with a rule id and the offending path on screen — the same rule family that objectstack validate applies to code-authored objects. Warning-level is not enough for the claim; it has to refuse.

Also observed, for context (by design, not the ask)

Code-loaded package objects are read-only in Studio (object.supportsOverlay=false, PUT /api/v1/meta/object/crm_opportunity → 403 NOT_OVERRIDABLE for crm_opportunity / crm_campaign / crm_case), per ADR-0005/0010. The video's original scene ("add a field to Opportunities") is therefore not filmable on hotcrm; the writable-package route above was the fallback, and it is where this finding came from.

Related: objectstack-ai/objectui#2260 (Studio field API-name derivation) and the follow-up filed alongside this one in objectui.

[os-zhuang]

Triage: cross-lane — domain:devx designated as the claiming lane, one PR. pm:queue · Bug · priority:p0 retained.

Triage seat, session session_01SwJQDFKe8tVit3BXQ9EfR5, R+145, 2026-09-04T18:50Z.

⚠️ This card sat 11 hours carrying priority:p0 and nothing else — no domain:*, no pm:* state, no assignee. ⇒ It was invisible to every lane's candidate query and unclaimable under the lane table, because domain:* has one producer. A p0 that no seat can see is a p0 that nobody is working on. Recorded as a process failure, not as a criticism of the filer, who correctly left routing to triage.

Landing points, read on origin/main at 18:48Z

half	file	lane
the rule family (list-view-field-unknown)	packages/lint/src/validate-list-view-field-refs.ts	domain:devx
the roster it is wired through	packages/lint/src/authoring-rules.ts	domain:devx
the publish probe (probes.checked)	packages/metadata-protocol/src/protocol.ts	domain:engine

domain:devx claims it. The substantive half is defining what "a field-name list on an object" is and which keys belong to it — that is lint's, and the family already lives there. The metadata-protocol limb is wiring the probe to run it over objects, which probes.checked does not cover today ({seeds:0, views:0, widgets:0} — no objects key at all).

Per the cross-domain path: declare the full file surface across both lanes in the claim, and run the directed in-flight check against domain:engine's claims before claiming.

Why the gate is silent — the card's diagnosis, and it is the whole fix

list-view-field-unknown inspects view.columns. The Studio app builder mints no view items at all — GET /api/v1/meta/view returned 89 views, 0 belonging to the new package — and highlightFields is an object-level property the probes do not cover.

⇒ The reference-integrity rule has nothing to inspect on the only artifacts Studio authors. ⛔ Not a rule that missed a case; a rule pointed at a surface the click-path never produces.

The acceptance bar, quoted because "warning" will not do

Publishing a Studio draft whose highlightFields (or any field-name list on an object) names a field that does not exist on that object must fail the publish with a rule id and the offending path on screen … Warning-level is not enough for the claim; it has to refuse.

⭐ And the reproduction is a click-path in the natural order, not a contrived one: place the field, then name it. The API name auto-derives from the label (field_10 → health_score) while highlightFields keeps the old id. ⇒ Any author who names a field after placing it produces this.

priority:p0 retained, with the reasoning made explicit

The filer named a concrete blocked deliverable (the promo video's single claim: "a change made by clicking in Studio is refused by the same gate that refuses code"), and on the pinned stack there is nothing Studio can produce that the gate refuses. ⛔ Triage does not downgrade a p0 filed against a named external blocker on its own reading.

⚠️ Worth stating separately for the maintainer, because it outlives the video: the asymmetry itself is the defect. objectstack validate would flag a code-authored object with an unknown highlightFields entry; the click path publishes it green and the app then silently ignores the bad reference at runtime. That is declared-not-enforced on the authoring surface AI and humans share.

⛔ Out of scope, and by design: code-loaded package objects are read-only in Studio (supportsOverlay=false, 403 NOT_OVERRIDABLE) per ADR-0005/0010. ⛔ Do not treat that as part of this card.

⚠️ Measured on hotcrm main @ 5e08628 with @objectstack/* 17.2.0 — an installed pin, not this tree. Re-verify the probe shape and the rule's scan surface on origin/main before implementing.

---

Generated by Claude Code

[claude]

Claim: PM seat domain:devx @ objectstack (#6023), session session_012zGPuVVX3deAx9LdjK8jCk, dispatching to an os-dev subagent on branch claude/issue-15254-studio-highlight-fields-refusal. P0, cross-lane with domain:devx designated (triage 15:30Z): file surface declared across both lanes — packages/lint/src/validate-list-view-field-refs.ts, packages/lint/src/authoring-rules.ts (devx) and packages/metadata-protocol/src/protocol.ts (engine, the publish probe). Directed in-flight check against domain:engine: open draft PR #15395 (#14147, needs:contract-review, human-gated) edits protocol.ts +65/−275 — this PR keeps its protocol.ts hunk minimal and additive (the objects probe wiring only) and merges main if #15395 lands first; no other open PR touches the three files. Main at f01adfa5c. Assignee field was empty at the read immediately before this write.

---

Generated by Claude Code