@geekbeer/minion 3.53.1 → 3.55.1

package/core/lib/dag-step-poller.js

@@ -119,12 +119,15 @@ async function pollOnce() {
 
 /**
  * Execute a single pending DAG node.
- * Routes to skill or transform execution based on node_type.
+ * Routes to skill / transform / script execution based on node_type.
  */
 async function executeNode(node) {
   if (node.node_type === 'transform') {
     return executeTransformNode(node)
   }
+  if (node.node_type === 'script') {
+    return executeScriptNode(node)
+  }
   return executeSkillNode(node)
 }
 
@@ -467,6 +470,247 @@ function appendContractTable(lines, fields) {
   }
 }
 
+/**
+ * Execute a script node:
+ * 1. Claim the node
+ * 2. Spawn python3 / node as a child process
+ * 3. Pipe input_data as JSON on stdin
+ * 4. Parse stdout as JSON → output_data, report completion
+ *
+ * Failure modes (all → status 'failed'):
+ * - Unsupported runtime
+ * - Non-zero exit code (stderr → error_message)
+ * - stdout is not parseable as JSON
+ * - Wall-clock timeout exceeded (process is SIGKILL'd)
+ *
+ * No tmux session is involved — this is a synchronous in-process child.
+ * The Output Contract on the outgoing edge is enforced by HQ on
+ * /node-complete, identical to skill / transform nodes.
+ */
+async function executeScriptNode(node) {
+  const {
+    node_execution_id,
+    node_id,
+    dag_workflow_name,
+    scope_path,
+    assigned_role,
+    input_data,
+    script_runtime,
+    script_source,
+    script_timeout_seconds,
+  } = node
+
+  console.log(
+    `[DagPoller] Executing script node "${node_id}" of DAG "${dag_workflow_name}" ` +
+    `(runtime: ${script_runtime}, scope: "${scope_path || 'root'}", role: ${assigned_role})`
+  )
+
+  try {
+    try {
+      await dagRequest('/claim-node', {
+        method: 'POST',
+        body: JSON.stringify({ node_execution_id }),
+      })
+    } catch (claimErr) {
+      if (claimErr.statusCode === 409) {
+        console.log(`[DagPoller] Script node ${node_id} already claimed, skipping`)
+        return
+      }
+      throw claimErr
+    }
+
+    if (!script_source || !script_source.trim()) {
+      await reportNodeComplete(node_execution_id, 'failed', null, 'Script node has empty script_source')
+      return
+    }
+
+    let interpreter
+    if (script_runtime === 'python') {
+      interpreter = 'python3'
+    } else if (script_runtime === 'node') {
+      interpreter = 'node'
+    } else {
+      await reportNodeComplete(
+        node_execution_id,
+        'failed',
+        null,
+        `Unsupported script_runtime: ${script_runtime} (allowed: python, node)`,
+      )
+      return
+    }
+
+    const timeoutMs = clampTimeout(script_timeout_seconds) * 1000
+
+    const result = await runScriptProcess(interpreter, script_source, input_data || {}, timeoutMs)
+
+    if (result.timedOut) {
+      await reportNodeComplete(
+        node_execution_id,
+        'failed',
+        null,
+        `Script timed out after ${timeoutMs / 1000}s. stderr: ${truncate(result.stderr, 2000)}`,
+      )
+      return
+    }
+
+    if (result.exitCode !== 0) {
+      await reportNodeComplete(
+        node_execution_id,
+        'failed',
+        null,
+        `Script exited with code ${result.exitCode}. stderr: ${truncate(result.stderr, 2000)}`,
+      )
+      return
+    }
+
+    let outputData
+    try {
+      outputData = JSON.parse(result.stdout)
+    } catch (parseErr) {
+      await reportNodeComplete(
+        node_execution_id,
+        'failed',
+        null,
+        `Script stdout is not valid JSON: ${parseErr.message}. stdout (first 500 chars): ${truncate(result.stdout, 500)}`,
+      )
+      return
+    }
+
+    if (typeof outputData !== 'object' || outputData === null || Array.isArray(outputData)) {
+      await reportNodeComplete(
+        node_execution_id,
+        'failed',
+        null,
+        `Script output_data must be a JSON object (got ${Array.isArray(outputData) ? 'array' : typeof outputData})`,
+      )
+      return
+    }
+
+    await reportNodeComplete(
+      node_execution_id,
+      'completed',
+      outputData,
+      buildScriptSummary(outputData, result.stderr),
+    )
+    console.log(`[DagPoller] Script node "${node_id}" completed`)
+
+  } catch (err) {
+    console.error(`[DagPoller] Failed to execute script node ${node_id}: ${err.message}`)
+    try {
+      await reportNodeComplete(node_execution_id, 'failed', null, err.message)
+    } catch {
+      // best-effort
+    }
+  }
+}
+
+/**
+ * Build the output_summary text shown in the HQ execution detail UI for a
+ * successful script node. The UI renders output_summary as a collapsible
+ * code block under "Output"; output_data itself is only visible from the
+ * Pin-fixture dialog. Always emit at least the JSON output so users can
+ * inspect what the script returned without round-tripping through fixtures.
+ */
+function buildScriptSummary(outputData, stderr) {
+  const lines = []
+  let serialized
+  try {
+    serialized = JSON.stringify(outputData, null, 2)
+  } catch {
+    serialized = '(failed to serialize output_data)'
+  }
+  lines.push('output_data:')
+  lines.push('```json')
+  lines.push(truncate(serialized, 8000))
+  lines.push('```')
+  if (stderr && stderr.trim()) {
+    lines.push('')
+    lines.push('stderr:')
+    lines.push(truncate(stderr, 2000))
+  }
+  return lines.join('\n')
+}
+
+function clampTimeout(seconds) {
+  const n = typeof seconds === 'number' && Number.isFinite(seconds) ? seconds : 60
+  if (n < 1) return 1
+  if (n > 600) return 600
+  return Math.floor(n)
+}
+
+function truncate(str, max) {
+  if (!str) return ''
+  return str.length > max ? str.slice(0, max) + '…(truncated)' : str
+}
+
+/**
+ * Spawn the interpreter, write the script to stdin via `-` / `-c` is not
+ * portable (python requires `-`, node requires `-e` with the source as an
+ * argument and no stdin). Instead we feed the script via stdin for both:
+ * - python3 reads source from stdin when invoked with `-`
+ * - node reads source from stdin when invoked with no args, but stdin is
+ *   then consumed by the script — so for node we must use `-e` with the
+ *   source as a flag value. To keep input_data on stdin for both, we
+ *   write the script to a temp file and pass the path as argv[1].
+ */
+function runScriptProcess(interpreter, source, inputData, timeoutMs) {
+  const { spawn } = require('child_process')
+  const fs = require('fs')
+  const os = require('os')
+  const path = require('path')
+  const crypto = require('crypto')
+
+  const ext = interpreter === 'python3' ? 'py' : 'js'
+  const tmpFile = path.join(
+    os.tmpdir(),
+    `dag-script-${crypto.randomBytes(8).toString('hex')}.${ext}`,
+  )
+  fs.writeFileSync(tmpFile, source, 'utf-8')
+
+  return new Promise(resolve => {
+    const child = spawn(interpreter, [tmpFile], {
+      stdio: ['pipe', 'pipe', 'pipe'],
+    })
+
+    let stdout = ''
+    let stderr = ''
+    let timedOut = false
+    let killed = false
+
+    const timer = setTimeout(() => {
+      timedOut = true
+      killed = true
+      try { child.kill('SIGKILL') } catch { /* noop */ }
+    }, timeoutMs)
+
+    child.stdout.on('data', chunk => { stdout += chunk.toString('utf-8') })
+    child.stderr.on('data', chunk => { stderr += chunk.toString('utf-8') })
+
+    child.on('error', err => {
+      clearTimeout(timer)
+      cleanup(tmpFile)
+      resolve({ exitCode: -1, stdout, stderr: stderr + `\nspawn error: ${err.message}`, timedOut })
+    })
+
+    child.on('close', code => {
+      clearTimeout(timer)
+      cleanup(tmpFile)
+      resolve({ exitCode: killed ? -1 : (code ?? -1), stdout, stderr, timedOut })
+    })
+
+    try {
+      child.stdin.write(JSON.stringify(inputData))
+      child.stdin.end()
+    } catch (writeErr) {
+      stderr += `\nstdin write error: ${writeErr.message}`
+    }
+  })
+}
+
+function cleanup(tmpFile) {
+  try { require('fs').unlinkSync(tmpFile) } catch { /* noop */ }
+}
+
 /**
  * Resolve skill_version_id to skill name via HQ API.
  */

