docs: verifier renamed to flow

docs/configuration/transit-agency.md

@@ -7,15 +7,15 @@ Then, the following steps are done by the Cal-ITP team to configure a new transi
 Note that a `TransitAgency` model requires:
 
 - a list of supported `EligibilityType`s
-- a list of `EligibilityVerifier`s used to verify one of those supported eligibility types
+- a list of `EnrollmentFlows`s available to the agency's users
 - a `TransitProcessor` for enrolling the user's contactless card for discounts
 - an `info_url` and `phone` for users to contact customer service
 - an SVG or PNG file of the transit agency's logo
 - HTML templates for various buttons, text and other user interface elements of the flow, including:
   - `index_template`: _Required for agencies_ - Text for agency direct entry page
   - `eligibility_index_template`: _Required for agencies_ - Text for Eligibility Index page
-  - `selection_label_template`: _Required for verifiers_ - Text and optional modals for the radio button form on the Eligibility Index page
-  - `eligibility_start_template`: _Required for verifiers_ - Text and optional custom styles for call to action button on the Eligibility Start page
+  - `selection_label_template`: _Required for enrollment flows_ - Text and optional modals for the radio button form on the Eligibility Index page
+  - `eligibility_start_template`: _Required for enrollment flows_ - Text and optional custom styles for call to action button on the Eligibility Start page
   - `enrollment_success_template`: _Required for agencies_ - Text for Enrollment Success page
   - `help_template`: _Required for agencies_ - Agency-specific help questions and answers
   - `sign_out_button_template`: _Required for claims providers_ - Sign out link button, used on any page after sign in
@@ -31,8 +31,8 @@ For development and testing, only a Littlepay customer group is needed since the
 
 1. Cal-ITP uses the transit agency's Littlepay merchant ID to create a customer group in the Littlepay QA environment for each type of eligibility (e.g. senior).
 1. For each group that's created, a group ID will be returned and should be set as the `group_id` on a new `EligibilityType` in the Benefits database. (See [Configuration data](../data/) for more on loading the database.)
-1. Cal-ITP creates a new `EligibilityVerifier` in the database for each supported eligibility type. This will require configuration for either [API](https://docs.calitp.org/eligibility-api/specification/)-based verification or verification through an [OAuth Open ID Connect provider](../oauth/) (e.g. sandbox Login.gov) -- either way, this resource should be meant for testing.
-1. Cal-ITP creates a new `TransitAgency` in the database and associates it with the new `EligibilityType`s and `EligibilityVerifier`s as well as the existing Littlepay `TransitProcessor`.
+1. Cal-ITP creates a new `EnrollmentFlow` in the database for each supported eligibility type. This will require configuration for either [API](https://docs.calitp.org/eligibility-api/specification/)-based verification or verification through an [OAuth Open ID Connect claims provider](../oauth/) (e.g. sandbox Login.gov) -- either way, this resource should be meant for testing.
+1. Cal-ITP creates a new `TransitAgency` in the database and associates it with the new `EligibilityType`s and `EnrollmentFlow`s as well as the existing Littlepay `TransitProcessor`.
 
 ## Configuration for production validation
 
@@ -45,9 +45,9 @@ For production validation, both a customer group and discount product are needed
 1. Cal-ITP creates a customer group **for testing purposes** in production Littlepay.
 1. Cal-ITP associates the group with the product.
 1. Cal-ITP creates a new `EligibilityType` **for testing purposes** in the Benefits database and sets the `group_id` to the ID of the newly-created group.
-1. Cal-ITP creates a new `EligibilityVerifier` with configuration **for a testing environment** to ensure successful eligibility verification. (For example, use sandbox Login.gov instead of production Login.gov.)
+1. Cal-ITP creates a new `EnrollmentFlow` with configuration **for a testing environment** to ensure successful eligibility verification. (For example, use sandbox Login.gov instead of production Login.gov.)
 1. Cal-ITP creates a new `TransitProcessor` **for testing purposes** with configuration for production Littlepay.
-1. Cal-ITP updates the existing `TransitAgency` (created [previously](#configuration-for-development-and-testing)) with associations to the eligibility types, verifiers, and transit processor that were just created for testing.
+1. Cal-ITP updates the existing `TransitAgency` (created [previously](#configuration-for-development-and-testing)) with associations to the eligibility types, enrollment flows, and transit processor that were just created for testing.
 
 At this point, Cal-ITP and transit agency staff can coordinate to do on-the-ground testing where a live card is tapped on a live payment validator.
 
@@ -67,13 +67,13 @@ Once production validation is done, the transit agency can be added to the produ
 1. Cal-ITP creates a customer group **for production use** in production Littlepay.
 1. Cal-ITP associates the group with the discount product created [previously during production validation](#configuration-for-production-validation).
 1. Cal-ITP sets that group's ID as the `group_id` for a new `EligibilityType` in the Benefits database.
-1. Cal-ITP creates a new `EligibilityVerifier` with configuration for the **production** eligibility verification system.
-1. Cal-ITP creates a new `TransitAgency` in the database with proper associations to eligibility types, verifiers, and transit processor.
+1. Cal-ITP creates a new `EnrollmentFlow` with configuration for the **production** eligibility verification system.
+1. Cal-ITP creates a new `TransitAgency` in the database with proper associations to eligibility types, enrollment flows, and transit processor.
 
 ### Cleanup
 
 At this point, the customer group that was created in production Littlepay for testing purposes can be deleted. The temporary production validation objects in the Benefits database can also be deleted.
 
 1. Remove the association between the test customer group and discount product.
 1. Delete the test customer group.
-1. Remove temporary `EligibilityType`s, `EligibilityVerifier`s, and `TransitProcessor` that were [created](#steps_1) in the Benefits test environment.
+1. Remove temporary `EligibilityType`s, `EnrollmentFlow`s, and `TransitProcessor` that were [created](#steps_1) in the Benefits test environment.

docs/development/commits-branches-merging.md

@@ -65,13 +65,13 @@ PR branches are typically named with a [conventional type][conventional-commits]
 E.g.
 
 ```bash
-git checkout -b feat/verifier-radio-buttons
+git checkout -b feat/flow-multi-select
 ```
 
 and
 
 ```bash
-git checkout -b refactor/verifier-model
+git checkout -b refactor/flow-model
 ```
 
 PR branches are deleted once their PR is merged.