@prettier-ai/dsh-workspace 0.1.2-alpha.1
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/LICENSE +21 -0
- package/README.i18n.yaml +6 -0
- package/README.md +178 -0
- package/README.zh.md +178 -0
- package/lib/index.js +757 -0
- package/lib/invariant.js +114 -0
- package/lib/types/entity.d.ts +88 -0
- package/lib/types/entity.js +156 -0
- package/lib/types/index.d.ts +163 -0
- package/lib/types/index.js +600 -0
- package/lib/types/invariant.d.ts +16 -0
- package/lib/types/invariant.js +43 -0
- package/lib/types/paths.d.ts +18 -0
- package/lib/types/paths.js +21 -0
- package/lib/types/spec.d.ts +85 -0
- package/lib/types/spec.js +63 -0
- package/lib/types/types.d.ts +92 -0
- package/lib/types/types.js +8 -0
- package/package.json +60 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 DeepSeek
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.i18n.yaml
ADDED
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
|
|
2
|
+
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
|
3
|
+
# after editing either side, bring the other along and re-record with:
|
|
4
|
+
# pnpm run verify-translation-pairing --write packages/workspace/workspace/README.md
|
|
5
|
+
README.md: 49ca861742fe9ea5f36edbaeb8d9700c475b1d50
|
|
6
|
+
README.zh.md: 707044970b716577d2f1f95e558c341e217985c4
|
package/README.md
ADDED
|
@@ -0,0 +1,178 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Workspace entity registry (ctx.workspaceRegistry) for hosts choosing, mounting, or debugging durable workspace records and header-validated session membership."
|
|
3
|
+
kind: "package-reference"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# @deepseek-ai/dsh-workspace
|
|
7
|
+
|
|
8
|
+
English | [中文](README.zh.md)
|
|
9
|
+
|
|
10
|
+
## Summary
|
|
11
|
+
|
|
12
|
+
`dsh-workspace` gives a host a persistent set of workspaces: named user directories, each with the sessions that ran in it, kept in a stable order across restarts. With it, a UI can show a sidebar of projects, attach sessions to the right project, hide a session from the grouping without losing it, and remove a project — removal never deletes the folder or the session histories, which become ungrouped. Use it in GUI or host compositions that need durable project grouping; headless and minimal runs can omit it entirely. The package is host-side only: the model, tools, and agent loop never see it, so it adds no tokens, prompts, or request context. It needs a session store and a persistence backend mounted alongside it; setup is a few composition rows.
|
|
13
|
+
|
|
14
|
+
## Table of Contents
|
|
15
|
+
|
|
16
|
+
- [Use this package](#use-this-package)
|
|
17
|
+
- [Understand the implementation](#understand-the-implementation)
|
|
18
|
+
- [Further Exploration](#further-exploration)
|
|
19
|
+
- [Model Experience](#model-experience)
|
|
20
|
+
- [Known Limitations and Deferred Work](#known-limitations-and-deferred-work)
|
|
21
|
+
- [Dev Note](#dev-note)
|
|
22
|
+
|
|
23
|
+
-----
|
|
24
|
+
|
|
25
|
+
<a id="use-this-package"></a>
|
|
26
|
+
## Use this package
|
|
27
|
+
|
|
28
|
+
Use this package to give the product a project list: named directories the user works in, the sessions that ran in each, a stable order, and a way to hide sessions without losing them. The API contracts behind each action live in the implementation section.
|
|
29
|
+
|
|
30
|
+
### When to use it
|
|
31
|
+
|
|
32
|
+
Use it when the product shows a persistent workspace surface — a sidebar, session grouping, or automation that names directories and orders them. It is invisible to the model, so it adds no token or request cost. Skip it when there is no grouping surface; nothing else in the harness needs it.
|
|
33
|
+
|
|
34
|
+
### Setting up
|
|
35
|
+
|
|
36
|
+
The package takes no configuration of its own; it needs a session store, a session persistence backend, and the storage rows that keep its records. A minimal composition:
|
|
37
|
+
|
|
38
|
+
```yaml
|
|
39
|
+
- name: '@deepseek-ai/dsh-session'
|
|
40
|
+
- name: '@deepseek-ai/dsh-session-persistence-jsonl'
|
|
41
|
+
- name: '@deepseek-ai/dsh-storage'
|
|
42
|
+
- name: '@deepseek-ai/dsh-storage-json'
|
|
43
|
+
- name: '@deepseek-ai/dsh-storage-domain'
|
|
44
|
+
config:
|
|
45
|
+
backend: json
|
|
46
|
+
- name: '@deepseek-ai/dsh-workspace'
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
With these rows mounted, creating a project shows up in the list immediately and survives a restart; the first start also groups existing sessions by the directory they ran in. If a required peer is missing, the workspace feature stays unavailable until it is mounted.
|
|
50
|
+
|
|
51
|
+
### Creating and ordering projects
|
|
52
|
+
|
|
53
|
+
Create a project from any directory that exists: give its path and an optional title, and the project appears in the list, newest first. A path that does not exist, or a file instead of a directory, is rejected and nothing changes; creating a project for a directory that already has one returns the existing project unchanged. Rename a project at any time, and move it to any position in the list:
|
|
54
|
+
|
|
55
|
+
```text
|
|
56
|
+
// Host consumer code, after the composition above is loaded:
|
|
57
|
+
const project = await ctx.workspaceRegistry.create('/path/to/dir', 'My Project')
|
|
58
|
+
await project.setTitle('Renamed')
|
|
59
|
+
ctx.workspaceRegistry.list() // shows the project, newest first
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### Grouping sessions under a project
|
|
63
|
+
|
|
64
|
+
A session joins the project of the directory it runs in: create a session in a project's directory and it appears under that project, newest first. A session can only belong to one project. A session whose directory cannot be validated — no recorded directory, or a moved or deleted folder — cannot join and stays ungrouped.
|
|
65
|
+
|
|
66
|
+
### Hiding sessions and removing projects
|
|
67
|
+
|
|
68
|
+
Hide a session from the grouping when it should stop appearing there: it disappears from the visible list, while its session, history, and place in the project stay intact. Remove a project when it is no longer needed: it leaves the list, and its folder, files, and session histories are never touched — those sessions become ungrouped. Adding the same directory again afterwards starts a fresh project without the old sessions.
|
|
69
|
+
|
|
70
|
+
-----
|
|
71
|
+
|
|
72
|
+
<a id="understand-the-implementation"></a>
|
|
73
|
+
## Understand the implementation
|
|
74
|
+
|
|
75
|
+
<details>
|
|
76
|
+
<summary>Implementation internals — click to expand</summary>
|
|
77
|
+
|
|
78
|
+
This section explains the design decisions behind the feature and points at the code that realizes them; the observable behavior is fully covered in [Use this package](#use-this-package).
|
|
79
|
+
|
|
80
|
+
### Design philosophy
|
|
81
|
+
|
|
82
|
+
- **One record per canonical path.** `fs.realpath` is the single uniqueness canon: paths are stored canonicalized, so a symlink to an owned directory collides, and uniqueness is string equality of canonical paths.
|
|
83
|
+
- **Membership is ownership plus a live cwd fact.** The record's ordered `sessionIds` is the ownership truth; the startup header index validates it, and `sessionIds` filters on read while the next mutation prunes durably.
|
|
84
|
+
- **Header-only reads.** Bootstrap and attach validation read `SessionHeader` fields only; event bodies are never loaded.
|
|
85
|
+
- **Two-write mutations with an explicit marker.** Create and delete persist a `pendingMutation` marker before the record/order pair can diverge, so startup completes exactly the interrupted operation and unmarked divergence fails loud as corruption.
|
|
86
|
+
- **Serialized writes.** Registry operations run on one operation chain; entity mutations go through `table.update` on the domain write chain, stamping `updatedAt` and deciding membership at their chain slot.
|
|
87
|
+
|
|
88
|
+
### API behavior
|
|
89
|
+
|
|
90
|
+
The API is one small family with two owners: `WorkspaceRegistry` creates, orders, and deletes projects and manages their session accounting; the `Workspace` entity exposes the display title, directory status, and the session projection. Per-method contracts live in the code, not this README — see [src/index.ts](src/index.ts) and [src/entity.ts](src/entity.ts).
|
|
91
|
+
|
|
92
|
+
### Source map
|
|
93
|
+
|
|
94
|
+
| File | Role |
|
|
95
|
+
|---|---|
|
|
96
|
+
| [`src/index.ts`](src/index.ts) | Plugin entry: `WorkspaceRegistry` service, header index, bootstrap, operation serialization |
|
|
97
|
+
| [`src/entity.ts`](src/entity.ts) | Package-private `Workspace` implementation and its single `mutate` write path |
|
|
98
|
+
| [`src/spec.ts`](src/spec.ts) | Domain declaration: record schema, registry state, `defineDomain` spec |
|
|
99
|
+
| [`src/types.ts`](src/types.ts) | Public `Workspace` interface and `WorkspaceId` brand |
|
|
100
|
+
| [`src/paths.ts`](src/paths.ts) | The `realpath` uniqueness canon |
|
|
101
|
+
| [`src/invariant.ts`](src/invariant.ts) | Invariant companion: the entity cache mirrors the durable table |
|
|
102
|
+
|
|
103
|
+
### Durable shape
|
|
104
|
+
|
|
105
|
+
The registry opens the `workspace` domain (version 2): a `workspaces` table keyed by `WorkspaceId` plus one global state holding `workspaceIds` (the authoritative display order), `archivedSessionIds`, and the optional `pendingMutation` marker. Records written before `archivedSessionIds` existed parse with an empty set through the schema default.
|
|
106
|
+
|
|
107
|
+
### Lifecycle
|
|
108
|
+
|
|
109
|
+
On start, the registry opens the domain, completes a marked mutation if one is pending, validates stored state — duplicate paths, duplicate session accounts, and order drift all fail loud — and, when not yet initialized, bootstraps history from persisted headers before writing the initialized marker last, so an interrupted bootstrap resumes safely. A fresh empty registry is real once initialized; it never re-bootstraps.
|
|
110
|
+
|
|
111
|
+
### Failure and recovery
|
|
112
|
+
|
|
113
|
+
A create or delete whose second write fails rolls the cache and the prior order back; when both the operation and its rollback fail, the durable marker still names the interrupted operation and the next startup completes or rolls it back. A committed delete whose marker cleanup fails still reports success, and the next startup clears the marker idempotently.
|
|
114
|
+
|
|
115
|
+
### Invariant
|
|
116
|
+
|
|
117
|
+
The `workspace-invariant` companion registers the owned relationship: every durable `domain/changed` for the `workspaces` table must name a record the entity cache already holds — a delete is valid only after the registry removed the entity from its cache, so a bypassing write path fails the invariant.
|
|
118
|
+
|
|
119
|
+
</details>
|
|
120
|
+
|
|
121
|
+
-----
|
|
122
|
+
|
|
123
|
+
<a id="further-exploration"></a>
|
|
124
|
+
## Further Exploration
|
|
125
|
+
|
|
126
|
+
Read these pages when this package's view is not enough: the subsystem reference is the authoritative feature contract, and the Agent Notes record why projects start from session history and why removal is non-destructive.
|
|
127
|
+
|
|
128
|
+
- [Workspace subsystem](../../../docs/subsystems/workspace.md) — the feature contract for projects and their sessions, and the generated API for the workspace service.
|
|
129
|
+
- [Workspace package map](../README.md) — the group's single package and its repository position.
|
|
130
|
+
- [domain KV storage Agent Note](../../../.agents/notes/proposed/architecture/2026-07-24-domain-kv-storage-and-workspace.md) — why project records use the domain data form.
|
|
131
|
+
- [Workspace UI product-flow Agent Note](../../../.agents/notes/implemented/feature/2026-07-25-workspace-ui-product-flow.md) — how the first start builds projects from session history and how the GUI orders them.
|
|
132
|
+
- [Workspace registration deletion decision](../../../.agents/notes/implemented/feature/2026-07-27-workspace-registration-deletion.md) — why removing a project never deletes its folder or sessions.
|
|
133
|
+
|
|
134
|
+
-----
|
|
135
|
+
|
|
136
|
+
<a id="model-experience"></a>
|
|
137
|
+
## Model Experience
|
|
138
|
+
|
|
139
|
+
### Workspace records and session accounts
|
|
140
|
+
|
|
141
|
+
#### What the model sees
|
|
142
|
+
|
|
143
|
+
Nothing. `ctx.workspaceRegistry` serves workspace records to host-side consumers only: the package registers no tools, injects no prompts, and writes no session events, so no request field ever carries this package's data.
|
|
144
|
+
|
|
145
|
+
#### Token effect
|
|
146
|
+
|
|
147
|
+
Zero direct tokens on every request.
|
|
148
|
+
|
|
149
|
+
#### KV Cache effect
|
|
150
|
+
|
|
151
|
+
Independent of live requests: the package never touches a request prefix, so it cannot invalidate provider cache reuse.
|
|
152
|
+
|
|
153
|
+
## Known Limitations and Deferred Work
|
|
154
|
+
|
|
155
|
+
<a id="known-limitations-and-deferred-work"></a>
|
|
156
|
+
|
|
157
|
+
|
|
158
|
+
These limits define when the project list is a poor fit or needs special operational care. They are current package constraints, not a task backlog.
|
|
159
|
+
|
|
160
|
+
- **Removal never deletes data** — removing a project leaves its folder, files, and session histories in place; those sessions become ungrouped, and session deletion or folder removal are separate, absent capabilities ([decision](../../../.agents/notes/implemented/feature/2026-07-27-workspace-registration-deletion.md)).
|
|
161
|
+
- **A session joins only with a recorded directory** — a session belongs to a project only when its record carries a directory that resolves to the project's path; sessions without one stay ungrouped, and a session from another directory cannot be moved in.
|
|
162
|
+
- **External changes are seen late** — if another process deletes or damages a directory, the project reflects it only at the next refresh or restart.
|
|
163
|
+
- **Archiving is one-way** — a hidden session keeps its history and its place, but no unarchive action exists yet; the archive set is a durable display filter.
|
|
164
|
+
- **Re-adding a directory starts fresh** — after removal, adding the same directory again creates a new project with an empty session list; the old sessions do not come back automatically.
|
|
165
|
+
|
|
166
|
+
<a id="dev-note"></a>
|
|
167
|
+
### Dev Note
|
|
168
|
+
|
|
169
|
+
<details>
|
|
170
|
+
<summary>Working context for maintainers — click to expand</summary>
|
|
171
|
+
|
|
172
|
+
This Dev Note is working context for maintainers: open questions and directions that are not decided. It is explicitly non-authoritative — shipped behavior, limits, and accepted rationale live in the sections above, the package code, and the linked Agent Notes.
|
|
173
|
+
|
|
174
|
+
#### Open: the `create(path, title?)` title parameter
|
|
175
|
+
|
|
176
|
+
The `title` parameter has no production caller since the gateway's create-by-name branch was removed; a code TODO proposes dropping the parameter and its `@param` clause together ([note](../../../.agents/notes/implemented/simplification/2026-07-31-one-route-to-add-a-workspace.md)).
|
|
177
|
+
|
|
178
|
+
</details>
|
package/README.zh.md
ADDED
|
@@ -0,0 +1,178 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "面向选择、挂载或排查持久 workspace 记录与会话头校验成员资格的宿主的 Workspace 实体注册表(ctx.workspaceRegistry)说明。"
|
|
3
|
+
kind: "package-reference"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# @deepseek-ai/dsh-workspace
|
|
7
|
+
|
|
8
|
+
[English](README.md) | 中文
|
|
9
|
+
|
|
10
|
+
## 概述
|
|
11
|
+
|
|
12
|
+
`dsh-workspace` 为宿主提供一组持久 workspace:命名用户目录,每个目录带有在其中运行的会话,并在重启之间保持稳定顺序。借助它,UI 可以显示项目侧边栏、把会话附加到正确的项目、把会话从分组中隐藏而不丢失它,以及移除项目——移除绝不会删除文件夹或会话历史,它们变成 Ungrouped。在需要持久项目分组的 GUI 或宿主组合中使用它;headless 与最小运行可以完全省略它。此包只面向宿主侧:模型、工具与 agent loop 永远不会看到它,因此不会增加任何 token、提示词或请求上下文。它需要会话存储与持久化后端一并挂载;设置只需几行组合配置。
|
|
13
|
+
|
|
14
|
+
## 目录
|
|
15
|
+
|
|
16
|
+
- [使用本包](#use-this-package)
|
|
17
|
+
- [理解实现](#understand-the-implementation)
|
|
18
|
+
- [进一步探索](#further-exploration)
|
|
19
|
+
- [模型体验](#model-experience)
|
|
20
|
+
- [已知限制与延期工作](#known-limitations-and-deferred-work)
|
|
21
|
+
- [开发备注](#dev-note)
|
|
22
|
+
|
|
23
|
+
-----
|
|
24
|
+
|
|
25
|
+
<a id="use-this-package"></a>
|
|
26
|
+
## 使用本包
|
|
27
|
+
|
|
28
|
+
使用此包为产品提供项目列表:用户工作的命名目录、每个目录中运行的会话、稳定顺序,以及在不丢失会话的前提下将其隐藏的能力。每项操作背后的 API 约定放在实现章节中。
|
|
29
|
+
|
|
30
|
+
### 何时使用
|
|
31
|
+
|
|
32
|
+
当产品展示持久 workspace 界面——侧边栏、会话分组或需要命名并排序目录的自动化——时使用它。它对模型不可见,因此不增加任何 token 或请求成本。没有分组界面时跳过它;harness 中没有其他包需要它。
|
|
33
|
+
|
|
34
|
+
### 设置
|
|
35
|
+
|
|
36
|
+
此包本身不声明任何配置;它需要会话存储、会话持久化后端,以及保存其记录的存储行。最小组合如下:
|
|
37
|
+
|
|
38
|
+
```yaml
|
|
39
|
+
- name: '@deepseek-ai/dsh-session'
|
|
40
|
+
- name: '@deepseek-ai/dsh-session-persistence-jsonl'
|
|
41
|
+
- name: '@deepseek-ai/dsh-storage'
|
|
42
|
+
- name: '@deepseek-ai/dsh-storage-json'
|
|
43
|
+
- name: '@deepseek-ai/dsh-storage-domain'
|
|
44
|
+
config:
|
|
45
|
+
backend: json
|
|
46
|
+
- name: '@deepseek-ai/dsh-workspace'
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
挂载这些行之后,创建项目会立即出现在列表中并在重启后保留;首次启动还会按会话运行的目录对既有会话分组。如果缺少某个必需依赖,workspace 功能会一直不可用,直到它被挂载。
|
|
50
|
+
|
|
51
|
+
### 创建与排序项目
|
|
52
|
+
|
|
53
|
+
从任何存在的目录创建项目:给出路径和可选标题,项目即出现在列表中,新到旧排列。不存在的路径或文件而非目录会被拒绝,且不会有任何变化;为已有项目的目录再次创建会原样返回现有项目。你可以随时重命名项目,并把它移动到列表中的任意位置:
|
|
54
|
+
|
|
55
|
+
```text
|
|
56
|
+
// Host consumer code, after the composition above is loaded:
|
|
57
|
+
const project = await ctx.workspaceRegistry.create('/path/to/dir', 'My Project')
|
|
58
|
+
await project.setTitle('Renamed')
|
|
59
|
+
ctx.workspaceRegistry.list() // shows the project, newest first
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### 将会话归入项目
|
|
63
|
+
|
|
64
|
+
会话加入它运行目录所在的项目:在项目目录中创建会话,它就会出现在该项目下,新到旧排列。一个会话只能属于一个项目。目录无法校验的会话——没有记录目录,或目录被移动、删除——无法加入,保持 Ungrouped。
|
|
65
|
+
|
|
66
|
+
### 隐藏会话与移除项目
|
|
67
|
+
|
|
68
|
+
当会话不应再出现在分组中时隐藏它:它会从可见列表中消失,但其会话、历史与在项目中的位置都保持不变。项目不再需要时移除它:它离开列表,而其文件夹、文件与会话历史绝不受影响——这些会话变成 Ungrouped。之后再次添加同一目录会从空项目开始,不会带回旧会话。
|
|
69
|
+
|
|
70
|
+
-----
|
|
71
|
+
|
|
72
|
+
<a id="understand-the-implementation"></a>
|
|
73
|
+
## 理解实现
|
|
74
|
+
|
|
75
|
+
<details>
|
|
76
|
+
<summary>实现细节——点击展开</summary>
|
|
77
|
+
|
|
78
|
+
本节解释此功能背后的设计决策,并指出实现它们的代码位置;可观察行为已在[使用本包](#use-this-package)中完整说明。
|
|
79
|
+
|
|
80
|
+
### 设计理念
|
|
81
|
+
|
|
82
|
+
- **每个规范路径一条记录。** `fs.realpath` 是唯一的一套唯一性规范:路径以规范化形式存储,因此指向已被拥有目录的符号链接会与之冲突,唯一性即规范路径的字符串相等。
|
|
83
|
+
- **成员资格是所有权加实时 cwd 事实。** 记录的 `sessionIds` 顺序是所有权真源;启动时的头部索引校验它,`sessionIds` 在读取时过滤,下一次变更持久剪除。
|
|
84
|
+
- **仅读取头部。** 引导与 attach 校验只读取 `SessionHeader` 字段;事件正文绝不加载。
|
|
85
|
+
- **两次写入的变更带显式标记。** 创建与删除在记录/顺序对可能分叉之前先持久化 `pendingMutation` 标记,因此启动只补全被中断的操作,未标记的分叉作为损坏明确报错。
|
|
86
|
+
- **串行化写入。** 注册表操作跑在同一条操作链上;实体变更通过领域写链上的 `table.update` 执行,盖上 `updatedAt` 并在其链槽决定成员资格。
|
|
87
|
+
|
|
88
|
+
### API 行为
|
|
89
|
+
|
|
90
|
+
该 API 是一个由两个所有者构成的小家族:`WorkspaceRegistry` 负责创建、排序与删除项目并管理其会话记账;`Workspace` 实体暴露显示标题、目录状态与会话投影。各方法的精确约定在代码中,而非本 README——参见 [src/index.ts](src/index.ts) 与 [src/entity.ts](src/entity.ts)。
|
|
91
|
+
|
|
92
|
+
### 源码地图
|
|
93
|
+
|
|
94
|
+
| 文件 | 职责 |
|
|
95
|
+
|---|---|
|
|
96
|
+
| [`src/index.ts`](src/index.ts) | 插件入口:`WorkspaceRegistry` 服务、头部索引、引导、操作串行化 |
|
|
97
|
+
| [`src/entity.ts`](src/entity.ts) | 包私有 `Workspace` 实现及其唯一的 `mutate` 写入路径 |
|
|
98
|
+
| [`src/spec.ts`](src/spec.ts) | 领域声明:记录 schema、注册表状态、`defineDomain` 规范 |
|
|
99
|
+
| [`src/types.ts`](src/types.ts) | 公开 `Workspace` 接口与 `WorkspaceId` 品牌 |
|
|
100
|
+
| [`src/paths.ts`](src/paths.ts) | `realpath` 唯一性规范 |
|
|
101
|
+
| [`src/invariant.ts`](src/invariant.ts) | 不变式伴生插件:实体缓存镜像持久表 |
|
|
102
|
+
|
|
103
|
+
### 持久形态
|
|
104
|
+
|
|
105
|
+
注册表打开 `workspace` 领域(版本 2):一张以 `WorkspaceId` 为键的 `workspaces` 表,加上一个持有 `workspaceIds`(权威显示顺序)、`archivedSessionIds` 与可选 `pendingMutation` 标记的全局状态。在 `archivedSessionIds` 存在之前写入的记录会通过 schema 默认值解析为空集合。
|
|
106
|
+
|
|
107
|
+
### 生命周期
|
|
108
|
+
|
|
109
|
+
启动时,注册表打开领域、若存在标记则补全被标记的变更、校验已存状态——重复路径、重复会话账本与顺序漂移都会明确报错——并在尚未初始化时先凭持久化头部引导历史、最后写入已初始化标记,因此被中断的引导可以安全恢复。全新空注册表一旦初始化即为真,绝不会再次引导。
|
|
110
|
+
|
|
111
|
+
### 失败与恢复
|
|
112
|
+
|
|
113
|
+
创建或删除的第二次写入失败时,缓存与先前顺序会回滚;当操作与回滚都失败时,持久标记仍指明被中断的操作,下一次启动会补全或回滚它。已提交的删除即使标记清理失败仍报告成功,下一次启动会幂等地清除该标记。
|
|
114
|
+
|
|
115
|
+
### 不变式
|
|
116
|
+
|
|
117
|
+
`workspace-invariant` 伴生插件注册归属关系:`workspaces` 表的每个持久 `domain/changed` 都必须指向实体缓存已持有的记录——只有在注册表从缓存移除实体之后删除才有效,因此绕过注册表的写入路径会触发不变式失败。
|
|
118
|
+
|
|
119
|
+
</details>
|
|
120
|
+
|
|
121
|
+
-----
|
|
122
|
+
|
|
123
|
+
<a id="further-exploration"></a>
|
|
124
|
+
## 进一步探索
|
|
125
|
+
|
|
126
|
+
当本包的视角不够用时阅读以下页面:子系统参考是权威的功能约定,Agent Note 记录了项目为何从会话历史起步、以及移除为何是非破坏性的。
|
|
127
|
+
|
|
128
|
+
- [Workspace 子系统](../../../docs/subsystems/workspace.zh.md)——项目及其会话的功能约定,以及 workspace 服务的生成 API。
|
|
129
|
+
- [Workspace 包映射](../README.zh.md)——本组唯一的包及其仓库位置。
|
|
130
|
+
- [领域 KV 存储 Agent Note](../../../.agents/notes/proposed/architecture/2026-07-24-domain-kv-storage-and-workspace.zh.md)——为什么项目记录使用领域数据形式。
|
|
131
|
+
- [Workspace UI 产品流 Agent Note](../../../.agents/notes/implemented/feature/2026-07-25-workspace-ui-product-flow.zh.md)——首次启动如何从会话历史构建项目,以及 GUI 如何排序。
|
|
132
|
+
- [删除 Workspace 注册记录决策](../../../.agents/notes/implemented/feature/2026-07-27-workspace-registration-deletion.zh.md)——为什么移除项目绝不会删除其文件夹或会话。
|
|
133
|
+
|
|
134
|
+
-----
|
|
135
|
+
|
|
136
|
+
<a id="model-experience"></a>
|
|
137
|
+
## 模型体验
|
|
138
|
+
|
|
139
|
+
### Workspace 记录与会话账本
|
|
140
|
+
|
|
141
|
+
#### 模型看到什么
|
|
142
|
+
|
|
143
|
+
没有。`ctx.workspaceRegistry` 只向宿主侧消费方提供 workspace 记录:此包不注册工具、不注入提示词、不写入会话事件,因此没有请求字段会携带此包数据。
|
|
144
|
+
|
|
145
|
+
#### Token 影响
|
|
146
|
+
|
|
147
|
+
每个请求的直接 token 为零。
|
|
148
|
+
|
|
149
|
+
#### KV Cache 影响
|
|
150
|
+
|
|
151
|
+
与实时请求无关:此包绝不触及请求前缀,因此不会使提供方缓存复用失效。
|
|
152
|
+
|
|
153
|
+
## 已知限制与延期工作
|
|
154
|
+
|
|
155
|
+
<a id="known-limitations-and-deferred-work"></a>
|
|
156
|
+
|
|
157
|
+
|
|
158
|
+
这些限制说明项目列表何时不合适,或何时需要特别的运维注意。它们是当前包约束,不是任务积压。
|
|
159
|
+
|
|
160
|
+
- **移除绝不删除数据**——移除项目会保留其文件夹、文件与会话历史;这些会话变成 Ungrouped,而会话删除与文件夹移除是彼此独立且尚未提供的功能(参见[决策记录](../../../.agents/notes/implemented/feature/2026-07-27-workspace-registration-deletion.zh.md))。
|
|
161
|
+
- **只有带记录目录的会话才能加入**——只有记录中带有可解析为项目路径的目录的会话才属于项目;没有目录的会话保持 Ungrouped,来自其他目录的会话无法移入。
|
|
162
|
+
- **外部变更延迟可见**——如果另一进程删除或损坏目录,项目只能在下次刷新或重启后反映出来。
|
|
163
|
+
- **归档是单向的**——被隐藏的会话保留其历史与位置,但目前没有取消归档操作;归档集合是持久的显示过滤器。
|
|
164
|
+
- **重新添加目录从空开始**——移除后再次添加同一目录会创建空会话列表的新项目;旧会话不会自动回来。
|
|
165
|
+
|
|
166
|
+
<a id="dev-note"></a>
|
|
167
|
+
### 开发备注
|
|
168
|
+
|
|
169
|
+
<details>
|
|
170
|
+
<summary>维护者的工作上下文——点击展开</summary>
|
|
171
|
+
|
|
172
|
+
本开发备注是维护者的工作上下文:开放问题与尚未决定的探索方向。它明确不具权威性——已交付的行为、限制与既定理由以上文、包代码和相关 Agent Note 为准。
|
|
173
|
+
|
|
174
|
+
#### 开放:`create(path, title?)` 的 title 参数
|
|
175
|
+
|
|
176
|
+
网关的按名称创建分支移除后,`title` 参数已无生产调用方;代码中的 TODO 提议把该参数与其 `@param` 子句一并移除(参见[笔记](../../../.agents/notes/implemented/simplification/2026-07-31-one-route-to-add-a-workspace.zh.md))。
|
|
177
|
+
|
|
178
|
+
</details>
|