package/docs/api-reference.md

@@ -52,20 +52,6 @@ hq list workspaces
 | `POST /api/skills/fetch/:name` | `workspace_id` | クエリパラメータ |
 | `GET /api/skills/remote` | `workspace_id` | クエリパラメータ |
 
-### Workflows
-
-v3.38.0 以降、workflows はワークスペース単位でスコープされる。各workflowレコードは `workspace_id` を持ち、未指定は `""`（未所属/legacy）として扱われる。
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| GET | `/api/workflows` | List local workflows with next_run. Optional `?workspace_id=` filter (omit for cross-workspace view) |
-| POST | `/api/workflows` | Receive/upsert workflows (from HQ). Each incoming workflow should carry `workspace_id` |
-| POST | `/api/workflows/push/:name` | Push local workflow to HQ |
-| POST | `/api/workflows/fetch/:name` | Fetch workflow from HQ and deploy locally (+ pipeline skills). HQ response includes `workspace_id` |
-| GET | `/api/workflows/remote` | List workflows on HQ |
-| DELETE | `/api/workflows/:id` | Remove a local workflow |
-| POST | `/api/workflows/trigger` | Manual trigger. Body: `{workflow_id}` |
-
 ### Routines
 
 v3.38.0 以降、routines はワークスペース単位でスコープされる。各routineレコードは `workspace_id` を持ち、未指定は `""`（未所属/legacy）として扱われる。
@@ -82,11 +68,11 @@ v3.38.0 以降、routines はワークスペース単位でスコープされる
 
 ### Executions
 
-v3.38.0 以降、executions は親 workflow / routine から `workspace_id` を継承する。
+v3.38.0 以降、executions は親 routine から `workspace_id` を継承する。
 
 | Method | Endpoint | Description |
 |--------|----------|-------------|
-| GET | `/api/executions` | List execution history (`?limit=50`, `?workflow_id=`, optional `?workspace_id=`) |
+| GET | `/api/executions` | List execution history (`?limit=50`, optional `?workspace_id=`) |
 | GET | `/api/executions/:id` | Get single execution (includes `workspace_id`) |
 | GET | `/api/executions/:id/log` | Get execution log content (`?tail=N`) |
 | POST | `/api/executions/:id/outcome` | Report outcome (no auth). Body: `{outcome, summary?, details?}` |
