Skip to content

Add Dynamic Workflow Console (workflow-console) - #54

Open
stevenjj33 wants to merge 3 commits into
MiniMax-AI:mainfrom
stevenjj33:feat/workflow-console
Open

stevenjj33 wants to merge 3 commits into
MiniMax-AI:mainfrom
stevenjj33:feat/workflow-console

Conversation

@stevenjj33

@stevenjj33 stevenjj33 commented Oct 21, 2026 •

Copy link
Copy Markdown
Contributor

What this is

workflow-console is a Mini App that runs, supervises, and inspects MiniMax Code dynamic workflows from one page.

Based on which project

This package is built on top of the mcode-dynamic-workflows plugin by hetaoBackend (version 0.8.2, Apache-2.0), from https://github.com/MiniMax-AI/MiniMax-Code-Plugins/tree/main/plugins/hetaoBackend/mcode-dynamic-workflows.

That plugin is an MCP server that orchestrates multi-agent workflows. It normally has to be installed as a MiniMax Code plugin and reached through MCP. This package vendors its runtime and runs it as a self-contained Mini App:

  • The upstream dist/ runtime is vendored unmodified into miniapp/node/vendor/dynamic-workflows/ and started as a child process, so the app works on machines where the plugin was never installed.
  • The upstream web/ canvas model (graph-model.mjs) is imported directly, so the flow graph in this console is the same graph model Workflow Studio draws, not a second implementation.
  • The console adds what the plugin does not provide: a per-project run list, a live event stream, run approval and control, template management, report export, and a working-directory picker.

miniapp/node/vendor/dynamic-workflows/VENDOR.md records the vendored files and every behavioural difference between the upstream plugin and this console.

What it does

  • Starts its own Workflow Studio engine and binds it to a project directory
  • Run list per project, with status filters, a live event log, and per-node results
  • A stage-and-dependency flow graph (SVG, the same model as the Studio canvas)
  • Approve and run a draft, pause / cancel / resume, export Markdown or HTML
  • Save a run as a template, and create a new draft from a template without running it
  • An always-visible working-directory bar, so switching projects is one field

The user interface is in Chinese; README.zh-CN.md is the Chinese README.

Install

Copy plugins/stevenjj33/workflow-console/ (including the hidden .minimax-plugin/) into the MiniMax Code plugins directory as workflow-console/ (~/.minimax/plugins/workflow-console/ by default). Restart MiniMax Code and ask the Agent to "打开动态工作流控制台".

There is no configuration step and no build step. On first launch it needs a project directory: the console resolves one from the running Workflow Studio services, then from the project registry left by earlier plugin runs, and otherwise falls back to your home directory and asks you to type an absolute path in the working-directory bar at the top of the page. Saving that bar restarts the embedded engine against the new directory; run history lives in the engine's own database and is not affected.

Running real workflows still needs a working mcode CLI on the machine, because the engine orchestrates agents through it. The demo executor works without it.

Tested environment

  • MiniMax Code 3.1.4 on Windows 11, Node.js 22 and 26. Installed from this directory, opened through the Agent, page rendered, engine started, run approved and executed with the demo executor.
  • MiniMax Code on macOS (arm64), Node.js 22.22.3, on a machine where the upstream plugin had never been installed: service discovery, working-directory resolution and the same demo-executor run were verified there.
  • Browser: Chromium-based desktop browser, 1280x720 and 589x899 viewports, light and dark themes. Console: 0 errors, 0 warnings.

Tests

node --test "tests/*.test.mjs"

10/10 pass. The tests boot an isolated console instance in a sandbox home directory, so they never touch a real project.

  • service-discovery.test.mjs — service discovery on a machine without the upstream plugin. This is the case that used to break: discoverOnce() returned early when ~/.mcode-dynamic-workflows/projects did not exist, which skipped the code that registers the embedded engine. /api/bootstrap then returned services: [] and the console showed "no Workflow Studio project service found" even though the engine was running, with its address file written and its database created.
  • workspace-resolution.test.mjs — working-directory resolution, including the Host's temporary deployment directory, which must never be used as a project.
  • manual-mac-scenario.mjs — starts a console whose working directory is a temporary deployment directory and prints the URL to open for manual inspection.

