mirror of
http://100.103.83.12:3003/fegger/odoo-at-payroll.git
synced 2026-09-17 16:56:42 +00:00
Planung und Skills für den Wissensbasis-RAG-Agenten
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).
This commit is contained in:
@@ -0,0 +1,130 @@
|
||||
---
|
||||
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.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,145 @@
|
||||
==============
|
||||
Git guidelines
|
||||
==============
|
||||
|
||||
Configure your git
|
||||
------------------
|
||||
|
||||
Based on ancestral experience and oral tradition, the following things go a long
|
||||
way towards making your commits more helpful:
|
||||
|
||||
- Be sure to define both the user.email and user.name in your local git config
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
git config --global <var> <value>
|
||||
|
||||
- Be sure to add your full name to your Github profile here. Please feel fancy
|
||||
and add your team, avatar, your favorite quote, and whatnot ;-)
|
||||
|
||||
Commit message structure
|
||||
------------------------
|
||||
|
||||
Commit message has four parts: tag, module, short description and full
|
||||
description. Try to follow the preferred structure for your commit messages
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
[TAG] module: describe your change in a short sentence (ideally < 50 chars)
|
||||
|
||||
Long version of the change description, including the rationale for the change,
|
||||
or a summary of the feature being introduced.
|
||||
|
||||
Please spend a lot more time describing WHY the change is being done rather
|
||||
than WHAT is being changed. This is usually easy to grasp by actually reading
|
||||
the diff. WHAT should be explained only if there are technical choices
|
||||
or decision involved. In that case explain WHY this decision was taken.
|
||||
|
||||
End the message with references, such as task or bug numbers, PR numbers, and
|
||||
OPW tickets, following the suggested format:
|
||||
task-123 (related to task)
|
||||
Fixes #123 (close related issue on Github)
|
||||
Closes #123 (close related PR on Github)
|
||||
opw-123 (related to ticket)
|
||||
|
||||
Tag and module name
|
||||
-------------------
|
||||
|
||||
Tags are used to prefix your commit. They should be one of the following
|
||||
|
||||
- **[FIX]** for bug fixes: mostly used in stable version but also valid if you
|
||||
are fixing a recent bug in development version;
|
||||
- **[REF]** for refactoring: when a feature is heavily rewritten;
|
||||
- **[ADD]** for adding new modules;
|
||||
- **[REM]** for removing resources: removing dead code, removing views,
|
||||
removing modules, ...;
|
||||
- **[REV]** for reverting commits: if a commit causes issues or is not wanted
|
||||
reverting it is done using this tag;
|
||||
- **[MOV]** for moving files: use git move and do not change content of moved file
|
||||
otherwise Git may loose track and history of the file; also used when moving
|
||||
code from one file to another;
|
||||
- **[REL]** for release commits: new major or minor stable versions;
|
||||
- **[IMP]** for improvements: most of the changes done in development version
|
||||
are incremental improvements not related to another tag;
|
||||
- **[MERGE]** for merge commits: used in forward port of bug fixes but also as
|
||||
main commit for feature involving several separated commits;
|
||||
- **[CLA]** for signing the Odoo Individual Contributor License;
|
||||
- **[I18N]** for changes in translation files;
|
||||
- **[PERF]** for performance patches;
|
||||
- **[CLN]** for code cleanup;
|
||||
- **[LINT]** for linting passes;
|
||||
|
||||
After tag comes the modified module name. Use the technical name as functional
|
||||
name may change with time. If several modules are modified, list them or use
|
||||
various to tell it is cross-modules. Unless really required or easier avoid
|
||||
modifying code across several modules in the same commit. Understanding module
|
||||
history may become difficult.
|
||||
|
||||
Commit message header
|
||||
---------------------
|
||||
|
||||
After tag and module name comes a meaningful commit message header. It should be
|
||||
self explanatory and include the reason behind the change. Do not use single words
|
||||
like "bugfix" or "improvements". Try to limit the header length to about 50 characters
|
||||
for readability.
|
||||
|
||||
Commit message header should make a valid sentence once concatenated with
|
||||
``if applied, this commit will <header>``. For example ``[IMP] base: prevent to
|
||||
archive users linked to active partners`` is correct as it makes a valid sentence
|
||||
``if applied, this commit will prevent users to archive...``.
|
||||
|
||||
Commit message full description
|
||||
-------------------------------
|
||||
|
||||
In the message description specify the part of the code impacted by your changes
|
||||
(module name, lib, transversal object, ...) and a description of the changes.
|
||||
|
||||
First explain WHY you are modifying code. What is important if someone goes back
|
||||
to your commit in about 4 decades (or 3 days) is why you did it. It is the
|
||||
purpose of the change.
|
||||
|
||||
What you did can be found in the commit itself. If there was some technical choices
|
||||
involved it is a good idea to explain it also in the commit message after the why.
|
||||
For Odoo R&D developers "PO team asked me to do it" is not a valid why, by the way.
|
||||
|
||||
Please avoid commits which simultaneously impact multiple modules. Try to split
|
||||
into different commits where impacted modules are different. It will be helpful
|
||||
if we need to revert changes in a given module separately.
|
||||
|
||||
Don't hesitate to be a bit verbose. Most people will only see your commit message
|
||||
and judge everything you did in your life just based on those few sentences.
|
||||
No pressure at all.
|
||||
|
||||
**You spend several hours, days or weeks working on meaningful features. Take
|
||||
some time to calm down and write clear and understandable commit messages.**
|
||||
|
||||
If you are an Odoo R&D developer the WHY should be the purpose of the task you
|
||||
are working on. Full specifications make the core of the commit message.
|
||||
**If you are working on a task that lacks purpose and specifications please
|
||||
consider making them clear before continuing.**
|
||||
|
||||
Finally here are some examples of correct commit messages :
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
[REF] models: use `parent_path` to implement parent_store
|
||||
|
||||
This replaces the former modified preorder tree traversal (MPTT) with the
|
||||
fields `parent_left`/`parent_right`[...]
|
||||
|
||||
[FIX] account: remove frenglish
|
||||
|
||||
[...]
|
||||
|
||||
Closes #22793
|
||||
Fixes #22769
|
||||
|
||||
[FIX] website: remove unused alert div, fixes look of input-group-btn
|
||||
|
||||
Bootstrap's CSS depends on the input-group-btn
|
||||
element being the first/last child of its parent.
|
||||
This was not the case because of the invisible
|
||||
and useless alert.
|
||||
|
||||
.. note:: Use the long description to explain the *why* not the
|
||||
*what*, the *what* can be seen in the diff
|
||||
Reference in New Issue
Block a user