Consider separating functional changes from test coverage PRs

[delano]

Background

During PR review of #32, feedback was received about mixing functional changes with test coverage additions, which increases review complexity and risk.

Current Situation

PR #32 was described as adding test coverage but also included:

• New utility methods (Otto::Utils.yes?)
• Core class refactoring
• Default global configuration changes
• RuboCop configuration overhauls
• Version bumps
• Extensive code formatting changes

Recommendation

For future development, consider separating:

1. Test Coverage PRs - Pure test additions and documentation
2. Functional Change PRs - New features, refactoring, utility additions
3. Configuration PRs - Linting rules, project configuration updates

Benefits

• Easier review process with clearer scope
• Reduced risk from mixing concerns
• Clearer regression analysis when issues arise
• Better git history for understanding changes

Labels

• process-improvement
• documentation

This is a process consideration for future PRs, not a blocker for current work.