Repository navigation
两条 flow 的节点 label 与 JSDoc 仍写着未发生的行为（Notify Management / Assign to Senior Agent），#851 的边界只覆盖了 description 串 #869
Description
Activity
[PM 认领 · R22] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-869-flow-node-labels· 文件面:src/flows/opportunity-won-alert.flow.ts(节点 label + 文件头 JSDoc)+src/flows/case-escalation.flow.ts(节点 label)+ changeset裁定与边界(#851/PR #870 的直接续篇,同一「写实当前行为」口径):
- 只改 label 与 JSDoc 注释,节点
id一个字不动(edges[]按 id 引用、case_escalation_on_create以n.id === 'start'改写——issue 已写明承重面,改前自行复核这两处引用链)。 'Notify Management'→ 写实(该节点只发{record.owner_id});'Assign to Senior Agent'→ 写实(该节点只写 is_escalated/escalation_reason/escalated_date/status,不碰 owner_id);opportunity-won-alert.flow.ts:10-12JSDoc 里残留的「notify the owner and their manager」→ 与 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 已改的 description 对齐。措辞与 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 落地的表行/description 一致,不再造第三种说法。- flow 行为零改动;label 变更会进 dist——build 后确认产物落位;若
automation-docs-coverage或其它测试钉了这些 label 原文,同批同步并在 PR body 说明(预期:该守卫派生的是行集/触发面/数词,不含节点 label——如实报)。 - issue 自陈「未验证 process monitor 是否渲染节点 label」——不需要为本单补这个验证(label 是随产物发布的 authored metadata,失真本身即足够修因),如实转述即可。
⚠️ 基线必须含 PR docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870(同两个文件刚动过 description);SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 边界同 automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851:不预判。
⛔ 不动
content/**、releases/;不加守卫;不升级 @objectstack/*;changeset 站内路径反引号;控制字节自扫;JSON 报告按标准 schema。
Generated by Claude Code
- 只改 label 与 JSDoc 注释,节点
[PM 验收] PR #877 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)
复核结论:
- 四处 label/JSDoc 全部写实且措辞与 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 落地文本一致,不造第三种说法。第四处(
Notify Support Team→Notify Case Owner)在派单授权内,且证据链最硬:case-sla-monitor里 id 相同、收件人相同的孪生节点早已叫Alert Owner——这不是新起名,是把落下的那个补齐。Notify Owner亦有四条既有 flow 先例。 - id 承重面处理到位:动手前核引用链(各 id 两条 edge +
n.id === 'start'改写点),改后逐字节 diff 证明所有 id/source/target 与 main 相同;给三个 stale-looking id 加注释防止未来被「顺手修掉」——这一步把「本 PR 不引入新风险」变成了「本 PR 消除了一个未来风险」。 - 产物证据代替不可用的反向红:旧串三个全部归零、新串命中数连派生拷贝都对上(
case_escalation_on_create由 map 派生故 ×2);无任何测试钉节点 label(这正是漂移存活的原因),照模板编反向验证会是捏造——如实报,采纳。 - CI 实测 9/9 绿(head 1845a1f);
src/**改动仅 label 与注释,行为面零变化,SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判。
越界发现处置:#875(
src/docs/crm_sales.md两处经理声明,经 ADR-0046 整篇进产物——非纯注释)入队pm:queue;#876(sla-and-escalation 三语把升级写成改派+三方群发,虚构邮箱地址,与 #850 已做分行切割)入队pm:queue。⚠️ 排期注记:#876/#850/#866 三单均触sla-and-escalation,派发时错轮或分行。
Generated by Claude Code
- 四处 label/JSDoc 全部写实且措辞与 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 落地文本一致,不造第三种说法。第四处(
来源：#851（PR 修 automation flow 表两行 +
opportunity_won_alert的description）实施过程中的顺带发现。#851 的派单边界是「src/**中除两个 flow 文件的description串外零改动」，所以下面这三处同族错误留在原地，单独立单。基线
origin/main= ed6885e（#851 的改动只动了description，不触及以下任何一处）。事实
1.
src/flows/opportunity-won-alert.flow.ts:71—— 节点 label'Notify Management'该节点只发给负责人本人。同一节点上方 73–75 行的注释自己就写明了为什么不发给经理（
{record.owner_id.manager}在原始触发快照上无法穿透 lookup，会插值成字面量undefined）。label 说的是没做的事。2.
src/flows/case-escalation.flow.ts:87—— 节点 label'Assign to Senior Agent'该节点不写
owner_id，不改派。同一节点 93–96 行的注释开头就是No owner reassignment:。label 与紧邻它的注释直接矛盾。3.
src/flows/opportunity-won-alert.flow.ts:10-12—— 文件头 JSDoc这正是 #851 刚从
description串里改掉的那句话。#851 合并后，该文件第 12 行的 JSDoc 与第 21 行的description会互相打脸（description 已改为「the owner alone, not their manager」）。影响与定性（留给 triage）
dist/objectstack.json发布（已在编译产物中确认落位），因此不是纯注释问题；它们与 automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851 修的文档表行是同一类读者伤害，只是往里挪了一层。但我没有验证 process monitor / flow 运行详情是否真的渲染节点 label —— 若不渲染，则退化为观察类。这一步请 triage 时确认，我不替它下结论。修复面（未做）
label可以安全改（纯展示串）：'Notify Management'→ 如'Notify Owner'；'Assign to Senior Agent'→ 如'Flag as Escalated'。id（notify_management/assign_senior_agent）不要顺手改：edges[]按 id 引用，且src/flows/case-escalation.flow.ts的CaseEscalationOnCreateFlow用n.id === 'start'做 map 改写，id 是承重的。改 id 属行为面变更，不应混进文案单。顺带记录（不必修）
case_escalation与case_escalation_on_create自身的description（'Automatically escalate high-priority cases'/'Escalate cases created critical (insert-time twin of case_escalation)'）是准确的，#851 已逐节点核过，无需改动——记在这里免得被重复打开。Refs #851 #595