@vrtmrz/livesync-commonlib 0.1.41 → 0.1.43

package/docs/conflict-resolution.md

@@ -30,17 +30,17 @@ After the conflict is resolved, the deleted losing branch and no-longer-needed m
 
 Commonlib follows these rules:
 
-- compare file content byte-for-byte; a path, size, modification time, or revision generation is not proof of identity;
+- never treat a path, size, modification time, or revision generation as proof of content identity;
 - use the nearest `available` revision shared by both leaves as the base for three-way merge;
 - retain a manual conflict when the common revision or a required body is missing or compacted;
-- recognise an unchanged file by comparing its bytes with its exact readable file-reflection provenance;
+- recognise an unchanged file through its exact readable file-reflection revision or the saved SHA-256 hash and byte length of that snapshot;
 - save a genuine edit as a child of that recorded revision, even when a newer database winner exists;
 - deduplicate unknown-origin content against current non-deleted leaves, preserving differing content as a fresh independent root under the same document ID; and
 - never select the newest modification time as a package-level default.
 
 Ordinary saving and incoming reflection share this classification. A historical byte match alone cannot distinguish an unchanged stale file from an intentional revert, and a prefix or suffix relationship does not prove which version the user edited. Unknown-origin content must not acquire an inferred parent from the current winner or its parent.
 
-After a resolution has propagated, an exact recorded revision can still identify unchanged content below a deleted losing leaf. The resolved winner may replace those bytes under the existing reflection policy. If the recorded body is unavailable, the file follows the conservative unknown-origin path. General history-query helpers remain available for callers with separate contracts, including existing deletion and rename recovery; ordinary save and overwrite protection do not scan all historical bodies.
+After a resolution has propagated, an exact recorded revision can still identify unchanged content below a deleted losing leaf. The resolved winner may replace those bytes under the existing reflection policy. If neither the recorded body nor valid matching content evidence is available, the file follows the conservative unknown-origin path. General history-query helpers remain available for callers with separate contracts, including existing deletion and rename recovery; ordinary save and overwrite protection do not scan all historical bodies.
 
 ## Resolution classes
 
@@ -51,10 +51,11 @@ After a resolution has propagated, an exact recorded revision can still identify
 | One side deletes content which the other leaves unchanged                       | Preserve the deletion.                                                      |
 | One side deletes content which the other modifies                               | Retain a manual conflict.                                                   |
 | A receiving file matches its exact readable recorded revision                   | Apply the propagated result under the existing conflict policy.             |
+| A receiving file matches its saved content hash and byte length                 | Apply the propagated result under the existing conflict policy, even after its recorded revision is pruned. |
 | A receiving file differs from its readable recorded revision                    | Preserve the edit as a child of that revision.                              |
 | Origin is unknown and no current non-deleted leaf matches                        | Preserve a fresh independent root for host conflict resolution.             |
 | Origin is unknown and current non-deleted leaves already contain the bytes       | Avoid duplicate storage; infer provenance only for a unique match.          |
-| A body or common ancestor is missing or compacted                               | Retain a manual conflict.                                                   |
+| A required merge body or common ancestor is missing or compacted                | Retain a manual conflict.                                                   |
 | Content is binary or otherwise not semantically mergeable                       | Leave the selection policy to the host; Commonlib cannot infer user intent. |
 
 ## Stale and concurrent resolutions
@@ -76,12 +77,20 @@ A host must not apply a dialogue result after either compared revision has cease
 The compatibility implementation accepts an injected, device-local `FileReflectionProvenance` capability owned by the database-to-storage composition rather than by a filesystem adapter. Maintained hosts persist:
 
 ```text
-path -> { revision, observedStorageMtime? }
+path -> { revision, observedStorageMtime?, contentHash?, contentSize? }
 ```
 
 `revision` is the exact database revision most recently saved from or reflected in this device's storage. It identifies the base for subsequent local edits, rather than certifying that the current file still contains those bytes. `observedStorageMtime` is the raw modification time of the saved snapshot or the file observed after reflection. It is neither rounded nor compared across devices, and it is diagnostic only: revision identity never comes from a timestamp, path, size, or content hash.
 
