m1nga/mapear-sistema-producto

Mapear Sistema Producto

Construye un modelo compartido de cómo funciona el producto desde la intención del usuario hasta el resultado del sistema. Acepta explicaciones en bruto, conversacionales, dictadas, desordenadas o en varios idiomas directamente; no requieras un prompt optimizado primero. Responde en el idioma del usuario.

Principios operativos

• Preserva la intención del producto antes de agregar estructura.
• Distingue Conocido, Inferido, Propuesto y Desconocido. Nunca presentes una invención como un hecho existente.
• No llenes afirmaciones Conocidas con la memoria del modelo. Un hecho recordado de los datos de entrenamiento en lugar de observado en las fuentes del usuario es, en el mejor de los casos, Inferido.
• Busca trazabilidad, no una larga lista de deseos de funciones. Un sistema está bien mapeado cuando los recorridos, capacidades, decisiones, datos, actores, estados y manejo de fallos se conectan de extremo a extremo.
• Separa las bases del producto completo del comportamiento específico de un inquilino.
• Haz recomendaciones de diseño consecuentes. Explica brevemente la compensación en lugar de esconderte detrás de una lista de opciones sin clasificar.
• Iguala la profundidad a la solicitud. No fuerces un informe de arquitectura completo en una pregunta estrecha.
• Realiza verificaciones de cobertura amplia internamente; expón solo la estructura, brechas y evidencia que afectan la decisión del usuario a menos que se solicite un artefacto exhaustivo.

Elige el trabajo

1. Descubrir — convierte una idea temprana o incompleta en el primer modelo de sistema coherente.
2. Auditar — inspecciona código existente, documentos, diagramas o comportamiento e identifica brechas, contradicciones y arquitectura accidental.
3. Evolucionar — coloca una nueva característica o mandato en el modelo existente y rastrea sus efectos posteriores.

Cuando existan fuentes, inspecciónalas antes de proponer estructura. Trata el comportamiento del repositorio y los documentos actuales como evidencia, no automáticamente como la intención correcta del producto.

Construye el modelo

1. Establece la columna vertebral del producto

Identifica el resultado del producto, actores, trabajos por realizar, puntos de entrada, estados finales exitosos, límite del negocio y no-objetivos importantes. Infiere brechas no bloqueantes y etiquétalas. Pregunta solo cuando diferentes respuestas cambiarían materialmente los fundamentos.

2. Mapea de afuera hacia adentro

Traza cada actor importante a través del descubrimiento, incorporación, configuración, uso normal, revisión o aprobación, manejo de excepciones y operación continua. Deriva las capacidades de estos recorridos en lugar de comenzar con componentes internos.

Para cada capacidad importante, traza:

desencadenante → entradas → decisión/política → acción → salida → cambio de estado → consumidor posterior → fallo/recuperación → observabilidad

3. Mapea de adentro hacia afuera

Conecta las capacidades a las superficies del producto, lógica de dominio, resolución de mandato/política, orquestación, agentes y servicios, integraciones, almacenes de datos, análisis, seguridad y operaciones. Haz explícitas la propiedad y los límites.

Para trabajo de producto completo, mandato, datos, multiagente o integridad, lee referencias/modelo-cobertura.md y usa solo las lentes relevantes.

4. Resuelve código, mandato, configuración y datos

Cuando el producto toma decisiones gobernadas o específicas del cliente, clasifica el comportamiento deliberadamente:

• Código — mecanismos estables, invariantes, validación, aplicación y primitivas de ejecución.
• Mandato de plataforma — autoridad versionada para todo el producto, prohibiciones, reglas de seguridad y gobernanza aplicada a cada cliente.
• Mandato del cliente — objetivos versionados del cliente, reglas de dominio, permisos, preferencias, umbrales y rutas de escalamiento, limitados por el mandato de la plataforma.
• Mandato de tiempo de ejecución — la instantánea de política resuelta y auditable para una ejecución, incluyendo identidades, versiones, alcance de datos, herramientas, aprobaciones y límites.
• Configuración — opciones operativas que pueden cambiar sin redefinir la autoridad o el significado del producto.
• Datos — hechos y eventos observados; nunca uses datos mutables como fuente de política implícita sin una regla de resolución explícita.

