58 lines
3.1 KiB
Markdown
58 lines
3.1 KiB
Markdown
|
# REGLAS Y DIRECTRICES DEL AGENTE
|
||
|
|
|
||
|
|
## 1. REGLA FUNDAMENTAL DE SEGURIDAD Y CONTROL (CRÍTICA)
|
||
|
|
> **NUNCA realizar modificaciones ni en Directus (creación/edición de tablas, campos, usuarios, registros, etc.) ni en la futura aplicación (código, dependencias, estructura) sin la autorización EXPLÍCITA del usuario.**
|
||
|
|
>
|
||
|
|
> El rol del agente ante cualquier cambio es:
|
||
|
|
> 1. Realizar análisis técnicos exhaustivos.
|
||
|
|
> 2. Presentar reportes detallados, planes de mejora o planes de migración/creación paso a paso.
|
||
|
|
> 3. Esperar la aprobación y confirmación explícita del usuario antes de ejecutar cualquier acción que modifique el estado o los datos.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. CONTEXTO DEL PROYECTO
|
||
|
|
- **Nombre oficial del sistema:** Hidalyx Med (antiguo AlfaMedical)
|
||
|
|
- **Backend / API:** Directus (https://api.hidalyx.com/)
|
||
|
|
- **Frontend Web:** Flutter Web
|
||
|
|
- **Fuente de datos original:** SQLite local ubicado en C:\Users\luism\Downloads\alfaMedical\data.sqlite
|
||
|
|
- **Alcance inicial de migración:**
|
||
|
|
- Estructura y datos de 2 tablas: pacientes y configuracion.
|
||
|
|
- Creación del usuario del doctor en directus_users.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. REGLA DE RESPONSIVIDAD NATURAL (WIDGETS FLEXIBLES)
|
||
|
|
> **El diseño responsive debe ser natural y fluido, basado en widgets flexibles y adaptativos nativos de Flutter.**
|
||
|
|
>
|
||
|
|
> - **Prohibición:** NO crear clases utilitarias rígidas de `MediaQuery` ni estructuras con condicionales forzados de breakpoints (`isMobile`, `isTablet`, `isDesktop`).
|
||
|
|
> - **Mandato:** Utilizar widgets que gestionen su espacio de forma intrínseca y fluida:
|
||
|
|
> - `Flexible` y `Expanded`
|
||
|
|
> - `Wrap` (para fluidez y salto de línea automático de elementos y chips)
|
||
|
|
> - `LayoutBuilder` (cuando los constraints directos del padre lo demanden)
|
||
|
|
> - `ConstrainedBox` y `BoxConstraints` (para fijar anchos máximos de lectura o formularios sin desbordes)
|
||
|
|
> - `FittedBox` y `FractionallySizedBox`
|
||
|
|
> - `SingleChildScrollView` y grids adaptativos (`GridView.extent`)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. ESTRUCTURA ESTÁNDAR POR CARACTERÍSTICA (FEATURE)
|
||
|
|
> **Toda característica dentro de `lib/features/` debe organizarse obligatoriamente bajo la siguiente estructura:**
|
||
|
|
> ```text
|
||
|
|
> features/<feature_name>/
|
||
|
|
> ├── data/
|
||
|
|
> │ ├── models/ # Modelos y clases para serializar o deserializar data
|
||
|
|
> │ └── services/ # Clase que engloba los endpoints en métodos listos para consumo
|
||
|
|
> └── presentation/
|
||
|
|
> ├── store/ # Clases del gestor de estado MobX
|
||
|
|
> ├── views/ # Vistas de la característica
|
||
|
|
> └── widgets/ # Widgets de la característica
|
||
|
|
> ```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 5. CONSULTA OBLIGATORIA DEL SISTEMA ANTERIOR (DESKTOP)
|
||
|
|
> **Antes de implementar o modificar cualquier lógica, métrica, condición de negocio, consulta o flujo de trabajo, el agente DEBE consultar y analizar el código fuente del sistema anterior ubicado en `C:\Users\luism\Downloads\alfaMedical\` (especialmente `index.py`, `index2.py` y `data.sqlite`).**
|
||
|
|
> - Se debe verificar exactamente cómo se estructuraban las consultas SQL originales, qué campos y tablas intervenían, y cuáles eran las condiciones y reglas de negocio para replicarlas con fidelidad técnica total.
|
||
|
|
|
||
|
|
|