feat: WaitForInput step kind for human-in-the-loop workflows#36
Merged
Conversation
Rust (distri-workflow): - Add EntryPoint struct with starts_at, preset_results, required_inputs - Add entry_points field to WorkflowDefinition - Add skip_if field to WorkflowStep for conditional step skipping - Add evaluate_skip_condition() supporting truthy/negation/equality/inequality - Add apply_entry_point() to skip unreachable steps and pre-populate context - Update runnable_steps() to treat Skipped deps as met - Update executor to evaluate skip_if before running steps - Store input under "input" namespace in with_input() for namespace resolution - Add 17 new tests (entry points, skip_if, serialization roundtrips) distri-home: - Add WorkflowEntryPointSelector component for multi-entry workflow UI - Shows entry point cards with step counts and preview - Required inputs hints for each entry point - Visual step preview with status icons https://claude.ai/code/session_01LujMqScYWaqfUcqoBDndAU
Adds WaitForInput variant to StepKind and WaitingForInput to StepStatus. When the executor encounters a WaitForInput step, it marks the step as WaitingForInput, sets workflow status to Paused, emits StepWaiting event, and stops. The resume() method on WorkflowRunner accepts the step ID and human input, marks the step Done, stores the result in context, and continues executing remaining steps. Changes: - distri-workflow types: WaitForInput StepKind, WaitingForInput StepStatus, resume_step(), is_waiting_for_input(), waiting_step() on WorkflowDefinition - distri-workflow executor: WaitForInput detection in run_next(), resume() method, StepWaiting event variant - distri-workflow tests: 8 new tests (pause, resume, multi-wait, entry point + wait, serialization, schema, error cases) - distri client executor: WaitForInput match arm - distri-core workflow_agent: WaitForInput + StepWaiting handling - distri-cli: StepWaiting display in workflow run output - distri-home: waiting_for_input status icon in WorkflowEntryPointSelector 93 tests passing. https://claude.ai/code/session_01LujMqScYWaqfUcqoBDndAU
5 tasks
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Delegates to agent_store.delete() for local server agent deletion. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds interactive y/N prompt before deletion. Skip with --yes/-y flag. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… substitution Adds resolve.rs with functions for extracting $VAR_NAME references from strings and JSON values, resolving them from env vars and secret stores with priority ordering, and substituting resolved values back. This is the foundation for the unified request tool's variable resolution. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* chore: refactor http request tool * chore: server side request tool * fix: drop RwLockReadGuard before .await in ExternalToolRegistry The std::sync::RwLockReadGuard is !Send and was held across an .await in try_handle(), making stream_agent's future non-Send. Clone the handler before dropping the guard. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add distri-formatter crate with Formatter trait and TextFormatter Extract shared event formatting logic into a new crate that can be used by both the CLI (distri) and the gateway (distri-gateway). Includes: - Formatter trait for pluggable output formats - ChatState and helper types extracted from printer.rs - TextFormatter for plain-text output (Telegram, WhatsApp, logs) - format_tool_call/is_probe_call pure-logic helpers Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: extract variable resolution functions to distri-types Move pure functions (extract_vars, extract_vars_from_value, substitute_string, substitute_value) from distri-core to distri-types::resolve, re-exporting them from distri-core to preserve the existing API. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: update distri a2a * feat: add POST /secrets/resolve batch endpoint Adds a new endpoint that resolves raw secret values for specified keys, allowing clients to resolve $VAR_NAME references in a single round-trip. Missing keys are silently omitted from the response. - distri-server: POST /secrets/resolve handler - distri client: resolve_secrets() method Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add client-side SecretCache and HTTP request handler Adds local execution of http_request tool calls with secret resolution via the Distri cloud API, eliminating server round-trips for HTTP requests. - SecretCache: caches resolved secrets and connection tokens with TTL - client_http_request: mirrors server-side HttpRequestTool input/output contract with $VAR_NAME resolution and x-connection-id Bearer injection - Wired into distri-cli for both Run and Tui commands Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: typed HttpRequestInput/Response, remove HttpRequestTool, update tests Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: typed HttpRequestInput/Response, POST /request proxy, remove HttpRequestTool Replace SecretCache-based resolution with typed proxy_request on the client and a POST /request endpoint on the server. Client auto-detects local vs proxy execution. TypeScript parity added in distrijs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: validate builtin tool names on agent push/update/validate Adds VALID_BUILTIN_TOOLS canonical list in distri-types. Agent create, update, and validate endpoints now reject unknown builtin tool names with a clear error message listing valid options. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: restore HttpRequestTool as server-side builtin The LLM needs the tool definition in the builtin list to know it exists. When a CLI client is connected, it intercepts via ExternalToolRegistry and executes client-side or proxies via POST /request. When no client is connected (self-hosted), the server executes directly using the typed execute_http_request. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: let server handle http_request instead of client-side interception The server has full ExecutorContext with env_vars from --context. Client-side interception doesn't have access to those env_vars, causing unresolved variable errors. Let the server builtin handle it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: pass --context env_vars to client-side http_request handler The env_vars from --context (REQUEST_BASE_URL, etc.) are now passed to register_client_http_request so the client can resolve $VAR_NAME references locally without round-tripping to the server. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: add detailed error messages to client http_request handler Errors now include method, URL, and reason (invalid input, unresolved vars, proxy failure, HTTP failure) instead of generic "builder error". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: typed RunContext struct for --context parsing, support env_vars key Replaces raw JSON .get()/.as_object() chains with proper typed deserialization. Accepts "envs", "env_vars", and "secrets" keys — all merge into env_vars for both server metadata and client-side http_request handler. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: handle relative URLs, typed RunContext, pass env_vars to client handler - Relative URLs (starting with /) auto-prepend REQUEST_BASE_URL from env_vars - Typed RunContext struct for --context parsing (accepts envs, env_vars, secrets) - Client-side http_request handler receives env_vars from --context Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: remove client-side http_request interception, server executes it The server has full ExecutorContext with env_vars from --context. Client-side interception can't work because is_external()=false means the server executes the tool before the client can intercept. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add dynamic tool factories with HTTP factory type Replace the builtin http_request tool with a dynamic factory system. Agent definitions can now declare named HTTP tools with baked-in base_url and headers via [[tools.dynamic]] config blocks. The factory resolves $VAR_NAME references and reuses execute_http_request for actual execution. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: clean up client_http_request.rs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: remove dead client-side http_request handler and unused code Removed: client_http_request.rs, register_client_http_request, register_http_request_handler, proxy_request, SecretCache references, client_env_vars. All HTTP requests now go through dynamic tool factories executed server-side. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
WaitForInputvariant toStepKindwith message and optional JSON schemaWaitingForInputvariant toStepStatusWorkflowRunner::resume()accepts step ID + human input, continues executionWorkflowDefinition::resume_step()marks waiting step Done and stores result in contextis_waiting_for_input(),waiting_step()query methodsHow it works
run_all()executes steps until hitting aWaitForInputstepWaitingForInput, workflowPaused,StepWaitingevent emittedrunner.resume(workflow_id, step_id, json_input)context.steps.<step_id>for downstream{steps.X.Y}refsTest plan
cargo checksucceeds for full workspacehttps://claude.ai/code/session_01LujMqScYWaqfUcqoBDndAU