[bug]: @sf-agentscript/agentforce@2.5.34 (latest) still unusable — dist/ compiled against a newer @sf-agentscript/language than package.json pins (missing export `nullLiteralValidationPass`)

使用 issue 中展示的干净 npm install 和 bare import 重现失败，然后结合 package.json 检查 dist/index.js:354，以追踪不匹配的语言依赖。阅读 scope-rewrite issue 涉及的发布流水线，并验证 workspace 版本如何变成已发布的固定版本。完成意味着干净安装可以 import 该 package，并且已打包 artifact 的 smoke test 覆盖每个 public entry point。

Summary

@sf-agentscript/agentforce@2.5.34 (current latest) cannot be imported after a clean npm install. The package's dist/ is compiled against a newer @sf-agentscript/language than the version its own package.json pins, so the import fails immediately.

This looks like a sibling of #35 (and PR #40): the scope-rewrite part appears fixed in 2.5.34 — dist/index.js now correctly imports from @sf-agentscript/language — but the same publish pipeline still emits dependency pins that don't match what dist/ was built against. Net effect is the same: the published package is broken end-to-end, just with a different error.

Reproduction

mkdir repro && cd repro && npm init -y
npm install @sf-agentscript/agentforce      # resolves 2.5.34
node --input-type=module -e "import { parse } from '@sf-agentscript/agentforce';"

Actual

SyntaxError: The requested module '@sf-agentscript/language' does not provide
an export named 'nullLiteralValidationPass'
    at .../node_modules/@sf-agentscript/agentforce/dist/index.js:354

Expected

The module imports and parse() is callable.

Root cause

@sf-agentscript/agentforce@2.5.34 → dist/index.js:354:

import { symbolTableAnalyzer, undefinedReferencePass, /* ... */,
         nullLiteralValidationPass } from "@sf-agentscript/language";

but its package.json pins the dependency exactly:

"@sf-agentscript/language": "2.5.4"

and that version does not export the symbol:

@sf-agentscript/language	exports nullLiteralValidationPass
2.5.4 (the pinned version)	❌ no
2.18.0	✅ yes

So the compiled output requires a newer language than the manifest allows. Installing @sf-agentscript/language@2.18.0 alongside it makes the import succeed, which confirms the diagnosis.

Suggested fix

1. Have the publish pipeline pin the workspace versions the artifacts were actually built against (the same step that got the scope rewrite wrong in #35 / #40), or simply bump the @sf-agentscript/language pin.
2. Add a post-publish smoke test that installs the packed tarball into a clean directory and does a bare import of every public entry point. Both #35 and this issue would have been caught by that single check, and it would keep the published artifact honest going forward.

Environment

• @sf-agentscript/agentforce@2.5.34 (dist-tag latest)
• resolved @sf-agentscript/language@2.5.4
• Node.js v24.15.0, npm 11.12.1, Windows 11

Notes

Workaround for anyone blocked: @sf-agentscript/parser is unaffected and can be used directly if you only need the AST — that is what I ended up doing. I am building a static authority analyzer that reads .agent authoring bundles and resolves each action's apex:// / flow:// target straight from the file.

Happy to send a PR for the smoke test if that approach is acceptable.