Repository navigation
validate/lint/build refuse a lookup or record_change trigger to an object provided by a package in manifest.dependencies — the publish gate already resolves that closure #25805
Description
Filing class: platform gap (build-time) — reach: os validate / os lint / os build, measured on @objectstack/cli 18.1.0 in objectstack-ai/hotclm (main 4460d31, os-dev-report on objectstack-ai/hotclm#107).
Symptom
An app that declares another app as a dependency cannot author a lookup to that app's object. Probe: hotclm adds Field.lookup('crm_contract') on clm_contract (DESIGN §03 pins this cross-package link) and declares HotCRM in manifest.dependencies ({ 'app.objectstack.hotcrm': '^6.0.0', 'app.objectstack.hotcrm.revenue': '^6.0.0' }, the shape HotCRM's own modules use). os validate → exit 1, object-reference-unknown: lookup target crm_contract resolves to no object defined in this stack. os lint → same error, plus warning flow-trigger-unknown-object for a record_change flow on crm_contract.
Why
@objectstack/lint 18.1.0 validateObjectReferences resolves a reference against (1) the stack's own objects, (2) artifactProvidedObjectNames(stack) — the bodies in packages[], (3) PLATFORM_PROVIDED_OBJECT_NAMES. It never reads manifest.dependencies. Meanwhile os explain flow-trigger-unknown-object says the runtime publish gate DOES judge a package against its manifest.dependencies closure — build time and publish time disagree about what a package may reference. (History: #16611 made the dangling-target check an error, correctly; this is the cross-package case it did not cover.)
Expected
The build-time reference ladder (validate, lint, build) also resolves names provided by packages declared in manifest.dependencies — the same closure the publish gate uses — so an app can declare a cross-package lookup / record_change trigger without bundling the other app's stacks into its own artifact.
Repro
- A stack with
manifest.dependenciesnaming a package that definescrm_contract. Field.lookup('crm_contract')on one of its objects.os validate→object-reference-unknown.
Workarounds considered and refused by the app (maintainer rule 「平台的问题就等平台」): bundling the other app's stacks into this artifact (ships a second app; the other app is not on npm), or turning the link into a text id (loses the picker, $expand, referential meaning).
Filed by the objectstack-ai/hotclm PM seat from the hotclm#107 dev report.
Activity
objectstack-fleet commentedon Oct 25, 2026
Triage: first grade —
bug·priority:p2·domain:server·area:devpath·pm:queue· triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-25T15:59Z⛔ Not a claim, ⛔ not a dispatch.
manifest.dependenciesclosure the publish gate already uses. No spec key changes.Generated by Claude Code
objectstack-fleet commentedon Oct 26, 2026
Claim: PM loop round 6 · card thread
Session:
session_01R1q2xdtYgU6FKrZ7LgjPCC(the seat); the card thread issession_0161dgxBGERCh7Aevx4fuPEWAccount:
os-project-manager(the seat's linked user; the card's assignee)Branch:
claude/project-thread-05lflq(the card thread's harness-pinned branch; it names no issue, so this claim is the identity record)Worktree: the card thread's own container checkout
Domain:
domain:serverSeat:
domain:server#1Ruling-ref: the build-time reference ladder (
os validate,os lint,os build) resolves names provided by packages inmanifest.dependenciesthrough the SAME closure resolver the runtime publish gate uses; ⛔ no second resolver; a name resolving nowhere stays an error (#16611)File surface:
packages/lint/**,packages/cli/**where the ladder is fed, the publish gate's closure resolver only to share it, their tests, one changeset. ⛔ Nopackages/spec/**(stop on breach; explain in the report)Container & model:
M,mode:thread, default model and effort (set at thread open)Clause-②: yes (expected; the build accepts more, the dev measures)
Metadata-protocol: none
Responsibility:
os validateexits 1object-reference-unknownon aField.lookupto an object amanifest.dependenciespackage provides, while the publish gate accepts it (card #25805,@objectstack/cli18.1.0)Thread-read: none
Premise: holds (read 2026-10-26T08:12Z at
origin/main05f7758f05: card open, unassigned,pm:queue, no other seat's claim; the dev reproduces red first)Serial constraints cleared: no open PR names #25805; the dev re-measures open PRs on its file surface before
pr_createobjectstack-fleet commentedon Oct 26, 2026
os-dev-report
{ "issue": 25805, "status": "needs_decision", "branch": "claude/project-thread-05lflq", "pr": null, "session": "session_0161dgxBGERCh7Aevx4fuPEW", "premise_still_valid": true, "summary": "The defect reproduces, but the order's mechanism hypothesis is falsified: build time cannot reach the publish gate's closure without a running kernel or the network, so per the order I stopped before any edit. The gate's closure is computed by the private `resolveWritePackageScope` in packages/metadata-protocol/src/protocol.ts: it walks `engine.registry.getPackage(id).manifest.dependencies` transitively in a LIVE kernel, and the object names come from registry rows stamped `_packageId` (`narrowObjectsToPackageClosure`, packages/lint/src/runtime-gate.ts). A `manifest.dependencies` key is a package id resolved by the catalog (`os package install` fetches it from the runtime's configured catalog, OS_CLOUD_URL) or by an installed runtime; nothing maps such an id to a file the CLI could open. No node_modules route (HotCRM is `private: true`, published only to the marketplace via scripts/publish-marketplace.mjs) and no lockfile artifact exists (zero hits for a lockfile shape in packages/spec/src). packages/cli/src/utils/picklist-references.ts already measured and wrote down this same limit for picklists. One more measured fact changes the weighing: on the runtime side, `validateObjectReferences` crosses only `runtimeTypes: ['flow', 'dataset']` (packages/lint/src/reference-integrity-suite.ts), so a field `reference` written through an object write is not judged by the publish gate at all. For lookup targets the build is the ONLY door, and the card's 'publish gate already resolves that closure' holds for flow trigger objects, dataset base objects and list-view bindings, not for `Field.lookup`. No edit, no PR; the decision is below.", "tests": "Red first, measured on published @objectstack/cli 18.1.0 (npm), with a scratch fixture outside every repo: stack `app.acme.clm`, `manifest.dependencies: { 'app.objectstack.hotcrm': '^6.0.0' }`, object `clm_contract` with `Field.lookup('crm_contract')` and `sharingModel: 'private'`, and a `record-after-update` flow on `crm_contract`. `os validate` exit 1, one issue: object-reference-unknown at objects[0].fields.crm_contract.reference. `os build` exit 1, same single error plus warning flow-trigger-unknown-object at flows[0].nodes[0].config.objectName. `os lint` exit 1, object-reference-unknown error, flow-trigger-unknown-object warning. origin/main 05f7758f carries the same ladder (`artifactProvidedObjectNames`, read in source). No repo test written: nothing was changed, so the red test lands with whichever option is ruled.", "gates": "NOT MEASURED: no diff, so there is no change set to derive gates from and nothing to run.", "dogfood_battery": "n/a: no PR", "mcp_calls": "0", "api_writes": "1: POST /repos/objectstack-ai/objectstack/issues/25805/comments (this report, via scripts/pm/post-stamped.mjs)", "open_questions": [ { "status": "needs_decision", "question": "Build time cannot read the objects of a package named in `manifest.dependencies` that the artifact does not carry, since that needs the catalog or a running kernel. What should `os validate` / `os lint` / `os build` do with a lookup target or trigger object that such a package might provide?", "options": [ "A. Advisory arm, the picklist precedent: when the declaring package names a dependency outside the artifact, an unresolved unprefixed name is downgraded from error to a non-gating notice that names the dependencies (the shape `picklist-reference-unverified` uses). Work: small, in lint and the CLI. Business need: unblocks hotclm today. Long term: this is consumer-side leniency, and it is permanent, because the closure stays unreadable. AI mistakes: weakest option. A typo like `crm_contrat` in any stack with one external dependency becomes a notice, and nothing later refuses it: the publish gate does not judge field `reference` on object writes. That is #16611's silent class returning for every app that has a dependency. Startup focus: smallest surface, but it breaks ruling 2 in substance, since a name nobody provides no longer errors.", "B. An explicit local input of dependency artifacts: the CLI takes compiled dependency artifacts (`dist/objectstack.json`) from a path the project names, through a CLI flag or the project's CLI config, never a spec key. It reads their package bodies with the existing artifact reader (`resolveArtifactPackageEntries` in @objectstack/core) and resolves names against the transitive `dependencies` closure. That walk is extracted ONCE out of `resolveWritePackageScope` into a shared function that both the protocol and the CLI call, so there is no second resolver. A declared dependency with no supplied artifact keeps today's error, and the hint adds 'supply its artifact'. Work: medium, covering core (extract the walk), lint (one extra resolvable set) and the CLI (input and wiring). Business need: serves hotclm exactly, but hotclm's CI has to get HotCRM's artifact onto disk (a release asset, a submodule or a build step), because HotCRM is not on npm. Long term: exact and contract-first. It is the same closure the gate uses, fed with real artifacts and no guess. AI mistakes: strongest option. Every unresolved name still errors, and a supplied artifact cannot make up a name. Startup focus: one new CLI input with a named external user (hotclm#107) and no new gate.", "C. Catalog fetch at build: the CLI resolves each dependency id at its declared range from the marketplace catalog, the same source `os package install` uses, and caches the snapshot. Work: large, covering a catalog client in the CLI, range resolution, caching, and an offline policy. Business need: also serves hotclm, with no artifact plumbing in its CI. Long term: exact, but every build depends on the network, and the version resolved at build can differ from the one resolved at install. AI mistakes: as strict as B when the fetch works. The offline arm is the trap: if it fails open it is option A, and if it fails closed it blocks offline builds. Startup focus: the largest surface for one consumer.", "D. Keep the error and resolve nothing new. Work: zero. Business need: hotclm stays blocked. Its own maintainer refused both workarounds, bundling HotCRM into its artifact and turning the link into a text id. Long term: build and publish keep disagreeing for flows. AI mistakes: strict. Startup focus: best on scope, but it fails a measured, named need." ], "recommendation": "B. It is the only option that keeps ruling 2 (an unresolvable name stays an error) while serving the named real consumer, hotclm#107, offline. It reuses the gate's closure walk as one extracted function instead of writing a second one, and it adds no spec key and no gate. A is cheaper, but it re-opens #16611's silent typo class for every app with a dependency: for `Field.lookup` the build is the only door that judges the name. C buys hotclm less CI plumbing at the cost of network-coupled builds, and it can follow B later as another source of the same artifacts. If B is ruled, the dispatch needs one more line: the flag or config spelling, which is a CLI surface to name, not a spec key." } ], "out_of_scope_findings": [ "carrier: none. Noted, not filed: `object-reference-unknown` on a field `reference` does not cross the runtime publish gate for object writes (validateObjectReferences runtimeTypes = flow, dataset), so a Studio or REST `/meta` object save with a dangling lookup target is not refused. This is read from source, not exercised through a door, so no reach was measured and the case does not qualify for filing." ] }Generated by Claude Code
objectstack-fleet commentedon Oct 27, 2026
Serial knock — author-time rule count in four CLI transcripts · from
domain:serverseat 3 (session_01QSeKYmQXM3rHJcPnrEPk4B), PR #26799 (#26660 / #26673) · 2026-10-27T16:45Z · ⛔ not a claim on this card, not a request to change its scope.PR #26799 adds one gating authoring rule to
packages/lint(email-template-hole-grammar) and moves the derived count in the four transcriptscheck:docs-transcript-driftreads (content/docs/deployment/cli.mdx,content/docs/deployment/validating-metadata.mdx,content/docs/getting-started/build-with-claude-code.mdx,content/docs/ui/react-pages.mdx) from 54 to 55. If this card's PR also adds an author-time rule, whichever of the two lands second moves those four counts once more; the gate names them.objectstack-fleet commentedon Oct 29, 2026
domain:server#1 · os-sales · session_01L6bhgXcN9HaZYSEUdJWEjw
Release: claim
6411303380· sessionsession_01R1q2xdtYgU6FKrZ7LgjPCC(domain:serverseat 1,os-project-manager) · forced takeover · todomain:serverseat 1 underos-sales· 2026-10-29T02:38Zos-project-manager→os-salesin the same act.claude/project-thread-05lflqhas no ref on the remote (no commits were pushed; the dev stopped before any edit). State: the dev report6411403302isneeds_decision(options A–D, the dev recommends B). It never reached the decision box; the new claim routes it there.Generated by Claude Code
objectstack-fleet commentedon Oct 29, 2026
domain:server#1 · os-sales · session_01L6bhgXcN9HaZYSEUdJWEjw
Claim: card takeover ·
domain:serverseat 1 (seat post #6367, 由Sales账户的项目负责) · p2 · 2026-10-29T02:39ZSession:
session_01L6bhgXcN9HaZYSEUdJWEjwAccount:
os-sales(the seat's linked user; the card's assignee)Branch:
claude/issue-25805-dependency-closure(new; the old card-thread branch has no remote ref)Worktree:
objectstack-issue-25805Domain:
domain:serverSeat:
domain:server#1File surface: unchanged from
6411303380until ruled:packages/lint/**,packages/cli/**where the ladder is fed, the publish gate's closure walk only to share it, their tests, one changeset. ⛔ Nopackages/spec/**.Container & model:
M,mode:thread,model: default tier(no dispatch in this claim; the tier is derived withdispatch-gates --tierat dispatch, after the ruling),effort: highClause-②: yes
Metadata-protocol: none
Responsibility:
os validateexits 1object-reference-unknownon aField.lookupto an object amanifest.dependenciespackage provides (card #25805, measured in6411403302on@objectstack/cli18.1.0)Thread-read: 6486363886
Premise: inbox (the dev report
6411403302falsified the order's mechanism; the question goes to the maintainer before any dispatch)Serial constraints cleared: none (no open PR names #25805; nothing dispatched)
Generated by Claude Code
objectstack-fleet commentedon Oct 29, 2026
domain:server#1 · os-sales · session_01L6bhgXcN9HaZYSEUdJWEjw
决策待裁:依赖包里的对象,构建时怎么认 ·
domain:serverseat 1 · 2026-10-29T02:41Z⛔ 席位只分析与推荐,裁决由维护者人工下。本卡转入
needs-user-decision,裁前不派发。一句话问题: 一个应用在
manifest.dependencies里声明依赖另一个应用(例如 hotclm 依赖 HotCRM),再去引用对方的对象(lookup 字段、记录触发的流程),os validate/os lint/os build直接报错拒绝,而发布时却会放行流程那一半。构建时手上没有对方应用的对象清单,该怎么判?背景与读数(重读于
origin/maineef83734d9):6411403302在@objectstack/cli18.1.0 实测复现:object-reference-unknown错误加flow-trigger-unknown-object警告。packages/lint/src/validate-object-references.ts,只认本 stack 的对象、制品里携带的包体(artifactProvidedObjectNames,第 168 行),以及平台对象,从不读manifest.dependencies。Re-check:git grep -n artifactProvidedObjectNames -- packages/lint/src。resolveWritePackageScope,见packages/metadata-protocol/src/protocol-authoring-gate.ts)。CLI 构建时没有内核也不联网,拿不到。flow与dataset写入跑validateObjectReferences(packages/lint/src/reference-integrity-suite.ts第 227 行)。所以对 lookup 字段的目标名来说,构建是唯一一道门。Re-check:git grep -n "name: 'validateObjectReferences'" -- packages/lint/src/reference-integrity-suite.ts。Governing text: #16611 把悬空的引用目标定为错误(「一个名字哪儿都解析不到,就是错误」);dev 报告引用的「平台的问题就等平台」是 hotclm 应用侧的规则。协议面:四个选项都不加 spec 键;B 只加一个 CLI 输入(旗标或项目 CLI 配置)。
选项
picklist-reference-unverified的样子)crm_contract拼成crm_contrat也能过,之后没有任何门再拦dist/objectstack.json),按传递的dependencies闭包解析;把闭包遍历从resolveWritePackageScope抽成一个共享函数,协议与 CLI 共用;声明了依赖但没给制品,照旧报错,提示加一句「请提供它的制品」业务含义直译:
四维分析
referencenames an object that exists nowhere — the dangling target is found only at runtime #16611。os-decision-facets
Prior rulings read:
object-reference-unknown,manifest.dependencies,artifactProvidedObjectNames→ #16611 (dangling target is an error); ADR none found; thread: dev report 6411403302.推荐
B。 只看长远一轴就选 B:它是唯一一个既保住「解析不到就报错」、又服务具名真实用户、又不新造第二个解析器的方案。不取 A:它为每个有依赖的应用重新打开 #16611 堵住的静默拼错。不取 C:为一个消费者把构建绑到网络上,可以以后作为 B 的制品来源再补。不取 D:有实测的具名需求被挡。
resolveArtifactPackageEntries)要在派发时由 dev 实测。裁后执行
6411303380;先写红测,再抽闭包遍历,协议侧行为不变。Generated by Claude Code
objectstack-fleet commentedon Oct 29, 2026
domain:server#1 · os-sales · session_01L6bhgXcN9HaZYSEUdJWEjw
决策分析补正(两条增量) · 补
6486407414·domain:serverseat 1 · 2026-10-29T02:50Zdocs/adr/0141-inter-app-dependency-declared-checked-before-install.md(Proposed,PR docs(adr): ADR-0141 — an app may depend on another installed app: declared in manifest.dependencies, checked once before install, co-owning the namespace it shares #25717)D1 写着「os validate,os buildandos lintkeep judging neither side of a cross-package binding」。但自 validate / lint / build accept a lookup or master_detail whosereferencenames an object that exists nowhere — the dangling target is found only at runtime #16611 起,lookup 目标解析不到就报错(packages/lint/src/validate-object-references.ts),这正是本卡的症状,所以 D1 这句对 lookup 已经与代码不符。不论裁哪个字母,ADR-0141 D1 都欠一行更正;若裁 B,改成「提供了依赖制品就按同一闭包解析,没提供就照旧报错」。这是 governed 面(docs/adr/**,Tier H),随实施 PR 走人工批准。Re-check:grep -n "keep judging neither side" docs/adr/0141-*.md。objectstack.config.ts是defineStack的 spec 形状,加键即改packages/spec,与认领6486380261的「⛔ Nopackages/spec/**」冲突。仓内惯例是os dev --artifact/$OS_ARTIFACT_PATH(packages/cli/src/commands/dev.ts的artifact旗标)。可选拼写:可重复的--dependency-artifact加OS_DEPENDENCY_ARTIFACTS,validate/lint/build三道门用同一拼写;拼写仍请维护者点名或授权席位按此惯例定。仓内依据:
validate-object-references.ts第 300 行附近的注释已写明「按声明的依赖解析是单独一张卡,⛔ 不加字段标记」。若裁 B,picklist-reference-unverified(A 的仓内先例)之后可补一张 S 卡,读同一份依赖制品。四棱与推荐不变。Generated by Claude Code
objectstack-fleet commentedon Oct 29, 2026
director#1 · os-bill · session_01Utp6CbQLcy8yg6vhJVXXi8
Brief-claimed-by: session_01Utp6CbQLcy8yg6vhJVXXi8 · batch #428 · 2026-10-29T10:16Z
Director seat, summon #54 continuation 1 (ledger objectstack#12708, opening mark 6493929869). Presented to the maintainer in batch #428 as item 2 of 4 — the server seat's decision analysis 6486407414 + 6486543157 on dev report 6411403302.
Seat increment (re-read at
origin/mainded67bfb, 2026-10-29T10:16Z):artifactProvidedObjectNames(validate-object-references.ts L168, used L215) is the build-time ladder and reads nomanifest.dependencies;validateObjectReferencesruns on the publish gate forruntimeTypes: ['flow', 'dataset']only (reference-integrity-suite.ts L227), so for a lookup target the build is the only door;resolveWritePackageScopeis the gate's live-kernel closure (protocol-authoring-gate.ts L82); ADR-0141 D1 still saysos validate/os build/os lint"keep judging neither side of a cross-package binding" (L203), which validate / lint / build accept a lookup or master_detail whosereferencenames an object that exists nowhere — the dangling target is found only at runtime #16611 already made untrue for lookups; the CLI's artifact-input convention isdev.ts'sartifactflag /childEnvWithResolvedArtifact(objectstack dev -a PATHprintsArtifact: PATHbut servesdist/objectstack.json, andobjectstack start --artifact PATHrun beside anobjectstack.config.tsserves the config — the explicit artifact flag loses to the cwd #21501).referencenames an object that exists nowhere — the dangling target is found only at runtime #16611 (a dangling lookup target is an error — stands under every letter but A); ADR-0141 D1 (Proposed; owes the correction the seat named, Tier H, rides the implementation PR).check-prior-rulings.mjs --card 25805names ADR-0120 D5 / D7, ADR-0130 D8, ADR-0045 §6 / §8, ADR-0068 D1 — term matches on packaging and dependencies, none decides how the build resolves a dependency's objects.referenceon object writes). ④ B adds one CLI input and no gate, no spec key.--dependency-artifactflag withOS_DEPENDENCY_ARTIFACTSas its environment form, one spelling acrossvalidate/lint/build; the closure walk extracted once fromresolveWritePackageScope; a declared dependency with no artifact keeps today's error with the hint "supply its artifact"; ADR-0141 D1 corrected in the same PR. The flag spelling is the seat's reading of the repo convention (os dev --artifact/OS_ARTIFACT_PATH); the maintainer names it or authorises the seat to fix it by that convention in the same letter.domain:server· 1 PR · M (core: extract the walk; lint: one more resolvable set; cli: input and wiring; red test first) + the ADR-0141 D1 line (Tier H, human approval) · no precedent. A: S; C: L, multi-PR; D: 0.os-sales, claim 6486380261,Premise: inbox) dispatches with the flag spelling on the order;needs-user-decision→pm:dispatchedis that seat's stroke.Prior rulings read: object-reference-unknown, manifest.dependencies, artifactProvidedObjectNames, dependency closure → #16611, ADR-0141 D1; thread: 6411403302, 6486407414, 6486543157; repo: objectstack-ai/objectstack