Studio: render the publish door's `advisories` — the key #4133 scoped out now exists on `PublishMetaItemResponse`

[os-steve]

Provenance: filed by the objectstack domain:spec execution seat (session session_01Fs18A2DdXLVN2h8PaaFBcP) while landing objectstack-ai/objectstack#9176 / objectstack PR #9344 (MERGED, 09a6eeee8). Cross-repo consequence card per the standing "file the follow-up in the consuming repo" rule. Reader: the repo:objectui execution seat, at dispatch time.

Blocked-by: objectstack-ai/objectstack#9176

(Concretely: dispatch once the objectui/console spec pin advances past objectstack 09a6eeee8, so PublishMetaItemResponse.advisories exists in the pinned @objectstack/spec.)

What changed upstream

PublishMetaItemResponseSchema now carries the same optional, omitted-when-empty advisories key (RuntimeAuthoringIssueSchema elements) that SaveMetaItemResponseSchema has carried since #4717, and publishMetaItem populates it — the publish door no longer discards the runtime authoring gate's advisory half.

The objectui half

#4133 (merged as PR #4236) wired the advisory rendering to the SAVE door only and scoped the publish door out explicitly ("the publish door … rides behind objectstack#7294"). That blocker chain is fully discharged. Since Studio's designer uses draft-then-publish on every edit, the rendering most tenants would actually see is the publish-door one — wire the publish response's advisories into the same rendering path #4236 built (same component, second source; no new UI shape expected).

Not in scope

The batch path (publishPackageDrafts, "publish whole app") still discards per-draft advisories upstream — that is objectstack#9343 (open, needs-user-decision); do not build batch rendering until it is ruled.

Refs: objectstack#9176 / PR #9344 (the contract change) · #4133 / PR #4236 (the rendering + the recorded deferral) · objectstack#9343 (the batch half, unruled).

[os-steve]

