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:

```bash
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:**

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

**Ejemplo:**

```bash
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:**

```bash
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 (`
`):

```bash
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:**

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

**Ejemplo:**

```bash
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:**
```bash
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.
```bash
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:**
```bash
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):**
```xml
<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):**
```xml
<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:**
```xml
<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:**
```xml
<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.
```xml
<field name="special_field" invisible="not is_special"/>
```
O, de forma equivalente:
```xml
<field name="special_field" invisible="is_special == False"/>
```
```