Standardize on sentence case headings

README.md

@@ -2,7 +2,7 @@
 
 A minimal Django app for form submission and review. The Django project lives under `efile_app/` with settings in `efile_app/efile/`.
 
-## Quick Start
+## Quick start
 
 - __Requirements__
   - Python 3.10+
@@ -73,11 +73,11 @@ Deactivate with `deactivate` when you're done.
 - __Static files__
   During development, static files are served automatically. No `collectstatic` is needed.
 
-## AWS S3 Setup (Required for File Uploads)
+## AWS S3 setup (required for file uploads)
 
 The application uses AWS S3 for document storage and file uploads. Follow these steps to set up your S3 bucket:
 
-### 1. Create an S3 Bucket
+### 1. Create an S3 bucket
 
 - Log into the AWS Console and navigate to S3
 - Create a new bucket (e.g., `litefile-your-suffix`)
@@ -86,7 +86,7 @@ The application uses AWS S3 for document storage and file uploads. Follow these
 - Tags can be created to help track ownership of resources and is useful for cost tracking, environment tracking, etc.
 - Default encryption settings should be fine
 
-### 2. Configure Bucket Permissions
+### 2. Configure bucket permissions
 
 Apply this bucket policy to allow public read access for Tyler to download documents:
 
@@ -107,7 +107,7 @@ Apply this bucket policy to allow public read access for Tyler to download docum
 
 Replace `YOUR-BUCKET-NAME` with your actual bucket name.
 
-### 3. Create IAM User and Permissions
+### 3. Create IAM user and permissions
 
 Create an IAM user with the following policy for application access:
 
@@ -134,14 +134,14 @@ Create an IAM user with the following policy for application access:
 }
 ```
 
-### 4. Disable Public Access to the S3 Bucket
+### 4. Disable public access to the S3 bucket
 
 You can now turn on "Block all public access" in the S3 bucket settings. Go to Permissions. Click on the Edit button in the "Block public access (bucket settings)" section. Toggle on "Block all public access". Click "Save Changes" and confirm the action.
 
 This will keep the existing policy, which we use to generate the pre-signed URLs to Tyler access, but restrict the files from being made publicly accessible in other ways.
 
 
-### 5. Configure Environment Variables
+### 5. Configure environment variables
 
 Copy the example environment file and update the S3 settings:
 
@@ -152,7 +152,7 @@ cp efile_app/.env.example efile_app/.env
 Edit `efile_app/.env` with your AWS credentials:
 
 ```bash
-# AWS S3 Configuration
+# AWS S3 configuration
 AWS_ACCESS_KEY_ID = "your-aws-access-key-id-here"
 AWS_SECRET_ACCESS_KEY = "your-aws-secret-access-key-here"
 AWS_S3_BUCKET_NAME = "your-bucket-name-here"
@@ -224,7 +224,7 @@ Notes:
 - `DJANGO_SETTINGS_MODULE` is set to `efile.settings` in `[tool.pytest.ini_options]`.
 - Tests are discovered under `efile_app/`. An example smoke test lives at `efile_app/efile/tests/test_smoke.py`.
 
-## End-to-End Testing (Playwright)
+## End-to-end testing (Playwright)
 
 Playwright tests are located in `efile_app/tests/` and provide browser-based testing of the complete user workflow. These are intended to be run manually and are not part of the CI/CD pipeline because they produce
 side-effects (e.g. filing new cases in EFSP) and rely on external APIs (e.g. EFSP again). The tests stop short
@@ -259,7 +259,7 @@ The Playwright configuration includes several important settings:
 - **Parallel Execution**: Disabled on CI (1 worker) to avoid conflicts with external services
 - **Browser**: Currently configured for Chromium only (Firefox and Safari commented out)
 
