Fix documentation accuracy issues and update code examples

.github/workflows/ci.yml

@@ -101,7 +101,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        go-version: ['1.20', '1.21']
+        go-version: ['1.21', '1.22']
     steps:
     - uses: actions/checkout@v4
 

AGENTS.md

@@ -2,14 +2,27 @@
 
 This file provides development guidelines for AI agents working in this repository.
 
+For detailed development guidelines, see [Development-Guidelines.md](Development-Guidelines.md).
+
 ## Build, Lint, and Test
 
-- **Build:** `make build`
-- **Test:** `make test`
+- **Build:** `make build` or `go build -o patience ./cmd/patience`
+- **Test:** `make test` or `go test ./...`
 - **Run a single test:** `go test -v -run ^TestMyFunction$ ./path/to/package`
+- **Test with race detection:** `go test -race ./...`
 - **Lint:** `golangci-lint run --config=.golangci.yml`
 - **Format:** `gofmt -w .` and `goimports -w .` (or run `pre-commit run --all-files`)
 
+## CLI Architecture
+
+The CLI uses a strategy-based subcommand architecture:
+
+```bash
+patience STRATEGY [OPTIONS] -- COMMAND [ARGS...]
+```
+
+Available strategies (with aliases): `http-aware` (`ha`), `exponential` (`exp`), `linear` (`lin`), `fixed` (`fix`), `jitter` (`jit`), `decorrelated-jitter` (`dj`), `fibonacci` (`fib`), `polynomial` (`poly`), `adaptive` (`adapt`), `diophantine` (`dio`).
+
 ## Code Style and Conventions
 
 - **Imports:** Use `goimports` for formatting. No blank or dot imports.
@@ -21,3 +34,16 @@ This file provides development guidelines for AI agents working in this reposito
 - **Constants:** Avoid magic numbers; define them as constants in `pkg/executor/constants.go`.
 - **Concurrency:** Use `sync.Mutex` or `sync.RWMutex` to protect shared resources.
 - **Pre-commit:** This project uses pre-commit hooks. Install with `pre-commit install`.
+
+## Project Structure
+
+- `/cmd/patience` - Main CLI with Cobra subcommand architecture
+- `/cmd/patienced` - Optional metrics daemon
+- `/pkg/backoff` - All backoff strategies (implement `backoff.Strategy` interface)
+- `/pkg/executor` - Core retry logic and command execution
+- `/pkg/config` - Configuration loading and validation
+- `/pkg/conditions` - Pattern matching for success/failure detection
+- `/pkg/metrics` - Metrics collection and daemon communication
+- `/pkg/ui` - Terminal output and status reporting
+- `/pkg/daemon` - Daemon server implementation
+- `/pkg/storage` - In-memory metrics storage

Architecture.md

@@ -96,6 +96,7 @@ We chose subcommands over a flag-based approach for several key reasons:
 - `fibonacci` (`fib`) - Fibonacci sequence delays
 - `polynomial` (`poly`) - Polynomial growth with configurable exponent
 - `adaptive` (`adapt`) - Machine learning adaptive strategy
+- `diophantine` (`dio`) - Mathematical proactive rate limiting
 
 ### **3.2. Execution Flow**
 
@@ -230,11 +231,11 @@ When patienced is not running, the CLI is the sole source of information. It pro
 
 #### **Real-time (Per-Attempt) Output:**
 
-* **Attempt Start:** A clear message indicating which attempt is starting.  
-  * Example: \[retry\] Attempt 1/5 starting...  
-* **Command Output:** The stdout and stderr from the wrapped command are streamed directly to the terminal by default.  
-* **Attempt Failure:** When an attempt fails, retry immediately reports **why** it failed and the **delay** before the next attempt.  
-  * Example (exit code): \[retry\] Attempt 1/5 failed (exit code: 1). Retrying in 2.1s.  
+* **Attempt Start:** A clear message indicating which attempt is starting.
+  * Example: \[retry\] Attempt 1/5 starting...
+* **Command Output:** The stdout and stderr from the wrapped command are streamed directly to the terminal by default.
+* **Attempt Failure:** When an attempt fails, patience immediately reports **why** it failed and the **delay** before the next attempt.
+  * Example (exit code): \[retry\] Attempt 1/5 failed (exit code: 1). Retrying in 2.1s.
   * Example (timeout): \[retry\] Attempt 2/5 failed (timeout: 10s). Retrying in 4.5s.
 
 #### **Final Summary Output:**

CONTRIBUTING.md

@@ -4,7 +4,7 @@ Thank you for your interest in contributing to the Patience project! This docume
 
 ## Code Quality Standards
 
-This project maintains **Grade A+ (95/100)** code quality through automated quality gates that prevent regression of critical improvements made during our TDD development cycles.
+This project maintains high code quality through automated quality gates that prevent regression of critical improvements made during our TDD development cycles.
 
 ### Quality Gates Overview
 
