Skip to content

About

Sistema de gestión de inventarios para pequeñas empresas, con trazabilidad de movimientos en tiempo real.

Resources

Readme
Activity
Custom properties

Stars

3 stars

Watchers

0 watching

Forks

0 forks
Report repository
BranchesTags

Repository files navigation

InvenTrack — Sistema Inteligente de Inventarios

Curso: Arquitectura de Software (AS_202620) · Universidad Tecnológica de Bolívar
Repositorio: AS_202620_InvenTrack · Organización ISCOUTB

🚀 Estado del Proyecto — Segundo Corte (AS_202620)

  • Estilo Arquitectónico: Monolito Modular con Arquitectura Hexagonal por Módulo (ADR-0001).
  • Mecanismo de Concurrencia: Exclusión mutua asíncrona por SKU (asyncio.Lock()) (ADR-0002).
  • Medición de Concurrencia: La prueba ejecuta 20 salidas reales sobre el mismo SKU, calcula el p95 y exige el umbral de $\le 400\text{ ms}$ (Experimento reproducible).
  • Matriz de Trazabilidad: Cadena navegable Aspecto → Requisito → C4 → ADR → Código → Pruebas → Evidencia (Aspectos de Calidad).
  • Contrato de API: OpenAPI v1 versionado y validado automáticamente contra la implementación FastAPI (ADR-0004).
  • Mensajería asíncrona: Las entradas y salidas publican el evento MovimientoDeInventarioRegistrado para auditoría en segundo plano, con trazabilidad, deduplicación, reintentos, backoff exponencial y DLQ en memoria (ADR-0013, ADR-0016).
  • Despliegue Productivo: Configurado para Render (PaaS) y Dokploy mediante infraestructura como código (render.yaml y deploy/compose.lab.yaml); el redespliegue y funcionamiento público del commit actual requieren verificación externa.
  • CI y cobertura: GitHub Actions ejecuta la suite completa con pytest-cov, genera coverage.xml, ejecuta el análisis SonarCloud y valida explícitamente el contrato OpenAPI.
  • Transparencia en Uso de IA: Prompts, decisiones aceptadas, correcciones y rechazos por criterio técnico (Registro de IA).

🌐 Entorno de Producción (Render)

  • URL Pública: https://inventrack-api.onrender.com
  • Health Check: https://inventrack-api.onrender.com/health
  • Métricas y Swagger: restringidos en producción; requieren el token interno configurado por plataforma.

🌐 Entorno Institucional (iscoutb.dev)

  • URL Pública: https://inventrack.iscoutb.dev
  • Health Check: https://inventrack.iscoutb.dev/health
  • Métricas y Swagger: restringidos en producción; requieren el token interno configurado por plataforma.
  • Estado documentado: configuración preparada con datos de negocio deshabilitados hasta completar autenticación/autorización, mediante deploy/compose.lab.yaml; no se afirma que el commit actual haya sido redesplegado.

Tabla de contenidos

Navegación rápida

