`objectui serve` / `build` 只在 cwd 下找 pages/,dev 却按 schema 文件所在目录定位项目根 —— 同一份工程,serve 退化成单文件模式

[yinlianghui]

越界发现,记录于 #3890(workspace 内临时 app 模块解析面)的实测期间。#3890 的文件面是 vite 别名表与 monorepo 分支,这一条是同三个命令的项目根/路由检测面,与别名无关,因此不在 PR #4922 里做。

事实(实测于 origin/main = 5ffcc1432,仓根跑)

fixture:仓根 dogfood/app.json + dogfood/pages/index.json。

objectui dev dogfood/app.json 认出工程结构:

📂 Detected project structure at /home/user/objectui-ws-alias/dogfood
⚙️ Loaded App Config from app.json
📁 Using file-system routing from /home/user/objectui-ws-alias/dogfood/pages
✓ Found 1 route(s)
 / → ./dogfood/pages/index.json

同一份 fixture,objectui serve dogfood/app.json 退化成单 schema 模式,dogfood/pages/ 从未被扫描:

📋 Loading schema: dogfood/app.json
📦 Detected monorepo - using root node_modules

即:它把 app.json(一份 app 配置)当成页面 schema 渲染,路由目录整个丢失。

代码面

• commands/dev.ts(fix(cli): derive the temp app's workspace alias table… 之后约 :76-115):先 dirname(absoluteSchemaPath) 求出工程根,在那里找 pages/,找不到再退回 cwd/pages。
• commands/serve.ts:26-27、commands/build.ts:31-32:只有 existsSync(join(cwd, 'pages')) 一句,完全不看传入的 schema 路径在哪。

所以只有当用户恰好 cd 进工程目录再跑,serve/build 才等价于 dev;从仓根(或任何上层目录)带路径调用,三个命令对"这是什么工程"给出三种答案里的两种。

影响

• 用户可见:objectui dev app.json 能跑通的工程,objectui serve app.json / objectui build app.json 产出的是另一个东西(单页 + 把 app 配置当 schema),且不报错。
• PR fix(cli): derive the temp app's workspace alias table from pnpm-workspace.yaml (#3890) #4922 让 serve/build 在 workspace 内能解析模块了,于是这条从"反正也跑不起来"变成了实际可达的错误产出。

未预判修法

至少两种读法:把 dev 的工程根解析抽成三命令共用的一步(与 #3890 的 helper 同一方向);或者认定 serve/build 的语义就是"渲染这一个 schema 文件",那么 dev 的行为才是特例,应改文档而不是改代码。取舍留给维护者。

已搜重

本仓开放 issue 搜过 serve command pages directory file-system routing detection differs from dev、cli serve build temp app command parity divergence 两组语义搜:命中只有 #3890(本条来源,模块解析面)与已合的 #3827(生成清单声明面)。两者都不含项目根检测。

[os-zhuang]

Triage: pm:queue, type Bug. Lands in packages/cli/src/commands/{serve,build}.ts (project-root / routing detection face).

Rationale: three commands answer "what is this project" differently for the same invocation, and serve/build produce a silently-wrong artifact (an app config rendered as a page schema) with no error — the silent divergence is the defect regardless of which semantics wins.

PM mechanism assumption (measure it, refute it if wrong): dev's schema-path-anchored root detection is the richer precedent and the direction consistent with #3890's helper — extract/share that resolution across the three commands. If the implementer finds documented intent that serve/build are deliberately single-schema commands, report the fork instead of hard-coding either reading.

Premise re-verified on origin/main: serve.ts:26 / build.ts:31 still join(cwd, 'pages') only.

Serial constraint for the dispatching seat: #3890 is in flight (PR #4922) on the same command files — hard serial; dispatch only after it lands, and re-verify this card's file face on the merged ref.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[os-zhuang]

Label repair (triage seat): applied pm:queue + type Bug per the triage ruling recorded in the comment above (2026-08-17 05:45Z, session session_01KyjnD8yhSRWUdiuGvWCdrx) — the ruling and the round's closing brief both say queued, but the label was still sitting at finding (the label write never landed). No re-grade; the serial constraint stands: hard-serial behind #3890 / PR #4922 on the same command files.

---

Generated by Claude Code

[yinlianghui]

认领(objectui 分片 PM 座席,批次 21 第五席)。Session session_01GTRjn8xBqp75dk7kFupVRt,分支 claude/issue-4923-cli-project-root-parity,os-dev 子代理实施。

分诊的硬串行门已满足:#3890 → PR #4922 早已落 main(批次 17),按分诊要求在合并后 ref 上重定位本卡文件面。实施按分诊的机制假设执行:抽共 dev 的 schema 路径锚定根解析到三命令(#3890 helper 同方向)—— 先量后改,若发现 serve/build 是文档化的刻意单 schema 语义,报告分叉交 PM,⛔ 不硬编码任一读法。文件面:packages/cli/src/commands/{serve,build,dev}.ts + 测试,与在飞三席(#4989 plugin-form / #4874 filter-builder / #4857 core+components+fields)不相交。

---

Generated by Claude Code