-The record is updated only after a successful database-to-storage reflection or storage-to-database write. A plain read does not change provenance. A record remains authoritative when a user edits the displayed file to bytes which happen to equal another branch; content equality must not silently change the branch being extended.
+The record is updated after a successful database-to-storage reflection or storage-to-database write, or after verifying an exact unchanged revision. A plain read does not change provenance. A record remains authoritative when a user edits the displayed file to bytes which happen to equal another branch; content equality must not silently change the branch being extended.
+
+`contentHash` is an algorithm-tagged SHA-256 digest (`sha256:<lowercase hexadecimal>`) of the exact immutable content saved or reflected; `contentSize` is its byte length. Together they let the handler recognise unchanged content after PouchDB prunes the recorded revision. They do not recreate missing revision ancestry or authorise attaching an edited file to an unavailable base. Unsupported or malformed evidence follows the legacy comparison path.
+
+Old records remain readable. An equal-time scan can add content evidence when the recorded revision is still the conflict-free current revision and its bytes match storage. An ordinary unchanged save can also upgrade its verified current record. These upgrades revalidate storage and provenance after hashing; an unrelated branch or an unreadable revision is never certified from the current file. A hashing failure leaves legacy revision evidence, so overwrite protection remains conservative.
+
+Hashing is serialised across files to bound simultaneous whole-file buffers. The public `computeFileContentHash(Blob)` helper includes reading the Blob and Web Crypto SHA-256; the handler reuses results only for the same immutable Blob. It still allocates a whole-file buffer and Web Crypto may copy it, so serialisation does not imply constant memory use.
+
+The [file-reflection content hash decision](file-reflection-content-hash.md) records why this evidence uses SHA-256, the measured comparison with xxHash64, and the conditions for reconsidering that choice.
 
 File-handler saves and reflections share a lock for the same Metadata document, held from snapshot acquisition through provenance recording. Different documents can proceed concurrently. An ordinary save keeps one captured body and its recorded base through the database write; a later local edit is processed as a subsequent change, without rereading the file to certify that it remained unchanged. The handler acquires the lock before loading a file body from storage. Rename operations acquire both document locks in a consistent order, and internal calls reuse the caller's lock rather than acquiring it again. Host conflict-check hooks run after the locks are released, allowing a hook to await another file-handler operation on the same document. Host queues may count document-lock waiters against their concurrency limits, so a burst for one document can temporarily delay unrelated files.
 
@@ -91,13 +100,13 @@ User-directed reconciliation may select any exact current live revision, includi
 
 `storeWithBaseRevision()` is the force-write primitive for deliberately preserving a branch below an exact revision, including a revision which is no longer a leaf. It must not be used when an operation means 'advance this revision only if it is still current'. For that compare-and-store boundary, `storeWithLiveBaseRevision()` uses PouchDB's ordinary revision check and returns `false` if the supplied base has already been advanced. Any current revision-tree leaf is eligible, including a non-winning conflict leaf or a logical-deletion leaf. The caller must refresh its state after refusal rather than silently falling back to the deterministic winner.
 
-`storeIndependentRevision()` explicitly preserves unknown-origin content through `putDBEntryAsIndependentRoot()`. Passing an undefined base to `storeWithBaseRevision()` retains its existing latest-revision behaviour and does not create an independent root. `findLiveContentRevisions()` compares only current non-deleted leaves using locally available chunks. Additional provenance comparisons also use local-only retrieval, so they do not introduce remote chunk requests or delivery waits; a missing body leads to preservation rather than an inferred base.
+`storeIndependentRevision()` explicitly preserves unknown-origin content through `putDBEntryAsIndependentRoot()`. Passing an undefined base to `storeWithBaseRevision()` retains its existing latest-revision behaviour and does not create an independent root. `findLiveContentRevisions()` compares only current non-deleted leaves using locally available chunks. Additional provenance comparisons also use local-only retrieval, so they do not introduce remote chunk requests or delivery waits; a missing body without matching saved content evidence leads to preservation rather than an inferred base.
 
 A successful non-deleted reconciliation records the exact selected or newly created revision as provenance. Applying a logical deletion removes the storage item and its provenance record. Deletion provenance is not retained indefinitely: an absent storage item and a current logical-deletion winner already agree and need no further reconciliation.
 
 Hosts may construct the namespaced store handle during service composition, before its backing database is open. Store operations begin only after the host's storage lifecycle is ready. They fail rather than wait when that lifecycle contract is violated, because an implicit readiness wait could hang after failed initialisation or wait on its own initialisation handler. Database reset is a transient unavailable boundary; the host must avoid file processing during it and reconstruct derived provenance after reopening.
 