@@ -429,6 +415,8 @@ GET `/api/daemons/status` response:
   "success": true,
   "daemons": {
     "step_poller": { "running": true, "last_poll_at": "2026-03-19T15:30:00.000Z" },
+    "dag_step_poller": { "running": true, "last_poll_at": "2026-03-19T15:30:02.000Z" },
+    "board_task_poller": { "running": true, "last_poll_at": "2026-03-19T15:30:08.000Z" },
     "revision_watcher": { "running": true, "last_poll_at": "2026-03-19T15:30:05.000Z" },
     "thread_watcher": { "running": true, "last_poll_at": "2026-03-19T15:29:52.000Z" },
     "reflection_scheduler": { "running": true, "next_run": "2026-03-20T03:00:00.000Z" },
@@ -439,12 +427,16 @@ GET `/api/daemons/status` response:
 
 | Daemon | 概要 |
 |--------|------|
-| `step_poller` | ワークフローステップの取得・実行（30秒間隔） |
-| `revision_watcher` | リビジョン要求の検知（30秒間隔、PMのみ） |
+| `dag_step_poller` | DAGノード（skill/transform/script）の取得・claim・実行（30秒間隔） |
+| `board_task_poller` | アクティブスプリント内のボードタスク自動着手（30秒間隔、v3.46.0〜） |
+| `step_poller` | 旧式ワークフローステップ用ポーラー（30秒間隔。サポート打ち切り後はpending返却なし、互換目的で稼働） |
+| `revision_watcher` | 旧式ワークフローのリビジョン要求検知（30秒間隔、PMのみ。DAGの差し戻しはサーバ側カスケードで処理） |
 | `thread_watcher` | プロジェクト・ワークスペーススレッドの監視・LLM評価（15秒間隔） |
 | `reflection_scheduler` | 1日1回の振り返り（cron） |
 | `heartbeat` | HQへのハートビート（30秒間隔） |
 
+> Note: `dag_cron_poller`（v3.51.0〜、PMロールがcron-enabled DAGを発火する）は内部的には起動しているが、`/api/daemons/status` のレスポンスには含まれていない（既知のギャップ）。稼働確認は `~/.minion/logs/agent.log` を grep する。
+
 ### Threads (スレッド)
 
 ワークスペースレベルのコミュニケーションチャネル。ブロッカー共有やチーム議論に使う。
@@ -513,7 +505,7 @@ POST `/api/threads` body (プロジェクト紐づきディスカッション):
 | `title` | string | Yes | スレッドの要約 |
 | `content` | string | Yes | スレッド本文（thread_messagesの最初のメッセージとして保存） |
 | `mentions` | string[] | No | メンション対象。形式: `role:engineer`, `role:pm`, `minion:<minion_id>`, `user` |
-| `context` | object | No | 任意のメタデータ（category, urgency, workflow_execution_id等） |
+| `context` | object | No | 任意のメタデータ（category, urgency, dag_execution_id等） |
 
 **プロジェクト紐づけの使い分け:**
 - ワークフロー実行中（プロジェクトあり）→ `project_ids: ["uuid"]`
@@ -817,7 +809,7 @@ Response:
 ]
 ```
 
-`role` is either `"pm"` (project manager) or `"engineer"`.
+`role` is one of `"pm"` (project manager), `"engineer"`, or `"accountant"`.
 
 ### Project Context
 
@@ -855,6 +847,18 @@ Response:
 
 プロジェクト変数はワークフロー実行時に `template_vars` としてミニオンに渡され、スキルの `{{VAR_NAME}}` テンプレートを展開する。
 
+#### 変数とシークレットの違い
+
+**変数**（ミニオン変数・プロジェクト変数）はスキル本文の `{{VAR_NAME}}` テンプレートとして実行時に展開される。スキル作成時にパラメータ化したい値は `{{変数名}}` で記述する。
+
+**シークレット**（ミニオンシークレット）は環境変数 `$SECRET_NAME` としてプロセスに注入される。APIキーやパスワード等の機密情報に使用する。テンプレート展開は行われない。
+
+#### テンプレート変数の展開優先順位
+
+同名の変数が複数のスコープで定義されている場合、以下の順序で上書きされる:
+1. ミニオン変数（最低優先）
+2. プロジェクト変数（最優先）
+
 ### Project Tasks
 
 タスクは5段階Kanban (`backlog`/`todo`/`doing`/`review`/`done`)で管理される。親子関係は2階層まで(孫タスク禁止)。担当は **ミニオンか人間の二択**(両方は不可、後勝ち null)。
@@ -1046,282 +1050,11 @@ Response:
 - 子タスクが `milestone_id=null` でも、親 EPIC の `milestone_id` を継承して集計される(effective milestone)。つまり「親に MVP を付ければ配下の子タスクも MVP 進捗に含まれる」。
 - `summary.by_status` は従来どおり全タスク(親含む)で計上する。
 
-### Workflow Variables (PM only)
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| POST | `/api/minion/me/project/[id]/workflows/[wfId]/variables/[key]` | ワークフロー変数を設定（upsert） |
-| DELETE | `/api/minion/me/project/[id]/workflows/[wfId]/variables/[key]` | ワークフロー変数を削除 |
-
-POST body:
-```json
-{
-  "value": "variable value (max 2000 chars)"
-}
-```
-
-Key format: `/^[A-Za-z_][A-Za-z0-9_]{0,99}$/`
-
-Response:
-```json
-{
-  "success": true,
-  "key": "MY_VAR",
-  "value": "variable value"
-}
-```
-
-ワークフロー変数はプロジェクト変数を上書きする（同名キーの場合）。
-
-#### 変数とシークレットの違い
-
-**変数**（ミニオン変数・プロジェクト変数・ワークフロー変数）はスキル本文の `{{VAR_NAME}}` テンプレートとして実行時に展開される。スキル作成時にパラメータ化したい値は `{{変数名}}` で記述する。
-
-**シークレット**（ミニオンシークレット）は環境変数 `$SECRET_NAME` としてプロセスに注入される。APIキーやパスワード等の機密情報に使用する。テンプレート展開は行われない。
-
-#### テンプレート変数の展開優先順位
-
-同名の変数が複数のスコープで定義されている場合、以下の順序で上書きされる:
-1. ミニオン変数（最低優先）
-2. プロジェクト変数
-3. ワークフロー変数（最優先）
-
-### Workflows (project-scoped, versioned)
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| GET | `/api/minion/workflows` | 参加プロジェクトのアクティブなワークフロー一覧 |
-| POST | `/api/minion/workflows` | ワークフローを push（新規作成 or 新バージョン） |
-
-GET Response:
-```json
-{
-  "workflows": [
-    {
-      "name": "daily-check",
-      "pipeline_skill_names": ["skill-1", "skill-2"],
-      "pipeline": [
-        {
-          "skill_version_id": "uuid",
-          "skill_name": "skill-1",
-          "skill_display_name": "Skill One",
-          "skill_version": 3,
-          "assigned_role": "engineer",
-          "requires_review": false,
-          "is_my_step": true
-        }
-      ],
-      "content": "...",
-      "version": 3,
-      "cron_expression": "0 9 * * *",
-      "project_id": "uuid",
-      "created_at": "..."
-    }
-  ]
-}
-```
-
-各ステップの `is_my_step` はミニオン自身のプロジェクトロールと `assigned_role` の一致を示す。
-
-POST body (push):
-```json
-{
-  "name": "my-workflow",
-  "pipeline_skill_names": ["skill-1", "skill-2"],
-  "content": "Workflow description",
-  "project_id": "uuid",
-  "change_summary": "Added skill-2 to pipeline"
-}
-```
-
-push するとパイプライン内のスキル名が `skill_version_id` に解決され、新バージョンが自動作成される。
-
-### Workflow Structure
-
-```json
-{
-  "name": "my-workflow",
-  "pipeline_skill_names": ["skill-1", "skill-2"],
-  "pipeline": [
-    {
-      "skill_version_id": "uuid",
-      "skill_name": "skill-1",
-      "skill_display_name": "Skill One",
-      "skill_version": 2,
-      "assigned_role": "engineer",
-      "requires_review": false,
-      "is_my_step": true
-    }
-  ],
-  "content": "Markdown description of the workflow",
-  "version": 2,
-  "cron_expression": "0 9 * * *",
-  "project_id": "uuid"
-}
-```
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `name` | string | Slug identifier (`/^[a-z0-9-]+$/`) |
-| `pipeline_skill_names` | string[] | Ordered skill names (for display/push) |
-| `pipeline` | PipelineStep[] | Resolved pipeline with version IDs and roles |
-| `content` | string | Markdown body describing the workflow |
-| `version` | number | Current version number (auto-incremented on push) |
-| `cron_expression` | string\|null | Cron schedule (null = manual/one-shot only) |
-| `project_id` | string | UUID of the parent project |
-
-### Pipeline Step Fields
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `skill_version_id` | string | UUID of the specific skill version |
-| `skill_name` | string | Skill slug name |
-| `skill_display_name` | string | Human-readable skill name |
-| `skill_version` | number | Skill version number |
-| `assigned_role` | string | `"pm"` or `"engineer"` — who executes this step |
-| `requires_review` | boolean | If true, human review required after completion |
-| `is_my_step` | boolean | Whether this minion's role matches assigned_role |
-
-### Syncing Workflows with HQ
-
-- `POST /api/workflows/push/:name` — Push local workflow to HQ. Pipeline skills are auto-pushed first.
-- `POST /api/workflows/fetch/:name` — Fetch workflow from HQ. Missing pipeline skills are auto-fetched.
-- `GET /api/workflows/remote` — List workflows available on HQ.
-
-Pipeline skills must be deployed locally (in `~/.claude/skills/`) before pushing a workflow.
-
-### Pending Steps (軽量ポーリング)
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| GET | `/api/minion/pending-steps` | 自分が実行すべき pending ステップ一覧 |
-
-**このエンドポイントはミニオンエージェント（非AI）による高頻度ポーリング用。**
-
-Response:
-```json
-{
-  "steps": [
-    {
-      "step_execution_id": "uuid",
-      "execution_id": "uuid",
-      "workflow_name": "daily-check",
-      "step_index": 0,
-      "skill_version_id": "uuid",
-      "assigned_role": "engineer"
-    }
-  ]
-}
-```
-
-返却条件:
-- `assigned_role` がミニオンのプロジェクトロールと一致
-- ステップの `status` が `pending`
-- 前ステップが全て `completed`（`requires_review` の場合は `approved` も必要）
-
-### Workflow Execution Recording
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| POST | `/api/minion/workflow-execution` | 新規 execution 開始を記録 |
-| POST | `/api/minion/execution` | ステップ実行状況を HQ に報告 |
-
-POST `/api/minion/workflow-execution` body:
-```json
-{
-  "workflow_version_id": "uuid"
-}
-```
-
-Response:
-```json
-{
-  "execution_id": "uuid",
-  "status": "running",
-  "steps_count": 3
-}
-```
-
-POST `/api/minion/execution` body:
-```json
-{
-  "workflow_execution_id": "uuid",
-  "steps": [
-    {
-      "step_index": 0,
-      "skill_version_id": "uuid",
-      "assigned_role": "engineer",
-      "status": "completed",
-      "outcome": "success",
-      "started_at": "...",
-      "completed_at": "..."
-    }
-  ],
-  "status": "running",
-  "started_at": "..."
-}
-```
-
-### Pending Revisions (PM のみ)
-
-レビューで `revision_requested` になったステップを検知する。ミニオンの `revision-watcher` デーモンが30秒ごとにポーリングし、LLM で差し戻し先ステップを判断した上で `/api/minion/revision-reset` を呼び出す。
-
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| GET | `/api/minion/pending-revisions` | `revision_requested` 状態のステップ一覧（PMのプロジェクトのみ） |
-| POST | `/api/minion/revision-reset` | 差し戻し対象ステップを `pending` に戻す |
-
-GET Response:
-```json
-{
-  "revisions": [
-    {
-      "execution_id": "uuid",
-      "workflow_name": "daily-check",
-      "revision_step_index": 2,
-      "review_comment": "string (レビュアーのフィードバック)",
-      "pipeline": [
-        {
-          "step_index": 0,
-          "skill_version_id": "uuid",
-          "skill_name": "string|null",
-          "assigned_role": "pm|engineer|accountant"
-        }
-      ]
-    }
-  ]
-}
-```
-
-POST `/api/minion/revision-reset` body:
-```json
-{
-  "execution_id": "uuid",
-  "target_step_index": 0,
-  "revision_step_index": 2,
-  "revision_feedback": "string (省略可、target step の review_comment に保存)"
-}
-```
-
-- `target_step_index` は差し戻し先（やり直し起点）のインデックス
-- `revision_step_index` は差し戻しを要求されたレビューステップのインデックス（`target_step_index <= revision_step_index`）
-- target から revision までのステップが `pending` に戻り、`revision_feedback` が再実行時のコンテキストとして注入される
-
-Response:
-```json
-{
-  "success": true,
-  "reset_count": 3,
-  "target_step_index": 0,
-  "revision_step_index": 2
-}
-```
-
 ---
 
 ## DAG Workflows (HQ, ノード/エッジ方式)
 
-DAG ワークフローは従来の線形パイプラインを拡張した有向非巡回グラフ方式のワークフローです。HQダッシュボードの DAG エディタで作成・編集できるほか、ミニオンAPI経由でも JSON ベースで編集可能（PMロールのみ）。ミニオンはプルベースのポーリングで pending ノードを検出・実行します。
+DAG ワークフローは有向非巡回グラフでスキル間の依存関係を表現するワークフローです。HQダッシュボードの DAG エディタで作成・編集できるほか、ミニオンAPI経由でも JSON ベースで編集可能（PMロールのみ）。ミニオンはプルベースのポーリングで pending ノードを検出・実行します。
 
 ### 編集エンドポイント (PMロール限定)
 
@@ -1407,7 +1140,7 @@ POST `/api/minion/dag-workflows/:id/publish` (body なし):
 }
 ```
 
