Simplify documentation language and remove superlatives

Architecture.md

@@ -1,6 +1,6 @@
 # **Architecture: patience CLI**
 
-This document outlines the architecture for the modern, strategy-based patience command-line utility, written in Go.
+This document outlines the architecture for the patience command-line utility, written in Go.
 
 ## **1\. Core Philosophy**
 
@@ -11,7 +11,7 @@ The patience CLI is designed to be:
 * **Reliable:** A trustworthy tool for wrapping and retrying critical commands in production environments
 * **Observant:** Provides clear, actionable feedback and metrics with real-time status reporting
 * **Flexible:** Supports a wide range of use cases, from simple scripts to complex distributed systems
-* **Modern:** Leverages modern CLI patterns (subcommands) and system capabilities
+* **Modern:** Uses subcommand patterns and system capabilities
 * **Self-contained:** Core functionality works flawlessly without external dependencies. The daemon is optional.
 
 ## **2\. High-Level Components**
@@ -72,13 +72,13 @@ The system consists of three main components:
 
 ## **3\. patience CLI \- Detailed Architecture**
 
-The CLI uses a modern subcommand-based architecture where each backoff strategy is a dedicated subcommand with specialized configuration.
+The CLI uses a subcommand-based architecture where each backoff strategy is a dedicated subcommand with its own configuration.
 
 ### **3.1. Subcommand Architecture Design**
 
 **Design Decision: Subcommands vs. Flags**
 
-We chose subcommands over a flag-based approach for several key reasons:
+Subcommands were chosen over a flag-based approach for these reasons:
 
 1. **Strategy-Specific Configuration:** Each strategy has unique parameters (e.g., HTTP-aware has `--fallback`, exponential has `--multiplier`)
 2. **Discoverability:** Users can explore strategies with `patience --help` and get strategy-specific help with `patience STRATEGY --help`
@@ -252,7 +252,7 @@ When patienced is not running, the CLI is the sole source of information. It pro
 
 ### **3.3. HTTP-Aware Intelligence**
 
-The HTTP-aware strategy represents a significant architectural innovation:
+The HTTP-aware strategy provides the following capabilities:
 
 **HTTP Response Parsing:**
 - Extracts `Retry-After` headers from HTTP responses
@@ -263,10 +263,10 @@ The HTTP-aware strategy represents a significant architectural innovation:
 **Real-World Validation:**
 - Tested against 7 major APIs: GitHub, Twitter, AWS, Stripe, Discord, Reddit, Slack
 - Handles various HTTP response formats and timing conventions
-- Respects server load and rate limiting automatically
+- Respects server load and rate limiting
 
 **Fallback Strategy Integration:**
-- Seamlessly integrates with any mathematical strategy as fallback
+- Integrates with any mathematical strategy as fallback
 - Allows users to specify fallback behavior: `--fallback exponential`
 - Maintains consistent behavior when HTTP information is unavailable
 
@@ -297,7 +297,7 @@ The HTTP-aware strategy represents a significant architectural innovation:
 
 ## **4\. patienced Daemon \- Detailed Architecture**
 
-The daemon is a long-running, optional background service for metrics aggregation.
+The daemon is an optional background service for metrics aggregation.
 
 ### **4.1. Core Responsibilities**
 
@@ -329,7 +329,7 @@ When the daemon is active, the following metrics are collected and aggregated:
 ### **5.1. Subcommand Architecture Benefits**
 
 **User Experience:**
-- **Intuitive Discovery:** `patience --help` shows all available strategies
+- **Discovery:** `patience --help` shows all available strategies
 - **Strategy-Specific Help:** `patience exponential --help` shows relevant options only
 - **Shorter Commands:** `patience exp -b 1s` vs `patience --backoff exponential --delay 1s` (58% shorter)
 - **No Flag Conflicts:** Each strategy can have unique flags without namespace pollution
@@ -349,7 +349,7 @@ When the daemon is active, the following metrics are collected and aggregated:
 ### **5.2. HTTP-Aware Strategy Benefits**
 
 **Adaptive Intelligence:**