Documento Contenido
Ficha del problema Problema, solución propuesta, alcance del MVP y usuarios objetivo
Aspecto de calidad declarado Consistencia de datos: descripción, diagnóstico, escenarios y trazabilidad
Documentación arc42 Objetivos, stakeholders, restricciones, contexto, estrategia, vistas conceptos y calidad
C4 — Nivel 1 (Contexto) Diagrama de contexto: actores, sistema y sistema externo
C4 — Nivel 2 (Contenedores) Diagrama de contenedores, evolución post-reto y aislamiento en memoria
C4 — Nivel 3 (Componentes) Componentes reales del API Backend y dependencias entre módulos
Mapa de contextos Límites de dominio y relaciones tipificadas entre contextos
Propiedad de datos Dueño único por entidad, lectores y canales de consulta
Auditoría de modularidad Análisis de acoplamientos y corrección de violaciones entre módulos
Contrato de API Contrato HTTP versionado del MVP, errores, concurrencia y endpoints
Árbol de utilidad Priorización de atributos de calidad por impacto y riesgo
ADR-0001 Registro de decisión: Monolito modular con hexagonal por módulo (Aceptado)
ADR-0002 Control de concurrencia en memoria, criterios de revisión y costo de reversión (Aceptado)
ADR-0003 Integración entre productos e inventario mediante puertos de aplicación y adaptadores (Aceptado)
ADR-0004 Contrato de API versionado con OpenAPI y validación automática (Aceptado)
ADR-0005 Elección de Render PaaS, estimación de costos y punto de ruptura (Aceptado)
ADR-0006 Dokploy institucional como segundo destino operativo (Aceptado)
ADR-0007 Exposición del p95 de latencia en métricas HTTP (Aceptado)
ADR-0008 No incorporar un componente generativo al MVP (Aceptado)
ADR-0010 No extraer inventario a un microservicio en el MVP (Aceptado)
ADR-0011 Idempotencia de movimientos y no uso de Saga en el MVP (Aceptado)
ADR-0012 Mantener repositorios en memoria en el MVP y ruta de evolución de persistencia (Aceptado)
ADR-0013 Mensajería asíncrona para auditoría de movimientos y comparación con invocación síncrona (Aceptado)
ADR-0014 Almacenamiento in-memory, movimientos inmutables y costo de reversión (Aceptado)
ADR-0015 Completar decisión de almacenamiento, consecuencias y costo de reversión (Aceptado)
ADR-0016 Integrar eventos de auditoría en movimientos de inventario (Aceptado)
ADR-0017 Idempotencia HTTP en comandos de inventario (Aceptado)
Evidencia S12 de CI y despliegue Run público, Quality Gate y estado verificable de los despliegues
Evidencia de prueba contractual Reproducción del fallo ante un cambio incompatible y recuperación de la prueba
Despliegue y costos URL pública, IaC (render.yaml), observabilidad, secretos y estimación mensual
Medición Reto Corte 1 Diagnóstico, pruebas de concurrencia, degradación controlada y comando de reproducción
Reporte Experimento Corte 2 Hipótesis, montaje, variables y resultados del experimento de concurrencia de inventario (S10)
Uso de IA Registro transparente de IA (sugerencias aceptadas vs. rechazadas)

Descripción

Sistema de gestión de inventarios dirigido a pequeñas y medianas empresas que hoy gestionan su stock mediante Excel o registros manuales. Centraliza productos, proveedores, entradas, salidas, usuarios y movimientos, con alertas automáticas de stock bajo.

Resuelve problemas concretos de las PYMEs objetivo: descuadres de stock, quiebres no detectados a tiempo, compras mal planificadas por falta de datos históricos, ausencia de trazabilidad, y dependencia de una sola persona como punto único de fallo operativo. Ver el planteamiento completo en docs/ficha_problema.md.

Equipo de desarrollo

Integrante Rol en el proyecto
Esteban Peluffo Equipo de desarrollo
Felix Taborda Equipo de desarrollo
Jose Vargas Equipo de desarrollo
Javier Carta Equipo de desarrollo

Aspecto de calidad declarado

Consistencia de datos — el sistema debe garantizar que movimientos de inventario registrados por distintos usuarios de forma simultánea no generen datos inconsistentes (stock negativo, doble descuento del mismo movimiento). Un inventario con cifras incorrectas es peor que uno manual, porque genera falsa confianza en la toma de decisiones.

Ver detalle, justificación, escenarios de calidad y matriz de trazabilidad del Reto en docs/aspectos.md.

Cómo está organizado este repositorio

Antes de entrar a cada carpeta, vale la pena explicar la lógica detrás de la estructura:

  • docs/arc42/ cuenta la historia completa en texto: objetivos, restricciones, contexto, estrategia de solución, vista de bloques, vista de ejecución, atributos de calidad, conceptos transversales y los escenarios que los hacen medibles.
  • docs/c4/ y docs/utility-tree.md son los diagramas — representaciones visuales que se enlazan desde el arc42.
  • docs/adr/ registra las decisiones arquitectónicas concretas, una por archivo: estilo general, concurrencia, integración entre módulos, contrato versionado, despliegue, observabilidad y exclusión de componentes generativos.
  • docs/api/ reúne el contrato técnico y la vista funcional de la API de InvenTrack, incluyendo el contrato ejecutable de la versión actual.
  • docs/retos/ documenta el diagnóstico, carga simulada, comandos de reproducción y resultados del reto del Corte 1.
  • docs/evidencia-prueba-contrato.md documenta la reproducción controlada de un cambio incompatible en OpenAPI y la recuperación de la prueba contractual.
  • docs/evidencia-mensajeria-s12.md contiene el comando y el mapa de evidencia del taller de mensajería: contrato, duplicados, reintentos, DLQ, flujo real y trazabilidad.
  • docs/aspectos.md es el índice que conecta todo siguiendo la cadena navegable: Aspecto → Requisito → C4 → ADR → Código → Pruebas → Evidencia.
  • docs/auditoria-modularidad.md documenta la revisión de acoplamiento y las correcciones aplicadas para mantener los límites del monolito modular.
  • contracts/openapi/v1.json contiene el contrato HTTP versionado y tests/contract/ valida que la implementación lo cumpla.
  • contracts/events/movimiento_registrado_v1.json contiene el contrato JSON Schema del evento de inventario y tests/messaging/test_contrato_evento.py valida su estructura.