-### Running Tests
+### Running tests
 
 - __Start the Django server__ first:
   ```bash
@@ -295,23 +295,23 @@ The Playwright configuration includes several important settings:
 
 **Note**: The global setup automatically validates your `.env` configuration before running tests. If environment variables are missing, tests will fail with a clear error message.
 
-### Test Architecture
+### Test architecture
 
 The Playwright tests use a modular architecture with shared utilities:
 
 - **`tests/setup.js`**: Global setup that loads environment variables and validates credentials before any tests run
 - **`tests/test-utils.js`**: Shared utilities including `loginViaLogout()`, `loginViaLoginPage()`, and `getTestConfig()` functions
 - **`playwright.config.js`**: Playwright configuration with global setup enabled, extended timeout, and CI-specific settings
 
-#### Login Utilities
+#### Login utilities
 
 The `test-utils.js` module provides two login methods:
 
 - **`loginViaLogout(page, config)`**: Logs in via the `/logout` endpoint (ensures clean session) - this is the default
 - **`loginViaLoginPage(page, config)`**: Logs in via the `/login` page
 - **`loginUser(page, config)`**: Alias for `loginViaLogout()` for backward compatibility
 
-### Available Tests
+### Available tests
 
 - **`expert-form-name-change.spec.js`**: Tests the complete workflow for filing a name change case
 - **`expert-form-order-of-protection.spec.js`**: Tests the complete workflow for filing an order of protection case  
@@ -359,7 +359,7 @@ Pre-commit hooks are configured in `.pre-commit-config.yaml` to run Ruff formatt
 
 **Note**: The pytest hook runs on `pre-push` stage to keep commits fast. If you skip the pre-push hook installation, tests won't run automatically before pushing.
 
-## Project Layout
+## Project layout
 
 - `efile_app/manage.py` — Django management script
 - `efile_app/efile/settings.py` — Project settings (uses SQLite by default; DB file at `efile_app/db.sqlite3`)

docs/sample_simple_form_config.md

@@ -1,5 +1,5 @@
 
-### Hypothetical Flow Config
+### Hypothetical flow config
 
 The Filing Flow config language follows these design principles:
 
@@ -20,7 +20,7 @@ The Filing Flow config language follows these design principles:
 - **Instructions**: Plain-language guidance at flow and step levels
 
 ```yaml
-# Illinois Adult Name Change - Cook County Filing Flow
+# Illinois adult name change - Cook County filing flow
 # NOTE: this is hypothetical and collects more data than necessary for the real e-filing since we merge data from 
 # the Tyler profile.
 # NOTE: to match the actual wireframes, this simple flow should've allowed for adult or child. We'd need a form

docs/vision-eval-20250827.md

@@ -1,4 +1,4 @@
-# Status Check vs Vision
+# Status check vs vision
 Based on the current codebase, here’s where things stand relative to your MVP vision.
 
 ## What’s in place
@@ -20,7 +20,7 @@ Based on the current codebase, here’s where things stand relative to your MVP
 - __Uploads and mapping to EFSP__
   - `efile/views/upload.py` implements `create_filing()` (maps session → Suffolk payload) and `upload_documents()` (S3 → Suffolk document registration), plus mock/simple upload utilities.
 
-## Gaps vs Vision
+## Gaps vs vision
 
 - __Filing Flow runner (recipe-driven)__: No generalized sequence/branch/validate engine or persisted recipes for curated flows.
 - __Form Blocks abstraction and UI__: No explicit Form Block schema/type library and reusable UI components.
@@ -31,7 +31,7 @@ Based on the current codebase, here’s where things stand relative to your MVP
 - __Configuration management UX__: No admin UI for non-technical authoring/editing of Blocks/Flows.
 - __Tests__: Limited tests for flow engine, YAML court overrides, and EFSP interactions.
 
-## Recommended Next Steps (MVP-targeted)
+## Recommended next steps (MVP-targeted)
 
 1. __Introduce a Filing Flow “recipe” format (JSON/YAML)__
    - Minimal schema: metadata (`id`, `title`, `jurisdiction`), steps (Form Blocks), branching (`next_if`, `next_else`), validation, mapping.
@@ -68,7 +68,7 @@ Based on the current codebase, here’s where things stand relative to your MVP
 8. __Tests__
    - Flow runner branching/validation; config merging for courts (e.g., `cook:cd1` vs `cook:chd1` per `efile/static/config/README.md`); mapping integration tests.
 
-## Concrete Implementation Plan
+## Concrete implementation plan
 
 - __Backend__
   - Create `efile/flow/`: `schemas.py` (dataclasses/Pydantic for Block/Step/Recipe), `runner.py`, `mapping.py`, (optional) `models.py` for persistence.
@@ -81,13 +81,13 @@ Based on the current codebase, here’s where things stand relative to your MVP
   - Reuse dropdown endpoints and party types via `config_views.py` and Suffolk codes.
   - Reuse S3 patterns from `upload.py`.
 
