`demo_bootstrap` runs every 10 minutes forever in production tenants (1,776 runs in 13 days, longest 26 min) — a bootstrap should run once

[hotlong]

Restart-when: a published @objectstack/plugin-security > 17.4.0 that this repo can pin carries objectstack-ai/objectstack@2266438ce0 (PR #17872, fixing #17628) — probe the tarball for the app:seeded re-run of claimSeedOwnership, not the issue state

现象（生产实测；租户信息已匿名）

一个装有 HotCRM 的生产租户，sys_job：

job	cron	13 天运行次数	平均耗时	最长耗时
flow-schedule:demo_bootstrap	*/10 * * * *	1,776	3.4 s	1,568,985 ms（26 分钟）

另有 2 次自该租户首次开机起一直停在 running。

demo_bootstrap 每次对 12 个 crm_* 对象各做一次 owner_id IS NULL 过滤（limit 500）再逐条认领。首轮之后每次都是空操作：sys_automation_run 保留的 100 次运行里 selected 合计 100、acted 0。

为什么要紧

• 一个「自举」流以永久 10 分钟 cron 的形式存在，在每个装了 HotCRM 的租户里无限期发语句
• 在远程 Turso 租户库上（框架侧已知缺索引问题），这 12 条过滤每条都是全表扫描
• 同一租户里有 12 个流以 channels: ['inbox', 'email'] 通知；未配置邮件的租户，每条通知都产生一条必死的 email 投递行。框架侧会另外处理渠道可用性，这里先知情

建议

1. demo_bootstrap 改为一次性：安装 / seed 完成时触发一次，或自检到 ownerless 记录归零后自我停用——不再是常驻 cron
2. 框架对「未配置渠道」的裁决落地后，评估这 12 个 notify 节点是否要把 email 设为可选

验收

• 新装租户：demo_bootstrap 至多运行到 ownerless 记录归零为止；sys_job 中不再保留常驻的 */10 调度
• test/flow-scheduled*.test.ts 相应更新并通过

---

Generated by Claude Code

[hotlong]

Related framework cards (same production incident):

• driver-turso: remote mode never materializes object-level indexes — every declared secondary index is absent on production Turso tenant databases, so hot polling queries full-scan objectstack#17609 — remote Turso never builds declared indexes (every filter here is a full scan)
• service-messaging: NotificationDispatcher issues 32 statements per tick on an EMPTY outbox (reap runs per partition, twice) — idle cost scales with partitions × table size and never backs off objectstack#17610 — notification dispatcher idle cost
• service-messaging: fan-out writes an email delivery for a tenant with no email transport — it dead-letters on its first attempt and is kept 90d, so the hot outbox grows ~1 dead row per notification objectstack#17611 — dead email deliveries for tenants without an email transport (the 12 notify nodes' email channel)

[os-project-manager]

First-touch grading → pm:queue + bug · backend · priority:p1, type Bug

repo:hotcrm seat (single-lane repo — self-serves grading and type), session_0132iDHq4FLW2zS9VPXqbf9f, R62.

Class (a): a reproducible defect with a production measurement attached, a named landing point (src/flows/demo-bootstrap.flow.ts) and written acceptance. p1 because it is live in every tenant carrying HotCRM, unbounded in time, and already has two jobs stuck in running — ⛔ not because a bootstrap looping is untidy.

⭐ R62 measured two things that price this card — and they point in opposite directions

This round's dispatches (PR #1895, #1275 + #1804) instrumented demo_bootstrap by accident. Both readings are load-bearing here:

① The 10-minute sweep is currently a live safety net — and R62 just removed its reason to exist.

On the unfixed tree, claimSeedOwnership failed at boot and left rows ownerless; the */10 sweep is what repaired them, within ten minutes, by id — measured boot+3min → boot+7min:

crm_case 38/38 -> 38/0 · crm_event 27/27 -> 27/0 · crm_contract 4/4 -> 4/0
crm_knowledge_article 4/4 -> 4/0 · crm_forecast 7/7 -> 7/0

⚠️ So before PR #1895, making this flow one-shot would have left ownerless rows permanently unowned — editable by nobody, admin included. PR #1895 fixed the root cause (99a6c990), so the boot-time claim now succeeds and the sweep has nothing to repair. ⇒ this card became safe to do in this round, and ⛔ would have been actively dangerous before it. Whoever takes it should verify the claim still succeeds on their base before removing the net.

② The obvious self-disable condition is a trap. The card's option 2 is "self-deactivate once ownerless records hit zero." R62 measured that crm_campaign_member (51 rows) and crm_event_attendee (27 rows) are 100% unowned after a full boot AND after the sweep — both carry a physical owner_id column, and neither is in CLAIMED_OBJECTS (event_attendee by explicit documented ruling; campaign_member without one being written down).

⇒ a naive "ownerless count is zero" predicate never becomes true, and the flow never stops. The condition must be scoped to CLAIMED_OBJECTS, ⛔ not to "rows with an owner_id column".

⚠️ The fence question is real, and the fix shape decides it

demo_bootstrap is pinned across six test files, including test/flow-scheduled-org-partition.test.ts, which asserts its schedule shape and its multi-organization exemption by name. test/** is epic #1579's fence.

• Option 1 (drop the cron, trigger once at install/seed) almost certainly reds those schedule assertions ⇒ hits the fence ⇒ becomes another card behind [Decision] Does the test/** fence release accuracy fixes to existing guards, or does it hold whole? Five queued cards are unfixable and R59 crossed it twice on its own word #1874, which already carries 11.
• Option 2 (keep the registration, add a self-disable / early return) may leave the registration-shape assertions intact and stay inside src/.

⛔ Not pre-decided here, and ⛔ not queued as "pick option 2 to dodge the fence" — that would be choosing an inferior design to avoid a governance question. The dispatch will require the implementer to establish which assertions actually move, and to stop and report rather than cross the fence.

⇒ queued because the primary landing point is src/flows/, not test/, and at least one legitimate shape stays inside it. If measurement shows every shape needs a test/** edit, this card converts to pm:blocked on #1874.

Not in scope here

The card's item 2 (whether the 12 notify nodes should make email optional) is downstream of a platform ruling that has not landed, and it overlaps #1185, which is in the decision box carrying its own notify conversion. ⛔ Not folded in; it stays an observation on this card until the channel-availability ruling exists.

Refs PR #1895 / 99a6c990 (the root-cause fix that makes this safe) · #1804 (the correction recording the sweep's repair window) · #1185 (the other notify card) · #1874 (the fence, if option 1 wins).

---

Generated by Claude Code

[claude]

Claim: PM loop round R63
Session: session_0132iDHq4FLW2zS9VPXqbf9f
Branch: claude/issue-1892-demo-bootstrap-one-shot
Worktree: hotcrm-issue-1892
Domain: repo:hotcrm (single-lane repo — ⛔ no domain:*)
File surface: src/flows/demo-bootstrap.flow.ts (+ whatever the chosen shape requires inside src/). ⛔ test/** is epic #1579's fence — STOP and report rather than cross (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgement — ⚠️ dispatch-gates.mjs --tier REFUSES in this repo (no scripts/pm/), per seat post §1; tier set by the seat.
Clause-②: no
Thread-read: 5629333907
Serial constraints cleared: none — sibling this wave is #1265 (src/objects/knowledge_article.hook.ts), disjoint. PR #1893 (#1185, draft, decision box) holds src/flows/*.flow.ts for the 15 notify nodes: ⚠️ do NOT touch notify nodes in this card. PR #1882 (draft, maintainer's) holds src/profiles/.

---

Generated by Claude Code

[claude]

Released at shift close — R63, ⛔ zero work lost

Release: session session_0132iDHq4FLW2zS9VPXqbf9f · cause: maintainer ended the shift on budget (「没 token 了」, 2026-09-11T04:2xZ) while this card was in flight · destination: back to pm:queue, unassigned.

Verified before releasing, ⛔ not assumed: the dispatched branch claude/issue-1892-demo-bootstrap-one-shot exists on the remote but points at 99a6c990 — byte-identical to main. No commit was pushed, so there is no WIP to rescue, no partial PR, and nothing for a successor to diff. ⇒ a clean release, ⛔ not a dead claim for someone to reclaim in 24h.

⭐ The dispatch order's analysis is not lost — it is on this card's claim comment and in the grading/verdict comments above. Whoever picks this up next should re-read those rather than re-derive, then re-verify every premise against the tree at their own base.

⚠️ Two things this card must not lose, both measured in R62 and written up at 5629333907: (1) the */10 sweep WAS the safety net for ownerless rows, and only PR #1895 (99a6c990) made removing it safe — re-verify the boot-time claim succeeds first; (2) a self-disable predicate scoped to "rows with an owner_id column" never becomes true — crm_campaign_member and crm_event_attendee are permanently unowned by design and are not in CLAIMED_OBJECTS. Scope it to CLAIMED_OBJECTS. ⚠️ Still priority:p1, still the maintainer's own production card.

---

Generated by Claude Code