docs: fix typos (#2193)

polkadot/roadmap/implementers-guide/src/node/utility/candidate-validation.md

@@ -31,7 +31,7 @@ all the necessary parameters to the validation function. These are:
   * The [`ValidationData`](../../types/candidate.md#validationdata).
   * The [`PoV`](../../types/availability.md#proofofvalidity).
 
-The second category is for PVF pre-checking. This is primarly used by the [PVF pre-checker](pvf-prechecker.md)
+The second category is for PVF pre-checking. This is primarily used by the [PVF pre-checker](pvf-prechecker.md)
 subsystem.
 
 ### Determining Parameters

polkadot/roadmap/implementers-guide/src/node/utility/pvf-host-and-workers.md

@@ -44,7 +44,7 @@ execution request:
 We use timeouts for both preparation and execution jobs to limit the amount of
 time they can take. As the time for a job can vary depending on the machine and
 load on the machine, this can potentially lead to disputes where some validators
-successfuly execute a PVF and others don't.
+successfully execute a PVF and others don't.
 
 One dispute mitigation we have in place is a more lenient timeout for
 preparation during execution than during pre-checking. The rationale is that the

polkadot/roadmap/implementers-guide/src/node/utility/pvf-prechecker.md

@@ -24,7 +24,7 @@ relevant.
 When a PVF just becomes relevant, the subsystem will send a message to the [Candidate Validation] subsystem asking for
 the pre-check.
 
-Upon receving a message from the candidate-validation subsystem, the pre-checker will note down that the PVF has its
+Upon receiving a message from the candidate-validation subsystem, the pre-checker will note down that the PVF has its
 judgement and will also sign and submit a [`PvfCheckStatement`][PvfCheckStatement] via the [`submit_pvf_check_statement`
 runtime API][PVF pre-checking runtime API]. In case, a judgement was received for a PVF that is no longer in view it is
 ignored.