-For ordinary saving and incoming reflection, an absent or unreadable recorded base permits reconstruction only from exactly one matching current non-deleted leaf. Multiple matches avoid duplicate storage without guessing branch identity. No current match creates a fresh independent root, even when an ancestor has the same bytes. Deletion and rename retain their existing provenance-recovery contracts.
+For ordinary saving and incoming reflection, an absent or unreadable recorded base without matching saved content evidence permits reconstruction only from exactly one matching current non-deleted leaf. Multiple matches avoid duplicate storage without guessing branch identity. No current match creates a fresh independent root, even when an ancestor has the same bytes. Deletion and rename retain their existing provenance-recovery contracts.
 
 An unchanged stale file is not saved below the winner. When the database has advanced without a conflict, the existing database-to-storage path reflects it; a conflict instead remains subject to the host's reflection and resolution policy. Independent roots retain the file's modification time and use the existing Metadata/Chunks format, with fresh revision identifiers and reusable chunks. They have no shared ancestor with unrelated existing branches, including after replication. This does not disable a host's explicit newer-file option.
 

package/docs/database-diagnostics.md

@@ -0,0 +1,24 @@
+---
+date: 2026-10-19
+commonlib_version: '0.1.43'
+livesync_version: '1.0.38'
+status: unreleased
+---
+
+# Database diagnostics
+
+The focused `/diagnostics` entry supplies read-only database usage analysis and integrity inspection. Hosts choose original names or temporary pseudonyms before each run, provide progress and cancellation controls, and present the resulting reports. Analysis uses the original identifiers; name projection happens afterwards.
+
+Usage retains the existing available-revision selection and incremental chunk accounting. The first processed reference counts a chunk as unique; later references count it as shared. Sizes count JavaScript string units, as in the existing report. These columns do not measure physical database size or establish whether a chunk can be deleted.
+
+Integrity inspection enumerates actual stored document IDs, including logically deleted normal-file Metadata and current conflict branches. It uses the same identity classifier as the existing Metadata inspector. It reads content only for groups with identity discrepancies, conflicting branches, duplicate path claims, or differences between the inspected local and remote Metadata. Content comparisons use reconstructed bytes, including the Vault file where available. Missing, unreadable, and uninspected content remain distinct outcomes. Equal content within this scope does not establish that an entry is safe to delete.
+
+The first implementation supports the local database and CouchDB. Internal-file, customisation, and plug-in storage Metadata, older revision history, and other remote backends are explicitly outside integrity inspection. Usage continues to cover the revisions available to its local source. A remote failure retains the local findings and marks the integrity report partial.
+
+The CouchDB reader only sends GET requests. It reads existing synchronisation parameters when decryption needs a Security Seed and never creates missing parameters, initialises a database, or invokes replication admission. Local content reads do not fetch or cache remote Chunks. Owned requests are cancelled and released when the run ends; host-native request adapters may finish an already dispatched request after cancellation, but its result is discarded.
+
+Database update sequences and the host's configuration identity are checked again before completion. Storage readers must detect changes while reading a file. These observations can detect concurrent changes; they do not provide an atomic snapshot or prevent a file from changing later.
+
+Reports project a whitelist of facts. Pseudonyms preserve exact path equality across sources and keep document, revision, and Chunk identifiers separate. Case and Unicode normalisation facts are computed before projection. Maps are local to one run and are not persisted. Original-name mode still excludes credentials, connection addresses, encryption keys, raw errors, and file contents. JSON and Markdown use the same projected integrity result; TSV uses the same name mapper for Usage.
+
+Hosts may pass Commonlib, plug-in, and application versions to either report projector through its optional third argument. Only those three version fields are retained. Integrity reports also retain the five identity-related settings used for the inspection; credentials and the active connection configuration remain outside the report.

package/docs/development.md

@@ -8,6 +8,7 @@ The source tree is larger than the supported package surface. Consumers may impo
 
 - `src/index.ts`, `src/context.ts`, `src/settings.ts`, `src/remoteConfigurations.ts`, `src/p2p/index.ts`, `src/platform/browser/index.ts`, and `src/platform/node/index.ts` define the focused entries;
 - `src/replication/index.ts` defines the focused provider-capability and interaction contract for hosts which compose replication;
