Fix spelling typos and markdown warnings

Just some minor fixes. Nothing special

Signed-off-by: Tim Smith <tsmith84@gmail.com>

docs/adr/2024-11-21_production-branching-strategy.md

@@ -55,7 +55,7 @@ The first step is to identify whether the work is destined for the current `prod
 1. Create a PR for changes into `production` branch
 1. Squash and merge PR into `production` branch
 1. Create a second PR from the `production` branch into `main` and resolve conflicts if needed. We are unable to automate this step at this time, but would like to merge into `main` on every PR in order to make the conflict resolution easier.
-   - Note: Regular merge (not "Squash and Merge") is recommended here 
+   - Note: Regular merge (not "Squash and Merge") is recommended here
 
 ##### For future features
 1. Check out `main` branch
@@ -81,7 +81,7 @@ The first step is to identify whether the work is destined for the current `prod
 #### Releases and Deployment
 - Cut releases from `main`
 - Deploy from `main`
-- Reserve a lower environment for regular dpeloyments from `future` for testing future features
+- Reserve a lower environment for regular deployments from `future` for testing future features
 - Continue these two branches throughout the year
 - When it is time to cutover to TY25 (December 2025 or January 2026), fork a new `main` branch from `future` and continue the same processes for the next tax year
 
@@ -94,7 +94,7 @@ The first step is to identify whether the work is destined for the current `prod
 1. Make PR against `main` branch
 1. Merge into `main` branch
 1. Create a second PR from the `main` branch into `future` and resolve conflicts if needed. We are unable to automate this step at this time, but would like to merge into `main` on every PR in order to make the conflict resolution easier.
-   - Note: Regular merge (not "Squash and Merge") is recommended here 
+   - Note: Regular merge (not "Squash and Merge") is recommended here
 
 ##### For future features
 1. Check out `future` branch

docs/adr/adr-css-preprocessor.md

@@ -6,16 +6,16 @@ Written: 20Jun2023
 CSS has some major problems. Namely, it:
 1. lacks variable names and the ability to import variables from other libraries.
 1. lacks nesting and other hierarchical structures that are common in components.
-1. is global (cascading!), leading to naming conflicts, difficult dead code detection, and difficult maintainbility in large code bases.
+1. is global (cascading!), leading to naming conflicts, difficult dead code detection, and difficult maintainability in large code bases.
 1. is constantly updated, and can have different implementations and minor differences between different browsers
 
-To avoid these issues, while adding additional features, most of the web development community uses one or more forms of CSS Preprocessor, preprocessing a superset of CSS into the CSS that will eventually reach the users' browsers. 
+To avoid these issues, while adding additional features, most of the web development community uses one or more forms of CSS Preprocessor, preprocessing a superset of CSS into the CSS that will eventually reach the users' browsers.
 
 ### Required Features
 1. Must be able to implement and rely on the US Web Design System (USWDS)
     1. Specifically, we need to interact with and rely on https://github.com/trussworks/react-uswds and https://github.com/uswds/uswds. Both of these systems use SASS and export SASS variables.
 1. Must be able to scope CSS, eliminating global classes
-1. Must help, not hinder, building an accessible product. 
+1. Must help, not hinder, building an accessible product.
 1. Must build output that runs without issue on popular phones and computers
 1. Must support mobile development and responsive design
 
@@ -26,19 +26,19 @@ To avoid these issues, while adding additional features, most of the web develop
 
 ## OSS Landscape
 There are a few CSS popular preprocessors:
-1. [SASS](https://sass-lang.com/), per their own marketing speak, defines themselves as "the most mature, stable, and powerful professional grade CSS extension language in the world." Sass has ~10m weekly downloads on NPM and is increasing in number of downloads.  
-1. [LESS](https://lesscss.org/) is the main competitor to SASS, and contains many of the same features.  Less has ~4m weekly downloads on NPM and is flat in number of downloads. 
-1. [PostCSS](https://postcss.org/) converts modern css into something most browsers can understand, placing polyfills in place. PostCSS is not a separate languagea -- it's a compile step like babel for greater compatibility. Stylelint and other tools are built on PostCSS
-1. [CSS Modules](https://github.com/css-modules/css-modules) provide local scoping for CSS. Styles are defined in a normal css/less/sass file, then are imported into the React components that use those classes. 
-1. [Tailwind](https://tailwindcss.com/) is noteable for being slightly different than other popular CSS frameworks, and is a css framework -- rather than a preprocessor -- that encourages stylistic, rather than semanetic, classnames directly in markup. It's gaining popularity rapidly (4.7m downloads/wk, up from 3m downloads/wk a year ago). However, it would be hard to integrate with USWDS. 
+1. [SASS](https://sass-lang.com/), per their own marketing speak, defines themselves as "the most mature, stable, and powerful professional grade CSS extension language in the world." Sass has ~10m weekly downloads on NPM and is increasing in number of downloads.
+1. [LESS](https://lesscss.org/) is the main competitor to SASS, and contains many of the same features.  Less has ~4m weekly downloads on NPM and is flat in number of downloads.
+1. [PostCSS](https://postcss.org/) converts modern css into something most browsers can understand, placing polyfills in place. PostCSS is not a separate language -- it's a compile step like babel for greater compatibility. Stylelint and other tools are built on PostCSS
+1. [CSS Modules](https://github.com/css-modules/css-modules) provide local scoping for CSS. Styles are defined in a normal css/less/sass file, then are imported into the React components that use those classes.
+1. [Tailwind](https://tailwindcss.com/) is notable for being slightly different than other popular CSS frameworks, and is a css framework -- rather than a preprocessor -- that encourages stylistic, rather than semantic, classnames directly in markup. It's gaining popularity rapidly (4.7m downloads/wk, up from 3m downloads/wk a year ago). However, it would be hard to integrate with USWDS.
 1. [Stylelint](https://stylelint.io/) is a CSS linter used to prevent bugs and increase maintainability of CSS
 
 
 ## Decision
 We should run the following CSS Preprocessors:
-1. Our CSS Language should be SASS, given its popularity and interoperability with USWDS. Most critically, we can import variable names from USWDS. 
-1. We should additionally use SASS Modules to scope our CSS to their components, avoiding global cascades. 
-1. We should use stylelint with its recommended config. We should also use the [a11y](https://www.npmjs.com/package/@ronilaukkarinen/stylelint-a11y) plugin experimentally to see if it helps us with accesibility (though noting that it seems not well supported and we should be willing to drop it).
+1. Our CSS Language should be SASS, given its popularity and interoperability with USWDS. Most critically, we can import variable names from USWDS.
+1. We should additionally use SASS Modules to scope our CSS to their components, avoiding global cascades.
+1. We should use stylelint with its recommended config. We should also use the [a11y](https://www.npmjs.com/package/@ronilaukkarinen/stylelint-a11y) plugin experimentally to see if it helps us with accessibility (though noting that it seems not well supported and we should be willing to drop it).
 1. Following our SASS compilation step, we should run postcss to get down to a supported list of browsers that we support via [browserlist](https://github.com/browserslist/browserslist#readme)
 
-Unsurprisingly, when developing for these criteria (and with a sigh of relief that USWDS uses SASS), this is the same CSS stack used by [Create React App](https://create-react-app.dev/docs/adding-a-css-modules-stylesheet). 
+Unsurprisingly, when developing for these criteria (and with a sigh of relief that USWDS uses SASS), this is the same CSS stack used by [Create React App](https://create-react-app.dev/docs/adding-a-css-modules-stylesheet).

docs/adr/adr-screener-config-update.md

@@ -7,7 +7,7 @@
 ## Context and Problem Statement
 
 [//]: # ([Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.])
-A decision was made in [adr-screener-config](./adr-screener-config.md) to use Astro SSG (static site generator) for the screener application. It was initially used for an MVP, and later replaced with React/Vite. This adr is to document that change and supercede the previous adr. 
+A decision was made in [adr-screener-config](./adr-screener-config.md) to use Astro SSG (static site generator) for the screener application. It was initially used for an MVP, and later replaced with React/Vite. This adr is to document that change and supersede the previous adr.
 
 ## Decision Drivers
 
@@ -25,8 +25,8 @@ Chosen option: "React/Vite", because it was consistent with the client app and t
 
     - More dynamic content is an option
     - We can easily utilize react-uswds library.
-    - The i18n system is aligned in both the screener and the client app. 
-    - Engineers don't need to learn multiple systems and can seemlessly develop between the two apps. Onboarding for new engineers is simplified.
+    - The i18n system is aligned in both the screener and the client app.
+    - Engineers don't need to learn multiple systems and can seamlessly develop between the two apps. Onboarding for new engineers is simplified.
 
 ### Negative Consequences
 

docs/adr/adr_a11y-target.md

@@ -16,7 +16,7 @@ informed: "All project technical staff"
 
 In supporting a critical task for all U.S. residents, Direct File should be accessible. This decision record sets a clear target for this phase of development to meet those accessibility needs, and we expect to exceed that target when feasible.
 
-The U.S. describes its accessiblity requirements in [Section 508](https://www.section508.gov/) of the Rehabilitation Act. [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) provides the same for the internet at large with three levels of compliance (A, AA, AAA), and it has increased in minor versions (2.0, 2.1, 2.2) over the last 15 years. 508 and WCAG have a [very large overlap](https://www.access-board.gov/ict/#E207.2), and all non-overlapping features unique to 508 are either irrelevant to this project (e.g. manual operation and hardware) or out of this repo's scope (e.g. support channels). See the note in "More Information" below for further information.
+The U.S. describes its accessibility requirements in [Section 508](https://www.section508.gov/) of the Rehabilitation Act. [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) provides the same for the internet at large with three levels of compliance (A, AA, AAA), and it has increased in minor versions (2.0, 2.1, 2.2) over the last 15 years. 508 and WCAG have a [very large overlap](https://www.access-board.gov/ict/#E207.2), and all non-overlapping features unique to 508 are either irrelevant to this project (e.g. manual operation and hardware) or out of this repo's scope (e.g. support channels). See the note in "More Information" below for further information.
 
 Given these equivalencies, all considered options are oriented toward WCAG and achieve 508 compliance.
 
@@ -38,7 +38,7 @@ Chosen option: "WCAG 2.2 AA (forward-thinking)", because it ensures we meet our
 * Good, because it challenges us to maximize WCAG at level AAA
 * Good, because it sets Direct File up with the latest a11y guidance for years to come
 * Good, because it doesn't require any more work than WCAG 2.1 AA with our current design
-* Neutral, because it may require slighly more work than the bare minimum in the future
+* Neutral, because it may require slightly more work than the bare minimum in the future
 * Neutral, some automated a11y tools don't yet support 2.2 (as of Oct 2023)
 
 ### Confirmation
@@ -65,7 +65,7 @@ This decision to exceed 508 requirements is confirmed by the IRS' 508 Program Of
 * Good, because it establishes and exceeds 508 compliance
 * Good, because it is easy to remember the level expected of all elements (i.e. "what needs level A vs AA?")
 * Good, because it challenges us to maximize WCAG at level AAA
-* Neutral, because it may require slighly more work than the bare minimum
+* Neutral, because it may require slightly more work than the bare minimum
 * Neutral, because it is an outdated version (see "more information" below)
 
 ### WCAG 2.2 AA (forward-thinking)
@@ -75,7 +75,7 @@ This decision to exceed 508 requirements is confirmed by the IRS' 508 Program Of
 * Good, because it challenges us to maximize WCAG at level AAA
 * Good, because it sets Direct File up with the latest a11y guidance for years to come
 * Good, because it doesn't require any more work than WCAG 2.1 AA with our current design
-* Neutral, because it may require slighly more work than the bare minimum in the future
+* Neutral, because it may require slightly more work than the bare minimum in the future
 * Neutral, some automated a11y tools don't yet support 2.2 (as of Oct 2023)
 
 ## More Information

docs/adr/adr_email_submit_error.md

@@ -1,16 +1,16 @@
 ## Overview
+
 There are two main scenarios that, as it currently stands, the combination of our incident response (IR) practices and customer support (CS) motion do not support:
 
         a) A taxpayer hits submit but an XMl validation failure occurs and they cannot submit at all. CS is unavailable (for whatever reason) and they give up attempting to submit with Direct File.
         b) A taxpayer submits successfully, but an internal error occurs in the Submit application that blocks our ability to send their return to MeF. CS is not involved because, presumbly, the taxpayer never reached out to CS in the first case as they didn't run into any errors when hitting submit.
 
-Our inability to reach out to taxpayers proactively is primarily due to the fact that CS can only reach out to taxpayer who reach out to them first via eGAIN. 
+Our inability to reach out to taxpayers proactively is primarily due to the fact that CS can only reach out to taxpayer who reach out to them first via eGAIN.
 
 In the above scenarios, neither taxpayer knows 1) if the issue they ran into has/will be fixed; and 2) if so, that they should resubmit their return. As a result, they are effectively left in the dark and/or knocked out of the filing with Direct File, thereby forcing them to submit elsewhere.
 
 While our scale to-date (as of 2/26) has shielded us from the pain of these scenarios, or alleviated them altogether, we don't have a clear way to address them at this moment. Further, there is a very high likelihood that these scenarios will occur over the coming weeks and will become especially painful if/when the submission volume scales dramatically faster than our CS capabilities.
 
-
 ## Proposals
 
 While we cannot change our CS motion to support this, we can enable a better product experience through how we notify taxpayers via email when an error occurs in our system.
@@ -21,14 +21,13 @@ We should notify taxpayers via email that there was an error submitting their re
 ### Notify taxpayers when Direct File has deployed a fix that should allow them to resubmit their return
 We should also notify taxpayers via email that they are able to submit their return when we have deployed a fix into production that addresses the error that blocked them from submitting in the first place.
 
-
 ### Proposed Technical Changes (Rough)
 
 1. Add two new HTML Templates to capture the two notification scenarios above, e.g. SubmissionErrorTemplate and ErrorResolvedTemplate. The templates should be added to the backend app, such that the ConfirmationService can process it, as well as the actual HTML template in the email app that is sent via email and rendered to the taxpayer
 2. When an XML validation failure occurs during submission  create a `SubmissionEvent` with an `eventType` of `error_xml` and enqueue a message from the backend to the email app to notify the user (naming of the eventType is TBD, might make sense to add a new `message` column and keep the eventType as `error`)
-3. Update the SQS message sent from submit -> backend (on the submission confirmation queue) to allow for an `error` status. If the ConfirmationService and SendService are properly configured as per #1 above, everything should flow seemlessly. Similar to #2, create a `SubmissionEvent` with an `eventType` of `error_mef` for each submission that failed to submit to MeF (naming of the eventType is TBD, might make sense to add a new `message` column and keep the eventType as `error`)
+3. Update the SQS message sent from submit -> backend (on the submission confirmation queue) to allow for an `error` status. If the ConfirmationService and SendService are properly configured as per #1 above, everything should flow seamlessly. Similar to #2, create a `SubmissionEvent` with an `eventType` of `error_mef` for each submission that failed to submit to MeF (naming of the eventType is TBD, might make sense to add a new `message` column and keep the eventType as `error`)
 4. Add a function to the backend that, when called, ingests a CSV of `taxReturnIds`, transforms the list into a SubmissionStatusMessage and calls ConfirmationService.handleStatusChangeEvent
 5. Once a deploy goes out that fixes the underlying issue, create a CSV with `taxReturnIds` of the affected taxpayers (both those who reached out to CS and those who did not) using Splunk queries
 6. Send this CSV to IEP and ask 1) their System Admin to run the command specified in #4; or 2)have them upload it to S3 and do something similar to the email allow list such that the function specified in #4 polls S3 and sends emails based off this polling. This second approach would require more state management but would possibly cut out the need for IEP to run commands and maybe obviate the need for a p2 to make this happen.
 7. Add monitoring in place to observe the emails being sent out accordingly
-8. [Alternative] We move the 'submitted' email to send only after we receive submission confirmation, not after we pass XML validation
+8. [Alternative] We move the 'submitted' email to send only after we receive submission confirmation, not after we pass XML validation

docs/adr/data-import-redux.md

@@ -1,7 +1,9 @@
 # Data Import Redux
+
 Date: 5 Nov 2024
 
 ## Context
+
 To facilitate the correctness of the frontend data import system, we will use redux to coalesce data from APIs.
 
 Data Import has many lifetimes that are independent of traditional timeframes from the app. Data fetches get kicked off, data returns later, data gets validated as ready for import all independently of user action.
@@ -14,21 +16,21 @@ Data Import will use the Redux Library to make it easier for us to manage changi
 
 We will write logic in redux to transform data as it comes in so that the frontend knows when to use it.
 
-
 # Alternatives Considered
 
 ## React Context and Fact Graph
 
-- Lack of chained actions - because we expect data from different sections (about you, IP PIN, w2) to come in at different times, we need to be able to chain /retry fetches and coalsce them into one structure. Redux makes this much easier than alternatives considered.
+- Lack of chained actions - because we expect data from different sections (about you, IP PIN, w2) to come in at different times, we need to be able to chain /retry fetches and coalesce them into one structure. Redux makes this much easier than alternatives considered.
 - Limits blast radius - with data coming in and out while people are on other screens, redux provides much better APIs to avoid rerenders on API calls that are not relevant to the current screen.
 
 # Other Libraries
 
-I looked briefly at Recoil, MobX, Zustand and Jotai but they all seemed geared at simpler apps. Some of Data Import's initial features (e.g. knowing if more than a second has elapsed during a request) are much easier to impliment in redux based on my prototyping. Secondly, Redux is so well used that nobody ever got fired for using redux :P
+I looked briefly at Recoil, MobX, Zustand and Jotai but they all seemed geared at simpler apps. Some of Data Import's initial features (e.g. knowing if more than a second has elapsed during a request) are much easier to implement in redux based on my prototyping. Secondly, Redux is so well used that nobody ever got fired for using redux :P
 
 # Future Uses
 
 Redux has a few key advantages over things we have in our codebase right now:
+
 - Automatically manages the render cycle more efficiently (important as our react tree grows ever larger)
 - Proven at scale with complex application state
 - Well known in the industry with a good tooling eco system