(docs) coquilles fixed

.github/workflows/rust.yml

@@ -87,8 +87,7 @@ jobs:
         run: bash build.sh
 
       - name: Run all unit and integration tests
-        run: |
-          cargo test --no-fail-fast -- --test-threads=1 --show-output
+        run: cargo test --no-fail-fast -- --test-threads=1 --show-output
 
       - name: Final cleanup
         if: always()

README.md

@@ -5,7 +5,7 @@
 </br>
 
 
-![Build Status](https://github.com/srlabs/phink/actions/workflows/rust.yml/badge.svg)
+![Docker](https://github.com/srlabs/phink/actions/workflows/docker.yml/badge.svg)
 [![License](https://img.shields.io/github/license/srlabs/phink)](https://github.com/srlabs/phink/blob/main/LICENSE)
 [![dependency status](https://deps.rs/repo/github/srlabs/phink/status.svg)](https://deps.rs/repo/github/srlabs/phink)
 ![Discord](https://img.shields.io/discord/1276519988349374587?label=Discord)

book/documentation/CAMPAIGN.html

@@ -179,15 +179,15 @@ <h1 class="menu-title">Phink Book</h1>
 
                 <div id="content" class="content">
                     <main>
-                        <h2 id="writing-properties-for-ink-contracts"><a class="header" href="#writing-properties-for-ink-contracts">Writing Properties for ink! Contracts</a></h2>
-<h3 id="adding-properties"><a class="header" href="#adding-properties">Adding Properties</a></h3>
+                        <h2 id="writing-properties-for-ink-contracts"><a class="header" href="#writing-properties-for-ink-contracts">Writing properties for ink! contracts</a></h2>
+<h3 id="adding-properties"><a class="header" href="#adding-properties">Adding properties</a></h3>
 <h4 id="inside-your-cargotoml"><a class="header" href="#inside-your-cargotoml">Inside your <code>Cargo.toml</code></a></h4>
-<p>First, you need to add the <code>phink</code> feature to your Cargo.toml, such as:</p>
+<p>First, you need to add the <code>phink</code> feature to your <code>Cargo.toml</code>, such as:</p>
 <pre><code class="language-toml">[features]
 phink = []
 </code></pre>
 <h4 id="inside-your-filers"><a class="header" href="#inside-your-filers">Inside your <code>file.rs</code></a></h4>
-<p>Then, you can use the following example to create invariants. You need to create another <code>impl</code> if your contract, and to
+<p>Then, you can use the following example to create invariants. Create another <code>impl</code> in your contract, and
 put
 it under the feature of <code>phink</code>. Use <code>assert!</code> or <code>panic!</code> for your properties.</p>
 <pre><pre class="playground"><code class="language-rust edition2021"><span class="boring">#![allow(unused)]
@@ -206,15 +206,16 @@ <h4 id="inside-your-filers"><a class="header" href="#inside-your-filers">Inside
 <span class="boring">}</span></code></pre></pre>
 <p>You can find more informations in the page dedicated to <a href="INVARIANTS.html">invariants</a>.</p>
 <h2 id="running-phink"><a class="header" href="#running-phink">Running Phink</a></h2>
-<h3 id="1-instrument-the-contract"><a class="header" href="#1-instrument-the-contract">1. Instrument the Contract</a></h3>
-<p>Run the following command to instrument your ink! smart contract, enabling it for fuzzing:</p>
+<h3 id="1-instrument-the-contract"><a class="header" href="#1-instrument-the-contract">1. Instrument the contract</a></h3>
+<p>First things first: Let’s enable your contract for fuzzing. Run the following command to instrument your ink! smart
+contract:</p>
 <pre><code class="language-sh">phink instrument my_contract/
 </code></pre>
 <p>This step modifies the contract to include necessary hooks for Phink’s fuzzing process. It creates a fork of the
 contract, so you don’t have to make a copy before.</p>
 <h3 id="2-run-the-fuzzer"><a class="header" href="#2-run-the-fuzzer">2. Run the fuzzer</a></h3>
-<p>After <strong>instrumenting</strong> your contract and <strong>writing</strong> properties and <strong>configuring</strong> your <code>phink.toml</code>, execute the
-fuzzing process:</p>
+<p>After <strong>instrumenting</strong> your contract and <strong>writing</strong> properties and <strong>configuring</strong> your <code>phink.toml</code>, let’s get our
+hands on the fuzzing process:</p>
 <pre><code class="language-sh">phink fuzz
 </code></pre>
 <p>After executing this command, your fuzzing tests will begin based on the configurations specified in your <code>phink.toml</code>
@@ -224,25 +225,26 @@ <h3 id="2-run-the-fuzzer"><a class="header" href="#2-run-the-fuzzer">2. Run the
 <pre><code class="language-sh">watch -c -t -n 0.1 "clear &amp;&amp; cat output/phink/logs/last_seed.phink" # `output` is the default, but it depends of your `phink.toml`
 </code></pre>
 <p>This will provide you with clearer logs by continuously updating them every <strong>0.1</strong> seconds.</p>
-<h2 id="analyzing-results"><a class="header" href="#analyzing-results">Analyzing Results</a></h2>
+<h2 id="analyzing-results"><a class="header" href="#analyzing-results">Analyzing results</a></h2>
 <h3 id="crashes"><a class="header" href="#crashes">Crashes</a></h3>
 <p>In case of crashes, you should see something like the following.</p>
 <img src="https://raw.githubusercontent.com/srlabs/phink/refs/heads/main/assets/crashed.png" alt="crash"/>
 <p>To analyze the crash, you can run <code>phink execute &lt;your_crash&gt;</code>, for instance
 <code>phink execute output/phink/crashes/1729082451630/id:000000,sig:06,src:000008,time:627512,execs:3066742,op:havoc,rep:2</code></p>
 <div class="table-wrapper"><table><thead><tr><th>Component</th><th>Description</th></tr></thead><tbody>
-<tr><td>1729082451630</td><td>Timestamp representing when the crash was recorded.</td></tr>
-<tr><td>id:000000</td><td>Unique identifier for the crash.</td></tr>
-<tr><td>sig:06</td><td>Signal number that triggered the crash.</td></tr>
-<tr><td>src:000008</td><td>Source test case number.</td></tr>
-<tr><td>time:627512</td><td>Execution time since the start of the testing process.</td></tr>
-<tr><td>execs:3066742</td><td>Cumulative number of executions performed until the crash.</td></tr>
-<tr><td>op:havoc,rep:2</td><td>Type of fuzzing operation (havoc) and its repetition number.</td></tr>
+<tr><td>1729082451630</td><td>Timestamp representing when the crash was recorded</td></tr>
+<tr><td>id:000000</td><td>Unique identifier for the crash</td></tr>
+<tr><td>sig:06</td><td>Signal number that triggered the crash</td></tr>
+<tr><td>src:000008</td><td>Source test case number</td></tr>
+<tr><td>time:627512</td><td>Execution time since the start of the testing process</td></tr>
+<tr><td>execs:3066742</td><td>Cumulative number of executions performed until the crash</td></tr>
+<tr><td>op:havoc,rep:2</td><td>Type of fuzzing operation (havoc) and its repetition number</td></tr>
 </tbody></table>
 </div>
-<p>By running this, you should have an output similar to the screenshot below:</p>
+<p>By running the above command, you should get an output similar to the screenshot below:</p>
 <img src="https://raw.githubusercontent.com/srlabs/phink/refs/heads/main/assets/backtrace.png" alt="crash"/>
-<h3 id="coverage-this-feature-is-in-alpha-and-unstable"><a class="header" href="#coverage-this-feature-is-in-alpha-and-unstable">Coverage (<strong>this feature is in alpha and unstable</strong>)</a></h3>
+<h3 id="coverage"><a class="header" href="#coverage">Coverage</a></h3>
+<p><strong>This feature is in alpha and unstable.</strong></p>
 <h4 id="generating-a-coverage-report"><a class="header" href="#generating-a-coverage-report">Generating a coverage report</a></h4>
 <p>First, you need to create a <code>traces.cov</code> file. For this, execute the command below.</p>
 <pre><code class="language-sh">phink run  
@@ -251,9 +253,9 @@ <h4 id="generating-a-coverage-report"><a class="header" href="#generating-a-cove
 <pre><code class="language-sh">phink coverage my_contract/
 </code></pre>
 <p>Some HTML files should then be generated in the path you’ve configured inside your <code>phink.toml</code>. The coverage report
-provides a visual representation of tested code areas. Basically, the more green lines, the better. You can find below
-an example of the coverage report.</p>
-<h3 id="coverage-report-example"><a class="header" href="#coverage-report-example">Coverage Report Example</a></h3>
+provides a visual representation of the tested code areas. As a rule of thumb, the more green lines you can see there,
+the better it is for the code.</p>
+<h3 id="coverage-report-example"><a class="header" href="#coverage-report-example">Coverage report example</a></h3>
 <p><strong>Green Lines</strong>: Code that has been tested.</p>
 <p><img src="https://raw.githubusercontent.com/srlabs/phink/refs/heads/main/assets/coverage_1.png" alt="Coverage Report Part 1" /></p>
 <p><em>Figure 1: Coverage Report of one specific file.</em></p>

book/documentation/CONCEPT.html

@@ -179,23 +179,25 @@ <h1 class="menu-title">Phink Book</h1>
 
                 <div id="content" class="content">
                     <main>
-                        <h1 id="concepts-and-terminology"><a class="header" href="#concepts-and-terminology">Concepts and Terminology</a></h1>
+                        <h1 id="concepts-and-terminology"><a class="header" href="#concepts-and-terminology">Concepts and terminology</a></h1>
 <h2 id="concepts"><a class="header" href="#concepts">Concepts</a></h2>
-<h3 id="fuzzing-in-general"><a class="header" href="#fuzzing-in-general">Fuzzing in general</a></h3>
+<h3 id="fuzzing"><a class="header" href="#fuzzing">Fuzzing</a></h3>
 <p><strong>Fuzzing</strong> is an automated software testing technique that involves providing random data inputs to
-a program. The primary goal is to uncover anomalies, such as crashes, assertion failures, that signify
+a program. The primary goal is to uncover anomalies, such as crashes and assertion failures. These are intriguing
+because they pinpoint
 potential vulnerabilities.</p>
-<h3 id="property-based-fuzzing"><a class="header" href="#property-based-fuzzing">Property-based Fuzzing</a></h3>
+<h3 id="property-based-fuzzing"><a class="header" href="#property-based-fuzzing">Property-based fuzzing</a></h3>
 <p><strong>Property-based testing</strong> involves specifying properties or invariants that your ink! contract should always satisfy.
 In
-Phink, these properties act as assertions. Phink uses this approach by allowing developers to
+Phink, these properties act as assertions. Phink makes it possible for developers to
 define properties directly within ink! smart contracts. Such properties are then tested against varied
-inputs, ensuring the contract maintains its invariants across all possible data conditions.</p>
-<h3 id="coverage-guided-fuzzing"><a class="header" href="#coverage-guided-fuzzing">Coverage-guided Fuzzing</a></h3>
+inputs. In this way, the contract maintains its invariants across all possible data conditions. But there is a final
+twist in the fuzzing tale.</p>
+<h3 id="coverage-guided-fuzzing"><a class="header" href="#coverage-guided-fuzzing">Coverage-guided fuzzing</a></h3>
 <p><strong>Coverage-guided fuzzing</strong> is a fuzzing strategy that focuses on maximizing code coverage during testing. It uses
 feedback from code execution paths to guide input generation, focusing on unexplored parts of the code.
-Phink instruments ink! smart contracts to track code coverage, optimizing its fuzzing efforts by targeting less examined
-paths.</p>
+Phink instruments ink! smart contracts to track code coverage. Optimizing fuzzing efforts by targeting less examined
+paths is what makes the game worth playing.</p>
 <h2 id="terminology"><a class="header" href="#terminology">Terminology</a></h2>
 <h3 id="corpus"><a class="header" href="#corpus">Corpus</a></h3>
 <p>A <strong>corpus</strong> refers to the collection of all input samples used during the testing process. It is
@@ -213,14 +215,14 @@ <h3 id="invariants"><a class="header" href="#invariants">Invariants</a></h3>
 <hr />
 <h3 id="instrumentation"><a class="header" href="#instrumentation">Instrumentation</a></h3>
 <p><strong>Instrumentation</strong> involves modifying a program to collect runtime information such as code coverage data. In fuzzing,
-instrumentation is used to trace execution paths, enabling coverage-guided techniques to generate more informed and
+instrumentation traces execution paths, enabling coverage-guided techniques to generate more informed and
 effective test cases.</p>
 <hr />
 <h3 id="coverage"><a class="header" href="#coverage">Coverage</a></h3>
-<p><strong>Coverage</strong> is a measure of how much of a program’s code is tested during fuzzing. High coverage corresponds to a
-good assessment of the contracts logic.</p>
+<p><strong>Coverage</strong> measures how much of a program’s code is tested during fuzzing. High coverage corresponds to a
+good assessment of the contract’s logic.</p>
 <hr />
-<h3 id="contract-selectors"><a class="header" href="#contract-selectors">Contract Selectors</a></h3>
+<h3 id="contract-selectors"><a class="header" href="#contract-selectors">Contract selectors</a></h3>
 <p><strong>ink! contract selectors</strong> are unique identifiers for functions within ink! smart contracts. Selectors are derived from
 function signatures and are used to call specific functions within a contract deployed on the blockchain.</p>
 <hr />