WakerFlow

Create, run, and troubleshoot repeatable multi-stage workflows: from generating canvases and scripts with natural language, to configuring run inputs, handling user input requests, understanding business logs, and setting up automatic triggers.

Chapter goal: Create, run, and troubleshoot repeatable multi-stage workflows. If you only need to run an existing workflow, go directly to Run History. If you need to adjust the workflow, check the input form, Workers, and return structure.

WakerFlow is used to orchestrate multi-role, multi-stage workflows or workflows that require human confirmation. For a single Waker that periodically repeats a fixed task, use “Auto Tasks” instead.

Opening or Creating a WakerFlow

Click “WakerFlow” in the left navigation to enter the WakerFlow management page.

When opening an existing workflow, first confirm the target by checking the name and description. Before modifying a running workflow, review the run history. If the list is empty or fails to load, refresh the page and check local service and network status.

Creating a new workflow: In the current version, you first create a draft, then generate the workflow through conversation.

Steps:

1. Click “New WakerFlow” on the WakerFlow list page.
2. Enter your goal in the blank workspace, clearly describing the run inputs, processing steps, role assignments, error handling, and output format.
3. Wait for the system to generate the canvas and script. Open “Script” and check the input fields, target Wakers, and the final return.
4. Edit the name at the top and add a description of the workflow’s purpose in “Detail Settings”.
5. Click “Run” in the top-right corner to complete one manual test run.

When describing the workflow, it is recommended to state in order: the goal, run inputs, processing steps, error handling, and final output. When human judgment is needed, also specify the confirmation node, question content, and how to handle timeout or skip scenarios.

Completion check:

• The canvas has generated phases and nodes, and the script is not empty.
• The run form contains the required fields, and every Worker points to a Waker in the current environment.
• The script has an explicit return whose content meets delivery requirements.

When generated results do not meet expectations:

In the customization conversation on the left, describe the nodes, execution order, inputs, or outputs to adjust. Adjust only one type of issue at a time, and re-check the canvas, script, and run form after modifications.

Understanding the Detail Page

The WakerFlow detail page is divided into three areas:

Area	Primary use
WakerFlow	View or adjust the canvas, script, and versions
Run History	View run status, logs, results, and errors
Detail Settings	Modify description, trigger methods, and default parameters

The top-right “Run” button is for manually executing the current workflow. “Add Trigger” or “Manage Triggers” is for configuring automatic runs. These are not the same operation.

Canvas

The canvas parses the script into phases and node relationships, making it easy to quickly understand the workflow structure.

Common nodes include:

Node	Meaning
Phase	Business stage
Worker	A task assigned to a Waker for execution
Parallel / Pipeline	Parallel processing or batch multi-stage processing
Ask User	Pause and wait for human input
Action / Sub-workflow	Execute an action or call another workflow

Conditions, error handling, and return structures not shown on the canvas are governed by the script. “Run Configuration” contains fillable fields, not the actual parameters of a past run.

Adjusting Scripts and Versions

1. Describe the modification requirements in the customization conversation on the left, or directly edit the “Script”.
2. After saving, check the canvas, run inputs, and return, then do a manual test run.
3. When you need to restore a previous version, preview and roll back in “Version History”.

Run History

Run history shows the run ID, trigger method, and node status. Click a node to view its input, session, result, or error. The logs and final return value for the entire workflow are available in the run details.

Configuring Run Inputs and Final Output

The run form is generated from meta.inputSchema in the script; filled values are passed in via args. The final deliverable is determined by return.

1. In inputSchema, set field types, descriptions, default values, and required fields.
2. Click “Run” and check whether the form fields and default values are correct.
3. After running, check whether the “Final Return Value” meets expectations.

Objects or arrays must contain valid JSON. When fields are missing, formats are incorrect, or types do not match, the page will block submission or show a validation failure.

Orchestration Capabilities Quick Reference

When modifying scripts, use the following capabilities as needed:

Capability	Function
phase / log	Mark phases and record business logs
worker	Dispatch a Waker task and wait for the result
parallel / pipeline	Parallel processing or batch multi-stage processing
askUser	Pause the workflow and wait for human input
workflow	Call another WakerFlow
action	Execute a declared HTTP or local action

Before saving, check that Waker IDs, sub-workflow IDs, Action addresses, and local paths belong to the current environment. Secrets must not be hardcoded in scripts.

