chore: update documentation for consistency and clarity

- Reformatted multiple documentation files to enhance readability and maintain consistency across the project.
- Adjusted line breaks and spacing in various sections, including project overviews, troubleshooting guides, and API references.
- Improved clarity in the integration testing framework documentation and other related files.

These changes contribute to a more polished and user-friendly documentation experience for contributors and users of the Gold Digger project.

Author: unclesp1d3r

.kiro/specs/documentation-setup/design.md

@@ -2,13 +2,19 @@
 
 ## Overview
 
-This design establishes a comprehensive documentation system for Gold Digger that combines user-focused guides (mdBook) with API documentation (rustdoc) in a unified GitHub Pages site. The system will provide a seamless experience for both end users learning to use the tool and developers contributing to the codebase.
+This design establishes a comprehensive documentation system for Gold Digger that combines
+user-focused guides (mdBook) with API documentation (rustdoc) in a unified GitHub Pages site. The
+system will provide a seamless experience for both end users learning to use the tool and developers
+contributing to the codebase.
 
 The documentation architecture follows a dual-purpose approach:
 
-- **User Documentation**: mdBook-powered guides covering installation, usage, configuration, and troubleshooting
-- **Developer Documentation**: rustdoc-generated API documentation with cross-references to user guides
-- **Unified Deployment**: Single GitHub Pages site serving both documentation types with consistent navigation
+- **User Documentation**: mdBook-powered guides covering installation, usage, configuration, and
+  troubleshooting
+- **Developer Documentation**: rustdoc-generated API documentation with cross-references to user
+  guides
+- **Unified Deployment**: Single GitHub Pages site serving both documentation types with consistent
+  navigation
 
 ## Architecture
 
@@ -60,7 +66,8 @@ The mdBook setup will include seven key plugins:
 
 **Core Plugins (Required):**
 
-1. **mdbook-admonish**: Provides styled callout boxes for notes, warnings, tips, and important information
+1. **mdbook-admonish**: Provides styled callout boxes for notes, warnings, tips, and important
+   information
 2. **mdbook-mermaid**: Enables diagram rendering for architecture and flow diagrams
 3. **mdbook-linkcheck**: Validates all internal and external links during build
 4. **mdbook-toc**: Automatically generates table of contents for long pages
@@ -291,7 +298,8 @@ graph TD
 
 ### Content Types and Templates
 
-1. **Installation Pages**: Step-by-step platform-specific instructions with tabbed content for different platforms
+1. **Installation Pages**: Step-by-step platform-specific instructions with tabbed content for
+   different platforms
 2. **Usage Pages**: Practical examples with input/output samples and admonitions for important notes
 3. **Security Pages**: Warning admonitions with best practices and security checklists
 4. **API Pages**: Cross-references between mdBook and rustdoc with "Edit on GitHub" links
