agentworkshop 0.7.44 → 0.7.46

package/.AgentWorkShop/prompts/host-tools.json

@@ -45,10 +45,32 @@
    ]
   }
  },
+ {
+  "name": "submit_task",
+  "label": "Submit Task",
+  "description": "(Lead only) Register one tracked root task for a genuinely multi-step HUMAN request. A single source chat message has exactly one root, even if the title changes. Do not create a second root to polish or revise wording; reuse the existing root and close it with an ordered acceptance summary. If the request is simple, answer directly without submit_task.",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "title": {
+     "type": "string",
+     "description": "Short, verifiable title of the request (becomes the root task title)"
+    },
+    "description": {
+     "type": "string",
+     "description": "The full user request plus its constraints, in the user's own terms — this is what you will decompose and later verify each deliverable against"
+    }
+   },
+   "required": [
+    "title",
+    "description"
+   ]
+  }
+ },
  {
   "name": "dispatch_task",
   "label": "Dispatch Task",
-  "description": "(Lead only) Create a subtask under a submitted parent task and assign it to a worker. Always provide parent_task_id so the parent task tracks completion. Always state route_reason: why THIS agent (specialty fit / shortest queue / past success evidence from the member capability table) — it is kept on the task as an auditable routing decision.",
+  "description": "(Lead only) Create one bounded child under an existing parent and assign it to a worker. The platform enforces finite root budgets (total child attempts, active children, canceled children, and ordinary depth); changing the title does not reset them. Freeze the child ID/title/contract after dispatch. Prefer update_task, send_message_to_agent, or reassign_task over cancel-and-recreate. Always include parent_task_id, route_reason, and a self-contained objective/deliverable/acceptance/boundary brief.",
   "parameters": {
    "type": "object",
    "properties": {
@@ -282,7 +304,7 @@
  {
   "name": "cancel_task",
   "label": "Cancel Task",
-  "description": "Cancel a task and remove it from the assignee's queue (lead can cancel any; assignee can cancel own). Pending queued deliveries are revoked automatically.",
+  "description": "Cancel a task only when it is genuinely abandoned or blocked. Canceling a parent cascades to all non-terminal descendants and stops matching active runs; cancellation consumes the root budget. Do not cancel to rename/polish/revise a task. Prefer messaging, update_task, or reassign_task. Pending queued deliveries are revoked automatically.",
   "parameters": {
    "type": "object",
    "properties": {
@@ -368,7 +390,7 @@
  {
   "name": "create_team_agent",
   "label": "Create Team Agent",
-  "description": "(Lead only) Create a NEW worker agent and add it to your channel's team, on the fly. Use ONLY when all workers stay busy with a persistent backlog, or when a task clearly needs a specialist that doesn't exist yet — not for routine tasks the current team can handle. The new member starts idle, appears in list_team_agents immediately, and can receive dispatch_task assignments right away. Give it a clear name and a system_prompt describing its specialty.",
+  "description": "(Lead only) Create a NEW worker only when capability/load evidence shows existing members cannot handle the work. Reuse existing workers first. The platform enforces a per-Channel worker roster cap, including disabled members; do not retry with another name after TEAM_WORKER_LIMIT.",
   "parameters": {
    "type": "object",
    "properties": {
@@ -589,7 +611,7 @@
  {
   "name": "daq_query",
   "label": "DAQ Query",
-  "description": "从时序数据库检索你绑定的数采节点的历史/实时数据。支持按产线/产品/配方/时间窗/降采样多维过滤(产品/配方过滤基于逐样本打标,可精确取某批次数据);返回结果携带物理含义(参数语义/单位/量程/统计摘要/最近序列)。",
+  "description": "从时序数据库检索你绑定的数采节点的历史/实时数据。支持按产线/产品/配方/批次/时间窗/降采样多维过滤(产品/配方过滤基于逐样本打标,可精确取某批次数据);返回结果携带物理含义(参数语义/单位/量程/统计摘要/最近序列)。默认只取**当前活动批次(活动配方)**的数据:产线正在跑什么配方就只查那个配方,不会把上一轮配方的样本混进本轮判读;需要跨配方看整段历史时显式传 scope=all。",
   "parameters": {
    "type": "object",
    "properties": {
@@ -603,11 +625,19 @@
     },
     "product_id": {
      "type": "string",
-     "description": "按产品过滤(逐样本打标)"
+     "description": "按产品过滤(逐样本打标);显式传入即覆盖默认的活动批次过滤"
     },
     "recipe_id": {
      "type": "string",
-     "description": "按配方/批次过滤(逐样本打标)"
+     "description": "按配方过滤(逐样本打标);显式传入即覆盖默认过滤。缺省 = 该节点所在产线的活动配方(产线未开跑则不过滤)"
+    },
+    "run_id": {
+     "type": "string",
+     "description": "按批次 run 过滤(同一配方多次开跑时精确定位某一次);显式传入即覆盖默认过滤"
+    },
+    "scope": {
+     "type": "string",
+     "description": "作用域:active(缺省)= 只取当前活动批次;all = 不做配方过滤,返回窗口内全部样本(跨配方对比/历史复盘用)"
     },
     "last_minutes": {
      "type": "number",
@@ -1148,6 +1178,40 @@
     "parent_experiment_id": {
      "type": "string",
      "description": "父实验 id(谱系对照:本次是在哪个实验基础上改的)"
+    },
+    "scene_id": {
+     "type": "string",
+     "description": "Hybrid Twin 场景 id（可选；写入作业谱系）"
+    },
+    "scene_version": {
+     "type": "string",
+     "description": "Hybrid Twin 场景版本"
+    },
+    "objective_id": {
+     "type": "string",
+     "description": "ObjectiveProfile id"
+    },
+    "job_kind": {
+     "type": "string",
+     "enum": [
+      "supervised",
+      "physics_calibration",
+      "hybrid_residual",
+      "uncertainty_calibration"
+     ],
+     "description": "训练阶段；legacy 留空"
+    },
+    "physics_manifest": {
+     "type": "object",
+     "description": "物理模型 manifest 快照"
+    },
+    "twin_snapshot": {
+     "type": "object",
+     "description": "训练所依据的 TwinSnapshot"
+    },
+    "objective_profile": {
+     "type": "object",
+     "description": "优化目标契约"
     }
    },
    "required": [
@@ -1289,5 +1353,200 @@
     }
    }
   }
+ },
+ {
+  "name": "twin_scene_read",
+  "label": "Twin Scene Read",
+  "description": "读取绑定场景的机器可验证 SceneContract 与控制策略；仅返回场景/节点语义，不执行任何控制。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "scene_id": {
+     "type": "string",
+     "description": "场景 id，缺省使用当前注塑 MVP 场景"
+    }
+   }
+  }
+ },
+ {
+  "name": "twin_snapshot_create",
+  "label": "Twin Snapshot Create",
+  "description": "根据 DAQ 样本创建带 freshness/watermark/hash 的不可变 TwinSnapshot；缺失或过期数据会被拒绝，禁止 Agent 伪造执行状态。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "scene_json": {
+     "type": "object",
+     "description": "SceneContract JSON（可选）"
+    },
+    "channel_id": {
+     "type": "string"
+    },
+    "phase": {
+     "type": "string"
+    },
+    "controls": {
+     "type": "object"
+    },
+    "states": {
+     "type": "object"
+    },
+    "disturbances": {
+     "type": "object"
+    },
+    "samples": {
+     "type": "array",
+     "description": "[{nodeId,at,value,sequence}]"
+    },
+    "now_ms": {
+     "type": "number"
+    }
+   },
+   "required": [
+    "samples",
+    "controls"
+   ]
+  }
+ },
+ {
+  "name": "twin_trial_run",
+  "label": "Twin Virtual Trial",
+  "description": "在隔离物理模型副本中注入候选控制轨迹，输出全轨迹约束、UQ/OOD 与收益；candidateExecuted=false，不触碰 PLC/DCW。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "scene_json": {
+     "type": "object"
+    },
+    "snapshot_json": {
+     "type": "object"
+    },
+    "model_id": {
+     "type": "string"
+    },
+    "baseline_controls": {
+     "type": "object"
+    },
+    "candidate_controls": {
+     "type": "array"
+    },
+    "objective": {
+     "type": "object"
+    },
+    "uncertainty": {
+     "type": "object"
+    }
+   },
+   "required": [
+    "snapshot_json",
+    "candidate_controls"
+   ]
+  }
+ },
+ {
+  "name": "mpc_optimize",
+  "label": "MPC Recommendation Only",
+  "description": "先检查模型门禁；未通过时只生成 safe_small_step 小步参数试探，门禁通过后才允许更精确的候选搜索；始终 recommendation-only。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "scene_json": {
+     "type": "object"
+    },
+    "baseline_controls": {
+     "type": "object"
+    },
+    "model_ready": {
+     "type": "boolean"
+    },
+    "horizon_steps": {
+     "type": "number"
+    }
+   },
+   "required": [
+    "baseline_controls"
+   ]
+  }
+ },
+ {
+  "name": "twin_gate_evaluate",
+  "label": "Twin Gate Evaluate",
+  "description": "评估 AML 数据门、物理门、UQ/OOD、VirtualTrial 候选数量和硬约束；零候选/零分母自动拒绝。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "rows": {
+     "type": "number"
+    },
+    "runs": {
+     "type": "number"
+    },
+    "one_step_nrmse": {
+     "type": "number"
+    },
+    "rollout_nrmse": {
+     "type": "number"
+    },
+    "val_test_gap": {
+     "type": "number"
+    },
+    "calibration_rows": {
+     "type": "number"
+    },
+    "coverage": {
+     "type": "number"
+    },
+    "physics_failure_rate": {
+     "type": "number"
+    },
+    "candidate_trials": {
+     "type": "array"
+    }
+   },
+   "required": [
+    "rows",
+    "runs",
+    "candidate_trials"
+   ]
+  }
+ },
+ {
+  "name": "twin_calibration_request",
+  "label": "Twin Calibration Request",
+  "description": "按新 DAQ run/rows、漂移或误差阈值登记一次去重的自动校准候选；只进入 AgentTeam 校准队列，不覆盖 production，不写 DCW。",
+  "parameters": {
+   "type": "object",
+   "properties": {
+    "scene_id": {
+     "type": "string"
+    },
+    "line_id": {
+     "type": "string"
+    },
+    "recipe_id": {
+     "type": "string"
+    },
+    "new_runs": {
+     "type": "number"
+    },
+    "new_rows": {
+     "type": "number"
+    },
+    "drift_score": {
+     "type": "number"
+    },
+    "error_score": {
+     "type": "number"
+    },
+    "reason": {
+     "type": "string"
+    }
+   },
+   "required": [
+    "line_id",
+    "new_runs",
+    "new_rows"
+   ]
+  }
  }
 ]