-- **Server-Directed Timing:** Respects server load and rate limiting automatically
+- **Server-Directed Timing:** Respects server load and rate limiting
 - **Optimal Performance:** Reduces unnecessary load on struggling servers
 - **Real-World Tested:** Validated against major APIs in production use
 - **Graceful Degradation:** Falls back to mathematical strategies when needed
@@ -362,9 +362,9 @@ When the daemon is active, the following metrics are collected and aggregated:
 
 ## **6\. Technology Choices**
 
-* **Language:** Go. Ideal for creating efficient, self-contained, cross-platform CLI tools. Excellent concurrency model for handling subprocesses, timeouts, and HTTP parsing.
-* **CLI Framework:** Cobra. Industry-standard library for building modern CLI applications with subcommand support.
-* **HTTP Parsing:** Go standard library (`net/http`, `encoding/json`). No external dependencies for HTTP intelligence.
+* **Language:** Go — efficient, self-contained, cross-platform CLI tooling with a strong concurrency model for handling subprocesses, timeouts, and HTTP parsing.
+* **CLI Framework:** Cobra — the standard library for Go CLI applications with subcommand support.
+* **HTTP Parsing:** Go standard library (`net/http`, `encoding/json`) — no external dependencies for HTTP intelligence.
 * **Configuration:** Custom TOML-based configuration with precedence handling (file → environment → flags).
-* **Testing:** Go standard testing with testify for assertions. Comprehensive test coverage including real HTTP integration tests.
-* **Metrics Exposition:** prometheus/client\_golang. Standard Go library for instrumenting applications with Prometheus metrics.
+* **Testing:** Go standard testing with testify for assertions, including real HTTP integration tests.
+* **Metrics Exposition:** prometheus/client\_golang — the standard Go library for Prometheus metrics.

CONTRIBUTING.md

@@ -1,14 +1,14 @@
 # Contributing to Patience
 
-Thank you for your interest in contributing to the Patience project! This document outlines our code quality standards and development practices.
+This document outlines code quality standards and development practices for the Patience project.
 
 ## Code Quality Standards
 
-This project maintains high code quality through automated quality gates that prevent regression of critical improvements made during our TDD development cycles.
+This project uses automated quality gates to prevent regression of improvements made during TDD development cycles.
 
 ### Quality Gates Overview
 
-Our CI/CD pipeline enforces the following quality standards:
+The CI/CD pipeline enforces these quality standards:
 
 #### 1. Function Complexity (TDD Cycle 1 Fix)
 - **Maximum function length**: 120 lines
@@ -61,7 +61,7 @@ go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
 
 ### 2. Before Committing
 
