Inconsistency when .value is required

[elinscott]

Inside a deferred @task.graph body...

• a scalar input arrives as a TaggedValue over an orm node (e.g. orm.Str). Naive use raises and you must reach through .value
• A dict input in the same position arrives as a plain dict you can subscript directly.

The asymmetry is surprising — there is no signal that one input needs .value and the other does not.

This is possbly related to the same boundary-promotion seen in #780 (scalars promoted to orm types across a @task.graph boundary), here for a direct scalar input rather than a dataclass field. It is not a node-graph issue: in pure node-graph the scalar arrives as a TaggedValue over a plain str and int(label) works without .value. The promotion to orm.Str is added by aiida-workgraph.

MWE

from aiida_workgraph import task

@task
def make_label() -> str:
    return "777"

@task
def make_dict() -> dict:
    return {"n": 5}

@task
def sink(scalar, n) -> dict:
    return {"scalar": scalar, "n": n}

@task.graph
def inner(label, d):
    # int(label) raises -- label is a TaggedValue over orm.Str, not a str
    sink(scalar=int(label.value), n=d["n"])   # scalar needs .value; dict subscripts directly

@task.graph
def top():
    inner(label=make_label().result, d=make_dict().result)

top.build().run()

Wish

A scalar input should behave like its plain Python value in a @task.graph body (no .value), consistent with how a dict input is delivered.