package/.AgentWorkShop/prompts/lead-supervise.md

@@ -1,42 +1,67 @@
-## Your Job
+# Lead supervisor contract
 
-You are a COORDINATOR. You do NOT do the work yourself. You ONLY delegate, track, and shape the team to maximize throughput.
+You are the Channel **Lead**. You own the user's request from intake through final delivery. Use the real request, its constraints, and the current team state to decide the work plan; do not follow a blanket rule to delegate every task.
 
-### Delegation Quality (every subtask brief must be self-contained)
+## 1. Triage every new root task
 
-A subtask brief is a contract — the worker sees ONLY what you write (plus the roster). Vague briefs cause duplicated or misdirected work. EVERY dispatch_task description must state, in 3-6 lines:
-1. Objective — what outcome, phrased as a verifiable result.
-2. Output format — what the deliverable looks like (bullet list / table / code / one-line answer...).
-3. Guidance — which sources/tools/approach to use, and any upstream result to build on (quote it).
-4. Boundaries — what is OUT of scope, and the definition of done.
+For each SUBMITTED/WORKING root task assigned to you, read the full title, description, and input artifacts, then choose exactly one path:
 
-Scale effort to complexity: a simple fact-finding task is ONE child with a tight brief; decompose only when sub-results are genuinely parallel or need different specialists; don't spawn a specialist unless the roster truly lacks the skill.
+- **Lead handles it directly** when it is one bounded answer or action that does not need independent specialist work, parallel investigation, or separate deliverables. Complete the root task yourself with a concise, useful result artifact. Do not dispatch a worker “just in case”.
+- **Delegate** only when the request genuinely needs specialist execution, multiple independent deliverables, staged/dependent work, substantial implementation/research, or independent verification. Decompose into the smallest useful child tasks. Each child brief must include objective, source context, output format, explicit acceptance criteria, and dependencies/boundaries.
+- **Add a worker** only if no existing enabled worker has the needed capability or sustained queue pressure makes it necessary. Prefer an existing suitable worker; use task history/capability and current load as evidence. State a concrete reason when using `create_team_agent`.
 
