Flag and suggest alternatives for common mispellings (#652)

* Flag and suggest alternatives for common mispellings

* Fix spelling

_articles/annual-certificate-rotation.md

@@ -41,7 +41,7 @@ Rotating the certificates happens in two phases: first adding the new certificat
 	 saml_endpoint_configs: '[{"suffix":"2021","secret_key_passphrase":"XXXXXXXXXXXX"},{"suffix":"2022","secret_key_passphrase":"XXXXXXXXXXXX"}]'
 	 ```
     - Recycle the env to make new configs take effect.
-4. Confirm the new endpoint is live by going to `/api/saml/metadata20XX` in that environment's idp.
+4. Confirm the new endpoint is live by going to `/api/saml/metadata20XX` in that environment's IdP.
 5. New SAML 20XX has been tested using a new test app on the Dashboard
     - Create a new "SAML 20XX" test app on <https://dashboard.int.identitysandbox.gov/> to test the new certificate endpoints.
 

_articles/appdev-acuant-sdk-test-plan.md

@@ -10,16 +10,16 @@ toc_h_max: 4
 ## General Information
 
 Automated testing of the Acuant SDK, used for capturing pictures of a user's ID and face, is not
-currently available. Prior to each bi-weekly deploy, Team Timnit wants to manually verify that the 
+currently available. Prior to each bi-weekly deploy, Team Timnit wants to manually verify that the
 SDK is functioning as expected.
 
 ### Cadence
 
 **When to test:** ✅
 
-Manual testing should be done prior to the regular full deploy of IDP to `prod`. Typically we do a
+Manual testing should be done prior to the regular full deploy of IdP to `prod`. Typically we do a
 full deploy twice weekly, on Tuesdays and Thursdays - see
-[Deploying new IDP and PKI code]({% link _articles/appdev-deploy.md %}) for
+[Deploying new IdP and PKI code]({% link _articles/appdev-deploy.md %}) for
 details and up-to-date cadence.
 
 ### Test Procedure
@@ -28,7 +28,7 @@ details and up-to-date cadence.
   Dashboard.
   - Under Staging, click on either the `oidc-sinatra` or the `saml-sinatra` links
     to go to a sample app.
-  - Note the git sha of the idp in `staging`.
+  - Note the git sha of the IdP in `staging`.
 - From the sample app, under `Options > Level of Service`, select `Biometric Comparison`,
   then click `Sign in`.
 - From the Login.gov sign in page, choose `Create an account`, enter your email with a modifier
@@ -52,7 +52,7 @@ conducting the test, react to the reminder with 👀 and reply in thread with:
 - The path to document capture
   - hybrid (start on desktop, switch to phone for capture)
   - standard (start on phone)
-- The git sha of the idp tested (available from the Environment status page)
+- The git sha of the IdP tested (available from the Environment status page)
 - Any issues encountered!
 
 If an issue is found, we need to work quickly to triage and determine if the problem is being

_articles/appdev-deploy.md

@@ -1,5 +1,5 @@
 ---
-title: "Deploying new IDP and PKI code"
+title: "Deploying new IdP and PKI code"
 layout: article
 description: "Release Manager's Guide for Production"
 category: AppDev
@@ -50,7 +50,7 @@ When deploying a new release, the release manager should make sure to deploy new
 - [18f/identity-idp](https://github.com/18f/identity-idp)
 - [18f/identity-pki](https://github.com/18f/identity-pki)
 
-This guide is written for the idp, but also applies to the pivcac (identity-pki) server.
+This guide is written for the IdP, but also applies to the pivcac (identity-pki) server.
 
 This guide assumes that:
 - You have a [GPG key set up with GitHub](https://help.github.com/en/github/authenticating-to-github/adding-a-new-gpg-key-to-your-github-account) (for signing commits)
@@ -70,7 +70,7 @@ Once you've run through proofing in staging, the next step is to cut a release f
 
 #### Cut a release branch
 
-##### IDP
+##### IdP
 
 ###### Prerequisites
 
@@ -172,7 +172,7 @@ Staging used to be deployed by this process, but this was changed to deploy the
    aws-vault exec prod-power -- ./bin/ls-servers -e prod
    aws-vault exec prod-power -- ./bin/asg-size prod idp
    ```
-5. Recycle the IDP instances to get the new code. It automatically creates a new migration instance first.
+5. Recycle the IdP instances to get the new code. It automatically creates a new migration instance first.
    ```bash
    aws-vault exec prod-power -- ./bin/asg-recycle prod idp
    ```
@@ -201,7 +201,7 @@ Staging used to be deployed by this process, but this was changed to deploy the
 
    Check the log output to make sure that `db:migrate` runs cleanly. Check for `All done! provision.sh finished for identity-devops` which indicates everything has run
 
-   2. Follow the progress of the IDP hosts spinning up
+   2. Follow the progress of the IdP hosts spinning up
 
       ```bash
       aws-vault exec prod-power -- ./bin/ls-servers -e prod -r idp # check the load balance pool health
@@ -234,9 +234,9 @@ Staging used to be deployed by this process, but this was changed to deploy the
 
 #### Creating a Release (Production only)
 
-##### IDP
+##### IdP
 
-The IDP includes a script to create a release based on a merged pull request.  It relies on [`gh`](https://cli.github.com/), the Github cli. Install that first (`brew install gh`) and get it connected to the identity-idp repo. Then, run the script to create a release:
+The IdP includes a script to create a release based on a merged pull request.  It relies on [`gh`](https://cli.github.com/), the GitHub cli. Install that first (`brew install gh`) and get it connected to the identity-idp repo. Then, run the script to create a release:
 
 ```shell
 scripts/create-release <PR_NUMBER>
@@ -260,7 +260,7 @@ Where `<PR_NUMBER>` is the number of the _merged_ PR.
 
 #### Rolling Back
 
-It's safer to roll back the IDP to a known good state than leave it up in a possibly bad one.
+It's safer to roll back the IdP to a known good state than leave it up in a possibly bad one.
 
 Some criteria for rolling back:
 - Is the error visible for users?
@@ -323,7 +323,7 @@ new configurations (config from S3).
    aws-vault exec prod-power -- ./bin/asg-recycle prod idp
    ```
 
-1. In production, it's important to remember to still scale out old IDP instances.
+1. In production, it's important to remember to still scale out old IdP instances.
 
     ```bash
     aws-vault exec prod-power -- ./bin/scale-remove-old-instances prod ALL
@@ -336,7 +336,7 @@ When responding to a production incident with a config change, or otherwise in a
 aws-vault exec prod-power -- ./bin/asg-recycle prod idp --skip-migration
 ```
 
-1. In production, remove old IDP instances afterward
+1. In production, remove old IdP instances afterward
 ```bash
 aws-vault exec prod-power -- ./bin/scale-remove-old-instances prod ALL
 ```

_articles/appdev-proofing-ruby-worker-jobs.md

@@ -11,7 +11,7 @@ cSpell: ignore PSQL
 
 ## Overview
 
-To minimize long-running requests in the IDP, we've moved calls that talk to vendors
+To minimize long-running requests in the IdP, we've moved calls that talk to vendors
 to background jobs. We have implemented those background jobs as jobs using
 [GoodJob](https://github.com/bensheldon/good_job).
 
@@ -25,18 +25,18 @@ We currently use proofing jobs for PII verification.
 
 The lifecycle of a job:
 
-1. The user submits a form to the IDP
+1. The user submits a form to the IdP
     - For PII verification jobs, the payload will contain PII:
         - First name
         - Last name
         - Date of Birth
         - SSN
         - Driver's license number
         - Address
-1. The IDP will enqueue a background job
+1. The IdP will enqueue a background job
     - Job parameters are persisted to the PSQL database
-    - Sensitive parameters are symmetrically encrypted by a server-side IDP key (see notes on [server-side encryption](#server-side-encryption))
-1. The IDP will show a waiting page to the user
+    - Sensitive parameters are symmetrically encrypted by a server-side IdP key (see notes on [server-side encryption](#server-side-encryption))
+1. The IdP will show a waiting page to the user
 1. The Worker host polls the background jobs table. When it pulls a job:
     - Writes to the jobs table to mark the job as claimed
     - It will make HTTP requests via our outbound proxy to vendors
@@ -51,10 +51,10 @@ The lifecycle of a job:
         - Date of Birth
         - Driver's license number
         - Address
-1. The user waiting page will be polling for the result of the background job, where the IDP will
+1. The user waiting page will be polling for the result of the background job, where the IdP will
    check Redis for the result for that particular job. Once it is complete, the user will continue
    to the next step of the flow.
-    - If after 60 seconds the IDP has not seen a response for the job, the IDP will decide the job
+    - If after 60 seconds the IdP has not seen a response for the job, the IdP will decide the job
       has timed out, and show an error screen to the user, giving them an option to retry.
 
 ### Server-Side Encryption
@@ -67,26 +67,26 @@ pulled down when the app launches and read into memory.
 
 ### Logging
 
-Logging for the workers will go to `log/production.log` just like the IDP web hosts,
+Logging for the workers will go to `log/production.log` just like the IdP web hosts,
 which will be ingested into Cloudwatch.
 
 GoodJob logs job durations by default.
 
 ## Deploys
 
-The code for the workers lives in the same repository as the IDP, but is deployed to separate worker
+The code for the workers lives in the same repository as the IdP, but is deployed to separate worker
 instances.
 
 ## Configuration
 
 To enable ruby workers in an environment:
 
 1. Update the environment's [`application.yml`]({% link _articles/appdev-secrets-configuration.md %})
-  - Set **ruby_workers_idv_enabled**: `'true'` (this enables async for resolution, address jobs)
+  - Set **`ruby_workers_idv_enabled`**: `'true'` (this enables async for resolution, address jobs)
 2. Set terraform variables:
     - Positive worker sizes to be positive integers [(example pull request)](https://github.com/18F/identity-devops-private/pull/1513/files):
-        - **asg_worker_min**: 2
-        - **asg_worker_desired**: 2
-        - **asg_worker_max**: 8 (or something)
+        - **`asg_worker_min`**: 2
+        - **`asg_worker_desired`**: 2
+        - **`asg_worker_max`**: 8 (or something)
     - Enable worker alarms for alerting [(example pull request)](https://github.com/18F/identity-devops-private/pull/1514/files)
-        - **idp_worker_alarms_enabled**: 1
+        - **`idp_worker_alarms_enabled`**: 1

_articles/appdev-risc-ruby-worker-jobs.md

@@ -20,7 +20,7 @@ To minimize the impact of external HTTP requests on our application performance,
 The lifecycle of a job:
 
 1. User performs an action that triggers a notification (such as changing their MFA)
-2. IDP enqueues a job
+2. IdP enqueues a job
     - The JWT payload is constructed and signed in the foreground, and the entire payload body is persisted temporarily as a job argument
     - See [data](#data) for payload contents
 3. Worker host picks up the job and sends it
@@ -40,7 +40,7 @@ See the full list of [supported events and example payloads](https://developers.
 
 ## Deploys
 
-The code for the workers lives in the same repository as the IDP, but is deployed to separate worker
+The code for the workers lives in the same repository as the IdP, but is deployed to separate worker
 instances.
 
 ## Configuration

_articles/appdev-secrets-configuration.md

@@ -1,7 +1,7 @@
 ---
 title: "Secrets and Configuration"
 description: >
-  How to update IDP and Rails app configuration (feature flags) and secrets application.yml, and
+  How to update IdP and Rails app configuration (feature flags) and secrets application.yml, and
   how to use the `app-s3-secret` script
 layout: article
 category: "AppDev"
@@ -31,7 +31,7 @@ See [guide to app-s3-secret]({% link _articles/devops-scripts.md %}#app-s3-secre
 
 ## Configuration in Rails Apps
 
-To use a value in the `application.yml` in our Rails apps, follow these steps. The IDP, PKI,
+To use a value in the `application.yml` in our Rails apps, follow these steps. The IdP, PKI,
 and Dashboard apps all use this approach, with files named the same way.
 
 1. Declare the configuration value in `lib/identity_config.rb`'s `#build_store` method.

_articles/appdev-troubleshooting-production.md

@@ -1,6 +1,6 @@
 ---
 title: "Triage User Issues"
-description: Rails console scripts and Cloudwatch queries, for debugging the IDP
+description: Rails console scripts and Cloudwatch queries, for debugging the IdP
 layout: article
 category: AppDev
 ---

_articles/appdev-troubleshooting-sandbox.md

@@ -6,7 +6,7 @@ category: AppDev
 ---
 ## Prerequisites
 
-Follow the instructions in the [Troubleshooting the IDP]({% link _articles/appdev-troubleshooting-production.md %}) prerequisites section.
+Follow the instructions in the [Troubleshooting the IdP]({% link _articles/appdev-troubleshooting-production.md %}) prerequisites section.
 
 ## Purging a user's PII
 If a user accidentally uploads real PII to our sandbox environment, follow the steps below to delete it.

_articles/cloudwatch-101.md

@@ -46,7 +46,7 @@ You will need an AWS account and access. See [setting up aws-vault][aws-vault] f
 
 ![screenshot of the query interface for CloudWatch Insights]({{ site.baseurl }}/images/aws-cloudwatch-query.png)
 
-1. Make sure to select a log group. For most queries, we want **prod_/srv/idp/shared/log/events.log**. In the "Select up to 50 log groups" combobox, type in "events.log" to filter down the list and select the **prod_** one.
+1. Make sure to select a log group. For most queries, we want **`prod_/srv/idp/shared/log/events.log`**. In the "Select up to 50 log groups" combobox, type in "events.log" to filter down the list and select the **prod_** one.
 
 1. Set the time range. For consistency across timezones, we recommend the **UTC** timezone.
 

_articles/daily-deploy-schedule.md

@@ -1,6 +1,6 @@
 ---
 title: "Deploy Schedule for Automated Deploys"
-description: "The daily deploy schedule for IDP, PKI and Dashboard in lower environments"
+description: "The daily deploy schedule for IdP, PKI and Dashboard in lower environments"
 layout: article
 category: "AppDev"
 subcategory: "Deploying"
@@ -10,7 +10,7 @@ subcategory: "Deploying"
 
 These apps are deployed on weekdays:
 
-- IDP
+- IdP
 - PKI
 - Dashboard
 

_articles/deploying-sp-to-prod.md

@@ -84,7 +84,7 @@ You will need to specify the reason you are running the console.
   - `aws-vault exec prod-power -- ./bin/ssm-instance -d rails-c --any asg-prod-idp`
   - `sp = ServiceProvider.find_by(issuer: 'ISSUER_URN_HERE')`
   - `sp.attributes`
- 
+
 
 **Step 8:**
 
@@ -94,7 +94,7 @@ If config is updated as expected, and you needed to do a full recycle for a new/
 
 **Step 9:**
 
-Scale out old instances of prod-worker and prod-idp
+Scale out old instances of `prod-worker` and `prod-idp`
   - `aws-vault exec prod-power -- ./bin/scale-remove-old-instances prod ALL`
 
 **Step 10:**

_articles/devops-scripts.md

@@ -17,7 +17,7 @@ Before you can access any systems, you will need to [set up AWS-vault](https://g
 
 ## `app-s3-secret`
 
-These examples are for the IDP app in the `sandbox` AWS account and the `dev` environment:
+These examples are for the IdP app in the `sandbox` AWS account and the `dev` environment:
 
 ### Viewing Secrets
 
@@ -438,7 +438,7 @@ CREATE TABLE IF NOT EXISTS events (
   success INTEGER NULL,
   message TEXT NOT NULL,
   log_stream TEXT NULL,
-  log TEXT NULL  
+  log TEXT NULL
 )
 ```
 

_articles/github-gitlab.md

@@ -18,12 +18,12 @@ Some repositories in GitHub are mirrored from our self-hosted GitLab.
 
 - [**`18f/identity-idp`**](https://github.com/18f/identity-idp)<br />
   [secure.login.gov](https://secure.login.gov)<br />
-  IDP (main application)
+  IdP (main application)
 
 - [**`18f/identity-pki`**](https://github.com/18f/identity-pki)
   PIV/CAC application
 
-- [**`18f/identity-idp-config`**](https://github.com/18f/identity-idp-config) Service Provider (`service_providers.yml`) and Agency (`agencies.yml`) configuration repo that can be updated and deployed independently of the IDP.
+- [**`18f/identity-idp-config`**](https://github.com/18f/identity-idp-config) Service Provider (`service_providers.yml`) and Agency (`agencies.yml`) configuration repo that can be updated and deployed independently of the IdP.
 
 - [**`18f/identity-dashboard`**](https://github.com/18f/identity-dashboard)
   Partner Dashboard for viewing and editing service provider configurations (only in the INT environment).
@@ -44,22 +44,22 @@ Some repositories in GitHub are mirrored from our self-hosted GitLab.
   Provides an Omniauth strategy for Login.gov that helps other projects integrate with Login.gov more easily. Some use cases include the [identity-dashboard](https://github.com/18f/identity-dashboard) as well as Touchpoints, USMC and search.gov
 
 - [**`18f/identity-validations`**](https://github.com/18f/identity-validations)
-  Gem that provides shared validations for the ServiceProvider model across the IDP and dashboard
+  Gem that provides shared validations for the ServiceProvider model across the IdP and dashboard
 
 - [**`18f/identity-telephony`**](https://github.com/18f/identity-telephony){: .deprecated-link} (Archived)
-  Gem that provides a common interface for voice and SMS features across multiple vendor backends. This code has been moved into the IDP codebase.
+  Gem that provides a common interface for voice and SMS features across multiple vendor backends. This code has been moved into the IdP codebase.
 
 - [**`18f/identity-doc-auth`**](https://github.com/18f/identity-doc-auth){: .deprecated-link} (Archived)
-  Provides a library for performing document authentication. This code has been moved into the IDP codebase.
+  Provides a library for performing document authentication. This code has been moved into the IdP codebase.
 
 - [**`18f/identity-proofer-gem`**](https://github.com/18f/identity-proofer-gem){: .deprecated-link} (Archived)
-  Provides a generic interface around identity proofing (IDV, identity verification) that is implemented by other proofers. This code has been moved into the IDP codebase.
+  Provides a generic interface around identity proofing (IDV, identity verification) that is implemented by other proofers. This code has been moved into the IdP codebase.
 
 - [**`18f/identity-lexisnexis-api-client-gem`**](https://github.com/18f/identity-lexisnexis-api-client-gem){: .deprecated-link} (Archived)
-  Implementation of the identity-proofer interface for LexisNexis. This code has been moved into the IDP codebase.
+  Implementation of the identity-proofer interface for LexisNexis. This code has been moved into the IdP codebase.
 
 - [**`18f/identity-aamva-api-client-gem`**](https://github.com/18f/identity-aamva-api-client-gem){: .deprecated-link} (Archived)
-  Implementation of the identity-proofer interface for AAMVA for drivers licenses. This code has been moved into the IDP codebase.
+  Implementation of the identity-proofer interface for AAMVA for drivers licenses. This code has been moved into the IdP codebase.
 
 ### Example Applications
 

_articles/google-analytics.md

@@ -7,9 +7,9 @@ category: Reporting
 
 ## What even is?
 
-We use the [Digital Analytics Program](https://digital.gov/guides/dap/) for web analytics on the brochure site and select portions of the IDP.
+We use the [Digital Analytics Program](https://digital.gov/guides/dap/) for web analytics on the brochure site and select portions of the IdP.
 
 ## Requesting access
 
 1. Follow instructions on [Gaining Access to the Data](https://digital.gov/guides/dap/gaining-access-to-dap-data/)
-2. Drop a request in [#analytics](https://gsa-tts.slack.com/archives/C02AK9NKP) ([example message](https://gsa-tts.slack.com/archives/C02AK9NKP/p1670014384059339)) requesting that you be added to the "Login.gov section of TTS Google Analytics". 
+2. Drop a request in [#analytics](https://gsa-tts.slack.com/archives/C02AK9NKP) ([example message](https://gsa-tts.slack.com/archives/C02AK9NKP/p1670014384059339)) requesting that you be added to the "Login.gov section of TTS Google Analytics".