-- `type` (必須): `start` | `end` | `skill` | `review` | `fan_out` | `join` | `conditional` | `transform`
+- `type` (必須): `start` | `end` | `skill` | `review` | `fan_out` | `join` | `conditional` | `transform` | `script`
 - `id` (任意): 省略時は `<type>_1`, `<type>_2`, ... で自動採番
 - `label` (任意): 省略時は `New <type>`
 - `after` (任意): このノードの後ろに挿入。`after` → 新ノード へのエッジを自動生成
@@ -1425,6 +1158,7 @@ POST `/api/minion/dag-workflows/:id/publish` (body なし):
 | `join` | `join_mode`, `aggregation` | |
 | `conditional` | `condition_type`, `branches` or `default_branch` | |
 | `transform` | `assigned_role`, incoming edge 1 本 + outgoing edge 1 本 (両方 `contract` 必須) | `transform_instruction` は optional hint。I/O 型は edge の contract から自動導出される |
+| `script` | `assigned_role`, `script_runtime` (`'python'` \| `'node'`), `script_source` (非空) | `script_timeout_seconds` (任意, デフォルト 60, 範囲 1-600)。LLM を使わず `python3` / `node` で決定的にスクリプト実行。input_data を stdin で JSON 受信 → output_data を stdout に JSON 出力。outgoing edge に `contract` があれば HQ が output_data を検証 |
 
 **review ノード追加の例:**
 ```json
@@ -1683,7 +1417,7 @@ hq dag update-node <wf-id> fan_out_1 /tmp/u.json
 テンプレート内部のノード/エッジを個別操作するAPIは現在ない。テンプレートは `template` フィールドの全体上書きで更新すること。テンプレートは start/end ノードを持たない sub-graph であり、バリデーション時に再帰的に検証される。
 
 > **⚠️ 重要: テンプレート内に `start` / `end` ノードを配置してはいけない。**
-> テンプレートのエントリポイントとエグジットポイントは、エッジ構造から自動検出される（incoming edge がないノード = エントリ、outgoing edge がないノード = エグジット）。`start` / `end` はトップレベル DAG 専用のノードタイプであり、テンプレート内に含めるとバリデーションエラーになる。テンプレート内では `skill`, `conditional`, `transform`, `review` 等の実行ノードのみ使用すること。
+> テンプレートのエントリポイントとエグジットポイントは、エッジ構造から自動検出される（incoming edge がないノード = エントリ、outgoing edge がないノード = エグジット）。`start` / `end` はトップレベル DAG 専用のノードタイプであり、テンプレート内に含めるとバリデーションエラーになる。テンプレート内では `skill`, `conditional`, `transform`, `script`, `review` 等の実行ノードのみ使用すること。
 
 ### ミニオン CLI ラッパー
 
@@ -1787,7 +1521,9 @@ GET `/api/minion/dag-executions/:id` Response:
 | POST | `/api/dag/minion/node-complete` | ノード完了を報告し、下流ノードへカスケード |
 | POST | `/api/dag/minion/dag-cron-tick` | PMロールのミニオン専用。所属プロジェクトのcron-enabled DAGワークフローを発火 |
 
-ミニオンの `dag-step-poller` デーモンが30秒ごとに `pending-nodes` を叩き、最大2並列で claim → skill/transform 実行 → node-complete の流れを回す。`skill`・`transform` 以外のノード（start/end/review/fan_out/join/conditional）はHQ内部のカスケードエンジンが処理するため、ミニオンには返されない。
+ミニオンの `dag-step-poller` デーモンが30秒ごとに `pending-nodes` を叩き、最大2並列で claim → skill/transform/script 実行 → node-complete の流れを回す。`skill`・`transform`・`script` 以外のノード（start/end/review/fan_out/join/conditional）はHQ内部のカスケードエンジンが処理するため、ミニオンには返されない。
+
+`script` ノード (v3.54.0〜) は LLM を経由しない決定的な処理用。ミニオン標準搭載の `python3` / `node` で `script_source` を `child_process` 実行し、`input_data` を stdin で JSON 渡し → stdout の JSON を `output_data` として `node-complete` に報告する。タイムアウト超過 (`script_timeout_seconds`、デフォルト60s) / 非0終了 / 不正JSON はいずれも `failed` 扱いで stderr が `output_summary` に格納される。tmux セッションは作らない (専用プロセスのみ)。
 
 `dag-cron-poller` デーモン（v3.51.0〜）は60秒ごとに `dag-cron-tick` を叩く。HQ側で「呼び出しミニオンがPMロールであるプロジェクトのDAGワークフロー」のうち `cron_enabled AND next_run_at <= now()` を atomic claim → triggerDagExecution。Push型ではないので、PMミニオンが offline ならcron発火が遅延する。
 
@@ -1809,7 +1545,10 @@ Response:
       "assigned_role": "pm|engineer|accountant",
       "input_data": { "...": "..." },
       "revision_feedback": "string|null",
-      "transform_instruction": "string|null"
+      "transform_instruction": "string|null",
+      "script_runtime": "python|node|null",
+      "script_source": "string|null",
+      "script_timeout_seconds": "number|null"
     }
   ]
 }
@@ -1818,7 +1557,7 @@ Response:
 返却条件:
 - `assigned_role` がミニオンのプロジェクトロールと一致
 - ノードの `status` が `pending`
-- `node_type` が `skill` または `transform`
+- `node_type` が `skill`、`transform`、または `script`
 - スコープ内の全依存ノードが `completed`（`requires_review` の場合は `approved` も必要）
 
 `scope_path` は fan-out 内のインスタンスを示す（ルートは空文字列、1段のfan-outでは `fan_out_A:0`、ネストでは `fan_out_A:2/fan_out_B:1`）。依存解決は同じ scope_path 内で閉じる。
@@ -1946,6 +1685,7 @@ DAG ワークフローの graph は以下の構造で保存される（`dag_work
 | `end` | 終端 | ❌ (内部) |
 | `skill` | スキル実行。`skill_version_id` と `assigned_role` が必須 | ✅ |
 | `transform` | contract 同士のブリッジ。I/O 型は incoming/outgoing edge の `contract` から自動導出、出力は HQ が contract validate。`transform_instruction` は optional hint | ✅ |
