Active architecture

Workspace

• apps/cli — current dits binary and reusable library modules.
• packages/dits-core — shared deterministic chunking and hashing engine.
• apps/web — website, docs, and local playground surfaces.
• packages/npm — package launcher and platform binary layout.
• legacy/backend-crates — historical research, excluded from the root workspace.

Trust core

Object identity, serialization, verification, atomic storage, manifest reconstruction, commit graphs, and ref updates form one local trust core. Commands and future transports should call those semantics rather than define competing formats or verification rules.

Current modules

• core — repository model, index, refs, and commits.
• store — local objects and chunks.
• commands — CLI handlers and presentation.
• mp4 — selected ISOBMFF/MP4 parsing and round-trip paths.
• facr, proxy, segment, vfs — experimental media and access paths.
• security — local advisory locks and audit inspection, plus a disabled legacy encryption experiment.
• metadata, dependency, lifecycle — local asset metadata and lifecycle experiments.
• p2p — scaffolding only; no peer repository transfer.

Dependency direction

Persistent object rules belong in reusable library code. CLI parsing and terminal output remain at the command boundary. Media adapters may emit domain records but must preserve exact source identity. A future remote exchanges the same verified objects and updates refs through the same transaction rules.

Architecture gates

1. Crash-safe local writes and recovery.
2. Versioned deterministic objects and manifests.
3. Bounded-memory ingest, packs, indexes, and trees.
4. Semantic media records proven on real workflows.
5. A transport-independent remote protocol and conformance suite.

The detailed authority lives in the repository’s active architecture, technical foundations, and status and roadmap.