Manual Run and Handling User Input

Manual Run

1. Click “Run” in the top-right corner of the detail page.
2. Fill in run parameters. Required fields cannot be empty; objects and arrays must use valid JSON.
3. After submission, view node progress in “Run History”.
4. After the run completes, check the status and “Final Return Value”.

Run statuses:

Status	Meaning	Action to take
Queued / Running	Created and progressing	If stuck, check the current node and service status
Waiting for Input	The workflow is waiting for a human response	Open the question and submit or skip
Completed	The script has finished	Check whether the final return value is correct
Failed / Terminated	The run encountered an error or was cancelled	View the failed node, fix, and retry

“Completed” only means the script finished successfully — it does not automatically prove the business content is correct. You still need to check whether the final return value contains the expected fields, quantities, and evidence.

Waiting for User Input

askUser() can generate text prompts, options, or approval cards. The script should clearly define the question, options, timeout, and default handling behavior.

After the workflow enters “Waiting for Input”, submit your answer in Run History or the approval dashboard. Unattended workflows should use this node cautiously to avoid remaining in a waiting state for extended periods.

“Terminate” does not undo files already written, messages already sent, or external actions already executed. “Retry” may reuse nodes completed in the previous round. If inputs or the script have been modified, start a new run instead.

Correctly Understanding Run Configuration, Business Logs, and Results

This is the most commonly confused part when reading WakerFlow run records.

Where Each Type of Information Comes From

Information	Source and meaning	Is NOT
Run Configuration	Form fields and values filled in this run	The final output
Business Logs	Progress or summary recorded by log() in the script	The complete input and final result
Worker Instruction	The task instruction for a single Worker	The entire workflow’s complete input
Worker Result	The return value of a single Worker	The Worker’s complete execution process
Final Return Value	The content of the script’s return	Necessarily a complete breakdown; content is determined by the script
Raw Events	Event stream of phases, dispatches, logs, results, and failures	The Worker’s full internal records

When the script does not explicitly return, the run may still succeed, but the final return value will be null.

Two adjacent “Log” sections on the page do not equate to “input configuration” and “complete output” — they may both be business summaries proactively written by the script.

The three entries in the screenshot come from log() calls like the following:

log(`Run mode: ${args.mode} | Run ID: ${runLabel}`)
log(`Competitor scan: yes | Pending requirements: ${pendingCount} | Existing capabilities: ${capabilityCount}`)
log(`Code repository: ${repoPath} | Generate plan: yes | Persist: yes`)

These are all summaries designed by the script and do not represent complete input or output. The +2m33s on the right is the time of the event relative to workflow start, not the duration of that log entry.

Where to View Actual Results

What you need to view	Entry point
A single Worker’s input and result	Run History → Target run → Phase → Worker → Instruction / Session / Result / Error
The entire workflow’s deliverable	Run details → “Final Return Value”; when failed or cancelled, view the corresponding reason
Full-process diagnostics	Run details → “Raw Events”; locate the issue from the last successful event and first failed event

Log writing recommendations:

• Logs should only record phases, counts, key decisions, and exceptions — do not write complete large objects or credentials.
• Use log levels info, warn, error.
• Content that needs to be delivered must be explicitly returned — do not rely on logging alone.

Configuring Automatic Runs

A single WakerFlow can have multiple trigger methods. The quantity and type limits are shown on the current page.

1. First complete a manual test run and confirm the final return value is correct.
2. Click “Add Trigger” in the top-right corner, or go to “Detail Settings” → “Manage Triggers”.
3. Configure default parameters and add scheduled, API, GitHub, or page-provided event trigger methods.
4. Save and enable, then wait for a real trigger or use the test entry provided on the page.
5. Return to “Run History” and verify the trigger method, run ID, status, and final return value.

Field values set in the trigger method override automatic run default parameters, which in turn override script default values. For the same field, choose only one of a fixed value or Payload mapping. When automatic triggers fail, first check the trigger configuration, default parameters, and run history.

Pre-launch checklist:

• Keep phase and node names clear; use Schema to constrain downstream data.
• Retain human confirmation before external writes, message sends, or publishing.
• For important changes, preserve a version and do a manual test run first. Retries do not undo external operations that have already occurred.