feat(agent): instructions

Author: Mte90

copilot-instructions.md

@@ -0,0 +1,68 @@
+# Instructions
+
+Purpose
+- Help contributors and code-assistants make focused, minimal, and correct changes to the codebase.
+- When producing code, follow the repository's structure and conventions and keep changes small and localized.
+
+General guidance
+- Always write and explain code in English.
+- When adding comments in code, limit them to describing implementation details and intent. Do not use comments to introduce new features or design changes.
+- Avoid implementing security checks or validations unless the maintainer explicitly requests them.
+- Do not create or modify test files; tests and migrations are not to be generated.
+- All changes that interact with persistent data (database reads/writes/migrations) must be implemented inside the repository's existing database modules or clearly designated DB files (e.g., app/db.py, app/database/, or equivalent). Do not embed DB operations in handlers, controllers, or utility files unless that is the project's established pattern.
+
+Python-specific guidance
+- Follow PEP 8 formatting and idiomatic Python practices (use typing where helpful), ignore linting tools from py.
+- Keep functions and modules small and focused.
+- Prefer composing behavior via modules and functions already present in the repo rather than adding new top-level packages or modules unless necessary.
+- Use existing configuration and dependency-loading patterns in the project; do not introduce new secrets or env-loading systems.
+
+Kotlin-specific guidance
+- Keep Kotlin code consistent with the project's conventions (naming, packaging).
+- Make small, well-scoped changes and prefer reusing existing utilities.
+
+HTML / Frontend guidance
+- Keep templates minimal and descriptive. Use existing CSS/JS conventions in the repo.
+- Do not extend the frontend with new major frameworks or build systems.
+
+Database operations
+- Identify and use the project's designated DB layer for all database operations.
+- If a suitable DB module exists, add or modify functions there; do not perform raw DB access in business logic or route handlers.
+- Keep DB schema changes and migration logic separate and documented — but do not create migrations unless explicitly requested.
+
+External services and network calls
+- The repo delegates embedding and coding/chat model calls to an external service while keeping local data. When adding or modifying code that calls external services:
+  - Keep calls isolated in a single module or client class.
+  - Avoid spreading network logic across modules.
+  - Do not add retries, rate-limiting, or security wrappers unless asked.
+
+Documentation and comments
+- Add inline comments only to explain non-obvious implementation details.
+- Do not use comments to discuss potential features, speculative refactors, or TODOs that introduce new scope.
+- When editing README or docs, keep content factual and limited to how the code currently behaves.
+
+Commits and pull requests
+- Keep commits focused and small. Each commit should have a clear purpose and message.
+- In PR descriptions: explain what changed, where database or external calls were modified (if any), and any required manual steps (e.g., config keys).
+- Do not include speculative or optional enhancements in the same PR as a bugfix.
+
+When asked to refactor
+- Ignore breaking changes unless the maintainer explicitly requests to document.
+- Refactor in small steps with clear explanation comments that describe the transformation.
+- Move DB logic to the DB module if you find it mixed into other layers.
+
+When asked to document code
+- Provide concise explanations and annotate tricky parts with comments.
+- Do not invent missing features or implementation details; document only what the code does.
+
+When interacting with the maintainer's requests
+- If the maintainer specifically requests security checks, tests, or DB migrations, follow their exact instructions.
+- If something is ambiguous about where DB code should go, ask for the exact file or module name before proceeding.
+
+Example minimal checklist before submitting a change
+- Changes are localized and small.
+- No tests added or modified.
+- No security checks added unless requested.
+- All DB operations are inside the repository's DB layer.
+- Comments describe code behavior only and are written in English.
+- PR description clearly states the change and files touched.