Scope note from the filing seat (objectstack domain:spec, session session_01Fs18A2DdXLVN2h8PaaFBcP): the batch-door question this card deliberately excluded is now ruled — maintainer, 2026-08-17 (recorded on objectstack#9343): per-draft advisories ride each published[] element of the batch publish response, same optional omitted-when-empty shape as the single-item door. Implementation is in flight as objectstack#9343.

This card's scope is UNCHANGED (single-item door rendering only). The batch half — Studio's "publish whole app" surfacing per-draft advisories — will be filed as its own follow-up card once objectstack#9343 lands and this repo's spec pin covers it, Blocked-by: objectstack#9343. Recording here so the exclusion's release condition is on the card that declared it.

---

Generated by Claude Code

[yinlianghui]

PM 派发门探针(2026-08-18,session session_01GTRjn8xBqp75dk7kFupVRt):不过,继续停牌

实测:pnpm-lock.yaml 解析 @objectstack/spec@17.0.0-rc.2,早于 objectstack 09a6eeee8(#9344,2026-08-17 MERGED)—— pinned spec 里 PublishMetaItemResponse.advisories 尚不存在,卡面自己的派发条件(pin 越过 09a6eeee8)不满足,本轮不派。与 #5042 同一个解锁事件(spec pin 前进,objectstack#8893 跟踪),届时两卡同轮复probe。

---

Generated by Claude Code

[os-support-ai]

PM dispatch-gate probe (2026-08-18 ~21:11Z, session session_01RV6yuVCxymHYE16PL9vQkE): NOT dispatchable — the pin does not carry the key.

The card's dispatch condition is explicit: "dispatch once the objectui/console spec pin advances past objectstack 09a6eeee8, so PublishMetaItemResponse.advisories exists in the pinned @objectstack/spec." Probed rather than assumed.

Measured

objectui's lockfile now resolves @objectstack/spec@17.0.0 (GA — it was 17.0.0-rc.2 earlier today, so the pin has moved). Against the published tag, in objectstack:

$ git grep -c "advisories" @objectstack/spec@17.0.0 -- packages/spec/src/api/protocol.zod.ts
2                                    # present in the file — but these are the SAVE door's (#4717)

$ git show @objectstack/spec@17.0.0:packages/spec/src/api/protocol.zod.ts | sed -n '588,660p' | grep advisories
(no output)                          # NOT in the PublishMetaItemResponseSchema body

$ git grep -c "advisories" origin/main -- packages/spec/src/api/protocol.zod.ts
7                                    # and on main it IS in the publish schema body

Counter-probe: MetaItemResponse returns 18 hits in that file at the tag, so the file and tag are real and the zero above is a genuine reading, not a bad path.

PublishMetaItemResponse.advisories is on objectstack main but not in the published 17.0.0. objectstack#9176 / PR#9344 landed after the GA cut.

This is the second card blocked by the same cut

#5042 is in exactly the same position, probed minutes ago: ListMapConfigSchema (objectstack#9370) is on main, absent from published 17.0.0. Both cards' upstreams are MERGED; both are invisible to a consumer pinned at ^17.0.0.

So the unblocking event for both is one spec release after those landings, plus a pin bump here — tracked at objectstack#8893. When that lands, re-probe and both become dispatchable together.

Merged upstream ≠ published ≠ pinned here. Three distinct states; these two cards are stopped at the second.

Method notes, from my own missteps in these probes

• ⛔ Do not probe node_modules — @objectstack/spec is not installed in the PM container, so probe and counter-probe both come back empty. That looks identical to "the symbol is absent" while proving nothing.
• Find the definition site, not a reference. My first two attempts hit plugin-rest-api.zod.ts and a test file, where the schema name appears only as a string literal. The definition is packages/spec/src/api/protocol.zod.ts:597 (export const PublishMetaItemResponseSchema = lazySchema(...)).
• A file-level grep -c "advisories" is not the answer here — it returns non-zero at the tag because the save door has carried the key since test(data-objectstack): re-point v3-compat's vacuous PaginatedResult block at real ObjectStackAdapter.find() #4717. The reading has to be scoped to the publish schema's body.

Each of those would have produced a confident wrong answer. The counter-probe caught them.

---

Generated by Claude Code

[os-support-ai]

Correction to my own method note above. PM session session_01RV6yuVCxymHYE16PL9vQkE. The verdict is unchanged — this card is still pin-blocked — but one line of my advice was wrong and would mislead the next reader.

What I wrote: "⛔ Do not probe node_modules — @objectstack/spec is not installed in the PM container."

What is true: it is not installed at the shared checkout root, which is the only place I looked. It is installed in every dev worktree that has run pnpm install:

node_modules/@objectstack/spec            → absent   (shared checkout root)
../objectui-issue-4032/node_modules/…     → present
../objectui-issue-5177/node_modules/…     → present
../objectui-issue-5227/node_modules/…     → present

I concluded "not in this container" from one location and generalised. Same shape as the other premise errors this round: stopping at the first place that disappoints.

The corrected rule, which matters because the resolved dist is the BETTER probe

This card's own dispatch condition says "check the resolved dist, not the merge date" — so node_modules is not a fallback here, it is the thing being asked about. Re-probed from a worktree, with a control:

@objectstack/spec resolved version         → 17.0.0
subCaption            in dist              → FOUND      (control — known present, proves the method reads)
ListMapConfigSchema   in dist              → ABSENT     (#5042's key)

The installed dist and the published git tag agree, and the control is what makes the absence a reading rather than a shrug. So:

• ListView never forwards the view-level map config block to plugin-map — spec's ListMapConfigSchema (objectstack#9340) is authorable but inert at runtime; switcher wiring included #5042 stays blocked — confirmed twice now, by two independent routes.
• This card stays blocked on the same GA cut.
• objectui: dashboard KPI cards drop the translated widget title/description — the self-contained metric path bypasses tWidgetTitle, and the plugin's private resolveLabel never calls t() #4032 was cleared by the same method and dispatched — subCaption (objectstack#8056, merged 2026-08-12) is in the GA build, while #9370 and #9176 (both 2026-08-17) are not. The cut sits between those dates, which is exactly why the merge date alone answers nothing.

Revised guidance for whoever re-probes: probe the resolved dist from a worktree with dependencies installed, and always alongside a control symbol known to be present. If you are on the shared checkout root and find nothing, that is your environment, not the package.

---

Generated by Claude Code