flavor-code 1.2.10 → 1.2.11
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 +38 -49
- package/README.zh-CN.md +39 -48
- package/dist/{app-USAFQVSX.js → app-MXWPZBEU.js} +38 -7
- package/dist/{chunk-G32MCAZA.js → chunk-EY6KE7L2.js} +1 -1
- package/dist/{chunk-WGYNTR4Q.js → chunk-OT5XIN6G.js} +3205 -610
- package/dist/cli.js +62 -23
- package/dist/desktop/main.js +2189 -393
- package/dist/desktop-renderer/assets/index-sgEm4kjf.js +151 -0
- package/dist/desktop-renderer/index.html +1 -1
- package/dist/pals/address.d.ts +6 -0
- package/dist/pals/auth.d.ts +7 -0
- package/dist/pals/broker-cli.d.ts +18 -0
- package/dist/pals/broker.d.ts +156 -0
- package/dist/pals/client.d.ts +109 -0
- package/dist/pals/lifecycle.d.ts +13 -0
- package/dist/pals/prompt.d.ts +23 -0
- package/dist/pals/protocol.d.ts +526 -0
- package/dist/pals/tools.d.ts +44 -0
- package/dist/production.d.ts +12 -0
- package/dist/sdk/index.js +2 -2
- package/dist/tools/types.d.ts +2 -0
- package/dist/ui/commands.d.ts +35 -3
- package/dist/ui/session.d.ts +47 -1
- package/dist/ui/transcript.d.ts +6 -0
- package/package.json +1 -1
- package/dist/desktop-renderer/assets/index-BVxdOZFW.js +0 -151
package/README.md
CHANGED
|
@@ -35,50 +35,9 @@ Flavor Code connects to OpenAI, Anthropic, or compatible services and works with
|
|
|
35
35
|
| 🧭 | **Controlled progress on complex tasks** | Task plans, sub-agents, steering, follow-ups, `/loop`, and `/goal` |
|
|
36
36
|
| ⏪ | **Traceable, resumable results** | Full timeline, checkpoints, rewind, traces, diffs, and failure audits |
|
|
37
37
|
| 🧠 | **Local long-term context** | Memory, Skills, plugins, and project guides stored on your machine |
|
|
38
|
-
| 🎨 | **
|
|
38
|
+
| 🎨 | **E2E requirement-to-delivery** | From a rough requirement or a design export to a delivered product: PRD, interactive prototype, visual implementation, API integration, autonomous acceptance, and scored delivery (Electron only) |
|
|
39
39
|
| 🛡️ | **Clear permission boundaries** | Independent control over read, write, Shell, network, and destructive actions; Docker supported |
|
|
40
40
|
|
|
41
|
-
## 1.2.10 D2C Acceptance & Delivery
|
|
42
|
-
|
|
43
|
-
1.2.10 hardens the D2C acceptance loop: failed authentication prerequisites block protected scenarios immediately, request recording survives navigation, repair prompts accept extra instructions, and the backend process restarts automatically when its source changes.
|
|
44
|
-
|
|
45
|
-
| Feature | How to use |
|
|
46
|
-
| --- | --- |
|
|
47
|
-
| **Auth-prerequisite fail-fast** | When a login / sign-in scenario (e.g. `POST /api/v1/auth/login`) fails during interactive acceptance, later protected scenarios are reported as blocked by that failed prerequisite instead of being executed one by one, so the root cause is visible immediately. |
|
|
48
|
-
| **Navigation-safe request recording** | Request recording now persists across in-app navigation through `sessionStorage` (up to 500 entries). Requests fired after a click that navigates to another page are captured too, so post-navigation behavior can still be asserted. |
|
|
49
|
-
| **Extra repair instructions** | Before repairing failed interaction scenarios, type extra requirements in the “补充修复要求” box; they are injected into the repair prompt as user-supplied constraints together with the failure details. |
|
|
50
|
-
| **Acceptance as a separate stage** | The D2C workbench now splits “API Integration” and “Acceptance & Delivery” into two explicit stages; after an automated repair run finishes, the workbench switches to the acceptance tab automatically. |
|
|
51
|
-
| **Backend source fingerprinting** | The mock/server backend is fingerprinted when it starts. If its source files change, the runtime detects the fingerprint difference and restarts the backend before acceptance, so tests always run against the code currently on disk. |
|
|
52
|
-
|
|
53
|
-
## 1.2.9 Runtime Productivity
|
|
54
|
-
|
|
55
|
-
1.2.9 adds layered project instructions, safe writes, background jobs, persistent terminals, and native web tools. Usually you can just describe the goal in natural language and the agent picks the right tool; when you need precise control, name the tool and its parameters explicitly in the prompt.
|
|
56
|
-
|
|
57
|
-
| Feature | How to use |
|
|
58
|
-
| --- | --- |
|
|
59
|
-
| **Layered project instructions** | Put `AGENTS.md` / `CLAUDE.md` in the project root or subdirectories; use `AGENTS.local.md` / `CLAUDE.local.md` for local additions in the same directory. Root rules load at startup; subdirectory rules load automatically when the agent touches files there. |
|
|
60
|
-
| **Per-turn change summary** | No configuration needed. After a successful `Write`, `Edit`, or `ApplyPatch`, the turn shows a color-coded `CHANGESET` receipt with workspace-relative paths, `CREATE` / `UPDATE` / `DELETE` operations, per-file line counts, and a total. At most 8 files are shown, with an explicit shown/total footer when more changed. |
|
|
61
|
-
| **File version protection** | No configuration needed. If the IDE, a formatter, or another process modifies a file after the agent read it, the next write fails with `Stale file`; ask the agent to re-read before editing. |
|
|
62
|
-
| **Standard tool presentation protocol** | Tool authors can declare `outputSchema`, `renderForModel`, `presentCall`, and `presentResult`, so the same result can use an appropriate form in the model context, CLI, and desktop. The CLI visually separates file diffs, web evidence, job receipts, foreground `COMMAND` output, and persistent `TERMINAL` output from the final answer. |
|
|
63
|
-
| **Background Shell / Jobs** | Say "start the dev server in the background" and the agent calls `Shell` with `background: true`. Use `JobList` to view jobs, `JobRead` for incremental output, `JobWait` to wait, and `JobKill` to stop. The CLI shows a color-bordered `JOB` receipt separating job metadata, logs, and the final answer; logs show at most the latest 12 lines and lists at most 8 items. Windows prefers UTF-8 and falls back automatically on GBK/GB18030 system diagnostics. |
|
|
64
|
-
| **Foreground command results** | Foreground `Shell` calls render as state-colored `COMMAND` receipts with separate command, stdout, stderr, and exit regions. Long output keeps the first and last 8 lines and explicitly folds the middle; persistent PTY output uses the distinct `TERMINAL` label. |
|
|
65
|
-
| **Desktop background status** | Electron automatically shows the number of running jobs in the session title bar, updated live on start, output, exit, or cancel. |
|
|
66
|
-
| **Persistent PTY** | Say "open a persistent terminal and keep interacting". The agent uses `TerminalOpen` to create a terminal, `TerminalWrite` for input, `TerminalRead` for incremental output, and `TerminalClose` to close it. |
|
|
67
|
-
| **Unified D2C/E2E process lifecycle** | No usage change. Preview and backend services still start/stop from the E2E/D2C workbench, but the underlying layer unifies output limits, process-tree termination, and idempotent cleanup. |
|
|
68
|
-
| **Native WebSearch** | Say "search the web for ...", or explicitly ask for `WebSearch`. It uses keyless DuckDuckGo Lite by default and degrades to Bing on connection failure, HTTP rejection, or no parseable results; up to 20 results per call. The CLI puts the top 5 into a bordered `WEB SEARCH` evidence block with titles and compact sources in search order. |
|
|
69
|
-
| **Native WebFetch** | Say "read this page: `https://...`", or explicitly ask for `WebFetch`. Supports HTTP(S), redirects, HTML-to-text, timeouts, and response size limits, and is compatible with Clash/TUN Fake-IP DNS. Direct access to Fake-IP, intranet, or cloud metadata addresses is still blocked; network operations still follow Flavor permission approval. |
|
|
70
|
-
|
|
71
|
-
Common precise usage:
|
|
72
|
-
|
|
73
|
-
```text
|
|
74
|
-
Start npm run dev with Shell in background mode, then use JobRead to inspect the startup logs.
|
|
75
|
-
Open a persistent terminal, run a Python REPL in it, execute two snippets, then close the terminal.
|
|
76
|
-
Use WebSearch to find the official TypeScript 7 migration notes, then WebFetch the most relevant official page.
|
|
77
|
-
This directory has its own conventions; follow src/payments/AGENTS.md before modifying code here.
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
See [Technical Design Report §38](./技术方案报告.md#38-129-运行时生产力与原生-web-能力) for tool parameters, state machines, security boundaries, and extension interfaces; acceptance criteria are in the [Runtime productivity spec](./docs/specs/2026-08-13-runtime-productivity-waves.md).
|
|
81
|
-
|
|
82
41
|
## Quick Start
|
|
83
42
|
|
|
84
43
|
> [!IMPORTANT]
|
|
@@ -193,12 +152,41 @@ Common commands:
|
|
|
193
152
|
| `/memory`, `/remember`, `/forget`, `/forget-cold` | Manage long-term memory; `/forget-cold` purges cold entries and their files |
|
|
194
153
|
| `/mcp` | View and manage MCP servers |
|
|
195
154
|
| `/loop <goal>` | Run an autonomous loop with verification |
|
|
196
|
-
| `/goal <objective>` | Run the plan, execute, adversarial-review workflow |
|
|
197
|
-
| `/
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
155
|
+
| `/goal <objective>` | Run the plan, execute, adversarial-review workflow |
|
|
156
|
+
| `/pals`, `/chat`, `/co-work` | Discover and collaborate with other local CLI instances |
|
|
157
|
+
| `/audit` | View tool failure audits |
|
|
158
|
+
|
|
159
|
+
You can submit steering or queue follow-ups while a run is in progress; once the current model response finishes, the task picks up new instructions at safe boundaries.
|
|
160
|
+
|
|
161
|
+
#### CLI pals and cross-project work
|
|
162
|
+
|
|
163
|
+
Interactive CLI instances on the same Windows or macOS user account can collaborate over local-only IPC (Windows named pipes or Unix sockets; no TCP fallback). Give each window a memorable alias:
|
|
164
|
+
|
|
165
|
+
```bash
|
|
166
|
+
# terminal A, in project A
|
|
167
|
+
flavor --pal-name A
|
|
168
|
+
|
|
169
|
+
# terminal B, in project B
|
|
170
|
+
flavor --pal-name B
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
Useful commands:
|
|
174
|
+
|
|
175
|
+
```text
|
|
176
|
+
/pals # aliases and per-process UUIDs
|
|
177
|
+
/pals --verbose # also show project paths and timestamps
|
|
178
|
+
/pals rename api # rename this active instance
|
|
179
|
+
/chat B Update the API and tests # deliver to B and start its agent safely
|
|
180
|
+
/co-work B Upgrade B, then adapt A # negotiate one plan before parallel work
|
|
181
|
+
/co-work status [co-work-uuid]
|
|
182
|
+
/co-work cancel <co-work-uuid> [reason]
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
`/chat` is bidirectional and task-oriented. If B is idle, the attributed message starts a normal model turn; if B is already running, it becomes steering, or a follow-up when another local submission is pending. Remote text is converted to a safe non-slash prompt, so `/exit`-like text is not dispatched as a local command. B can answer with `/chat A ...`.
|
|
186
|
+
|
|
187
|
+
`/co-work` first places both agents in planning and waits for both to accept the same hashed plan and declare READY. Early READY intents are retained, and only the broker's exactly-once START event opens parallel execution. Each agent works only in its own project, receives only its assigned tasks, and reports bounded completion evidence. The broker-selected integration owner verifies all assertions and emits END or FAIL through `CoWorkIntegrate`. Communication uses authenticated, bounded local IPC with no TCP listener; peer input cannot approve tools or access the other workspace. UUID/alias routing and the protocol already support a third active client; durable artifact exchange, broker-restart journaling/recovery, and large-group coordination are later hardening work. See the [CLI pals specification](./docs/specs/2026-08-14-cli-pals-cowork.md).
|
|
188
|
+
|
|
189
|
+
### Electron Desktop
|
|
202
190
|
|
|
203
191
|
```bash
|
|
204
192
|
npm run desktop:dev # dev mode
|
|
@@ -209,7 +197,7 @@ npm run desktop:dist # Windows NSIS installer
|
|
|
209
197
|
|
|
210
198
|
The desktop app provides project and session switching, streaming Markdown, tool and diff views, permission confirmations, task status, and management of Skills, MCP, memory, and models.
|
|
211
199
|
|
|
212
|
-
The **
|
|
200
|
+
The **E2E** module in the sidebar drives a rough requirement or an existing design export through the full delivery pipeline: it generates a PRD and an interactive prototype for review, then moves into D2C visual implementation (Vue 3 / React) under `src/d2c-output/<task>/`. A Vite dev server starts automatically for pixel-level comparison, producing a visual-fidelity score and a structured diff report (region offsets, color deviations, font differences); the results workbench offers overlay, curtain, flicker, and heatmap modes, an SVG annotation layer, and a severity-sorted issue list. After visual review, a Swagger/OpenAPI contract is generated or imported to auto-create Axios wrappers and an Express mock server, followed by autonomous interactive acceptance and scored delivery.
|
|
213
201
|
|
|
214
202
|
### VS Code / Qoder
|
|
215
203
|
|
|
@@ -384,6 +372,7 @@ npm run build
|
|
|
384
372
|
- [Multimodal image attachments spec](./docs/specs/2026-07-30-multimodal-image-attachments.md)
|
|
385
373
|
- [D2C design-to-code spec](./docs/specs/2026-08-09-d2c-design-to-code.md)
|
|
386
374
|
- [D2C review & integration spec](./docs/specs/2026-08-10-d2c-review-and-integration.md)
|
|
375
|
+
- [E2E requirement-to-delivery spec](./docs/specs/2026-08-12-e2e-requirement-to-delivery.md)
|
|
387
376
|
- [1.2.9 runtime productivity spec](./docs/specs/2026-08-13-runtime-productivity-waves.md)
|
|
388
377
|
- [VS Code next steps](./docs/specs/2026-08-01-flavor-code-vscode-next.md)
|
|
389
378
|
|
package/README.zh-CN.md
CHANGED
|
@@ -35,50 +35,9 @@ Flavor Code 接入 OpenAI、Anthropic 或兼容服务,在受控工作区内使
|
|
|
35
35
|
| 🧭 | **复杂任务可控推进** | 任务计划、子 Agent、steering、follow-up、`/loop` 和 `/goal` |
|
|
36
36
|
| ⏪ | **结果可追溯、可恢复** | 完整时间线、checkpoint、rewind、trace、Diff 和失败审计 |
|
|
37
37
|
| 🧠 | **本地长期上下文** | 记忆、Skill、插件和项目指南均保存在本机 |
|
|
38
|
-
| 🎨 | **
|
|
38
|
+
| 🎨 | **E2E 需求到交付** | 从粗需求或设计稿到可交付产品:PRD、交互原型、视觉还原、接口联调、自主验收与评分交付(仅 Electron) |
|
|
39
39
|
| 🛡️ | **明确的权限边界** | 分别控制读、写、Shell、网络和破坏性操作,也可使用 Docker |
|
|
40
40
|
|
|
41
|
-
## 1.2.10 D2C 验收与交付
|
|
42
|
-
|
|
43
|
-
1.2.10 强化 D2C 验收闭环:认证前置失败快速阻断、请求记录跨导航保留、修复提示支持补充要求,后端源码变化时自动重启。
|
|
44
|
-
|
|
45
|
-
| 功能 | 使用方式 |
|
|
46
|
-
| --- | --- |
|
|
47
|
-
| **认证前置失败快速阻断** | 交互验收中,登录/认证类场景(如 `POST /api/v1/auth/login`)失败后,后续受保护场景不再逐个执行,直接标记为被该失败前置场景阻断,根因一目了然。 |
|
|
48
|
-
| **跨导航请求记录** | 请求记录通过 `sessionStorage` 在页面导航之间保留(最多 500 条),点击跳转等导航之后的请求同样会被捕获,可继续参与断言。 |
|
|
49
|
-
| **修复补充要求** | 修复失败的交互场景前,可在“补充修复要求”输入框填写额外约束,它们会与失败详情一起作为“用户补充要求”注入修复提示词。 |
|
|
50
|
-
| **验收与交付独立阶段** | D2C 工作台将“接口联调”与“验收与交付”拆分为两个明确阶段;自动修复完成后自动切换到验收页签。 |
|
|
51
|
-
| **后端源码指纹检测** | 启动时为 mock/server 后端源码计算指纹;源码文件变化后,运行时检测到指纹差异会自动重启后端,确保验收针对磁盘上的最新代码。 |
|
|
52
|
-
|
|
53
|
-
## 1.2.9 运行时生产力
|
|
54
|
-
|
|
55
|
-
1.2.9 新增分层项目指令、安全写入、后台任务、持久终端和原生 Web 工具。通常只需用自然语言描述目标,Agent 会选择合适的工具;需要精确控制时,也可以在提示词中明确指定工具和参数。
|
|
56
|
-
|
|
57
|
-
| 功能 | 使用方式 |
|
|
58
|
-
| --- | --- |
|
|
59
|
-
| **分层项目指令** | 在项目根目录或子目录放置 `AGENTS.md` / `CLAUDE.md`;同目录需要本地补充时使用 `AGENTS.local.md` / `CLAUDE.local.md`。根规则启动时加载,子目录规则在 Agent 访问该目录文件时自动加载。 |
|
|
60
|
-
| **每轮成果物汇总** | 无需配置。`Write`、`Edit` 或 `ApplyPatch` 成功后,回合结束会显示带语义色的 `CHANGESET` 收据,使用工作区相对路径列出 `CREATE` / `UPDATE` / `DELETE` 操作、各文件行数和总计。最多展示 8 个文件,超出时明确显示已展示数与总数。 |
|
|
61
|
-
| **文件版本保护** | 无需配置。如果 IDE、格式化器或其他进程在 Agent 读取后修改了文件,后续写入会报 `Stale file`;让 Agent 重新读取后再修改即可。 |
|
|
62
|
-
| **标准工具展示协议** | 工具作者可声明 `outputSchema`、`renderForModel`、`presentCall` 和 `presentResult`,让同一结果在模型上下文、CLI 与桌面端分别使用合适的形式。CLI 会把文件 Diff、Web 证据、Job 运行收据、前台 `COMMAND` 和持久 `TERMINAL` 与最终回答明确分开。 |
|
|
63
|
-
| **后台 Shell / Job** | 提示“在后台启动开发服务器”,Agent 会调用 `Shell` 并设置 `background: true`。使用 `JobList` 查看任务、`JobRead` 增量读取输出、`JobWait` 等待结束、`JobKill` 停止任务。CLI 使用带状态色边界的 `JOB` 收据区分任务元数据、日志与最终回答;日志最多显示最近 12 行,列表最多显示 8 项。Windows 优先使用 UTF-8,遇到 GBK/GB18030 系统诊断时自动回退。 |
|
|
64
|
-
| **前台命令结果** | 前台 `Shell` 显示为带状态色的 `COMMAND` 收据,分别展示命令、stdout、stderr 和退出状态。长输出保留开头 8 行与结尾 8 行,并明确折叠中间部分;持久 PTY 使用独立的 `TERMINAL` 标签。 |
|
|
65
|
-
| **桌面后台状态** | Electron 会在会话标题栏自动显示运行中的 Job 数量,并在任务启动、输出、退出或取消时实时更新。 |
|
|
66
|
-
| **持久 PTY** | 提示“打开一个持久终端并继续交互”。Agent 使用 `TerminalOpen` 创建终端、`TerminalWrite` 输入、`TerminalRead` 增量读取输出,并用 `TerminalClose` 关闭。 |
|
|
67
|
-
| **D2C/E2E 统一进程生命周期** | 使用方式不变。预览和后端服务仍从 E2E/D2C 工作台启动或停止,底层统一处理输出限制、进程树终止和幂等清理。 |
|
|
68
|
-
| **原生 WebSearch** | 提示“搜索 Web 上的……”,或明确要求使用 `WebSearch`。默认使用无需密钥的 DuckDuckGo Lite;连接失败、HTTP 拒绝或没有可解析结果时自动降级到 Bing。单次最多返回 20 条;CLI 将前 5 条放入带边界的 `WEB SEARCH` 证据块,按搜索排名显示标题和紧凑来源。 |
|
|
69
|
-
| **原生 WebFetch** | 提示“读取这个网页:`https://...`”,或明确要求使用 `WebFetch`。支持 HTTP(S)、重定向、HTML 转文本、超时和响应大小限制,并兼容 Clash/TUN Fake-IP DNS。直接访问 Fake-IP、内网或云元数据地址仍会被拦截;网络操作继续遵守 Flavor 权限审批。 |
|
|
70
|
-
|
|
71
|
-
常见的精确用法:
|
|
72
|
-
|
|
73
|
-
```text
|
|
74
|
-
使用 Shell 后台模式启动 npm run dev,然后通过 JobRead 检查启动日志。
|
|
75
|
-
打开持久终端,在其中运行 Python REPL,连续执行两段代码后关闭终端。
|
|
76
|
-
使用 WebSearch 搜索 TypeScript 7 官方迁移说明,再用 WebFetch 读取最相关的官方页面。
|
|
77
|
-
这个目录有独立约定,请先遵守 src/payments/AGENTS.md 再修改代码。
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
原生工具的参数、状态机、安全边界和扩展接口详见[技术方案报告第 38 节](./技术方案报告.md#38-129-运行时生产力与原生-web-能力);验收规格见[运行时生产力规范](./docs/specs/2026-08-13-runtime-productivity-waves.md)。
|
|
81
|
-
|
|
82
41
|
## 快速开始
|
|
83
42
|
|
|
84
43
|
> [!IMPORTANT]
|
|
@@ -193,12 +152,41 @@ OAuth PKCE 的运行时行为与配置约定见 [PKCE 规范](./docs/specs/pkce-
|
|
|
193
152
|
| `/memory`、`/remember`、`/forget`、`/forget-cold` | 管理长期记忆;`/forget-cold` 清空 cold 记忆及其文件 |
|
|
194
153
|
| `/mcp` | 查看和管理 MCP 服务 |
|
|
195
154
|
| `/loop <goal>` | 运行带验证的自治循环 |
|
|
196
|
-
| `/goal <objective>` | 运行规划、执行、对抗审查流程 |
|
|
197
|
-
| `/
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
155
|
+
| `/goal <objective>` | 运行规划、执行、对抗审查流程 |
|
|
156
|
+
| `/pals`、`/chat`、`/co-work` | 发现并协作其他本机 CLI 实例 |
|
|
157
|
+
| `/audit` | 查看工具失败审计 |
|
|
158
|
+
|
|
159
|
+
运行中可以提交 steering 或排队 follow-up;当前模型响应结束后,任务会在安全边界处接收新指令。
|
|
160
|
+
|
|
161
|
+
#### CLI Pals 与跨项目协作
|
|
162
|
+
|
|
163
|
+
同一 Windows 或 macOS 用户下的交互式 CLI 可以通过纯本地 IPC 协作(Windows named pipe 或 Unix socket,不回退到 TCP)。先给每个窗口一个容易识别的别名:
|
|
164
|
+
|
|
165
|
+
```bash
|
|
166
|
+
# 终端 A,位于项目 A
|
|
167
|
+
flavor --pal-name A
|
|
168
|
+
|
|
169
|
+
# 终端 B,位于项目 B
|
|
170
|
+
flavor --pal-name B
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
常用命令:
|
|
174
|
+
|
|
175
|
+
```text
|
|
176
|
+
/pals # 查看别名和每进程 UUID
|
|
177
|
+
/pals --verbose # 额外显示项目路径和时间
|
|
178
|
+
/pals rename api # 重命名当前活动实例
|
|
179
|
+
/chat B 更新 API 和测试 # 投递给 B,并安全启动其 Agent
|
|
180
|
+
/co-work B 先升级 B,再兼容 A # 先协商同一计划,再并行开工
|
|
181
|
+
/co-work status [co-work-uuid]
|
|
182
|
+
/co-work cancel <co-work-uuid> [reason]
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
`/chat` 支持双向任务通信。B 空闲时,带来源标识的消息会启动正常模型回合;B 正在运行时,消息会成为 steering;已有本地提交待运行时则成为 follow-up。远端文本会转换成安全的非斜杠 prompt,因此 `/exit` 一类文本不会被当成本地命令分派。B 可以用 `/chat A ...` 回复。
|
|
186
|
+
|
|
187
|
+
`/co-work` 会先让双方进入规划,等待双方接受同一个哈希计划并声明 READY;较早的 READY 意图会被保留,只有 broker 恰好一次的 START 事件才会放行并行执行。每个 Agent 只在自己的项目内工作,只接收分配给自己的任务,并提交有界的完成证据。broker 指定的集成负责人会检查所有断言,再通过 `CoWorkIntegrate` 广播 END 或 FAIL。通信使用经过认证、有大小上限的本机 IPC,不开放 TCP 监听;peer 输入不能代替本机工具审批,也不能访问另一工作区。UUID/别名路由和协议已能支持第三个活动实例;持久化成果物交换、broker 重启日志与恢复、大规模多方协调属于后续强化。详见 [CLI Pals 规范](./docs/specs/2026-08-14-cli-pals-cowork.md)。
|
|
188
|
+
|
|
189
|
+
### Electron 桌面端
|
|
202
190
|
|
|
203
191
|
```bash
|
|
204
192
|
npm run desktop:dev # 开发模式
|
|
@@ -209,6 +197,8 @@ npm run desktop:dist # Windows NSIS 安装包
|
|
|
209
197
|
|
|
210
198
|
桌面端提供项目和会话切换、流式 Markdown、工具与 Diff 展示、权限确认、任务状态,以及 Skill、MCP、记忆和模型管理。
|
|
211
199
|
|
|
200
|
+
侧栏的 **E2E** 模块覆盖从粗需求到可验收成果物的完整交付链路:从粗需求生成 PRD 与可交互原型(支持审阅与退回),确认后进入 D2C 视觉还原(Vue 3 / React),自动启动 Vite dev server 进行像素级对比,输出视觉还原度评分与结构化差异报告,并提供叠加、帘幕、闪烁与热力图等对比模式、SVG 标注层和按严重度排序的问题列表;视觉审阅通过后,自动生成或导入 Swagger/OpenAPI 契约以创建 Axios 封装与 Express mock 服务,随后进行自主交互验收,最终完成评分与成果物交付。
|
|
201
|
+
|
|
212
202
|
### VS Code / Qoder
|
|
213
203
|
|
|
214
204
|
```bash
|
|
@@ -381,6 +371,7 @@ npm run build
|
|
|
381
371
|
- [控制面、沙箱与 VS Code 规范](./docs/specs/2026-07-29-control-plane-sandbox-vscode.md)
|
|
382
372
|
- [多模态图片规范](./docs/specs/2026-07-30-multimodal-image-attachments.md)
|
|
383
373
|
- [VS Code 后续规划](./docs/specs/2026-08-01-flavor-code-vscode-next.md)
|
|
374
|
+
- [E2E 需求到交付规范](./docs/specs/2026-08-12-e2e-requirement-to-delivery.md)
|
|
384
375
|
|
|
385
376
|
## 安全提示
|
|
386
377
|
|
|
@@ -15,7 +15,7 @@ import {
|
|
|
15
15
|
packageVersion,
|
|
16
16
|
redactErrorText,
|
|
17
17
|
transcriptReducer
|
|
18
|
-
} from "./chunk-
|
|
18
|
+
} from "./chunk-OT5XIN6G.js";
|
|
19
19
|
import "./chunk-XFCJXRJ2.js";
|
|
20
20
|
import {
|
|
21
21
|
Box_default,
|
|
@@ -1825,7 +1825,20 @@ function completionKeyAction(key, menuOpen) {
|
|
|
1825
1825
|
function slashKeyAction(key, completion) {
|
|
1826
1826
|
return completionKeyAction(key, completion !== null);
|
|
1827
1827
|
}
|
|
1828
|
-
function
|
|
1828
|
+
function appRuntimeOptions(props, output, onApprovalChange) {
|
|
1829
|
+
return {
|
|
1830
|
+
workspace: props.workspace,
|
|
1831
|
+
...props.home === void 0 ? {} : { home: props.home },
|
|
1832
|
+
...props.resumeSession === void 0 ? {} : { resumeSession: props.resumeSession },
|
|
1833
|
+
collaboration: {
|
|
1834
|
+
instanceId: props.instanceId,
|
|
1835
|
+
...props.palAlias === void 0 ? {} : { alias: props.palAlias }
|
|
1836
|
+
},
|
|
1837
|
+
output,
|
|
1838
|
+
onApprovalChange
|
|
1839
|
+
};
|
|
1840
|
+
}
|
|
1841
|
+
function App({ workspace, home, resumeSession, instanceId, palAlias }) {
|
|
1829
1842
|
const { exit } = use_app_default();
|
|
1830
1843
|
const { stdout } = useStdout();
|
|
1831
1844
|
const [runtime, setRuntime] = useState2();
|
|
@@ -1912,13 +1925,13 @@ function App({ workspace, home, resumeSession }) {
|
|
|
1912
1925
|
flushText();
|
|
1913
1926
|
dispatch({ type: "session", event });
|
|
1914
1927
|
};
|
|
1915
|
-
void createProductionRuntime({
|
|
1928
|
+
void createProductionRuntime(appRuntimeOptions({
|
|
1916
1929
|
workspace,
|
|
1930
|
+
instanceId,
|
|
1917
1931
|
...home === void 0 ? {} : { home },
|
|
1918
1932
|
...resumeSession === void 0 ? {} : { resumeSession },
|
|
1919
|
-
|
|
1920
|
-
|
|
1921
|
-
}).then(async (created) => {
|
|
1933
|
+
...palAlias === void 0 ? {} : { palAlias }
|
|
1934
|
+
}, receive, () => setRevision((value) => value + 1))).then(async (created) => {
|
|
1922
1935
|
if (disposed) {
|
|
1923
1936
|
await created.dispose();
|
|
1924
1937
|
return;
|
|
@@ -1945,7 +1958,7 @@ function App({ workspace, home, resumeSession }) {
|
|
|
1945
1958
|
void closeAndDisposeRuntime(runtimeRef.current, (error) => process.stderr.write(`flavor cleanup: ${error}
|
|
1946
1959
|
`));
|
|
1947
1960
|
};
|
|
1948
|
-
}, [workspace, home, resumeSession]);
|
|
1961
|
+
}, [workspace, home, resumeSession, instanceId, palAlias]);
|
|
1949
1962
|
useEffect3(() => installSigintHandler(process, interrupt), [interrupt]);
|
|
1950
1963
|
useEffect3(() => {
|
|
1951
1964
|
if (runtime?.services.ideContext === void 0) {
|
|
@@ -2719,6 +2732,23 @@ function TurnView({
|
|
|
2719
2732
|
turn.blocks.map((block, index) => block.kind === "status" ? /* @__PURE__ */ jsx5(StatusBlockView, { block, interactive, workspaceName }, block.id) : /* @__PURE__ */ jsx5(Box_default, { children: /* @__PURE__ */ jsx5(AssistantText, { text: block.text }) }, `${turn.id}-text-${index}`))
|
|
2720
2733
|
] });
|
|
2721
2734
|
}
|
|
2735
|
+
if (turn.source?.kind === "pal") {
|
|
2736
|
+
const context = turn.source.context === void 0 ? "" : ` \xB7 ${turn.source.context}`;
|
|
2737
|
+
return /* @__PURE__ */ jsxs4(Box_default, { flexDirection: "column", marginBottom: 1, children: [
|
|
2738
|
+
/* @__PURE__ */ jsxs4(Box_default, { flexDirection: "column", borderStyle: "round", borderColor: "cyan", paddingX: 1, children: [
|
|
2739
|
+
/* @__PURE__ */ jsxs4(Text, { color: "cyanBright", bold: true, children: [
|
|
2740
|
+
"PAL \xB7 ",
|
|
2741
|
+
turn.source.alias,
|
|
2742
|
+
" (",
|
|
2743
|
+
turn.source.instanceId.slice(0, 8),
|
|
2744
|
+
")",
|
|
2745
|
+
context
|
|
2746
|
+
] }),
|
|
2747
|
+
/* @__PURE__ */ jsx5(Text, { color: "ansi:whiteBright", children: turn.prompt })
|
|
2748
|
+
] }),
|
|
2749
|
+
/* @__PURE__ */ jsx5(Box_default, { flexDirection: "column", paddingLeft: 2, marginTop: 1, children: turn.blocks.map((block, index) => block.kind === "status" ? /* @__PURE__ */ jsx5(StatusBlockView, { block, interactive, workspaceName }, block.id) : /* @__PURE__ */ jsx5(Box_default, { marginBottom: 1, children: /* @__PURE__ */ jsx5(AssistantText, { text: block.text }) }, `${turn.id}-text-${index}`)) })
|
|
2750
|
+
] });
|
|
2751
|
+
}
|
|
2722
2752
|
return /* @__PURE__ */ jsxs4(Box_default, { flexDirection: "column", marginBottom: 1, children: [
|
|
2723
2753
|
/* @__PURE__ */ jsxs4(Box_default, { flexDirection: "row", backgroundColor: "#3a3a3a", paddingX: 1, paddingY: 0, children: [
|
|
2724
2754
|
/* @__PURE__ */ jsx5(Text, { color: "ansi:whiteBright", bold: true, backgroundColor: "#3a3a3a", children: "\u276F" }),
|
|
@@ -3535,6 +3565,7 @@ export {
|
|
|
3535
3565
|
PromptLine,
|
|
3536
3566
|
SinglePendingPrompt,
|
|
3537
3567
|
TerminalLayout,
|
|
3568
|
+
appRuntimeOptions,
|
|
3538
3569
|
classifyTerminalInput,
|
|
3539
3570
|
closeAndDisposeRuntime,
|
|
3540
3571
|
completionKeyAction,
|