fegger
bf8191b013
planung.md: Architektur (schlanker RAG-Service, SQLite-Index, Hybrid-Retrieval), verbindliche Grounding-Regeln, Modell-Bake-off M3 (qwen3.8:27b, qwen3:32b, gemma3:27b, mistral-small3.2:24b, qwen3:14b als Latenz-Untergrenze), Meilensteine M1-M4 und Odoo-Integrationsoptionen. .agents: neuer Skill pv-rag-agent (verbindliche Regeln für die Implementierung) sowie bestehende Projekt-Skills (agent-memory, wissensbasis, odoo19-development, opendataloader-pdf).
131 lines
3.1 KiB
Markdown
131 lines
3.1 KiB
Markdown
---
|
|
name: odoo19-development
|
|
description: |
|
|
Guidance for developing and maintaining Odoo 19 Enterprise modules.
|
|
disable-model-invocation: false
|
|
---
|
|
|
|
## Required source material
|
|
|
|
Before implementation, consult:
|
|
|
|
- Odoo 19 source available in the repository/environment;
|
|
- Odoo 19 development coding guidelines;
|
|
- Odoo 19 Git guidelines;
|
|
- existing implementations of the functionality being changed.
|
|
|
|
Do not rely solely on knowledge from other Odoo versions.
|
|
|
|
## Framework-first development
|
|
|
|
Odoo already provides extensive infrastructure. Before writing custom code,
|
|
search for an existing implementation.
|
|
|
|
Look for:
|
|
|
|
- existing models;
|
|
- inherited models;
|
|
- mixins;
|
|
- computed fields;
|
|
- constraints;
|
|
- ORM helpers;
|
|
- views;
|
|
- actions;
|
|
- security mechanisms;
|
|
- `account.report` infrastructure;
|
|
- existing localization patterns;
|
|
- standard accounting functionality.
|
|
|
|
Extend or compose existing functionality whenever practical.
|
|
|
|
Avoid:
|
|
|
|
- monkey patching;
|
|
- duplicating standard Odoo functionality;
|
|
- unnecessary overrides;
|
|
- custom infrastructure where an Odoo mechanism exists;
|
|
- version-specific APIs copied from older Odoo releases.
|
|
|
|
## API verification
|
|
|
|
Every referenced API must be verified.
|
|
|
|
Before using a model, field, method, XML ID, module, package, or framework API:
|
|
|
|
1. search the current Odoo 19 source;
|
|
2. verify the exact name and signature/behavior;
|
|
3. inspect callers or existing implementations where useful;
|
|
4. only then use it.
|
|
|
|
Never invent plausible Odoo APIs or Python dependencies.
|
|
|
|
## Repository exploration
|
|
|
|
Use search strategically.
|
|
|
|
For an unfamiliar feature:
|
|
|
|
1. find the relevant model;
|
|
2. find existing implementations;
|
|
3. inspect inheritance;
|
|
4. inspect views/actions/security;
|
|
5. inspect tests;
|
|
6. identify the smallest appropriate extension point.
|
|
|
|
Do not start implementation immediately after finding the first apparently
|
|
relevant file.
|
|
|
|
## Odoo conventions
|
|
|
|
Follow the project's Odoo 19 coding guidelines.
|
|
|
|
Prefer:
|
|
|
|
- ORM operations;
|
|
- declarative fields and constraints;
|
|
- proper model inheritance;
|
|
- standard security mechanisms;
|
|
- standard views and actions;
|
|
- existing framework abstractions.
|
|
|
|
Avoid unnecessary SQL, low-level manipulation, and custom abstractions.
|
|
|
|
## Odoo 19 references
|
|
|
|
The following pinned Odoo 19 documentation is included with this skill:
|
|
|
|
- `references/coding_guidelines.rst`
|
|
- `references/git_guidelines.rst`
|
|
|
|
These documents are authoritative for Odoo coding and Git conventions in this
|
|
repository.
|
|
|
|
When a conflict exists between general knowledge and these references, follow
|
|
the pinned Odoo 19 references.
|
|
|
|
## Testing
|
|
|
|
Every functional change should have appropriate tests.
|
|
|
|
Tests should verify behavior rather than implementation details.
|
|
|
|
For accounting functionality, include relevant:
|
|
|
|
- company behavior;
|
|
- currency behavior;
|
|
- dates/fiscal periods;
|
|
- posted vs draft records;
|
|
- reconciliation;
|
|
- access rights;
|
|
- accounting edge cases.
|
|
|
|
## Maintainability
|
|
|
|
Optimize for long-term Odoo upgradeability.
|
|
|
|
Prefer small, idiomatic extensions over large replacements of standard behavior.
|
|
|
|
Avoid unrelated refactoring.
|
|
|
|
If standard functionality is intentionally not reused, document why.
|