@agimon-ai/doompi-workflow 0.0.1-alpha.21 → 0.0.1-alpha.22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +65 -45
- package/package.json +5 -5
package/README.md
CHANGED
|
@@ -1,72 +1,92 @@
|
|
|
1
1
|
# @agimon-ai/doompi-workflow
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Asynchronous workflow discovery, launch, monitoring, control, and terminal-failure recovery for DoomPi.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
`needs:`, `steps:`, timeouts, and declared artifacts. Every step names the session it wants,
|
|
7
|
-
so implementation can use coding tools while a later release note gets marketing context
|
|
8
|
-
and a brand profile. One run does not mean one swollen context window.
|
|
5
|
+
The integration embeds `@agimon-ai/workflow-mcp`; workflow files describe job dependencies and host-executed steps while DoomPi provides session-scoped tools and TUI surfaces.
|
|
9
6
|
|
|
10
|
-
|
|
11
|
-
running jobs continue under the boundaries declared by the workflow.
|
|
7
|
+
> **Alpha:** workflow and recovery contracts may change between releases.
|
|
12
8
|
|
|
13
|
-
|
|
14
|
-
|
|
9
|
+
## Requirements
|
|
10
|
+
|
|
11
|
+
- Node.js 22.19.0 or newer
|
|
12
|
+
- Pi 0.84.2 and Pi TUI 0.84.2
|
|
15
13
|
|
|
16
14
|
## Install
|
|
17
15
|
|
|
16
|
+
DoomPi loads Workflow as core. For standalone Pi:
|
|
17
|
+
|
|
18
18
|
```bash
|
|
19
|
-
|
|
19
|
+
pi install npm:@agimon-ai/doompi-workflow
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Enable tools with `SPC w e`, or set `WORKFLOW_MCP_MODE=on` for a non-interactive harness that cannot toggle the minor mode.
|
|
23
23
|
|
|
24
|
-
|
|
25
|
-
appear in `.doom/modes.yaml`. The bare package name follows its Pi manifest and loads the
|
|
26
|
-
Pi adapter.
|
|
24
|
+
## Define a workflow
|
|
27
25
|
|
|
28
|
-
|
|
26
|
+
Create a `*.workflow.yml` file:
|
|
29
27
|
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
- `SPC w r` recovers a failed workflow.
|
|
33
|
-
- `SPC w e` gives the agent workflow tools or takes them back.
|
|
28
|
+
```yaml
|
|
29
|
+
name: verify
|
|
34
30
|
|
|
35
|
-
|
|
31
|
+
jobs:
|
|
32
|
+
test:
|
|
33
|
+
runs-on: ubuntu-latest
|
|
34
|
+
steps:
|
|
35
|
+
- name: Run tests
|
|
36
|
+
run: pnpm test
|
|
37
|
+
|
|
38
|
+
summarize:
|
|
39
|
+
runs-on: ubuntu-latest
|
|
40
|
+
needs: test
|
|
41
|
+
steps:
|
|
42
|
+
- name: Record result
|
|
43
|
+
run: node scripts/write-verification-summary.mjs
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
`run` commands execute on the host with the workflow process's environment and privileges. Review workflow files as executable code. Runner-specific `interactiveRun` mappings are available for commands that genuinely require a TTY.
|
|
47
|
+
|
|
48
|
+
## Launch and monitor
|
|
49
|
+
|
|
50
|
+
Core tools are:
|
|
51
|
+
|
|
52
|
+
- `list_workflows`: discover workflows;
|
|
53
|
+
- `launch_workflow`: register and start an asynchronous run;
|
|
54
|
+
- `workflow_run`: inspect or control a run through supported actions.
|
|
36
55
|
|
|
37
|
-
|
|
38
|
-
`workflow_run` action `recovery-evidence` reads only terminal registry evidence; status,
|
|
39
|
-
tail, and every live control remain scoped to the session that owns the run.
|
|
56
|
+
Launch returns after the run is registered, not after all jobs complete. Use status/follow controls for progress and wait for a terminal notification.
|
|
40
57
|
|
|
41
|
-
|
|
42
|
-
controls to the exact run generation that was authorized. Recovery resumes the failed
|
|
43
|
-
work; it does not quietly launch a second copy beside it.
|
|
58
|
+
In the TUI, `SPC w w` launches, `SPC w l` manages runs, `SPC w r` opens recovery, and `SPC w e` toggles model-visible tools. The root session can launch; child sessions can inspect the catalog but do not receive an unrestricted workflow factory.
|
|
44
59
|
|
|
45
|
-
##
|
|
60
|
+
## Storage, concurrency, and lifecycle
|
|
46
61
|
|
|
47
|
-
|
|
48
|
-
contributes `workflow-help`; deactivating Help removes that generated wrapper. The
|
|
49
|
-
`workflow-recovery` skill is model-visible only while Workflow mode is active.
|
|
62
|
+
Registry data defaults to `$HOME/.workflow-mcp`; set `WORKFLOW_MCP_HOME` to relocate it. Persisted records contain workflow/run identity, job and step state, ownership, output locations, and recovery evidence. The default concurrency ceiling is five runs.
|
|
50
63
|
|
|
51
|
-
|
|
64
|
+
Runs embedded directly in the Pi process end with that process. Runs launched through a terminal host can have a different lifetime and remain CLI-manageable. Reconciliation distinguishes stale registry records from live processes; do not assume every run outlives its parent session.
|
|
52
65
|
|
|
53
|
-
|
|
54
|
-
step and an animated spinner. Step updates and raw launcher frames stay out of chat. The
|
|
55
|
-
list disappears on completion, and only terminal success or failure emits an agent
|
|
56
|
-
message. Raw output remains available through the follow and open views; it does not take
|
|
57
|
-
over the footer.
|
|
66
|
+
Each workflow or repair step can launch commands and model-backed agents, consuming provider quota and repeating external side effects.
|
|
58
67
|
|
|
59
|
-
|
|
60
|
-
|
|
68
|
+
## Recovery
|
|
69
|
+
|
|
70
|
+
Recovery is available only for terminal failed records. A recovery claim atomically adopts the eligible failure, validates the evidence, and transfers ownership to the replay session. Live controls remain scoped to the owning session. Recovery does not launch a second copy beside a still-running job and is not a blanket promise that parent-session work survives shutdown.
|
|
71
|
+
|
|
72
|
+
The package publishes `workflow-recovery` for active Workflow mode and contributes `workflow-help` while parent Help mode is active. Help deactivation logically hides the descriptor; cached files may remain.
|
|
61
73
|
|
|
62
|
-
##
|
|
74
|
+
## Public API
|
|
75
|
+
|
|
76
|
+
```ts
|
|
77
|
+
import { registerWorkflowDispatcherExtension, registerWorkflowExtension } from '@agimon-ai/doompi-workflow';
|
|
78
|
+
```
|
|
63
79
|
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
80
|
+
The dispatcher extension is available at `/extensions/dispatcher`; the Pi host entry is `/extensions/pi`.
|
|
81
|
+
|
|
82
|
+
## Development
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
pnpm build
|
|
86
|
+
pnpm typecheck
|
|
87
|
+
pnpm test
|
|
88
|
+
pnpm lint
|
|
89
|
+
```
|
|
70
90
|
|
|
71
91
|
## License
|
|
72
92
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@agimon-ai/doompi-workflow",
|
|
3
|
-
"version": "0.0.1-alpha.
|
|
3
|
+
"version": "0.0.1-alpha.22",
|
|
4
4
|
"description": "Doompi workflow execution and monitoring integration",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai",
|
|
@@ -47,10 +47,10 @@
|
|
|
47
47
|
"dependencies": {
|
|
48
48
|
"@modelcontextprotocol/sdk": "1.29.0",
|
|
49
49
|
"zod": "4.4.3",
|
|
50
|
-
"@agimon-ai/doompi-extension-contracts": "0.0.1-alpha.
|
|
51
|
-
"@agimon-ai/doompi-
|
|
52
|
-
"@agimon-ai/
|
|
53
|
-
"@agimon-ai/
|
|
50
|
+
"@agimon-ai/doompi-extension-contracts": "0.0.1-alpha.22",
|
|
51
|
+
"@agimon-ai/doompi-ui": "0.0.1-alpha.22",
|
|
52
|
+
"@agimon-ai/doompi-telemetry": "0.0.1-alpha.22",
|
|
53
|
+
"@agimon-ai/workflow-mcp": "0.23.12"
|
|
54
54
|
},
|
|
55
55
|
"devDependencies": {
|
|
56
56
|
"@earendil-works/pi-coding-agent": "0.84.2",
|