Not verified

  • Real model execution. Every execution in testing used the demo executor, which does not call a model.
  • Pause / resume / cancel on the real executor. Verified on the demo executor only; the real executor may differ in how it interrupts a run.
  • mcodeAvailable: true only means the mcode binary exists on the machine. Its login state and quota are not checked by this app.
  • The narrow-viewport layout was not re-tested in the latest round.

About the two warnings

npm run check reports plugins/stevenjj33/workflow-console: 0 errors, 2 warnings.

Both are ENTRY_STDOUT in miniapp/node/vendor/dynamic-workflows/dist/main.mjs and .../sandbox.mjs. Those files are the unmodified upstream runtime, kept byte-identical so the vendored copy stays redistributable under its own Apache-2.0 license. The check scans the whole Node payload tree, so it sees the console.log calls the upstream CLI uses. In the mode this app runs the engine in (--workspace), the child's stdout is redirected to engine/service.log under context.dataDir, so nothing reaches the Host's stdout.

Two failures in the repository's own npm test (files: a symlink inside the package is an error and files: a package root that is itself a symlink is rejected before walking) are a Windows limitation, not a problem with this package: the test creates symlinks with fs.symlink, which needs Developer Mode or administrator rights. They fail the same way on a clean checkout without this package.

Files

.minimax-plugin/plugin.json                 Plugin manifest
package.json                                Mini App declaration
miniapp/miniapp.json                        Payload roots, Node entry, page route
miniapp/client/index.html                   The page served at /dashboard
miniapp/client/app.js                       Front end (plain HTML/CSS/JS, no framework, no build)
miniapp/client/style.css                    Styling, light and dark themes
miniapp/node/server.mjs                     Node entry: start(context) -> { dispose }
miniapp/node/miniapp-api.ts                 Type declarations for the runtime context
miniapp/node/vendor/dynamic-workflows/      Vendored upstream runtime (0.8.2, Apache-2.0)
tests/workspace-resolution.test.mjs         Working-directory resolution
tests/service-discovery.test.mjs            Service discovery without the upstream plugin
tests/manual-mac-scenario.mjs               Isolated instance that mimics a fresh macOS host
icon.png                                    Plugin icon

License

MIT for this package. The vendored upstream runtime keeps its own Apache-2.0 license; attribution is in miniapp/node/vendor/dynamic-workflows/THIRD_PARTY_NOTICES.txt.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

@stevenjj33
stevenjj33 force-pushed the feat/workflow-console branch 2 times, most recently from b7db350 to 0c95f20 Compare October 21, 2026 10:25
A Mini App that runs, supervises, and inspects MiniMax Code dynamic workflows
from one page, built on the mcode-dynamic-workflows plugin runtime (0.8.2,
Apache-2.0) by hetaoBackend.

The upstream runtime is vendored unmodified into
miniapp/node/vendor/dynamic-workflows/ and started as a child process, so the
app works on machines where the plugin was never installed. The upstream web
canvas graph model is imported directly, so the flow graph here is the same one
Workflow Studio draws.

The console adds what the plugin does not provide: a per-project run list, a
live event stream, run approval and control, template management, report
export, and a working-directory picker.
@stevenjj33
stevenjj33 force-pushed the feat/workflow-console branch from 0c95f20 to 3235a68 Compare October 21, 2026 10:26
The registry fixture pointed at a loopback port that happens to be in use on the
machine the tests were written on. Any loopback port that nothing listens on
works the same way, so use the discard port instead.
The registry fixture pointed at a loopback port that happens to be in use on the
machine the tests were written on. Any loopback port that nothing listens on
works the same way, so use the discard port instead.