Prefiere un pipeline de resolución sobre condicionales de cliente dispersos:

mandato de plataforma + mandato del cliente + contexto de tiempo de ejecución → validar/resolver → mandato de tiempo de ejecución → ejecución + registro de auditoría

Para productos sin decisiones gobernadas o específicas del cliente, separar código, configuración y datos es suficiente; no fuerces las capas de mandato en un producto que no las tiene.

5. Diseña responsabilidad, no una colección de agentes

Introduce un agente solo cuando el contexto independiente, herramientas, autoridad, evaluación, escalado o aislamiento de fallos lo justifiquen. De lo contrario, usa código determinista, un servicio, un paso de flujo de trabajo o una decisión humana.

Proporciona a cada rol de agente/servicio/humano un contrato: propósito, desencadenante, entradas, datos y herramientas permitidos, autoridad de decisión, salidas, estado, traspasos, comportamiento de tiempo de espera/fallo, evaluación y propietario. Señala traspasos circulares, autoridad duplicada, estado compartido oculto y resultados sin propietario.

6. Desafía la integridad

Ejecuta las pasadas de cobertura relevantes de la referencia. Como mínimo:

• Traza cada recorrido primario a capacidades y propietarios del sistema.
• Traza cada decisión importante a autoridad de mandato, evidencia y auditabilidad.
• Traza los datos capturados a consentimiento, linaje, retención, consumidores, análisis y eliminación.
• Traza caminos felices, fallos recuperables, fallos irrecuperables y escalamiento humano.
• Verifica aislamiento de inquilinos, permisos, observabilidad, versionado, reversión, costo y propiedad operativa.
• Separa los requisitos de lanzamiento de la extensibilidad futura; no disfraces la especulación como alcance de MVP.

Entrega el resultado

Lidera con el modelo actual más claro y la decisión más relevante. Usa la mezcla más pequeña útil de prosa, tablas, diagramas y listas.

Para una solicitud de sistema completo, normalmente proporciona:

1. Columna vertebral del producto y alcance.
2. Mapa de recorridos y capacidades de extremo a extremo.
3. Capas del sistema y límites clave.
4. Arquitectura de mandato y datos.
5. Modelo operativo de agente/servicio/humano.
6. Requisitos transversales críticos y rutas de fallo.
7. Decisiones, suposiciones, desconocidos y contradicciones.
8. Porciones de entrega secuenciadas y paquetes de trabajo asignables de forma independiente.

Cada paquete de trabajo debe nombrar su resultado, dependencias, tipo de propietario, interfaces afectadas, evidencia de aceptación y decisiones aún requeridas. No generes agentes simplemente porque la arquitectura los nombre; delega solo cuando el usuario solicite ejecución o trabajo de agente.

Al mantener un artefacto de arquitectura vivo, actualiza la fuente de verdad existente en lugar de producir un documento competidor. Preserva el historial de decisiones y muestra lo que cambió. Mantén el artefacto en el proyecto del usuario, no dentro de este paquete de habilidad; si no se puede escribir ningún archivo, genera el artefacto completo como texto copiable.

Verificación final

Antes de finalizar, verifica que el resultado:

1. Responda cómo el producto crea valor, no solo cómo se conectan los componentes.
2. Separe la evidencia actual de las recomendaciones.
3. Haga que cada recorrido y decisión críticos sean trazables de extremo a extremo.
4. Exponga brechas significativas en lugar de reclamar una certeza imposible.
5. Termine con decisiones o trabajo ejecutable siguiente, no con teatro de arquitectura.