Remove header fragments which is not needd

2 files changed, 8 insertions, 8 deletions

diff --git a/doc/manual/src/architecture/store/path.md b/doc/manual/src/architecture/store/path.md
index 039d8b1c6..663f04f46 100644
--- a/doc/manual/src/architecture/store/path.md
+++ b/doc/manual/src/architecture/store/path.md
@@ -26,7 +26,7 @@ Example:
       |--------| |------------------------------| |----------|
     store directory            digest                 name
 
-## Store Directory {#store-directory}
+## Store Directory
 
 Every [store](./store.md) has a store directory.
 
@@ -53,7 +53,7 @@ One cannot copy a store object to a store with a different store directory.
 Instead, it has to be rebuilt, together with all its dependencies.
 It is in general not enough to replace the store directory string in file contents, as this may render executables unusable by invalidating their internal offsets or checksums.
 
-# Digest {#digest}
+# Digest
 
 In a [store path](#store-path), the [digest][digest] is the output of a [cryptographic hash function][hash] of either all *inputs* involved in building the referenced store object or its actual *contents*.
 
@@ -84,7 +84,7 @@ This depends on the specifics of the software to build and run.
 >
 > For example, Java programs are compressed after compilation, which obfuscates any store paths they may refer to and prevents Nix from automatically detecting them.
 
-## Input Addressing {#input-addressing}
+## Input Addressing
 
 Input addressing means that the digest derives from how the store object was produced, namely its build inputs and build plan.
 
@@ -95,7 +95,7 @@ Nix has a custom serialisation format called Nix Archive (NAR)
 Store object references of this sort can *not* be validated from the content of the store object.
 Rather, a cryptographic signature has to be used to indicate that someone is vouching for the store object really being produced from a build plan with that digest.
 
-## Content Addressing {#content-addressing}
+## Content Addressing
 
 Content addressing means that the digest derives from the store object's contents, namely its file system objects and references.
 If one knows content addressing was used, one can recalculate the reference and thus verify the store object.
diff --git a/doc/manual/src/architecture/store/store.md b/doc/manual/src/architecture/store/store.md
index 9f580f9da..08b6701d5 100644
--- a/doc/manual/src/architecture/store/store.md
+++ b/doc/manual/src/architecture/store/store.md
@@ -25,7 +25,7 @@ Arrows indicate suggested reading order.
 [ input addressing ] [ content addressing ]
 ```
 
-## Store Object {#store-object}
+## Store Object
 
 A store object can hold
 
@@ -36,13 +36,13 @@ Store objects can be build inputs, build results, or build tasks.
 
 Store objects are [immutable][immutable-object]: once created, they do not change until they are deleted.
 
-## Reference {#reference}
+## Reference
 
 A store object reference is an [opaque][opaque-data-type], [unique identifier][unique-identifier]:
 The only way to obtain references is by adding or building store objects.
 A reference will always point to exactly one store object.
 
-## Operations {#operations}
+## Operations
 
 A Nix store can *add*, *retrieve*, and *delete* store objects.
 
@@ -89,7 +89,7 @@ As it keeps track of references, it can [garbage-collect][garbage-collection] un
 
     [ store ] --> collect garbage --> [ store' ]
 
-## Files and Processes {#files-and-processes}
+## Files and Processes
 
 Nix maps between its store model and the [Unix paradigm][unix-paradigm] of [files and processes][file-descriptor], by encoding immutable store objects and opaque identifiers as file system primitives: files and directories, and paths.
 That allows processes to resolve references contained in files and thus access the contents of store objects.