fix small bugs in the React course docs

angular/DEVELOPMENT_DIARY.md

@@ -5,9 +5,9 @@ The diary is a **mandatory** artefact of this course.
 > "We are what we repeatedly do. Excellence, then, is not an act, but a habit."
 > — Aristotle
 
-This course gives you a lot of freedom in *what* to do and *how*. To make sense of your individual progress, we ask you to keep a development diary. In real-world projects you might encounter this as a formal Architecture Design Log; in our case it'll be something simpler and less formal.
+This course gives you a lot of freedom in _what_ to do and _how_. To make sense of your individual progress, we ask you to keep a development diary. In real-world projects you might encounter this as a formal Architecture Design Log; in our case it'll be something simpler and less formal.
 
-A diary is a powerful way to think *again* about what you're doing — to put the essence of your work into words, even if only for an MD file :) It's another chance to revisit, "digest", and reflect.
+A diary is a powerful way to think _again_ about what you're doing — to put the essence of your work into words, even if only for an MD file :) It's another chance to revisit, "digest", and reflect.
 
 In your development diary I ask you to record your progress, problems you ran into, decisions you made, and anything else you find worth noting. You can emulate a "stand-up" ceremony from Scrum (What did you do yesterday/today? Problems? Blockers?).
 
@@ -72,7 +72,6 @@ After that, clone it locally and work with it like a regular GitHub repo.
 6. **Honesty (No Backdating):** an entry must be committed on the same day or the next.
 7. **The `main` branch:** diary entries must be merged into **`main`** by the time of the check. The parser only looks at `main` — entries on feature branches are ignored. If you have branch protection set up, open a PR with the entry and merge it — that takes 30 seconds.
 8. **Don't use Squash Merge for diaries.** Squash erases the original commit dates, and we need real Git history to verify regularity. Recommended flow: branch → commit entries on the right days → PR → merge with a regular **Merge commit** or **Rebase**. If your team uses squash for code — fine, just make an exception when merging diary files.
-
    - _Forbidden:_ writing 10 entries on Sunday evening and committing them in a batch. We check Git history.
    - If you don't have time to write a full entry on the day, commit the bullet points and flesh out the rest later in the week.
 
@@ -176,19 +175,19 @@ If, for any reason, you didn't keep the diary for one or two weeks, you have to
 
 ### Threshold for being allowed to defend the final project (pass / fail)
 
-| Requirement                                                                                                                                  | Status    |
-| -------------------------------------------------------------------------------------------------------------------------------------------- | --------- |
-| The development diary exists, is filled in regularly, entries are committed on time                                                          | must pass |
-| **The diary describes how you learned Angular's core topics — in your own words** (or these topics are captured on video — see Plan B)       | must pass |
+| Requirement                                                                                                                            | Status    |
+| -------------------------------------------------------------------------------------------------------------------------------------- | --------- |
+| The development diary exists, is filled in regularly, entries are committed on time                                                    | must pass |
+| **The diary describes how you learned Angular's core topics — in your own words** (or these topics are captured on video — see Plan B) | must pass |
 
 ### Quality criteria (0–100 points)
 
-| Points  | Level         | Description                                                                                                |
-| ------- | ------------- | ---------------------------------------------------------------------------------------------------------- |
-| **20**  | Formal        | Brief entries without detail ("did X")                                                                     |
-| **60**  | Regular       | At least 2 entries/week, visible progress, learning of several core topics is described                    |
-| **80**  | Detailed      | Problems and solutions are described; the line of thinking is clear                                        |
-| **100** | Reflective    | Deep reflection, comparison of implementation options — clear that it wasn't written for the checkbox      |
+| Points  | Level      | Description                                                                                           |
+| ------- | ---------- | ----------------------------------------------------------------------------------------------------- |
+| **20**  | Formal     | Brief entries without detail ("did X")                                                                |
+| **60**  | Regular    | At least 2 entries/week, visible progress, learning of several core topics is described               |
+| **80**  | Detailed   | Problems and solutions are described; the line of thinking is clear                                   |
+| **100** | Reflective | Deep reflection, comparison of implementation options — clear that it wasn't written for the checkbox |
 
 ---
 

react/modules/tasks/forms.md

@@ -185,7 +185,7 @@ In this task, you will implement form handling using two different approaches: u
   - Usage of _ts-ignore_: **-20 points per each**
   - Presence of _code-smells_ (God-object, chunks of duplicate code), commented code sections: **-10 points per each**
 
-- **2. Test Coverage**
+- **2. Test Coverage (one which applies)**
   - Testing statement coverage below 80% (≥70%): **-10 points**
   - Testing statement coverage below 70% (≥50%): **-30 points**
   - All coverage metrics below 50%: **-50 points**

react/modules/tasks/functional-routing.md

@@ -124,7 +124,7 @@ Focus on routing and functional components.
   - Usage of _ts-ignore_: **-20 points per each**
   - Presence of _code-smells_ (God-object, chunks of duplicate code), commented code sections: **-10 points per each**
 
-- **2. Test Coverage**
+- **2. Test Coverage (one which applies)**
   - Statement coverage below 80% (≥70%): **-10 points**
   - Statement coverage below 70% (≥50%): **-30 points**
   - All coverage metrics below 50%: **-50 points**

react/modules/tasks/performance/performance.md

