org 作用域的 flow overlay 只在「本进程内发布后」绑定触发器,重启后静默失绑——冷启动两条读路径都把 organization_id 非空的行滤掉了

[hotlong]

发现于 #6155 的前提核验(未在该 PR 内修,按 Prime Directive #10 单开)。

事实(实测,非推断)

flow 在 DEFAULT_METADATA_TYPE_REGISTRY 里是 allowOrgOverride: true + allowRuntimeCreate: true,所以 runtime/src/domains/meta.ts:158-159 的 saveMetaItem({ type, name, item, organizationId })(org 取 resolveActiveOrganizationId)会写出 sys_metadata.organization_id = 'org_a' 的 flow 行。实测确认该行确实落库。

之后这一行的命运是不对称的:

时机	路径	org 行可见?
发布当场(同进程)	saveMetaItem → applyRegistryWriteThrough(publish 分支)→ hydrateOverlayIntoRegistry → 进程级 SchemaRegistry	✅ 可见
发布当场,自动化重绑	emitMetadataMutation → metadata:reloaded → resyncFlowsFromProtocol → getMetaItems({ type: 'flow' })(读到 registry 分支)	✅ 绑定,定时任务起飞
重启后冷启动	ObjectQLPlugin.restoreMetadataFromDb → protocol.loadMetaFromDb(),where = { state:'active', organization_id: null }(metadata-protocol/src/protocol.ts:10620-10623)	❌ 跳过
重启后 kernel:ready 绑定	service-automation/src/plugin.ts:1542 protocol.getMetaItems({ type: 'flow' }) —— 不传 organizationId,于是 protocol.ts:3319 的 orgRecords = orgId ? … : [] 为空	❌ 跳过

实测(真 ObjectStackProtocolImplementation + 内存 sys_metadata 引擎,两行 flow:org_sweep org=org_a、platform_sweep org=null):

PROBE rows = [{"name":"org_sweep","org":"org_a"},{"name":"platform_sweep","org":null}]
PROBE getMetaItems({type:flow}) names(registry 为空时) = ["platform_sweep"]
PROBE getMetaItems({type:flow}) names(publish 写穿后)  = ["org_sweep","platform_sweep"]
PROBE loadMetaFromDb = {"loaded":1,...}      // 只有 platform_sweep

影响

1. 静默失效:租户在 Studio 里发布一个 org 归属的 flow(record-change 或 schedule),当天正常触发;下一次进程重启后它再也不触发,没有任何日志说它消失了——kernel:bootstrapped 的 unbound 审计也看不见它(它压根没注册)。这正是 AGENTS.md「Absence must be loud」的反面。
2. 可见性不对称:写穿期间该 org 行进了进程级 registry,于是 getMetaItems({ type: 'flow' }) 对任何 org 的调用方都返回它——而 loadMetaFromDb 的注释明确说 per-org overlay 之所以不 hydrate 就是「to avoid cross-org leakage into the process-wide SchemaRegistry」。写路径比读路径更宽松,恰好是 applyRegistryWriteThrough TSDoc 自己声明要避免的("The write must not be more permissive about that than the read is" —— 该 gate 只挡了 environmentId !== undefined,没挡 org)。

与 #6155 的关系

不是 #6155 的子问题:#6155 问的是「定时流程的 org 从哪来」,本单问的是「org 归属的 flow 到底还活不活」。但两者相互制约——若维护者裁决 org flow 本就不应被加载(ADR-0005 的白名单表原文即「automation flow ❌ per-org override,Per-org variants are a deployment, not an overlay」,与代码现状矛盾,另见同批开的 registry/ADR 漂移单),那本单的修法就是在写入侧拒绝而不是在读取侧补齐。所以建议先定性再定修法。

复现

无需真 DB:packages/metadata-protocol/src/protocol-publish-drafts-org-scope.test.ts 的 stub 引擎即可(需给 registry 补 isPackageDisabled: () = false 与一个真存的 listItems)。

Refs:#6155、#4636(loadMetaFromDb object 分支的另一处 row 读取缺陷)、ADR-0005 §Tenant-customizable type whitelist、applyRegistryWriteThrough(protocol.ts:7434)。

Blocked-by: #6191

---

Generated by Claude Code

[claude]

