Mantenimiento de la documentacion

Objetivo

Este portal existe para evitar que la documentacion de Cutlyy vuelva a quedar separada, duplicada o escondida entre dos repositorios.

Repos de origen

• cutlyy-front: experiencia web, rutas, guards, stores e integraciones cliente
• cutlyy-back: API, reglas de negocio, modelo de datos, automatizaciones e integraciones server-side
• cutlyy-docs: portal central de lectura y mantenimiento documental

Regla editorial

Seccion Negocio

Debe poder entenderla una persona no tecnica.

Eso implica:

• lenguaje claro
• menos jerga tecnica
• foco en flujo, decisiones y reglas

Secciones Frontend y Backend

Deben describir el estado real de implementacion.

Eso implica:

• nombrar componentes, rutas, headers, servicios o variables cuando haga falta
• dejar visibles limitaciones o legacy
• no maquillar riesgos conocidos

Cuando actualizar cada seccion

Cambio en el producto	Documento minimo a actualizar
Cambio en actores, membresias o permisos	business/actors-and-roles y docs relacionadas
Cambio en reglas operativas	business/business-rules
Cambio en booking, appointment, pago o review	business/booking-lifecycle y backend/data-and-services
Cambio en rutas o guards del panel	frontend/user-experience-and-routes
Cambio en stack, providers o stores	frontend/technical-architecture
Cambio en API, headers o seguridad	backend/api-and-security
Cambio en colecciones o side effects	backend/data-and-services
Cambio en integraciones o env vars	frontend/data-and-integrations o backend/integrations-and-operations

Checklist para mantener calidad

Antes de cerrar un cambio relevante:

1. confirma si el comportamiento funcional cambio
2. confirma si cambio el contrato tecnico
3. actualiza la pagina correspondiente en este portal
4. deja explicito si existe legacy o riesgo conocido
5. evita crear markdown sueltos en otros repos si ya cabe aqui

Como correr este portal

npm install
npm run start
npm run build

Estructura esperada

• docs/business: logica de negocio
• docs/frontend: comportamiento y arquitectura del frontend
• docs/backend: comportamiento y arquitectura del backend
• docs/reference: glosario y reglas de mantenimiento

Criterio para nueva documentacion

Antes de agregar una pagina nueva, preguntate:

• ¿ya existe una pagina donde esto encaja mejor?
• ¿esto es realmente una regla nueva o una variante de una regla existente?
• ¿la audiencia es de negocio o tecnica?

Si la respuesta es ambigua, prioriza ampliar una pagina existente antes de abrir otra.

Lo que no deberia volver a pasar

• duplicar la misma logica en varios markdown
• dejar reglas solo en el codigo sin explicacion funcional
• explicar solo el frontend o solo el backend cuando la regla es end-to-end
• esconder detalles importantes como legacy, accesos publicos o placeholders operativos