⚠️ 重建卡。 原卡 #17150 随 os-trump 账号被停用一起销毁。⛔ 原卡上的选项字母（A′ / B / C）与其正文已经不存在，本席不复原它们——下面的选项是重新写的，⛔ 不要把它们当成原卡那三个。若你记得原来的裁定倾向，请直接说，本席照办。
PR #17334 的四处源码注释与 changeset 都写着这张卡"正在重建"（grep 'is being re-filed'），⇒ 这个号是欠代码库的。
一句话问题
我们自己发的示例应用里有四个定时流。新规则要求每个定时流声明它代表哪个组织，而这四个流一个都声明不了 —— 于是要么它们在启动时全部不再运行，要么规则对它们网开一面。
背景
#16659 的维护者裁决（2026-09-08，逐字）：
多组织定时任务本来只能在组织内运行，应该带组织ID，不允许跨组织的定时任务。
PR #17334 实现了它：一个 schedule / time_relative 流若不声明 organization，启动时就不再 armed，并打出一条点名该流与该键的拒绝。
⚠️ 问题在于组织 id 是运行时才存在的值（一个 sys_organization.id，部署自己铸的）⇒ 示例应用的作者写不出它。四个流是：showcase_task_due_reminder、showcase_scheduled_digest，以及另外两个（PR #17334 的文档段落列全）。
⭐ 已经被这一轮回答掉的那一半（⛔ 不再是本卡的问题）
原卡曾把「validate-flow-trigger-readiness 能不能学会这条规则」列为待决之一。它学会了，而且严重度是测量出来的，不是选的：
- 定为
warning ⇒ objectstack build 在 examples/app-showcase 与 example-todo 上通过；
- 承接席做了一次一次性变异探针把它翻成
error ⇒ objectstack build 直接失败，点名 showcase_task_due_reminder 与 showcase_scheduled_digest，⛔ 而作者没有任何可写的修法。
⇒ 这条探针把本卡的真问题量了出来：规则本身没错，是我们自己的示例满足不了它。
选项 × 真实代价（⛔ 重新写的，不是原卡那三个）
|
做什么 |
客户能感知到什么 |
| A |
让示例流能声明组织：给一个可授权的引用形式（例如指向"本部署的唯一组织"或一个具名种子组织的记号），示例照写 |
示例能跑；⚠️ 代价是新增一个已声明的键或记号 ⇒ 永久义务，且它必须在多组织装机上有明确语义，否则就是把"跨组织"从后门放回来 |
| B |
承认示例是单组织场景，给单组织装机一条明确的、声明式的豁免 |
示例照跑；⚠️ 但豁免一旦存在，多组织装机的第一天就是它失效的那天——正是 #16659 要修的缺陷"晚一步复现" |
| C |
示例流不再自带定时触发，改成文档里说明"你自己加上 organization 之后再启用" |
⛔ 示例失去一个能跑起来的能力；但规则不被稀释，⇒ 也没有新增永久面 |
| D |
维持现状：四个示例流在启动时静静地不 armed，lint 报 warning |
⛔ 我们自己发的示例带着一个警告，且它演示的能力实际上不工作 |
业务含义直译
- A =「给示例发一张通用工牌」——能进门，但要想清楚这张工牌在有很多扇门的大楼里意味着什么。
- B =「单间办公室不用刷卡」——今天成立，搬进写字楼的第一天失效。
- C =「示例只演示怎么装门，不演示开门」。
- D =「门装好了，钥匙没发，门口贴张纸条」。
四棱
os-decision-facets
① 项目长远合理性 —— C 不新增任何永久面，最省；A 新增一个必须在多组织下也说得通的记号，⇒ 它是唯一可能扩大契约的；B 造一个"今天成立、明天失效"的条件豁免，⚠️ 那正是 #16659 的缺陷形状（在单组织装机上合法、第二个组织出现当天静默失效）。
② 实际业务拉动 —— 撞上的是照示例学的人：示例是新用户第一眼看到的东西，而它现在演示一个不工作的能力。⛔ 但本席没有实测有多少人真的在跑这四个流，⇒ 拉动强度未知。
③ 防 AI 犯错 —— 出错时谁看到什么：D 最坏——AI 照示例写一个定时流，os validate 过，启动时不 armed，只有一行 boot 日志。⭐ 而这正是 #17123 那张卡的形状（跑了、报告健康、什么都没送达）。A / B / C 都把它变成作者写下时就知道的东西。
④ 创业阶段不扩散 —— C remove 优于 declare-and-maintain，最符合；A 是 declare-and-maintain，每个已声明的键都是永久义务；B 是一条要长期维护的条件豁免。
推荐：⛔ 本席不推荐。 四棱在此分歧：①④ 指向 C，③ 指向"任何一个都好过 D"，② 数据缺失。⇒ 按纪律分歧即升级，交你拍板。
⛔ 置信缺口 —— 本分析看不见：有多少人真的在用这四个示例流（②轴没有实测）；objectui / cloud 里有没有同形状的示例（⛔ 声明为未知，不是"没有"）；以及 A 的那个"记号"具体能不能在多组织下定义清楚——⚠️ 若定义不清，A 就等于把跨组织从后门放回来，而那是裁决明令禁止的。
关联
一句话问题
我们自己发的示例应用里有四个定时流。新规则要求每个定时流声明它代表哪个组织，而这四个流一个都声明不了 —— 于是要么它们在启动时全部不再运行，要么规则对它们网开一面。
背景
#16659 的维护者裁决（2026-09-08，逐字）：
PR #17334 实现了它：一个
schedule/time_relative流若不声明organization，启动时就不再 armed，并打出一条点名该流与该键的拒绝。sys_organization.id，部署自己铸的）⇒ 示例应用的作者写不出它。四个流是：showcase_task_due_reminder、showcase_scheduled_digest，以及另外两个（PR #17334 的文档段落列全）。⭐ 已经被这一轮回答掉的那一半（⛔ 不再是本卡的问题）
原卡曾把「
validate-flow-trigger-readiness能不能学会这条规则」列为待决之一。它学会了，而且严重度是测量出来的，不是选的：warning⇒objectstack build在examples/app-showcase与example-todo上通过；error⇒objectstack build直接失败，点名showcase_task_due_reminder与showcase_scheduled_digest，⛔ 而作者没有任何可写的修法。⇒ 这条探针把本卡的真问题量了出来：规则本身没错，是我们自己的示例满足不了它。
选项 × 真实代价（⛔ 重新写的，不是原卡那三个）
warning业务含义直译
四棱
os-decision-facets
① 项目长远合理性 —— C 不新增任何永久面，最省；A 新增一个必须在多组织下也说得通的记号，⇒ 它是唯一可能扩大契约的；B 造一个"今天成立、明天失效"的条件豁免，⚠️ 那正是 #16659 的缺陷形状（在单组织装机上合法、第二个组织出现当天静默失效）。
② 实际业务拉动 —— 撞上的是照示例学的人：示例是新用户第一眼看到的东西，而它现在演示一个不工作的能力。⛔ 但本席没有实测有多少人真的在跑这四个流，⇒ 拉动强度未知。
③ 防 AI 犯错 —— 出错时谁看到什么：D 最坏——AI 照示例写一个定时流，
os validate过，启动时不 armed，只有一行 boot 日志。⭐ 而这正是 #17123 那张卡的形状（跑了、报告健康、什么都没送达）。A / B / C 都把它变成作者写下时就知道的东西。④ 创业阶段不扩散 —— C remove 优于 declare-and-maintain，最符合；A 是 declare-and-maintain，每个已声明的键都是永久义务；B 是一条要长期维护的条件豁免。
推荐：⛔ 本席不推荐。 四棱在此分歧：①④ 指向 C，③ 指向"任何一个都好过 D"，② 数据缺失。⇒ 按纪律分歧即升级，交你拍板。
⛔ 置信缺口 —— 本分析看不见：有多少人真的在用这四个示例流（②轴没有实测）；⚠️ 若定义不清，A 就等于把跨组织从后门放回来，而那是裁决明令禁止的。
objectui/cloud里有没有同形状的示例（⛔ 声明为未知，不是"没有"）；以及 A 的那个"记号"具体能不能在多组织下定义清楚——关联
notifydelivers nothing on a multi-organization install: the run carries no organization, so the tenant-scoped inbox/delivery writes are refused (#8844) while the run reads healthy #16659 · PR fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334（其文档段落列全四个流；F4 的严重度探针是本卡的测量来源）