Triage: pm:blocked (Blocked-by: #6191) + domain:engine-core + target:v17.

Classification — real, well-located, but its fix direction is gated

Every fact in the body reproduces against origin/main: flow carries allowOrgOverride: true (packages/spec/src/kernel/metadata-plugin.zod.ts:649), loadMetaFromDb filters organization_id: null (packages/metadata-protocol/src/protocol.ts:10622), and the cold-boot binder calls protocol.getMetaItems({ type: 'flow' }) with no organizationId (packages/services/service-automation/src/plugin.ts:1542). The write/read asymmetry is exactly as documented.

Not queued, because the body's own closing line is right: the two candidate fixes are opposite. If ADR-0005's ❌ row stands, the fix is to refuse the write; if the reversal is ratified, the fix is to complete the read. A dev dispatched today would hit the os-dev "underspecified decision that changes the public contract → STOP" clause and burn a run. #6191 is now in the maintainer's decision inbox and is the gate, so this issue takes pm:blocked with a machine-readable Blocked-by: line added to the body — the unlock sweep returns it to the queue when #6191 closes. This is a deferral of direction, not of priority.

Routing rationale (landing site, not title vocabulary)

domain:engine-core. The issue reads as automation, and the most visible symptom is a service-automation one — but three of the four named code sites are in packages/metadata-protocol (domain:engine-core per the domain table's packages/metadata* family): the read filter at protocol.ts:10620-10623, the orgRecords = orgId ? … : [] branch at :3319, and the write-through gate applyRegistryWriteThrough at :7434 whose own TSDoc states the write must not be more permissive than the read. The service-automation call site at plugin.ts:1542 is a consumer of the flattened view, and it is correct under the current contract — it cannot pass an organizationId it has no business knowing at kernel:ready. Under either ruling the asymmetry is resolved in metadata-protocol (or, for the refuse-the-write route, in the packages/spec flag that #6191 owns), not in the binder. Labeling this domain:services off the title would route it away from the package the fix lands in.

One part of this is a defect under either ruling

Worth pricing separately when the gate lifts: impact ② (the publish-time write-through hydrates an org_a row into the process-wide SchemaRegistry, so getMetaItems({ type: 'flow' }) returns it to callers of any org) is a cross-org visibility leak regardless of which direction #6191 goes — loadMetaFromDb's comment says avoiding exactly that leak is why per-org overlays are not hydrated. If the maintainer's ruling is slow, that half is separable and dispatchable on its own.

Dedup

Full-text scan of all open issues and PRs across the three repos (loadMetaFromDb, OVERLAY_ALLOWED_TYPES, resyncFlowsFromProtocol, applyRegistryWriteThrough, allowOrgOverride): no existing dispatch entry. Neighbours checked and distinct:

• loadMetaFromDb object branch reads record.packageId from a snake_case row — always undefined, every object overlay registers under the 'sys_metadata' sentinel at boot #4636 (pm:dispatched, domain:engine-core) — also loadMetaFromDb, but the record.packageId snake_case read on the object branch. Different line, different failure; same function, so whoever takes this one should expect a same-file serial constraint against loadMetaFromDb object branch reads record.packageId from a snake_case row — always undefined, every object overlay registers under the 'sys_metadata' sentinel at boot #4636's PR.
• Schedule 触发器不携带任何 org 上下文——定时 runAs:'system' 清扫在多组织部署里仍会产出 organization_id=NULL 的行(#5494 的用户缺席半边) #6155 (needs-user-decision, domain:services, target:v17) — where a scheduled flow's org comes from, not whether an org-scoped flow survives a restart. Correctly kept separate by the author.
• ADR-0005 的租户可定制白名单表说 flow/workflow/approval 一律 ❌ per-org override,注册表却写着 allowOrgOverride: true——反转没有走 ADR(Prime Directive #13) #6191 — the gate; cross-linked both ways.

Cross-repo: nothing in objectui/cloud.

Release board

target:v17 on criterion ① and ④: a tenant publishes an org-scoped flow in Studio, it fires all day, and after the next process restart it never fires again with no log line anywhere — silent loss on a shipped path, and the kind of thing release notes would have to apologise for. Note the label is applied on the symptom, independent of which fix direction #6191 picks; if the ruling is "org flows should never have been writable", the board item becomes the write-side rejection plus whatever migration the already-stored rows need, which is still v17 work.

Body edit

Appended one line to the body — Blocked-by: objectstack-ai/objectstack#6191 — per the label discipline that pm:blocked carries its machine half in the body. No other text touched.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[hotlong]

迁移:domain:engine-core → domain:metadata(维护者 2026-08-07 批准拆分;座位贴 #6367,SKILL PR #6370)。落点证据:冷启动两条读路径滤掉 organization_id 非空行 —— loadMetaFromDb(protocol.ts:10620)+ getMetaItems org 分支,metadata 冷启动加载/水合。pm:blocked 状态与正文 Blocked-by: 行随卡走。全量分类审计 49 卡三判,本卡 MOVE/high。分诊会话:session_01BickTBKm2JYSNnrtPT8ysa。

---

Generated by Claude Code