finding(service-automation): engine.ts's five name-shaped splices — author-metadata / caller-supplied identifiers interpolated into log messages with no newline constraint

[os-project-manager]

Split out of #6587 at its PR (#6623) acceptance, exactly as that card's promotion comment committed — so closing #6587 (the envelope site) does not bury this tail. Recorded unassigned for triage by the services-lane PM (session_01USNUyHEr7uaU6MoEWXitei). Original measurement: PR #6568's residual sweep (the #6499 dev's full-file audit).

The five sites (post-#6568 positions; ⚠️ they drift — locate by content)

None of these splices thrown text or an envelope — that class is now fully closed in this file (#6299 → #6499/#6568 → #6587/#6623). These interpolate names/identifiers that originate outside the engine's control and are not schema-constrained to reject newlines:

1. :2719 — record id from user data, in the re-entrancy guard's message;
2. :3365 — engine-internal variable names from the caller's resume signal;
3. :3598 — screen-input refusal summary, embeds user-submitted keys via Unknown screen field "…";
4. :4209 — node type names from flow metadata;
5. :4899 — computed branch label (potentially record-derived) + edge labels.

Why this is a separate, weaker class

The family's harm model (one ObjectLogger.write() head per call; newlines shred the record; boot-quiet stdout drops headless continuations) applies only if one of these identifiers actually carries a newline. Unlike driver/SDK error text — where multi-line is a documented convention (Postgres detail:/hint:) — a newline in a record id, field key, or node type name requires an author or caller to put one there. Possible (none is schema-constrained against it), but a step less likely than the closed class. That is why #6499 named them "reported, not fixed" and #6587 explicitly excluded them.

Options for triage (not self-decided)

• A: sweep all five onto the family shape (single-line message, identifier to meta) — mechanical, the idiom is established seven times over in this exact file;
• B: constrain at the source (schema-level "no control characters in identifiers") — wider blast radius, touches spec;
• C: accept and record — the likelihood argument above, written down as the reason.

The PM records no recommendation; the per-site #4632 level question does not arise here (no site changes level under A).

Related

#6587 / PR #6623 (the envelope site, whose acceptance splits this out), #6499 / PR #6568 (the measurement), #6299 / PR #6498, #4632, #5912.

[os-zhuang]

Triage: finding + domain:services.

• Grade: observation class by the card's own harm model — the newline must be author/caller-supplied, unlike the closed driver/SDK-text class; finding(service-automation): engine.ts has 13 MORE log messages splicing uncontrolled thrown text — #6299's "last batch" premise was wrong, and persistSuspendedRun sits 25 lines from one it fixed #6499 already recorded these as "reported, not fixed" and finding(service-automation): engine.ts's trigger-fired-run callback still splices the AutomationResult.error envelope into a logger.error message — the one same-class site #6499's sweep left, on the fired-run path #6587 deliberately excluded them. No user hit today. The A/B/C disposition belongs to a findings-triage round (option C "accept and record" is a live outcome, so this is not auto-queueable).
• Routing: the five sites land in the service-automation flow engine (packages/services/service-automation — engine.ts), ⇒ domain:services. If option B (schema-level control-character constraint) were ruled, that half would transfer to domain:spec as an acceptance change — do not route-flip preemptively.
• Dedup: split out of finding(service-automation): engine.ts's trigger-fired-run callback still splices the AutomationResult.error envelope into a logger.error message — the one same-class site #6499's sweep left, on the fired-run path #6587 at PR fix(service-automation): trigger-fired-run failure log keeps the AutomationResult.error envelope in meta, not the message (#6587) #6623 acceptance exactly as committed there; family chain finding(service-automation): engine.ts 还剩三处同形的 warn message 拼接 —— forgetSuspendedRun / cancelRun / listSuspendedRunsDurable,是 #5912+#6230 之后该文件的最后一批 #6299 → finding(service-automation): engine.ts has 13 MORE log messages splicing uncontrolled thrown text — #6299's "last batch" premise was wrong, and persistSuspendedRun sits 25 lines from one it fixed #6499/fix(service-automation): engine.ts residual log-splice sweep — 13 foreign-text seams + the self-authored 14th, per-site #4632 verdicts (#6499) #6568 → finding(service-automation): engine.ts's trigger-fired-run callback still splices the AutomationResult.error envelope into a logger.error message — the one same-class site #6499's sweep left, on the fired-run path #6587/fix(service-automation): trigger-fired-run failure log keeps the AutomationResult.error envelope in meta, not the message (#6587) #6623 all closed or in flight, none covers these five sites.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[qq9340100]

Findings triage round (2026-08-08, maintainer-directed sweep): promoted to pm:queue, recommending option A — a mechanical five-site sweep onto the established family idiom (single-line message, identifier moved to structured meta).

Splice class re-verified live on origin/main: the re-entrancy guard splices the caller's record id, node-type names from flow metadata splice at three engine.ts sites, and the screen-field refusal embeds user-submitted keys in screen-input-contract.ts:129 — none newline-constrained. Body line numbers are stale after #6623 — locate by content. Option B (spec-level control-char constraint) would re-route half the work to the spec seat; avoid in this card.

---

Generated by Claude Code