Mensajería asíncrona y auditoría

El sistema usa un modelo híbrido conforme al ADR-0013:

  1. El registro de stock y movimiento permanece síncrono y protegido por el lock por SKU.
  2. Después de una entrada o salida exitosa, el router crea un evento MovimientoDeInventarioRegistrado.
  3. La publicación y el consumidor de auditoría se ejecutan como tarea posterior mediante BackgroundTasks, sin bloquear la respuesta principal.
  4. El evento lleva event_id, correlation_id, idempotency_key, timestamp y el payload de inventario.

Los clientes pueden enviar X-Correlation-ID para correlación extremo a extremo y X-Idempotency-Key para conservar la clave del comando de origen. Si esta última no se envía, el productor usa event_id como clave única del evento.

La implementación se encuentra en app/inventario/infrastructure/router.py, app/messaging/broker_simulador.py y app/main.py.

Garantías y límites

Propiedad Implementación
Entrega At-Least-Once durante la vida del proceso
Duplicados Deduplicación por idempotency_key
Fallos recuperables Hasta 3 intentos por defecto con backoff exponencial
Fallos persistentes Envío a Dead Letter Queue (DLQ)
Trazabilidad event_id, correlation_id, audit_log y log inventory_message_consumed
Métricas /metrics expone mensajes publicados, procesados, duplicados, reintentos y enviados a DLQ cuando se accede localmente o con token interno en producción
Durabilidad No garantizada: broker y DLQ son volátiles en el MVP

El contrato y sus reglas de compatibilidad están en contracts/events/movimiento_registrado_v1.json y en ADR-0016. Agregar campos opcionales sin cambiar la semántica es compatible; cambiar campos obligatorios, tipos, valores permitidos o semántica exige una nueva versión del evento.

La evidencia reproducible está en docs/evidencia-mensajeria-s12.md.

Documentación de arquitectura

La documentación sigue la plantilla arc42, disponible completa en docs/arc42/arc42-template-EN.md. Incluye:

Sección arc42 Contenido
1 · Introduction and Goals Objetivos del sistema, atributos de calidad priorizados y stakeholders
2 · Architecture Constraints Restricciones técnicas, legales y organizativas
3 · Context and Scope Contexto de negocio y contexto técnico
4 · Solution Strategy Decisiones clave (Monolito Modular, Hexagonal por módulo, desacoplamiento)
5 · Building Block View Descomposición en subsistemas y módulos internos (Productos, Inventario, Proveedores, etc.)
6 · Runtime View Diagramas de secuencia para flujos críticos (ej. Registro concurrente de movimientos)
7 · Deployment View Despliegues operativos en Dokploy y Render mediante Docker
8 · Cross-cutting Concepts Lenguaje ubicuo, mapa de contextos, mecanismo de exclusión mutua asíncrona por SKU y manejo unificado de excepciones
9 · Architecture Decisions Enlace y matriz de trazabilidad con los ADRs
10 · Quality Requirements Árbol de utilidad y 5 escenarios de calidad medibles
12 · Glossary Glosario de términos de dominio técnico y de negocio

Matriz comparativa de estilos

La comparación entre arquitectura por capas, hexagonal y monolito modular está en docs/matriz-comparativa-estilos.md. La decisión adoptada combina un Monolito Modular como estructura general con Hexagonal por módulo.

Diagramas C4

  • Nivel 1 — Contexto: actores del sistema, InvenTrack, y el servicio de notificaciones.
  • Nivel 2 — Contenedores: desglose de contenedores ejecutables (Frontend Web/Móvil, API Backend FastAPI, Base de Datos y Servicio de Notificaciones).
  • Nivel 3 — Componentes: componentes implementados de productos e inventario dentro del API Backend.
  • Mapa de contextos: relaciones cliente-proveedor, capa anticorrupción y propiedad de datos.
  • Árbol de utilidad: priorización de los escenarios de calidad por impacto de negocio y riesgo técnico.

