[objectstack-fleet]

Requested by Elon · project thread

Fixes #33341

Clause-②: yes (widening)
Metadata-protocol: added
Skills-docs: none — the added member is a field of the run summary the platform answers; no metadata author writes it, and no skill teaches the summary's node rows

维护者速读

• 改了什么:流程运行摘要 summary.nodes[] 的每个节点行,现在会带上该节点步骤产生的告警(warnings,字符串数组);spec 的 FlowRunNodeSummarySchema 同步声明这个可选字段。
• 为什么改:notify 节点唯一的渠道被拒(如未注册的 push)时,步骤日志里有告警,但触发接口返回的摘要里该行只显示 success、acted: 0,调用方看不出其实谁都没通知到。
• 风险与回滚:只加可选字段,节点状态、计数和流程走向都不变;每个节点最多列 5 条不同告警,超出时最后一条写明省略了几条。回滚即 revert 本 PR。
• 先看:packages/services/service-automation/src/run-summary.ts(折叠与上限,nodeWarnings);packages/spec/src/automation/execution.zod.ts(新字段与描述);packages/services/service-automation/src/builtin/notify-delivery-outcome.integration.test.ts(末尾新 describe)。
• 两分钟验证:pnpm --filter @objectstack/service-automation exec vitest run src/builtin/notify-delivery-outcome.integration.test.ts,预期 12 个用例全绿,其中新 describe 的 4 个用例断言摘要行带有点名 'push' 的告警。
• 需要你做的:无,席位落地。

What changes

• @objectstack/spec: FlowRunNodeSummarySchema gains warnings?: string[], the same element shape as ExecutionStepLogSchema.warnings. Optional and additive: absent when no execution of the node raised a warning, never [].
• @objectstack/service-automation: summarizeRun folds every node's step warnings onto that node's row, distinct texts in first-seen order. The list is bounded per node (MAX_NODE_SUMMARY_WARNINGS = 5, not exported from the package entry) because the summary's detail is sized by the flow's static shape, which is what keeps a long sweep's persisted summary_json under its byte cap; past the bound a final entry says how many distinct warnings were left out, and the step log keeps each execution's own.
• Every node type's step warnings ride along, not only notify's: a create_record / update_record whose requested fields were stripped now says so on its row too. One fold over the step log covers the whole class instead of a notify special case.
• Unchanged: node status, every counter, the run's outcome and flow control. A refused channel is still a successful step, as Flow notify step records success when its only channel was refused and nothing was delivered #32143's fix decided.
• Generated: packages/spec/authorable-surface/automation.json (+1 key) and content/docs/references/automation/execution.mdx, both from check:generated --fix. authorable-surface.base.json is untouched.
• Changeset .changeset/33341-notify-summary-row-warning.md: minor for both packages, with both declaration lines.

The trigger door serves the engine's result verbatim (deps.success(result), packages/runtime/src/domains/automation.ts), so the engine's run.summary is the trigger response's summary; the same summary rides a flow door's 400 FLOW_FAILED details and the persisted run row.

Why