@@ -92,7 +92,7 @@ Our pre-commit hooks automatically check for:
 All pull requests must pass our comprehensive CI/CD pipeline:
 
 - **Linting**: golangci-lint with comprehensive rules
-- **Testing**: Unit tests with race detection on Go 1.20 and 1.21
+- **Testing**: Unit tests with race detection on Go 1.21 and 1.22
 - **Building**: Cross-platform builds (Linux, macOS, Windows)
 - **Security**: Gosec security scanning
 - **Coverage**: Code coverage analysis
@@ -209,7 +209,6 @@ Brief description of changes and motivation.
 
 Our current quality metrics (maintained by automation):
 
-- **Grade**: A+ (95/100)
 - **Function Complexity**: ✅ All functions under 120 lines
 - **Magic Numbers**: ✅ All constants properly extracted
 - **Error Handling**: ✅ Comprehensive error propagation

DAEMON.md

@@ -363,7 +363,8 @@ Monitor daemon performance via:
     ls -la /var/run/patience/daemon.sock
 
     # Fix permissions if needed
-    sudo chmod 666 /var/run/patience/daemon.sock   ```
+    sudo chmod 666 /var/run/patience/daemon.sock
+   ```
 
 2. **Port already in use**:
    ```bash

DOCUMENTATION.md

@@ -80,7 +80,9 @@ The patience project maintains several documentation files:
 - **delay** - The time waited between attempts
 - **timeout** - Maximum time allowed for a single attempt
 
-**Avoid These Terms:**
+**Note:** The CLI output uses a `[retry]` prefix (e.g., `[retry] Attempt 1/5 starting...`). When quoting actual CLI output, preserve this prefix. The terminology guidance below applies to prose in documentation, not to CLI output examples.
+
+**Avoid These Terms in Prose:**
 - "retry tool" (use "patience CLI" or just "patience")
 - "backoff algorithm" (use "backoff strategy")
 - "wait time" (use "delay")
@@ -218,4 +220,4 @@ For questions about documentation maintenance:
 
 ---
 
-*This document is maintained as part of the patience CLI project. Last updated: 2025-07-28*
+*This document is maintained as part of the patience CLI project. Last updated: 2026-02-15*

Development-Guidelines.md

@@ -1,4 +1,4 @@
-# AGENTS.md - Development Guide for patience CLI
+# Development Guidelines for patience CLI
 
 ## Build/Test Commands
 - `go build ./...` - Build all packages

README.md

@@ -143,7 +143,7 @@ patience exp -b 1s -x 2.0 -- curl https://httpbin.org/status/503
 | `http-aware` | `ha` | Respects HTTP `Retry-After` headers | API calls, HTTP requests |
 | `exponential` | `exp` | Exponentially increasing delays | Network operations, external services |
 | `linear` | `lin` | Linearly increasing delays | Rate-limited APIs, predictable timing |
-| `fixed` | `fix` | Fixed delay between patience | Simple patience, testing |
+| `fixed` | `fix` | Fixed delay between attempts | Simple retries, testing |
 | `jitter` | `jit` | Random jitter around exponential | Distributed systems, load balancing |
 | `decorrelated-jitter` | `dj` | AWS-style decorrelated jitter | High-scale distributed systems |
 | `fibonacci` | `fib` | Fibonacci sequence delays | Moderate growth, gradual recovery |
@@ -180,13 +180,13 @@ Use `--success-pattern` to define when a command should be considered successful
 
 ```bash
 # Deployment tools that don't use exit codes properly
-patience --success-pattern "deployment successful" -- kubectl apply -f deployment.yaml
+patience fixed --success-pattern "deployment successful" -- kubectl apply -f deployment.yaml
 
 # API responses that indicate success
-patience --success-pattern "\"status\":\"ok\"" -- curl -s https://httpbin.org/json
+patience exponential --success-pattern "\"status\":\"ok\"" -- curl -s https://httpbin.org/json
 
 # Multiple success indicators (regex OR)
-patience --success-pattern "(success|completed|ready)" -- health-check.sh
+patience fixed --success-pattern "(success|completed|ready)" -- health-check.sh
 ```
 
 ### Failure Patterns
@@ -195,13 +195,13 @@ Use `--failure-pattern` to define when a command should be considered failed, ev
 
 ```bash
 # Catch error messages in output
-patience --failure-pattern "(?i)error|failed|timeout" -- flaky-script.sh
+patience exponential --failure-pattern "(?i)error|failed|timeout" -- flaky-script.sh
 
 # Specific failure conditions
-patience --failure-pattern "connection refused|network unreachable" -- network-test.sh
+patience fixed --failure-pattern "connection refused|network unreachable" -- network-test.sh
 
 # JSON error responses
-patience --failure-pattern "\"error\":" -- api-call.sh
+patience exponential --failure-pattern "\"error\":" -- api-call.sh
 ```
 
 ### Pattern Precedence
@@ -217,7 +217,7 @@ Add `--case-insensitive` to make pattern matching case-insensitive:
 
 ```bash
 # Matches "SUCCESS", "success", "Success", etc.
