@geekbeer/minion 3.52.0 → 3.55.1

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"]`
@@ -696,6 +688,72 @@ PUT `/api/email/inbox/:id` body:
 
 Note: 既読メールは受信後90日で自動削除される。未読メールは保持される。
 
+### Web Page Extraction 🧪 (experimental, v3.53.0〜)
+
+Web ページの読み取り・要約・情報抽出をミニオン内のサブプロセスで完結させ、メインの Claude Code セッションには結果 JSON だけを返すための実験的 API。Playwright MCP で DOM 全体がチャットに流れ込みトークン肥大化を起こす問題への対処として導入。
+
+| Method | Endpoint | Description |
+|--------|----------|-------------|
+| POST | `/api/web/extract` | URL を抽出済み JSON に変換 (タイトル・本文・主要構造化データ) |
+| GET  | `/api/web/recipes` | キャッシュされたレシピ一覧 (debug) |
+| DELETE | `/api/web/recipes?template=...&fingerprint=...` | レシピを削除 |
+
+**前提条件 (LLM の解決順):**
+1. **primary LLM プラグインが設定されていればそれを使用** (推奨)。`PUT /api/llm/config` で `claude` 等を primary に指定すると、CLI の認証情報 (`~/.claude/.credentials.json`) がそのまま使われる。API キーの別途設定は不要。
+2. primary 未設定で `ANTHROPIC_API_KEY` シークレットが設定されていれば、そちらを fallback として使用 (Anthropic Messages API の tool_use で JSON Schema を強制)。
+3. どちらもなければ 503 (`LLM_UNAVAILABLE`) を返す。
+
+その他の前提:
+- ホスト上で `npx playwright install chromium` を実行済みであること (未実行の場合 503 が返る)
+
+**`POST /api/web/extract` リクエスト:**
+```json
+{
+  "url": "https://example.com/article/123",
+  "hint": "本文と著者を抽出してほしい (任意, 抽出フィールドのヒント)"
+}
+```
+
+**レスポンス (success):**
+```json
+{
+  "success": true,
+  "experimental": true,
+  "url": "https://example.com/article/123",
+  "finalUrl": "https://example.com/article/123",
+  "statusCode": 200,
+  "recipeMode": "cold",
+  "recipeId": "example.com/article/:id#abc123def456",
+  "pageType": "article",
+  "title": "...",
+  "content": "Markdown 本文...",
+  "structured": { "title": "...", "author": "...", "publishedAt": "..." },
+  "selectors": { "title": { "selector": "h1" }, "author": { "selector": "a[rel=author]" } }
+}
+```
+
+**動作:**
+- 初回アクセス (cold): Playwright でレンダリング → Readability で本文抽出 → Anthropic Haiku でセレクタ生成 → SQLite (`page_recipes`) に保存 → セレクタで再抽出して返却
+- 2回目以降 (hot): URL 正規化・テンプレート化 → DOM フィンガープリントで保存済みレシピを照合 → セレクタで抽出のみ (LLM 呼び出しなし)
+- セルフヒール: hot 実行で空結果が返ったら `fail_count++`、3回失敗で破棄して次回 cold 再生成
+
+**URL 正規化ルール:**
+- `utm_*` `fbclid` `gclid` `ref` 等のトラッキングクエリは除去
+- `page` `p` `offset` 等のページネーション値は `:n` プレースホルダ化
+- パスセグメントは数値→`:id`、UUID→`:uuid`、20文字以上の英数字→`:slug` に置換
+- 例: `https://www.lancers.jp/work/proposal/123456?utm_source=foo&page=2` → `lancers.jp/work/proposal/:id?page=:n`
+
+**エラー:**
+- 401: APIトークン不正
+- 400: URL 欠落・不正
+- 502: primary LLM 呼び出し失敗 (`PRIMARY_LLM_FAILED`) / 返却 JSON が parse 不能 (`PRIMARY_LLM_BAD_JSON`)
+- 503: Playwright 未インストール (`PLAYWRIGHT_UNAVAILABLE`) / LLM 未設定 (`LLM_UNAVAILABLE`)
+- 500: 抽出失敗 (タイムアウト等)
+
+**注意 (experimental):**
+- レスポンス形状・URL 正規化ルール・キャッシュスキーマは予告なく変更される可能性がある
+- 認証付きページ (ログイン必須) は対応外。Cookie や対話的操作が必要な場合は Playwright MCP を使用すること
+
 ### Commands
 
 | Method | Endpoint | Description |
@@ -751,7 +809,7 @@ Response:
 ]
 ```
 
-`role` is either `"pm"` (project manager) or `"engineer"`.
+`role` is one of `"pm"` (project manager), `"engineer"`, or `"accountant"`.
 
 ### Project Context
 
@@ -789,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)。
@@ -980,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ロール限定)
 
@@ -1341,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` → 新ノード へのエッジを自動生成
@@ -1359,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
@@ -1617,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 ラッパー
 
@@ -1721,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発火が遅延する。
 
@@ -1743,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"
     }
   ]
 }
@@ -1752,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 内で閉じる。
@@ -1880,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 とは独立 | ❌ (内部) |
@@ -1905,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