+| `script` | LLMを使わず `python3` / `node` でインラインスクリプトを実行 (v3.54.0〜)。input_data を stdin で JSON 受信 → output_data を stdout に JSON 出力。決定的処理向け | ✅ |
 | `review` | レビューゲート。`approved` / `revision_requested` で分岐 | ❌ (内部) |
 | `fan_out` | 配列入力をテンプレートsub-graphに展開して並列実行。子が全て settle すると自ノードが completed に遷移 | ❌ (内部) |
 | `join` | N本の上流エッジを待ち合わせる汎用バリア。fan_out とは独立 | ❌ (内部) |
@@ -1971,6 +1711,9 @@ DAG ワークフローの graph は以下の構造で保存される（`dag_work
 | `branches` | Record<string,string> | conditional: 条件出力→遷移先ノードID |
 | `default_branch` | string? | conditional: マッチしなかった場合の遷移先 |
 | `transform_instruction` | string | transform: LLMへの変換指示 |
+| `script_runtime` | `python`\|`node` | script: ランタイム指定 |
+| `script_source` | string | script: インラインスクリプト本文。stdin から JSON を読み、stdout に JSON を出力 |
+| `script_timeout_seconds` | number? | script: タイムアウト秒数 (デフォルト60、範囲1-600) |
 | `review` | object | review: レビュー設定 |
 
 #### DagEdge

package/docs/task-guides.md

@@ -88,7 +88,7 @@ requires:
 ---
 
 Skill instructions here...
-Use {{PROJECT_VAR}} to reference project/workflow variables.
+Use {{PROJECT_VAR}} to reference project variables.
 ```
 
 フロントマターのフィールド:
@@ -120,7 +120,7 @@ description: サイトをデプロイする
 
 - 変数名は英数字とアンダースコアのみ（`\w+`）
 - 未定義の変数は `{{VAR_NAME}}` のまま残る（エラーにはならない）
-- 展開優先順位: ミニオン変数 < プロジェクト変数 < ワークフロー変数（後者が上書き）
+- 展開優先順位: ミニオン変数 < プロジェクト変数（後者が上書き）
 - ルーティン実行時もミニオン変数による `{{VAR}}` 展開が行われる
 
 ### 変数とシークレットの使い分け
@@ -130,7 +130,7 @@ description: サイトをデプロイする
 | 変数 | `{{VAR_NAME}}` | 設定・パラメータ（非機密） | デプロイ先、サイトURL、プロジェクト名 |
 | シークレット | `$SECRET_NAME`（環境変数） | 機密情報 | APIキー、パスワード、トークン |
 
-- **変数**はスキル本文のテンプレートとして展開される。全スコープ（ミニオン・プロジェクト・ワークフロー）で同じ `{{VAR}}` 構文を使用する
+- **変数**はスキル本文のテンプレートとして展開される。全スコープ（ミニオン・プロジェクト）で同じ `{{VAR}}` 構文を使用する
 - **シークレット**は環境変数としてプロセスに注入される。テンプレート展開は行われない
 - デイリーログやメモリーから変数・シークレットの値を推測して使用しないこと
 
@@ -154,63 +154,11 @@ minion-cli skill fetch <name>
 
 ---
 
