agentworkshop 0.7.20 → 0.7.21

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 CHANGED
@@ -1,475 +1,486 @@
1
- <div align="center">
2
-
3
- <img src="https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/hero.png" alt="AgentWorkShop — Agents that run the production line" width="100%" />
4
-
5
- # AgentWorkShop
6
-
7
- **Where AI agent teams meet the production line.**
8
-
9
- [![Nuxt 4](https://img.shields.io/badge/Nuxt-4-00DC82?logo=nuxt&logoColor=white)](https://nuxt.com)
10
- [![Vue 3.5](https://img.shields.io/badge/Vue-3.5-42B883?logo=vuedotjs&logoColor=white)](https://vuejs.org)
11
- [![TypeScript 5.7](https://img.shields.io/badge/TypeScript-5.7-3178C6?logo=typescript&logoColor=white)](https://www.typescriptlang.org)
12
- [![Node ≥ 23.4](https://img.shields.io/badge/Node.js-%E2%89%A5%2023.4-3C873A?logo=nodedotjs&logoColor=white)](https://nodejs.org)
13
- [![SQLite node:sqlite](https://img.shields.io/badge/SQLite-node:sqlite-003B57?logo=sqlite&logoColor=white)](https://nodejs.org/api/sqlite.html)
14
- [![License: PolyForm Noncommercial](https://img.shields.io/badge/License-PolyForm_NC_1.0-8A2BE2?logo=openaccess&logoColor=white)](./LICENSE)
15
-
16
- **[中文文档 →](./README-zh.md)** · **[Online Docs →](https://kingdol666.github.io/AgentWorkShop/)**
17
-
18
- *A configuration-driven platform where **AI agent teams** and an **industrial digital twin** share one runtime — agents query real telemetry, issue supervisory setpoints through human-approved write control, and every event streams live to a 3D twin.*
19
-
20
- </div>
21
-
22
- > ⚠️ **Positioning: supervisory layer.** AgentWorkShop is a *supervisory* (SCADA-adjacent) layer for production-line management, digital twins, DAQ and agent orchestration, operating at **second-level soft real-time**. It is **not** a hard real-time controller: any time-critical loop (**< 10 ms**, interlocks, safety, servo) **must live inside the PLC**. Setpoints written here are advisory — plant-side logic may veto.
23
-
24
- ---
25
-
26
- ## What is this?
27
-
28
- AgentWorkShop started as a **multi-agent software workshop** — channels of coding agents with a lead-agent scheduler, a 7-state task machine, persistent memory, and four interoperable entry points (WebSocket / MCP / A2A / REST).
29
-
30
- It grew an **industrial half**: a full data-acquisition and write-control stack (Modbus TCP / OPC UA), production lines with recipes and batch runs, a 3D digital-twin town — and the bridge that makes it unique: **agents can be granted bound, permission-scoped access to real industrial nodes**, query their live telemetry with physical semantics attached, and drive write operations through an interlock → human-in-the-loop → readback pipeline.
31
-
32
- The result: submit a goal like *"analyze the melt temperature trend and optimize the setpoint"* — and an agent team reads real sensor history, computes statistics, proposes a new setpoint, waits for your approval in the HITL panel, writes it to the PLC, verifies the readback, and reports the numbers back. **End to end, verified by automated E2E.**
33
-
34
- <div align="center">
35
- <img src="https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/town-demo.gif" alt="3D digital twin — live production line" width="86%" />
36
- <br><sub><b>Live 3D twin.</b> Line equipment, device health, DAQ channels and trend analysis — all driven by real-time telemetry.</sub>
37
- </div>
38
-
39
- ---
40
-
41
- ## Highlights
42
-
43
- | Capability | Why it matters |
44
- |---|---|
45
- | **Agent teams, industrial scope** | Agents bind to DAQ/DCW nodes and see semantic cards — physical meaning, units, safe range, recipe window — never raw registers. |
46
- | **Human-approved write control** | DCW writes flow through **safe-range ∩ recipe-window** interlock → optional **HITL approval** → PLC write → **readback verification** → signed write history. |
47
- | **Read-write DCW channels (v0.7)** | Every control node also **reads its PLC value back** through the same calibration path it writes with: periodic + on-demand + agent reads surface **SET vs ACT** side by side in the DCW console, the twin panel (green ACT row) and a new `dcw_read` agent tool — passive observation, never blocked by write interlocks. |
48
- | **Five field protocols** | Modbus TCP, Modbus RTU-over-TCP (serial gateway), OPC UA, MQTT and HTTP/REST — acquisition and write-control drivers with connection pools, classified error messages and per-driver connection tests. `mock` covers demos/CI; the driver registry accepts plugin-registered protocols. |
49
- | **Per-channel LLM selection** | Each channel picks a **harness → provider → model (+effort)** triple from the harness's live catalog (e.g. `zhipu-coding-plan/glm-5.3-flash` on omp, `ustc/glm-5.3-flash` on dsh). Members inherit it unless they override — mixing harnesses in one team is a first-class setup, not a workaround. |
50
- | **Configurable cadences (v0.7.7)** | Sampling default & floor and Timescale query bucket default & floor are **live settings** (`daq.sampling.*`, `daq.query.*`): change them in `config.yml`, the Settings UI or via `aw config set` — hot-reloaded, clamped on node create/patch, and the injected agent tool descriptions always carry the current values. |
51
- | **Fully config-driven runtime (v0.7)** | Every runtime knob (memory budgets, compaction, rollback guardrails, retention, backups, log level…) is declared once in the settings descriptor registry with precedence **config.yml < runtime-settings < env** — legacy env names kept as aliases, no hardcoded defaults left in code. Project-level `.AgentWorkShop` wins; `~/.AgentWorkShop` is the user-level fallback (auto-seeded on install). |
52
- | **Multi-modal DAQ frame pipeline (v0.6)** | Multi-point profiles (thickness/scanner) and CCD image frames are processed through template sink pipelines before storage: vectors & metadata into Timescale (`daq_frames`), pixels into object storage (MinIO, auto disk fallback); derived-metric thresholds ride the existing alarm chain. |
53
- | **Plugin extension API (v0.6)** | `ctx.daq.registerDriver / registerProcessor / registerTemplate` for custom acquisition and sink algorithms (drop into `plugins/`); `ctx.omp.registerTool` for custom agent tools, hot-injected into every running session on registry change. |
54
- | **Line operations** | Lines → products → recipes → batch runs. Recipe windows gate acquisition and interlock writes; every sample is tagged `product/recipe/run` for per-batch isolation. |
55
- | **Lead-agent orchestration** | Each channel has one lead: decomposes goals, dispatches to idle workers, reassigns failures, judges goal satisfaction. LLM decisions with a deterministic rule-engine fallback — the system never stalls. |
56
- | **Three execution modes** | `goal` (satisfaction judging) · `loop` (fixed-interval replay) · `pipeline` (ordered stages). 7-state task machine with progress, artifacts and full history. |
57
- | **Four entry points** | One manager behind every door: **WS** (AEP v1 event stream with seq-resume), **MCP** (in-process tools), **A2A** (JSON-RPC 2.0 + AgentCard), **REST**. |
58
- | **Persistent memory** | Private + channel-shared domains; FTS5 with CJK segmentation, optional vector hybrid recall, token-budgeted injection; session compaction summaries auto-archived, team chronicle and idle reflections keep accumulating (v0.6). |
59
- | **Harness-agnostic** | One `AgentInterface` — `mock` (in-process), `omp` / `codex` / `dsh` / `opencode` (real engine subprocesses over RPC/ACP/JSON-RPC) and a Claude SDK adapter. The platform never knows which one runs. |
60
- | **3D digital twin** | Three.js town: place line equipment and channel territories, watch device health, alarms and live values — driven by the same event bus. |
61
-
62
- ---
63
-
64
- ## Interface
65
-
66
- <div align="center">
67
-
68
- | Agent Workbench | Line Operations |
69
- |:---:|:---:|
70
- | ![Agent workbench](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/workshop.png) | ![Line operations](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/dcw.png) |
71
-
72
- | DAQ Center | Digital Twin Town |
73
- |:---:|:---:|
74
- | ![DAQ center](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/daq.png) | ![Digital twin town](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/town.png) |
75
-
76
- </div>
77
-
78
- ---
79
-
80
- ## Architecture
81
-
82
- ```mermaid
83
- flowchart TB
84
- subgraph FE["Frontend — Nuxt 4 / Vue 3"]
85
- UI["Workshop UI · 3D Twin · Dashboards"]
86
- WS["AEP client — seq resume"]
87
- end
88
- subgraph SRV["Server — Nitro / h3"]
89
- REST["REST /api/workshop/**"]
90
- HUB["WS Hub — AEP v1"]
91
- A2A["A2A JSON-RPC"]
92
- MCP["MCP Server"]
93
- subgraph RT["Runtime"]
94
- MGR["AgentChannelManager"]
95
- SCH["SchedulerLoop — lead supervision"]
96
- TE["TaskEngine — 7-state machine"]
97
- AR["AgentRuntime × N"]
98
- MEM["AgentMemory — FTS5 + vector"]
99
- BUS["ChannelBus — per-channel seq + ring"]
100
- end
101
- subgraph IND["Industrial"]
102
- DAQ["DAQ gateway — per-node edge runtimes"]
103
- DCW["DCW gateway — write control"]
104
- BR["Bus — inproc / MQTT"]
105
- TSDB["TSDB — SQLite / Timescale"]
106
- end
107
- subgraph HB["Harness adapters"]
108
- MOCK["mock"]
109
- OMP["omp — RPC subprocess"]
110
- CDX["codex — app-server"]
111
- DSH["dsh — ACP"]
112
- OC["opencode — serve"]
113
- CLD["claude — SDK"]
114
- end
115
- DB[("SQLite — channels · agents · tasks
116
- messages · memories (FTS5) · events")]
117
- end
118
- UI <--> WS
119
- WS --> BUS
120
- REST & A2A & MCP --> MGR
121
- MGR --> SCH & TE & AR
122
- AR --> MEM
123
- AR --> MOCK & OMP & CDX & DSH & OC & CLD
124
- MGR & TE & MEM & BUS --> DB
125
- DAQ <--> BR --> TSDB
126
- DCW --> BR
127
- DAQ & DCW --> BUS
128
- ```
129
-
130
- **The agent × machine bridge** (the part worth reading the source for):
131
-
132
- ```
133
- agent ──binds to──▶ node (daq: auto / dcw: manual)
134
- │ │
135
- │ my_industrial_nodes ◀── semantic card: meaning · unit · safe range · recipe window
136
- │ daq_query ◀── TSDB history, stats + physical semantics
137
- │ dcw_control ──▶ interlock (safe range ∩ recipe window)
138
- │ ──▶ HITL approval (manual mode, 180 s timeout)
139
- │ ──▶ PLC write → readback check → ACK + write history
140
- ◀── result text with numbers the agent can cite
141
- ```
142
-
143
- ---
144
-
145
- ## Quick start
146
-
147
- ### Prerequisites
148
-
149
- ```bash
150
- node -v # ≥ 23.4.0 (needs built-in node:sqlite)
151
- ```
152
-
153
- > The real-agent harnesses require their CLI on PATH — `omp`, `codex`, `opencode` or `dsh` (any subset; each channel can mix harnesses). The `mock` harness works out of the box for demos and CI. Optional DAQ infrastructure (MQTT broker + TimescaleDB) auto-starts via Docker when reachable (`docker compose up -d`).
154
-
155
- ### Option A — install from npm (recommended)
156
-
157
- ```bash
158
- npm install -g agentworkshop # → `aw` / `agentworkshop` on PATH
159
- aw start # first run builds once (~2-3 min) → http://localhost:3001
160
- ```
161
-
162
- That's it — no checkout, no build tools. On first launch everything initializes into the config root **`~/.AgentWorkShop`**: the default `config.yml`, a generated `.env` holding a random session secret, `runtime-settings.json`, a docker-compose seed and an empty `data/` directory. All runtime data (SQLite, JSON repos, backups, logs) lives there too — config and data stay with the install, not the working directory.
163
-
164
- Prefer a one-off run without installing?
165
-
166
- ```bash
167
- npx agentworkshop start # fetch + run, nothing persisted globally
168
- ```
169
-
170
- ### Option B — from source
171
-
172
- ```bash
173
- git clone https://github.com/kingdol666/AgentWorkShop.git && cd AgentWorkShop
174
- pnpm install
175
- pnpm dev # → http://localhost:3000 (port from config.yml)
176
- ```
177
-
178
- Production from source:
179
-
180
- ```bash
181
- pnpm build # nuxt build → .output/
182
- pnpm start # port from config.yml → server.prod.port
183
- ```
184
-
185
- > In a source checkout the config root is the project's **`.AgentWorkShop/`** folder (runtime overrides, data, project-level commands), while `config.yml` / `.env` stay at the checkout root, version-controlled as the factory defaults.
186
-
187
- ### Updating
188
-
189
- ```bash
190
- aw update # check + self-update the global install
191
- aw update --check # only report; nothing is installed
192
- npm install -g agentworkshop@latest # manual equivalent
193
- ```
194
-
195
- Releases follow semver. Every `aw start` verifies the config root and migrates it in place when a new version changes the layout — your data survives upgrades.
196
-
197
- ### Your first agent × line session (~2 minutes)
198
-
199
- 1. **Sign in** — register in the sidebar (or `POST /api/users/register`).
200
- 2. **Build a line** — `Line Operations` → create a line, add DAQ nodes (e.g. `daq-temp-tc`) and control nodes (e.g. `dcw-temp-sp`), create a product + recipe, hit **Start**. Live values start flowing.
201
- 3. **Create a team** — `Agent Workshop` → pick a lead + workers, **deploy** into a channel.
202
- 4. **Bind nodes** — open the agent's detail panel → bind the DAQ node (*auto*) and the control node (*manual* = needs your approval).
203
- 5. **Submit the goal** — *"Analyze the last 5 minutes of melt temperature; if deviation from 182 °C exceeds 1 °C, correct the setpoint (wait for my approval)."*
204
- 6. **Approve** — the agent reads real history, computes the mean, requests the write → approve in the HITL panel → watch the setpoint change and the goal close with a numeric report.
205
-
206
- ---
207
-
208
- ## Configuration & CLI — config-driven by design
209
-
210
- One runtime, one source of truth. **`config.yml`** declares defaults; **`runtime-settings.json`** inside the config root carries runtime overrides; environment variables and CLI flags sit on top. Every editable key is described once in `shared/config/schema.json` (type, range, enum, live-vs-restart) and surfaced through the same descriptors in **both the UI and the CLI**.
211
-
212
- ```
213
- config.yml (defaults) < .AgentWorkShop/runtime-settings.json (runtime) < env vars / CLI flags
214
- ```
215
-
216
- The config root is **`~/.AgentWorkShop`** for a global install (`npm i -g`) — wherever you run `aw` from — and **`<repo>/.AgentWorkShop`** in a source checkout (with `config.yml` / `.env` staying at the checkout root as version-controlled factory defaults). `AW_HOME` redirects it; `AW_MODE=home` forces the global shape.
217
-
218
- ### Live settings, persisted, hot-reloaded
219
-
220
- - The **Settings → Runtime config** tab renders every editable key from the descriptors — change server ports, theme, API timeouts, locale or the approval gate, hit save.
221
- - `live` keys apply instantly (theme, title, timeouts, approval gate, DAQ sampling cadences, TSDB query buckets…) over a server-sent event stream — no reload, no restart.
222
- - `restart` keys (ports, hosts) persist to disk and take effect on the next launch of the matching mode (`aw dev` / `aw start`).
223
- - One channel for every writer: the UI, the CLI and the server's file watcher all converge on the same settings file, so a change made anywhere shows up everywhere.
224
-
225
- Example — retune the acquisition and query cadences live:
226
-
227
- ```bash
228
- aw config set daq.sampling.defaultIntervalMs 2000 # new nodes sample every 2 s
229
- aw config set daq.sampling.minIntervalMs 500 # per-node floor (create/patch clamp)
230
- aw config set daq.query.defaultBucketMs 3000 # TSDB reads default to a 3 s bucket
231
- aw config set daq.query.minBucketMs 500 # query floor (samples/line query/agent tool)
232
- ```
233
-
234
- Agent tool descriptions are re-rendered with the current values on every injection, so an LLM always sees the floor and default that will actually apply to its `daq_query` calls.
235
-
236
- ### The `aw` CLI
237
-
238
- | Command | What it does |
239
- |---|---|
240
- | `aw start · aw dev · aw build` | Production server / dev server / build — ports from the effective config; first `start` builds once |
241
- | `aw config list · get · set · unset · reset` | Read & write runtime settings (validated against the schema, atomic writes) |
242
- | `aw home` | Inspect / initialize the config root `.AgentWorkShop` |
243
- | `aw init <dir>` | Scaffold a runnable project (full config system + CLI included) |
244
- | `aw register <path\|url\|npm:pkg>` | Register a new command — project-local or `--global` |
245
- | `aw update` | Check npm for the latest release and self-update the global install |
246
- | `aw doctor` | Environment + project health check (node, config, ports, keys) |
247
- | `aw status` | Live overview: mode, config sources, running server, command table |
248
- | `aw tui` | Terminal workbench: channel/agent management, task submission, live monitor pane, HITL answering (see `tui/README.md`) |
249
-
250
- Global flags: `--help/-h` · `--version/-v` · `--json` (machine-readable) · `--root <dir>` · `--debug`.
251
-
252
- ### Command registration
253
-
254
- Commands are plain modules exporting `{ meta, run }`. Drop one into a scanned directory and it's live on the next invocation — no registry bookkeeping, convention over configuration:
255
-
256
- | Scope (highest wins) | Directory |
257
- |---|---|
258
- | project | `<root>/.AgentWorkShop/commands/` |
259
- | user | `~/.AgentWorkShop/commands/` |
260
- | built-in | packaged with the CLI (`cli/commands/`) |
261
-
262
- `aw register <file|url|npm:pkg>` copies a command into the right scope (`--global` for user scope); `aw help` lists everything that's registered.
263
-
264
- ```js
265
- // ~/.AgentWorkShop/commands/hello.mjs
266
- export const meta = { name: 'hello', group: 'Custom', summary: 'Say hi', usage: 'aw hello [--name <n>]' }
267
- export async function run(argv, ctx) {
268
- console.log(`Hi ${argv.flags.name ?? 'AW'} — mode: ${ctx.mode}`)
269
- }
270
- ```
271
-
272
- ---
273
-
274
- ## The industrial stack in detail
275
-
276
- ### Data acquisition (DAQ)
277
-
278
- - **Five protocol drivers**: Modbus TCP, Modbus RTU-over-TCP (serial gateway), OPC UA, MQTT, HTTP/REST — connection pools, classified error messages, per-driver connection tests; the driver registry accepts plugin-registered protocols.
279
- - **Per-node edge runtimes**: independent sampling cadence, publish cadence, in-flight mutex per node — one slow driver never blocks its neighbors. Sampling and query defaults/floors are driven by the live `daq.sampling.*` / `daq.query.*` settings.
280
- - **Pipeline**: driver → queue (in-process or MQTT, offline buffer on disconnect) → consumer with out-of-order defense → three-way fan-out: WS live push (gated), TSDB batch write, device-twin writeback.
281
- - **Robustness**: TSDB single-in-flight writes with bounded retries, buffer backpressure with drop counters, real loss metrics exposed on `daq.controller` frames.
282
- - **Alarms**: recipe-scoped monitoring windows with **2 % hysteresis + 3-tick debounce**; alarm/offline transitions are instant (safety first).
283
-
284
- ### Write control (DCW)
285
-
286
- - Engineering-unit writes: `linear` calibration (scale/offset) PLC↔physical, **readback verification** with deadband tolerance, ACK states and write history.
287
- - **Interlock**: with a line running, the active recipe's parameter window *replaces* the node's global safe range for that node.
288
- - **HITL**: `manual`-mode bindings suspend the write for user approval (deduped per agent+node; re-validation at approval time — permission is re-checked when you click approve).
289
-
290
- ### Recipe & batch
291
-
292
- `Line → Product → Recipe → Run`. Starting a run applies recipe params node-by-node (each write verified), gates acquisition per line, and tags every sample with `line/product/recipe/run` — per-product data isolation with five-dimension queries (line × product × recipe × time × node).
293
-
294
- ---
295
-
296
- ## Usage
297
-
298
- ### Authentication
299
-
300
- Email + password login issues a **bearer token** (multiple tokens per user, individually revocable).
301
-
302
- ```bash
303
- # register
304
- curl -X POST http://localhost:3000/api/users/register \
305
- -H 'content-type: application/json' \
306
- -d '{"email":"you@example.com","password":"secret","name":"you"}'
307
-
308
- # every workshop call
309
- curl http://localhost:3000/api/workshop/channels \
310
- -H 'authorization: Bearer <token>'
311
- ```
312
-
313
- ### Line-level permissions
314
-
315
- Industrial data is gated **per production line** with three states, managed by an admin
316
- in the built-in **Permissions** page (`/permissions`, admin-only in the sidebar):
317
-
318
- | State | DAQ nodes | DCW (write) nodes | Visibility |
319
- | --- | --- | --- | --- |
320
- | **none** (default for regular users) | hidden | hidden | line data withheld server-side — invisible in Line Ops, DAQ center and the digital twin |
321
- | **read-only** | read | ✕ | line visible, values stream, no writes / dispatch / device binding |
322
- | **operate** | read | read + write | full access incl. setpoint writes, dispatch, binding |
323
-
324
- - `admin` / `editor` roles are unrestricted (operations roles).
325
- - Regular users **default to none** — they see no line data until granted.
326
- - Enforcement lives in the data plane: list endpoints filter by grant, write/dispatch
327
- endpoints return a human-readable 403, and Agent↔node bindings validate the line grant
328
- (DAQ needs read-only+, DCW needs operate).
329
- - Plugins get the same surface via `ctx.permissions` (`lineMode` / `visibleLineIds` /
330
- `listGrants` / `setGrants`) plus a `permissions:changed` lifecycle hook; the SDK REST
331
- client exposes `client.permissions.overview()` / `client.permissions.set(...)`.
332
-
333
- ### Execution modes
334
-
335
- Prefix the task description (or pick in the composer UI):
336
-
337
- | Mode | Semantics | Config |
338
- |---|---|---|
339
- | `goal` | lead decomposes → workers deliver → **lead judges satisfaction**; unmet → more subtasks; met → parent completes. | `goalCriteria` |
340
- | `loop` | replay the same task on a fixed interval. | `intervalMs` (default 60 000), `maxIterations` (default ∞) |
341
- | `pipeline` | ordered stages; stage N+1 consumes stage N's output. | `stages: [{name, description, assigneeId?}]` |
342
-
343
- ### The four entry points
344
-
345
- | Entry | Endpoint | Audience |
346
- |---|---|---|
347
- | **WS** | `/api/workshop/ws?channelId=…` | Dashboards / UI — AEP v1 envelopes, per-channel monotonic `seq`, 5 000-event ring, `lastSeq` resume, snapshot fallback. |
348
- | **MCP** | in-process server, ~20 tools | Agents (omp host tools) — management + job-face tools, channel-scoped. |
349
- | **A2A** | `POST /api/workshop/a2a/:agentId/rpc` | External agents — JSON-RPC 2.0, `AgentCard` at `/card`, `tasks/sendSubscribe` SSE. |
350
- | **REST** | `/api/workshop/**` | Humans / scripts — full management face. |
351
-
352
- ### Task state machine
353
-
354
- ```
355
- SUBMITTED ─▶ ASSIGNED ─▶ WORKING ─▶ WAITING ─▶ COMPLETED
356
- │ │ │ │
357
- └────────────┴───────────┴──▶ CANCELED / FAILED ─▶ (retry ≤ 3 or cancel)
358
- ```
359
-
360
- ---
361
-
362
- ## Verified end-to-end
363
-
364
- The repo ships live E2E that exercises the full loop against a running server — the numbers below are from an actual run:
365
-
366
- | Check | Result |
367
- |---|---|
368
- | Line start → recipe writes setpoint (180 °C) | ✅ |
369
- | Interlock: write 170 (<176) and 200 (>188) → **400 rejected** | ✅ |
370
- | Team deploy → goal dispatch (lead → omp worker) | ✅ t + 3 s |
371
- | Worker reads real history: **mean 168.05 °C, 96 samples, min/max/latest** | ✅ |
372
- | HITL approval → setpoint **180 → 182 °C** written & read back | ✅ |
373
- | Goal closes with structured summary | ✅ |
374
- | Batch tagging: samples carry product/recipe/run | ✅ |
375
-
376
- Reproduce: `node scripts/_dbg-full-feature-e2e.mjs` (against a running server).
377
-
378
- ---
379
-
380
- ## Project layout
381
-
382
- ```
383
- AgentWorkShop/
384
- ├── bin/ · cli/ # aw CLI — command registry · built-in commands · config engine
385
- ├── app/ # Nuxt 4 frontend (srcDir)
386
- │ ├── pages/ # / · /workshop · /town · /daq · /dcw · /monitor · /users · /tokens
387
- │ ├── components/workshop/ # timeline · lanes · task board · memory panel · 3D town
388
- │ └── stores/composables/ # Pinia + AEP client
389
- ├── server/
390
- │ ├── api/ # REST + WS + A2A + MCP routes
391
- │ ├── services/workshop/
392
- │ │ ├── runtime/ # manager · scheduler-loop · task-engine · memory · mailbox
393
- │ │ ├── agents/ # AgentInterface: mock · omp · codex · dsh · opencode · claude (+ industrial tools)
394
- │ │ ├── daq/ dcw/ # edge runtimes · drivers · bus · storage
395
- │ │ └── db/ # repos over node:sqlite
396
- │ ├── mcp/ # MCP server (tools)
397
- │ └── plugins/ # runtime assembly (singletons)
398
- ├── shared/
399
- │ └── config/ # schema.json (settings descriptors) + engine (merge/validate/persist) + mode/path resolver
400
- ├── config.yml # ⚙ single source of truth (factory defaults)
401
- ├── .AgentWorkShop/ # config root — prompts (versioned) + runtime overrides · data · logs · commands (git-ignored)
402
- ├── data/ # legacy pre-migration location (auto-migrated into the config root)
403
- └── scripts/ # launchers · home bootstrap · E2E · verification suites
404
- ```
405
-
406
- ## Tech stack
407
-
408
- | Layer | Tech |
409
- |---|---|
410
- | Framework | [Nuxt 4](https://nuxt.com) + Nitro (WebSocket) |
411
- | UI | Vue 3.5 · Pinia · Ant Design Vue · UnoCSS · Three.js · ECharts |
412
- | Language | TypeScript 5.7 across the stack; `shared/` used by both sides |
413
- | CLI | Node ESM CLI with a pluggable command registry (`bin/aw.mjs`) |
414
- | Persistence | `node:sqlite` (zero native deps) + FTS5 + optional `sqlite-vec`; TimescaleDB for time-series |
415
- | Validation | `zod` at every message boundary |
416
- | Interop | `@modelcontextprotocol/sdk` · A2A (JSON-RPC 2.0) · AEP v1 (in-house WS protocol) |
417
- | Field bus | `modbus-serial` · `node-opcua` · `mqtt` |
418
-
419
- ## Development
420
-
421
- ```bash
422
- pnpm dev # dev server (port from effective config)
423
- pnpm aw … # the CLI is available in-repo too: pnpm aw config list
424
- pnpm build && pnpm start
425
- pnpm typecheck
426
- pnpm lint
427
- node scripts/_dbg-full-feature-e2e.mjs # full-feature live E2E (server must be running)
428
- ```
429
-
430
- ## Roadmap
431
-
432
- | Capability | Status |
433
- |---|---|
434
- | Channel runtime, lead orchestration, 7-state task engine | Shipped |
435
- | Four entry points: WS (AEP v1) · MCP · A2A · REST | Shipped |
436
- | Persistent memory (FTS5 + optional vector hybrid) | Shipped |
437
- | Industrial stack: DAQ · DCW write control · lines/recipes/runs | Shipped |
438
- | Agent ↔ node binding + HITL approval + interlock | Shipped |
439
- | 3D digital-twin town · line operations UI · dashboards | Shipped |
440
- | Full-feature live E2E (agent reads/writes a real line, 23 checks) | Shipped |
441
- | Runtime configuration system: settings persistence · hot reload · settings UI | Shipped |
442
- | `aw` CLI: config · run · init · register · doctor | Shipped |
443
- | Multi-harness registry: omp · codex · dsh · opencode subprocess engines | Shipped |
444
- | Per-channel LLM provider/model selection from live harness catalogs | Shipped |
445
- | Configurable DAQ/TSDB cadences (sampling & query defaults + floors, live) | Shipped |
446
- | Claude Agent SDK adapter — full parity with `mock`/`omp` | In progress |
447
- | Production hardening: TLS, MQTT auth, OPC UA sign+encrypt defaults, structured audit log | Planned |
448
- | Edge deployment shape: standalone edge-agent + central broker | Planned |
449
- | Alarm outbound delivery (email/webhook) + ack workflow | Planned |
450
- | CI pipeline (typecheck + lint + e2e) | Planned |
451
- | License: PolyForm Noncommercial 1.0.0 (source-available, non-commercial) | Shipped |
452
-
453
- ## License
454
-
455
- AgentWorkShop is an independent project and is **not an official product of Anthropic** or any LLM vendor. It integrates with agent harnesses (e.g. `omp`) through their public interfaces.
456
-
457
- **AgentWorkShop is source-available software, licensed under the [PolyForm Noncommercial 1.0.0](./LICENSE).**
458
-
459
- - ✅ **Permitted** — personal study, research, hobby projects, teaching, and use by noncommercial organizations (charities, education, public research, government).
460
- - ❌ **Not permitted without prior written permission** — any **commercial use**: selling, paid services, integrating into commercial products, or production use serving a business. Commercial licenses are available from the copyright holder.
461
- - 📌 When you redistribute the software, you must pass through the `Required Notice` line and these terms.
462
-
463
- For commercial licensing, contact: [GitHub @kingdol666](https://github.com/kingdol666) · kingdol6080@gmail.com
464
-
465
- <div align="center">
466
-
467
- <a href="https://star-history.com/#kingdol666/AgentWorkShop&Date">
468
- <picture>
469
- <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date&theme=dark" />
470
- <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date" />
471
- <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date" width="80%" />
472
- </picture>
473
- </a>
474
-
475
- </div>
1
+ <div align="center">
2
+
3
+ <img src="https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/hero.png" alt="AgentWorkShop — Agents that run the production line" width="100%" />
4
+
5
+ # AgentWorkShop
6
+
7
+ **Where AI agent teams meet the production line.**
8
+
9
+ [![Nuxt 4](https://img.shields.io/badge/Nuxt-4-00DC82?logo=nuxt&logoColor=white)](https://nuxt.com)
10
+ [![Vue 3.5](https://img.shields.io/badge/Vue-3.5-42B883?logo=vuedotjs&logoColor=white)](https://vuejs.org)
11
+ [![TypeScript 5.7](https://img.shields.io/badge/TypeScript-5.7-3178C6?logo=typescript&logoColor=white)](https://www.typescriptlang.org)
12
+ [![Node ≥ 23.4](https://img.shields.io/badge/Node.js-%E2%89%A5%2023.4-3C873A?logo=nodedotjs&logoColor=white)](https://nodejs.org)
13
+ [![SQLite node:sqlite](https://img.shields.io/badge/SQLite-node:sqlite-003B57?logo=sqlite&logoColor=white)](https://nodejs.org/api/sqlite.html)
14
+ [![License: PolyForm Noncommercial](https://img.shields.io/badge/License-PolyForm_NC_1.0-8A2BE2?logo=openaccess&logoColor=white)](./LICENSE)
15
+
16
+ **[中文文档 →](./README-zh.md)** · **[Online Docs →](https://kingdol666.github.io/AgentWorkShop/)**
17
+
18
+ > 📖 Docs are bilingual — the [VitePress site](https://kingdol666.github.io/AgentWorkShop/) ships a language switcher (简体中文 / English) across guides, SDK and plugin references.
19
+
20
+ *A configuration-driven platform where **AI agent teams** and an **industrial digital twin** share one runtime — agents query real telemetry, issue supervisory setpoints through human-approved write control, and every event streams live to a 3D twin.*
21
+
22
+ </div>
23
+
24
+ > ⚠️ **Positioning: supervisory layer.** AgentWorkShop is a *supervisory* (SCADA-adjacent) layer for production-line management, digital twins, DAQ and agent orchestration, operating at **second-level soft real-time**. It is **not** a hard real-time controller: any time-critical loop (**< 10 ms**, interlocks, safety, servo) **must live inside the PLC**. Setpoints written here are advisory — plant-side logic may veto.
25
+
26
+ ---
27
+
28
+ ## What is this?
29
+
30
+ AgentWorkShop started as a **multi-agent software workshop** — channels of coding agents with a lead-agent scheduler, a 7-state task machine, persistent memory, and four interoperable entry points (WebSocket / MCP / A2A / REST).
31
+
32
+ It grew an **industrial half**: a full data-acquisition and write-control stack (Modbus TCP / OPC UA), production lines with recipes and batch runs, a 3D digital-twin town — and the bridge that makes it unique: **agents can be granted bound, permission-scoped access to real industrial nodes**, query their live telemetry with physical semantics attached, and drive write operations through an interlock → human-in-the-loop → readback pipeline.
33
+
34
+ The result: submit a goal like *"analyze the melt temperature trend and optimize the setpoint"* — and an agent team reads real sensor history, computes statistics, proposes a new setpoint, waits for your approval in the HITL panel, writes it to the PLC, verifies the readback, and reports the numbers back. **End to end, verified by automated E2E.**
35
+
36
+ <div align="center">
37
+ <img src="https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/town-demo.gif" alt="3D digital twin — live production line" width="86%" />
38
+ <br><sub><b>Live 3D twin.</b> Line equipment, device health, DAQ channels and trend analysis — all driven by real-time telemetry.</sub>
39
+ </div>
40
+
41
+ ---
42
+
43
+ ## Highlights
44
+
45
+ | Capability | Why it matters |
46
+ |---|---|
47
+ | **Agent teams, industrial scope** | Agents bind to DAQ/DCW nodes and see semantic cards — physical meaning, units, safe range, recipe window — never raw registers. |
48
+ | **Human-approved write control** | DCW writes flow through **safe-range ∩ recipe-window** interlock → optional **HITL approval** → PLC write → **readback verification** → signed write history. |
49
+ | **Read-write DCW channels (v0.7)** | Every control node also **reads its PLC value back** through the same calibration path it writes with: periodic + on-demand + agent reads surface **SET vs ACT** side by side in the DCW console, the twin panel (green ACT row) and a new `dcw_read` agent tool — passive observation, never blocked by write interlocks. |
50
+ | **Five field protocols** | Modbus TCP, Modbus RTU-over-TCP (serial gateway), OPC UA, MQTT and HTTP/REST — acquisition and write-control drivers with connection pools, classified error messages and per-driver connection tests. `mock` covers demos/CI; the driver registry accepts plugin-registered protocols. |
51
+ | **Per-channel LLM selection** | Each channel picks a **harness → provider → model (+effort)** triple from the harness's live catalog (e.g. `zhipu-coding-plan/glm-5.3-flash` on omp, `ustc/glm-5.3-flash` on dsh). Members inherit it unless they override — mixing harnesses in one team is a first-class setup, not a workaround. |
52
+ | **Harness availability check** | `GET /api/workshop/harnesses` probes each engine's CLI on PATH (`available` / `command` / `resolvedPath`). The UI disables not-installed engines, and dispatch is hard-checked at every entry point — you can no longer assign an agent to an engine that isn't there. |
53
+ | **HITL + control loop, protocol-real** | Agent dispatches pend for human approval, then write over Modbus/OPC UA with readback verification; the closed loop (control → sample → judge → keep/rollback) runs against real simulators — verified end to end with four harnesses in parallel. |
54
+ | **Recipe versioning & governance** | Parameter changes are versioned with attribution (user/agent/system + operator + reason). Roll back to any revision or the last-good batch — non-destructively. Agents save best parameters and roll back through tools; stale-node params are skipped and clearly marked. |
55
+ | **Agent self-audit tools** | `line_context`, `ops_log`, `recipe_log`, `recipe_versions`, `dcw_journal` — agents see exactly which line/product/recipe they control, who did what, and how every value changed. Operations are attributed to "Channel/Member" in the ops log, distinct from users and the system. |
56
+ | **Configurable cadences (v0.7.7)** | Sampling default & floor and Timescale query bucket default & floor are **live settings** (`daq.sampling.*`, `daq.query.*`): change them in `config.yml`, the Settings UI or via `aw config set` — hot-reloaded, clamped on node create/patch, and the injected agent tool descriptions always carry the current values. |
57
+ | **Fully config-driven runtime (v0.7)** | Every runtime knob (memory budgets, compaction, rollback guardrails, retention, backups, log level…) is declared once in the settings descriptor registry with precedence **config.yml < runtime-settings < env** — legacy env names kept as aliases, no hardcoded defaults left in code. Project-level `.AgentWorkShop` wins; `~/.AgentWorkShop` is the user-level fallback (auto-seeded on install). |
58
+ | **Multi-modal DAQ frame pipeline (v0.6)** | Multi-point profiles (thickness/scanner) and CCD image frames are processed through template sink pipelines before storage: vectors & metadata into Timescale (`daq_frames`), pixels into object storage (MinIO, auto disk fallback); derived-metric thresholds ride the existing alarm chain. |
59
+ | **Plugin extension API (v0.6)** | `ctx.daq.registerDriver / registerProcessor / registerTemplate` for custom acquisition and sink algorithms (drop into `plugins/`); `ctx.omp.registerTool` for custom agent tools, hot-injected into every running session on registry change. |
60
+ | **Line operations** | Lines → products → recipes → batch runs. Recipe windows gate acquisition and interlock writes; every sample is tagged `product/recipe/run` for per-batch isolation. |
61
+ | **Lead-agent orchestration** | Each channel has one lead: decomposes goals, dispatches to idle workers, reassigns failures, judges goal satisfaction. LLM decisions with a deterministic rule-engine fallback — the system never stalls. |
62
+ | **Three execution modes** | `goal` (satisfaction judging) · `loop` (fixed-interval replay) · `pipeline` (ordered stages). 7-state task machine with progress, artifacts and full history. |
63
+ | **Four entry points** | One manager behind every door: **WS** (AEP v1 event stream with seq-resume), **MCP** (in-process tools), **A2A** (JSON-RPC 2.0 + AgentCard), **REST**. |
64
+ | **Persistent memory** | Private + channel-shared domains; FTS5 with CJK segmentation, optional vector hybrid recall, token-budgeted injection; session compaction summaries auto-archived, team chronicle and idle reflections keep accumulating (v0.6). |
65
+ | **Harness-agnostic** | One `AgentInterface` — `mock` (in-process), `omp` / `codex` / `dsh` / `opencode` (real engine subprocesses over RPC/ACP/JSON-RPC) and a Claude SDK adapter. The platform never knows which one runs. |
66
+ | **3D digital twin** | Three.js town: place line equipment and channel territories, watch device health, alarms and live values — driven by the same event bus. |
67
+
68
+ ---
69
+
70
+ ## Interface
71
+
72
+ <div align="center">
73
+
74
+ | Agent Workbench | Line Operations |
75
+ |:---:|:---:|
76
+ | ![Agent workbench](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/workshop.png) | ![Line operations](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/dcw.png) |
77
+
78
+ | DAQ Center | Digital Twin Town |
79
+ |:---:|:---:|
80
+ | ![DAQ center](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/daq.png) | ![Digital twin town](https://raw.githubusercontent.com/kingdol666/AgentWorkShop/main/docs/readme-assets/town.png) |
81
+
82
+ </div>
83
+
84
+ ---
85
+
86
+ ## Architecture
87
+
88
+ ```mermaid
89
+ flowchart TB
90
+ subgraph FE["Frontend — Nuxt 4 / Vue 3"]
91
+ UI["Workshop UI · 3D Twin · Dashboards"]
92
+ WS["AEP client — seq resume"]
93
+ end
94
+ subgraph SRV["Server — Nitro / h3"]
95
+ REST["REST /api/workshop/**"]
96
+ HUB["WS Hub — AEP v1"]
97
+ A2A["A2A JSON-RPC"]
98
+ MCP["MCP Server"]
99
+ subgraph RT["Runtime"]
100
+ MGR["AgentChannelManager"]
101
+ SCH["SchedulerLoop — lead supervision"]
102
+ TE["TaskEngine — 7-state machine"]
103
+ AR["AgentRuntime × N"]
104
+ MEM["AgentMemory — FTS5 + vector"]
105
+ BUS["ChannelBus — per-channel seq + ring"]
106
+ end
107
+ subgraph IND["Industrial"]
108
+ DAQ["DAQ gateway — per-node edge runtimes"]
109
+ DCW["DCW gateway — write control"]
110
+ BR["Bus — inproc / MQTT"]
111
+ TSDB["TSDB — SQLite / Timescale"]
112
+ end
113
+ subgraph HB["Harness adapters"]
114
+ MOCK["mock"]
115
+ OMP["omp — RPC subprocess"]
116
+ CDX["codex — app-server"]
117
+ DSH["dsh — ACP"]
118
+ OC["opencode — serve"]
119
+ CLD["claude — SDK"]
120
+ end
121
+ DB[("SQLite — channels · agents · tasks
122
+ messages · memories (FTS5) · events")]
123
+ end
124
+ UI <--> WS
125
+ WS --> BUS
126
+ REST & A2A & MCP --> MGR
127
+ MGR --> SCH & TE & AR
128
+ AR --> MEM
129
+ AR --> MOCK & OMP & CDX & DSH & OC & CLD
130
+ MGR & TE & MEM & BUS --> DB
131
+ DAQ <--> BR --> TSDB
132
+ DCW --> BR
133
+ DAQ & DCW --> BUS
134
+ ```
135
+
136
+ **The agent × machine bridge** (the part worth reading the source for):
137
+
138
+ ```
139
+ agent ──binds to──▶ node (daq: auto / dcw: manual)
140
+ │ │
141
+ │ my_industrial_nodes ◀── semantic card: meaning · unit · safe range · recipe window
142
+ │ daq_query ◀── TSDB history, stats + physical semantics
143
+ │ dcw_control ──▶ interlock (safe range ∩ recipe window)
144
+ │ ──▶ HITL approval (manual mode, 180 s timeout)
145
+ │ ──▶ PLC write → readback check → ACK + write history
146
+ ◀── result text with numbers the agent can cite
147
+ ```
148
+
149
+ ---
150
+
151
+ ## Quick start
152
+
153
+ ### Prerequisites
154
+
155
+ ```bash
156
+ node -v # ≥ 23.4.0 (needs built-in node:sqlite)
157
+ ```
158
+
159
+ > The real-agent harnesses require their CLI on PATH — `omp`, `codex`, `opencode` or `dsh` (any subset; each channel can mix harnesses). The `mock` harness works out of the box for demos and CI. Optional DAQ infrastructure (MQTT broker + TimescaleDB) auto-starts via Docker when reachable (`docker compose up -d`).
160
+
161
+ ### Option A — install from npm (recommended)
162
+
163
+ ```bash
164
+ npm install -g agentworkshop # → `aw` / `agentworkshop` on PATH
165
+ aw start # first run builds once (~2-3 min) → http://localhost:3001
166
+ ```
167
+
168
+ That's it — no checkout, no build tools. On first launch everything initializes into the config root **`~/.AgentWorkShop`**: the default `config.yml`, a generated `.env` holding a random session secret, `runtime-settings.json`, a docker-compose seed and an empty `data/` directory. All runtime data (SQLite, JSON repos, backups, logs) lives there too — config and data stay with the install, not the working directory.
169
+
170
+ Prefer a one-off run without installing?
171
+
172
+ ```bash
173
+ npx agentworkshop start # fetch + run, nothing persisted globally
174
+ ```
175
+
176
+ ### Option B — from source
177
+
178
+ ```bash
179
+ git clone https://github.com/kingdol666/AgentWorkShop.git && cd AgentWorkShop
180
+ pnpm install
181
+ pnpm dev # → http://localhost:3000 (port from config.yml)
182
+ ```
183
+
184
+ Production from source:
185
+
186
+ ```bash
187
+ pnpm build # nuxt build → .output/
188
+ pnpm start # port from config.yml → server.prod.port
189
+ ```
190
+
191
+ > In a source checkout the config root is the project's **`.AgentWorkShop/`** folder (runtime overrides, data, project-level commands), while `config.yml` / `.env` stay at the checkout root, version-controlled as the factory defaults.
192
+
193
+ ### Updating
194
+
195
+ ```bash
196
+ aw update # check + self-update the global install
197
+ aw update --check # only report; nothing is installed
198
+ npm install -g agentworkshop@latest # manual equivalent
199
+ ```
200
+
201
+ Releases follow semver. Every `aw start` verifies the config root and migrates it in place when a new version changes the layout — your data survives upgrades.
202
+
203
+ ### Your first agent × line session (~2 minutes)
204
+
205
+ 1. **Sign in** — register in the sidebar (or `POST /api/users/register`).
206
+ 2. **Build a line** — `Line Operations` → create a line, add DAQ nodes (e.g. `daq-temp-tc`) and control nodes (e.g. `dcw-temp-sp`), create a product + recipe, hit **Start**. Live values start flowing.
207
+ 3. **Create a team** — `Agent Workshop` → pick a lead + workers, **deploy** into a channel.
208
+ 4. **Bind nodes** — open the agent's detail panel → bind the DAQ node (*auto*) and the control node (*manual* = needs your approval).
209
+ 5. **Submit the goal** — *"Analyze the last 5 minutes of melt temperature; if deviation from 182 °C exceeds 1 °C, correct the setpoint (wait for my approval)."*
210
+ 6. **Approve** — the agent reads real history, computes the mean, requests the write → approve in the HITL panel → watch the setpoint change and the goal close with a numeric report.
211
+
212
+ ---
213
+
214
+ ## Configuration & CLI — config-driven by design
215
+
216
+ One runtime, one source of truth. **`config.yml`** declares defaults; **`runtime-settings.json`** inside the config root carries runtime overrides; environment variables and CLI flags sit on top. Every editable key is described once in `shared/config/schema.json` (type, range, enum, live-vs-restart) and surfaced through the same descriptors in **both the UI and the CLI**.
217
+
218
+ ```
219
+ config.yml (defaults) < .AgentWorkShop/runtime-settings.json (runtime) < env vars / CLI flags
220
+ ```
221
+
222
+ The config root is **`~/.AgentWorkShop`** for a global install (`npm i -g`) — wherever you run `aw` from — and **`<repo>/.AgentWorkShop`** in a source checkout (with `config.yml` / `.env` staying at the checkout root as version-controlled factory defaults). `AW_HOME` redirects it; `AW_MODE=home` forces the global shape.
223
+
224
+ ### Live settings, persisted, hot-reloaded
225
+
226
+ - The **Settings → Runtime config** tab renders every editable key from the descriptors — change server ports, theme, API timeouts, locale or the approval gate, hit save.
227
+ - `live` keys apply instantly (theme, title, timeouts, approval gate, DAQ sampling cadences, TSDB query buckets…) over a server-sent event stream — no reload, no restart.
228
+ - `restart` keys (ports, hosts) persist to disk and take effect on the next launch of the matching mode (`aw dev` / `aw start`).
229
+ - One channel for every writer: the UI, the CLI and the server's file watcher all converge on the same settings file, so a change made anywhere shows up everywhere.
230
+
231
+ Example — retune the acquisition and query cadences live:
232
+
233
+ ```bash
234
+ aw config set daq.sampling.defaultIntervalMs 2000 # new nodes sample every 2 s
235
+ aw config set daq.sampling.minIntervalMs 500 # per-node floor (create/patch clamp)
236
+ aw config set daq.query.defaultBucketMs 3000 # TSDB reads default to a 3 s bucket
237
+ aw config set daq.query.minBucketMs 500 # query floor (samples/line query/agent tool)
238
+ ```
239
+
240
+ Agent tool descriptions are re-rendered with the current values on every injection, so an LLM always sees the floor and default that will actually apply to its `daq_query` calls.
241
+
242
+ ### The `aw` CLI
243
+
244
+ | Command | What it does |
245
+ |---|---|
246
+ | `aw start · aw dev · aw build` | Production server / dev server / build — ports from the effective config; first `start` builds once |
247
+ | `aw config list · get · set · unset · reset` | Read & write runtime settings (validated against the schema, atomic writes) |
248
+ | `aw home` | Inspect / initialize the config root `.AgentWorkShop` |
249
+ | `aw init <dir>` | Scaffold a runnable project (full config system + CLI included) |
250
+ | `aw register <path\|url\|npm:pkg>` | Register a new command — project-local or `--global` |
251
+ | `aw update` | Check npm for the latest release and self-update the global install |
252
+ | `aw doctor` | Environment + project health check (node, config, ports, keys) |
253
+ | `aw status` | Live overview: mode, config sources, running server, command table |
254
+ | `aw tui` | Terminal workbench: channel/agent management, task submission, live monitor pane, HITL answering (see `tui/README.md`) |
255
+
256
+ Global flags: `--help/-h` · `--version/-v` · `--json` (machine-readable) · `--root <dir>` · `--debug`.
257
+
258
+ ### Command registration
259
+
260
+ Commands are plain modules exporting `{ meta, run }`. Drop one into a scanned directory and it's live on the next invocation — no registry bookkeeping, convention over configuration:
261
+
262
+ | Scope (highest wins) | Directory |
263
+ |---|---|
264
+ | project | `<root>/.AgentWorkShop/commands/` |
265
+ | user | `~/.AgentWorkShop/commands/` |
266
+ | built-in | packaged with the CLI (`cli/commands/`) |
267
+
268
+ `aw register <file|url|npm:pkg>` copies a command into the right scope (`--global` for user scope); `aw help` lists everything that's registered.
269
+
270
+ ```js
271
+ // ~/.AgentWorkShop/commands/hello.mjs
272
+ export const meta = { name: 'hello', group: 'Custom', summary: 'Say hi', usage: 'aw hello [--name <n>]' }
273
+ export async function run(argv, ctx) {
274
+ console.log(`Hi ${argv.flags.name ?? 'AW'} — mode: ${ctx.mode}`)
275
+ }
276
+ ```
277
+
278
+ ---
279
+
280
+ ## The industrial stack in detail
281
+
282
+ ### Data acquisition (DAQ)
283
+
284
+ - **Five protocol drivers**: Modbus TCP, Modbus RTU-over-TCP (serial gateway), OPC UA, MQTT, HTTP/REST — connection pools, classified error messages, per-driver connection tests; the driver registry accepts plugin-registered protocols.
285
+ - **Per-node edge runtimes**: independent sampling cadence, publish cadence, in-flight mutex per node — one slow driver never blocks its neighbors. Sampling and query defaults/floors are driven by the live `daq.sampling.*` / `daq.query.*` settings.
286
+ - **Pipeline**: driver → queue (in-process or MQTT, offline buffer on disconnect) → consumer with out-of-order defense → three-way fan-out: WS live push (gated), TSDB batch write, device-twin writeback.
287
+ - **Robustness**: TSDB single-in-flight writes with bounded retries, buffer backpressure with drop counters, real loss metrics exposed on `daq.controller` frames.
288
+ - **Alarms**: recipe-scoped monitoring windows with **2 % hysteresis + 3-tick debounce**; alarm/offline transitions are instant (safety first).
289
+
290
+ ### Write control (DCW)
291
+
292
+ - Engineering-unit writes: `linear` calibration (scale/offset) PLC↔physical, **readback verification** with deadband tolerance, ACK states and write history.
293
+ - **Interlock**: with a line running, the active recipe's parameter window *replaces* the node's global safe range for that node.
294
+ - **HITL**: `manual`-mode bindings suspend the write for user approval (deduped per agent+node; re-validation at approval time — permission is re-checked when you click approve).
295
+
296
+ ### Recipe & batch
297
+
298
+ `Line → Product → Recipe → Run`. Starting a run applies recipe params node-by-node (each write verified), gates acquisition per line, and tags every sample with `line/product/recipe/run` — per-product data isolation with five-dimension queries (line × product × recipe × time × node).
299
+
300
+ ---
301
+
302
+ ## Usage
303
+
304
+ ### Authentication
305
+
306
+ Email + password login issues a **bearer token** (multiple tokens per user, individually revocable).
307
+
308
+ ```bash
309
+ # register
310
+ curl -X POST http://localhost:3000/api/users/register \
311
+ -H 'content-type: application/json' \
312
+ -d '{"email":"you@example.com","password":"secret","name":"you"}'
313
+
314
+ # every workshop call
315
+ curl http://localhost:3000/api/workshop/channels \
316
+ -H 'authorization: Bearer <token>'
317
+ ```
318
+
319
+ ### Line-level permissions
320
+
321
+ Industrial data is gated **per production line** with three states, managed by an admin
322
+ in the built-in **Permissions** page (`/permissions`, admin-only in the sidebar):
323
+
324
+ | State | DAQ nodes | DCW (write) nodes | Visibility |
325
+ | --- | --- | --- | --- |
326
+ | **none** (default for regular users) | hidden | hidden | line data withheld server-side — invisible in Line Ops, DAQ center and the digital twin |
327
+ | **read-only** | read | ✕ | line visible, values stream, no writes / dispatch / device binding |
328
+ | **operate** | read | read + write | full access incl. setpoint writes, dispatch, binding |
329
+
330
+ - `admin` / `editor` roles are unrestricted (operations roles).
331
+ - Regular users **default to none** — they see no line data until granted.
332
+ - Enforcement lives in the data plane: list endpoints filter by grant, write/dispatch
333
+ endpoints return a human-readable 403, and Agent↔node bindings validate the line grant
334
+ (DAQ needs read-only+, DCW needs operate).
335
+ - Plugins get the same surface via `ctx.permissions` (`lineMode` / `visibleLineIds` /
336
+ `listGrants` / `setGrants`) plus a `permissions:changed` lifecycle hook; the SDK REST
337
+ client exposes `client.permissions.overview()` / `client.permissions.set(...)`.
338
+
339
+ ### Execution modes
340
+
341
+ Prefix the task description (or pick in the composer UI):
342
+
343
+ | Mode | Semantics | Config |
344
+ |---|---|---|
345
+ | `goal` | lead decomposes → workers deliver → **lead judges satisfaction**; unmet → more subtasks; met → parent completes. | `goalCriteria` |
346
+ | `loop` | replay the same task on a fixed interval. | `intervalMs` (default 60 000), `maxIterations` (default ∞) |
347
+ | `pipeline` | ordered stages; stage N+1 consumes stage N's output. | `stages: [{name, description, assigneeId?}]` |
348
+
349
+ ### The four entry points
350
+
351
+ | Entry | Endpoint | Audience |
352
+ |---|---|---|
353
+ | **WS** | `/api/workshop/ws?channelId=…` | Dashboards / UI — AEP v1 envelopes, per-channel monotonic `seq`, 5 000-event ring, `lastSeq` resume, snapshot fallback. |
354
+ | **MCP** | in-process server, ~20 tools | Agents (omp host tools) — management + job-face tools, channel-scoped. |
355
+ | **A2A** | `POST /api/workshop/a2a/:agentId/rpc` | External agents — JSON-RPC 2.0, `AgentCard` at `/card`, `tasks/sendSubscribe` SSE. |
356
+ | **REST** | `/api/workshop/**` | Humans / scripts — full management face. |
357
+
358
+ ### Task state machine
359
+
360
+ ```
361
+ SUBMITTED ─▶ ASSIGNED ─▶ WORKING ─▶ WAITING ─▶ COMPLETED
362
+ │ │ │ │
363
+ └────────────┴───────────┴──▶ CANCELED / FAILED ─▶ (retry ≤ 3 or cancel)
364
+ ```
365
+
366
+ ---
367
+
368
+ ## Verified end-to-end
369
+
370
+ The repo ships live E2E suites that run against a production instance over **simulated real
371
+ plant protocols** (Modbus TCP/RTU, OPC UA, MQTT, HTTP + MQTT/Timescale pipelines). Latest
372
+ acceptance run — **156 assertions, 0 failures** ([full report](./docs/audit/e2e-2026-09-07.md)):
373
+
374
+ | Suite | Checks | Covers |
375
+ |---|---|---|
376
+ | Five-protocol live line | 37 ✅ | protocol connectivity, DAQ sampling (5 protocols) into Timescale, DCW dispatch + readback per protocol, agent closed loop, HITL approval with a real OPC UA write, recipe update/rollback, param-ledger rollback |
377
+ | Multi-harness parallel | 21 ✅ | omp closed loop · codex real register write · dsh real acquisition · opencode recipe write+rollback — each engine COMPLETED on a running line |
378
+ | Permissions / audit-neg / harness availability / stale-node guard / recipe versions | 98 ✅ | line grants, WS auth, engine probing, three-state stale params, versioned history with attribution |
379
+
380
+ Reproduce: `node scripts/_dbg-live-line-e2e.mjs` · `node scripts/_dbg-multiharness-live-e2e.mjs` (against a running server).
381
+
382
+ ---
383
+
384
+ ## Project layout
385
+
386
+ ```
387
+ AgentWorkShop/
388
+ ├── bin/ · cli/ # aw CLI — command registry · built-in commands · config engine
389
+ ├── app/ # Nuxt 4 frontend (srcDir)
390
+ │ ├── pages/ # / · /workshop · /town · /daq · /dcw · /monitor · /users · /tokens
391
+ │ ├── components/workshop/ # timeline · lanes · task board · memory panel · 3D town
392
+ │ └── stores/composables/ # Pinia + AEP client
393
+ ├── server/
394
+ │ ├── api/ # REST + WS + A2A + MCP routes
395
+ │ ├── services/workshop/
396
+ │ │ ├── runtime/ # manager · scheduler-loop · task-engine · memory · mailbox
397
+ │ │ ├── agents/ # AgentInterface: mock · omp · codex · dsh · opencode · claude (+ industrial tools)
398
+ │ │ ├── daq/ dcw/ # edge runtimes · drivers · bus · storage
399
+ │ │ └── db/ # repos over node:sqlite
400
+ │ ├── mcp/ # MCP server (tools)
401
+ │ └── plugins/ # runtime assembly (singletons)
402
+ ├── shared/
403
+ │ └── config/ # schema.json (settings descriptors) + engine (merge/validate/persist) + mode/path resolver
404
+ ├── config.yml # ⚙ single source of truth (factory defaults)
405
+ ├── .AgentWorkShop/ # config root — prompts (versioned) + runtime overrides · data · logs · commands (git-ignored)
406
+ ├── data/ # legacy pre-migration location (auto-migrated into the config root)
407
+ └── scripts/ # launchers · home bootstrap · E2E · verification suites
408
+ ```
409
+
410
+ ## Tech stack
411
+
412
+ | Layer | Tech |
413
+ |---|---|
414
+ | Framework | [Nuxt 4](https://nuxt.com) + Nitro (WebSocket) |
415
+ | UI | Vue 3.5 · Pinia · Ant Design Vue · UnoCSS · Three.js · ECharts |
416
+ | Language | TypeScript 5.7 across the stack; `shared/` used by both sides |
417
+ | CLI | Node ESM CLI with a pluggable command registry (`bin/aw.mjs`) |
418
+ | Persistence | `node:sqlite` (zero native deps) + FTS5 + optional `sqlite-vec`; TimescaleDB for time-series |
419
+ | Validation | `zod` at every message boundary |
420
+ | Interop | `@modelcontextprotocol/sdk` · A2A (JSON-RPC 2.0) · AEP v1 (in-house WS protocol) |
421
+ | Field bus | `modbus-serial` · `node-opcua` · `mqtt` |
422
+
423
+ ## Development
424
+
425
+ ```bash
426
+ pnpm dev # dev server (port from effective config)
427
+ pnpm aw … # the CLI is available in-repo too: pnpm aw config list
428
+ pnpm build && pnpm start
429
+ pnpm typecheck
430
+ pnpm lint
431
+ node scripts/_dbg-full-feature-e2e.mjs # full-feature live E2E (server must be running)
432
+ ```
433
+
434
+ ## Roadmap
435
+
436
+ | Capability | Status |
437
+ |---|---|
438
+ | Channel runtime, lead orchestration, 7-state task engine | Shipped |
439
+ | Four entry points: WS (AEP v1) · MCP · A2A · REST | Shipped |
440
+ | Persistent memory (FTS5 + optional vector hybrid) | Shipped |
441
+ | Industrial stack: DAQ · DCW write control · lines/recipes/runs | Shipped |
442
+ | Agent ↔ node binding + HITL approval + interlock | Shipped |
443
+ | 3D digital-twin town · line operations UI · dashboards | Shipped |
444
+ | Full-feature live E2E (agent reads/writes a real line, 23 checks) | Shipped |
445
+ | Runtime configuration system: settings persistence · hot reload · settings UI | Shipped |
446
+ | `aw` CLI: config · run · init · register · doctor | Shipped |
447
+ | Multi-harness registry: omp · codex · dsh · opencode subprocess engines | Shipped |
448
+ | Five field protocols: Modbus RTU-over-TCP · MQTT · HTTP (acquisition + write control) | Shipped |
449
+ | Harness availability probing + dispatch-time engine checks (UI disable + 409) | Shipped |
450
+ | Recipe versioning with attribution + non-destructive rollback (UI + agent tools) | Shipped |
451
+ | Agent self-audit: line_context / ops_log / recipe_log / recipe_versions / dcw_journal | Shipped |
452
+ | Multi-harness parallel live E2E on a real protocol line (four engines, one line) | Shipped |
453
+ | HITL approval flow verified over real OPC UA writes | Shipped |
454
+ | Bilingual docs (简体中文 / English) with VitePress language switcher | Shipped |
455
+ | Per-channel LLM provider/model selection from live harness catalogs | Shipped |
456
+ | Configurable DAQ/TSDB cadences (sampling & query defaults + floors, live) | Shipped |
457
+ | Claude Agent SDK adapter — full parity with `mock`/`omp` | In progress |
458
+ | Production hardening: TLS, MQTT auth, OPC UA sign+encrypt defaults, structured audit log | Planned |
459
+ | Edge deployment shape: standalone edge-agent + central broker | Planned |
460
+ | Alarm outbound delivery (email/webhook) + ack workflow | Planned |
461
+ | CI pipeline (typecheck + lint + e2e) | Planned |
462
+ | License: PolyForm Noncommercial 1.0.0 (source-available, non-commercial) | Shipped |
463
+
464
+ ## License
465
+
466
+ AgentWorkShop is an independent project and is **not an official product of Anthropic** or any LLM vendor. It integrates with agent harnesses (e.g. `omp`) through their public interfaces.
467
+
468
+ **AgentWorkShop is source-available software, licensed under the [PolyForm Noncommercial 1.0.0](./LICENSE).**
469
+
470
+ - ✅ **Permitted** — personal study, research, hobby projects, teaching, and use by noncommercial organizations (charities, education, public research, government).
471
+ - ❌ **Not permitted without prior written permission** — any **commercial use**: selling, paid services, integrating into commercial products, or production use serving a business. Commercial licenses are available from the copyright holder.
472
+ - 📌 When you redistribute the software, you must pass through the `Required Notice` line and these terms.
473
+
474
+ For commercial licensing, contact: [GitHub @kingdol666](https://github.com/kingdol666) · kingdol6080@gmail.com
475
+
476
+ <div align="center">
477
+
478
+ <a href="https://star-history.com/#kingdol666/AgentWorkShop&Date">
479
+ <picture>
480
+ <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date&theme=dark" />
481
+ <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date" />
482
+ <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=kingdol666/AgentWorkShop&type=Date" width="80%" />
483
+ </picture>
484
+ </a>
485
+
486
+ </div>