diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index f5ec281..5f451aa 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -36,7 +36,7 @@ convention:
 - Python >= 3.11; use modern syntax (PEP 604 unions, f-strings, `match` where appropriate).
 - Linter: `ruff` (line length 99, target py311). Run `ruff check python/`.
 - All new Python code should have type hints.
-- Never hardcode credentials — use env vars, Ansible Vault, or Terraform `sensitive`.
+- Never hardcode credentials - use env vars, Ansible Vault, or Terraform `sensitive`.
 - Ansible playbooks use `netapp.ontap` FQCNs with `use_rest: always`.
 - Terraform modules use the `NetApp/netapp-ontap` provider `~> 2.5`.
 - Every generated source file (`.py`, `.yml`, `.tf`, `.sh`, `.html`) MUST start
@@ -59,17 +59,17 @@ Exempt files: Markdown, `requirements.*`, `ansible/inventory/*`,
 
 ## ONTAP API rules
 
-- Use ONLY ONTAP REST APIs — no ZAPI, no CLI passthrough, no SSH.
+- Use ONLY ONTAP REST APIs - no ZAPI, no CLI passthrough, no SSH.
 - Target ONTAP 9.8+ REST endpoints.
 - See `docs/ontap-api-patterns.md` for endpoints, auth, async job handling.
 
 ## Python conventions
 
-- Import and use `python/ontap_client.py` — never build a new HTTP client.
+- Import and use `python/ontap_client.py` - never build a new HTTP client.
 - Authenticate via `OntapClient.from_env()` (reads `ONTAP_HOST`, `ONTAP_PASS`).
 - Operational params via `argparse` with env-var fallbacks.
 - Async jobs: `client.poll_job(resp["job"]["uuid"])`.
-- Logging via `logging` module — never `print()`.
+- Logging via `logging` module - never `print()`.
 
 ## Ansible conventions
 
diff --git a/.github/prompts/generate-ansible.prompt.md b/.github/prompts/generate-ansible.prompt.md
index 2e6aff8..90e5db8 100644
--- a/.github/prompts/generate-ansible.prompt.md
+++ b/.github/prompts/generate-ansible.prompt.md
@@ -16,22 +16,22 @@ collection, which calls exclusively REST APIs.
 
 Use these repository files as the authoritative source for conventions:
 
-- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) — NFS reference implementation
-- [ansible/cifs_provision.yml](../../ansible/cifs_provision.yml) — CIFS reference implementation
-- [ansible/group_vars/ontap.yml.example](../../ansible/group_vars/ontap.yml.example) — variable defaults
-- [ansible/inventory/hosts.yml](../../ansible/inventory/hosts.yml) — inventory structure
-- [ansible/requirements.yml](../../ansible/requirements.yml) — collection version pin
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — API endpoints, auth, async jobs
-- [docs/example-template/ansible/example.yml](../../docs/example-template/ansible/example.yml) — skeleton
-- [CONTRIBUTING.md](../../CONTRIBUTING.md) — naming, CI, quality bar
+- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) - NFS reference implementation
+- [ansible/cifs_provision.yml](../../ansible/cifs_provision.yml) - CIFS reference implementation
+- [ansible/group_vars/ontap.yml.example](../../ansible/group_vars/ontap.yml.example) - variable defaults
+- [ansible/inventory/hosts.yml](../../ansible/inventory/hosts.yml) - inventory structure
+- [ansible/requirements.yml](../../ansible/requirements.yml) - collection version pin
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - API endpoints, auth, async jobs
+- [docs/example-template/ansible/example.yml](../../docs/example-template/ansible/example.yml) - skeleton
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - naming, CI, quality bar
 
-## Step 1 — Clarify Inputs
+## Step 1 - Clarify Inputs
 
 Before writing YAML, identify what information is missing and ask me.
 Common inputs: SVM name, volume name/size, aggregate, protocol details,
 cluster hostname, special options (snapshot policy, QoS, junction path).
 
-## Step 2 — API Sequence
+## Step 2 - API Sequence
 
 Even though Ansible modules abstract the API, list the underlying REST calls
 and map each to its `netapp.ontap` module:
@@ -40,14 +40,14 @@ and map each to its `netapp.ontap` module:
 |---|---------------|--------|----------------|-----|
 
 Rules:
-- REST only — `use_rest: always` on every ONTAP module.
+- REST only - `use_rest: always` on every ONTAP module.
 - Target ONTAP 9.8+.
 - Fully-qualified collection names: `netapp.ontap.na_ontap_*`.
 - Collection version: `netapp.ontap >= 22.12.0`.
 
 Wait for my confirmation before generating the playbook.
 
-## Step 3 — Generate Playbook
+## Step 3 - Generate Playbook
 
 File: `ansible/<use_case>.yml` (snake_case filename)
 
@@ -55,7 +55,7 @@ File: `ansible/<use_case>.yml` (snake_case filename)
 
 ```yaml
 ---
-# <use_case>.yml — Brief description.
+# <use_case>.yml - Brief description.
 #
 # Usage:
 #   ansible-playbook -i inventory/hosts.yml <use_case>.yml
@@ -106,11 +106,11 @@ svm_name, volume_name, volume_size, volume_size_unit, aggregate_name,
 client_match (NFS), share_name (CIFS), etc.
 ```
 
-## Step 4 — Validate
+## Step 4 - Validate
 
 After the playbook, provide:
 1. Exact `ansible-playbook` command to run it.
-2. Idempotency behavior — what happens on re-run for each task.
+2. Idempotency behavior - what happens on re-run for each task.
 3. Teardown playbook or reversal instructions.
 
 ## Copyright header (required)
@@ -128,4 +128,4 @@ See the NOTICE file in the repo root for trademark and attribution details.
 
 Place after any shebang (`#!/usr/bin/env python3`), YAML directive (`---`),
 or `<!DOCTYPE html>` line. Do **not** duplicate the full trademark text in
-source files — it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
+source files - it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
diff --git a/.github/prompts/generate-python.prompt.md b/.github/prompts/generate-python.prompt.md
index f44f849..bc0087c 100644
--- a/.github/prompts/generate-python.prompt.md
+++ b/.github/prompts/generate-python.prompt.md
@@ -15,19 +15,19 @@ The script automates a NetApp ONTAP storage task using exclusively REST APIs.
 
 Use these repository files as the authoritative source for conventions:
 
-- [python/ontap_client.py](../../python/ontap_client.py) — shared REST client (MUST import and use this)
-- [python/nfs_provision.py](../../python/nfs_provision.py) — reference implementation pattern
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — API endpoints, auth, async jobs
-- [docs/example-template/python/example.py](../../docs/example-template/python/example.py) — skeleton to start from
-- [CONTRIBUTING.md](../../CONTRIBUTING.md) — naming, CI, quality bar
+- [python/ontap_client.py](../../python/ontap_client.py) - shared REST client (MUST import and use this)
+- [python/nfs_provision.py](../../python/nfs_provision.py) - reference implementation pattern
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - API endpoints, auth, async jobs
+- [docs/example-template/python/example.py](../../docs/example-template/python/example.py) - skeleton to start from
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - naming, CI, quality bar
 
-## Step 1 — Clarify Inputs
+## Step 1 - Clarify Inputs
 
 Before writing code, identify what information is missing and ask me.
 Common inputs: SVM name, volume name/size, aggregate, protocol details,
 cluster hostname, special options (snapshot policy, QoS, junction path).
 
-## Step 2 — API Sequence
+## Step 2 - API Sequence
 
 List the ONTAP REST API calls in execution order:
 
@@ -35,14 +35,14 @@ List the ONTAP REST API calls in execution order:
 |---|--------|----------|-----------------------|------------|-----|
 
 Rules:
-- ONTAP REST only — no ZAPI, no CLI passthrough, no SSH.
+- ONTAP REST only - no ZAPI, no CLI passthrough, no SSH.
 - Target ONTAP 9.8+ endpoints.
 - Full endpoint paths (e.g. `/api/storage/volumes`).
 - For async calls, include the poll step: `GET /api/cluster/jobs/{uuid}`.
 
 Wait for my confirmation before generating code.
 
-## Step 3 — Generate Python Script
+## Step 3 - Generate Python Script
 
 File: `python/<use_case>.py` (snake_case filename)
 