-## ワークフローの修正 (PM のみ)
-
-### パイプライン構成の変更
-
-```bash
-# API経由で push (新バージョン自動作成)
-curl -s -X POST "$HQ_URL/api/minion/workflows" \
-  -H "Authorization: Bearer $API_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "name": "my-workflow",
-    "pipeline_skill_names": ["skill-1", "skill-2"],
-    "content": "Workflow description",
-    "project_id": "<project-uuid>",
-    "change_summary": "Updated pipeline"
-  }'
-```
-
-### ステップごとのロール・レビュー設定
-
-```bash
-curl -s -X POST "$HQ_URL/api/minion/workflows" \
-  -H "Authorization: Bearer $API_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "name": "my-workflow",
-    "pipeline_skill_names": ["skill-1", "skill-2"],
-    "pipeline_steps": [
-      { "assigned_role": "engineer", "requires_review": false },
-      { "assigned_role": "pm", "requires_review": true }
-    ],
-    "content": "Workflow description",
-    "project_id": "<project-uuid>"
-  }'
-```
-
-### ローカルワークフローの同期
-
-```bash
-# HQからワークフローを取得 (不足スキルも自動fetch)
-curl -s -X POST "http://localhost:8080/api/workflows/fetch/<name>" \
-  -H "Authorization: Bearer $API_TOKEN"
-
-# ローカルワークフローをHQにpush (スキルも自動push)
-curl -s -X POST "http://localhost:8080/api/workflows/push/<name>" \
-  -H "Authorization: Bearer $API_TOKEN"
-```
-
-> **Note**: `/api/workflows/push|fetch` は線形パイプライン形式（`pipeline_skill_names`）の旧式ワークフロー専用です。DAGワークフロー（ノード/エッジ形式）はHQダッシュボードの DAG エディタで作成・編集します。次節を参照。
-
----
-
 ## DAG ワークフロー (ノード/エッジ形式)
 
-DAG ワークフローは有向非巡回グラフでスキル間の依存関係を表現する新方式のワークフローです。fan-out による並列展開、join による集約、conditional による分岐、transform による LLM データ変換、review によるゲーティングをサポートします。
+DAG ワークフローは有向非巡回グラフでスキル間の依存関係を表現するワークフローです。fan-out による並列展開、join による集約、conditional による分岐、transform による LLM データ変換、script による決定的スクリプト実行 (Python/Node)、review によるゲーティングをサポートします。
 
-**HQダッシュボードの DAG エディタ（プロジェクト画面 → 「DAG (beta)」タブ）で GUI 編集**できるほか、**ミニオンからは JSON ベースで編集可能**（PMロールのみ）。ミニオンは実行ランタイムも担当し、`dag-step-poller` デーモンが pending ノードを自動で処理します。
+**HQダッシュボードの DAG エディタ（プロジェクト画面の「DAG」タブ）で GUI 編集**できるほか、**ミニオンからは JSON ベースで編集可能**（PMロールのみ）。ミニオンは実行ランタイムも担当し、`dag-step-poller` デーモンが pending ノードを自動で処理します。
 
 **cronスケジュール (v3.51.0〜):** DAGワークフローは cron 式による定期実行をサポート。設定はHQダッシュボードのDAGビューにある SchedulePanel から行う（最小実行間隔 5分）。発火主体はそのプロジェクトのPMロールのミニオンで、`dag-cron-poller` デーモンが60秒間隔で `/api/dag/minion/dag-cron-tick` を叩いて発火させる。PM不在のプロジェクトでは cron は発火しない。
 
@@ -405,7 +353,7 @@ hq dag remove-edge <wf-id> edge_3
 
 **fan_out テンプレート編集:**
 
-> **⚠️ テンプレート内に `start` / `end` ノードを入れないこと。** テンプレートのエントリ/エグジットはエッジ構造から自動検出される。`start` / `end` はトップレベル DAG 専用であり、テンプレート内に含めるとバリデーションエラーになる。`skill`, `conditional`, `transform`, `review` 等の実行ノードのみ使用すること。
+> **⚠️ テンプレート内に `start` / `end` ノードを入れないこと。** テンプレートのエントリ/エグジットはエッジ構造から自動検出される。`start` / `end` はトップレベル DAG 専用であり、テンプレート内に含めるとバリデーションエラーになる。`skill`, `conditional`, `transform`, `script`, `review` 等の実行ノードのみ使用すること。
 
 ```bash
 # fan_out ノードの template を PATCH で上書き
@@ -434,7 +382,7 @@ hq dag update-node <wf-id> fan_out_1 /tmp/t.json
 - 書き込み（create / put / publish / dag 操作）は **PMロールのみ**。Engineer / accountant では 403 が返る。読み取り（fetch）は全メンバー可。
 - ノード/エッジ操作は各ステップでドラフトに自動保存され、バリデーション結果がレスポンスに含まれる。
 - `hq dag validate` で公開前にフル検証できる。publish 時の想定外エラーを防止できる。
-- 全文 JSON 操作（`hq put dag-workflow`）も引き続き利用可能だが、**ノード/エッジ操作APIの方が推奨**。
+- 全文 JSON 操作（`hq put dag-workflow`）も引き続き利用可能だが、**ノード/エッジ操作APIの方が推奨**（型の取り違えで 400 になりやすい）。
 
 ### 実行フロー（ランタイム側、参考）
 
@@ -548,6 +496,63 @@ input_data: { "items": [{ "title": "Item A" }, { "title": "Item B" }, { "title":
 output_data: { "items": [{ "title": "Item A" }, { "title": "Item C" }] }
 ```
 
+### Script ノード（決定的処理、LLM不要）v3.54.0〜
+
+Script ノードは **LLM を使わない決定的なデータ処理** を DAG 内に挟み込むためのノード。トークンコストもかからず、出力形式のブレも発生しない。ミニオン標準搭載の `python3` または `node` でインラインスクリプトを `child_process` 実行する。
+
+**静的バリデーション要件:**
+
+- `assigned_role` 必須（pm / engineer / accountant のいずれか）
+- `script_runtime`: `'python'` または `'node'`
+- `script_source`: 非空のスクリプト本文
+- `script_timeout_seconds`: 任意（デフォルト 60、範囲 1–600）
+
+**I/O プロトコル（skill / transform と完全に揃う）:**
+
+- 入力: `input_data` (incoming edge から渡る JSON object) → スクリプトの **stdin に JSON 1 個** として書き込まれる
+- 出力: スクリプトが **stdout に JSON object 1 個を書く** → そのままパースされて `output_data` として `node-complete` に送られる
+- outgoing edge に contract が貼ってあれば HQ が `output_data` を validate（skill / transform と同じ runtime validation 経路）
+
+**failure モード（いずれも `status: failed`、stderr が `output_summary` に格納される）:**
+
+- 非 0 終了
+- stdout が JSON parse 不能 / object でない（配列・プリミティブは不可）
+- `script_timeout_seconds` 超過（プロセスは SIGKILL）
+- `script_runtime` が unsupported
+
+**典型用途:**
+
+```python
+# script_runtime: "python", input edge contract: { items: array<item> }
+# output edge contract: { items: array<item>, total: number }
+import sys, json
+
+data = json.load(sys.stdin)
+items = [it for it in data["items"] if it.get("score", 0) >= 0.8]
+json.dump({"items": items, "total": len(items)}, sys.stdout)
+```
+
+```javascript
+// script_runtime: "node", URL 一覧から domain ごとにグルーピング
+let raw = ''
+process.stdin.on('data', c => raw += c)
+process.stdin.on('end', () => {
+  const data = JSON.parse(raw)
+  const groups = {}
+  for (const url of data.urls) {
+    const host = new URL(url).host
+    ;(groups[host] ||= []).push(url)
+  }
+  process.stdout.write(JSON.stringify({ groups }))
+})
+```
+
+**制約:**
+
+- 追加ライブラリのインストール（pip / npm install）は未対応。ミニオン標準搭載のもののみ使用可能
+- tmux セッションは作らず、ミニオンのエージェントプロセス内で `child_process.spawn` する
+- 並列実行上限は skill / transform と共通（`concurrency-manager` の `MAX_CONCURRENT=2`）
+
 ### DAG 構築時のノード選定フロー
 
 スキルは汎用的で再利用可能な資産であり、ワークフロー固有の contract に合わせて SKILL.md を改修することは原則行わない。代わりに以下のフローで判断する:
