[jason810496]

Why

The _arg_bindings comment in the serialization schema says the key is only present on @task.stub tasks. That is no longer the only producer: a Dag declared in a language SDK serializes its tasks with is_stub and writes _arg_bindings itself, with no Python operator behind them.

Noticed while reviewing #73436.

How

• schema.json: the $comment now covers both producers: mixed-language tasks (the @task.stub operator) and tasks defined in a non-Python SDK Dag.
• ts-sdk/schema/dag-schema.json: re-synced from schema.json, since the TS SDK vendors a copy.
• adr/lang-sdk/0007-taskflow-across-language-boundary.md: one consequence bullet records the second producer. Decision B is unchanged, since it describes core-side materialization from a DecoratedOperator, which still works exactly as written.

No behaviour change: a $comment is documentation inside the schema and nothing reads it.

---

Was generative AI tooling used to co-author this PR?

• Yes, with help of Claude Code Opus 5 following the guidelines

[pierrejeambrun]

LGTM thanks.

Is 'native dag' vs 'mixed dag' public naming ? I like those and it wold probably be easier for users to understand what's going on.

native dag reads better than or a task of a Dag a language SDK declared and serialized itself but I think Ash didn't like that.

[jason810496]

Thanks, good point.

I rephrased as "Used for mixed-language tasks (the @task.stub operator) or tasks defined in a non-Python SDK Dag". Btw, Ash don't like the term "mixed-language Dag" not "mixed-language Task".

In the case of "mixed-language Task", we define the Dag at Python. In another word, only one language defines the "Dag", so there shouldn't be "mixed-language Dag".