@@ -72,7 +72,7 @@ File: `python/<use_case>.py` (snake_case filename)
   ```
 - Async job polling: `client.poll_job(resp["job"]["uuid"])`
 - Logging: `logging.basicConfig(level=logging.INFO, format="%(asctime)s  %(levelname)-8s  %(message)s")`
-  - `logger = logging.getLogger(__name__)` — never use `print()`.
+  - `logger = logging.getLogger(__name__)` - never use `print()`.
 - Entry point:
   ```python
   if __name__ == "__main__":
@@ -86,7 +86,7 @@ File: `python/<use_case>.py` (snake_case filename)
   ```
 - Type hints on all functions. No hardcoded credentials.
 
-## Step 4 — Validate
+## Step 4 - Validate
 
 After the code, provide:
 1. Exact shell commands to run the script.
@@ -108,4 +108,4 @@ See the NOTICE file in the repo root for trademark and attribution details.
 
 Place after any shebang (`#!/usr/bin/env python3`), YAML directive (`---`),
 or `<!DOCTYPE html>` line. Do **not** duplicate the full trademark text in
-source files — it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
+source files - it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
diff --git a/.github/prompts/generate-terraform.prompt.md b/.github/prompts/generate-terraform.prompt.md
index 11f8ea6..7416b71 100644
--- a/.github/prompts/generate-terraform.prompt.md
+++ b/.github/prompts/generate-terraform.prompt.md
@@ -16,21 +16,21 @@ provider, which calls exclusively REST APIs.
 
 Use these repository files as the authoritative source for conventions:
 
-- [terraform/nfs-provision/main.tf](../../terraform/nfs-provision/main.tf) — reference implementation
-- [terraform/nfs-provision/variables.tf](../../terraform/nfs-provision/variables.tf) — variable patterns
-- [terraform/nfs-provision/outputs.tf](../../terraform/nfs-provision/outputs.tf) — output patterns
-- [terraform/nfs-provision/terraform.tfvars.example](../../terraform/nfs-provision/terraform.tfvars.example) — tfvars template
-- [docs/example-template/terraform/](../../docs/example-template/terraform/) — skeleton files
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — API endpoints and conventions
-- [CONTRIBUTING.md](../../CONTRIBUTING.md) — naming, CI, quality bar
+- [terraform/nfs-provision/main.tf](../../terraform/nfs-provision/main.tf) - reference implementation
+- [terraform/nfs-provision/variables.tf](../../terraform/nfs-provision/variables.tf) - variable patterns
+- [terraform/nfs-provision/outputs.tf](../../terraform/nfs-provision/outputs.tf) - output patterns
+- [terraform/nfs-provision/terraform.tfvars.example](../../terraform/nfs-provision/terraform.tfvars.example) - tfvars template
+- [docs/example-template/terraform/](../../docs/example-template/terraform/) - skeleton files
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - API endpoints and conventions
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - naming, CI, quality bar
 
-## Step 1 — Clarify Inputs
+## Step 1 - Clarify Inputs
 
 Before writing HCL, identify what information is missing and ask me.
 Common inputs: SVM name, volume name/size, aggregate, protocol details,
 cluster hostname, special options (snapshot policy, QoS, junction path).
 
-## Step 2 — API Sequence & Resource Mapping
+## Step 2 - API Sequence & Resource Mapping
 
 List the REST API calls the provider makes and map each to a Terraform
 resource or data source:
@@ -47,7 +47,7 @@ Rules:
 
 Wait for my confirmation before generating HCL.
 
-## Step 3 — Generate Module
+## Step 3 - Generate Module
 
 Directory: `terraform/<use-case>/` (kebab-case directory name)
 
@@ -56,7 +56,7 @@ Create four files:
 ### main.tf
 
 ```hcl
-# <use-case> — Brief description.
+# <use-case> - Brief description.
 
 terraform {
   required_version = ">= 1.4"
@@ -101,7 +101,7 @@ provider "netapp-ontap" {
 
 - Placeholder values with comments. Never include real credentials.
 
-## Step 4 — Validate
+## Step 4 - Validate
 
 After the module, provide:
 1. Exact commands: `terraform init`, `terraform plan`, `terraform apply`.
@@ -123,4 +123,4 @@ See the NOTICE file in the repo root for trademark and attribution details.
 
 Place after any shebang (`#!/usr/bin/env python3`), YAML directive (`---`),
 or `<!DOCTYPE html>` line. Do **not** duplicate the full trademark text in
-source files — it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
+source files - it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
diff --git a/.github/prompts/generate-workflow.prompt.md b/.github/prompts/generate-workflow.prompt.md
index 5a09f44..c44618e 100644
--- a/.github/prompts/generate-workflow.prompt.md
+++ b/.github/prompts/generate-workflow.prompt.md
@@ -1,5 +1,5 @@
 ---
-description: "Generate a complete ONTAP workflow — Python + Ansible + Terraform — for a storage task"
+description: "Generate a complete ONTAP workflow - Python + Ansible + Terraform - for a storage task"
 ---
 
 # Generate Complete ONTAP Workflow (All Three Tools)
@@ -14,16 +14,16 @@ implementations so users can compare side-by-side.
 
 ## Reference Files
 
-- [python/ontap_client.py](../../python/ontap_client.py) — shared Python REST client
-- [python/nfs_provision.py](../../python/nfs_provision.py) — Python reference
-- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) — Ansible reference
-- [ansible/cifs_provision.yml](../../ansible/cifs_provision.yml) — Ansible CIFS reference
-- [terraform/nfs-provision/](../../terraform/nfs-provision/) — Terraform reference
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — API endpoints, auth, async jobs
-- [docs/example-template/](../../docs/example-template/) — skeleton files for all tools
-- [CONTRIBUTING.md](../../CONTRIBUTING.md) — naming, CI, quality bar
+- [python/ontap_client.py](../../python/ontap_client.py) - shared Python REST client
+- [python/nfs_provision.py](../../python/nfs_provision.py) - Python reference
+- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) - Ansible reference
+- [ansible/cifs_provision.yml](../../ansible/cifs_provision.yml) - Ansible CIFS reference
+- [terraform/nfs-provision/](../../terraform/nfs-provision/) - Terraform reference
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - API endpoints, auth, async jobs
+- [docs/example-template/](../../docs/example-template/) - skeleton files for all tools
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - naming, CI, quality bar
 
-## Phase 1 — Clarify Inputs
+## Phase 1 - Clarify Inputs
 
 Before generating any code, ask me for anything missing:
 - SVM name, volume name/size, aggregate
@@ -32,7 +32,7 @@ Before generating any code, ask me for anything missing:
 - Authentication approach
 - Non-default options (snapshot policy, tiering, QoS, junction path)
 
-## Phase 2 — API Sequence
+## Phase 2 - API Sequence
 
 Present a numbered list of ONTAP REST API calls in execution order.
 For each:
@@ -41,16 +41,16 @@ For each:
 |---|--------|----------|----------------|------------|-----|
 
 Rules:
-- ONTAP REST only — no ZAPI, no CLI passthrough, no SSH.
+- ONTAP REST only - no ZAPI, no CLI passthrough, no SSH.
 - Target ONTAP 9.8+ endpoints.
 - Full paths (e.g. `/api/storage/volumes`).
 - Include poll steps for async calls.
 
 **Wait for my approval before Phase 3.**
 
-## Phase 3 — Generate All Three Implementations
+## Phase 3 - Generate All Three Implementations
 
-### 3A. Python — `python/<use_case>.py`
+### 3A. Python - `python/<use_case>.py`
 
 - `#!/usr/bin/env python3`, `from __future__ import annotations`
 - Module docstring: steps, prerequisites, usage with CLI flags.
@@ -62,7 +62,7 @@ Rules:
 - `if __name__ == "__main__":` with try/except guard.
 - Type hints throughout. No hardcoded credentials.
 
-### 3B. Ansible — `ansible/<use_case>.yml`
+### 3B. Ansible - `ansible/<use_case>.yml`
 
 - `---` header with filename, description, usage comment.
 - `hosts: ontap`, `gather_facts: false`, `connection: local`.
@@ -72,7 +72,7 @@ Rules:
 - `vars:` for operational defaults (overridable with `-e`).
 - Final `ansible.builtin.debug` summary. No hardcoded credentials.
 
-### 3C. Terraform — `terraform/<use-case>/`
+### 3C. Terraform - `terraform/<use-case>/`
 
 - `main.tf`: `required_version >= 1.4`, provider `NetApp/netapp-ontap ~> 2.5`,
   `connection_profiles` with `cx_profile_name = "cluster1"`.
