Merge pull request #474 from codecrafters-io/fix-stages-for-llm-referencing-rule-tropicolx

Fix stages that don't follow the LLM referencing rule

Author: TropicolX

stage_descriptions/base-03-wy1.md

@@ -8,11 +8,11 @@ Redis clients to send multiple commands using the same connection.
 For this stage, your server should run a loop that continuously reads commands and sends responses back through the same connection. Since we're only dealing with the `PING` command for now, your program can run a loop that reads input and responds with `+PONG\r\n`.
 
 {{#lang_is_javascript}}
-In most languages, you'd need to write specific code to run this loop on your server. In JavaScript, however, if you're listening to the [`data`](https://nodejs.org/api/net.html#net_event_data) event, this should be automatically handled for you. **It is very likely that the code you used in the previous stage will pass this stage without any changes!**
+In most languages, you'd need to write specific code to run this loop on your server. In JavaScript, however, if you're listening to the [`data`](https://nodejs.org/api/net.html#net_event_data) event, this should be automatically handled for you. **It is very likely that the code you used in previous stages will pass this stage without any changes!**
 {{/lang_is_javascript}}
 
 {{#lang_is_typescript}}
-In most languages, you'd need to write specific code to run this loop on your server. In JavaScript, however, if you're listening to the [`data`](https://nodejs.org/api/net.html#net_event_data) event, this should be automatically handled for you. **It is very likely that the code you used in the previous stage will pass this stage without any changes!**
+In most languages, you'd need to write specific code to run this loop on your server. In JavaScript, however, if you're listening to the [`data`](https://nodejs.org/api/net.html#net_event_data) event, this should be automatically handled for you. **It is very likely that the code you used in previous stages will pass this stage without any changes!**
 {{/lang_is_typescript}}
 
 
@@ -24,7 +24,9 @@ The tester will execute your program like this:
 $ ./your_program.sh
 ```
 
-It will then send multiple `PING` commands using the same connection. For example, it might send:
+It will then send multiple `PING` commands using the same connection. 
+
+For example, it might send:
 
 ```bash
 $ echo -e "PING\nPING" | redis-cli

stage_descriptions/base-04-zu2.md

@@ -9,12 +9,12 @@ In most languages, you'd need to either use threads or implement an
 [Event Loop](https://en.wikipedia.org/wiki/Event_loop) to do this. In JavaScript, however, since [the concurrency
 model itself is based on an event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), most
 standard library functions are designed to support this kind of concurrent behaviour out of the box. **It is very
-likely that the code you had for the previous stage will pass this stage without any changes!**
+likely that the code you had for previous stages will pass this stage without any changes!**
 {{/lang_is_javascript}}
 
 {{#lang_is_typescript}}
 In most languages, you'd need to either use threads or implement an [Event Loop](https://en.wikipedia.org/wiki/Event_loop) to do this. In JavaScript, however, since [the concurrency
-model itself is based on an event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), most standard library functions are designed to support this kind of concurrent behaviour out of the box. **It is very likely that the code you had for the previous stage will pass this stage without any changes!**
+model itself is based on an event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), most standard library functions are designed to support this kind of concurrent behaviour out of the box. **It is very likely that the code you had for previous stages will pass this stage without any changes!**
 {{/lang_is_typescript}}
 
 {{^lang_is_javascript}}

stage_descriptions/base-06-la7.md

@@ -48,6 +48,6 @@ The tester will expect to receive `$3\r\nbar\r\n` as a response. That's the stri
 
 ### Notes
 
-- If you implemented a proper RESP parser in the previous stage, you should be able to reuse it in this stage.
-- Just like the previous stage, the values used for keys and values will be random, so you won't be able to hardcode the response to pass this stage.
-- If a key doesn't exist, the `GET` command should return a [null bulk string](https://redis.io/docs/latest/develop/reference/protocol-spec/#null-bulk-strings) (`$-1\r\n`). We won't explicitly test this in this stage, but you'll need it for the next stage.
+- If you implemented a proper RESP parser in previous stages, you should be able to reuse it in this stage.
+- Just like previous stages, the keys and values will be random, so you won't be able to hardcode the response to pass this stage.
+- If a key doesn't exist, the `GET` command should return a [null bulk string](https://redis.io/docs/latest/develop/reference/protocol-spec/#null-bulk-strings) (`$-1\r\n`). We won't explicitly test this in this stage, but you'll need it in later stages.

stage_descriptions/lists-04-sf6.md

@@ -69,5 +69,5 @@ c\r\n
 
 ### Notes
 
-- In this stage, you will only implement `LRANGE` with non-negative indexes. We will get to handling `LRANGE` for negative indexes in the next stage.
+- In this stage, you will only implement `LRANGE` with non-negative indexes. We will get to handling `LRANGE` for negative indexes in later stages.
 - If a list doesn't exist, `LRANGE` should respond with an empty RESP array (`*0\r\n`). 

stage_descriptions/lists-10-ec3.md

@@ -8,7 +8,7 @@ If the list is empty, the command blocks until:
 
 - A new element is added to the list
 - Or a specified timeout is reached.
-  
+
 If the timeout is `0`, the command blocks indefinitely.
 
 For example, a client can block on a list with an indefinite timeout like this:
@@ -88,4 +88,4 @@ The tester will expect your server to respond to the client that sent the `BLPOP
 
 ### Notes
 
-- In this stage, the timeout argument will always be `0`, meaning `BLPOP` should wait indefinitely. We'll handle non-zero timeouts in a later stage.
+- In this stage, the timeout argument will always be `0`, meaning `BLPOP` should wait indefinitely. We'll handle non-zero timeouts in later stages.

stage_descriptions/lists-11-xj7.md

@@ -9,7 +9,7 @@ $ redis-cli BLPOP list_key 0.5
 # (Blocks for 0.5 seconds)
 ```
 
-If an element is not available on the list within this time, the server returns a [null array](https://redis.io/docs/latest/develop/reference/protocol-spec/#null-arrays) (`*-1\r\n`). If an element is pushed to the list before the timeout, the command unblocks and returns the list key and the popped element as a RESP array, just as in the previous stage.
+If an element is not available on the list within this time, the server returns a [null array](https://redis.io/docs/latest/develop/reference/protocol-spec/#null-arrays) (`*-1\r\n`). If an element is pushed to the list before the timeout, the command unblocks and returns the list key and the popped element as a RESP array, just like with previous stages.
 
 ### Tests
 

stage_descriptions/persistence-rdb-03-gc6.md

@@ -1,6 +1,6 @@
 In this stage, you'll add support for reading the value corresponding to a key from an RDB file.
 
-Just like with the previous stage, we'll stick to supporting RDB files that contain a single key for now.
+Just like with previous stages, we'll stick to supporting RDB files that contain a single key for now.
 
 The tester will create an RDB file with a single key and execute your program like this:
 

stage_descriptions/replication-03-hc6.md

@@ -38,6 +38,6 @@ is a key-value pair separated by a colon (`:`). The tester will only look for th
 
 ### Notes
 
-- Your program still needs to pass the previous stage tests, so if `--replicaof` isn't specified, you should default to the `master` role.
-- Just like the last stage, you only need to support the `role` key in the response for this stage. We'll add support for the other keys in later stages.
+- Your program still needs to pass the tests for previous stages, so if `--replicaof` isn't specified, you should default to the `master` role.
+- Just like the previous stages, you only need to support the `role` key in the response for this stage. We'll add support for the other keys in later stages.
 - You don't need to actually connect to the master server specified via `--replicaof` in this stage. We'll get to that in later stages.

stage_descriptions/replication-04-xc1.md

@@ -39,4 +39,4 @@ Your program should respond with a [bulk string](https://redis.io/docs/latest/de
 
 ### Notes
 
-- Your code must pass previous stage tests, meaning you should still return the correct `role` key.
+- Your code must pass the tests for previous stages, meaning you should still return the correct `role` key.

stage_descriptions/replication-06-eh4.md

@@ -4,7 +4,7 @@ In this stage, you'll implement the second step of the replication handshake.
 
 As a recap, there are three steps to the handshake:
 
-1. The replica sends a `PING` to the master (Handled in the previous stage)
+1. The replica sends a `PING` to the master (Handled in previous stages)
 2. The replica sends `REPLCONF` twice to the master
 3. The replica sends `PSYNC` to the master