-patience --success-pattern "success" --case-insensitive -- deployment.sh
+patience fixed --success-pattern "success" --case-insensitive -- deployment.sh
 ```
 
 ### Regex Support
@@ -226,13 +226,13 @@ Both success and failure patterns support full regex syntax:
 
 ```bash
 # Match specific formats
-patience --success-pattern "build #\d+ completed" -- build-script.sh
+patience exponential --success-pattern "build #\d+ completed" -- build-script.sh
 
 # Word boundaries
-patience --failure-pattern "\berror\b" -- log-parser.sh
+patience fixed --failure-pattern "\berror\b" -- log-parser.sh
 
 # Capture groups and alternatives
-patience --success-pattern "(deployed|updated) successfully" -- deploy.sh
+patience exponential --success-pattern "(deployed|updated) successfully" -- deploy.sh
 ```
 
 ## Strategy Details

cmd/patience/subcommands.go

@@ -1120,7 +1120,7 @@ func createDiophantineCommand() *cobra.Command {
 
 	cmd := &cobra.Command{
 		Use:     "diophantine [OPTIONS] -- COMMAND [ARGS...]",
-		Aliases: []string{"dioph"},
+		Aliases: []string{"dioph", "dio"},
 		Short:   "Proactive rate limit compliance using Diophantine inequalities",
 		Long: `Diophantine strategy prevents rate limit violations before they occur by using
 mathematical modeling to ensure optimal throughput within rate limit constraints.

docs/project/current-state_gemini.md

@@ -38,7 +38,7 @@ This codebase implements a sophisticated command-line tool for demonstrating pat
 
 ### Potential Areas for Improvement:
 
-*   **Adaptive Strategy Integration**: The `Adaptive` backoff strategy has a `RecordOutcome` method to learn from patience attempts, but it is not currently called by the `Executor`. This means the adaptive learning functionality is not being used.
+*   **Adaptive Strategy Integration**: ~~The `Adaptive` backoff strategy has a `RecordOutcome` method to learn from patience attempts, but it is not currently called by the `Executor`.~~ **Resolved:** The `Executor` now calls `RecordOutcome` via interface type assertion in `recordStrategyOutcome()` (see `pkg/executor/executor.go`). The adaptive learning functionality is active.
 *   **Configuration Validation**: The list of valid backoff types in `config.Validate` is incomplete and does not include `adaptive` or `polynomial`.
 *   **Daemon Stability**: The daemon's `handleConnections` method could be made more robust by using a fixed-size worker pool to prevent resource exhaustion from a large number of concurrent connections.
 *   **Testing**: While not reviewed, the presence of numerous test files suggests a good testing culture. However, the effectiveness of these tests is crucial, especially for complex features like the adaptive strategy and the daemon.
@@ -47,7 +47,9 @@ This codebase implements a sophisticated command-line tool for demonstrating pat
 
 This is a high-quality, well-engineered project that goes beyond a simple patience tool. It demonstrates a strong understanding of software engineering principles, with a focus on modularity, extensibility, and advanced features. The inclusion of a metrics daemon and adaptive backoff strategies sets it apart from typical patience libraries.
 
-With a few minor improvements, particularly in integrating the adaptive learning mechanism and expanding configuration validation, this tool could be a production-ready solution for robust command execution and patience.
+With a few minor improvements, particularly in expanding configuration validation, this tool could be a production-ready solution for robust command execution and patience.
+
+*Note: This assessment was originally written during an earlier development phase. Some items marked for improvement (e.g., Adaptive Strategy Integration) have since been resolved.*
 
 ---
 

docs/reports/FINAL_EVALUATION_REPORT.md

@@ -18,7 +18,7 @@ The patience CLI has successfully completed a comprehensive 6-phase performance
 - **Startup Time:** 4ms average (Target: <100ms) - **25x better than target**
 - **Memory Usage:** <15MB (Target: <50MB) - **3x better than target**
 - **Command Overhead:** ~5x (Target: <10x) - **2x better than target**
-- **All 6 backoff strategies** perform within 5% of each other
+- **All 6 original backoff strategies** perform within 5% of each other (4 additional strategies added after this evaluation)
 - **Configuration loading:** <8ms for all complexity levels
 
 ### ✅ **Phase 2: Stress Testing & Scalability - SUCCESSFUL**
@@ -160,7 +160,7 @@ The patience CLI has successfully completed a comprehensive 6-phase performance
 
 ### **Competitive Positioning:**
 - **Superior performance** vs existing retry tools
-- **Comprehensive feature set** with 6 backoff strategies
+- **Comprehensive feature set** with 10 backoff strategies
 - **Production-ready reliability** with excellent error handling
 - **Modern toolchain integration** (CI/CD, containers, shell scripts)
 - **Optimized resource utilization** suitable for all environments