docs(tvix): fix some typos across various documents r/8227

Fix some typos found while reading various documents, mostly those
relating to the castore.

Here is a summary of the edits.

- fix broken link between documents in the store and castore directories
- clarify expression in castore's data model document that indicates
  that the *name* of each child node of a directory must be unique
  across all three lists of children
- add missing closing parenthesis in castore's data model document
- replace "how" with "what" in the phrase "unclear how a ... would even
  look like" in castore's why-not-git-trees document
- remove unnecessary articles in castore's blobstore chunking document
- add missing "y" to "optionall" in eval's compilation of bindings
  document

Change-Id: I1997ea91bb4e9c40abcd81e0cde9405968580ba6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/11763
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>

3 files changed, 6 insertions, 6 deletions

diff --git a/tvix/castore/docs/blobstore-chunking.md b/tvix/castore/docs/blobstore-chunking.md
index 49bbe6927554..df3c29680257 100644
--- a/tvix/castore/docs/blobstore-chunking.md
+++ b/tvix/castore/docs/blobstore-chunking.md
@@ -73,10 +73,10 @@ This means one only needs to the root digest to validate a constructions, and th
 constructions can be sent [separately][bao-spec].
 
 This relieves us from the need of having to encode more granular chunking into
-our data model / identifier upfront, but can make this a mostly a transport/
+our data model / identifier upfront, but can make this mostly a transport/
 storage concern.
 
-For the some more description on the (remote) protocol, check
+For some more description on the (remote) protocol, check
 `./blobstore-protocol.md`.
 
 #### Logical vs. physical chunking
diff --git a/tvix/castore/docs/data-model.md b/tvix/castore/docs/data-model.md
index 2df6761aae8f..5e6220cc23fa 100644
--- a/tvix/castore/docs/data-model.md
+++ b/tvix/castore/docs/data-model.md
@@ -15,8 +15,8 @@ a directory.
 
 All three message types have a `name` field, specifying the (base)name of the
 element (which MUST not contain slashes or null bytes, and MUST not be '.' or '..').
-For reproducibility reasons, the lists MUST be sorted by that name and also
-MUST be unique across all three lists.
+For reproducibility reasons, the lists MUST be sorted by that name and the
+name MUST be unique across all three lists.
 
 In addition to the `name` field, the various *Node messages have the following
 fields:
@@ -27,7 +27,7 @@ A `DirectoryNode` message represents a child directory.
 It has a `digest` field, which points to the identifier of another `Directory`
 message, making a `Directory` a merkle tree (or strictly speaking, a graph, as
 two elements pointing to a child directory with the same contents would point
-to the same `Directory` message.
+to the same `Directory` message).
 
 There's also a `size` field, containing the (total) number of all child
 elements in the referenced `Directory`, which helps for inode calculation.
diff --git a/tvix/castore/docs/why-not-git-trees.md b/tvix/castore/docs/why-not-git-trees.md
index fd46252cf55c..4a12b4ef5554 100644
--- a/tvix/castore/docs/why-not-git-trees.md
+++ b/tvix/castore/docs/why-not-git-trees.md
@@ -48,7 +48,7 @@ The git tree object format uses sha1 both for references to other trees and
 hashes of blobs, which isn't really a hash function to fundamentally base
 everything on in 2023.
 The [migration to sha256][git-sha256] also has been dead for some years now,
-and it's unclear how a "blake3" version of this would even look like.
+and it's unclear what a "blake3" version of this would even look like.
 
 [bao]: https://github.com/oconnor663/bao
 [blake3]: https://github.com/BLAKE3-team/BLAKE3