-## Open Questions
+## Open questions
 
 - Recipes YAML (human-friendly) or JSON (browser-native)? Suggest YAML in repo + compile to JSON at runtime.
 - Attachments: embed file-upload blocks in steps now or upload at review step?
 - Initial guided flow: Illinois Name Change (best documented today)?
 
-## Proposed Short Milestones
+## Proposed short milestones
 
 - __M1 (day 1-2)__: Schemas + runner skeleton (load/next/back), session storage, minimal API.
 - __M2 (day 3-4)__: Mapping layer + Review & Submit, integrate with `create_filing()`.

docs/vision-eval-20250902.md

@@ -1,31 +1,31 @@
-# Vision Evaluation - September 2, 2025
+# Vision evaluation - September 2, 2025
 
-## Executive Summary
+## Executive summary
 
 The current Form Submission MVP demonstrates solid progress toward the vision goals, with core infrastructure in place and key user flows implemented. The app successfully implements EFSP integration, session-based data management, and a working filing flow for Illinois Adult Name Change cases. However, several vision components remain incomplete or need refinement.
 
 **Overall Assessment: 70% Complete**
 
-## Vision Goal Analysis
+## Vision goal analysis
 
-### ✅ **Achieved Goals**
+### ✅ **Achieved goals**
 
-#### EFSP REST API Integration
+#### EFSP REST API integration
 - **Status**: ✅ Complete
 - **Implementation**: Full integration with Suffolk's EFSP API for authentication, options discovery, and filing submission
 - **Evidence**: Comprehensive API views in `efile/api/` directory, auth handling, dropdown population from live API data
 
-#### Session Data Management
+#### Session data management
 - **Status**: ✅ Complete
 - **Implementation**: Robust session-based data storage with structured case data, party information, and file uploads
 - **Evidence**: Session API endpoints, data persistence across flow steps, temporary file storage
 
-#### Basic Auth/Session
+#### Basic auth/session
 - **Status**: ✅ Complete
 - **Implementation**: Django-based authentication with user registration, login/logout, and session management
 - **Evidence**: User registration forms, login views, session-based auth tokens
 
-#### Local Deploy via Docker/Compose
+#### Local deploy via Docker/Compose
 - **Status**: ✅ Complete
 - **Implementation**: Full Docker setup with compose configuration
 - **Evidence**: `Dockerfile`, `compose.yml`, and environment-specific settings
@@ -35,80 +35,80 @@ The current Form Submission MVP demonstrates solid progress toward the vision go
 - **Implementation**: GitHub Actions workflow with type checking, linting, and testing
 - **Evidence**: `.github/workflows/ci.yml`, pyproject.toml configuration
 
-#### Illinois Adult Name Change Support
+#### Illinois adult name change support
 - **Status**: ✅ Complete
 - **Implementation**: Dedicated case type configuration and form handling for Cook County Adult Name Change
 - **Evidence**: Case type config in `case_type_config.yml`, specialized form validation
 
-### 🔄 **Partially Implemented**
+### 🔄 **Partially implemented**
 
-#### Form Blocks Architecture
+#### Form blocks architecture
 - **Status**: 🔄 Partial (40%)
 - **Current State**: Basic form components exist but not as reusable, configurable blocks
 - **Gap**: Forms are hardcoded rather than built from composable Form Block components
 - **Next Steps**: Refactor forms to use configurable Form Block system
 
-#### Filing Flow Runner
+#### Filing flow runner
 - **Status**: 🔄 Partial (60%)
 - **Current State**: Linear flow exists (login → options → expert form → upload → review → submit)
 - **Gap**: No configuration-driven flow system; flows are hardcoded in views
 - **Next Steps**: Implement YAML-based Filing Flow configuration system
 
-#### Review & Submit Step
+#### Review & submit step
 - **Status**: 🔄 Partial (70%)
 - **Current State**: Review page exists with case data summary
 - **Gap**: Summary could be more human-readable; needs better formatting
 - **Next Steps**: Enhance review page with clearer data presentation
 
-#### Mapping Layer
+#### Mapping layer
 - **Status**: 🔄 Partial (50%)
 - **Current State**: Basic field mapping exists in forms and API calls
 - **Gap**: No centralized, configurable mapping system
 - **Next Steps**: Create declarative mapping configuration system
 
-### ❌ **Missing Components**
+### ❌ **Missing components**
 