The run already stopped claiming a false success (#32143), but a caller reading only the trigger response's summary still saw a notify row with status: 'success', acted: 0 and no reason, so it could not tell "nothing to send" from "the only channel was refused". The card asks for the warning on that row, in the shape other nodes already use for warnings (the step log's warnings).

Metadata-protocol is added and not none because FlowRunNodeSummary is on the spec's authorable-surface baseline, and the changeset gate refuses none beside a moved authorable-surface/ file. Clause-② is yes (widening): an optional member added to a published response schema.

Tests

All readings on head c14afda2e9.

• Premise, re-measured before the fix on the real run path (AutomationEngine.execute with the real MessagingService, outbox and dispatcher): the new describe in notify-delivery-outcome.integration.test.ts went red, 3 failed / 9 passed (12), AssertionError: Target cannot be null or undefined. on the row's warnings; the CONTROL case (registered channel, no warning) stayed green.
• New pins: 4 cases in a new top-level describe in notify-delivery-outcome.integration.test.ts (durable path, inline path, partial delivery, control); each parses the summary through FlowRunSummarySchema, so an undeclared member would be stripped and the case would go red. 5 cases in run-summary.test.ts (distinct first-seen fold, absent on other rows and on skipped nodes, a failed execution's warnings, the bound with its overflow entry, a list exactly at the bound). 3 cases in packages/spec/src/automation/execution.test.ts (kept through a parse, absent stays absent, a non-string entry is refused at ['warnings', 0]).
• Ablation on the committed fix, through scripts/ablation-replace.mjs: anchor if (warnings) node.warnings = warnings; 1 → 0, blob bacf67bb → ef6fbf30; 8 failed / 51 passed (59), every new warning pin red and the control green. Restored: blob == HEAD bacf67bb, git diff HEAD empty. The tests import run-summary.ts from src, so no dist leg.

Suite readings (os-verify-lock VERDICT lines)

• pnpm --filter @objectstack/service-automation test: Test Files 281 passed (281), Tests 3916 passed (3916), VERDICT command-exit 0.
• pnpm --filter @objectstack/service-automation typecheck (tsc + check:test-typecheck): exit 0.
• pnpm --filter @objectstack/spec test: Test Files 840 passed (840), Tests 26868 passed, 1 todo (26869), VERDICT command-exit 0.
• pnpm --filter @objectstack/spec typecheck: exit 0.
• pnpm --filter @objectstack/runtime typecheck + vitest run of flow-failed-inner-refusal, endpoint-flow-dispatch-status, automation-trigger-paused-run, automation-runs-unknown-flow: Test Files 4 passed (4), Tests 39 passed (39), VERDICT command-exit 0.
• eslint --no-inline-config over the five touched source and test files: exit 0.

Acceptance notes

• Narrowed dependent testing, declared: the spec change is an optional member on a response schema, so of the downstream consumers only @objectstack/runtime (the trigger door and the typed FlowFailureDetails builder) was re-run locally, its typecheck plus the four test files that read the summary. Every other dependent is left to CI's Test Core and TypeScript Type Check. A turbo ls --affected set would be blind to tests that read another package's source from disk, and the repo-root suites are not on that graph at all.
• Not merged with origin/main before opening: the branch is 9 commits behind, none touching packages/spec/src/automation, run-summary.ts, the authorable-surface or the reference docs (read with git diff HEAD...origin/main on those paths); the merge queue tests the merged tree.
• A subflow child's warnings stay on the child's own run row, as its skipped gates do; the parent's subflow row carries only warnings its own step raised.
• The Console's Runs panel reads step warnings and is not changed here; whether it shows the summary row's warnings is a UI question for another card.

Verification

Derived gates (dispatch-gates --commands at c14afda, 8 paths vs merge base b462444)

• 109 derived commands, each run with its exit code captured before any pipe; dispatch-gates --ran: 109 accounted for, 107 run, 2 NOT MEASURED, 0 UNRUN.
• NOT MEASURED, family check:skill-examples (spec), reason: exit 3 PREREQUISITE NOT MET, it compiles the skill examples against built @objectstack/client / @objectstack/client-react declarations, and this container has not built them.
• NOT MEASURED, family check:dual-build-cjs-loads, reason: exit 3 PREREQUISITE NOT MET, it loads 38 packages' built CJS entries and needs a full pnpm build.
• Both run in CI's Lint & Repo Gates on this PR.
• pnpm --filter @objectstack/spec check:generated after --fix: 14 of 14 artifacts current (it had named check:docs stale once, regenerated above); check:authorable-surface and check:api-surface green.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic.
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes (eslint run over the touched files; the repo-wide run is CI's).
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: its generated artifacts are regenerated and committed.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

Seat: domain:server#5 · os-elon-musk · session_016WV4cykhsWAtSL6Sr4VWFG, dispatched to an os-dev subagent on claim 6883603057.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

4 anchor(s) derived from 2 changed package(s); no hand-written page names any of them. ⚠️ 1 changed file(s) yielded no anchor (packages/spec/authorable-surface/automation.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/spec/authorable-surface/automation.json) — pages documenting those are invisible to this run
• the SDK route bridge reached 65 of 247 client-bound route-ledger rows — the other 182 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 182: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 59 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 123 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 172 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 9499dcc530a3dd8c0eee872f9483b96127ac8bfe → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 47ef06f73b2843ff1db4e15aec0deda8a8a4e410 — the merge of head c14afda2e91048a917253ec3c1b3d4b6c5a9b7a9 into base 9499dcc530a3dd8c0eee872f9483b96127ac8bfe, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 47ef06f73b2843ff1db4e15aec0deda8a8a4e410 && git checkout 47ef06f73b2843ff1db4e15aec0deda8a8a4e410
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 9499dcc530a3dd8c0eee872f9483b96127ac8bfe c14afda2e91048a917253ec3c1b3d4b6c5a9b7a9 && git checkout -B drift-repro 9499dcc530a3dd8c0eee872f9483b96127ac8bfe && git merge --no-ff c14afda2e91048a917253ec3c1b3d4b6c5a9b7a9

node scripts/docs-audit/affected-docs.mjs --json 9499dcc530a3dd8c0eee872f9483b96127ac8bfe

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cxHwXNcGcAHNerZsom

Request: review · area A5 · head c14afda · 2026-11-14T21:47Z

Contract review (Clause-② yes, widening: optional FlowRunNodeSummary.warnings in spec; Metadata-protocol line added). Fixes #33341. CI green on this head (58 success, 10 skipped). Two open questions from the os-dev report (comment 6884319460 on #33341): keep the widening (A), keep the 5-per-node cap with the counted overflow entry (A).

[objectstack-fleet]

Contract-review-claim: session_016WV4cxDxAYxdtDhtR1kQQe · head c14afda · 2026-11-14T21:48Z

review#2 (server area pilot, A5).

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: c14afda2e91048a917253ec3c1b3d4b6c5a9b7a9
Local-runs: none
Scope: packages/spec/src/automation/execution.zod.ts + packages/services/service-automation/src/run-summary.ts, packages/spec/authorable-surface/automation.json

review#2 (server area pilot) · area A5 · Fixes #33341 · published schema face (packages/spec/src/**). CI on this head: 58 success, 10 skipped, none failing.

① Derived judgments

• FlowRunNodeSummarySchema gains one optional member, warnings: z.array(z.string()).optional(). The element shape is the one ExecutionStepLog.warnings already publishes, so a reader that knows the step log reads the summary row the same way.
• run-summary.ts is the only producer. summarizeRun collects each step's warnings into a per-node Set (distinct texts, first-seen order) and publishes them through nodeWarnings, which returns undefined for none. The member is absent, never [], which matches the jsdoc and the step log's own convention.
• The per-node list is capped at MAX_NODE_SUMMARY_WARNINGS = 5 plus one counted overflow entry, so a row carries at most 6 strings whatever the run's iteration count. The spec describe says "Bounded per node", which matches.
• A subflow child's warnings stay on the child's own run row and are not lifted into the parent. That is the same rule the row's skipped counts follow.
• The card's scenario holds: a notify node whose deliveries all fail now reads status: success with warnings: ["channel 'email' (1 deliveries): …"] in summary.nodes[]. That text comes from deliveryFailureWarning (notify-node.ts), unchanged on main. The four integration cases in notify-delivery-outcome.integration.test.ts pin it end to end. Five cases in run-summary.test.ts cover distinct, dedupe, cap, overflow and the subflow rule. Three spec cases cover parse and absence. The ablation went red.
• authorable-surface/automation.json gains exactly automation/FlowRunNodeSummary:warnings, and the generated execution.mdx rows match the schema.

② Semver level

• Clause-②: yes (widening) is right: an optional member is added to a published schema, and no existing reader or writer is refused.
• Metadata-protocol: added is right and forced, because the authorable-surface baseline moved by one key.
• Minor bumps on @objectstack/spec and @objectstack/service-automation are the level that line requires. The Skills-docs: none — … line is present.

③ Boundary flags

• Not security sensitive. Warning texts now reach the trigger caller through the summary as well as the step log. Delivery errors carry a recipient id or address (email-channel.ts), and stripped-field warnings name field API names. Both were already readable to the same caller in the run's step log, so nothing new is exposed.
• No cross-area file. packages/spec/src/automation/** and service-automation are A5's lease.

④ Design judgment

Rulings on the two questions from the os-dev report (comment 6884319460 on #33341):

• Q1: keep the widening (option A). The card asks for the warning on the notify row in summary.nodes[], in the shape other nodes use. A run-level-only warning would leave the row reading as a clean success, which is the defect the card names. An optional member that reuses the step log's element shape is the smallest published change that answers it. Holding for a separate contract-tier ruling is not needed: this record is that ruling.
• Q2: keep the cap of 5 distinct texts plus the counted overflow entry (option A). It keeps each row sized by the static flow shape rather than by the iteration count, so the persisted summary stays under the serializeSummaryBounded cap without a second member. The full per-execution list is still in the step log, and the overflow sentence says so.

Nits (none blocking):

• N1: deliveryFailureWarning puts the per-execution delivery count in the text ((N deliveries)), so a loop whose fan-out varies produces several distinct texts for one cause. The cap bounds the count. A later card could make the text stable (count outside the text) so dedupe folds them.
• N2: a single warning text has no length bound. Many nodes × 6 long texts could push a run's summary into detailOmitted. That is the existing byte-cap fallback working as designed, not a regression.
• N3: the overflow sentence is a meta entry inside a data list, so a reader that counts warnings.length counts it too. It is documented in the jsdoc and the describe. A typed warningsOmitted: number would be cleaner but is a second widening, so not for this PR.

Implemented-by: claude/area-A5-33341
Reviewed-by: session_016WV4cxDxAYxdtDhtR1kQQe

VERDICT: PASS

Nits only, so this is the final round.

[objectstack-fleet]

domain:server#5 · os-elon-musk · session_016WV4cxHwXNcGcAHNerZsom

ACCEPT · area A5 · head c14afda · 2026-11-14T21:52Z

• Cards: Fixes flow trigger response: the notify row in summary.nodes[] carries no warning when its channel was refused #33341.
• Review: review#2 contract review PASS at this head (comment 6884750517). Clause-②: yes (widening) and Metadata-protocol: added ruled right; open questions ruled Q1 keep the widening, Q2 keep the 5-per-node cap with the counted overflow entry. Three non-blocking nits (N1 count inside the notify warning text defeats dedupe, N2 no per-text length bound, N3 overflow sentence is a meta entry in the data list) go to one loose-ends card after landing.
• Governed: check-governed-merges.mjs --pr 33438 → NOT governed, 232 changed lines (≤ 3000).
• Checks: 58 success, 10 skipped, none failing on this head; mergeable_state clean.
• Landing: ready + auto-merge under the maintainer's standing area rule (15:21Z, A5 thread).

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 43645264458 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

分类：failure —— 按下面的日志分诊。

失败的 job（日志抽取，best effort）：

• Dogfood Regression Gate (3/3) — 失败步骤: Boot example apps and exercise real user flows

  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > the
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: one warning line: expected [] to have a length of 1 but got +0
  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > ins
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: {"success":true,"data":{"manifestId":"com.qa.bare.delta","version":"1.0.0","versionId":"1.0.0","installedAt":"2026-11-14T22:01:53.245Z","hotLoaded":true,"upg
  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > the
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: expected [ Array(3) ] to deeply equal [ Array(2) ]
  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > the
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: expected [ Array(3) ] to deeply equal [ Array(2) ]
  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > the
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: expected [ [ 'com.qa.bare.alpha', true ], …(2) ] to deeply equal [ [ 'com.qa.bare.alpha', true ], …(1) ]
  @objectstack/dogfood:test:  FAIL   isolated  test/bare-name-one-holder-flow-family.dogfood.test.ts > one package holder per flow, webhook, connector and email template name, on a booted showcase > the
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: expected [ 'com.qa.bare.alpha', …(3) ] to deeply equal [ 'com.qa.bare.alpha', …(2) ]
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/bare-name-one-holder-flow-family.dogfood.test.ts — 24h 内已弹出 7 个 PR（feat(service-automation)!: two packages of two namespaces may each declare a connector of the same name (ADR-0150 child B, the narrowing) #33431、fix(service-automation): a run summary node row carries its steps warnings, so a refused notify channel shows in the trigger response #33438、fix(plugin-grid): fold a row's inline primary action into its menu while the table overflows with it #33441、test(dogfood): take the admin search terms from rows the stock admin is served #33449、fix(scenarios): the run grader reads a write withheld in a card's own verb ("I didn't lend out AST-0041") as a decline #33453、docs(skills): retirement playbook counts the six spec artifacts AGENTS.md lists #33457、docs(kernel): auth-service handleRequest names the whole surface, the mount-layer checks and the transport argument #33461），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: test/bare-name-one-holder-flow-family.dogfood.test.ts #33479（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 17 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)