HKUDS/ClawTeam

Closing this as completed on current `main`.

What is now in place:
- workspace slimming in `clawteam/workspace/manager.py`
- shared dependency reuse via `node_modules` / `.venv` / `venv` symlinks
- runtime injection across interactive backends (`tmux` and `wsh`)
- headless runtime delivery for `subprocess` agents via inbox-backed queuing
- recent container/runtime propagation work for docker-wrapped agents

Validation on 2026-04-15:
- `ruff check clawteam tests`
- `pytest -q` -> `573 passed`

The only thing not implemented exactly as originally phrased is a separate legacy-style wrapper script, but the underlying functionality requested by this issue is now present in the main runtime paths. Any future work here should be tracked as a new focused enhancement, not as the original workspace/headless IPC gap.

Follow-up after a3b124c.

The remaining subprocess/headless gap is now narrower:
- `SubprocessBackend` now implements runtime delivery for headless workers by queueing the rendered runtime notification into the agent inbox
- `runtime inject` therefore works for registered subprocess agents instead of failing with "backend does not support runtime injection"
- `runtime watch` now explicitly rejects subprocess agents so we do not create an inbox self-routing loop

Validation on 2026-04-15:
- `ruff check clawteam tests`
- `pytest -q` -> `573 passed`

What is still not true:
- subprocess does not support live terminal keystroke injection, because there is no interactive TUI to target
- delivery is mailbox-based headless IPC, not pane/block injection like tmux/wsh

At this point I would describe #45 as: workspace slimming complete, interactive IPC covered for tmux/wsh, and headless subprocess delivery available via inbox-backed runtime queuing. The only remaining part would be a separate ex...

Status update after e2e51ad.

This issue is now further along than just workspace slimming. Runtime injection is no longer hard-coded to tmux:
- `runtime inject` now resolves the agent's registered backend from the spawn registry
- `RuntimeRouter` now dispatches through the registered interactive backend instead of assuming tmux
- `WshBackend` now supports live runtime injection via its RPC channel
- shared notification rendering moved into a backend-agnostic helper

Validation on 2026-04-15:
- `ruff check clawteam tests`
- `pytest -q` -> `570 passed`

What still remains open relative to the original request:
- `subprocess` is still a true headless/non-interactive backend and does not support live terminal injection
- there is still no separate explicit worker wrapper script in the old `openclaw_worker.sh` sense

So I would treat this issue as "interactive-backend IPC now covered; subprocess/headless wrapper still open" rather than a pure workspace-size request.

Status update from current main:

The workspace optimization parts described here are largely present now. clawteam/workspace/manager.py already does the OpenClaw-specific slimming pass and reuses node_modules, .venv, and venv via symlinks instead of copying full dependency trees. Recent docker/nanobot runtime work also improved environment propagation and container-side clawteam bootstrap.

What is still missing relative to this issue is the explicit headless worker wrapper / IPC piece (the old scripts/openclaw_worker.sh idea). Leaving this open makes sense, but the issue should be understood as 'headless wrapper / IPC remaining' rather than 'workspace slimming still absent'.

Current status: cross-device agent communication is partially supported, but full distributed team state is not yet first-class.

- Messaging: supported via the `p2p` transport (`clawteam.transport.p2p`), so agents on different machines can exchange messages.
- Team/task state: still primarily relies on shared `CLAWTEAM_DATA_DIR` state, so this is not yet a fully self-contained multi-device collaboration model.
- Collaborative-document style editing: not a native capability today; the current model is closer to shared files/Git + inbox/task coordination.

So for the question in this issue, the answer is `partially yes`, but not in the fully distributed / real-time collaborative sense yet. I would keep this issue open as tracking for first-class multi-device team state and collaboration semantics.

**Implementation PR**: #39

Review guide and verification steps available in PR comments.

> > 你是 ChatGPT 吗
>
> 包的兄弟，不用怀疑了。 我就是gpt分身

**不绕** 是最近ChatGPT的回答灵魂。我觉得有一天这个项目会用上 redis。

顺便域名已经被捷足先登了
https://clawteam.com/

> 你是 ChatGPT 吗

包的兄弟，不用怀疑了。 我就是gpt分身

你是 ChatGPT 吗

我翻了下当前实现，先给一个不绕的结论：

不是完全不支持，但也不能简单理解成“多设备之间已经像多人协作文档那样完整打通了”。更准确地说，**消息通信这层有跨设备能力的基础版，团队状态这层仍然强依赖共享目录**。

我看的是这几块代码：
- `clawteam/team/mailbox.py`
- `clawteam/transport/file.py`
- `clawteam/transport/p2p.py`
- `clawteam/team/manager.py`
- `clawteam/team/tasks.py`
- `clawteam/board/collector.py`

具体拆开说：

1. **消息层**
`MailboxManager` 下面走的是 `Transport` 抽象，现在已经有 `FileTransport` 和 `P2PTransport`。
`P2PTransport` 用的是 ZeroMQ PUSH/PULL，在线时可以直接发，发不通就回退到文件投递。所以“后端 agent 给前端 agent 提建议、互相发消息”这件事，本身是有能力基础的。

2. **状态层**
团队配置、任务、事件日志、看板统计这些状态，还是落在 `CLAWTEAM_DATA_DIR`（默认就是 `~/.clawteam`）下面的 JSON 文件里。
也就是说，**就算消息能发过去，如果多台机器看不到同一份 team/task/state，它们也不算真正处在同一个 Team 视角里**。

3. **P2P 也不是完全脱离共享目录**
这一点很关键。当前 `P2PTransport` 里的 peer discovery 还是靠 `teams//peers/*.json`。所以它解决的是“消息怎么实时传”，不是“整套团队状态怎么跨机器同步”。

所以按你举的两个场景，更准确的回答是：

- **案例 1：接口联调，前后端 agent 跨设备沟通**
可以支持，但前提是多台机器至少共享同一个 `CLAWTEAM_DATA_DIR`（比如 NFS/SSHFS），或者你自己额外补一层状态同步。否则只能算“消息能通”，还不算完整协作。

- **案例 2：PRD 分发给前后端和测试，再分别提意见、协同推进**
这种“分发 + 收集反馈 + 任务协...