Contribution Guide

1. Ways to contribute

• Report a reproducible bug or request a feature in GitHub Issues.
• Improve documentation, clarify in-app descriptions, or add troubleshooting steps.
• Submit a focused code fix, accessibility improvement, or performance enhancement.
• Propose a new tweak only when its behavior, supported Windows versions, side effects, and reversal approach are understood.

2. Development setup

CoreX is an Electron desktop app using React. The repository specifies pnpm as its package manager. Install a supported Node.js runtime, Git, and pnpm for your environment, then:

git clone https://github.com/Noveriks/CoreX.git
cd CoreX
pnpm install
pnpm start

To produce a Windows installer, use pnpm build on a suitable Windows build environment. Check the README and package.json for the current commands. Do not commit generated installers, local credentials, signing certificates, tokens, or unrelated build output.

3. Recommended workflow

1. Search existing issues and pull requests first. If the change is substantial, open an issue to discuss the approach before investing in a large patch.
2. Fork the repository, create a short descriptive branch, and keep the change focused.
3. Make the smallest complete change that addresses the issue. Follow the neighboring code and documentation style.
4. Run the app with pnpm start and verify the behavior you changed. If you add or modify tests, run the relevant checks available in the repository. The current package scripts should be treated as authoritative for available commands.
5. Review your diff for secrets, unrelated generated files, unsafe defaults, and claims not supported by the code.
6. Open a pull request describing the problem, solution, manual or automated checks, Windows version, and any known limitations. Link the related issue.

4. Submitting Windows tweaks

Before proposing a system tweak, document:

• The Windows versions and editions where you tested it, and whether administrator approval is required.
• The exact setting changed and the user-facing purpose in clear, neutral language.
• Side effects, dependencies, restarts or sign-outs needed, and potential compatibility issues.
• How to reverse it and what state the reversal restores. Do not claim the change is universally reversible if it cannot restore the user's original value.
• How you tested applying and reverting it, including the expected before/after state.

Use the tweak catalog's existing structure and metadata conventions. Review existing examples before adding new files. Never describe a tweak as “safe,” “private,” or “performance improving” without clearly qualifying the claim and supporting it with evidence.

5. Pull request checklist

• Explain what changes and why; include screenshots for meaningful UI changes.
• List tests or manual checks actually performed. Do not report checks you did not run.
• Describe any impact on Windows settings, permissions, network requests, user data, or existing preferences.
• Update directly related documentation and release notes if the project workflow requires them.
• Keep the pull request focused and respond constructively to review feedback.

6. Reporting security issues

Do not publish exploit details or sensitive user data in a public issue. Use any private security contact or reporting route specified by the repository. If none is listed, contact the maintainers privately at help.mahinulislam@gmail.com with a concise description and safe reproduction information.

7. License and conduct

CoreX is licensed under the MIT License. Contributions are submitted under the repository's applicable licensing terms; review the repository license before contributing. Be respectful, specific, and constructive in issues and pull requests. Do not include personal data, secrets, or code you do not have the right to contribute.

Open an issue or pull request at github.com/Noveriks/CoreX.