+- `src/diagnostics/index.ts` defines read-only Usage and integrity inspection, report projection, and formatting; hosts own the run dialogue and output destination;
 - `src/rpc/index.ts` defines a transitional entry for the existing LiveSync P2P composition, not a stable Commonlib 1.0 contract;
 - `_tools/build-package.mjs` compiles those entries and creates the publishable manifest under `.package`;
 - `docs/migration/downstream-imports.json` is the reviewed inventory from which explicit `compat/*` exports are generated;

package/docs/proven-in-use.md

@@ -8,7 +8,13 @@ The code paths below identify the maintained Self-hosted LiveSync composition po
 
 ## Obsidian plug-in
 
-Unreleased deletion tests exercise `deleteMetadataOfDeletedFiles` enabled and disabled with two in-memory PouchDB replicas and injected file storage. They verify deletion and rename reflection, preservation of genuine local edits, and restoration before or during a deleted-winner lookup, including the final revision check before deletion. They also verify that missing provenance or a compacted base preserves local storage, and that continuously advancing deleted revisions do not return stale Metadata. These tests cover the Commonlib file handler and revision lookup, including the latest-revision check before deletion; they do not exercise Obsidian file watchers or a remote CouchDB server.
+Unreleased [database diagnostics](database-diagnostics.md) tests cover preserved Usage accounting, normal-file identity classification, current conflict branches, byte comparisons, embedded Chunks, missing and unreadable content, cancellation, concurrent changes, and consistent pseudonyms. Real in-memory PouchDB tests verify pagination and conflict revision reads while retaining the original database handle. A CouchDB 3.5.0 integration test verifies GET-only access, encrypted Metadata and Chunk reads with an existing Security Seed, missing-seed failure without initialisation, and unchanged database update sequences and Seed documents. Focused tests also reject ciphertext which remains undecoded after an ID mismatch. Self-hosted LiveSync owns the serviceFeature, run-time name choice, dialogue lifecycle, and report copy and download controls. Its real Obsidian 1.12.7 test on Linux verifies cancellation before a run, both name modes, the nine-column Usage report, copy and download payloads, local integrity findings when CouchDB is unavailable, and unchanged settings, database update sequences, and Vault file names. Mobile emulation verifies the choice dialogue's viewport, safe-area, and touch-target layout; native iOS and Android behaviour remains unverified.
+
+Unreleased content-evidence tests replicate 99, 100, and 599 updates between real in-memory PouchDB databases, including a receiver with `revs_limit: 100`. They verify unchanged reflection after the recorded revision is pruned, including a recreated handler, and preserve same-size edits, intentional reverts, and records without valid content evidence. Separate tests verify legacy upgrades and changes during hashing. These are package-owned tests; they do not establish Windows, mobile, or remote CouchDB behaviour.
+
+The exact local packed candidate also passes Self-hosted LiveSync 1.0.37's checks, unit tests, application builds, and CLI E2E. Its focused real-Obsidian `stale-file-restart` scenario prunes the recorded revision before restarting, verifies unchanged reflection and legacy-record upgrades, and preserves an unknown-origin file. The Review Harness exercises the exported hash helper in desktop Obsidian. Maintainer-supplied Android and iOS reports additionally verify the helper and its benchmark on those devices; these timing measurements do not establish complete mobile synchronisation behaviour or peak memory use.
+
+Unreleased deletion tests exercise `deleteMetadataOfDeletedFiles` enabled and disabled with two in-memory PouchDB replicas and injected file storage. They verify deletion and rename reflection, preservation of genuine local edits, and restoration before or during a deleted-winner lookup, including the final revision check before deletion. They also verify that missing provenance or a compacted base without content evidence preserves local storage, and that continuously advancing deleted revisions do not return stale Metadata. These tests cover the Commonlib file handler and revision lookup, including the latest-revision check before deletion; they do not exercise Obsidian file watchers or a remote CouchDB server.
 
 Unreleased configuration-encryption tests cover changing the wrapper key without changing connection, E2EE, profile, or independent ID values. They also cover custom-key input before loading, failed writes, concurrent saves, cancellation, and unreadable-payload retention. Commonlib owns these service results. LiveSync owns the Apply controls, setting-tab registration, and database startup order; actual Apply and restart behaviour requires its focused real-Obsidian scenario.
 
