docs(project): add community health files

- Add community health files: CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md.

Author: Emin-ACIKGOZ

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,39 @@
+# Code of Conduct
+
+## Purpose
+
+This project aims to provide a respectful, professional, and productive environment for collaboration. All participants are expected to act in good faith and treat others with courtesy and respect.
+
+## Expected Behavior
+
+Participants are expected to:
+- Communicate clearly, respectfully, and professionally
+- Be constructive in discussions, reviews, and feedback
+- Focus on technical merit and project goals
+- Assume good intent in others’ actions and words
+- Accept feedback and correction gracefully
+
+## Unacceptable Behavior
+
+The following behaviors are not tolerated:
+- Harassment, discrimination, or hostility of any kind
+- Personal attacks, insults, or derogatory comments
+- Trolling, deliberate disruption, or bad-faith argumentation
+- Publishing private information without consent
+- Persistent unconstructive or disrespectful behavior
+
+## Scope
+
+This Code of Conduct applies to all project spaces, including issues, pull requests, code reviews, discussions, and any other project-related communication.
+
+## Enforcement
+
+Project maintainers are responsible for enforcing this Code of Conduct. Actions taken in response to violations may include warnings, content removal, temporary restrictions, or permanent bans, depending on severity.
+
+## Reporting
+
+If you experience or witness behavior that violates this Code of Conduct, report it privately to the project maintainer.
+
+## Attribution
+
+This Code of Conduct is inspired by established open-source community standards.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,28 @@
+---
+name: Bug report
+about: Report a reproducible bug
+labels: bug
+---
+
+## Description
+Clear and concise description of the bug.
+
+## Reproduction
+Steps to reproduce the behavior:
+1.
+2.
+3.
+
+## Expected behavior
+What you expected to happen.
+
+## Actual behavior
+What actually happened.
+
+## Environment
+- Go version:
+- OS/Arch:
+- Library version or commit:
+
+## Additional context
+Logs, stack traces, or screenshots if applicable.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an enhancement or new feature
+labels: enhancement
+---
+
+## Summary
+Concise description of the proposed feature.
+
+## Motivation
+Why this feature is needed and what problem it solves.
+
+## Proposed solution
+High-level description of the desired behavior or API.
+
+## Alternatives considered
+Other approaches or workarounds, if any.
+
+## Additional context
+Relevant examples, references, or prior art.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,43 @@
+# Pull Request
+
+## Summary
+
+Briefly describe what this change does and why it is needed.
+
+## Type of Change
+
+- [ ] Bug fix
+- [ ] Performance improvement
+- [ ] Documentation update
+- [ ] Test improvement
+- [ ] New feature (backward compatible)
+- [ ] Breaking change
+
+## Details
+
+Explain the change at a technical level if not obvious from the diff.
+Include relevant context, constraints, or trade-offs.
+
+## Tests
+
+- [ ] Existing tests pass (`go test ./...`)
+- [ ] New tests added or existing tests updated (if applicable)
+
+Describe how this change is tested or why tests are not required.
+
+## API Impact
+
+- [ ] No public API changes
+- [ ] Backward-compatible API change
+- [ ] Breaking API change (justified and documented)
+
+## Checklist
+
+- [ ] Code follows project standards and idiomatic Go
+- [ ] `golangci-lint` passes
+- [ ] Public APIs are documented where applicable
+- [ ] Commit history is focused (one logical change per commit)
+
+## Related Issues
+
+Link any relevant issues or discussions.

.github/SECURITY.md

@@ -0,0 +1,34 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+If you discover a security vulnerability, do **not** open a public issue or pull request.
+
+Instead, report it **privately** by contacting the project maintainer with:
+- A clear description of the issue
+- Steps to reproduce, if applicable
+- Potential impact and affected versions
+
+You may use encrypted communication if preferred.
+
+## Scope
+
+This policy applies to:
+- Public APIs and exported behavior
+- Validation logic, safety guarantees, and concurrency controls
+- Middleware, adapters, and reflection helpers
+
+Issues caused by misuse outside documented guarantees are generally out of scope.
+
+## Disclosure Process
+
+Reported vulnerabilities will be reviewed and triaged as soon as possible.  
+If confirmed, a fix will be developed and released. Public disclosure may occur after a fix is available.
+
+## Supported Versions
+
+Only the latest released version is supported with security updates unless stated otherwise.
+
+## Responsible Disclosure
+
+Please allow reasonable time for investigation and remediation before public disclosure.

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# Contributing
+
+Hello! Thank you for showing interest in my project.
+
+This document defines the standard contribution rules used across my Go projects. Individual repositories may add project-specific requirements.
+
+
+## Scope
+
+Contributions may include bug fixes, performance improvements, documentation updates, tests, or API extensions consistent with existing design. Significant or breaking changes should be discussed in an issue first.
+
+
+## Code Standards
+
+- Go version must match `go.mod`
+- Code must be formatted with `gofmt`
+- `go vet` must pass
+- `golangci-lint` must pass using the repository’s `.golangci.yml`
+- Public APIs must have clear, idiomatic Go doc comments
+- Avoid new dependencies unless strictly necessary
+- Keep changes minimal and focused
+
+
+## Tests
+
+- All changes must include appropriate tests
+- Existing tests must pass:
+  ```sh
+  go test ./...
+  ```
+
+- New behavior should include edge-case and failure-path coverage
+
+
+## Commits
+
+- Each commit must do exactly one logical thing
+- Do not mix refactors, formatting, and behavior changes in a single commit
+- Commit messages should be clear and imperative
+
+
+## Pull Requests
+
+- Clearly describe the problem and the change
+- Reference relevant issues if applicable
+- Ensure the branch is up to date with `main`
+- Do not include generated files unless required
+
+
+## API Stability
+
+- Public APIs should remain backward compatible when possible
+- Breaking changes require clear justification and documentation
+- `internal/` packages are not considered stable
+
+
+## License
+
+- By contributing, you agree that your contributions are licensed under the same license as the project.
+
+```
+Copyright 2025 Emin Salih Açıkgöz
+
+SPDX-License-Identifier: MIT
+```