UI & integration FAQ
dsh-filesnap is a DeepSeek Harness Web UI rewind and redo plugin. It provides a rewind control beside completed assistant turns, coordinates conversation forks with tracked-file recovery, and provides session-level redo and status actions. Its storage engine is the separate Rust package filesnap.
We maintain dsh-filesnap. Reviewed 2026-09-10, using dsh-filesnap 0.2.2 source and the explicitly named evidence below. This page separates observable capabilities, configured checks and claims that would require additional measurements.
Does dsh-filesnap have a Web UI?#
Yes. In 0.2.2, the client registers a per-turn rewind control in DSH's conversation.chat.assistant-actions slot, plus redo/status actions in conversation.session.header.actions. The package manifest declares a browser integration and client service dependencies.
The browser handler asks DSH to fork at the selected conversation boundary, invokes file recovery into that child, and opens the resulting conversation. A typed command has a different navigation path: it returns the child session ID, which you may need to open yourself. Separating storage into a Rust engine does not remove these UI actions.
Sources: 0.2.2 client registration and navigation, published manifest.
Does FileSnap understand DSH conversations and turns?#
The dsh-filesnap plugin connects DSH turns, conversations and file recovery. It captures on agent/pre-step, observes filesystem write/edit intents, maps restore points to conversation boundaries and coordinates fork, restore and redo. You select a DSH recovery point; you do not manually match an unrelated backup timestamp to a conversation.
The standalone filesnap engine owns file content, manifests and recovery operations. The TypeScript DSH integration owns host events, commands, browser controls and conversation navigation. This is a division of responsibilities within the product, not a distinction between one plugin having conversation integration and the other lacking it. Host integration, architecture.
Can I rewind directly inside DSH chat?#
Yes: click the rewind control in the DSH conversation UI. You stay in the DSH application; the handler creates and opens a child conversation while preserving the original. Direct UI operation and keeping the same session ID are different properties. The current implementation provides the former and deliberately forks for the latter.
Does in-place rewind mean deeper integration?#
In-place and fork-based rewind describe where the user continues. They do not measure integration depth. SiriLee's dsh-rewind-plugin provides an in-place workflow with message-text refill; FileSnap preserves the original conversation, continues in a child and supports /redo.
Both integrate with DSH conversations and UI. FileSnap's conversations share one physical workspace. Compare the user-visible behavior and recovery boundaries rather than inferring capability from the absence or presence of a fork. Versioned comparison.
Is FileSnap a disk-level or block-level deduplication tool?#
The FileSnap engine uses application-level, whole-file content addressing. It hashes complete file bytes with SHA-256 and stores content objects referenced by snapshots. It does not deduplicate storage-device blocks or take a full-disk image.
The DSH plugin supplies the conversation/turn association. The content store can reuse retained identical bytes across paths, non-adjacent versions, sessions and workspaces in one data directory. Turn integration and content reuse are complementary responsibilities; being keyed to a turn does not, by itself, make deduplication more effective. See the seven reproduced storage cases, including ties and workload limits.
What DSH compatibility is actually documented?#
| Evidence | Exact scope |
|---|---|
| Existing screenshots and walkthrough | Plugin 0.2.2; recorded Web UI example on DSH 0.1.2-rc.1 |
| Repository CI configuration | Checks out dsh-v0.1.2-rc.1; configures type checks, tests, host build and client build |
| This review | Source/document review; no fresh DSH compatibility test or CI-run result was collected |
| Other host releases, including 0.1.3 | Not verified by this review; require a specific version and successful run before claiming support |
The versioned CI workflow identifies a configured target. Configuration is not a successful run. Release count alone cannot demonstrate compatibility, nor identify which host changes a plugin actually handles.
Uninstalling the plugin does not delete conversation logs or workspace files. Sessions with plugin records currently require reinstalling before reopening in DSH. Source-checkout startup can encounter the event-registration issue described in troubleshooting.
Do an awesome-list entry and trusted publishing prove a more active community?#
They answer different questions. A directory entry establishes discoverability. Release provenance concerns where an artifact came from. Community activity requires comparable observations such as independent contributors, issue-response times and user reports over a stated period. None is a substitute for all the others.
The 0xsline ecosystem list already describes FileSnap as rewinding conversations and the workspace together with fork/redo. A listing or a maintainer's post in an upstream Discussions area is not, on its own, an official endorsement or a comparative quality ranking.
FileSnap also has a release workflow: it builds against a pinned host, builds the browser bundle and declares OIDC permissions for publication. The manifest defines prepublication checks. Those sources demonstrate the configured process; this review does not independently verify npm publisher settings or attestations for each release, or rank either project's community activity.
Where has the design been used beyond DSH?#
The snapshot design originated in our published codex-rewind distribution. The standalone engine now powers dsh-filesnap and Pi's pi-better-rewind-redo. Codex retains a related inlined implementation; DSH and Pi use different engine versions. These are concrete integration and release experiences. Package versions, source relationships and validation scope.