mirror of
https://github.com/azaion/detections.git
synced 2026-04-22 08:46:32 +00:00
Oleksandr Bezdieniezhnykh
ad5530b9ef
- Updated `.cursor/rules/coderule.mdc` to include new guidelines on maintaining test environments and avoiding hardcoded workarounds. - Revised state file rules in `.cursor/skills/autopilot/state.md` to ensure comprehensive updates after every meaningful state transition. - Improved existing-code workflow in `.cursor/skills/autopilot/flows/existing-code.md` to automate task re-entry without user confirmation. - Added requirements for test coverage in the implementation process within `.cursor/skills/implement/SKILL.md`, ensuring all acceptance criteria are validated by tests. - Enhanced new-task skill documentation to include test coverage gap analysis, ensuring all new requirements are covered by tests. These changes aim to strengthen project maintainability, improve testing practices, and streamline workflows.
32 lines
3.2 KiB
Plaintext
32 lines
3.2 KiB
Plaintext
---
|
|
description: "Enforces concise, comment-free, environment-aware coding standards with strict scope discipline and test verification"
|
|
alwaysApply: true
|
|
---
|
|
# Coding preferences
|
|
- Always prefer simple solution
|
|
- Generate concise code
|
|
- Do not put comments in the code, except in tests: every test must use the Arrange / Act / Assert pattern with language-appropriate comment syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS). Omit any section that is not needed (e.g. if there is no setup, skip Arrange; if act and assert are the same line, keep only Assert)
|
|
- Do not put logs unless it is an exception, or was asked specifically
|
|
- Do not put code annotations unless it was asked specifically
|
|
- Write code that takes into account the different environments: development, production
|
|
- You are careful to make changes that are requested or you are confident the changes are well understood and related to the change being requested
|
|
- Mocking data is needed only for tests, never mock data for dev or prod env
|
|
- Make test environment (files, db and so on) as close as possible to the production environment
|
|
- When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
|
|
- When a test fails due to a missing dependency, install it — do not fake or stub the module system. For normal packages, add them to the project's dependency file (requirements-test.txt, package.json devDependencies, test csproj, etc.) and install. Only consider stubbing if the dependency is heavy (e.g. hardware-specific SDK, large native toolchain) — and even then, ask the user first before choosing to stub.
|
|
- Do not solve environment or infrastructure problems (dependency resolution, import paths, service discovery, connection config) by hardcoding workarounds in source code. Fix them at the environment/configuration level.
|
|
- Before writing new infrastructure or workaround code, check how the existing codebase already handles the same concern. Follow established project patterns.
|
|
- If a file, class, or function has no remaining usages — delete it. Do not keep dead code "just in case"; git history preserves everything. Dead code rots: its dependencies drift, it misleads readers, and it breaks when the code it depends on evolves.
|
|
|
|
- Focus on the areas of code relevant to the task
|
|
- Do not touch code that is unrelated to the task
|
|
- Always think about what other methods and areas of code might be affected by the code changes
|
|
- When you think you are done with changes, run the full test suite. Every failure — including pre-existing ones, collection errors, and import errors — is a **blocking gate**. Never silently ignore, skip, or proceed past a failing test. On any failure, stop and ask the user to choose one of:
|
|
- **Investigate and fix** the failing test or source code
|
|
- **Remove the test** if it is obsolete or no longer relevant
|
|
- Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
|
|
|
|
- Make sure we don't commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task
|
|
- Never force-push to main or dev branches
|
|
- Place all source code under the `src/` directory; keep project-level config, tests, and tooling at the repo root
|