@@ -579,7 +584,7 @@ Review ノードはレビューゲート。`review_status=review_pending` で下
 - `approved` にすると `approved` 種別のエッジで下流に進む
 - `revision_requested` にすると `revision` 種別のエッジで差し戻し先に戻る
 
-レガシー線形パイプラインの差し戻しは `revision-watcher` デーモン + `/api/minion/pending-revisions` + `/api/minion/revision-reset` で処理される。DAGの差し戻しはサーバ側カスケードで自動処理。
+差し戻しはサーバ側のカスケードで自動処理される（`revision` 種別のエッジが指す上流ノード以降が `pending` に戻り再実行される）。
 
 ### デバッグ
 
@@ -714,17 +719,14 @@ curl -X PATCH "$HQ_URL/api/minion/projects/<project-id>/tasks/<task-id>" \
   -H "Authorization: Bearer $API_TOKEN" -H "Content-Type: application/json" \
   -d '{"status":"doing"}'
 
-# レビュー依頼
+# レビュー依頼（acceptance_criteria を全て満たした後）
 curl -X PATCH "$HQ_URL/api/minion/projects/<project-id>/tasks/<task-id>" \
   -H "Authorization: Bearer $API_TOKEN" -H "Content-Type: application/json" \
   -d '{"status":"review"}'
-
-# 完了
-curl -X PATCH "$HQ_URL/api/minion/projects/<project-id>/tasks/<task-id>" \
-  -H "Authorization: Bearer $API_TOKEN" -H "Content-Type: application/json" \
-  -d '{"status":"done"}'
 ```
 
+> **重要**: ミニオン自身は `done` へ直接遷移してはいけない。`done` 遷移はレビュアー（人間または別のミニオン）の責務。受け入れ要件達成後は `review` で停止し、承認を待つこと。
+
 ### 共通の注意
 
 - **`status_changed_at` を手動で渡してはならない**。サーバ側で自動更新される(stalled 検出に使われる)。
@@ -821,20 +823,19 @@ minion-cli skill list --local
 minion-cli skill fetch <name>
 ```
 
-### ワークフローが実行されない
+### DAG ワークフローが実行されない
 
 ```bash
-# ローカルワークフロー一覧 (next_run を確認)
-curl -s "http://localhost:8080/api/workflows" \
-  -H "Authorization: Bearer $API_TOKEN"
+# pending ノードが自分に割り当てられているか確認
+curl -s "$HQ_URL/api/dag/minion/pending-nodes" \
+  -H "Authorization: Bearer $API_TOKEN" | jq
 
-# 手動トリガー
-curl -s -X POST "http://localhost:8080/api/workflows/trigger" \
-  -H "Authorization: Bearer $API_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{ "workflow_id": "<workflow-uuid>" }'
+# dag-step-poller のログを確認
+tail -f ~/.minion/logs/agent.log | grep '\[DAG'
 ```
 
+PMロールが不在のプロジェクトでは cron 発火が行われない。`hq list dag-workflows <project-id>` の `my_role` を確認すること。
+
 ### エージェントの状態確認
 
 ```bash

package/linux/routes/chat.js

@@ -464,26 +464,11 @@ async function buildContextPrefix(message, context, sessionId, workspaceId, refe
           )
         }
         break
-      case 'workflow':
-        if (context.projectId) {
-          const label = context.workflowName
-            ? `ワークフロー「${context.workflowName}」`
-            : 'ワークフロー'
-          parts.push(
-            `ユーザーはHQダッシュボードで${label}を閲覧しています。`,
-            `ワークフロー情報を取得するには以下を実行してください:`,
-            `  hq fetch workflow ${context.workflowName || context.workflowId}`,
-            `プロジェクトコンテキスト:`,
-            `  hq fetch project-context ${context.projectId}`,
-            `取得した内容をもとに回答してください。`
-          )
-        }
-        break
       case 'dag-workflow':
         if (context.projectId && context.dagWorkflowId) {
           parts.push(
             `ユーザーはHQダッシュボードで DAG ワークフロー (ID: ${context.dagWorkflowId}) のエディタ/詳細を閲覧しています。`,
-            `DAG ワークフローはノード/エッジ形式でスキル間の依存関係を表現し、fan-out / join / conditional / transform / review をサポートします。`,
+            `DAG ワークフローはノード/エッジ形式でスキル間の依存関係を表現し、fan-out / join / conditional / transform / script / review をサポートします。`,
             `DAG ワークフロー情報を取得するには以下を実行してください:`,
             `  hq fetch dag-workflow ${context.dagWorkflowId}`,
             `プロジェクトコンテキスト:`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@geekbeer/minion",
-  "version": "3.53.1",
+  "version": "3.55.1",
   "description": "AI Agent runtime for Minion - manages status and skill deployment on VPS",
   "main": "linux/server.js",
   "bin": {

package/rules/core.md

@@ -15,10 +15,7 @@ You are an AI agent running on a Minion VPS, managed by @geekbeer/minion.
 Project (組織・課金単位)
 ├── Context (markdown, PMが更新)
 ├── Members (minion + role: pm | engineer | accountant)
-├── Workflows (スキルの線形パイプライン + オプションcronスケジュール)
-│   ├── Versions (pipeline の不変スナップショット)
-│   └── Executions (実行履歴, ステップごとの進捗)
-└── DAG Workflows (ノード/エッジ形式のワークフロー, beta)
+└── DAG Workflows (ノード/エッジ形式のワークフロー)
     ├── Versions (graph の不変スナップショット)
     └── Executions (node_executions の集合, scope-aware)
 
@@ -26,14 +23,14 @@ Minion
 └── Routines (ミニオンローカルの定期タスク, cron付き)
 ```
 
