Feature request: git workspace status next to the composer input (DSH ↔ Claude Desktop parity)

[mvpereira-git]

Feature request — git workspace status next to the composer input (DSH ↔ Claude Desktop parity)

Summary

Expose the workspace git state (branch, ahead/behind vs upstream, uncommitted count, last push) inline next to the composer input line, matching Claude Desktop's placement of workspace-level status near the input.

Context (measured)

• Environment channel: GitHub Issues are disabled on deepseek-ai/deepseek-harness and external PRs are not accepted (CONTRIBUTING.md), so this is posted as a feature-request discussion.
• Measured on the installed dsh-desktop v0.7.1 prebuilt bundle: no git-status provider/UI exists in the compiled client libs (@deepseek-ai/dsh-client-ui-*), the served web dist, or the desktop host. The only occupant of the input-adjacent conversation.composer.dock slot (StatsLine, id stats, order 0) shows token statistics only (turns/steps/LLM/tool durations).
• Corroborated at source level on current master (cd5ef814): a grep over packages/ for git-status terms finds no provider/UI — only incidental prose (e.g. "write-behind", "uncommitted tail"). No git provider exists in the source tree.

So the premise that "DSH already shows git push/commit/state in the header above the input" is not corroborated in v0.7.1 nor in current master; the maintainers are the ones to adjudicate whether this belongs in the product. This request proposes the feature rather than a reposition.

Proposed behavior

1. Provider (host-side): read-only git state per workspace — current branch, ahead/behind vs upstream, dirty/clean count, last push. No mutation.
2. UI: a compact chip in the composer region. Measured mount options:
   • conversation.input.dock — rendered above the input bar (closest to the Claude Desktop inline position);
   • conversation.input.left/right — inside the input row;
   • conversation.composer.dock — co-located with the existing StatsLine.
3. Fallback: if the workspace is not a git repo, nothing renders; no console noise.

Suggested acceptance (for the maintainer)

• Repo with unpushed local commits: chip shows the ahead count next to the input.
• Clean repo: shows branch + "clean" (or hidden, at maintainer discretion).
• Non-git workspace: renders nothing; no errors in the console.

Reference measurements

Reproducible path:line table (MEASURED / RECONSTRUCTED / NOT MEASURED tags) plus the full upstream-ready change package (item 1: subagents details panel; item 2: this request; item 3: umbrella layout direction) live in the workspace dsh-ux-parity-upstream/ (verified-measurements.md is the measurement table). Slot anchors measured: conversation.composer.dock (list, session), conversation.input.left/right, conversation.session.header.utilities.

Not in scope (deliberately)

• No provider is fabricated here — this report measures the absence; implementation belongs upstream.
• No external mutation beyond this discussion; the workspace commit stays local pending owner approval.

[liyangbing]

这个功能适合作为只读 workspace capability，但建议把“显示一个 chip”和“状态可作为 Agent 证据”分开定义：

• host 端返回结构化快照：workspace identity、repo root、branch/HEAD、upstream、ahead/behind、dirty count、detected-at、source revision 和 provider error；UI 只渲染快照，不在浏览器端执行 git。
• 快照必须绑定 workspace/session/generation。切换 workspace、branch 或重启 host 后，旧状态不能继续显示在新 composer 上；刷新期间明确标记 stale/unknown，不要把上一次 clean 当成当前 clean。
• ahead/behind 需要声明比较对象和失败分支：没有 upstream、detached HEAD、浅克隆、无权限、非 git 目录、仓库正在 rebase/merge、submodule 或巨型 worktree。不要把“无法比较”渲染成 0。
• 这个 provider 应只读。commit/push/checkout 等动作若未来加入，必须是独立的显式授权路径，不能因点击 chip 或自然语言提示隐式执行。
• 验收覆盖 dirty/unpushed/behind/diverged、非 git workspace、远端不可达、并发刷新、workspace 删除、Session 切换和冷启动恢复；记录 snapshot ID、HEAD、comparison ref、更新时间、错误码和最终 UI 状态。
• 如果状态是给 Agent 提示使用，还应把它作为带 source/time 的 context，而不是无 provenance 的 system text；模型不能依据旧快照宣称“已 push”。

独立社区手册有相关的 workspace/session evidence 与只读边界整理：https://sandbaseai.github.io/deepseek-harness-handbook/workspace-write-shared-cache.html 和 https://sandbaseai.github.io/deepseek-harness-handbook/live-session-log-durability.html 。手册不是官方 DeepSeek AI 项目。

[argszero]

Source verification of both measurements against current master (cd5ef81481, 0.1.2-alpha.1):

1. "No git provider in the tree" — CONFIRMED. Grep over packages/*/*/src for git status/branch/dirty/ahead handling finds no provider or UI. The only git status occurrences are example commands in shell tool descriptions (tool-bash/src/index.ts:252, tool-pwsh/src/index.ts:262 — "Show working tree status" as a description of what git status does, not a git capability). No service, no workspace-level git read, no UI chip.

