Follow-up surfaced by the Phase-D.1 bootstrap planning pass (the 4th locked decision; see the Wave-5 design addendum "Phase D.1 — bootstrap structure + locked decisions").
Context
The SDK's neutral AdapterCallResult is status-only for now: {ok, Status::Code error_code, std::string error_message}. The shared call-handler stamps a constant accepted=true. This is the right minimal shape to ship the SDK device-model lift (D.2) without blocking on a payload design.
But the need is real, not hypothetical: ezo's call handler already special-cases a per-function result payload — handlers.cpp:581-583 sets results["enabled"] for SetLed, beyond the constant accepted. So a status-only AdapterCallResult cannot carry ezo's function-specific call results once ezo migrates onto the SDK descriptor.
Decision deferred to here
Add an optional, nullable results payload to AdapterCallResult (e.g. a Map<string, Value> mirroring the read path's value typing), and have the SDK call-handler merge it over the constant accepted=true. Keep it nullable so sim/bread (which return no call payload today) are unaffected.
Temp shim until then
ezo keeps its handler-side set_led → results["enabled"] if as a temporary shim during its migration (it does not move into the adapter yet). Remove the shim when this lands.
Acceptance
Part of epic anolis-protocol#45 (Wave 5). Not a blocker for D.2 / the SDK lift — it's a post-migration convergence item.
Follow-up surfaced by the Phase-D.1 bootstrap planning pass (the 4th locked decision; see the Wave-5 design addendum "Phase D.1 — bootstrap structure + locked decisions").
Context
The SDK's neutral
AdapterCallResultis status-only for now:{ok, Status::Code error_code, std::string error_message}. The shared call-handler stamps a constantaccepted=true. This is the right minimal shape to ship the SDK device-model lift (D.2) without blocking on a payload design.But the need is real, not hypothetical: ezo's call handler already special-cases a per-function result payload —
handlers.cpp:581-583setsresults["enabled"]forSetLed, beyond the constantaccepted. So a status-onlyAdapterCallResultcannot carry ezo's function-specific call results once ezo migrates onto the SDK descriptor.Decision deferred to here
Add an optional, nullable
resultspayload toAdapterCallResult(e.g. aMap<string, Value>mirroring the read path's value typing), and have the SDK call-handler merge it over the constantaccepted=true. Keep it nullable so sim/bread (which return no call payload today) are unaffected.Temp shim until then
ezo keeps its handler-side
set_led→results["enabled"]ifas a temporary shim during its migration (it does not move into the adapter yet). Remove the shim when this lands.Acceptance
AdapterCallResultgains a nullableresultspayload; SDK call-handler merges it.enabledspecial-case moves from the handler into its adapter'scall.Part of epic anolis-protocol#45 (Wave 5). Not a blocker for D.2 / the SDK lift — it's a post-migration convergence item.