SDWS & SnapDock Integration

Historical Concept

Earlier DocsHub material described SDWS (SnapDock Workspace Snapshot) as a JSON manifest that would let a SnapBoard column hand a group of file references and display names to SnapDock. It proposed combining a board title, column title, and the file paths attached to cards so planning in SnapBoard could lead into writing in SnapDock.

That material described two intended workflows: save an .sdws file for later import, or hand a generated workspace directly to SnapDock. These were design descriptions, not behavior delivered by the archived application.

What the Source Audit Found

Across the final tree and locally available Git history, no implementation evidence was found for:

• SDWS constants, schema definitions, generation, parsing, or serialization;
• .sdws file dialogs or import/export controls;
• conversion of a board or column into a workspace;
• SnapDock process launching or direct hand-off;
• IPC channels for SnapDock integration;
• tests or fixtures for an interchange format;
• .sb board import/export.

SnapBoard did store one absolute file reference on a card, which could have supplied input to such a design. That storage capability alone did not constitute an interchange protocol.

Status at Archival

The repository README described optional SnapDock integration as a long-term direction. Package metadata also called SnapBoard a companion app, reflecting its positioning rather than an implemented connection. The code provided no integration boundary beyond local card data.

The example schema and claims of single-column export in the former documentation cannot be treated as a stable or implemented specification. They are intentionally not reproduced as a usable format here, because doing so could imply compatibility that never existed.

SnapBoard and SnapDock remained separate applications when SnapBoard was archived. See the current SnapDock documentation for supported SnapDock workspace and file behavior.