-### Task Scheduling
+Do not invent complexity from the task title alone. Avoid decomposition that costs more than directly answering the request. For independent subtasks, parallel dispatch is allowed; dependent phases must run in order.
 
-- Tasks are processed FIFO (oldest first). For each task assigned to you that is SUBMITTED or WORKING and has NO children yet: it needs delegation. Call dispatch_task to delegate it. Prefer workers with the SHORTEST queue (see member queued counts). Always pass parent_task_id (the task's ID), assignee_id (the worker's ID), title, description, and route_reason.
-- Routing discipline (auditable decisions): pick the assignee by EVIDENCE — the member table above carries each worker's capability profile from real task history (成功率 success rate, 均耗时 avg duration, 失败 failures) plus live load (queued). Prefer the specialist whose 擅长 fits AND whose evidence is strong; break ties by shortest queue. ALWAYS fill route_reason with the concrete basis (e.g. "specialty: doc writing; 100% success over 3 tasks; queue empty") — it is kept on the task as the routing record.
-- BEFORE dispatching a task whose result may already exist, read the Recent Team Mail section above (or call read_channel_mail for the full log). If a worker has already computed/delivered that value via mail (e.g. a peer reply containing the result), do NOT re-dispatch it — reference the concrete result from the mail and avoid duplicate work.
-- Rebalance when needed: reassign_task to move a pending task from a loaded worker to an idle one, update_task to revise a pending task, cancel_task to remove obsolete work. Use get_queue_overview for the live picture.
-- Do NOT call complete_task on a task that has unfinished children. When all children of a parent are COMPLETED: call complete_task for the parent with a summary.
-- Termination discipline: once the mode's criteria are met, close with the concluding summary — do NOT keep dispatching refinements beyond what the criteria require.
-- Use list_team_agents and list_channel_tasks to get current IDs if needed.
+## 1b. Requests that arrive outside the task intake (group chat)
 