-#### Configuration-Driven Form Blocks
+#### Configuration-driven form blocks
 - **Status**: ❌ Not Implemented
 - **Vision**: Small set of validated input blocks (text, select, date, address) with basic theming
 - **Current State**: Hardcoded Django forms
 - **Impact**: Non-technical users cannot configure workflows without code changes
 
-#### Self-Service Filing Flow Configuration
+#### Self-service filing flow configuration
 - **Status**: ❌ Not Implemented  
 - **Vision**: Non-technical users can create/edit Filing Flows without code
 - **Current State**: All flows are hardcoded in Python/templates
 - **Impact**: Major blocker for vision goal of self-service configuration
 
-#### Multiple Case Type Support
+#### Multiple case type support
 - **Status**: ❌ Limited
 - **Vision**: Proof of feasibility for at least 2 other case types beyond Adult Name Change
 - **Current State**: Only Adult Name Change fully implemented
 - **Impact**: Cannot demonstrate system flexibility
 
-#### Guided Interview Experience
+#### Guided interview experience
 - **Status**: ❌ Not Implemented
 - **Vision**: Plain-language labels, helper text, step-by-step guidance
 - **Current State**: Expert form is technical and overwhelming
 - **Impact**: Poor user experience for self-represented litigants
 
-## User Experience Assessment
+## User experience assessment
 
-### Current User Journey
+### Current user journey
 1. **Registration/Login**: ✅ Working, clean interface
 2. **Options Selection**: ✅ Functional but technical (expert mode only)
 3. **Case Details**: ✅ Working but complex form
 4. **Document Upload**: ✅ Functional with S3 integration
 5. **Review**: ✅ Basic summary provided
 6. **Submission**: ✅ EFSP integration working
 
-### UX Gaps vs Vision
+### Ux gaps vs vision
 - **Clarity**: Current interface is expert-focused, not beginner-friendly
 - **Guidance**: Lacks step-by-step guidance and plain-language instructions
 - **Progressive Disclosure**: Shows all options at once rather than guided flow
 - **Error Handling**: Basic validation exists but could be more user-friendly
 
-## Technical Architecture Assessment
+## Technical architecture assessment
 
 ### Strengths
 - **Solid Foundation**: Django app with proper structure and separation of concerns
@@ -117,38 +117,38 @@ The current Form Submission MVP demonstrates solid progress toward the vision go
 - **Configuration Start**: Beginning of configuration system with YAML files
 - **Testing Infrastructure**: CI/CD pipeline with proper tooling
 
-### Areas for Improvement
+### Areas for improvement
 - **Form Block Architecture**: Need composable, reusable form components
 - **Configuration System**: Expand YAML-based configuration for full Filing Flows
 - **Error Handling**: Enhance user-facing error messages and recovery flows
 - **UI Components**: Move toward more modular, themeable UI components
 
-## Success Metrics Progress
+## Success metrics progress
 
-### Time-to-Submit (Target: 15 minutes)
+### Time-to-submit (target: 15 minutes)
 - **Current**: Estimated 20-25 minutes for technical users
 - **Gap**: Expert form complexity adds time; needs guided flow
 
-### First-Pass Acceptance (Target: ≥80%)
+### First-pass acceptance (target: ≥80%)
 - **Current**: Unknown (needs testing)
 - **Blocker**: Limited real-world testing data
 
-### Self-Service Configuration (Target: Non-technical user can edit flows)
+### Self-service configuration (target: Non-technical user can edit flows)
 - **Current**: 0% - All configuration requires code changes
 - **Critical Gap**: No visual or YAML-based flow configuration
 
-### Fast Onboarding (Target: Quick Docker setup)
+### Fast onboarding (target: Quick docker setup)
 - **Current**: ✅ Achieved - Docker compose setup works well
 
-## Priority Recommendations
+## Priority recommendations
 
-### High Priority (Core Vision Blockers)
+### High priority (core vision blockers)
 1. **Implement Form Block Architecture**: Create reusable, configurable form components
 2. **Build Filing Flow Configuration System**: YAML-based flow definitions
 3. **Create Guided Interview Mode**: User-friendly alternative to expert form
 4. **Add 2 More Case Types**: Demonstrate system flexibility
 
-### Medium Priority (UX Improvements)
+### Medium priority (ux improvements)
 1. **Enhance Error Handling**: Better user-facing error messages
 2. **Improve Review Page**: More readable data summary
 3. **Add Helper Text System**: Step-by-step guidance and instructions