feat(python-pipeline): support dynamic_secret runtime-secret arguments

[Silin144]

What

Ports the dynamic_secret / DynamicData authoring primitive into OSS tangle-cli so Python-authored pipelines can express a runtime-resolved secret argument natively, without reaching into a downstream package.

Tangle runnable arguments can be literals, graph/task edges, or dynamic data resolved by the runtime (e.g. a secret reference). Until now the Python emitter had no explicit wrapper for the dynamic-data case, so author code couldn't request a dynamicData argument without opening support for arbitrary dict constants. This adds a narrow, typed primitive for exactly that.

Surface

from tangle_cli.python_pipeline import dynamic_secret

@task
def call_model(openai_api_key: In[str] = dynamic_secret("OPENAI_API_KEY")):
    ...

Emits:

openai_api_key:
  dynamicData:
    secret:
      name: OPENAI_API_KEY

• dynamic_secret(name) — the public authoring entry point; raises ValueError on a non-empty-string name. Re-exported from tangle_cli.python_pipeline (added to __all__, not # noqa).
• DynamicData(value) — internal frozen-dataclass emit primitive, emitted as {"dynamicData": <value>}. Deliberately not part of the public surface: value is a general mapping (the runtime resolves several kinds — secrets, run IDs, loop indices), but the only public producer today is dynamic_secret, which always builds the schema-valid secret shape. Any other shape fails closed at compile validation until the constructor and schema are extended together, so the public API never promises more than the schema enforces.

Changes

• python_pipeline/dynamic_data.py — new DynamicData + dynamic_secret.
• python_pipeline/__init__.py — re-export dynamic_secret via __all__ (DynamicData stays internal).
• python_pipeline/emit.py — emit DynamicData args as {"dynamicData": ...}.
• schema_validation.py + schemas/dehydrated_pipeline_schema.json — the dehydrated (strict) schema now recognizes dynamicData.secret.name. The runnable (pipeline_schema.json, API-generated) schema stays intentionally permissive.
• Tests: tests/test_python_pipeline_dynamic_data.py (new, 79 lines) covers the wrapper contract, emit shape, validation, and the non-empty-name guard; one import-surface assertion added to tests/test_python_pipeline_dsl.py.

Testing

• Full OSS suite green; ruff clean.

🤖 Generated with Claude Code

[Volv-G]

(AI-assisted) [nit] DynamicData is a general wrapper but the schema only accepts the secret.name shape. value: Mapping[str, Any] accepts any mapping, and emit renders it verbatim as {"dynamicData": value} — but the dehydrated schema (DynamicSecretData, additionalProperties:false, required:["secret"]) only allows the secret shape. So a DynamicData({"someOtherKind": ...}) would emit yet fail compile-validation, even though the runtime resolves other dynamic-data kinds (run IDs, loop indices — per this PR's own test docstring). Consider either narrowing the class to secrets-only, or broadening the schema to match the documented runtime generality, so the type doesn't promise more than the schema enforces.

Minor also: @dataclass(frozen=True) with a dict field leaves instances effectively unhashable (unlike sibling Raw, which defines __hash__). Harmless today (never hashed), just inconsistent.

[Silin144]

Good catch — fixed in 4949b4a. Rather than loosen the strict schema, I documented DynamicData on the class as an internal emit primitive (kept out of __all__): its value stays a general mapping since the runtime resolves several kinds, but the only public producer dynamic_secret always builds the schema-valid secret shape, and any other shape fails closed at compile validation until the constructor + schema are extended together. So the public API never promises more than the schema enforces.

On the hash: since it holds a dict and is never hashed, I left it unhashable rather than fabricate a canonical form — happy to add a __hash__ for parity with Raw if you would prefer the consistency.

[Volv-G]

(AI-assisted) [nit] Only dynamic_secret is re-exported here, not DynamicData. The PR description says "Both re-exported from tangle_cli.python_pipeline (added to __all__)", but DynamicData — the type users would annotate or isinstance-check against — is reachable only via the .dynamic_data submodule. Either add DynamicData to the import + __all__ too, or adjust the description.

[Silin144]

Kept DynamicData internal (only dynamic_secret is in __all__) and corrected the PR description to match — the "both re-exported" line was the inaccurate part. DynamicData is only an emit primitive, so users never need to annotate or isinstance-check against it.

[Volv-G]

(AI-assisted) Clean, narrow, well-tested port of the dynamic_secret / DynamicData primitive — emit dispatch, strict dehydrated schema (secret.name, non-empty, no extra props), and good negative tests. Left two nits inline (class generality vs. schema narrowness; DynamicData not top-level exported). Neither blocks. LGTM.