-Run these commands to ensure your changes meet quality standards:
+Run these commands before committing:
 
 ```bash
 # Format code
@@ -79,7 +79,7 @@ go test -bench=. -benchtime=1s -run=^$ ./...
 
 ### 3. Pre-commit Hooks
 
-Our pre-commit hooks automatically check for:
+Pre-commit hooks check for:
 - Code formatting and imports
 - Function complexity limits
 - Magic number detection
@@ -89,7 +89,7 @@ Our pre-commit hooks automatically check for:
 
 ### 4. CI/CD Pipeline
 
-All pull requests must pass our comprehensive CI/CD pipeline:
+All pull requests must pass the CI/CD pipeline:
 
 - **Linting**: golangci-lint with comprehensive rules
 - **Testing**: Unit tests with race detection on Go 1.21 and 1.22
@@ -207,7 +207,7 @@ Brief description of changes and motivation.
 
 ## Quality Metrics
 
-Our current quality metrics (maintained by automation):
+Current quality metrics (maintained by automation):
 
 - **Function Complexity**: ✅ All functions under 120 lines
 - **Magic Numbers**: ✅ All constants properly extracted
@@ -226,7 +226,7 @@ Our current quality metrics (maintained by automation):
 
 ## Regression Prevention
 
-Our automated systems prevent regression of these critical fixes:
+Automated checks prevent regression of these fixes:
 
 1. **TDD Cycle 1**: Function complexity and magic number elimination
 2. **TDD Cycle 2**: Error handling improvements
@@ -237,4 +237,4 @@ Any changes that would reintroduce these issues will be automatically rejected b
 
 ---
 
-By following these guidelines, you help maintain the high code quality standards that make Patience a reliable and maintainable project. Thank you for your contributions!
+These guidelines keep the codebase reliable and maintainable.

DAEMON.md

@@ -1,6 +1,6 @@
 # Patience Daemon (patienced)
 
-The patience daemon (`patienced`) is a background service that collects and aggregates metrics from patience CLI instances, providing a centralized monitoring solution for patience operations across your infrastructure.
+The patience daemon (`patienced`) is an optional background service. It collects and aggregates metrics from patience CLI instances and provides a centralized monitoring solution for patience operations.
 
 **Author:** Shane Isley  
 **Repository:** [github.com/shaneisley/patience](https://github.com/shaneisley/patience)
@@ -265,7 +265,7 @@ The dashboard provides:
 
 ## Integration with patience CLI
 
-The patience CLI automatically sends metrics to the daemon when available. The daemon also provides coordination services for the Diophantine strategy, enabling multi-instance rate limiting.
+The patience CLI sends metrics to the daemon when the daemon is running. The daemon also coordinates the Diophantine strategy across multiple instances.
 
 ### Diophantine Strategy Coordination
 
@@ -436,7 +436,7 @@ patienced -enable-profiling
 1. **Monitor resource usage**: Check memory and CPU usage
 2. **Review logs**: Look for errors or warnings
 3. **Update configuration**: Adjust limits based on usage patterns
-4. **Restart periodically**: Consider periodic restarts for long-running instances
+4. **Restart periodically**: Restart long-running instances periodically
 
 ### Backup and Recovery
 

DOCUMENTATION.md

@@ -1,6 +1,6 @@
 # Documentation Maintenance Guide
 
-This document outlines the processes and standards for maintaining the patience CLI documentation suite.
+This document describes the processes and standards for maintaining the patience CLI documentation.
 
 ## Documentation Structure
 
@@ -46,11 +46,11 @@ The patience project maintains several documentation files:
 ### 3. Quality Standards
 
 **Writing Standards:**
-- Use clear, concise language
+- Write clearly and concisely
 - Include practical examples for all features
-- Maintain consistent terminology (see [Terminology](#terminology))
+- Use consistent terminology (see [Terminology](#terminology))
 - Follow markdown best practices
-- Include cross-references between related sections
+- Cross-reference related sections
 
 **Technical Standards:**
 - All code examples must be tested and working
@@ -220,4 +220,4 @@ For questions about documentation maintenance:
 
 ---
 
-*This document is maintained as part of the patience CLI project. Last updated: 2026-02-15*
+*Last updated: 2026-02-15*

README.md

@@ -1,14 +1,14 @@
 # patience
 
-A modern, intelligent command-line tool for practicing patience with adaptive backoff strategies. Built with Go and designed to be your patient companion when dealing with flaky commands, network requests, or any process that might need a second (or third, or fourth) chance.
+A command-line tool for retrying commands with adaptive backoff strategies, written in Go. Use it when commands fail due to transient errors — network blips, rate limits, flaky services, or any process that benefits from a second attempt.
 
 **Author:** Shane Isley  
 **Repository:** [github.com/shaneisley/patience](https://github.com/shaneisley/patience)  
 **License:** MIT
 
 ## Why patience?
 
-We've all been there – a deployment script fails because of a temporary network hiccup, a test flakes out randomly, or an API call times out just when you need it most. Instead of manually running the same command over and over, let `patience` handle the tedious work for you with grace and wisdom.
+Deployment scripts fail on temporary network hiccups. Tests flake out randomly. API calls time out at inconvenient moments. Instead of running the same command over and over manually, let `patience` handle the retries.
 
 ## Features
 
@@ -36,7 +36,7 @@ We've all been there – a deployment script fails because of a temporary networ
 
 ## Quick Start
 
-Get up and running with patience in under 2 minutes:
+Get up and running with patience:
 
 ### 1. Install
 ```bash
@@ -172,7 +172,7 @@ patience http-aware --success-pattern "SUCCESS" --case-insensitive -- deployment
 
 ## Pattern Matching
 
-Many real-world commands don't use exit codes properly. A deployment script might print "deployment successful" but exit with code 1, or a health check might exit with code 0 but print "Error: service unavailable". Pattern matching solves this by letting you define success and failure based on the command's output.
+Many commands don't use exit codes correctly. A deployment script might print "deployment successful" but exit with code 1, or a health check might exit with code 0 but print "Error: service unavailable". Pattern matching lets you define success and failure based on the command's output instead.
 
 ### Success Patterns
 
