First round of implementers guide fixes (#6146)

polkadot/roadmap/implementers-guide/src/protocol-chain-selection.md

@@ -43,6 +43,6 @@ The leaf-selection rule based on our definitions above is simple: we take the ma
 Finality gadgets, as mentioned above, will often impose an additional requirement to vote on a chain containing a specific block, known as the **required** block. Although this is typically the most recently finalized block, it is possible that it may be a block that is unfinalized. When receiving such a request:
 1. If the required block is the best finalized block, then select the best viable leaf.
 2. If the required block is unfinalized and non-viable, then select the required block and go no further. This is likely an indication that something bad will be finalized in the network, which will never happen when approvals & disputes are functioning correctly. Nevertheless we account for the case here.
-3. If the required block is unfinalized and non-viable, then iterate over the viable leaves in descending order by score and select the first one which contains the required block in its chain. Backwards iteration is a simple way to check this, but if unfinalized chains grow long then Merkle Mountain-Ranges will most likely be more efficient.
+3. If the required block is unfinalized and viable, then iterate over the viable leaves in descending order by score and select the first one which contains the required block in its chain. Backwards iteration is a simple way to check this, but if unfinalized chains grow long then Merkle Mountain-Ranges will most likely be more efficient.
 
 Once selecting a leaf, the chain should be constrained to the maximum of the required block or the highest **finalizable** ancestor.