@@ -19,7 +19,7 @@ In this task, you will optimize a intentionally unoptimized React application th
 - [Chrome](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi)
 - [Firefox](https://addons.mozilla.org/en-US/firefox/addon/react-devtools/)
 
-## Performance Optimization Workflow
+## Performance Optimization Workflow (max 100 points)
 
 For detailed step-by-step instructions on how to profile the application, see the [Profiling Workflow Guide](./profiling-workflow-guide.md).
 

react/modules/tasks/queries.md

@@ -121,7 +121,7 @@ This task is a continuation of the state management task. In this task, you will
   - Usage of _ts-ignore_: **-20 points per each**
   - Presence of _code-smells_ (God-object, chunks of duplicate code), commented code sections: **-10 points per each**
 
-- **2. Test Coverage**
+- **2. Test Coverage (one which applies)**
   - Statement coverage below 80% (≥70%): **-10 points**
   - Statement coverage below 70% (≥50%): **-30 points**
   - All coverage metrics below 50%: **-50 points**

react/modules/tasks/state-management.md

@@ -133,7 +133,7 @@
   - Presence of _code-smells_ (God-object, chunks of duplicate code), commented code sections: **-10 points per each**
   - ESLint or similar static analysis violations (errors, not warnings): **-5 points per violation**
 
-- **2. Test Coverage**
+- **2. Test Coverage (one which applies)**
   - Statement coverage below 80% (≥70%): **-10 points**
   - Statement coverage below 70% (≥50%): **-30 points**
   - All coverage metrics below 50%: **-50 points**

react/modules/tasks/tests.md

@@ -110,6 +110,22 @@ You must use **Jest** or **Vitest** as the test runner and **React Testing Libra
 
 ### Feature 6: User Interactions (**14 points**)
 
+**As a** developer
+**I want** to test all user interactions
+**So that** my components respond correctly
+
+**Scenario:** Test interactions
+
+- **Given** a component with user input
+- **When** the user interacts (clicks, submits, changes input)
+- **Then** the interaction is tested
+
+**Acceptance Criteria:**
+
+- All user interactions (clicks, input changes, form submissions, etc.) are covered by tests.
+- Tests verify that components respond correctly to user actions (e.g., updating state, calling callbacks, rendering changes).
+- Edge cases and invalid inputs are tested to ensure robust handling of user interactions.
+
 ### Feature 7: LocalStorage Functionality Testing (**16 points**)
 
 **As a** developer
@@ -129,22 +145,6 @@ You must use **Jest** or **Vitest** as the test runner and **React Testing Libra
 - Tests cover cases where localStorage is empty, contains a value, or is updated.
 - Tests ensure that localStorage integration does not break component behavior.
 
-**As a** developer
-**I want** to test all user interactions
-**So that** my components respond correctly
-
-**Scenario:** Test interactions
-
-- **Given** a component with user input
-- **When** the user interacts (clicks, submits, changes input)
-- **Then** the interaction is tested
-
-**Acceptance Criteria:**
-
-- All user interactions (clicks, input changes, form submissions, etc.) are covered by tests.
-- Tests verify that components respond correctly to user actions (e.g., updating state, calling callbacks, rendering changes).
-- Edge cases and invalid inputs are tested to ensure robust handling of user interactions.
-
 ## Technical Requirements
 
 1. **Branch Management**: Create a separate branch from "class-components". Branch name: **"unit-testing"**
@@ -188,7 +188,7 @@ You must use **Jest** or **Vitest** as the test runner and **React Testing Libra
 
 ### Penalties
 
-- **Absence of required features from the previous task (`class-components`) results in a penalty equal to the original feature's points:**
+- **1. Absence of required features from the previous task (`class-components`) results in a penalty equal to the original feature's points:**
   - Application Layout Structure: **-5 points**
   - Search Functionality with Local Storage: **-15 points**
   - Search Results Display: **-10 points**
@@ -198,24 +198,25 @@ You must use **Jest** or **Vitest** as the test runner and **React Testing Libra
   - Loading State Indication: **-10 points**
   - Error Handling: **-10 points**
   - Application Error Boundary: **-15 points**
-- **1. TypeScript & Code Quality**
+
+- **2. TypeScript & Code Quality**
   - TypeScript isn't used: **-95 points**
   - Usage of _any_: **-20 points per each**
   - Usage of _ts-ignore_: **-20 points per each**
   - Presence of _code-smells_ (God-object, chunks of duplicate code), commented code sections: **-10 points per each**
 
-- **2. Test Coverage**
+- **3. Test Coverage (one which applies)**
   - Statement coverage below 80% (≥70%): **-10 points**
   - Statement coverage below 70% (≥50%): **-30 points**
   - All coverage metrics below 50%: **-50 points**
 
-- **3. React Best Practices**
+- **4. React Best Practices**
   - Direct DOM manipulations inside the React components: **-50 points per each**
 
-- **4. External Dependencies**
+- **5. External Dependencies**
   - Usage of component libraries, e.g. Material UI, Ant Design: **-100 points**
 
-- **5. Project Management**
+- **6. Project Management**
   - Commits after the deadline: **-40 points**
   - Pull Request doesn't follow guideline (including checkboxes in Score) [PR example](https://rs.school/docs/mentoring/pull-request-review-process#pull-request-requirements-pr): **-10 points**