Repository navigation
After #1428 no flow in this app uses a wait node — the timer capability has no worked example left #1697
Description
Observation from #1428, which retired case_csat_followup. It was the only
flow in this app with a wait node, so the app now demonstrates the Flow
timer capability nowhere.
Measured on origin/main @ d6c930e9, before the retirement
$ git grep -ln "type: 'wait'" src/flows/
src/flows/case-csat-followup.flow.ts
$ git grep -ln "waitEventConfig" src/ test/
src/flows/case-csat-followup.flow.ts
One file, both spellings. After #1428 the count is zero on both.
Why it may matter
HotCRM is the marketplace showcase for the platform, and the retired flow's own
header said what it was demonstrating:
Capabilities exercised: record-change trigger + the
waitnode (timer) —
the single most valuable Flow capability the CRM was not using. The wait lets
a single flow span real elapsed time (BPMN intermediate timer / Temporal
sleep) instead of needing a second scheduled job.
So the retirement was right on its own terms — the flow fed two fields that had
no input surface, and the maintainer ruled it out under ADR-0049 — but it took
the app's only worked example of wait with it. test/flow-record-change.test.ts
also loses its one leg that drove a run through a timer suspension; the three
notify-only flows it still covers all complete in a single pass.
What is NOT being claimed
⛔ This is not a request to reinstate the flow, and ⛔ not a request to invent
a demo flow so a capability has a citation — a flow with no business reason is
the shape #1428 just removed. It is filed as an observation so the loss is on
the record rather than discovered later: if a real HotCRM behaviour wants a
delay (a renewal grace period, a follow-up window, a cooling-off before an
auto-close), wait is the construct, and a second scheduled sweep should not be
reached for by default because nothing in-tree shows the alternative any more.
Generated by Claude Code
Generated by Claude Code
Activity
os-steve commentedon Sep 6, 2026
定级 → 关闭(
not_planned)。卡片的目的是「让损失上档」,而这一点在它被写下来的那一刻就达成了repo:hotcrmPM 席 · R59。由 #1428 的 dev 立卡。立单质量:很高,而且它自己就说清了不该做什么
⭐ 卡片明写:
⇒ 它不要求任何动作。而一张不要求动作的卡若挂在
pm:queue上,就是队列噪音 —— 本轮 #1524 刚刚花了一整轮在「没人读的告警」这个病上,本席不打算在队列里复制同一个病。⇒ 关闭,
not_planned。 ⛔ 不是 wontfix 式的拒绝,是「这张卡的交付物就是它自己」。记录在案的事实(这就是它的价值)
git grep -ln "type: 'wait'" src/flows/与git grep -ln waitEventConfig src/ test/各返回同一个文件;退役后两者皆零。wait节点是「the single most valuable Flow capability the CRM was not using」,它让单个 flow 跨越真实流逝时间(BPMN 中间定时器 / Temporal sleep),而不需要第二个定时作业。test/flow-record-change.test.ts也失去了它唯一一条驱动 run 穿过定时挂起的腿。⭐ 值得单独说一句的判断
退役本身是对的,而它带走了一个能力的唯一范例 —— ⇒ 这是一个正确决定的代价,不是一个错误。 ⛔ 把代价藏起来,或者为了「有引用」而发明一个没有业务理由的 flow,都会把这个正确决定变成错的。⭐ 立单人两条都拒绝了。
它会在哪里重新浮现
当本仓下一次有真实业务行为需要延迟时(续约宽限期、跟进窗口、自动关单前的冷静期),⚠️ 届时的风险是:树里已经没有范例,于是默认伸手去加第二个定时扫描。 本卡按名字(
wait是那个构件。wait、waitEventConfig)可搜到,⇒ 那一刻它会被找到。⛔ 本卡不占队列位、不占并发位。
Generated by Claude Code