@@ -239,7 +239,7 @@ patience exponential --success-pattern "(deployed|updated) successfully" -- depl
 
 ### HTTP-Aware Strategy (`http-aware`, `ha`)
 
-The HTTP-aware strategy is patience's flagship feature - it intelligently parses HTTP responses to determine optimal patience timing.
+The HTTP-aware strategy parses HTTP responses to determine optimal retry timing.
 
 ```bash
 # Basic HTTP-aware patience
@@ -445,7 +445,7 @@ Use `--debug-config` to see how configuration values are resolved:
 patience exponential --debug-config -- command
 ```
 
-This shows the source of each configuration value (CLI flag, environment variable, config file, or default).
+This shows where each configuration value came from (CLI flag, environment variable, config file, or default).
 
 ## Command-Line Options
 
@@ -553,7 +553,7 @@ This shows the source of each configuration value (CLI flag, environment variabl
 
 ## Behavior
 
-**Important:** `patience` stops immediately when a command succeeds - it does not execute remaining attempts.
+`patience` stops immediately when a command succeeds and skips remaining attempts.
 
 - ✅ **Exits on first success** - If attempt 1 succeeds, attempts 2-N are never executed
 - 🔄 **Only has patience on failure** - Success means the job is complete
@@ -575,7 +575,7 @@ patience http-aware --attempts 5 -- curl https://httpbin.org/status/200
 
 ## Migration Guide
 
-Switching from other retry tools? Here's how to migrate common patterns to patience:
+Switching from other retry tools? Common migration patterns:
 
 ### From `retry` (bash script)
 
@@ -672,7 +672,7 @@ Check out [examples.md](examples.md) for real-world usage scenarios and common p
 
 ## Development
 
-This project follows Test-Driven Development (TDD) principles and is built incrementally. The codebase includes:
+This project follows Test-Driven Development (TDD) principles and is built incrementally. The codebase has:
 
 - **Comprehensive test coverage** – Unit tests for all core functionality
 - **Integration tests** – End-to-end CLI testing
@@ -710,7 +710,7 @@ GOOS=windows GOARCH=amd64 go build -o patience.exe ./cmd/patience
 
 ## Architecture
 
-The project is organized into clean, testable packages:
+The project uses these packages:
 
 - `cmd/patience` – CLI interface with subcommand architecture using Cobra
 - `pkg/executor` – Core patience logic and command execution
@@ -724,7 +724,7 @@ See [Architecture.md](Architecture.md) for a detailed breakdown of the component
 
 ## Contributing
 
-We welcome contributions! The project follows conventional commit messages and maintains high test coverage. Feel free to:
+The project follows conventional commit messages and maintains high test coverage. Contributions are welcome:
 
 - Report bugs or suggest features via [GitHub Issues](https://github.com/shaneisley/patience/issues)
 - Submit pull requests with tests

docs/ADVANCED_CAPABILITIES.md

@@ -2,14 +2,13 @@
 
 ## Overview
 
-The patience tool has evolved from a simple command retry utility into an **intelligent pattern recognition and log analysis system**. The new multi-line pattern capabilities transform how developers and operations teams handle complex, real-world command outputs.
+patience now includes multi-line pattern recognition for log analysis. These capabilities help developers and operations teams handle complex command outputs.
 
 ## Core Capabilities
 
 ### 1. **Intelligent Stack Trace Analysis**
 
-**Before**: Manual log scanning and error interpretation
-**After**: Automated root cause identification with structured extraction
+The strategy automates root cause identification with structured extraction, replacing manual log scanning.
 
 ```yaml
 # Example: Java Application Debugging
@@ -350,4 +349,4 @@ patience --pattern go_panic --ide-format go test ./...
 
 ---
 
-This advanced pattern system transforms patience from a simple retry tool into a **comprehensive log intelligence platform**, enabling developers and operations teams to quickly understand, diagnose, and resolve complex issues across their entire technology stack.
+These pattern capabilities help developers and operations teams understand, diagnose, and resolve issues across their technology stack.