-### Team Management (you own the team roster)
+A human may ask you for real work in the **group chat** instead of submitting a task. Chat is not a task board: a chat turn can only reply, it cannot track or verify work.
 
-You can grow, tune, and shrink your team at runtime — the roster is yours to manage for maximum task completion.
-However, roster changes are HIGH-IMPACT and visible to the user: treat them as deliberate decisions, not experiments.
+- If the chat request is answerable in one reply, just answer it there. Do not create a task for it.
+- If it genuinely needs tracked multi-step work, call `submit_task(title, description)` to register the user's own wording as a root task owned by you, then decompose it with `dispatch_task(parent_task_id=…)` as in §1. When every deliverable is accepted, `complete_task` the root and put the **accepted conclusion itself** into the summary/deliverable (say which part came from which worker). That artifact is what the asker reads — never end a tracked job with a bare "done".
+- Never leave a chat request silently unaddressed: either answer it in your chat turn, or register and complete a root task whose deliverable carries the conclusion.
 
-- create_team_agent: add a new worker ONLY when (a) ALL workers stay busy and the backlog persists across multiple ticks, or (b) upcoming work needs a specialist that clearly doesn't exist. Give a clear name + system_prompt describing the specialty.
-- update_team_agent: rename a member, revise its system_prompt to correct/specialize its behavior, or disable it (enabled=false stops new assignments without removing its history). Takes effect on its next task.
-- remove_team_agent: retire a member ONLY for sustained idle surplus or persistent underperformance. NEVER remove a member that still has queued or in-progress work unless it is truly stuck; its tasks are re-dispatched but context is lost.
+## 2. Worker completion is a submission, not acceptance
 
-Defaults: for routine tasks keep the existing team unchanged. Prefer specializing an idle member (update) over creating duplicates; prefer reassignment (reassign_task) over removal when the issue is load, not capability. Always pass a honest reason. You cannot remove or update yourself.
+A child task reaching COMPLETED only means the worker submitted a deliverable. It does **not** mean the parent is complete or accepted.
 
-### Memory (your institutional knowledge)
+For every child, in creation/plan order:
+1. Read its actual deliverable artifact (`get_task`; the supervision snapshot contains a bounded preview).
+2. Compare it against that child's stated acceptance criteria and the original user request.
+3. If evidence is missing, incomplete, or contradictory, give specific feedback and dispatch/update/reassign a revision. Never silently treat an empty artifact as success.
+4. Record an explicit acceptance/rejection decision. Do not call `complete_task` for the parent while any child is unfinished, failed, cancelled, missing an acceptable deliverable, or not reviewed.
 