@@ -81,7 +81,7 @@ Rules:
 - `terraform.tfvars.example`: placeholder values, no real credentials.
 - `depends_on` where ordering matters.
 
-## Phase 4 — Validate
+## Phase 4 - Validate
 
 For each implementation:
 1. Exact commands to run it.
@@ -103,4 +103,4 @@ See the NOTICE file in the repo root for trademark and attribution details.
 
 Place after any shebang (`#!/usr/bin/env python3`), YAML directive (`---`),
 or `<!DOCTYPE html>` line. Do **not** duplicate the full trademark text in
-source files — it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
+source files - it lives in [NOTICE](../../NOTICE) and the LICENSE appendix.
diff --git a/.github/prompts/plan-api-sequence.prompt.md b/.github/prompts/plan-api-sequence.prompt.md
index ce48b1e..e53136b 100644
--- a/.github/prompts/plan-api-sequence.prompt.md
+++ b/.github/prompts/plan-api-sequence.prompt.md
@@ -5,7 +5,7 @@ description: "Design the ONTAP REST API call sequence for a storage operation be
 # Plan ONTAP REST API Sequence
 
 You are an ONTAP REST API specialist. Design the exact sequence of API calls
-for a storage operation — **no code yet**, just the API plan.
+for a storage operation - **no code yet**, just the API plan.
 
 ## Task
 
@@ -13,7 +13,7 @@ for a storage operation — **no code yet**, just the API plan.
 
 ## Reference
 
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — endpoints, auth, query params, async jobs
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - endpoints, auth, query params, async jobs
 - ONTAP REST API docs: https://docs.netapp.com/us-en/ontap-restapi/swagger-ui/index.html
 
 ## Output Format
@@ -22,11 +22,11 @@ For each API call, fill in this table:
 
 | # | Method | Endpoint | Key Body / Query Params | Sync/Async | Idempotent? | Why |
 |---|--------|----------|-------------------------|------------|-------------|-----|
-| 1 | GET | /api/svm/svms?name=vs0&fields=uuid | — | Sync | Yes | Resolve SVM UUID |
+| 1 | GET | /api/svm/svms?name=vs0&fields=uuid | - | Sync | Yes | Resolve SVM UUID |
 
 ## Rules
 
-1. **REST only** — no ZAPI, no CLI passthrough, no SSH.
+1. **REST only** - no ZAPI, no CLI passthrough, no SSH.
 2. **ONTAP 9.8+** target minimum.
 3. Full endpoint paths (e.g. `/api/storage/volumes`, not just "volumes").
 4. For POST/PATCH returning a job, include the poll step:
diff --git a/.github/prompts/review-contribution.prompt.md b/.github/prompts/review-contribution.prompt.md
index bf19591..81b74b6 100644
--- a/.github/prompts/review-contribution.prompt.md
+++ b/.github/prompts/review-contribution.prompt.md
@@ -14,12 +14,12 @@ I provide and prepare it for a pull request.
 
 ## Reference Files
 
-- [CONTRIBUTING.md](../../CONTRIBUTING.md) — full contribution guide
-- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) — API conventions
-- [python/ontap_client.py](../../python/ontap_client.py) — shared client
-- [python/nfs_provision.py](../../python/nfs_provision.py) — Python reference
-- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) — Ansible reference
-- [terraform/nfs-provision/](../../terraform/nfs-provision/) — Terraform reference
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - full contribution guide
+- [docs/ontap-api-patterns.md](../../docs/ontap-api-patterns.md) - API conventions
+- [python/ontap_client.py](../../python/ontap_client.py) - shared client
+- [python/nfs_provision.py](../../python/nfs_provision.py) - Python reference
+- [ansible/nfs_provision.yml](../../ansible/nfs_provision.yml) - Ansible reference
+- [terraform/nfs-provision/](../../terraform/nfs-provision/) - Terraform reference
 
 ## 1. Naming & File Structure
 
@@ -74,9 +74,9 @@ I provide and prepare it for a pull request.
 ## 4. Documentation Updates
 
 Generate README update snippets for each tool's README:
-- `python/README.md` — new section with description + run instructions
-- `ansible/README.md` — new section with description + run instructions
-- `terraform/README.md` — new section with description + run instructions
+- `python/README.md` - new section with description + run instructions
+- `ansible/README.md` - new section with description + run instructions
+- `terraform/README.md` - new section with description + run instructions
 
 ## 5. Commit Message
 
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 517d6b6..be935d5 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,6 +24,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
-- TruffleHog flag mismatch: pre-commit used `--fail` but CI did not — both now use `--only-verified --fail`
+- TruffleHog flag mismatch: pre-commit used `--fail` but CI did not - both now use `--only-verified --fail`
 
 [Unreleased]: https://github.com/NetApp/pace/commits/main
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 150bced..a876e7a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -43,18 +43,18 @@ Each new use case should be implemented across all three tools where practical.
 Use `docs/example-template/` as a starting point.
 
 **Python** (`python/`):
-- `<use_case>.py` — self-contained script
+- `<use_case>.py` - self-contained script
 - Update `python/README.md` with a section for the new example
 
 **Ansible** (`ansible/`):
-- `<use_case>.yml` — playbook using `netapp.ontap` FQCNs
+- `<use_case>.yml` - playbook using `netapp.ontap` FQCNs
 - Update `ansible/README.md` with a section for the new example
 
 **Terraform** (`terraform/`):
-- `<use_case>/main.tf` — provider + resources
-- `<use_case>/variables.tf` — input variables with descriptions
-- `<use_case>/outputs.tf` — useful output values
-- `<use_case>/terraform.tfvars.example` — variable template
+- `<use_case>/main.tf` - provider + resources
+- `<use_case>/variables.tf` - input variables with descriptions
+- `<use_case>/outputs.tf` - useful output values
+- `<use_case>/terraform.tfvars.example` - variable template
 - Update `terraform/README.md` with a section for the new example
 
 ### Quality bar
@@ -62,7 +62,7 @@ Use `docs/example-template/` as a starting point.
 Every example must:
 
 - Be self-contained (copy one directory and it works)
-- Never hardcode credentials — use env vars, Ansible Vault, or Terraform `sensitive`
+- Never hardcode credentials - use env vars, Ansible Vault, or Terraform `sensitive`
 - Include clear run instructions in the parent README
 - Pass CI lint checks (see below)
 - Follow the conventions of the target tool (idiomatic Python, Ansible FQCNs, HCL style)
@@ -85,16 +85,16 @@ The `insert-license` pre-commit hook (configured in
 [.pre-commit-config.yaml](.pre-commit-config.yaml)) inserts and verifies the
 header automatically; CI rejects PRs that drop it. Exempt files: Markdown,
 `requirements.*`, `ansible/inventory/*`, `ansible/group_vars/*`, `*.example`,
-and `dependabot.yml` — all covered by the root [NOTICE](NOTICE).
+and `dependabot.yml` - all covered by the root [NOTICE](NOTICE).
 
 > **Testing:** Every PR that touches `python/`, `ansible/`, or `terraform/`
-> must include a populated **Test Report** in the PR body — see
+> must include a populated **Test Report** in the PR body - see
 > [TESTING.md](TESTING.md) for what to capture (environment, ONTAP
 > version, first-run output, idempotency / re-run check, teardown). A
 > soft-gate workflow applies a `needs-test-report` label until the
 > section is filled in.
 >
-> CI continues to validate lint, format, syntax, and secrets only — the
+> CI continues to validate lint, format, syntax, and secrets only - the
 > end-to-end run evidence is contributor-supplied.
 
 ### ONTAP API reference
