Address comments from code review.

Author: nuttycom

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to `librustzcash` Crates
+# Contributing to Zallet
 
 First off, thanks for taking the time to contribute! ❤️
 
@@ -140,7 +140,7 @@ Once it's filed:
 - If the team is able to reproduce the issue, it will be assigned an
   appropriate category and fixed according to the criticality of the issue. If
   you're able to contribute a proposed fix, this will likely speed up the
-  process, although be aware that `librustzcash` is a complex project and fixes
+  process, although be aware that Zallet is a complex project and fixes
   will be considered in the context of safety and potential for unintentional
   misuse of overall API; you should be prepared to alter your approach based on
   suggestions from the team and for your contributions to undergo multiple
@@ -197,18 +197,8 @@ Enhancement suggestions are tracked as [GitHub issues](/issues).
 
 This repository is currently developed with an "unstable main" workflow. The
 current contents of the main branch is a preview of what the next full release
-of all crates may look like, but is not stable. For example, as-yet-unreleased
-`zcash_client_sqlite` migrations may be altered incompatibly at any time.
-
-In the main branch, all crates have the version corresponding to their most
-recent stable release on https://crates.io; this enables the preview state to
-be tested ahead-of-time by downstream users via [patch.crates-io] directives.
-
-Individual crates have their own tags, e.g. `zcash_primitives-0.19.0`. These
-tags point to the Git commit at which that crate version was published (which
-in general is not the merge commit for a release branch, but the actual commit
-that incremented the crate's version). Note however that other crates should
-not be considered stable at that revision.
+of all crates may look like, but is not stable. As-yet-unreleased code may be
+altered incompatibly at any time.
 
 #### Merge Workflow
 
@@ -259,9 +249,7 @@ conflicts.
   crates' `CHANGELOG.md` files to clearly document the change.
 - Updated or added members of the public API MUST include complete `rustdoc`
   documentation comments.
-- It is acceptable and desirable to open pull requests in "Draft" status. Only
-  once the pull request has passed CI checks should it be transitioned to
-  "Ready For Review".
+- Each commit should be formatted cleanly using `cargo fmt`.
 - There MUST NOT be "work in progress" commits as part of your history, with
   the following exceptions:
   - When making a change to a public API or a core semantic change, it is
@@ -277,8 +265,37 @@ conflicts.
     additions or other changes to the test framework may be required. Please
     consult with the maintainers if substantial changes of this sort are
     needed, or if you are having difficulties reproducing the bug in a test.
+- Each commit should pass `cargo +beta clippy --tests --all-features --all-targets`
+  without warnings, excepting the first case described above for work-in-progress
+  commits.
+
+#### Pull Requests
 
-#### Pull Request Review
+A pull request MUST reference one or more issues that it closes. Furthermore,
+DO NOT submit a pull request without a maintainer having acknowledged the
+validity of the issue(s) that the pull request purports to close.
+
+It is acceptable and desirable to open pull requests in "Draft" status. Only
+once the pull request has passed CI checks should it be transitioned to "Ready
+For Review". Please @mention a maintainer if you need CI to be triggered in
+preparation for transitioning the PR to "Ready For Review"; CI does not run
+automatically for PRs from external contributors.
+
+##### Commit Messages
+
+- Commit messages should have a short (preferably less than ~120 characters) title.
+- The body of each commit message should include the motivation for the change,
+  although for some simple cases (such as the application of suggested changes) this
+  may be elided.
+- When a commit has multiple authors, please add `Co-Authored-By:` metadata to
+  the commit message to include everyone who is responsible for the contents of
+  the commit; this is important for determining who has the most complete
+  understanding of the changes. 
+- If any AI agent was used in writing the code being commited, you MUST
+  maintain or add `Co-Authored-By:` metadata indicating the participation of
+  the AI agent. Failure to do so is grounds for closing a pull request.
+
+##### Pull Request Review
 
 It is acceptable and desirable to use a rebase-based workflow within the
 context of a single pull request in order to produce a clean commit history.
@@ -345,19 +362,6 @@ missing cross-organization permissions); in this case (or if a user's PR has
 "allow maintainers to edit" disabled), we may close the PR and open a new PR
 containing the commits from the original.
 
-#### Commit Messages
-
-- Commit messages should have a short (preferably less than ~120 characters) title.
-- The body of each commit message should include the motivation for the change,
-  although for some simple cases (such as the application of suggested changes) this
-  may be elided.
-- When a commit has multiple authors, please add `Co-Authored-By:` metadata to
-  the commit message to include everyone who is responsible for the contents of
-  the commit; this is important for determining who has the most complete
-  understanding of the changes. If any AI agent was used in writing the code
-  being commited, you MUST maintain or add `Co-Authored-By` metadata indicating
-  the use of the AI agent. Failure to do so is grounds for closing a PR.
-
 ### Coding Style
 
 The Zallet authors hold our software to a high standard of quality. The list of
@@ -387,9 +391,8 @@ implications, including but not limited to the following:
     state space are used.
   - Use custom `enum`s with semantically relevant variants instead of boolean
     arguments and return values.
-- Prefer immutability; make data types immutable unless there is a strong
-  reason to believe that values will need to be modified in-place for
-  performance reasons.
+- Make data types immutable unless there is a strong reason to believe that
+  values will need to be modified in-place for performance reasons.
 - Take care when introducing and/or using structured enum variants, because
   Rust does not provide adequate language features for making such values
   immutable or ensuring safe construction. Instead of creating structured or
@@ -405,8 +408,9 @@ This means:
 - Write referentially transparent functions. A referentially transparent
   function is one that, given a particular input, always returns the same
   output.
-- Avoid mutation whenever possible. If it's strictly necessary, use mutable
-  variables only in the narrowest possible scope.
+- Avoid mutation. If it's necessary for performance, use mutable variables only
+  in the narrowest possible scope (e.g. within the internal scope of a
+  referentially transparent function).
 - In Rust, we don't have good tools for referentially transparent treatment
   of operations that involve side effects. If a statement produces or makes use
   of a side-effect, the context in which that statement is executed should use