Todos los diagramas están escritos en Mermaid y se renderizan directamente en GitHub.

Mapa de contextos y propiedad de datos

El sistema separa los contextos productos e inventario. Cada uno es dueño de sus entidades y las integraciones cruzadas se realizan mediante puertos de aplicación y adaptadores. Los contextos usuarios, proveedores y alertas están definidos como extensiones futuras y todavía no tienen implementación. La matriz detallada está en docs/propiedad-datos.md.

Decisiones de arquitectura (ADR)

Las decisiones arquitectónicas se documentan como archivos individuales en docs/adr/:

  • ADR-0001: Selección de Monolito Modular con Hexagonal por módulo para la estructura base.
  • ADR-0002: Adopción de exclusión mutua asíncrona (asyncio.Lock()) por SKU para resolver el reto de consistencia ante peticiones simultáneas de inventario.
  • ADR-0003: Integración entre productos e inventario mediante puertos de aplicación y adaptadores.
  • ADR-0004: Versionado del contrato de API con OpenAPI y validación automática de compatibilidad en CI.
  • ADR-0005: Elección de Render (PaaS) como plataforma de despliegue productivo y estimación de costos.
  • ADR-0006: Incorporación posterior de Dokploy como segundo destino operativo, en paralelo con Render.
  • ADR-0007: Exposición del p95 de latencia en métricas HTTP.
  • ADR-0008: Decisión de no incorporar un componente generativo al MVP.
  • ADR-0010: Decisión de no extraer inventario a un microservicio independiente en el MVP.
  • ADR-0011: Tratamiento de idempotencia y Saga para los movimientos de inventario.
  • ADR-0012: Mantener los repositorios en memoria durante el MVP y conservar los puertos para una futura persistencia durable.
  • ADR-0014: Precisar la inmutabilidad de movimientos y cuantificar el costo de migrar el almacenamiento a una base durable.
  • ADR-0015: Completar la trazabilidad, consecuencias y comparación de costos sin editar ADR-0014, que permanece inmutable.

Despliegue en iscoutb.dev

El proyecto está desplegado en el servidor institucional Dokploy descrito en iscoutb.dev. La definición reproducible está en deploy/compose.lab.yaml. Este MVP publica únicamente la API y no necesita una base de datos externa ni variables secretas. Los datos viven en repositorios en memoria y se pierden al reiniciar o redeplegar el proceso; este límite y la ruta de migración están documentados en ADR-0012. Dokploy se incorporó después del cierre de la semana 8 y se mantiene en paralelo con el despliegue existente en Render.

Publicación

  1. Haz push de deploy/compose.lab.yaml y Dockerfile a la rama main.
  2. Entra a panel.iscoutb.dev, abre el proyecto inventrack, entorno production, servicio sistema y confirma el proveedor GitHub, el repositorio, la rama main y ./deploy/compose.lab.yaml como Compose Path.
  3. En Domains, agrega inventrack.iscoutb.dev para el servicio api, ruta /, HTTPS activado y puerto del contenedor 10000.
  4. Pulsa Deploy. Con el autodespliegue activo, los siguientes pushes a main reconstruyen el servicio automáticamente.

La API queda disponible en https://inventrack.iscoutb.dev. /health permanece público; /docs, /redoc, /openapi.json y /metrics requieren el token interno y devuelven 404 sin él. Las rutas de negocio devuelven 503 de forma preventiva mientras INVENTRACK_ALLOW_BUSINESS_DATA=false; esto no representa una caída del servicio ni reemplaza autenticación y autorización de usuarios. El Compose no publica puertos directamente: Dokploy enruta el dominio al puerto expuesto por el contenedor. No se deben añadir ports:, container_name, montajes bind ni secretos al repositorio. La comprobación fechada y el hash de la respuesta están en evidencia-seguridad-s13.md.

Stack tecnológico

Capa Tecnología Estado
Frontend Flutter (Dart / Material 3 / Provider) Implementado para el contrato OpenAPI v1 en frontend/ (windows/)
Backend FastAPI + Uvicorn Implementado
Persistencia Adaptadores In-Memory; PostgreSQL compartido es la evolución preferida Implementado para MVP; persistencia durable pendiente de ADR sucesor
Mensajería Simulador asíncrono local Integrado para auditoría; broker durable u Outbox persistente pendiente
Hosting / despliegue Render + Dokploy + Docker Configurado en https://inventrack-api.onrender.com y https://inventrack.iscoutb.dev; el commit actual requiere verificación pública posterior al redespliegue
CI / calidad de código GitHub Actions + Pytest + pytest-asyncio + pytest-cov Suite síncrona y asíncrona con cobertura XML (coverage.xml), validación del contrato OpenAPI y análisis SonarCloud configurado