@@ -124,7 +124,7 @@ Optional (only needed for example validation):
 | **tflint** | any | Terraform linting | [github.com/terraform-linters/tflint](https://github.com/terraform-linters/tflint) |
 
 `make install` automatically creates a `.venv/` and installs **ruff**
-inside it — you do not need to install it manually.
+inside it - you do not need to install it manually.
 
 ### First-time setup
 
@@ -155,7 +155,7 @@ The workspace `.vscode/settings.json` configures:
 - **Terraform format-on-save** via the Terraform extension
 - **Python interpreter** pointed at `.venv/bin/python` (from `make install`)
 
-No manual formatter configuration needed — just save the file and it formats.
+No manual formatter configuration needed - just save the file and it formats.
 
 ### Running checks locally
 
@@ -188,7 +188,7 @@ docker compose run --rm dev bash
 ```
 
 The container includes Python 3.11, Ruff, pre-commit, Ansible, ansible-lint,
-Terraform, and tflint — everything CI expects.
+Terraform, and tflint - everything CI expects.
 
 ### Pre-commit hooks
 
@@ -219,7 +219,7 @@ PRs are validated by GitHub Actions workflows:
 | **Terraform lint** | `validate-examples.yml` | `terraform/**` changes | `terraform fmt -check`, `terraform validate`, `tflint` |
 | **Test Report check** | `test-report-check.yml` | PRs only | Soft gate: labels PR `needs-test-report` if the body's Test Report section is unfilled (see [TESTING.md](TESTING.md)) |
 
-All checks except the Test Report check are **hard gates** — PRs must
+All checks except the Test Report check are **hard gates** - PRs must
 pass them before merge. The Test Report check is informational and
 reviewer-enforced.
 
diff --git a/README.md b/README.md
index d2d18c3..339b45d 100644
--- a/README.md
+++ b/README.md
@@ -18,7 +18,7 @@
 ---
 
 Pace is an open-source library of ready-to-run **NetApp ONTAP** automation
-examples, implemented three ways — side by side — so you can pick the
+examples, implemented three ways - side by side - so you can pick the
 style your team already uses.
 
 | Style                     | Tool      | In a sentence                       |
@@ -27,7 +27,7 @@ style your team already uses.
 | **Declarative playbooks** | Ansible   | You describe the outcome.           |
 | **Stateful blueprints**   | Terraform | The tool tracks every change.       |
 
-Same task, same outcome — different trade-offs in readability, idempotency,
+Same task, same outcome - different trade-offs in readability, idempotency,
 and lifecycle management.
 
 > Visit **[netapp.github.io/pace](https://netapp.github.io/pace/)** for the
@@ -38,10 +38,10 @@ and lifecycle management.
 ## Quick start
 
 Pick a style and run the matching block. All examples use placeholder host
-names and credentials — swap them for your own before running.
+names and credentials - swap them for your own before running.
 
 <details open>
-<summary><strong>Imperative scripts — Python</strong></summary>
+<summary><strong>Imperative scripts - Python</strong></summary>
 
 ```bash
 cd python
@@ -53,7 +53,7 @@ python cluster_info.py
 </details>
 
 <details>
-<summary><strong>Declarative playbooks — Ansible</strong></summary>
+<summary><strong>Declarative playbooks - Ansible</strong></summary>
 
 ```bash
 cd ansible
@@ -65,7 +65,7 @@ ansible-playbook -i inventory/hosts.yml cluster_info.yml
 </details>
 
 <details>
-<summary><strong>Stateful blueprints — Terraform</strong></summary>
+<summary><strong>Stateful blueprints - Terraform</strong></summary>
 
 ```bash
 cd terraform/cluster-info
@@ -87,7 +87,7 @@ and example output.
 - Network access to the cluster management LIF
 
 Credentials are never hardcoded. Each style uses its native secret
-mechanism — environment variables, Ansible Vault, or Terraform `sensitive`
+mechanism - environment variables, Ansible Vault, or Terraform `sensitive`
 variables.
 
 <details>
diff --git a/SUPPORT.md b/SUPPORT.md
index 29f1e53..8599677 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -20,13 +20,13 @@ We recommend always running the latest version.
 
 We use GitHub for tracking bugs and feature requests.
 
-- **Bug reports** — [open an issue](https://github.com/NetApp/pace/issues/new?template=bug_report.md)
-- **Feature requests** — [open an issue](https://github.com/NetApp/pace/issues/new?template=feature_request.md)
-- **Questions and discussion** — [GitHub Discussions](https://github.com/NetApp/pace/discussions)
+- **Bug reports** - [open an issue](https://github.com/NetApp/pace/issues/new?template=bug_report.md)
+- **Feature requests** - [open an issue](https://github.com/NetApp/pace/issues/new?template=feature_request.md)
+- **Questions and discussion** - [GitHub Discussions](https://github.com/NetApp/pace/discussions)
 
 ## Documentation
 
-* [README](README.md) — project overview and quick start
-* [Contributing](CONTRIBUTING.md) — how to add examples and what CI expects
-* [ONTAP API Patterns](docs/ontap-api-patterns.md) — REST endpoint conventions
-* [Troubleshooting](docs/troubleshooting.md) — common errors and how to fix them
+* [README](README.md) - project overview and quick start
+* [Contributing](CONTRIBUTING.md) - how to add examples and what CI expects
+* [ONTAP API Patterns](docs/ontap-api-patterns.md) - REST endpoint conventions
+* [Troubleshooting](docs/troubleshooting.md) - common errors and how to fix them
diff --git a/TESTING.md b/TESTING.md
index a03d1c8..fff4e27 100644
--- a/TESTING.md
+++ b/TESTING.md
@@ -53,7 +53,7 @@ Pick the style(s) your PR touches and capture the matching evidence.
 
 ### Python (`python/`)
 
-1. **First run** — execute the script with realistic args:
+1. **First run** - execute the script with realistic args:
 
    ```bash
    python <script>.py --svm <svm> --volume <vol> ...
@@ -61,33 +61,33 @@ Pick the style(s) your PR touches and capture the matching evidence.
 
    Capture stdout (10-50 lines is usually enough) and the exit code.
 
-2. **Re-run safety** — run the same command again. Either:
+2. **Re-run safety** - run the same command again. Either:
    - the script is idempotent and exits 0 with no destructive change, or
    - the script detects the existing state and reports it, or
    - if the script is intentionally not re-runnable, document that in
      the report so reviewers know what to expect.
 
-3. **Cleanup** — if the script created resources, show the commands
+3. **Cleanup** - if the script created resources, show the commands
    used to remove them (often a separate teardown script or REST `DELETE`
    calls). One-shot read-only scripts can skip this.
 
 ### Ansible (`ansible/`)
 
-1. **First run** — run the playbook:
+1. **First run** - run the playbook:
 
    ```bash
    ansible-playbook -i inventory/hosts.yml <playbook>.yml
    ```
 
-   Capture the **PLAY RECAP** line — `ok=`, `changed=`, `failed=`.
+   Capture the **PLAY RECAP** line - `ok=`, `changed=`, `failed=`.
 
-2. **Idempotency** — re-run the same command immediately. The recap
+2. **Idempotency** - re-run the same command immediately. The recap
    **must report `changed=0`**. This is the canonical Ansible
    idempotency proof. If the recap shows `changed > 0` on the second
    run, the playbook is not idempotent and should be fixed before
    review.
 
-3. **Teardown** — for provisioning playbooks, run the corresponding
+3. **Teardown** - for provisioning playbooks, run the corresponding
    `state: absent` task or a teardown playbook and capture its recap.
    Read-only fact-gathering playbooks can skip this.
 
@@ -96,11 +96,11 @@ Pick the style(s) your PR touches and capture the matching evidence.
 The full lifecycle is the test. Capture each step:
 
 1. `terraform init`
-2. `terraform plan` — should show the resources to be created.
-3. `terraform apply` — capture the *Apply complete!* summary line.
-4. `terraform plan` again — **must report `No changes`** (drift / idempotency proof).
-5. `terraform destroy` — capture the *Destroy complete!* line.
-6. `terraform plan` once more — should again report `No changes`
+2. `terraform plan` - should show the resources to be created.
+3. `terraform apply` - capture the *Apply complete!* summary line.
+4. `terraform plan` again - **must report `No changes`** (drift / idempotency proof).
+5. `terraform destroy` - capture the *Destroy complete!* line.
+6. `terraform plan` once more - should again report `No changes`
    (clean teardown proof).
 
 For data-source-only modules (no resources), steps 1-3 plus the
@@ -110,14 +110,14 @@ For data-source-only modules (no resources), steps 1-3 plus the
 
 ## Output excerpt rules
 
-- **Length** — paste 10-50 lines per command. Truncate the middle with
+- **Length** - paste 10-50 lines per command. Truncate the middle with
   `# ... <N> lines elided ...` if needed.
-- **Redaction** — replace cluster hostnames, serial numbers, license
+- **Redaction** - replace cluster hostnames, serial numbers, license
   keys, IP addresses, and SVM names if they are sensitive. Use placeholders
   like `cluster-1.example.com`, `10.0.0.1`, `svm0`. Do **not** redact
-  ONTAP version, return codes, counts, or error messages — those are
+  ONTAP version, return codes, counts, or error messages - those are
   the parts reviewers need.
-- **Format** — wrap output in fenced code blocks with the `text`
+- **Format** - wrap output in fenced code blocks with the `text`
   language tag for readability.
 
 ---
@@ -141,5 +141,5 @@ end-to-end evidence and without a credible reason will be sent back.
 
 A workflow checks the PR body for a populated Test Report and, when it
 looks empty, applies a `needs-test-report` label and posts a sticky
-comment pointing here. The check is informational — it does not fail
-the build — but reviewers will not approve a PR carrying that label.
+comment pointing here. The check is informational - it does not fail
+the build - but reviewers will not approve a PR carrying that label.
diff --git a/ansible/README.md b/ansible/README.md
index 9c3c5a6..c3efcf8 100644
--- a/ansible/README.md
+++ b/ansible/README.md
@@ -129,15 +129,15 @@ ansible-playbook -i inventory/hosts.yml cifs_provision.yml \
 
 ## Design Decisions
 
-- **FQCNs everywhere** — all modules use fully qualified collection names
+- **FQCNs everywhere** - all modules use fully qualified collection names
   (e.g., `netapp.ontap.na_ontap_volume`, not `na_ontap_volume`) per Ansible
   best practices
-- **`use_rest: always`** — forces the REST API transport; avoids falling back
+- **`use_rest: always`** - forces the REST API transport; avoids falling back
   to ZAPI on older collections
-- **`wait_for_completion: true`** — the `na_ontap_volume` module handles job
+- **`wait_for_completion: true`** - the `na_ontap_volume` module handles job
   polling internally, unlike the Python scripts where polling is manual
-- **`connection: local`** — ONTAP modules connect over HTTPS from the control
+- **`connection: local`** - ONTAP modules connect over HTTPS from the control
   node; no SSH to the cluster
-- **`no_log: false`** — explicitly set so reviewers can verify no task
+- **`no_log: false`** - explicitly set so reviewers can verify no task
   accidentally hides output; flip to `true` on tasks that echo credentials
   in production
diff --git a/docs/ai-prompt-catalog.md b/docs/ai-prompt-catalog.md
index 5206ddd..9279b1d 100644
--- a/docs/ai-prompt-catalog.md
+++ b/docs/ai-prompt-catalog.md
@@ -2,9 +2,9 @@
 
 This repository ships **reusable AI prompts** in two forms:
 
-1. **Copilot-native prompt files** in `.github/prompts/` — usable directly
+1. **Copilot-native prompt files** in `.github/prompts/` - usable directly
    from GitHub Copilot Chat, VS Code Copilot, and Cursor.
-2. **Copy-paste prompts** (below) — for any AI assistant (ChatGPT, Gemini,
+2. **Copy-paste prompts** (below) - for any AI assistant (ChatGPT, Gemini,
    Claude, etc.).
 
 ---
@@ -64,15 +64,15 @@ ONLY the ONTAP REST API.
 
 Task: [DESCRIBE THE STORAGE TASK]
 
-STEP 1 — CLARIFY: Ask me for any missing information (SVM, volume, aggregate,
+STEP 1 - CLARIFY: Ask me for any missing information (SVM, volume, aggregate,
 protocol, cluster hostname, special options).
 
-STEP 2 — API SEQUENCE: List ONTAP REST API calls in order. For each: method,
+STEP 2 - API SEQUENCE: List ONTAP REST API calls in order. For each: method,
 endpoint, key body/query params, sync/async, one-sentence justification.
 Rules: REST only (no ZAPI, no CLI, no SSH), target ONTAP 9.8+. Wait for my
 approval.
 
-STEP 3 — GENERATE PYTHON: File `python/<use_case>.py` with:
+STEP 3 - GENERATE PYTHON: File `python/<use_case>.py` with:
   • #!/usr/bin/env python3, from __future__ import annotations
   • Module docstring with steps, prerequisites, usage
   • from ontap_client import OntapClient (shared client, do NOT create a new one)
@@ -82,7 +82,7 @@ STEP 3 — GENERATE PYTHON: File `python/<use_case>.py` with:
   • logging module only (no print), type hints, no hardcoded credentials
   • if __name__ == "__main__": try/except guard with sys.exit(1)
 
-STEP 4 — VALIDATE: Run commands, error scenarios, teardown instructions.
+STEP 4 - VALIDATE: Run commands, error scenarios, teardown instructions.
 ````
 
 ---
@@ -95,14 +95,14 @@ the netapp.ontap collection (REST API only).
 
 Task: [DESCRIBE THE STORAGE TASK]
 
-STEP 1 — CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
+STEP 1 - CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
 cluster hostname, special options).
 
-STEP 2 — API SEQUENCE: List REST calls and map each to a netapp.ontap module.
+STEP 2 - API SEQUENCE: List REST calls and map each to a netapp.ontap module.
 Rules: use_rest: always, ONTAP 9.8+, FQCNs (netapp.ontap.na_ontap_*).
 Wait for approval.
 
-STEP 3 — GENERATE PLAYBOOK: File `ansible/<use_case>.yml` with:
+STEP 3 - GENERATE PLAYBOOK: File `ansible/<use_case>.yml` with:
   • --- header comment with filename, description, usage
   • hosts: ontap, gather_facts: false, connection: local
   • vars: section for operational defaults (overridable with -e)
@@ -111,7 +111,7 @@ STEP 3 — GENERATE PLAYBOOK: File `ansible/<use_case>.yml` with:
   • state: present for creates, wait_for_completion: true where supported
   • Final ansible.builtin.debug summary. No hardcoded credentials.
 
-STEP 4 — VALIDATE: Run command, idempotency behavior, teardown playbook.
+STEP 4 - VALIDATE: Run command, idempotency behavior, teardown playbook.
 ````
 
 ---
@@ -124,21 +124,21 @@ the NetApp/netapp-ontap provider (REST API only).
 
 Task: [DESCRIBE THE STORAGE TASK]
 
-STEP 1 — CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
+STEP 1 - CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
 cluster hostname, special options).
 
-STEP 2 — RESOURCE MAPPING: Map REST endpoints to Terraform resources/data
+STEP 2 - RESOURCE MAPPING: Map REST endpoints to Terraform resources/data
 sources. Rules: provider ~> 2.5, required_version >= 1.4, depends_on for
 ordering. Wait for approval.
 
-STEP 3 — GENERATE MODULE: Directory `terraform/<use-case>/` with:
-  • main.tf — provider block with connection_profiles, resources with
+STEP 3 - GENERATE MODULE: Directory `terraform/<use-case>/` with:
+  • main.tf - provider block with connection_profiles, resources with
     cx_profile_name = "cluster1"
-  • variables.tf — descriptions, types, sensitive = true for passwords
-  • outputs.tf — meaningful outputs with descriptions
-  • terraform.tfvars.example — placeholder values, no real credentials
+  • variables.tf - descriptions, types, sensitive = true for passwords
+  • outputs.tf - meaningful outputs with descriptions
+  • terraform.tfvars.example - placeholder values, no real credentials
 
-STEP 4 — VALIDATE: init/plan/apply commands, drift behavior, destroy teardown.
+STEP 4 - VALIDATE: init/plan/apply commands, drift behavior, destroy teardown.
 ````
 
 ---
@@ -151,14 +151,14 @@ You are a NetApp ONTAP automation engineer. Generate a COMPLETE example set
 
 Task: [DESCRIBE THE STORAGE TASK]
 
-PHASE 1 — CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
+PHASE 1 - CLARIFY: Ask for missing info (SVM, volume, aggregate, protocol,
 hostname, auth approach, special options).
 
-PHASE 2 — API SEQUENCE: Numbered list of REST API calls in order. For each:
+PHASE 2 - API SEQUENCE: Numbered list of REST API calls in order. For each:
 method, endpoint, body/query, sync/async, justification. REST only, ONTAP
 9.8+, no ZAPI/CLI/SSH. Wait for approval.
 
-PHASE 3 — GENERATE CODE:
+PHASE 3 - GENERATE CODE:
   Python (python/<use_case>.py):
     • from ontap_client import OntapClient, OntapClient.from_env(), argparse,
       logging, type hints, poll_job for async, try/except guard.
@@ -170,7 +170,7 @@ PHASE 3 — GENERATE CODE:
     • main.tf + variables.tf + outputs.tf + terraform.tfvars.example,
       provider ~> 2.5, connection_profiles, sensitive passwords.
 
-PHASE 4 — VALIDATE: Run commands, error handling, teardown for each tool.
+PHASE 4 - VALIDATE: Run commands, error handling, teardown for each tool.
 ````
 
 ---
diff --git a/docs/choosing-an-approach.md b/docs/choosing-an-approach.md
index 2f43311..1072193 100644
--- a/docs/choosing-an-approach.md
+++ b/docs/choosing-an-approach.md
@@ -1,7 +1,7 @@
 # Choosing an Automation Approach
 
 This guide helps you pick the right tool for automating ONTAP workflows.
-All three approaches in this repo do the same things — the difference is
+All three approaches in this repo do the same things - the difference is
 **how much you write**, **what you control**, and **what the tool manages
 for you**.
 
@@ -17,10 +17,10 @@ flowchart TD
     Q2 -->|Yes| Ansible[Ansible]
     Q2 -->|No| Q3{Custom logic, branching,\nor Python integrations?}
     Q3 -->|Yes| Python[Python scripts]
-    Q3 -->|No| Any[Any approach works —\npick what your team knows]
+    Q3 -->|No| Any[Any approach works -\npick what your team knows]
 ```
 
-Each tool has clear strengths. There is no single "right" answer — choose based
+Each tool has clear strengths. There is no single "right" answer - choose based
 on your team's existing skills and the operational requirements of your workflow.
 
 ---
@@ -72,24 +72,24 @@ Notes:
 
 ### Python scripts
 
-- **Custom business logic** — if/else, loops, data transformation
-- **Integration with other systems** — combine ONTAP calls with Slack, Jira, databases
+- **Custom business logic** - if/else, loops, data transformation
+- **Integration with other systems** - combine ONTAP calls with Slack, Jira, databases
 - **One-off scripts** for teams that already think in Python
 - **Full control** over error handling, retries, and output formatting
 
 ### Ansible playbooks
 
-- **Fleet operations** — run the same playbook against 50 clusters via inventory
-- **Idempotent provisioning** — `state: present` / `state: absent` does the right thing
+- **Fleet operations** - run the same playbook against 50 clusters via inventory
+- **Idempotent provisioning** - `state: present` / `state: absent` does the right thing
 - **Teams already using Ansible** for OS/app config management
-- **Ansible Tower / AWX** — centralized scheduling, RBAC, audit trail
+- **Ansible Tower / AWX** - centralized scheduling, RBAC, audit trail
 
 ### Terraform
 
-- **Infrastructure lifecycle** — create, update, destroy with full state tracking
-- **Drift detection** — `terraform plan` shows what changed since last apply
-- **Multi-provider** — manage ONTAP alongside AWS/Azure/GCP in one plan
-- **Compliance / auditability** — state file is the source of truth
+- **Infrastructure lifecycle** - create, update, destroy with full state tracking
+- **Drift detection** - `terraform plan` shows what changed since last apply
+- **Multi-provider** - manage ONTAP alongside AWS/Azure/GCP in one plan
+- **Compliance / auditability** - state file is the source of truth
 
 ---
 
diff --git a/docs/index.html b/docs/index.html
index d634426..75b097b 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -9,14 +9,14 @@
 <head>
 <meta charset="UTF-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-<title>Pace — Storage automation, in three different styles.</title>
-<meta name="description" content="Pace is an open-source library of ready-to-run NetApp ONTAP storage automation examples written across three styles — imperative scripts, declarative playbooks, and stateful blueprints — to make the trade-offs visible and the right approach easier to pick." />
+<title>Pace - Storage automation, in three different styles.</title>
+<meta name="description" content="Pace is an open-source library of ready-to-run NetApp ONTAP storage automation examples written across three styles - imperative scripts, declarative playbooks, and stateful blueprints - to make the trade-offs visible and the right approach easier to pick." />
 <link rel="preconnect" href="https://fonts.googleapis.com" />
 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
 <link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700;800;900&family=JetBrains+Mono:wght@400;500;600&family=Space+Grotesk:wght@400;500;600;700&display=swap" rel="stylesheet" />
 <style>
 /* =========================================================================
-   PACE PORTFOLIO — single-file, modular sections
+   PACE PORTFOLIO - single-file, modular sections
    1. Reset & Tokens (with light/dark themes)
    2. Layout primitives & typography
    3. Ambient background (orbs, grid, stars)
@@ -765,10 +765,10 @@ <h1 data-reveal data-reveal-delay="2" style="margin-top:24px;">
         <p class="hero-lead" data-reveal data-reveal-delay="2">
           <b>Pace</b> is an open-source library of ready-to-run automation
           examples for <b>NetApp</b>, starting with <b>ONTAP</b>. Workflows
-          are written across three styles — as imperative <b>scripts</b> that
+          are written across three styles - as imperative <b>scripts</b> that
           execute step by step, declarative <b>playbooks</b> that describe
           the desired outcome, or stateful <b>blueprints</b> that track and
-          enforce infrastructure over time — making it easier to pick the
+          enforce infrastructure over time - making it easier to pick the
           right approach for each job.
         </p>
         <div class="hero-cta" data-reveal data-reveal-delay="3">
@@ -828,14 +828,14 @@ <h3 style="font-family:var(--font-sans); font-size:24px; margin-bottom:8px;">
         </h3>
         <p style="color:var(--text-muted)">
           Tasks are built in three styles, side by side. Underneath, they all talk
-          to the same storage system — so the real differences are obvious: how
+          to the same storage system - so the real differences are obvious: how
           much code you write, how safe it is to re-run, how easy it is to undo,
           and how much the tool handles for you versus how much you handle yourself.
         </p>
         <p style="color:var(--text-muted); margin-top:14px;">
           Some styles give you full control over every step. Others let you
           describe what you want and figure out the rest. The same task, the same
-          outcome — just different trade-offs in readability, flexibility, and
+          outcome - just different trade-offs in readability, flexibility, and
           maintenance. Seeing them next to each other makes those trade-offs
           concrete instead of theoretical.
         </p>
@@ -924,9 +924,9 @@ <h4>Each example just runs</h4>
       <div class="eyebrow" data-reveal>PICK YOUR STYLE</div>
       <h2 data-reveal data-reveal-delay="1">One task, three styles.</h2>
       <p class="lead" data-reveal data-reveal-delay="2">
-        Here's one task — printing cluster info — written in all three styles.
+        Here's one task - printing cluster info - written in all three styles.
         The tool used in each example is one representative of its style.
-        Across the wider library, coverage varies — not every example exists
+        Across the wider library, coverage varies - not every example exists
         in every style.
       </p>
     </div>
@@ -950,16 +950,16 @@ <h2 data-reveal data-reveal-delay="1">One task, three styles.</h2>
       <!-- SCRIPTS (today: Python) -->
       <div class="tool-pane active" data-tool="python" role="tabpanel">
         <div class="tool-meta">
-          <h3>Imperative scripts — you write each step yourself.</h3>
+          <h3>Imperative scripts - you write each step yourself.</h3>
           <p class="summary">You spell out every step in order: call this, then call that, retry if it fails. A natural fit when a job needs custom logic, data transforms, or has to talk to other systems. Today shown in <code>Python</code>; the same idea fits other general-purpose languages.</p>
           <div class="specs">
             <div class="spec"><div class="k">Style</div><div class="vv">Imperative scripts</div></div>
-            <div class="spec"><div class="k">Tracks state</div><div class="vv">No — you handle it</div></div>
+            <div class="spec"><div class="k">Tracks state</div><div class="vv">No - you handle it</div></div>
             <div class="spec"><div class="k">Safe to re-run</div><div class="vv">You write that in</div></div>
             <div class="spec"><div class="k">Lines of code</div><div class="vv">145 + 188 helpers<small>NAS provisioning example</small></div></div>
           </div>
           <div class="when">
-            <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> See every API call — easy to debug</div>
+            <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> See every API call - easy to debug</div>
             <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> Fits one-off jobs and gluing systems together</div>
             <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> When you need branching, retries, or custom integrations</div>
           </div>
@@ -985,17 +985,17 @@ <h3>Imperative scripts — you write each step yourself.</h3>
       <!-- RECIPES (today: Ansible) -->
       <div class="tool-pane" data-tool="ansible" role="tabpanel">
         <div class="tool-meta">
-          <h3>Declarative playbooks — say what you want, not how.</h3>
-          <p class="summary">You write a playbook — "the volume should exist with these settings" — and the tool figures out what to change. Safe to run over and over, and easy to apply to many clusters at once. Today shown in <code>Ansible</code>; the same idea fits other configuration-management tools.</p>
+          <h3>Declarative playbooks - say what you want, not how.</h3>
+          <p class="summary">You write a playbook - "the volume should exist with these settings" - and the tool figures out what to change. Safe to run over and over, and easy to apply to many clusters at once. Today shown in <code>Ansible</code>; the same idea fits other configuration-management tools.</p>
           <div class="specs">
             <div class="spec"><div class="k">Style</div><div class="vv">Declarative playbooks</div></div>
-            <div class="spec"><div class="k">Tracks state</div><div class="vv">No — checks each run</div></div>
+            <div class="spec"><div class="k">Tracks state</div><div class="vv">No - checks each run</div></div>
             <div class="spec"><div class="k">Safe to re-run</div><div class="vv">Built in</div></div>
             <div class="spec"><div class="k">Lines of code</div><div class="vv">96<small>NAS provisioning example</small></div></div>
           </div>
           <div class="when">
             <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> Run the same playbook across many clusters at once</div>
-            <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> Safe to re-run any time — won't double up</div>
+            <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> Safe to re-run any time - won't double up</div>
             <div class="pill"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12l5 5 9-9"/></svg> Fits when you need to keep many clusters in a known good state</div>
           </div>
         </div>
@@ -1027,11 +1027,11 @@ <h3>Declarative playbooks — say what you want, not how.</h3>
       <!-- BLUEPRINTS (today: Terraform) -->
       <div class="tool-pane" data-tool="terraform" role="tabpanel">
         <div class="tool-meta">
-          <h3>Stateful blueprints — track everything, see every change.</h3>
+          <h3>Stateful blueprints - track everything, see every change.</h3>
           <p class="summary">You declare the resources you want, and the tool keeps a record of what it built. Before any change, you get a preview of exactly what will happen. Cleanup is one command. Today shown in <code>Terraform</code>; the same idea fits other declarative IaC tools.</p>
           <div class="specs">
             <div class="spec"><div class="k">Style</div><div class="vv">Stateful blueprints</div></div>
-            <div class="spec"><div class="k">Tracks state</div><div class="vv">Yes — full record</div></div>
+            <div class="spec"><div class="k">Tracks state</div><div class="vv">Yes - full record</div></div>
             <div class="spec"><div class="k">Safe to re-run</div><div class="vv">Preview, then apply</div></div>
             <div class="spec"><div class="k">Lines of code</div><div class="vv">155<small>NAS provisioning example</small></div></div>
           </div>
@@ -1077,7 +1077,7 @@ <h3>Stateful blueprints — track everything, see every change.</h3>
       <div class="eyebrow" data-reveal>PROMPT TEMPLATES</div>
       <h2 data-reveal data-reveal-delay="1">Reusable prompts: plan, generate, review.</h2>
       <p class="lead" data-reveal data-reveal-delay="2">
-        The repo includes reusable prompts that cover the full loop — planning
+        The repo includes reusable prompts that cover the full loop - planning
         a new use case, generating a first draft, and reviewing the result.
         Paste them into your AI assistant of choice; the output is a starting
         point that still needs human review and testing.
@@ -1095,7 +1095,7 @@ <h2 data-reveal data-reveal-delay="1">Reusable prompts: plan, generate, review.<
           </span>
           <h3>Plan</h3>
         </div>
-        <p>Break a use case into the resources, dependencies, and edge cases worth handling — before any code is written.</p>
+        <p>Break a use case into the resources, dependencies, and edge cases worth handling - before any code is written.</p>
       </div>
       <div class="prompt-card">
         <div class="prompt-card-head">
@@ -1120,14 +1120,14 @@ <h3>Generate</h3>
           </span>
           <h3>Review</h3>
         </div>
-        <p>Surface idempotency, error handling, naming, and convention drift — a second pair of eyes before opening a PR.</p>
+        <p>Surface idempotency, error handling, naming, and convention drift - a second pair of eyes before opening a PR.</p>
       </div>
     </div>
 
     <div class="prompt-note" data-reveal>
       <strong>AI output is a draft, not a merge.</strong> Run the project's
       checks, validate against a real cluster, and have a maintainer review
-      before opening a PR — the same as any human-written change.
+      before opening a PR - the same as any human-written change.
     </div>
   </div>
 </section>
@@ -1142,7 +1142,7 @@ <h3>Review</h3>
       <h2 data-reveal data-reveal-delay="1">From your first edit to a merged PR in 5 steps.</h2>
       <p class="lead" data-reveal data-reveal-delay="2">
         Use clear commit messages, get one approving review, make sure the checks
-        pass. That's the whole protocol — no matter which style you contribute to.
+        pass. That's the whole protocol - no matter which style you contribute to.
       </p>
     </div>
 
@@ -1156,17 +1156,17 @@ <h4>Fork &amp; clone</h4>
         <div class="flow-step">
           <div class="num">2</div>
           <h4>Set up locally</h4>
-          <p>Install the tools for the style you'll touch — the contribution guide walks through it.</p>
+          <p>Install the tools for the style you'll touch - the contribution guide walks through it.</p>
         </div>
         <div class="flow-step">
           <div class="num">3</div>
           <h4>Add a use case</h4>
-          <p>One style is enough — script, playbook, or blueprint. Add more if you'd like.</p>
+          <p>One style is enough - script, playbook, or blueprint. Add more if you'd like.</p>
         </div>
         <div class="flow-step">
           <div class="num">4</div>
           <h4>Run the checks</h4>
-          <p>Run the same checks locally that CI runs on every PR — lint, tests, formatting.</p>
+          <p>Run the same checks locally that CI runs on every PR - lint, tests, formatting.</p>
         </div>
         <div class="flow-step">
           <div class="num">5</div>
@@ -1177,7 +1177,7 @@ <h4>Open a PR</h4>
 
       <div class="cta-band">
         <div class="copy">
-          <h4>Got a use case — or a new tool to add?</h4>
+          <h4>Got a use case - or a new tool to add?</h4>
           <p>Adding examples in another tool, or a use case we haven't covered yet? Welcome here.</p>
         </div>
         <div class="actions">
@@ -1211,7 +1211,7 @@ <h4>Got a use case — or a new tool to add?</h4>
           </span>
           <span class="nav-brand-name">Pace</span>
         </a>
-        <p>NetApp ONTAP storage automation, in three different styles — imperative scripts, declarative playbooks, stateful blueprints. Apache 2.0.</p>
+        <p>NetApp ONTAP storage automation, in three different styles - imperative scripts, declarative playbooks, stateful blueprints. Apache 2.0.</p>
       </div>
       <div class="footer-col">
         <h5>Project</h5>
@@ -1333,7 +1333,7 @@ <h5>Community</h5>
   const termTabs = document.querySelectorAll('.terminal-bar .tab');
   const scripts = {
     python: [
-      { t: '<span class="cmt"># imperative scripts — explicit step-by-step</span>' },
+      { t: '<span class="cmt"># imperative scripts - explicit step-by-step</span>' },
       { t: '<span class="prompt">$ </span><span class="kw">export</span> ONTAP_HOST=<span class="str">10.0.0.1</span> ONTAP_USER=admin' },
       { t: '<span class="prompt">$ </span>./run cluster-info', delay: 600 },
       { t: '<span class="out">Cluster: lab-cluster (ONTAP 9.15.1)</span>' },
@@ -1342,7 +1342,7 @@ <h5>Community</h5>
       { t: '<span class="prompt">$ </span><span class="cursor-blink"></span>' },
     ],
     ansible: [
-      { t: '<span class="cmt"># declarative playbooks — describe the outcome, safe to re-run</span>' },
+      { t: '<span class="cmt"># declarative playbooks - describe the outcome, safe to re-run</span>' },
       { t: '<span class="prompt">$ </span>ansible-playbook cluster-info', delay: 600 },
       { t: '<span class="out">PLAY [ontap] *********</span>' },
       { t: '<span class="out">TASK [Get cluster info] ok: [primary]</span>' },
@@ -1351,7 +1351,7 @@ <h5>Community</h5>
       { t: '<span class="prompt">$ </span><span class="cursor-blink"></span>' },
     ],
     terraform: [
-      { t: '<span class="cmt"># stateful blueprints — preview, then apply, track every change</span>' },
+      { t: '<span class="cmt"># stateful blueprints - preview, then apply, track every change</span>' },
       { t: '<span class="prompt">$ </span>terraform init', delay: 400 },
       { t: '<span class="out">Initializing provider plugins... ontap v1.1</span>' },
       { t: '<span class="prompt">$ </span>terraform apply -auto-approve', delay: 600 },
diff --git a/docs/ontap-api-patterns.md b/docs/ontap-api-patterns.md
index 886a12a..1e1cbb4 100644
--- a/docs/ontap-api-patterns.md
+++ b/docs/ontap-api-patterns.md
@@ -17,7 +17,7 @@ https://<cluster-management-ip-or-hostname>/api/<category>/<resource>
 
 | Field | Value | Notes |
 |-------|-------|-------|
-| `username` | Admin user | Basic auth — typically `admin` |
+| `username` | Admin user | Basic auth - typically `admin` |
 | `password` | Admin password | Never hardcode; use env vars or vault |
 | `verify_ssl` | `false` | Supports self-signed certs; set `true` once CA-signed certs are in place |
 
@@ -87,7 +87,7 @@ instead of completing synchronously.
 }
 ```
 
-Key field: `job.uuid` — used to construct the poll URL.
+Key field: `job.uuid` - used to construct the poll URL.
 
 ### Job Poll Result
 
@@ -109,9 +109,9 @@ Job states: `queued`, `running`, `success`, `failure`.
 Any POST or PATCH that triggers a long-running operation returns a `job` object.
 The standard pattern is:
 
-1. **Trigger** — POST/PATCH returns `{ "job": { "uuid": "..." } }`
-2. **Poll** — GET `/api/cluster/jobs/{uuid}?fields=state,message&return_timeout=120` until `state != running`
-3. **Continue** — use the poll result's `state` and `message` in downstream logic
+1. **Trigger** - POST/PATCH returns `{ "job": { "uuid": "..." } }`
+2. **Poll** - GET `/api/cluster/jobs/{uuid}?fields=state,message&return_timeout=120` until `state != running`
+3. **Continue** - use the poll result's `state` and `message` in downstream logic
 
 ## Common API Categories
 
@@ -177,6 +177,6 @@ Additional variables depend on the operation (e.g. `VOLUME_NAME`, `AGGR_NAME`, `
 
 | Scenario | `attempts` | `delay_seconds` |
 |----------|-----------|-----------------|
-| Standard GET | 1 (no retry) | — |
+| Standard GET | 1 (no retry) | - |
 | Network-dependent discovery | 3 | 30 |
 | Flaky endpoints | 3 | 5 |
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index bec0816..952427e 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -31,13 +31,13 @@ nslookup <ONTAP_HOST>
 
 ## Authentication Failures
 
-### HTTP 401 — Unauthorized
+### HTTP 401 - Unauthorized
 
 - Double-check `ONTAP_USER` and `ONTAP_PASS` (or the Ansible/Terraform equivalents).
 - Ensure the user account is not locked (`security login show -vserver <svm>`).
 - Verify the user has REST API access (`security login role show`).
 
-### HTTP 403 — Forbidden
+### HTTP 403 - Forbidden
 
 The credentials are valid but the user lacks the required RBAC permissions
 for the endpoint being called. Check the ONTAP documentation for the
@@ -163,7 +163,7 @@ backend or separate workspaces to avoid state collisions.
 
 ### Volume already exists
 
-The Python `nfs_provision.py` script is not idempotent — running it twice
+The Python `nfs_provision.py` script is not idempotent - running it twice
 with the same volume name will fail. Either:
 
 - Choose a different volume name, or
diff --git a/python/README.md b/python/README.md
index 3cf5e32..812b6aa 100644
--- a/python/README.md
+++ b/python/README.md
@@ -10,7 +10,7 @@ To compare this approach with Ansible or Terraform, see
 [Choosing an approach](../docs/choosing-an-approach.md).
 
 > **Note:** These scripts are runnable illustrations, not a tested library.
-> There are no unit tests by design — CI validates only lint and formatting
+> There are no unit tests by design - CI validates only lint and formatting
 > via Ruff. When you adapt a script for production, add tests appropriate
 > to your environment.
 
@@ -106,13 +106,13 @@ All flags can also be set via environment variables (`SVM_NAME`, `VOLUME_NAME`,
 
 These scripts demonstrate several patterns you can reuse:
 
-- **`OntapClient.from_env()`** — builds a configured client from environment
+- **`OntapClient.from_env()`** - builds a configured client from environment
   variables so credentials never appear in code
-- **`client.poll_job(uuid)`** — polls an async ONTAP job until completion with
+- **`client.poll_job(uuid)`** - polls an async ONTAP job until completion with
   configurable interval and timeout
-- **Context manager** — `with OntapClient.from_env() as client:` ensures the
+- **Context manager** - `with OntapClient.from_env() as client:` ensures the
   HTTP session is properly closed
-- **Structured logging** — all output goes through `logging`, not `print()`,
+- **Structured logging** - all output goes through `logging`, not `print()`,
   so you can control verbosity and format
 
 ## Adapting for Your Environment
@@ -120,13 +120,13 @@ These scripts demonstrate several patterns you can reuse:
 These scripts illustrate workflows using simple API call sequences. When
 adapting them, consider adding the following based on your requirements:
 
-- **Idempotency** — check whether a resource exists before creating it
+- **Idempotency** - check whether a resource exists before creating it
   (e.g. `GET /storage/volumes?name=vol01&svm.name=vs0` before calling
   `POST /storage/volumes`). Ansible modules handle this natively; Python
   and Terraform scripts require explicit checks or state tracking.
-- **Retry and backoff** — handle transient network or API errors gracefully
-- **Partial failure recovery** — clean up or resume when a multi-step workflow
+- **Retry and backoff** - handle transient network or API errors gracefully
+- **Partial failure recovery** - clean up or resume when a multi-step workflow
   fails midway
-- **Dry-run mode** — log intended actions without executing them
-- **Input validation** — enforce constraints on volume sizes, naming
+- **Dry-run mode** - log intended actions without executing them
+- **Input validation** - enforce constraints on volume sizes, naming
   conventions, or CIDR ranges before calling the API
diff --git a/terraform/README.md b/terraform/README.md
index 0e5a056..51ad3f1 100644
--- a/terraform/README.md
+++ b/terraform/README.md
@@ -18,7 +18,7 @@ To compare this approach with Python or Ansible, see
 - Network access to an ONTAP cluster management LIF (HTTPS)
 - Cluster admin credentials (or appropriate RBAC user)
 
-No manual provider download is needed — `terraform init` fetches the
+No manual provider download is needed - `terraform init` fetches the
 `NetApp/netapp-ontap` provider automatically.
 
 ## Setup
@@ -52,7 +52,7 @@ terraform apply
 
 ### Cluster Info
 
-Read-only — retrieves the cluster version and lists all nodes. Uses only
+Read-only - retrieves the cluster version and lists all nodes. Uses only
 Terraform data sources, so `terraform apply` makes no changes to the cluster.
 
 ```bash
@@ -134,15 +134,15 @@ terraform/
 
 ## Design Decisions
 
-- **Self-contained root modules** — each directory is independent with its
+- **Self-contained root modules** - each directory is independent with its
   own provider block and state. This keeps examples copy-paste-friendly;
   you can grab one directory without pulling the whole repo.
-- **`sensitive = true`** on password variables — Terraform redacts these from
+- **`sensitive = true`** on password variables - Terraform redacts these from
   plan/apply output and state display.
-- **`depends_on` for ordering** — the NFS module creates the export policy
+- **`depends_on` for ordering** - the NFS module creates the export policy
   and rule before the volume, using explicit `depends_on` to guarantee the
   policy is ready when the volume references it.
-- **No remote backend** — examples use the default local backend. Production
+- **No remote backend** - examples use the default local backend. Production
   users should configure S3/GCS/Consul for shared state.
-- **`terraform.tfvars` over environment variables** — Terraform's native
+- **`terraform.tfvars` over environment variables** - Terraform's native
   variable mechanism; cleaner than `TF_VAR_*` env vars for examples.