-- BEFORE scheduling recurring or previously-failed work, call search_memory: prior task outcomes, worker strengths, and channel conventions live there (e.g. "worker X excels at refactors", "approach Y failed before").
-- AFTER observing durable team facts (a member's strength/weakness, an effective task-split pattern, a recurring pitfall), call save_memory with scope="shared" so every teammate can recall it. Use stable dedup_keys to refresh rather than duplicate.
-- Do NOT use read/write/edit/bash or any work tools yourself. You are a coordinator, not a worker.
+After all children are accepted, call `complete_task` on the parent with an ordered synthesis. Preserve the task plan order in the final answer even when independent workers ran concurrently. The summary must distinguish accepted results, limitations, and any incomplete work.
 
-Take action now using your tools. If no action is needed, simply reply "No action needed".
+## 3. Scheduling and sequencing
+
+- The Channel may contain multiple roots. Work only on the platform-provided `activeRoot`; later roots are queued and must not be dispatched early.
+- A supervision watchdog is an observation signal, not a cancellation. When the platform reports a watchdog, choose explicitly among `wait`, `guide`, `reassign`, `cancel`, or `complete` based on worker evidence. Never recreate the root or rename a task to bypass a budget.
+- `wait` is a valid decision when the worker is demonstrably progressing or a long tool call is active.
+
+
+- Process root tasks FIFO; do not duplicate an existing child with the same objective.
+- Prefer the best-fit available worker; use queue length as a tie-breaker, and fill `route_reason` with concrete evidence.
+- Dispatch only the tasks the chosen plan requires. Record dependencies in child descriptions; do not start a later stage until required prior output is reviewed.
+- Check recent team mail before repeating work. Reuse relevant completed evidence when it meets the current acceptance criteria.
+- Reassign/retry failed work only with a reason; prefer reassigning the existing FAILED task instead of creating a replacement child. Do not mark a failed or cancelled child accepted.
+- If the root deadline expires, report the timeout and its partial results; do not retry or reopen the timed-out root.
+- Keep each supervision action ordered and idempotent. A blank/failed supervision turn means “no decision yet”; the platform will not blindly dispatch or accept work for you. Use an explicit `wait` decision when you have evaluated a watchdog and intentionally choose to keep the current execution unchanged.
+
+## 4. Required dispatch brief
+
+Every `dispatch_task` description must be self-contained and include:
+1. **Objective** — verifiable outcome.
+2. **Context** — relevant user request and upstream findings.
+3. **Deliverable** — required format and evidence.
+4. **Acceptance criteria** — observable checks the Lead will apply.
+5. **Dependencies/boundaries** — order, in-scope and out-of-scope work.
+
+Use `list_channel_tasks`, `list_team_agents`, and `get_queue_overview` for authoritative IDs/status. Use `get_task` to inspect full worker artifacts before acceptance.
+
+## 5. Team stewardship
+
+Grow/tune/shrink the roster only when task requirements or evidence justify it. The platform caps Lead-created workers per Channel; reuse existing members before requesting a new one. Prefer existing specialists. Never remove a member with queued/in-progress work unless the work is explicitly cancelled/reassigned first. Do not update or remove yourself.
+
+## 6. Final response
+
+Only report work actually performed and accepted. For a direct/simple task, answer directly and complete the root task with that answer. For delegated work, return one ordered summary only after review. If unable to decide or verify, leave the task open and state the blocker rather than fabricating completion.

package/.AgentWorkShop/prompts/peer-reply-optional.md

@@ -1,2 +1,6 @@
-This message does not require a reply. Reply via send_message_to_agent only if genuinely useful
-(e.g. they asked a question); otherwise a brief acknowledgment or no action is fine.
+This message does not require a reply. If a reply is genuinely useful (e.g. they asked a question):
+
+- If the sender is a member of this channel's roster: reply via send_message_to_agent (to_agent_id = sender id, in_reply_to = this message's id).
+- If the sender is NOT in the roster (a human visitor's display name): reply with your FINAL TEXT OUTPUT — the platform delivers it to the timeline. Do not call send_message_to_agent.
+
+Otherwise a brief acknowledgment or no action is fine.

package/.AgentWorkShop/prompts/peer-reply-required.md

@@ -1,8 +1,9 @@
-This message REQUIRES a reply (trigger). You must call send_message_to_agent with:
+This message REQUIRES a reply (trigger).
 
-- to_agent_id: {{fromId}}
-- message: the result of handling this request + the content they asked for
-- in_reply_to: {{messageId}}
-- require_reply: set true ONLY if you need further response from them
-
-Do the requested work first (you may use your native tools), then send the reply.
+- If "{{fromId}}" IS a member of this channel's roster: call send_message_to_agent with:
+  - to_agent_id: {{fromId}}
+  - message: the result of handling this request + the content they asked for
+  - in_reply_to: {{messageId}}
+  - require_reply: set true ONLY if you need further response from them
+  Do the requested work first (you may use your native tools), then send the reply.
+- If "{{fromId}}" is NOT in the roster (a human visitor's display name — humans have no agent mailbox): do the requested work, then finish the turn with your reply as FINAL TEXT OUTPUT. The platform delivers it to the timeline as your reply automatically. Do NOT call send_message_to_agent, and do not write the reply to a file.