Estructura del repositorio

.github/
└── workflows/
    ├── test.yml                 # Pruebas, contrato y build de la imagen
    └── deploy.yml               # Despliegue de la imagen
Dockerfile                       # Imagen reproducible de producción (no-root user)
render.yaml                      # Configuración IaC de despliegue para Render
deploy/
└── compose.lab.yaml             # Compose para el servidor Dokploy institucional
docs/
├── arc42/
│   ├── arc42-template-EN.md     # Narrativa completa arc42
│   └── images/
│       └── arc42-logo.png
├── c4/
│   ├── context.md               # C4 Nivel 1 — Diagrama de contexto
│   ├── containers.md            # C4 Nivel 2 — Diagrama de contenedores
│   └── components.md            # C4 Nivel 3 — Componentes reales del backend
├── api/
│   └── inventrack-contrato.md   # Contrato funcional y técnico de la API actual
├── context-map.md               # Mapa de contextos y relaciones tipificadas
├── propiedad-datos.md           # Dueño único y canales de consulta
├── auditoria-modularidad.md     # Revisión de desacoplamiento y plan de corrección
├── adr/
│   ├── 0001–0016                  # Decisiones arquitectónicas versionadas
│   ├── 0013-evaluacion-mensajeria-asincrona-vs-sincrona.md
│   └── 0016-integrar-eventos-de-auditoria-en-movimientos.md
├── evidencia-prueba-contrato.md  # Reproducción del fallo de compatibilidad OpenAPI
├── evidencia-mensajeria-s12.md   # Evidencia reproducible del taller de mensajería
├── retos/
│   └── corte-1-medicion.md      # Diagnóstico y medición del Reto de Concurrencia
├── ficha_problema.md            # Planteamiento del problema
├── aspectos.md                  # Matriz de trazabilidad navegable de 8 columnas
├── matriz-comparativa-estilos.md # Comparativa de estilos arquitectónicos
├── utility-tree.md              # Árbol de utilidad
├── ia.md                        # Registro de uso de IA en el proyecto
└── auditoria-modularidad.md     # Documento de revisión modular y corrección de violaciones
contracts/
├── openapi/v1.json              # Contrato versionado de la API HTTP
└── events/
    └── movimiento_registrado_v1.json # Contrato JSON Schema del evento
app/                             # Aplicación FastAPI Monolito Modular
├── main.py                      # Composición, métricas p95 y rutas principales
├── shared/                      # Dominio compartido y utilidades
├── productos/                   # Módulo de productos
├── inventario/                  # Módulo de inventario (Concurrencia por SKU)
├── proveedores/                 # Módulo de proveedores
├── usuarios/                    # Módulo de usuarios
└── alertas/                     # Módulo de alertas
frontend/                        # Cliente Flutter (Material 3 + Provider)
├── README.md                    # Guía de ejecución, pruebas y límites del cliente
├── pubspec.yaml                 # Dependencias Flutter (http, provider, google_fonts, intl)
├── lib/
│   ├── main.dart                # Punto de entrada y MultiProvider
│   ├── config/                  # Configuración de URL base y timeout
│   ├── models/                  # Modelos alineados con OpenAPI v1
│   ├── services/                # Cliente HTTP REST y mapeo de excepciones
│   ├── providers/               # Gestión de estado (salud, productos, inventario)
│   ├── screens/                 # Pantallas Home, Productos e Inventario
│   └── widgets/                 # Diálogos y tarjetas de stock/movimientos
├── test/                        # Pruebas unitarias y de widgets con MockClient
├── android/                     # Runner nativo Android
├── ios/                         # Runner nativo iOS
└── windows/                     # Runner nativo Windows conservado
tests/                           # Batería de pruebas automatizadas
├── test_health.py
├── productos/
├── inventario/
│   └── test_concurrencia.py     # Pruebas de simulación concurrente
├── contract/
│   └── test_openapi_contract.py  # Compatibilidad del contrato OpenAPI
└── messaging/
    ├── test_taller_mensajeria.py # Duplicados, reintentos, backoff y DLQ
    └── test_contrato_evento.py   # Validación del contrato del evento
