Current Beta Limitations
Sequential flattening
Connections determine a run order, then every tool runs in sequence. Connections do not activate routes.
Visual fan-out and convergence are therefore misleading about runtime behavior.
Separate canvas and script runs
Canvas Run and deployed script runs each have their own loop. They execute individual tools the same way, but they do not share automation scheduling or result policy.
No conditions or merge behavior
There is no condition system, default route, branch state, Merge node, Input node, or Output node.
A tool with multiple incoming visual connections receives only the output from the tool immediately before it in the flattened list.
Document cards are not input
Documents on the canvas are visual only. Canvas Run always starts with empty input.
Limited deployment input options
Deployment writes immediately to the project's standard automation folder and does not ask for input. Existing file or folder bindings are preserved, but the Automations page has no binding editor, the canvas has no input picker, and document cards cannot be bound.
Weak failure propagation
- Missing tool definitions are skipped.
- A thrown error stops the deployed runner, but the canvas catches it and continues.
- A normal tool failure result is not inspected by either loop, so a run may continue and report success.
- There is no cancellation, retry, timeout, rollback, or resume.
No automation triggers
Tool schedule and file-watch triggers target tool deployments only. They cannot invoke automation scripts.
Limited invocation surfaces
Automations can be invoked from the Automations tab's canvas Run, Tools-page automation deployments, Power Strip Automation commands, Power Strip drops, and Power Strip browser capture.
There is no Ribbon, Dashboard-widget, tool-trigger, Mobile Dashboard, or MCP automation endpoint.
Mutable live tools
Scripts reference current tools without versions. Tool edits change deployed behavior, and deleted tools are skipped.
Deployment is not atomic
Deployment writes directly to the destination JSON. There is no published revision history or rollback.
Incomplete deployment management
The Tools page can run, rename, duplicate, remove, and configure a surface-owned automation deployment. Power Strip creates and removes slot-owned placements. These controls do not manage the canvas-published library artifact: the Automations tab still cannot compare revisions, unpublish it, roll it back, edit saved input bindings, or automatically remove it when its draft is deleted. Automation placements also have no enable or disable control.
Safe Beta Pattern
For release-critical use:
- Build one straight chain.
- Use at least two connected tools.
- Avoid fan-out and convergence.
- Keep any required canvas-test input inside the tools, because Canvas Run starts empty.
- Supply explicit input from the intended surface, or verify an existing saved binding before relying on a no-input run.
- Verify every referenced tool still exists.
- Test from the actual Power Strip path you intend to use.
- Verify output artifacts. Do not rely only on the success badge.
What Is Planned
A future version replaces the flattened runner with a real graph: explicit input and output nodes, per-node output you can address, conditional connections with a default route, true parallel branches, explicit convergence, and stronger failure reporting.
Other candidates for later work include canvas input selection, project-relative paths, deployment revisions, automation schedule and file-watch triggers, mobile and MCP invocation, and cancellation, retries, and timeouts.
None of this is beta behavior.