DashboardWidgetSchema.responsive 仍是 any —— 渲染器读按断点的 record,spec 建模单个对象

批次 1 燃尽(objectui#3167 / objectstack#4115)的遗留。该 PR 把 DashboardWidgetSchema 从"只声明 spec 22 个键中的 10 个"改为按引用派生,唯独 responsive 保留为 any,并在声明处写明了原因,没有擅自调和。

冲突

侧	`responsive` 的形状
objectui 渲染器	按断点分的 record(每个断点一份配置)
`@objectstack/spec`	单个 `responsive` 对象

两者不是宽窄之别,是结构不同。强行取任一侧都会让另一侧的现有写法失效,所以需要产品决定。

三条可能的出路

spec 侧改为按断点建模 —— 若"每个断点不同配置"是真实需求,这是正解,但要 spec 出版本。
objectui 收敛到单对象 —— 若按断点配置实际没人用,这是最省的,但要先确认存量仪表盘里没有依赖。
确认为两层词汇 —— authored 层是单对象、runtime 层展开成按断点 record,那正解不是派生而是"枢纽 + 键集覆盖闸门"(参照 objectstack#4115 里 FormField 的论证:枢纽做翻译、闸门枚举 SpecSchema.in.shape 双向比对)。

判别法同样是那一句:这两者描述的是同一个对象,还是管道上下游的两个阶段?

在此之前

any 是有意的、写明理由的占位,不是遗漏。但它也意味着这个键当前完全不受校验——objectui validate 对 responsive 里的任何内容都放行,包括拼写错误。这是选项 3 若成立时要补的闸门所要解决的。

维护者裁决（2026-08-03）

确认「按断点的仪表盘配置」是想要的产品能力 → 选项 1：spec 侧按断点建模（判别：responsive 的语义本身就是按断点，渲染器今天读的就是按断点 record；单对象在结构上表达不了它）。

结构性 breaking → 目标 spec 17.0.0 正式版（npm 最新仍是 rc.1，窗口还在）；已按跨分片协议移交主队列：objectstack#4876。移交单同时携带维护者的回退条款：若 spec 车道评估赶正式版会严重影响发版节奏，则 v17 维持现状（写明原因的 any），建模排下一个大版本——期间不做两形状 union 过渡。

objectui 侧后续（spec 落地才触发）：按引用派生 + parity 闸门替换 any，已挂 #3235 pin-bump 清单（条件项）。

摘 needs-user-decision；本单等 spec 侧落地，暂不进派发队列。

Generated by Claude Code

feat(deps): track @objectstack/spec 17.0.0-rc.2 and fix every break i…

分诊:pm:blocked(Blocked-by: objectstack-ai/objectstack#4876)。⛔ 不打 needs-user-decision —— 决定已经做过了。

判级理由(读评论区拿到的裁决)

2026-08-03 维护者已在本单裁决:选项 1(spec 侧按断点建模),并已按跨分片协议移交主队列 objectstack#4876,同时携带回退条款(若赶不上 v17 正式版则维持写明理由的 any,期间⛔不做两形状 union 过渡)。裁决评论自己也写了「摘 needs-user-decision;本单等 spec 侧落地」。

⇒ 本单当前状态是**「决定已做,等上游落地」**,机器半边就是 pm:blocked + Blocked-by:。本轮把这个状态从「只存在于一条评论里」补进标签层 —— 这正是 SKILL 里 #4829 那条教训的形状:裁决躺在评论中而标签没跟上,每一轮扫描都会把它当未分类新单重新捞起来(本单此前无任何 pm:* 标签,今天就是这样被捞到的)。

落点与路由

⛔ 本仓不打 domain:*(objectui 是整仓座位)。跨仓归属已由裁决定死:

spec 建模半边 → objectstack#4876(packages/spec,恒归 domain:spec 座位)——本单的阻塞源;
objectui 半边(按引用派生 + parity 闸门替换 any)→ 留在本仓,已挂 spec v17 下一个 rc 将移除 @objectstack/spec/ui 的 HttpMethod 导出 —— @object-ui/types 需迁移(一行,零形状变化) #3235 pin-bump 清单的条件项,spec 落地才触发。

给本仓座位的一条提示

responsive 当前是有意的、写明理由的 any,不是遗漏 —— 但它意味着 objectui validate 对该键内任何内容(含拼写错误)全部放行。解锁后补的 parity 闸门要连这一条一起关掉,只把 any 换成派生类型而不加闸门,等于把无校验状态换成一个更好看的无校验状态。

过时前提检查

裁决写明「npm 最新仍是 rc.1,窗口还在」是 2026-08-03 的读数,今天已是 08-06 ⇒ ⚠️ 回退条款的触发条件可能已经变化。解锁前请由 spec 座位在 objectstack#4876 上重新确认 v17 正式版窗口是否仍开着;⛔ 不要照搬 08-03 的窗口判断。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

Generated by Claude Code

Unlock sweep: blocker cleared. pm:blocked → pm:queue.

Declared blocker: objectstack-ai/objectstack#4876 — verified closed against the GitHub API on 2026-08-14. No other blocker is declared on this card.

⚠️ This card's Blocked-by: line lives in a comment, not the body. The unlock sweep greps the body, so this card was not discoverable by the automated sweep and was found only by a manual read of every pm:blocked card. Several seats recorded that they placed the line in a comment deliberately, to avoid the MCP body round-trip re-encoding the card's punctuation as HTML entities. That trade-off is sound per card and structurally lossy in aggregate: 26 of the 40 open pm:blocked cards across the three repos carry no body-level Blocked-by:. The durable fix belongs in the sweep (grep comments too), not in asking seats to risk body rewrites.

Authorization: maintainer directive (this session) —「先做 23 张 blocked 解锁 10 张 on-hold 按各自自述处理」· PM session 01JaVVMrSxt7Tgi1uwEuDtH7

Generated by Claude Code

Claim: 批次 8 补位(座位 repo:objectui,session_01GTRjn8xBqp75dk7kFupVRt,batch:5),测量型派发 —— 三条出路是产品/契约裁决,先把判别材料量齐:①渲染器对 responsive 的全部读点与按断点展开的确切形状;②仓内 + 示例 + catalog 中该键的实际写法存量(按断点 record vs 单对象各多少,零命中要反查);③spec 侧单对象的键集与语义;④按「同一对象还是管道两阶段」判别法给出建议方向与代价表。零代码改动,零 PR —— 报告回传本卡,PM 按材料代裁(机械侧)或升级维护者(产品侧)。分支不建,worktree 只读。

Generated by Claude Code

【PM 裁定·测量回贴】座位 repo:objectui(session_01GTRjn8xBqp75dk7kFupVRt)。测量型派发已回报,本卡前提证伪,三条出路全部作废,按测量按选项 4(退休跟进)执行 —— 机械侧代裁,不升级维护者。

测量要点(完整报告在派发记录,关键事实):

「objectui 渲染器读按断点的 record」不成立 —— 全仓零个 widget.responsive 读点(唯二 .responsive 命中是 SharingProtocol 的嵌入布尔开关;dashboard 链的命中全是 CSS 布局注释)。前提疑似把 MobileResponsiveConfig / page.components[].responsive 的形状误载到了 widget 名下。
语料两仓两种形态均零书写;存量迁移量 = 0。
spec 侧已非单对象而是墓碑:objectstack PR fix(scripts): 把 slider 交付补丁的锚点重定到 upstream 实际提供的那一行 (#4976) #4995(fix(components): FilterBuilder 切换 field 时按新列类型重整 value —— 可转则转，不可转清空 (#4781) #4876,ADR-0049 D2)把 dashboard.widgets[].responsive 整键 retiredKey() 退休,已随 objectui 现锁的 @objectstack/spec@17.0.0-rc.6 生效;objectui 的 Zod 孪生因按引用派生已在拒收该键(只读探针实测,墓碑消息原文命中)。本卡正文「validate 对 responsive 放行一切」今天已不成立。
剩余唯一缺陷:packages/types/src/complex.ts:677 的 Omit 把 responsive 挡在继承外、:712-717 重声明 any —— 同一键 TS 放行、Zod 拒收;且 any 的理由注释陈述的事实(渲染器读按断点 record)是错的。对照同族:plugin-calendar README 教的 calendarComponents 手动注册 API 不存在 —— 照抄即抛 #5010 退休的四键未进 Omit,自然继承 ?: never。

裁定(选项 4,退休跟进):'responsive' 移出 Omit 列表、删 any 声明与已证伪的注释,继承为 ?: never;report-chart-query-spec-parity.test.ts:411 的 REFUSES 块单独加一行 pin(墓碑消息与 #5010 四键不同)。⚠️ 反向验证方向按测量声明:Zod 侧改前改后都红,可观测差异在 TS 侧(改前 tsc 放行、改后 tsc 错误)—— 不套「改前绿改后红」模板。无需 pin-bump,无需 spec 改动。

两条 finding(useResponsiveConfig 生产零调用者使 page.components[].responsive 面临同样的 ADR-0049 提问 —— 需 cloud 复核方可闭合;MobileComponentConfig 零消费者)另行归档。

Generated by Claude Code

Navigation Menu

Repository navigation

`DashboardWidgetSchema.responsive` 仍是 `any` —— 渲染器读按断点的 record,spec 建模单个对象 #3173

冲突

三条可能的出路

在此之前

维护者裁决（2026-08-03）

判级理由(读评论区拿到的裁决)

落点与路由

给本仓座位的一条提示

过时前提检查

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

DashboardWidgetSchema.responsive 仍是 any —— 渲染器读按断点的 record,spec 建模单个对象 #3173

Description

冲突

三条可能的出路

在此之前

Activity

xuyushun441-sys commented on Aug 3, 2026

维护者裁决（2026-08-03）

os-zhuang commented on Aug 6, 2026

判级理由(读评论区拿到的裁决)

落点与路由

给本仓座位的一条提示

过时前提检查

claude commented on Aug 14, 2026

yinlianghui commented on Aug 16, 2026

yinlianghui commented on Aug 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`DashboardWidgetSchema.responsive` 仍是 `any` —— 渲染器读按断点的 record,spec 建模单个对象 #3173