You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] the JSX page gate looks for the project's sdui.manifest.json in the invoker's cwd, not beside the config the command was given: os validate path/to/objectstack.config.ts from elsewhere never reads that project's manifest #20166
Filing gate: ① a defect with a named landing site, packages/cli/src/utils/sdui-manifest.tsresolveSduiManifest. Finding class (a), with reach: measured at a public door (os validate given an explicit config path).
Found by the os-dev round on #20113 (PR #20164) and verified at source and filed by the domain:cli execution seat (#6024, session_01UYBdGBzWSrAMzpW8ah3GbP). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.
What happens (measured)
The dev measured on PR #20164's head 08a046af: os validate /path/to/project/objectstack.config.ts, run from a different directory, exits 0. The JSX page gate runs at parse level, and its new notice names CWD/sdui.manifest.json. The project's own sdui.manifest.json beside that config is never read. On main before PR #20164 the same run was silent.
The seat's reading at source (origin/main9401b842)
resolveSduiManifest() joins process.cwd() with sdui.manifest.json.
The same command locates everything else about the project from the config's directory. For example, validate.ts passes projectDir: dirname(absolutePath) to its capability preflight.
⇒ Two lookup roots in one command: the manifest follows the invoker's cwd, and the rest follows the config.
os build and os lint share the resolver.
Why it is not a mechanical fix
This repository tracks a sdui.manifest.json at its ROOT, and none in examples/app-showcase. Today a repo-root invocation against the showcase config resolves that root manifest. That is the arming measured on #19922, where the manifest's missing html-tier vocabulary turns the showcase from exit 0 to exit 1 with 200 errors. Moving the lookup to the config's directory changes which manifest that invocation resolves. So the fix has to be sequenced with the decision #20112 and with #19922, which will next change this resolver. ⛔ This card does not presume the order.
Who acts
The domain:cli execution seat, on the same file as #19922 (currently pm:blocked on #20112). PR #20164 (#20113) is in flight on that file now, so this card waits behind it.
Dedupe
MCP issue search in this repository, open and closed, run 2026-09-27:
Filing gate: ① a defect with a named landing site,
packages/cli/src/utils/sdui-manifest.tsresolveSduiManifest. Finding class (a), withreach:measured at a public door (os validategiven an explicit config path).Found by the
os-devround on #20113 (PR #20164) and verified at source and filed by thedomain:cliexecution seat (#6024,session_01UYBdGBzWSrAMzpW8ah3GbP). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.What happens (measured)
The dev measured on PR #20164's head
08a046af:os validate /path/to/project/objectstack.config.ts, run from a different directory, exits 0. The JSX page gate runs at parse level, and its new notice namesCWD/sdui.manifest.json. The project's ownsdui.manifest.jsonbeside that config is never read. Onmainbefore PR #20164 the same run was silent.The seat's reading at source (
origin/main9401b842)resolveSduiManifest()joinsprocess.cwd()withsdui.manifest.json.validate.tspassesprojectDir: dirname(absolutePath)to its capability preflight.os buildandos lintshare the resolver.Why it is not a mechanical fix
This repository tracks a
sdui.manifest.jsonat its ROOT, and none inexamples/app-showcase. Today a repo-root invocation against the showcase config resolves that root manifest. That is the arming measured on #19922, where the manifest's missing html-tier vocabulary turns the showcase from exit 0 to exit 1 with 200 errors. Moving the lookup to the config's directory changes which manifest that invocation resolves. So the fix has to be sequenced with the decision #20112 and with #19922, which will next change this resolver. ⛔ This card does not presume the order.Who acts
The
domain:cliexecution seat, on the same file as #19922 (currentlypm:blockedon #20112). PR #20164 (#20113) is in flight on that file now, so this card waits behind it.Dedupe
MCP issue search in this repository, open and closed, run 2026-09-27:
sdui.manifest.json resolved from process.cwd instead of config directory os validate explicit config path→ 5 hits: [finding] the CLI's@objectstack/consolemanifest fallback can never resolve:resolveSduiManifest()asks for@objectstack/console/dist/sdui.manifest.json, but the console'sexportsmap publishes only./package.json#19922 (open, the console leg; a different defect in the same resolver), [finding] the trackedsdui.manifest.jsonhas noobject-treeentry althoughplugin-treeregisters the renderer — the newobject-treespec row gets no parity comparison at all #18407, scripts/gen-sdui-manifest.sh cannot run twice on macOS — its mktemp templates put the X's before a suffix, which BSD mktemp takes literally #15182, [finding]pnpm sdui:manifestdies with ENOENT whenpackages/console/dist/does not exist — the ratchet's only trigger cannot run before a successful console build #10138 and sdui.manifest.json 的来源未定:声明一致性 ratchet 目前只在手工pnpm sdui:manifest时跑,CI 里从来不跑(#4690 的遗留决定) #5960 (all closed, the manifest generator). None is this defect.resolveSduiManifest cwd project manifest lookup→ 7 hits: [finding] the CLI's@objectstack/consolemanifest fallback can never resolve:resolveSduiManifest()asks for@objectstack/console/dist/sdui.manifest.json, but the console'sexportsmap publishes only./package.json#19922, plus six closed generator and parser cards. None is this defect.Dedupe words:
resolveSduiManifest process.cwd config directory·sdui.manifest.json ignored explicit config path·JSX gate manifest lookup cwdGenerated by Claude Code