Environment: kane-cli 0.4.10
Summary
kane-cli generate dropped an API-GET reconciliation step, labeling it UNSUPPORTED_OPERATION — but the v16 runtime does make API calls. @v16_api[...] / execute_api returned a full JSON HTTP response in a live run.
Actual
Planner omits valid API steps as unsupported.
Expected
The planner should author API steps that the runtime already supports.
Notes / confirmation the runtime supports it
A testmd / run step fetched GET /api/loans/LOAN-2001/schedule and returned status 200 + the JSON body into run memory. So the planner is understating real capability and omitting valid steps.
Correction / clarification (2026-07-06): the "status 200 + JSON body" result above is only reproducible when the API request is pre-defined and named in KaneAI web. When the same call is issued from a _test.md step with an inline URL, execute_api drops the URL and hits a LambdaTest default host, returning 404 — see #132. So the runtime's API capability is real, but sourcing the endpoint from the step does not currently work; that nuance should inform whatever the planner authors. A related limitation on the passive side (DevTools→Network capture resets per agent-step, so asserting on an XHR triggered by a prior action is unreliable) is tracked in #133.
Environment: kane-cli 0.4.10
Summary
kane-cli generatedropped an API-GET reconciliation step, labeling itUNSUPPORTED_OPERATION— but the v16 runtime does make API calls.@v16_api[...]/execute_apireturned a full JSON HTTP response in a live run.Actual
Planner omits valid API steps as unsupported.
Expected
The planner should author API steps that the runtime already supports.
Notes / confirmation the runtime supports it
A
testmd/runstep fetchedGET /api/loans/LOAN-2001/scheduleand returned status 200 + the JSON body into run memory. So the planner is understating real capability and omitting valid steps.Correction / clarification (2026-07-06): the "status 200 + JSON body" result above is only reproducible when the API request is pre-defined and named in KaneAI web. When the same call is issued from a
_test.mdstep with an inline URL,execute_apidrops the URL and hits a LambdaTest default host, returning404— see #132. So the runtime's API capability is real, but sourcing the endpoint from the step does not currently work; that nuance should inform whatever the planner authors. A related limitation on the passive side (DevTools→Network capture resets per agent-step, so asserting on an XHR triggered by a prior action is unreliable) is tracked in #133.