@@ -404,4 +412,5 @@ Add documentation checks to `.pre-commit-config.yaml`:
         pass_filenames: false
 ```
 
-This design provides a comprehensive documentation system that serves both users and developers while integrating seamlessly with Gold Digger's existing development workflow and quality standards.
+This design provides a comprehensive documentation system that serves both users and developers
+while integrating seamlessly with Gold Digger's existing development workflow and quality standards.

.kiro/specs/documentation-setup/requirements.md

@@ -2,101 +2,149 @@
 
 ## Introduction
 
-This feature establishes a comprehensive documentation system for Gold Digger that combines API documentation (rustdoc) with user-focused guides (mdBook) to serve both developers and end users. The documentation will be hosted on GitHub Pages and include interactive features like admonitions, diagrams, link validation, table of contents generation, and internationalization support.
+This feature establishes a comprehensive documentation system for Gold Digger that combines API
+documentation (rustdoc) with user-focused guides (mdBook) to serve both developers and end users.
+The documentation will be hosted on GitHub Pages and include interactive features like admonitions,
+diagrams, link validation, table of contents generation, and internationalization support.
 
 ## Requirements
 
 ### Requirement 1
 
-**User Story:** As a Gold Digger user, I want comprehensive documentation that explains how to use the tool effectively, so that I can quickly understand installation, configuration, and usage patterns without reading source code.
+**User Story:** As a Gold Digger user, I want comprehensive documentation that explains how to use
+the tool effectively, so that I can quickly understand installation, configuration, and usage
+patterns without reading source code.
 
 #### Acceptance Criteria
 
-1. WHEN a user visits the documentation site THEN they SHALL see a clear landing page with navigation to user guides, API documentation, and examples
-2. WHEN a user needs installation instructions THEN they SHALL find step-by-step guides for different platforms (Windows, macOS, Linux)
-3. WHEN a user wants to understand configuration options THEN they SHALL find detailed explanations of CLI flags, environment variables, and their precedence
-4. WHEN a user needs usage examples THEN they SHALL find practical examples for common use cases (CSV export, JSON output, database connections)
-5. WHEN a user encounters errors THEN they SHALL find troubleshooting guides with common issues and solutions
+1. WHEN a user visits the documentation site THEN they SHALL see a clear landing page with
+   navigation to user guides, API documentation, and examples
+2. WHEN a user needs installation instructions THEN they SHALL find step-by-step guides for
+   different platforms (Windows, macOS, Linux)
+3. WHEN a user wants to understand configuration options THEN they SHALL find detailed explanations
+   of CLI flags, environment variables, and their precedence
+4. WHEN a user needs usage examples THEN they SHALL find practical examples for common use cases
+   (CSV export, JSON output, database connections)
+5. WHEN a user encounters errors THEN they SHALL find troubleshooting guides with common issues and
+   solutions
 
 ### Requirement 2
 
-**User Story:** As a developer contributing to Gold Digger, I want integrated API documentation alongside user guides, so that I can understand both the public interface and internal architecture.
+**User Story:** As a developer contributing to Gold Digger, I want integrated API documentation
+alongside user guides, so that I can understand both the public interface and internal architecture.
 
 #### Acceptance Criteria
 
-1. WHEN a developer visits the documentation THEN they SHALL find rustdoc-generated API documentation integrated with the user guides
-2. WHEN a developer needs to understand module structure THEN they SHALL see documented public APIs with examples and cross-references
-3. WHEN a developer wants to contribute THEN they SHALL find development setup guides and coding standards
-4. WHEN a developer needs architecture information THEN they SHALL find design documents explaining core concepts and constraints
+1. WHEN a developer visits the documentation THEN they SHALL find rustdoc-generated API
+   documentation integrated with the user guides
+2. WHEN a developer needs to understand module structure THEN they SHALL see documented public APIs
+   with examples and cross-references
+3. WHEN a developer wants to contribute THEN they SHALL find development setup guides and coding
+   standards
+4. WHEN a developer needs architecture information THEN they SHALL find design documents explaining
+   core concepts and constraints
 
 ### Requirement 3
 
-**User Story:** As a documentation maintainer, I want automated validation and enhanced formatting features, so that I can ensure documentation quality and provide rich content without manual overhead.
+**User Story:** As a documentation maintainer, I want automated validation and enhanced formatting
+features, so that I can ensure documentation quality and provide rich content without manual
+overhead.
 
 #### Acceptance Criteria
 
 1. WHEN documentation is built THEN all internal and external links SHALL be validated automatically
 2. WHEN documentation includes diagrams THEN Mermaid diagrams SHALL render correctly in the output
-3. WHEN documentation needs emphasis THEN admonitions (notes, warnings, tips) SHALL be available and properly styled
-4. WHEN documentation pages are long THEN table of contents SHALL be automatically generated for navigation
-5. WHEN documentation needs internationalization THEN i18n helpers SHALL be available for future translation support
+3. WHEN documentation needs emphasis THEN admonitions (notes, warnings, tips) SHALL be available and
+   properly styled
+4. WHEN documentation pages are long THEN table of contents SHALL be automatically generated for
+   navigation
+5. WHEN documentation needs internationalization THEN i18n helpers SHALL be available for future
+   translation support
 
 ### Requirement 4
 
-**User Story:** As a project maintainer, I want the documentation to be automatically deployed to GitHub Pages, so that users always have access to up-to-date documentation without manual publishing steps.
+**User Story:** As a project maintainer, I want the documentation to be automatically deployed to
+GitHub Pages, so that users always have access to up-to-date documentation without manual publishing
+steps.
 
 #### Acceptance Criteria
 
-1. WHEN code is pushed to the main branch THEN documentation SHALL be automatically built and deployed to GitHub Pages
-2. WHEN rustdoc comments are updated THEN API documentation SHALL be regenerated and included in the deployment
+1. WHEN code is pushed to the main branch THEN documentation SHALL be automatically built and
+   deployed to GitHub Pages
+2. WHEN rustdoc comments are updated THEN API documentation SHALL be regenerated and included in the
+   deployment
 3. WHEN mdBook content is modified THEN user guides SHALL be rebuilt and deployed
-4. WHEN deployment fails THEN the build process SHALL provide clear error messages and fail the CI pipeline
+4. WHEN deployment fails THEN the build process SHALL provide clear error messages and fail the CI
+   pipeline
 5. WHEN users visit the GitHub Pages URL THEN they SHALL see the latest version of the documentation
 
 ### Requirement 5
 
-**User Story:** As a Gold Digger user, I want the documentation to reflect the current version and feature set, so that I can rely on accurate information that matches my installed version.
+**User Story:** As a Gold Digger user, I want the documentation to reflect the current version and
+feature set, so that I can rely on accurate information that matches my installed version.
 
 #### Acceptance Criteria
 
-1. WHEN documentation is generated THEN it SHALL include version information matching the current Cargo.toml version
-2. WHEN features are documented THEN feature flags SHALL be clearly indicated (e.g., "requires ssl feature")
+1. WHEN documentation is generated THEN it SHALL include version information matching the current
+   Cargo.toml version
+2. WHEN features are documented THEN feature flags SHALL be clearly indicated (e.g., "requires ssl
+   feature")
 3. WHEN CLI options are documented THEN they SHALL match the current clap configuration
 4. WHEN examples are provided THEN they SHALL work with the current codebase and be testable
 5. WHEN breaking changes occur THEN migration guides SHALL be provided in the documentation
 
 ### Requirement 6
 
-**User Story:** As a security-conscious user, I want the documentation to clearly explain security considerations and best practices, so that I can use Gold Digger safely in production environments.
+**User Story:** As a security-conscious user, I want the documentation to clearly explain security
+considerations and best practices, so that I can use Gold Digger safely in production environments.
 
 #### Acceptance Criteria
 
-1. WHEN users read about database connections THEN they SHALL find security warnings about credential handling
-2. WHEN users configure TLS/SSL THEN they SHALL find clear guidance on certificate validation and secure connection options
-3. WHEN users handle sensitive data THEN they SHALL find best practices for output file permissions and credential redaction
-4. WHEN users deploy in production THEN they SHALL find security checklists and hardening recommendations
-5. WHEN security vulnerabilities are discovered THEN they SHALL be documented with mitigation strategies
+1. WHEN users read about database connections THEN they SHALL find security warnings about
+   credential handling
+2. WHEN users configure TLS/SSL THEN they SHALL find clear guidance on certificate validation and
+   secure connection options
+3. WHEN users handle sensitive data THEN they SHALL find best practices for output file permissions
+   and credential redaction
+4. WHEN users deploy in production THEN they SHALL find security checklists and hardening
+   recommendations
+5. WHEN security vulnerabilities are discovered THEN they SHALL be documented with mitigation
+   strategies
 
 ### Requirement 7
 
-**User Story:** As a documentation contributor, I want markdown formatting to be consistent and compatible with both mdBook and the existing project standards, so that documentation maintains quality and integrates seamlessly with the build process.
+**User Story:** As a documentation contributor, I want markdown formatting to be consistent and
+compatible with both mdBook and the existing project standards, so that documentation maintains
+quality and integrates seamlessly with the build process.
 
 #### Acceptance Criteria
 
-1. WHEN documentation markdown is written THEN it SHALL be compatible with mdBook rendering requirements
-2. WHEN mdformat is run via justfile or pre-commit THEN it SHALL NOT break mdBook-specific syntax or formatting
-3. WHEN documentation is built THEN markdown formatting SHALL pass existing project linting standards
-4. WHEN contributors write documentation THEN they SHALL be able to use existing formatting tools without conflicts
-5. WHEN mdBook plugins require specific markdown syntax THEN the mdformat configuration SHALL preserve that syntax
+1. WHEN documentation markdown is written THEN it SHALL be compatible with mdBook rendering
+   requirements
+2. WHEN mdformat is run via justfile or pre-commit THEN it SHALL NOT break mdBook-specific syntax or
+   formatting
+3. WHEN documentation is built THEN markdown formatting SHALL pass existing project linting
+   standards
+4. WHEN contributors write documentation THEN they SHALL be able to use existing formatting tools
+   without conflicts
+5. WHEN mdBook plugins require specific markdown syntax THEN the mdformat configuration SHALL
+   preserve that syntax
 
 ### Requirement 8
 
-**User Story:** As a developer working on Gold Digger, I want convenient justfile recipes for documentation tasks, so that I can easily build, serve, and maintain documentation locally without memorizing complex commands.
+**User Story:** As a developer working on Gold Digger, I want convenient justfile recipes for
+documentation tasks, so that I can easily build, serve, and maintain documentation locally without
+memorizing complex commands.
 
 #### Acceptance Criteria
 
-1. WHEN a developer wants to build documentation THEN they SHALL run `just docs-build` to generate both mdBook and rustdoc output
-2. WHEN a developer wants to serve documentation locally THEN they SHALL run `just docs-serve` to start a local development server
-3. WHEN a developer wants to clean documentation artifacts THEN they SHALL run `just docs-clean` to remove generated files
-4. WHEN a developer wants to install documentation dependencies THEN they SHALL run `just docs-install` to set up mdBook and plugins
-5. WHEN a developer wants to validate documentation THEN they SHALL run `just docs-check` to run link checking and formatting validation
+1. WHEN a developer wants to build documentation THEN they SHALL run `just docs-build` to generate
+   both mdBook and rustdoc output
+2. WHEN a developer wants to serve documentation locally THEN they SHALL run `just docs-serve` to
+   start a local development server
+3. WHEN a developer wants to clean documentation artifacts THEN they SHALL run `just docs-clean` to
+   remove generated files
+4. WHEN a developer wants to install documentation dependencies THEN they SHALL run
+   `just docs-install` to set up mdBook and plugins
+5. WHEN a developer wants to validate documentation THEN they SHALL run `just docs-check` to run
+   link checking and formatting validation

.kiro/specs/gold-digger/design.md

@@ -2,11 +2,14 @@
 
 ## Overview
 
-Gold Digger is architected as a single-purpose CLI tool that transforms MySQL/MariaDB query results into structured output formats. The design emphasizes reliability, security, and composability for automation workflows.
+Gold Digger is architected as a single-purpose CLI tool that transforms MySQL/MariaDB query results
+into structured output formats. The design emphasizes reliability, security, and composability for
+automation workflows.
 
 ### Design Principles
 
-- **CLI-first with Environment Fallback**: CLI flags take precedence over environment variables for flexible deployment
+- **CLI-first with Environment Fallback**: CLI flags take precedence over environment variables for
+  flexible deployment
 - **Offline-first**: No external service dependencies at runtime
 - **Fail-fast**: Clear error messages with standardized exit codes (0-5)
 - **Memory-efficient**: Streaming processing for large result sets with O(row_width) memory usage
@@ -976,7 +979,9 @@ fn execute_query_workflow(config: Config) -> Result<()> {
 
 ### Error Handling Flow
 
-The application uses a centralized error handling approach where all errors are mapped to standardized exit codes (Requirements 4.1-4.7). The main function catches all errors and calls `std::process::exit()` with the appropriate code.
+The application uses a centralized error handling approach where all errors are mapped to
+standardized exit codes (Requirements 4.1-4.7). The main function catches all errors and calls
+`std::process::exit()` with the appropriate code.
 
 ## Performance Characteristics