{"owner":"major","repo":"MySQLTuner-perl","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["GEMINI.md","RULES.md"],"skills":{"GEMINI.md":"For project-specific context, please refer to:\n- [RULES.md](file:///RULES.md): Core constitution, execution rules, and best practices.\n- [MEMORY_DB.md](file:///MEMORY_DB.md): Project evolution, version history, and systemic findings.\n- [TESTS.md](file:///TESTS.md): Comprehensive guide on unit and laboratory testing.\n\n---\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.","RULES.md":"# MySQLTuner-perl Project Rules\n\n## Core Constitution\nMake `mysqltuner.pl` the most stable, portable, and reliable performance tuning advisor for MySQL, MariaDB, and Percona Server.\n\n### Key Pillars\n- **Production Stability**: Every recommendation must be safe for production environments.\n- **Single-File Architecture**: Strict enforcement of a single-file structure. Modules or splitting are prohibited.\n- **Zero-Dependency Portability**: The script must remain self-contained and executable on any server with a base Perl installation (Core modules only).\n- **Universal Compatibility**: Support the widest possible range of MySQL-compatible versions (Legacy 5.5 to Modern 11.x).\n- **Regression Limit**: Proactively identify and prevent regressions through exhaustive automated testing.\n\n## Execution Rules & Constraints\n1. **SINGLE FILE**: Spliting `mysqltuner.pl` into modules is **strictly prohibited**.\n2. **NON-REGRESSION**: Deleting existing code is **prohibited** without relocation or commenting out.\n3. **TDD MANDATORY**: Use a TDD approach. Validate solutions by creating test cases before final submission.\n4. **SAFE COMMANDS**: Always use absolute paths. Monitor every command for `exit code 0`.\n5. **CREDENTIAL HYGIENE**: NEVER hardcode credentials.\n6. **VERSION CONSISTENCY**: Version numbers MUST be synchronized across `CURRENT_VERSION.txt`, `Changelog`, and all occurrences within `mysqltuner.pl`.\n7. **CONVENTIONAL COMMITS**: All commit messages MUST follow the [Conventional Commits](https://www.conventionalcommits.org/) specification.\n8. **NO DIRECT COMMIT**: All changes SHOULD be committed via `npm run commit` or `git cz`.\n\n## Best Practices\n1. **Multi-Version Validation**: Test diagnostic logic changes against at least one \"Legacy\" version (e.g. MySQL 8.0) and one \"Modern\" version (e.g. MariaDB 11.4).\n2. **System Call Resilience**: Every external command MUST check for binary existence and handle non-zero exit codes. Use `execute_system_command`.\n3. **\"Zero-Dependency\" CPAN Policy**: Use ONLY Perl \"Core\" modules.\n4. **Audit Trail**: Every recommendation MUST be documented in code with a comment pointing to official documentation.\n5. **Memory-Efficient Parsing**: Process logs line-by-line; NEVER load large files into memory.\n6. **SQL Modeling**: Use the `Modeling` array to collect schema design findings (naming, constraints, data types).\n"},"files":{"GEMINI.md":"For project-specific context, please refer to:\n- [RULES.md](file:///RULES.md): Core constitution, execution rules, and best practices.\n- [MEMORY_DB.md](file:///MEMORY_DB.md): Project evolution, version history, and systemic findings.\n- [TESTS.md](file:///TESTS.md): Comprehensive guide on unit and laboratory testing.\n\n---\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.","RULES.md":"# MySQLTuner-perl Project Rules\n\n## Core Constitution\nMake `mysqltuner.pl` the most stable, portable, and reliable performance tuning advisor for MySQL, MariaDB, and Percona Server.\n\n### Key Pillars\n- **Production Stability**: Every recommendation must be safe for production environments.\n- **Single-File Architecture**: Strict enforcement of a single-file structure. Modules or splitting are prohibited.\n- **Zero-Dependency Portability**: The script must remain self-contained and executable on any server with a base Perl installation (Core modules only).\n- **Universal Compatibility**: Support the widest possible range of MySQL-compatible versions (Legacy 5.5 to Modern 11.x).\n- **Regression Limit**: Proactively identify and prevent regressions through exhaustive automated testing.\n\n## Execution Rules & Constraints\n1. **SINGLE FILE**: Spliting `mysqltuner.pl` into modules is **strictly prohibited**.\n2. **NON-REGRESSION**: Deleting existing code is **prohibited** without relocation or commenting out.\n3. **TDD MANDATORY**: Use a TDD approach. Validate solutions by creating test cases before final submission.\n4. **SAFE COMMANDS**: Always use absolute paths. Monitor every command for `exit code 0`.\n5. **CREDENTIAL HYGIENE**: NEVER hardcode credentials.\n6. **VERSION CONSISTENCY**: Version numbers MUST be synchronized across `CURRENT_VERSION.txt`, `Changelog`, and all occurrences within `mysqltuner.pl`.\n7. **CONVENTIONAL COMMITS**: All commit messages MUST follow the [Conventional Commits](https://www.conventionalcommits.org/) specification.\n8. **NO DIRECT COMMIT**: All changes SHOULD be committed via `npm run commit` or `git cz`.\n\n## Best Practices\n1. **Multi-Version Validation**: Test diagnostic logic changes against at least one \"Legacy\" version (e.g. MySQL 8.0) and one \"Modern\" version (e.g. MariaDB 11.4).\n2. **System Call Resilience**: Every external command MUST check for binary existence and handle non-zero exit codes. Use `execute_system_command`.\n3. **\"Zero-Dependency\" CPAN Policy**: Use ONLY Perl \"Core\" modules.\n4. **Audit Trail**: Every recommendation MUST be documented in code with a comment pointing to official documentation.\n5. **Memory-Efficient Parsing**: Process logs line-by-line; NEVER load large files into memory.\n6. **SQL Modeling**: Use the `Modeling` array to collect schema design findings (naming, constraints, data types).\n"},"items":[{"name":"GEMINI.md","path":"GEMINI.md","title":"GEMINI.md","content":"For project-specific context, please refer to:\n- [RULES.md](file:///RULES.md): Core constitution, execution rules, and best practices.\n- [MEMORY_DB.md](file:///MEMORY_DB.md): Project evolution, version history, and systemic findings.\n- [TESTS.md](file:///TESTS.md): Comprehensive guide on unit and laboratory testing.\n\n---\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.","category":"root","tokens":664},{"name":"RULES.md","path":"RULES.md","title":"RULES.md","content":"# MySQLTuner-perl Project Rules\n\n## Core Constitution\nMake `mysqltuner.pl` the most stable, portable, and reliable performance tuning advisor for MySQL, MariaDB, and Percona Server.\n\n### Key Pillars\n- **Production Stability**: Every recommendation must be safe for production environments.\n- **Single-File Architecture**: Strict enforcement of a single-file structure. Modules or splitting are prohibited.\n- **Zero-Dependency Portability**: The script must remain self-contained and executable on any server with a base Perl installation (Core modules only).\n- **Universal Compatibility**: Support the widest possible range of MySQL-compatible versions (Legacy 5.5 to Modern 11.x).\n- **Regression Limit**: Proactively identify and prevent regressions through exhaustive automated testing.\n\n## Execution Rules & Constraints\n1. **SINGLE FILE**: Spliting `mysqltuner.pl` into modules is **strictly prohibited**.\n2. **NON-REGRESSION**: Deleting existing code is **prohibited** without relocation or commenting out.\n3. **TDD MANDATORY**: Use a TDD approach. Validate solutions by creating test cases before final submission.\n4. **SAFE COMMANDS**: Always use absolute paths. Monitor every command for `exit code 0`.\n5. **CREDENTIAL HYGIENE**: NEVER hardcode credentials.\n6. **VERSION CONSISTENCY**: Version numbers MUST be synchronized across `CURRENT_VERSION.txt`, `Changelog`, and all occurrences within `mysqltuner.pl`.\n7. **CONVENTIONAL COMMITS**: All commit messages MUST follow the [Conventional Commits](https://www.conventionalcommits.org/) specification.\n8. **NO DIRECT COMMIT**: All changes SHOULD be committed via `npm run commit` or `git cz`.\n\n## Best Practices\n1. **Multi-Version Validation**: Test diagnostic logic changes against at least one \"Legacy\" version (e.g. MySQL 8.0) and one \"Modern\" version (e.g. MariaDB 11.4).\n2. **System Call Resilience**: Every external command MUST check for binary existence and handle non-zero exit codes. Use `execute_system_command`.\n3. **\"Zero-Dependency\" CPAN Policy**: Use ONLY Perl \"Core\" modules.\n4. **Audit Trail**: Every recommendation MUST be documented in code with a comment pointing to official documentation.\n5. **Memory-Efficient Parsing**: Process logs line-by-line; NEVER load large files into memory.\n6. **SQL Modeling**: Use the `Modeling` array to collect schema design findings (naming, constraints, data types).\n","category":"root","tokens":595}]}