Problem
Five codebases implement overlapping file/link/metadata functionality, and the same capabilities keep getting rebuilt because no layer contract says where each belongs:
- dazzlelink (tool) reimplements UNC<->drive mapping, path normalization, timestamp/attribute handling, and checksums -- all of which exist in
dazzle-filekit/unctools. Its own issue tracker contains a filed-but-unexecuted plan to delegate.
- preservelib exists only embedded inside the
preserve CLI, plus two drifting vendored copies (safedel, ghtraf). The canonical copy carries a stale 883-line metadata.py and a known junction-detection bug that dazzle-filekit already fixed.
- Junction and hardlink creation exist only in preservelib (via
cmd /c mklink -- a known-bad pattern); dazzle-filekit, the declared primitives home, has neither.
- A latent dependency cycle: filekit's
create_symlink soft-imports dazzlelink, while dazzlelink plans to depend on filekit.
- Name collisions with different semantics across libraries (
get_path_type, normalize_path).
Proposed solution
A five-domain layered stack with one home per capability and dependencies that only point down:
| Layer |
Domain |
Library |
| L0 |
Path identity (UNC<->drive, origin) |
unctools |
| L1 |
Filesystem primitives (one object, one op, every OS) |
dazzle-filekit |
| L2 |
Link serialization (.dazzlelink as portable data) |
dazzlelinklib (extracted from the dazzlelink tool) |
| L3 |
Operation orchestration (manifest, verify, policy) |
preservelib (new repo, dist dazzle-preservelib) |
| ⊥ |
Traversal engine (orthogonal) |
dazzletreelib |
Rules: every capability has exactly one home; sibling imports are real dependencies (graceful fallback reserved for platform capability only); libraries live in DazzleLib, CLI tools in DazzleTools and consume the libraries.
The full class map, capability-ownership table, Mermaid dependency chain, and open decisions live in the STACK-MAP golden-rule document (maintained privately while iterating; graduates to this org repo on design freeze).
Phases
Acceptance criteria
Related
- DazzleLib/dazzle-filekit (L1 home;
docs/preservelib-integration.md + docs/unctools-integration.md are the prior partial contracts this generalizes)
- DazzleLib/UNCtools, DazzleLib/dazzle-tree-lib
- DazzleTools/preserve, DazzleTools/dazzlelink (extraction sources)
Problem
Five codebases implement overlapping file/link/metadata functionality, and the same capabilities keep getting rebuilt because no layer contract says where each belongs:
dazzle-filekit/unctools. Its own issue tracker contains a filed-but-unexecuted plan to delegate.preserveCLI, plus two drifting vendored copies (safedel, ghtraf). The canonical copy carries a stale 883-linemetadata.pyand a known junction-detection bug thatdazzle-filekitalready fixed.cmd /c mklink-- a known-bad pattern);dazzle-filekit, the declared primitives home, has neither.create_symlinksoft-imports dazzlelink, while dazzlelink plans to depend on filekit.get_path_type,normalize_path).Proposed solution
A five-domain layered stack with one home per capability and dependencies that only point down:
unctoolsdazzle-filekitdazzlelinklib(extracted from the dazzlelink tool)preservelib(new repo, distdazzle-preservelib)dazzletreelibRules: every capability has exactly one home; sibling imports are real dependencies (graceful fallback reserved for platform capability only); libraries live in DazzleLib, CLI tools in DazzleTools and consume the libraries.
The full class map, capability-ownership table, Mermaid dependency chain, and open decisions live in the STACK-MAP golden-rule document (maintained privately while iterating; graduates to this org repo on design freeze).
Phases
legacy/, pyproject layout), publish 0.7.0_libjunction), ghtraf (unvendors), csb (manifest-based recovery tier), dazzlelink toolAcceptance criteria
Related
docs/preservelib-integration.md+docs/unctools-integration.mdare the prior partial contracts this generalizes)