-
Notifications
You must be signed in to change notification settings - Fork 3.4k
v0.8.64: Add a dev-server readiness primitive for local app automation #3360
Copy link
Copy link
Closed
Labels
bugSomething isn't workingSomething isn't workingenhancementNew feature or requestNew feature or requestreliabilityReliability, flaky behavior, retries, fallbacks, and robustnessReliability, flaky behavior, retries, fallbacks, and robustnesstoolsTool execution, tool schemas, tool UX, and built-in tool behaviorTool execution, tool schemas, tool UX, and built-in tool behaviortuiTerminal UI behavior, rendering, or interactionTerminal UI behavior, rendering, or interaction
Milestone
Description
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingenhancementNew feature or requestNew feature or requestreliabilityReliability, flaky behavior, retries, fallbacks, and robustnessReliability, flaky behavior, retries, fallbacks, and robustnesstoolsTool execution, tool schemas, tool UX, and built-in tool behaviorTool execution, tool schemas, tool UX, and built-in tool behaviortuiTerminal UI behavior, rendering, or interactionTerminal UI behavior, rendering, or interaction
Projects
StatusShow more project fields
Done
Problem
Agents doing local webapp work currently have to poll shell output or guess when a dev server is ready. That makes the loop flaky:
npm run devmay print before the app is actually serving, and frontend verification can race the server startup.The
webapp-testingworkflow needs a small, reusable readiness primitive that can be used by tools, bundled skills, verifier gates, and helper scripts.Proposal
Add a bounded dev-server readiness primitive, either as a small native tool, a shared helper, or both.
Initial shape:
This should avoid replacing full process supervision. It is the narrow readiness check that higher-level server lifecycle helpers and browser automation can call.
Acceptance criteria
localhost:<port>with a bounded timeout and receive structured success/failure output.Related