Apply suggestions from code review

Co-authored-by: Robert Hensing <[email protected]>

Author: Ericson2314

doc/manual/source/store/resolution.md

@@ -7,7 +7,7 @@ Derivations that only have store paths as inputs are likewise called *resolved d
 
 [Deriving paths][deriving-path] intentionally make it possible to refer to the same [store object] in multiple ways.
 This is a consequence of content-addressing, since different derivations can produce the same outputs, and the same date can also be manually added to the store.
-This is also a consequence even of input-addressing, as an output can be referred to by derivation and output name, or directly by its store path input address.
+This is also a consequence even of input-addressing, as an output can be referred to by derivation and output name, or directly by its [computed](./outputs/input-address.md) store path.
 Since dereferencing deriving paths is thus not injective, it induces an equivalence relation on deriving paths.
 
 Let's call this equivalence relation \\(\\sim\\), where \\(p_1 \\sim p_2\\) means that deriving paths \\(p_1\\) and \\(p_2\\) refer to the same store object.
@@ -49,7 +49,7 @@ $}
 Derivation resolution always maps derivations to input-content-equivalent derivations.
 
 Similar to evaluation, we can also speak of *partial* vs *total* derivation resolution.
-Total resolution is the function described above.
+Total resolution is the _resolve_ function described above.
 For partial resolution, a derivation is related to equivalent derivations with the same or simpler inputs, but not all those inputs will be plain store paths.
 This is useful when the input refers to a floating content addressed output we have not yet built --- we don't know what (content-address) store path will used for that derivation, so we are "stuck" trying to resolve derived path in question.
 Partial resolution is not a function, but an (assymetic) relation, created by directing the above equivalence relation so the right-side items are always equal or simpler.