# Project Workbench

<p>
  <a href="README.md"><img src="https://img.shields.io/badge/%E4%B8%AD%E6%96%87-%E9%BB%98%E8%AE%A4-1677ff?style=for-the-badge" alt="Chinese documentation"></a>
  <a href="README.en.md"><img src="https://img.shields.io/badge/English-Documentation-30363d?style=for-the-badge" alt="English documentation"></a>
</p>

For the design and product boundary, see [docs/design.md](docs/design.md).

Project Workbench is a local bundle compatible with ordinary DeepSeek Harness Web profiles and DSH Desktop. It adds a full-height workbench column beside the existing sidebar and groups native conversations as `project → requirement group → conversation` without replacing the sidebar, conversation view, or composer.

## Problems addressed

- One development requirement often needs separate conversations for analysis, implementation, and verification, but native conversations do not share its context. Switching conversations therefore repeats the work of establishing background and changes.
- The native sidebar organizes conversations by workspace and time, making a requirement's status, related conversations, and remaining work difficult to see together.
- Project management must preserve the existing development flow rather than covering or replacing the native workspace, session navigation, or composer.

## Design principles

- Add a separate column to the existing Web interface. The native UI continues to own workspaces, sessions, and chat, while the workbench owns requirement groups and their metadata.
- Use the `project → requirement group → conversation` hierarchy to collect native conversations for one requirement, and summarize in-progress, review, and completed requirements at the top.
- Each requirement group keeps local summary, changes, and evidence layers. The summary enters the next request in a group conversation automatically; the other layers are read only when the user opens or copies them, so unrelated detail is not added to every request.
- Keep the workbench local and single-user. Archiving a requirement group archives its linked native conversations first, keeping the workbench list consistent with the native session state.

## Screenshots

### Projects and requirement groups

![Project picker, requirement groups, and group conversations](docs/images/project-workbench-overview.en.png)

### Progressive group memory

![Summary, changes, and evidence layers for group memory](docs/images/project-workbench-memory.en.png)

### Collapsed state

![Collapsed Project Workbench entry](docs/images/project-workbench-collapsed.en.png)

## Install

The plugin requires a profile that includes `@deepseek-ai/dsh-web-app`.

```powershell
pnpm dsh plugin --profile web add ./plugins/dsh-project-workbench
pnpm dsh --profile web
```

The profile loads this bundle after its existing Web bundle. The browser discovers `client.js` from the `dsh.client` declaration and registers one `shell.overlay` entry.

## Compatibility

- Ordinary DSH Web profiles and DSH Desktop use the same bundle, Web route, client metadata, and slot. The plugin does not depend on Electron APIs or declare Desktop services as top-level required dependencies.
- In Desktop, the plugin uses the public `desktopProfiles.current.dir` to store state in `project-workbench/state.json` beneath the active profile. Ordinary DSH continues to use the same path below `$DSH_HOME` (default: `~/.dsh`).
- A headless profile without `webServer` can still load the Host plugin, but it does not expose the workbench UI or its local state route. Use a profile that includes `@deepseek-ai/dsh-web-app` to manage requirement groups.

## Features

- The workbench occupies its own column to the right of the native sidebar and reserves the same width in the center conversation column. The native sidebar, workspace list, and conversation list remain visible and usable. The Project Workbench entry above Settings remains available; it has an active state while expanded and toggles the workbench when selected.
- The project selector reads existing native workspaces through a keyboard-operable workbench menu. A project can contain multiple requirement groups, each with its own status, group-to-session links, and three memory layers persisted in the local DSH data directory; browser storage is an offline cache and migration source for older data.
- The plus button in the requirement-group heading expands an in-workbench name field rather than a browser prompt. The edit button at the end of each requirement group can rename the group, control its status, or archive it. Archiving has an in-workbench confirmation, first archives its native conversations, and then hides the requirement group. Creation, attachment, and archive failures are shown in the panel with a recovery path.
- Labels follow the current DSH interface language automatically; changing that language does not require a plugin restart.
- Selecting a group lists its linked native conversations. Selecting a conversation uses the native session navigator. Creating a group conversation uses the native workspace session flow and then records the returned session in the selected group.
- Group memory has three independently revealed layers: summary, changes, and evidence. The panel opens one layer at a time; the summary enters the next model request in a group conversation automatically, while changes and evidence remain available for intentional reading, copying, or pasting.
- Archiving a requirement group first archives every linked native conversation through the host API. The group leaves the default list only after every archive succeeds; if any archive fails, the group remains visible so the operation can be retried.

## Model experience

Before the first model step in a group conversation, the host adds the current group summary as a source-attributed context message. The message enters the session log and the model request with the user’s current input. A summary revision is added once on the next request; the same revision is not duplicated. If the summary conflicts with the user’s current request, the current request takes precedence.

Changes and evidence remain progressive disclosure: they are not injected automatically, so a request does not carry unrelated detail by default.

## Known limitations and future work

- This is a local, single-user workbench. Its data is stored on the current device in the DSH data directory and is not shared with another device or user.
- The public overlay slot does not expose the native sidebar width. The plugin measures the first frame column to align its overlay; a host-provided overlay anchor would remove that DOM-layout dependency.
- The external API does not expose a composer draft insertion action. The summary uses session context; progressive layers remain available for copying into the native composer.