观察类发现（finding，不入 pm:queue）。在 #5177 / PR #5211 里定位 CI 红时顺带撞到，与该单实现无关，故未在该 PR 内修。
现象
在一个刚建好、装完依赖但没有构建的 worktree 里跑：
node scripts/check-i18n-bundles.mjs
得到的是 9 个包各自「炸了」的报告：
› Error: command i18n:extract:packages/plugins/plugin-security/scripts/i18n-extract.config.ts not found
plugins/plugin-security ERROR
› Error: command i18n:extract:packages/services/service-storage/scripts/i18n-extract.config.ts not found
services/service-storage ERROR
...
check-i18n-bundles: 9 bundle problem(s)
• platform-objects: extract failed — no output
• plugins/plugin-approvals: extract failed — no output
• plugins/plugin-audit: extract failed — no output
...
真实原因只有一个：该门禁跑的是构建产物 packages/cli/bin/run.js（scripts/check-i18n-bundles.mjs:55 的 CLI 常量），CLI 的 dist 不在时 oclif 找不到 i18n extract 这条命令，于是每个包各失败一次。
跑一次 pnpm exec turbo run build --filter=@objectstack/cli 之后，同一条命令干净通过（9 个包全 in sync）。
为什么值得记一笔
输出把一个环境前置条件呈现成九个内容问题，而且用词正好指向错误的方向 —— 「bundle problem(s)」「extract failed」会让人以为是 i18n 配置或 bundle 内容坏了。本地复现一条 i18n CI 红时，这一步会先把人带偏一次：CI 里因为构建在前所以永远看不到这个形态，只有本地/worktree 里才撞得到，而本地正是你想复现 CI 的时候。
脚本自己其实已经知道这个前置条件 —— 文件头注释写着「Requires the workspace build (it runs the built CLI), so it belongs after …」—— 只是没有把它变成一次检查。声明了但没强制执行。
建议方向（实现者自选）
在进入 per-package 循环之前做一次前置判定，失败时用一条话说清楚该干什么，而不是让 N 个包各报一次：
- 判据可以是 CLI 产物是否存在（注意
bin/run.js 本身是源文件、未构建时也在，所以要探的是它加载的 dist），
- 或者更省事：把首个包的 oclif
command … not found 签名识别出来，直接判定为「工作区未构建」并立刻退出，提示 pnpm exec turbo run build --filter=@objectstack/cli。
任一种都行，关键是把「9 个 bundle 问题」换成「1 个前置条件没满足 + 修法」。
影响面
纯内部工具链 DX，无用户可见影响，今天没有人因此收到错误结果 —— CI 的判定始终是正确的，坏的只是本地复现时的首个诊断步骤。故按观察类归档，交由 PM 定级。
观察类发现（
finding，不入pm:queue）。在 #5177 / PR #5211 里定位 CI 红时顺带撞到，与该单实现无关，故未在该 PR 内修。现象
在一个刚建好、装完依赖但没有构建的 worktree 里跑：
得到的是 9 个包各自「炸了」的报告：
真实原因只有一个：该门禁跑的是构建产物
packages/cli/bin/run.js（scripts/check-i18n-bundles.mjs:55的CLI常量），CLI 的 dist 不在时 oclif 找不到i18n extract这条命令，于是每个包各失败一次。跑一次
pnpm exec turbo run build --filter=@objectstack/cli之后，同一条命令干净通过（9 个包全 in sync）。为什么值得记一笔
输出把一个环境前置条件呈现成九个内容问题，而且用词正好指向错误的方向 —— 「bundle problem(s)」「extract failed」会让人以为是 i18n 配置或 bundle 内容坏了。本地复现一条 i18n CI 红时，这一步会先把人带偏一次：CI 里因为构建在前所以永远看不到这个形态，只有本地/worktree 里才撞得到，而本地正是你想复现 CI 的时候。
脚本自己其实已经知道这个前置条件 —— 文件头注释写着「Requires the workspace build (it runs the built CLI), so it belongs after …」—— 只是没有把它变成一次检查。声明了但没强制执行。
建议方向（实现者自选）
在进入 per-package 循环之前做一次前置判定，失败时用一条话说清楚该干什么，而不是让 N 个包各报一次：
bin/run.js本身是源文件、未构建时也在，所以要探的是它加载的 dist），command … not found签名识别出来，直接判定为「工作区未构建」并立刻退出，提示pnpm exec turbo run build --filter=@objectstack/cli。任一种都行，关键是把「9 个 bundle 问题」换成「1 个前置条件没满足 + 修法」。
影响面
纯内部工具链 DX，无用户可见影响，今天没有人因此收到错误结果 —— CI 的判定始终是正确的，坏的只是本地复现时的首个诊断步骤。故按观察类归档，交由 PM 定级。