观察
packages/plugins/plugin-auth/src/rate-limit-storage.ts 里的 incrementFixedWindow() / createLazyCounterStore() / InProcessCounterStore 是仓内唯一的定窗计数件，#4790 的交叉说明也明确要求后来者复用而不是写第三份。它们确实被复用了，而且已经跨出了 auth：
问题在于它只能从包根导入（@objectstack/plugin-auth 的 exports 只有 "."），而该包的 index.ts 是 export * 一大串，其中 objectql-adapter.ts 直接 import { createAdapterFactory } from 'better-auth/adapters'、backfill-account-issuer.ts 直接 import … from '@better-auth/core/db' —— 都是值导入，会在模块加载时被急切求值。
于是任何想用这 90 行计数的包，都要把 better-auth + @better-auth/{core,oauth-provider,scim,sso} + jose + @noble/hashes + @objectstack/rest + @objectstack/platform-objects 一起装上并加载。@objectstack/runtime 本来就依赖 plugin-auth，代价隐形；@objectstack/service-sms 在 #2814 之前只有 @objectstack/core + @objectstack/spec 两个工作区依赖，之后为了一个计数器多出上面整串（plugin-auth 的 dist 本身 ~320 KB）。
为什么现在只记录、不动手
改法（把计数件提到中立包，或给 plugin-auth 加一个子路径 export）要动 packages/plugins/plugin-auth 的文件，是 identity 车道领地；#2814 的派发令明确 ⛔ 不动那里，所以按 Prime Directive #10 记录为 finding。
今天没有人踩到
没有用户可见症状：依赖方向不成环，构建、类型检查、测试全绿，实际部署里 plugin-auth 基本总在场。这条是架构负债，不是缺陷 —— 严重度交 PM 分诊。
可能的方向（不预设结论）
- 给 plugin-auth 的
exports 加一个 "./rate-limit-storage" 子路径，消费方按子路径导入，避开 index 的急切求值（改动最小，依赖树不变但加载面变小）；
- 把计数件提到中立包（
@objectstack/core 或新的小包），plugin-auth 反过来消费它（最干净，但牵动 4 个现有消费方）；
- 维持现状，在被复用第 4 次时再议。
观察
packages/plugins/plugin-auth/src/rate-limit-storage.ts里的incrementFixedWindow()/createLazyCounterStore()/InProcessCounterStore是仓内唯一的定窗计数件，#4790 的交叉说明也明确要求后来者复用而不是写第三份。它们确实被复用了，而且已经跨出了 auth：packages/runtime/src/security/inbound-rate-limit.ts（「v17」入站 rateLimit 接执行:ApiEndpoint / HttpServer 的 RateLimitConfig 推导为 runtime token bucket 配置,dispatcher 生效(#4686 拆向之一) #4910，logPrefix选项就是为它加的）packages/runtime/src/endpoint-policy.tspackages/services/service-sms/src/sms-daily-quota.ts问题在于它只能从包根导入（
@objectstack/plugin-auth的exports只有"."），而该包的index.ts是export *一大串，其中objectql-adapter.ts直接import { createAdapterFactory } from 'better-auth/adapters'、backfill-account-issuer.ts直接import … from '@better-auth/core/db'—— 都是值导入，会在模块加载时被急切求值。于是任何想用这 90 行计数的包，都要把
better-auth+@better-auth/{core,oauth-provider,scim,sso}+jose+@noble/hashes+@objectstack/rest+@objectstack/platform-objects一起装上并加载。@objectstack/runtime本来就依赖 plugin-auth，代价隐形；@objectstack/service-sms在 #2814 之前只有@objectstack/core+@objectstack/spec两个工作区依赖，之后为了一个计数器多出上面整串（plugin-auth 的 dist 本身 ~320 KB）。为什么现在只记录、不动手
改法（把计数件提到中立包，或给 plugin-auth 加一个子路径 export）要动
packages/plugins/plugin-auth的文件，是 identity 车道领地；#2814 的派发令明确 ⛔ 不动那里，所以按 Prime Directive #10 记录为 finding。今天没有人踩到
没有用户可见症状：依赖方向不成环，构建、类型检查、测试全绿，实际部署里 plugin-auth 基本总在场。这条是架构负债，不是缺陷 —— 严重度交 PM 分诊。
可能的方向（不预设结论）
exports加一个"./rate-limit-storage"子路径，消费方按子路径导入，避开 index 的急切求值（改动最小，依赖树不变但加载面变小）；@objectstack/core或新的小包），plugin-auth 反过来消费它（最干净，但牵动 4 个现有消费方）；