@MyPrototypeWhat MyPrototypeWhat left a comment •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @stevenjj33, welcome, and thanks for your first contribution! A live console for dynamic workflows is a useful idea. It's good to see Apache-2.0 attribution for the bundled runtime (LICENSE, THIRD_PARTY_NOTICES, VENDOR.md), the strict 127.0.0.1 checks on upstream addresses, the revision check on approve, and the test suite. Locally npm run check passes (0 errors; the 2 ENTRY_STDOUT warnings are in the bundled dist/ files) and node --test tests passes 10/10.

There are a few things to address before this can merge:

Must-fix

  1. Falling back to the home directory. When no project is found, the engine's workspace becomes homedir() (miniapp/node/server.mjs:291-294), so a run started there could act on the whole home folder. Please refuse to start the engine, or block Start, until the user picks a project directory.
  2. Reading another plugin's service data, including its access token. discoverOnce() and probeRegisteredWorkspace() scan ~/.mcode-dynamic-workflows/projects/*/address.json|endpoint.json (server.mjs:162, 323-335, 627-649). They take the bearer token from the stored URL and use it to call those services (server.mjs:190, 213, 649). That data and token belong to the separate mcode-dynamic-workflows plugin. Please use only the bundled engine under context.dataDir. If you'd like to keep the "connect to an existing service" option, make it something the user explicitly enters rather than an automatic scan.

Suggestions

  • Tell users what runs without asking. The bundled runtime runs the CLI with --permission smart (miniapp/node/vendor/dynamic-workflows/dist/main.mjs:14056), so during a run some file writes and commands are approved automatically, and any step that would need the user's confirmation fails that node instead. That's a sensible choice for a headless run, but the start dialog (miniapp/client/app.js:1586-1594) only mentions model usage. Please say this in the dialog and the README (the runtime already has a similar note at main.mjs:15008).
  • Version of the bundled runtime. VENDOR.md says 0.8.2, "copied unmodified from the local plugin cache", but dist/main.mjs:26447 reports 0.8.0. The upstream repo's main is 0.8.0 and differs from the bundled dist/main.mjs in several hundred lines, so I couldn't confirm it's a verbatim copy. Could you note the exact upstream commit or release it came from, or build it from a published source?
  • Bundle size. The bundle is about 2 MB (a 27k-line main.mjs plus quickjs.wasm) and is pinned to a copy that won't get upstream fixes. Bundling seems reasonable for a standalone app, but please write down how it will be kept up to date. examples/reflection.js from upstream is also missing.
  • Data & access. Once must-fix 2 is addressed, please update the "Data & access" section of the README (README.md:72-77) to match.
  • Display name. The displayName/description in plugin.json are Chinese only; an English name would help non-Chinese readers of the catalog.

Thanks again! Happy to take another look after the update.

title: '开始执行该工作流',
note:
`运行「${run.name}」,静态拓扑共 ${nodeCount} 个节点。` +
(real

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion (non-blocking): with --permission smart (vendor/dynamic-workflows/dist/main.mjs:14056), some file writes and commands are approved automatically during the run, and steps that would need confirmation fail the node. Worth saying so here, since this dialog only mentions model usage.

return cwd;
}
/* 兜底只能落在用户主目录,同时告诉前端「还没绑定到真实项目」。 */
engineWorkspace = homedir();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Falling back to the home directory means a real run could act on the whole home folder. Please refuse to start, or block Start, until a project directory is chosen.

const record = {
id: name.slice(0, 12),
origin: target.origin,
token: target.token,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This takes another plugin's service token from ~/.mcode-dynamic-workflows/projects/*/address.json and uses it. Please limit the console to the bundled engine under context.dataDir, or make connecting to an external service something the user explicitly enters.

## 版本与来源

- 上游:`MiniMax-AI/MiniMax-Code-Plugins` → `plugins/hetaoBackend/mcode-dynamic-workflows`
- 版本:**0.8.2**(从本机插件缓存原样复制,未做任何修改)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dist/main.mjs:26447 reports version 0.8.0, and upstream main (0.8.0) differs from this copy. Could you note the exact upstream commit or release this came from?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants