Junie guidelines: fix grammar and typos in development guidelines

.junie/guidelines.md

@@ -27,11 +27,11 @@ Chill is a comprehensive web application built as a set of Symfony bundles. It i
 
 ## Project Structure
 
-Note: This is a project which exists from a long time ago, and we found multiple structure inside each bundle. When having the choice, the developers should choose the new structure.
+Note: This is a project that's existed for a long time, and throughout the years we've used multiple structures inside each bundle. When having the choice, the developers should choose the new structure.
 
 The project follows a standard Symfony bundle structure:
 - `/src/Bundle/`: Contains all the Chill bundles. The code is either at the root of the bundle directory, or within a `src/` directory (preferred). See psr4 mapping at the root's `composer.json`.
-- each bundle come with his own tests, either in the `Tests` directory (when the code is directly within the bundle directory (for instance `src/Bundle/ChillMainBundle/Tests`, `src/Bundle/ChillPersonBundle/Tests`)), or inside the `tests` directory, alongside to the `src/` sub-directory (example: `src/Bundle/ChillWopiBundle/tests`) (this is the preferred way).
+- each bundle comes with its own tests, either in the `Tests` directory (when the code is directly within the bundle directory (for instance `src/Bundle/ChillMainBundle/Tests`, `src/Bundle/ChillPersonBundle/Tests`)), or inside the `tests` directory, alongside the `src/` sub-directory (example: `src/Bundle/ChillWopiBundle/tests`) (this is the preferred way).
 - `/docs/`: Contains project documentation
 
 Each bundle typically has the following structure:
@@ -46,13 +46,13 @@ Each bundle typically has the following structure:
 
 ### A special word about TicketBundle
 
-The ticket bundle is developed using a kind of "Command" pattern. The controller fill a "Command", and a "CommandHandler" handle this command. They are savec in the `src/Bundle/ChillTicketBundle/src/Action` directory.
+The ticket bundle is developed using a kind of "Command" pattern. The controller fills a "Command," and a "CommandHandler" handles this command. They are saved in the `src/Bundle/ChillTicketBundle/src/Action` directory.
 
 ## Development Guidelines
 
 ### Building and Configuration Instructions
 
-All the command should be run through the `symfony` command, which will configure the required variables.
+All the commands should be run through the `symfony` command, which will configure the required variables.
 
 For assets, we must ensure that we use node at version `^20.0.0`. This is done using `nvm use 20`.
 
@@ -87,7 +87,7 @@ For assets, we must ensure that we use node at version `^20.0.0`. This is done u
    docker compose up -d
    ```
 
-5. **Set Up the Database**:
+6. **Set Up the Database**:
    ```bash
    # Create the database
    symfony console doctrine:database:create
@@ -99,20 +99,20 @@ For assets, we must ensure that we use node at version `^20.0.0`. This is done u
    symfony console doctrine:fixtures:load
    ```
 
-6. **Build Assets**:
+7. **Build Assets**:
    ```bash
    nvm use 20
    yarn run encore dev
    ```
 
-7. **Start the Development Server**:
+8. **Start the Development Server**:
    ```bash
    symfony server:start -d
    ```
 
 #### Docker Setup
 
-The project includes Docker configuration for easier development:
+The project includes a Docker configuration for easier development:
 
 1. **Start Docker Services**:
    ```bash
@@ -153,9 +153,9 @@ Key configuration files:
 
 Each time a doctrine entity is created, we generate migration to adapt the database.
 
-The migration are created using the command `symfony console doctrine:migrations:diff --no-interaction --namespace <namespace>`, where the namespace is the relevant namespace for migration. As this is a bash script, do not forget to quote the `\` (`\` must become `\\` in your command).
+The migration is created using the command `symfony console doctrine:migrations:diff --no-interaction --namespace <namespace>`, where the namespace is the relevant namespace for migration. As this is a bash script, remember to quote the `\` (`\` must become `\\` in your command).
 
-Each bundle has his own namespace for migration (always ask me to confirm that command, with a list of updated / created entities so that I can confirm you that it is ok):
+Each bundle has his own namespace for migration (always ask me to confirm that command with a list of updated / created entities so that I can confirm to you that it is ok):
 
 - `Chill\Bundle\ActivityBundle` writes migrations to `Chill\Migrations\Activity`;
 - `Chill\Bundle\BudgetBundle` writes migrations to `Chill\Migrations\Budget`;
@@ -183,7 +183,7 @@ Once created the, comment's classes should be removed and a description of the c
 
 When we need to use a DateTime or DateTimeImmutable that need to express "now", we prefer the usage of
 `Symfony\Component\Clock\ClockInterface`, where possible. This is usually not possible in doctrine entities,
-where injection does not work when restoring an entity from database, but usually possible in services.
+where injection does not work when restoring an entity from a database, but usually possible in services.
 
 In test, we use `\Symfony\Component\Clock\MockClock` which is an implementation of `Symfony\Component\Clock\ClockInterface`
 where we have full and easy control of the date.
@@ -198,9 +198,9 @@ The project uses PHPUnit for testing. Each bundle has its own test suite, and th
 
 For creating mock, we prefer using prophecy (library phpspec/prophecy).
 
-##### Useful helpers and tips that avoid create a mock
+##### Useful helpers and tips that avoid creating a mock
 
-Some notable implementations that are tests helper, and avoid to create a mock:
+Some notable implementations that are test helpers and avoid creating a mock:
 
 - `\Psr\Log\NullLogger`, an implementation of `\Psr\Log\LoggerInterface`;
 - `\Symfony\Component\Clock\MockClock`, an implementation of `Symfony\Component\Clock\ClockInterface` (already mentioned above);
@@ -297,7 +297,7 @@ class TicketTest extends TestCase
 
 #### Test Database
 
-For tests that require a database, the project uses postgresql database filled by fixtures (usage of doctrine-fixtures). You can configure a different database for testing in the `.env.test` file.
+For tests that require a database, the project uses a postgresql database filled with fixtures (usage of doctrine-fixtures). You can configure a different database for testing in the `.env.test` file.
 
 ### Code Quality Tools