clinical_laboratory/GEMINI.md

Instrucciones para el uso de tea CLI

Este proyecto utiliza tea para interactuar con el repositorio de Gitea.

Crear un Issue (Modo no Interactivo)

Para crear un nuevo issue de forma no interactiva, se utiliza el siguiente comando, proporcionando todos los datos necesarios mediante flags:

tea issue create --title "Título del Issue" --description "Descripción detallada del issue." --labels "etiqueta1,etiqueta2"

• --title: Especifica el título del issue.
• --description: Especifica la descripción o cuerpo del issue.
• --labels: Especifica una o más etiquetas separadas por comas.

---

Comentar en un Issue

Para agregar un comentario a un issue existente, se utiliza el comando comment seguido del número del issue y el texto del comentario entre comillas.

Formato correcto:

tea comment <NÚMERO_ISSUE> "Tu comentario aquí"

Ejemplo:

tea comment 3 "Comentario de prueba"

Nota: No se deben utilizar flags como -i o --message. El formato es directo.

---

Realizar Commits

Debido a problemas de interpretación de comillas en el shell de ejecución, el uso de git commit -m "mensaje" puede fallar. Para evitar estos problemas, se debe pasar el mensaje del commit a través de la entrada estándar (stdin).

Política de Mensajes de Commit

Es mandatorio que el título de cada commit referencie el número del issue que resuelve. Esto se hace para mantener una trazabilidad clara entre el código y las tareas.

Formato del Título:

<tipo>(#<issue_id>): <descripción breve>

• <tipo>: feat (nueva funcionalidad), fix (corrección de bug), docs (cambios en documentación), style (formato), refactor, test, chore (otras tareas).
• (<issue_id>): El número del issue entre paréntesis y precedido de #.

Ejemplo:

feat(#4): Agregar campos de género y fecha de nacimiento al paciente

Método Recomendado

Utiliza el comando echo y una tubería (|) para enviar el mensaje a git commit -F -.

Commit de una sola línea:

echo "feat(#4): Tu mensaje de commit conciso" | git commit -F -

Commit multilínea: Para mensajes de commit multilínea, la forma más segura es usar printf que maneja mejor los saltos de línea ( ):

printf "feat(#4): Título del commit

Cuerpo del mensaje con descripción detallada." | git commit -F -

Esto asegura que el formato del mensaje del commit se preserve correctamente.

---

Crear un Pull Request

Para crear un pull request (PR), se utiliza el comando tea pulls create. Debes especificar la rama base (hacia donde van los cambios) y la rama head (tu rama actual), junto con un título que referencie el issue que resuelve.

Formato del comando:

tea pulls create --base "<rama_base>" --head "<tu_rama>" --title "<Tipo>(#issue): Título descriptivo"

Ejemplo:

tea pulls create --base "dev" --head "feature/3-core-setup" --title "feat(#3): Actualiza instrucciones en GEMINI.md"

• --base: La rama de destino (ej. dev, main).
• --head: Tu rama de trabajo actual.
• --title: Un título claro que incluya el tipo de cambio (feat, fix, docs) y el número de issue.

---

Contexto del Proyecto

Al iniciar cada sesión de trabajo, es mandatorio leer los siguientes documentos para comprender el contexto completo de los requerimientos y el diseño técnico:

• documents/requirements/RequerimientoInicial.md
• documents/requirements/ToBeDesing.md

Levantamiento de la Instancia de Odoo 18

Para levantar la instancia efímera de Odoo 18 junto con la base de datos de PostgreSQL, se utiliza Docker Compose.

Comando de inicio:

docker-compose up -d

Este comando levantará los servicios definidos en el archivo docker-compose.yml en modo "detached" (-d).

Comando de detención y limpieza: Para detener los servicios y asegurar un estado limpio, siempre se deben eliminar los volúmenes, a menos que se indique lo contrario.

docker-compose down -v

Verificación de la Inicialización

Después de levantar la instancia, es mandatorio verificar los registros del contenedor de inicialización para confirmar que los módulos se instalaron o actualizaron correctamente.

Comando para ver los logs:

docker-compose logs odoo_init

Busca errores en la salida. Si encuentras alguno, debes presentar un resumen del problema y sus posibles causas, como:

• Dependencias faltantes: Un módulo no se puede instalar porque requiere otro que no está presente.
• Errores de sintaxis: Problemas en archivos Python (.py) o XML (.views, .xml).
• Permisos incorrectos: Problemas de acceso a archivos o directorios.
• Datos incorrectos: Errores en los archivos de datos de demostración o iniciales.

---

Convenciones de Desarrollo en Odoo 18

Para evitar errores recurrentes, es mandatorio seguir las siguientes convenciones específicas para Odoo 18, especialmente en lo que respecta a la definición de vistas.

Uso de Vistas de Lista (Tree Views)

En Odoo 18, la etiqueta <tree> ha sido reemplazada por <list>. El uso de <tree> provocará un error de validación (ValueError: Wrong value for ir.ui.view.type: 'tree').

Forma Incorrecta (Odoo < 18):

<record id="view_example_tree" model="ir.ui.view">
    <field name="arch" type="xml">
        <tree string="Ejemplo">
            <field name="name"/>
        </tree>
    </field>
</record>

Forma Correcta (Odoo 18):

<record id="view_example_list" model="ir.ui.view">
    <field name="arch" type="xml">
        <list string="Ejemplo">
            <field name="name"/>
        </list>
    </field>
</record>

Definición de Acciones de Ventana (view_mode)

Consecuente con el cambio anterior, al definir una acción de ventana (ir.actions.act_window) que deba mostrar una vista de lista, el view_mode debe ser 'list,form' en lugar de 'tree,form'.

Forma Incorrecta:

<record id="action_example" model="ir.actions.act_window">
    <field name="name">Ejemplo</field>
    <field name="res_model">example.model</field>
    <field name="view_mode">tree,form</field>
</record>

Forma Correcta:

<record id="action_example" model="ir.actions.act_window">
    <field name="name">Ejemplo</field>
    <field name="res_model">example.model</field>
    <field name="view_mode">list,form</field>
</record>

### Atributos de Visibilidad (`attrs`)

A partir de Odoo 17, el atributo `attrs` para controlar la visibilidad de los elementos ha sido **reemplazado por el uso directo de `invisible`**.

**Forma Incorrecta (Odoo < 17):**
```xml
<field name="special_field" attrs="{'invisible': [('is_special', '=', False)]}"/>

Forma Correcta (Odoo 18): Se utiliza el atributo invisible con una expresión de dominio simplificada. La expresión se evalúa como verdadera para ocultar el campo.

<field name="special_field" invisible="not is_special"/>

O, de forma equivalente:

<field name="special_field" invisible="is_special == False"/>