@@ -88,6 +94,10 @@ The CLI extends the same neutral context with its database path and injected `St
 
 The CLI filesystem composition receives a configured base directory and constructs the rooted Node storage adapter in `src/apps/cli/adapters/NodeFileSystemAdapter.ts`. Commonlib's shared storage result table checks the focused root contract; the consumer adds its file cache, Vault-shaped operations, case handling, and command policy.
 
+The [Unicode path identity contract](unicode-path-identity.md), introduced in Commonlib `0.1.42`, provides opt-in NFC document IDs for CLI and Obsidian use with CouchDB. Commonlib tests exercise real in-memory Metadata lookup across different host normalisers. CLI temporary-filesystem tests cover resolution, updates, deletions, unchanged physical spellings, and ambiguous NFC paths. File-reflection tests preserve NFC-equivalent physical names while retaining case-only rename behaviour. With the packed candidate installed, the Linux CLI-to-real-Obsidian scenario verifies creation, remote updates, and daemon-applied deletions with and without E2EE and Path Obfuscation. A separate run migrates two legacy CLI databases with Rebuild and Fetch before the Obsidian round trip, preserving both NFD physical names and replacing the remote document ID. These checks do not establish native macOS or iOS behaviour.
+
+The unreleased reconstruction refinement excludes unconflicted logical deletions only when replacing the local database. Rebuilder tests exercise real PouchDB enumeration before the reset boundary across Rebuild, Standard Fetch, and Fast Fetch. Real CouchDB tests cover deletion propagation, fully tombstoned documents, unresolved conflict leaves, and a stale local copy after a remote deletion. Non-deleted duplicates and unresolved conflicts still stop reconstruction, and remote-only Rebuild retains its ID check. These package-owned tests establish preflight decisions; the maintained downstream migration scenario separately owns complete CLI reconstruction and real-Obsidian Fast Fetch with the exact packed candidate.
+
 Unreleased Node timestamp tests verify that `stat` and `trystat` retain an available birth time when change time advances, fall back when birth time is zero, and return integer milliseconds. Packed-package checks exercise the shared `getNodeFileCreationTime` export. With the exact locally packed candidate installed, downstream CLI tests verify that an in-place edit retains creation time in local Metadata. The CLI-to-real-Obsidian scenario additionally verifies the edited content and creation time in received Metadata. These checks do not establish the reporter's ZFS behaviour or physical-file creation times in Obsidian.
 
 The maintained CLI checks include unit tests, Deno-driven CLI E2E, Compose-based compatibility runs, and the CLI-to-real-Obsidian synchronisation scenario in `test/e2e-obsidian/scripts/cli-to-obsidian-sync.ts`. The latter is the strongest current evidence that the CLI and plug-in compose compatible Commonlib behaviour across two hosts.

package/docs/unicode-path-identity.md

@@ -0,0 +1,98 @@
+---
+date: 2026-10-19
+commonlib-version: "0.1.42"
+self-hosted-livesync-version: "1.0.38"
+status: unreleased
+---
+
+# Unicode path identity
+
+`pathNormalizationVersion` controls the logical path used to derive a normal-file
+Metadata document ID. An absent value or `0` preserves legacy behaviour. Value
+`1` applies Unicode NFC before the existing case and ID derivation rules. It
+does not alter the Metadata path or require physical files to be renamed.
+Unsupported values are rejected.
+
+NFC identity shipped in Commonlib `0.1.42` and Self-hosted LiveSync `1.0.38`.
+The deletion handling below is an unreleased refinement of reconstruction.
+
+## Package contract
+
+The Commonlib settings entry exposes `PathNormalizationVersion`,
+`PathIdentitySettings`, `getPathNormalizationVersion`, and
+`normalisePathForIdentity`. Consumers must use the shared path identity
+implementation for Metadata IDs rather than add a host-specific normalisation
+rule. Host storage adapters remain responsible for mapping a logical path back
+to its existing physical entry.
+
+## Database compatibility
+
+Version `1` uses `nfc-path-identity-v1` in the existing generation-13
+`used_features` list. This is separate from `idDerivationVersion`, which selects
+the cryptographic ID key. The NFC setting is a required Tweak even when
+encryption is disabled.
+
+A fresh database declares the feature before its first Metadata mutation. An
+existing database without the feature cannot acquire it through an ordinary
+Metadata write or replication while it already contains Metadata. A client
+configured for version `0` refuses an NFC database. These checks also apply
+when ordinary configuration-mismatch warnings are disabled. The existing
+version-document reception hook stops an active replication session when it
+detects incompatible path identity. It does not revoke server credentials or
+atomically cancel work already admitted by another device.
+
+Fast Fetch checkpoints include the path identity version, so a checkpoint
+created under version `0` cannot resume under version `1`, or vice versa.
+
+## Migration contract
+
+1. Update every participating client, stop synchronisation, and retain a
+   complete backup.
+2. Select a complete, authoritative Vault. Resolve distinct files or Metadata
+   documents which would derive the same NFC document ID. Case-insensitive
+   handling also applies its existing case rule.
+3. Set version `1` on the source and Rebuild both databases from that Vault.
+4. Set version `1` on the remaining clients and Fetch the rebuilt remote before
+   resuming synchronisation.
+
+Reconstruction checks the available storage listing and local Metadata before
+resetting either database. When the local database is not open, the storage
+check conservatively includes every listed file. A collision stops the
+operation; it never chooses a file to keep or merges separate histories.
+Ordinary synchronisation does not rename legacy document IDs in place.
+
+Full Rebuild, Standard Fetch, and Fast Fetch replace the local database. Their
+Metadata check requests conflict information and excludes a logically deleted
+document (`deleted: true`) only when it has no unresolved conflict leaves.
+A deleted winner with any unresolved conflict remains a collision candidate.
+Remote-only Rebuild retains logically deleted Metadata and still requires its
+stored document IDs to match the selected identity.
+
+A fully tombstoned document is already absent from ordinary Metadata
+enumeration. A deletion made only on the remote does not exclude a still
+non-deleted local document until that deletion has been replicated.
+
+The Setup URI shares `pathNormalizationVersion`; an absent value decodes as
+legacy mode, and unsupported versions are rejected. Importing a shared value
+does not itself perform the required reconstruction.
+
+## Supported hosts
+
+The initial support boundary is the maintained CLI and Obsidian with CouchDB.
+`PathService` owns logical ID derivation. The CLI resolves NFC-equivalent names
+against directory entries while preserving the actual entry spelling; its
+generic Node storage contract remains exact-path access. Obsidian supplies its
+normalised storage paths and preserves an existing physical spelling when it
+is NFC-equivalent to the received path.
+
+Journal and P2P refuse version `1`. Direct file access refuses a remote which
+declares the NFC feature. Other host adapters must establish physical path
+resolution before offering this setting. The regression tests cover ASCII,
+NFC, NFD, and mixed paths through in-memory PouchDB Metadata lookup, with and
+without path obfuscation, plus database admission, reconstruction ordering,
+collisions, and physical path handling. These tests do not establish native
+iOS or macOS filesystem behaviour.
+
+The full host setting, Rebuild/Fetch, CLI, and Obsidian migration contract is
+in the [Self-hosted LiveSync Unicode path identity design](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/design_docs/unicode_path_identity.md)
+and its [decision record](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/adr/2026_10_unicode_path_identity.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vrtmrz/livesync-commonlib",
-  "version": "0.1.41",
+  "version": "0.1.43",
   "description": "Shared data, storage, and replication primitives for Self-hosted LiveSync clients.",
   "type": "module",
   "types": "./dist/index.d.ts",
@@ -47,6 +47,11 @@
       "import": "./dist/context.js",
       "default": "./dist/context.js"
     },
+    "./diagnostics": {
+      "types": "./dist/diagnostics/index.d.ts",
+      "import": "./dist/diagnostics/index.js",
+      "default": "./dist/diagnostics/index.js"
+    },
     "./hashing": {
       "types": "./dist/hashing.d.ts",
       "import": "./dist/hashing.js",
@@ -643,6 +648,9 @@
       "context": [
         "dist/context.d.ts"
       ],
+      "diagnostics": [
+        "dist/diagnostics/index.d.ts"
+      ],
       "hashing": [
         "dist/hashing.d.ts"
       ],