Apply suggestions from code review

Co-authored-by: apradoada <110429145+apradoada@users.noreply.github.com>

Author: kelsey-steven-ada

ada-project-docs/wave_01.md

@@ -67,7 +67,8 @@ Use the tests in `tests/test_wave_01.py` to guide your implementation.
 - Pay attention to the exact shape of the expected JSON. Double-check nested data structures and the names of the keys for any misspellings.
   - That said, remember that dictionaries do not have an implied order. This is still true in JSON with objects. When you make Postman requests, the order of the key/value pairings within the response JSON object does not need to match the order specified in this document. (The term "object" in JSON is analogous to "dictionary" in Python.)
 - Notice that the details for a Task in the response is shared across all the endpoints that return Task details. Rather than repeating the same literal `dict` structure in each response, we should create a helper method that returns the `dict` structure for a Task, and use it in each relevant endpoint. This will ensure that all our responses are consistent.
-- Retrieving a model by its ID is a common operation. We should create a route helper method that can retrieve a model by its ID, and use it in relevant routes. 
+- We should remember that retrieving a model by its ID is a common operation. We should consider creating a route helper method that can retrieve a model by its ID, and use it in all applicable routes. 
+    - This method could start out only working for Task models. But, knowing that we'll be working with Goal models later on, it might be worth generalizing this method to work with any model.
 
 ### CLI
 
@@ -156,8 +157,6 @@ As a client, I want to be able to make a `GET` request to `/tasks/1` when there
 }
 ```
 
-We should remember that retrieving a model by its ID is a common operation. We should consider creating a route helper method that can retrieve a model by its ID, and use it in this route. 
-- This method could start out only working for Task models. But, knowing that we'll be working with Goal models later on, it might be worth generalizing this method to work with any model.
 
 #### Update Task
 

ada-project-docs/wave_03.md

@@ -4,7 +4,7 @@
 
 Our task list API allows users to meaningfully use the task resource. Users want to be able to mark a task as "complete" or "incomplete."
 
-We want to design our API so that it stores a task's `completed_at` date as a datetime value in our database. In this scenario, our API does _not_ give users the `completed_at` date – it only gives the information if `is_complete` is `true` or `false`.
+We want to design our API so that it stores a task's `completed_at` date as a datetime value in our database. In this scenario, our API does _not_ give users the `completed_at` date – it only indicates whether `is_complete` is `true` or `false`.
 
 A task's `is_complete` is:
 - `true` when there is a datetime for the task's `completed_at` value.

ada-project-docs/wave_05.md

@@ -3,7 +3,7 @@
 ## Goal
 
 Our task list API should be able to work with an entity called `Goal`.
-- `Goal`s are entities that describe a task a user wants to complete.
+- `Goal`s are entities that describe a set of tasks a user wants to complete.
 - They contain a title to name the goal.
 
 Our plan for this wave is to be able to create, read, update, and delete different `Goal`s. We will create RESTful routes for these different operations.