hold(step=/timeout_step=) emits keys the SWAIG HoldAction schema rejects — needs live-platform verdict

[grandcamel]

FunctionResult.hold(step=..., timeout_step=...) (added in 350fcca, "hold routing") emits a hold action object like:

{"hold": {"timeout": 300, "step": "back_with_agent", "timeout_step": "take_a_message"}}

Every schema-side source disagrees that those keys exist:

• The bundled schema.json $defs.HoldAction allows the object form only as {"timeout": <int>} with "unevaluatedProperties": {"not": {}} — step/timeout_step fail validation.
• The platform docs for SWAIG response actions document hold as an integer or an object with a timeout property, nothing else.
• The TypeScript agents SDK's FunctionResult.hold takes only timeout?: number.

The 350fcca commit message says the feature was "driven by building a call screening agent against it", which suggests it may have been exercised against the live platform — i.e. the platform might accept these keys undocumented, and the published schema/docs lag. Or the keys are silently ignored and held calls have been resuming in place regardless of step/timeout_step.

This needs a live-platform check that an SDK reader can't settle:

1. If the platform honors step/timeout_step: the published schema/docs (and the bundled schema.json, plus the TS SDK) need updating, and the Python helper is correct as-is.
2. If the platform ignores or rejects them: the helper should drop or loudly reject the kwargs, since today it emits an action that either fails validation or silently does nothing while looking like a routed hold.

Not touching the helper until that's known — it gates a real feature (deferred step routing at hold-release) that swml_change_step() cannot replicate (that one fires immediately, moving the caller before the hold begins).

🤖 Generated with Claude Code

https://claude.ai/code/session_01MgA3KeCEPMKMJVvroZY1wV