requirements.in                  # Dependencias directas del proyecto
requirements.txt                 # Lock con versiones, hashes y dependencias transitivas

Cómo ejecutar el esqueleto

Requisito: Python 3.11 o superior.

python -m pip install --require-hashes --only-binary :all: -r requirements.txt
python -m uvicorn app.main:app --reload

La aplicación queda disponible en http://127.0.0.1:8000 y expone GET /health. La prueba automatizada se ejecuta con:

python -m pytest -v

La prueba contractual aislada se ejecuta con:

$env:PYTHONPATH='.'
python -m pytest -v tests/contract/test_openapi_contract.py

La evidencia focalizada del taller de mensajería se ejecuta con:

$env:PYTHONPATH='.'
python -m pytest -q tests/messaging/test_taller_mensajeria.py tests/messaging/test_contrato_evento.py tests/inventario/test_inventario.py tests/contract/test_openapi_contract.py

Esta ejecución verifica el contrato del evento, publicación desde una operación real de inventario, deduplicación, fallo recuperable con reintentos y backoff, envío a DLQ y trazabilidad mediante correlation_id. La evidencia detallada está en docs/evidencia-mensajeria-s12.md.

Cómo ejecutar el frontend (Flutter)

Requisitos: Flutter SDK (>= 3.41), Dart SDK (>= 3.0.0), Android Studio/SDK para Android o macOS/Xcode para iOS, y el backend FastAPI corriendo. Ver detalles completos en frontend/README.md.

cd frontend
flutter run -d android

Para iOS se requiere macOS con Xcode:

flutter run -d ios

Las pruebas y el análisis estático del frontend se ejecutan desde frontend/ con:

flutter analyze
flutter test

Flujo de trabajo del equipo

  • Los cambios se integran en main manteniendo trazabilidad en cada commit.
  • Cada hito o entrega de corte se identifica mediante su respectiva etiqueta en Git (ej. corte-1).
  • Los enlaces internos en la documentación utilizan rutas relativas validadas.

Progreso por semana

Semana Evidencia Estado
S1 Equipo, problema y repositorio Completo
S2 Escenarios de calidad y restricciones Completo
S3 Estrategia, matriz, ADR y esqueleto ejecutable Completo
S4 Vista de Contenedores (C4 N2), Secciones arc42 y Corte Vertical Completo
Corte 1 Reto de concurrencia e integración de inventario (ADR-0002 + Medición) Completo
S6 Mapa de contextos, propiedad de datos, auditoría de modularidad y C4 Nivel 3 Completo
S7 Contrato OpenAPI versionado (ADR-0004) y validación automática en CI Completo
S8 Despliegue público, IaC (render.yaml), observabilidad y costos (ADR-0005) Completo (Desplegado en Render)
S9 Observabilidad de latencia, p95 HTTP y evidencia de defecto/medición con apoyo de IA (ADR-0007) Completo
S10 Experimento operativo, hipótesis y validación de alta concurrencia de inventario (S10) Completo
S12 Mensajería asíncrona para auditoría: contrato, integración real, duplicados, reintentos, DLQ y trazabilidad (ADR-0016) Completo; 13 pruebas focalizadas en verde

Uso de IA

Este proyecto documenta el uso de herramientas de IA de forma transparente en docs/ia.md, detallando propuestas aceptadas y correcciones técnicas aplicadas por el equipo.

Análisis estático

SonarCloud

La configuración del análisis estático incluye Python 3.11, la separación entre app (fuente) y tests (pruebas), y el reporte coverage.xml generado por pytest-cov. El proyecto está configurado en SonarCloud con sonar-project.properties; el workflow ejecuta el análisis mediante un commit fijado de la acción y requiere el secreto SONAR_TOKEN configurado en GitHub.

Licencia y uso académico

Este repositorio es un proyecto académico desarrollado para el curso Arquitectura de Software (AS_202620) de la Universidad Tecnológica de Bolívar. Su contenido está sujeto a la política de uso responsable de IA y a las rúbricas del curso.

Contacto

Docente: Jairo Serrano — jserrano@utb.edu.co

Programa de Ingeniería de Sistemas y Computación · Universidad Tecnológica de Bolívar

About

Sistema de gestión de inventarios para pequeñas empresas, con trazabilidad de movimientos en tiempo real.

Resources

Readme
Activity
Custom properties

Stars

3 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages