|
| 1 | +# Dynamic Workflow Console (`workflow-console`) |
| 2 | + |
| 3 | +A Mini App that runs, supervises, and inspects MiniMax Code dynamic workflows from one page. |
| 4 | + |
| 5 | +It embeds the `mcode-dynamic-workflows` runtime, so it works on a machine where that plugin was |
| 6 | +never installed. Open the app and the console starts its own Workflow Studio engine, binds it to a |
| 7 | +project directory, and shows every run of that project: status, live event log, a stage-and-dependency |
| 8 | +flow graph, per-node output, and the final report. Runs can be approved, started, paused, cancelled, |
| 9 | +resumed, exported to Markdown or HTML, saved as a template, and restored from a template. |
| 10 | + |
| 11 | +The user interface is in Chinese. |
| 12 | + |
| 13 | +## Based on which project |
| 14 | + |
| 15 | +This package is built **on top of the `mcode-dynamic-workflows` plugin** by `hetaoBackend`, from |
| 16 | +<https://github.com/MiniMax-AI/MiniMax-Code-Plugins/tree/main/plugins/hetaoBackend/mcode-dynamic-workflows> |
| 17 | +(version 0.8.2, Apache-2.0). |
| 18 | + |
| 19 | +That plugin is an MCP server that orchestrates multi-agent workflows. It normally has to be installed |
| 20 | +as a MiniMax Code plugin and reached through MCP. This package takes its runtime and runs it as a |
| 21 | +**self-contained Mini App**: |
| 22 | + |
| 23 | +- The upstream `dist/` runtime is vendored unmodified into |
| 24 | + `miniapp/node/vendor/dynamic-workflows/`, and the console starts it as a child process. |
| 25 | +- The upstream `web/` canvas (`graph-model.mjs`) is imported directly, so the flow graph in this |
| 26 | + console is the same graph model Workflow Studio draws, not a second implementation. |
| 27 | +- The console adds what the plugin does not provide: a per-project run list, a live event stream, |
| 28 | + run approval and control, template management, report export, and a running-directory picker. |
| 29 | + |
| 30 | +`miniapp/node/vendor/dynamic-workflows/VENDOR.md` records the vendored files and every behavioural |
| 31 | +difference between the upstream plugin and this console. |
| 32 | + |
| 33 | +## Install |
| 34 | + |
| 35 | +Copy this directory, including the hidden `.minimax-plugin/`, into the MiniMax Code plugins |
| 36 | +directory as `workflow-console/` (`~/.minimax/plugins/workflow-console/` by default; the root |
| 37 | +README's Install section explains where that directory is). Restart MiniMax Code and ask the Agent |
| 38 | +to "打开动态工作流控制台" (open the Dynamic Workflow Console). |
| 39 | + |
| 40 | +The app has no configuration step and no build step. On first launch it needs a project directory: |
| 41 | +the console resolves one from the running Workflow Studio services, then from the project registry |
| 42 | +left by earlier plugin runs, and otherwise falls back to your home directory and asks you to type an |
| 43 | +absolute path in the always-visible **Working directory** bar at the top of the page. Saving that bar |
| 44 | +restarts the embedded engine against the new directory; run history is kept in the engine's own |
| 45 | +database and is not affected by the change. |
| 46 | + |
| 47 | +Running real workflows still requires a working `mcode` CLI: the engine orchestrates agents through |
| 48 | +it. The demo executor works without it. |
| 49 | + |
| 50 | +## Tested environment |
| 51 | + |
| 52 | +- MiniMax Code 3.1.4 on Windows 11, Node.js 22 and 26. Installed from this directory, opened |
| 53 | + through the Agent, page rendered, engine started, run approved and executed with the demo |
| 54 | + executor. |
| 55 | +- MiniMax Code on macOS (arm64), Node.js 22.22.3. Installed from this directory on a machine where |
| 56 | + the upstream plugin had never been installed; service discovery, working-directory resolution, |
| 57 | + and the same demo-executor run were verified there. |
| 58 | +- Browser: Chromium-based desktop browser, 1280x720 and 589x899 viewports, light and dark themes. |
| 59 | + |
| 60 | +Not verified: real model execution, and the pause/resume/cancel path on the real executor. Every |
| 61 | +execution in testing used the `demo` executor, which does not call a model. `mcodeAvailable: true` |
| 62 | +only means the `mcode` binary exists on the machine; its login state and quota are not checked by |
| 63 | +this app. |
| 64 | + |
| 65 | +## Data & access |
| 66 | + |
| 67 | +### Files |
| 68 | + |
| 69 | +Read: |
| 70 | + |
| 71 | +- `miniapp/client/` and `miniapp/node/vendor/` — this package's own assets. |
| 72 | +- `~/.mcode-dynamic-workflows/projects/<sha256>/address.json` and `endpoint.json` — **a Host-side |
| 73 | + directory with no supported API**. It is located as `<home>/.mcode-dynamic-workflows/projects/` |
| 74 | + and read only to learn which project other Workflow Studio services are bound to, and to pick a |
| 75 | + default working directory. This relies on an unspecified layout that MiniMax Code may change at |
| 76 | + any time. If the directory does not exist, the app works normally and the working directory falls |
| 77 | + back to your home directory. |
| 78 | + |
| 79 | +Written — always under `context.dataDir`, never elsewhere: |
| 80 | + |
| 81 | +- `selection.json` — the service id the console points at. |
| 82 | +- `workspace.json` — the working directory the embedded engine is bound to. |
| 83 | +- `hidden-runs.json` — the list of runs hidden locally. Hiding is not deletion; the run record |
| 84 | + stays in the engine's database and can be restored. |
| 85 | +- `engine/` — `address.json`, `endpoint.json`, `service.log`, and `workflows.sqlite`, written by the |
| 86 | + embedded engine. |
| 87 | + |
| 88 | +### Network |
| 89 | + |
| 90 | +Loopback only. The embedded engine binds `http://127.0.0.1:<port>` and the console proxies the |
| 91 | +page to it. Discovered Workflow Studio services are contacted on `http://127.0.0.1` as well. No |
| 92 | +outbound internet host is contacted. |
| 93 | + |
| 94 | +### Processes |
| 95 | + |
| 96 | +One child process, spawned with an argv array and no shell: |
| 97 | + |
| 98 | +``` |
| 99 | +node <pluginRoot>/miniapp/node/vendor/dynamic-workflows/dist/main.mjs --workspace <directory> --data-dir <directory> |
| 100 | +``` |
| 101 | + |
| 102 | +`<directory>` is the working directory shown in the page's top bar: either typed by the user or |
| 103 | +resolved from a discovered service. User input is passed as a separate argv element, never |
| 104 | +concatenated into a command line. The process tree is terminated when the app is disposed. |
| 105 | + |
| 106 | +### Agent turns |
| 107 | + |
| 108 | +None. The package declares no `agentAccess` and starts no Agent turn itself. The embedded engine |
| 109 | +may invoke the local `mcode` CLI when a run uses the real executor, which is the behaviour of the |
| 110 | +upstream plugin and is documented by it. |
| 111 | + |
| 112 | +### State |
| 113 | + |
| 114 | +Everything durable lives in `context.dataDir` (see **Files** above). The page keeps no domain data |
| 115 | +in browser storage. |
| 116 | + |
| 117 | +## Files |
| 118 | + |
| 119 | +```text |
| 120 | +.minimax-plugin/plugin.json Plugin manifest |
| 121 | +package.json Mini App declaration |
| 122 | +miniapp/miniapp.json Payload roots, Node entry, page route |
| 123 | +miniapp/client/index.html The page served at /dashboard |
| 124 | +miniapp/client/app.js Front end (plain HTML/CSS/JS, no framework, no build) |
| 125 | +miniapp/client/style.css Styling, light and dark themes |
| 126 | +miniapp/node/server.mjs Node entry: start(context) -> { dispose } |
| 127 | +miniapp/node/miniapp-api.ts Type declarations for the runtime context |
| 128 | +miniapp/node/vendor/dynamic-workflows/ Vendored upstream runtime (0.8.2, Apache-2.0) |
| 129 | +tests/workspace-resolution.test.mjs Working-directory resolution |
| 130 | +tests/service-discovery.test.mjs Service discovery on a machine without the upstream plugin |
| 131 | +tests/manual-mac-scenario.mjs Boots an isolated instance that mimics a fresh macOS host |
| 132 | +icon.png Plugin icon |
| 133 | +``` |
| 134 | + |
| 135 | +## Tests |
| 136 | + |
| 137 | +The tests use Node's built-in test runner and start an isolated console instance in a sandbox home |
| 138 | +directory, so they never touch a real project: |
| 139 | + |
| 140 | +```bash |
| 141 | +node --test "tests/*.test.mjs" |
| 142 | +``` |
| 143 | + |
| 144 | +`tests/service-discovery.test.mjs` covers the case where `~/.mcode-dynamic-workflows/projects` does |
| 145 | +not exist, which is what a machine that never installed the upstream plugin looks like. |
| 146 | +`tests/workspace-resolution.test.mjs` covers working-directory resolution, including the Host's |
| 147 | +temporary deployment directory, which must never be used as a project. |
| 148 | +`tests/manual-mac-scenario.mjs` starts a console whose working directory is a temporary deployment |
| 149 | +directory and prints the URL to open for manual inspection. |
| 150 | + |
| 151 | +## License |
| 152 | + |
| 153 | +[MIT](./LICENSE). The vendored upstream runtime keeps its own Apache-2.0 license. |
0 commit comments