2. The measured dock slots — CONFIRMED, with one correction. All four anchors exist in packages/client/ui-conversation/src/client/contract/slots.ts, each kind: 'list'; scope: 'session':

• conversation.input.dock (:127) — full-width above the composer card
• conversation.composer.dock (:131) — ambient entries below the composer card
• conversation.input.left (:133) / conversation.input.right (:135) — compact controls in the composer tool row

Correction: your summary says the only occupant of conversation.composer.dock is StatsLine (id stats, order 0). In this tree that slot is a list slot with no fixed StatsLine registration visible in the slots contract — the stats line is registered elsewhere (rendered via the renderer/ui-slots machinery), so the slot is not "occupied" by a hard-coded component in the contract. That actually helps your proposal: it is an open list slot, not a taken one. (conversation.input.dock is the closest to Claude Desktop's inline placement, matching your assessment.)

3. A plugin-shaped path exists today. packages/client/ui-slots exposes a register API (kind keyed dispatch, list slots with priority/order semantics — the same machinery StatsLine-style entries use). A community plugin could deliver this feature without waiting for upstream adjudication: host-side read-only git state (branch, ahead/behind, dirty count via git status --porcelain=v2 or direct .git read — no mutation), client-side chip mounted into one of the measured slots with the non-git-workspace fallback you specify. The one thing to verify before building is the third-party client plugin channel — whether a published package can register into the client slot registry or whether client-side contributions are limited to bundled code. If you're interested, I can prototype this against the measured slots as a standalone plugin (it would also give maintainers a working reference implementation for the upstream feature).

Your measured-absence framing is the right one for this repo (issues/PRs disabled, per CONTRIBUTING) — this keeps the feature request on record while the plugin path gives users something installable in the meantime.

[argszero]

Follow-up: the third-party client plugin channel I flagged as the open question is open — verified at source on the same revision (cd5ef81481).

A published package can reach the client slot registry today. The chain:

1. A package declares "dsh": { "client": { ... } } in its package.json — the schema (DshClientDeclaration, packages/client/modules/src/index.ts:55-69) supports inject / platform / immediately / external. In-tree example: packages/client/ui-conversation/package.json:32-45 (platform: "web", injects its UI service dependencies).
2. The package is mounted as an ordinary Loader entry (user-layer cordis.patch.yml insert, same as any plugin).
3. The client-modules node half scans the host Loader's entries for dsh.client declarations ("scans the host Loader's entries for packages declaring dsh.client", index.ts:2-3), builds the package's client bundle into the web boot graph, and serves it.
4. The browser boot (packages/client/web/src/boot.ts:113-135) loads every manifest row through its own client-side Cordis Loader and audits activation.
5. The frozen module table (packages/client/web/src/seed.ts) exposes @deepseek-ai/cordis, @deepseek-ai/dsh-client-store, @deepseek-ai/dsh-client-ui-slots, and @deepseek-ai/dsh-client-ui-primitives as externals — so a client plugin can call the same ui-slots register API the built-in UI uses.

So the git-status chip is implementable as a standalone plugin: node half reads git state, client half (declaring dsh.client) mounts the chip into the measured slot. The one remaining design piece is the node→client data bridge — the client half gets host data the same way the built-in client packages do (injecting an API service that talks to the host; there is no direct host-fs access from the browser). Your "UI only renders the snapshot" boundary (@liyangbing's point about not running git in the browser) aligns with this: the node half produces the snapshot, the client half only renders it.

I'll take a first pass at prototyping this as a standalone plugin (it gives maintainers a working reference implementation for the upstream feature request). If you want to coordinate the snapshot shape, the structured fields you listed are a good baseline.

[argszero]

The reference implementation I offered in the follow-up is now published: @argszero/cordis-plugin-git-status@0.1.0 (source).

It implements the exact channel verified above:

• Node half polls git status --porcelain=v2 --branch (read-only — no mutation commands are ever executed) and serves a summarized snapshot over an SSE channel (/plugins/git-status), pushing a new frame only when the status changes.
• Client half declares dsh.client in package.json, gets bundled into the web boot graph by client-modules, and registers a chip on the measured conversation.composer.dock slot via the same ctx.slots.register API the built-in StatsLine uses. The browser never runs git — it only renders the snapshot, matching the "UI only renders the snapshot" boundary.
• Non-git fallback: a directory that is not a git repository renders nothing (typed not-a-repo frame — no crash, no spam).

Usage — mount as a normal user-layer plugin:

plugins:
  '@argszero/cordis-plugin-git-status':
    root: /path/to/repo   # optional; default: dsh process cwd
    intervalMs: 5000      # optional; poll interval (min 500)

The chip renders branch ↳ ↑ahead ↓behind ●dirty-count right next to the composer input.

This is a standalone community plugin (the upstream PR channel is disabled, so this is the delivery path), deliberately built as a working reference implementation for the upstream feature request: same snapshot shape, same slot anchor. If maintainers adopt it upstream, the structured fields from your measurement table are a natural baseline — happy to align the snapshot shape if you want to coordinate.