-- **Workflow**: プロジェクトスコープ。線形パイプライン形式のバージョン管理ワークフロー。ミニオンAPIで push/fetch 可能。
-- **DAG Workflow**: プロジェクトスコープ。ノード/エッジで依存関係を表現する新方式。fan-out / join / conditional / transform / review をサポート。作成・編集はHQダッシュボードのみ、ミニオンは `dag-step-poller` で自動実行。詳細は `~/.minion/docs/api-reference.md` の「DAG Workflows」と `~/.minion/docs/task-guides.md` の「DAG ワークフロー」を参照。
+- **DAG Workflow**: プロジェクトスコープ。ノード/エッジで依存関係を表現するワークフロー。fan-out / join / conditional / transform / script / review をサポート。作成・編集はHQダッシュボードまたはミニオンAPI、ランタイムは `dag-step-poller` が自動実行。詳細は `~/.minion/docs/api-reference.md` の「DAG Workflows」と `~/.minion/docs/task-guides.md` の「DAG ワークフロー」を参照。
   - **PMロールで編集する場合の重要な規則**:
     - ノード/エッジ/contract の追加・更新は**個別API** (`/nodes` `/edges` `/contracts`) を使うこと。`PUT /dag-workflows/:id` による graph 全文PUTは型の取り違えが起きやすく、バリデーションエラーで 400 が返る
     - `edge.contract` は**単一のContract名（string）**のみ。配列は不可。複数の型構造を束ねたい場合は、それらを内包する複合Contractを1つ定義する
     - Contract内で `List<別Contract>` を表現するには `type: 'array'` + `items: "別Contract名"` を使う（詳細は `~/.minion/docs/api-reference.md` の「Contracts API」を参照）
     - **Contract はランタイムで強制される型定義**。`node-complete` 報告時に outgoing edge の contract で `output_data` が検証され、違反はノード `failed` 扱い。スキルが contract に沿った `## Output Data` を出せない場合は **transform ノードをスキルと下流の間に挟んで整形**すること。スキル側の SKILL.md を各ワークフロー専用に改修するのは原則 NG（スキルは汎用資産）
     - **transform ノードの I/O 型は edge の contract から自動導出**。incoming edge と outgoing edge にそれぞれ contract を必ず貼ること。`transform_instruction` は contract だけで意図が伝わらない場合の補足ヒント（任意）
+    - **script ノード (v3.54.0〜)** は LLM を使わない決定的処理用。`script_runtime` (`'python'` or `'node'`) と `script_source` を指定。input_data を stdin で JSON 受け取り → output_data を stdout に JSON 出力する規約。outgoing edge に contract を貼れば transform と同じ runtime validation が走る。LLMトークンを節約したい・出力ブレを許容できない定型処理に使う。詳細は `~/.minion/docs/task-guides.md` の「Script ノード」を参照
     - **fan_out の incoming edge に contract を貼る場合**、`fan_out_source` が指すフィールドが contract 内に `type='array'` として宣言されている必要がある（静的検証で弾かれる）
 - **Routine**: ミニオンスコープ。ミニオンローカルの定期タスク。
 - **Project Tasks / Milestones**: プロジェクトスコープ。**人間+ミニオンが共有するタスクボード**(5段階Kanban: `backlog`→`todo`→`doing`→`review`→`done`)とロードマップ(マイルストーン)。ミニオンは `/api/minion/projects/:projectId/{tasks,milestones,health}` で操作可能。
@@ -103,7 +100,7 @@ minion-cli --version                      # バージョン確認
 
 `http://localhost:8080` — 認証: `Authorization: Bearer $API_TOKEN`
 
-主なカテゴリ: Health, Skills, Workflows, Executions, Terminal, Files, Commands, Permissions, Admin (HQ-pushed freeze), Web Extraction (experimental)
+主なカテゴリ: Health, Skills, Executions, Terminal, Files, Commands, Permissions, Admin (HQ-pushed freeze), Web Extraction (experimental)
 
 #### Web Page Extraction 🧪 (experimental, v3.53.0〜)
 
@@ -202,7 +199,7 @@ Note: Codex CLI の `.codex/` ディレクトリはLLMからの直接編集が
 
 `$HQ_URL/api/minion/*` — 認証: `Authorization: Bearer $API_TOKEN`
 
-主なカテゴリ: Projects, Context, Workflows, DAG Workflows, Skills, Executions, Routines, Reports
+主なカテゴリ: Projects, Context, DAG Workflows, Skills, Executions, Routines, Reports
 
 DAG ワークフローのランタイム API は `$HQ_URL/api/dag/minion/*`（pending-nodes / claim-node / node-complete / dag-cron-tick）。`dag-step-poller` と `dag-cron-poller` デーモンが自動でポーリングするため、通常ミニオンのAI側から直接叩くことは無い。
 
@@ -224,7 +221,7 @@ Routine 実行中は以下もtmuxセッション環境で利用可能:
 - `MINION_ROUTINE_ID` — ルーティンUUID
 - `MINION_ROUTINE_NAME` — ルーティン名
 
-**変数**（ミニオン変数・プロジェクト変数・ワークフロー変数）はスキル本文の `{{VAR_NAME}}` テンプレートとして実行時に展開される。スキル作成時にパラメータ化したい値は `{{変数名}}` で記述すること。展開優先順位: ミニオン変数 < プロジェクト変数 < ワークフロー変数（後者が優先）。
+**変数**（ミニオン変数・プロジェクト変数）はスキル本文の `{{VAR_NAME}}` テンプレートとして実行時に展開される。スキル作成時にパラメータ化したい値は `{{変数名}}` で記述すること。展開優先順位: ミニオン変数 < プロジェクト変数（後者が優先）。
 
 **シークレット**（ミニオンシークレット）はサーバー起動時に `process.env` にロードされ、全子プロセスで環境変数 `$SECRET_NAME` として利用可能。APIキーやパスワード等の機密情報に使用する。シークレットは `{{VAR}}` テンプレートでは展開されない。
 

package/win/routes/chat.js

@@ -525,24 +525,11 @@ async function buildContextPrefix(message, context, sessionId, workspaceId, refe
           )
         }
         break
-      case 'workflow':
-        if (context.projectId) {
-          const label = context.workflowName ? `ワークフロー「${context.workflowName}」` : 'ワークフロー'
-          parts.push(
-            `ユーザーはHQダッシュボードで${label}を閲覧しています。`,
-            `ワークフロー情報を取得するには以下を実行してください:`,
-            `  hq fetch workflow ${context.workflowName || context.workflowId}`,
-            `プロジェクトコンテキスト:`,
-            `  hq fetch project-context ${context.projectId}`,
-            `取得した内容をもとに回答してください。`
-          )
-        }
-        break
       case 'dag-workflow':
         if (context.projectId && context.dagWorkflowId) {
           parts.push(
             `ユーザーはHQダッシュボードで DAG ワークフロー (ID: ${context.dagWorkflowId}) のエディタ/詳細を閲覧しています。`,
-            `DAG ワークフローはノード/エッジ形式でスキル間の依存関係を表現し、fan-out / join / conditional / transform / review をサポートします。`,
+            `DAG ワークフローはノード/エッジ形式でスキル間の依存関係を表現し、fan-out / join / conditional / transform / script / review をサポートします。`,
             `DAG ワークフロー情報を取得するには以下を実行してください:`,
             `  hq fetch dag-workflow ${context.dagWorkflowId}`,
             `プロジェクトコンテキスト:`,