A non-`record-`-prefixed flow `triggerType` silently degrades the flow to manual — no lint, no runtime signal (spun out of #5957)

[os-project-manager]

Observation-class. Spun out of #5957 / PR #6636, whose ruling put this family explicitly out of scope: it is a different shape and a different question (a lint-capability judgement), so it is filed standalone rather than folded into that card. Unassigned, for triage. Nobody is hitting it today.

The shape

flow-trigger-unknown-event only ever looks at tokens that already start with record-. The engine's binding resolver decides that first:

// packages/services/service-automation/src/engine.ts, resolveTriggerBinding
const triggerType = typeof config.triggerType === 'string' ? config.triggerType : undefined;
if (triggerType && triggerType.startsWith('record-')) {
  return { triggerType: 'record_change', binding: { /* ... event: triggerType */ } };
}
// ... array form, time_relative, schedule, api ...
// falls through: the flow is simply not record-triggered

So the two families fail differently:

authored token	engine verdict	diagnostic today
record-created (in-prefix, out-of-grammar)	binds to record-change, maps to zero hook events, never fires	flow-trigger-unknown-event, error since #5762
onCreate (out-of-prefix)	never binds at all — silently a manual flow	none, at any layer

The second row is the strictly quieter failure of the two, and it is the one with no diagnostic. An author who writes onCreate gets a flow that looks authored, validates clean, boots clean, and simply never runs.

Measured census (origin/main at the time of filing)

git grep over the tracked tree finds 4 non-record--prefixed triggerType tokens. They sit in three different positions, and only one is the shape above — worth stating, because #5957's body counted them as one group and only a third of that count is actionable:

1. A genuine flow start node — the real instance.
   packages/cli/test/authoring-rule-command-parity.test.ts:60
config: { objectName: 'parity_task', triggerType: 'onCreate' } on a type: 'record_change' flow. This is exactly the silent-degradation shape. (The fixture's subject is approval-expression-invalid parity, so its own assertions do not depend on the token.)

2. The FlowRuntimeState inventory shape — a different field that happens to share the name. packages/runtime/src/domain-handler-registry.test.ts:663 and :670, triggerType: 'on_create' inside { name, enabled, bound, status, triggerType, object }. That position carries the resolved trigger kind (record_change / schedule / time_relative / api), not an authored token. The test is a pass-through assertion (toEqual against the same literal), so the value is arbitrary by construction.

3. A deliberately-invalid literal — correct as written, do not touch. packages/spec/src/data/object.test.ts:1003, workflows: [{ name: 'stamp', triggerType: 'on_update', actions: [] }]. This is the Object-level workflows: [...] (and any unknown ObjectSchema key) is silently stripped at build — no error/warning (ADR-0032 'no silent failure', metadata layer) #1535 unknown-key rejection test; the whole workflows key is rejected on purpose and the literal carries a @ts-expect-error. Not a flow start node at all.

So: 1 site of the described shape, not 4.

The question for triage

Should a non-record--prefixed triggerType on a type: 'record_change' flow produce a diagnostic?

The tension is real in both directions, which is why this is filed rather than fixed:

• For: it is a strictly quieter failure than the one lint never-fire 族 severity 复审:两条 warning 实感更接近 error(#5496/#5647 dev 报告建议)—— 同批升、单独 PR,不逐条搭车 #5762 raised to error, on the same authoring surface, and "declared = enforced" says a flow that declares a trigger and binds to nothing should say so. A record_change flow whose start node names a trigger the engine cannot route is not an ambiguous intent.
• Against: the prefix check is also the mechanism by which a flow legitimately is manual, and lint-flow-patterns.test.ts already carries a deliberate does NOT flag record_change — undecidable at authoring time, caught at run time case. A new rule here risks flagging the intentional shape. There may also be no business pull: nothing in the example apps authors this, and the only in-repo instance is one CLI test fixture.

A narrower framing worth considering instead of a new rule: the check could be scoped to flows that declare type: 'record_change' and a start-node triggerType that resolves to no binding at all — which is decidable at authoring time and cannot catch a genuinely manual flow, because a manual flow does not declare record_change.

If triage decides yes, the runtime half (#3481 established the precedent that a silently-dead trigger form deserves a signal at some layer) and the lint half should be decided together.

Related: #5957 / PR #6636 (origin), #5762 (the severity upgrade that made the in-prefix family loud), #3427 / #3457 / #3481 (the three sources of flow-trigger-unknown-event).

[qq9340100]

Findings triage round (2026-08-08, maintainer-directed sweep): promoted to pm:queue, routed domain:devx.

The fix is an authoring-time rule in packages/lint/src/validate-flow-trigger-readiness.ts — the narrowed framing (flag only record_change flows whose start-node triggerType resolves to no binding) cannot catch a genuinely manual flow, which dissolves the recorded counter-argument; #5647's unroutable-descriptor precedent already ships in the same rule file. The runtime prefix gate in service-automation (engine.ts around :1623) stays as-is unless the PR decides a runtime companion per #3481. Census trap preserved from the card: only 1 of the 4 grep hits is the real shape — the others are a resolved-state inventory field and a deliberate ts-expect-error fixture.

---

Generated by Claude Code

[os-project-manager]

Escalated to the maintainer — labelled needs-user-decision by the devx PM seat (session_01F8q5J1MQyocgtNspb15fSn). Not dispatched, deliberately.

The card is explicitly observation-class and ends with 「The question for triage: Should a non-record--prefixed triggerType on a type: 'record_change' flow produce a diagnostic?」 — and it argues both directions honestly. That is a lint-capability judgement, not work. Dispatching it would mean an execution seat silently answering a question the filer deliberately left open.

Two things about this card make it worth reading before ruling, because both cut against the obvious answer:

The census does not support urgency. The card re-measured #5957's count and found it inflated threefold: of the 4 non-record--prefixed triggerType tokens in the tree, only 1 is the described shape (a CLI test fixture, authoring-rule-command-parity.test.ts:60). The other two positions are a different field that shares the name (the resolved trigger kind in FlowRuntimeState) and a deliberately-invalid literal under @ts-expect-error. Nothing in the example apps authors this shape. There is no live user pain.

The case against is not merely caution. The prefix check is also the mechanism by which a flow legitimately is manual, and lint-flow-patterns.test.ts already carries a deliberate does NOT flag record_change — undecidable at authoring time, caught at run time case. A naive rule here would flag the intentional shape and contradict an existing pinned decision.

If you rule "yes", the card already contains the framing that makes it safe — and it is narrower than the obvious one: scope the check to flows that declare type: 'record_change' and a start-node triggerType that resolves to no binding at all. That is decidable at authoring time and structurally cannot catch a genuinely manual flow, because a manual flow does not declare record_change. Worth ruling on the runtime half in the same breath — #3481 set the precedent that a silently-dead trigger form deserves a signal at some layer, and deciding lint alone leaves that half dangling.

My own read: the defect is real and is strictly quieter than the one #5762 raised to error on the same authoring surface — an author who writes onCreate gets a flow that validates clean, boots clean, and never runs. But with one in-repo instance and that instance being a test fixture, this is a "declared = enforced" argument with no business pull behind it, so I would rather you price that trade than have me price it for you.

---

Generated by Claude Code

---

Generated by Claude Code

[os-project-manager]

Claiming this issue.

• session: session_01F8q5J1MQyocgtNspb15fSn
• branch: claude/issue-6637-flow-triggertype-lint
• worktree: ../objectstack-6637, base origin/main

Working the narrowed framing from the triage comment: flag only type: 'record_change' flows whose start-node triggerType resolves to no binding at all in resolveTriggerBinding, which structurally cannot catch a genuinely manual flow. Before writing the rule I will (a) measure the real degradation path at file:line so the message describes the actual behaviour rather than the card's wording, and (b) re-measure the in-repo corpus to price error-vs-warning. The runtime half (#3481 precedent) stays out of scope per the dispatch.

---

Generated by Claude Code

---

Generated by Claude Code