Casos de uso¶
Ejemplos de aplicación para aprender ASILO 0.1 y MILPA 0.1. No son perfiles aceptados ni casos reales.
Los casos de esta página son ilustrativos. Se aceptan casos reales depurados cuando cuentan con el consentimiento escrito de las personas o de la organización implicadas y una persona mantenedora revisó su anonimización; el consentimiento no se publica. Consulta cómo aportar.
La metodología no exige una interfaz gráfica, un SDK o un sistema multiagente. El proyecto decide su forma; las obligaciones se revisan por alcance y condición en las fichas aceptadas.
1. Un proyecto que ya existe¶
Pregunta: ¿cómo ordenar sus fuentes sin reescribirlo todo?
Empieza por identificar responsable y alcance, localizar las siete funciones del núcleo y declarar el perfil. Prepara un índice que señale las fuentes dueñas; no copies reglas a cada carpeta. Si falta un perfil aceptado adecuado, registra la situación y propuesta.
Artefactos: manifiesto, índice, fuentes y decisiones. Reglas: MILPA-R-001, R-004, R-006. Evidencia pendiente: ubicaciones reales, revisiones, owner y validación del manifiesto.
2. Pasar un encargo entre asistentes¶
Pregunta: ¿cómo continuar una revisión con otra herramienta?
Prepara un traspaso con objetivo, revisiones, límites, hallazgos y próxima acción. Revisa la clasificación de datos y el nuevo destinatario. El segundo asistente consulta las fuentes; no se supone que conoce la memoria privada del primero ni hereda autorizaciones.
Artefactos: presupuesto de contexto, informe y traspaso sugerido. Reglas: ASILO-R-003, R-006, MILPA-R-002. Evidencia pendiente: contenido recibido, vigencia y permisos efectivos.
3. Procesar archivos sin interfaz gráfica¶
Pregunta: ¿cómo revisar un inventario y producir un archivo de propuesta?
Limita la tarea a datos sintéticos y un destino declarado. Separa la propuesta del efecto de escribir, sustituir o borrar. Comprueba contrato, autorización, límites y revisión si la acción entra al catálogo crítico. Tener un proceso local no elimina riesgos ni todas las condiciones de aplicación; las excepciones se examinan en cada ficha.
Artefactos: contexto, alcance del agente, contrato de efecto y registro de ejecución. Reglas: ASILO-R-001, R-004, R-005, R-007. Evidencia pendiente: qué se leyó/escribió y pruebas de rechazo y parada aplicables.
4. Una aplicación que consume una capa de agentes¶
Pregunta: ¿cómo conectar interfaz, backend y agentes sin confundir responsabilidades?
Declara los proyectos y contratos que cruzan sus fronteras, las capas y su dirección de dependencia. Separa identidad humana, permisos de aplicación y alcance del agente. Identifica el punto de efecto y la persona autorizada a revisar acciones críticas. El login por sí solo no demuestra autoridad para aprobar cualquier objeto.
Artefactos: vínculo, arquitectura, alcances y catálogo crítico. Reglas: MILPA-R-007, ASILO-R-002, R-004, R-005. Evidencia pendiente: contrato en ambos extremos, autorizaciones y efectos observados.
5. Cambiar el modelo o una configuración relevante¶
Pregunta: ¿podemos sostener las mismas afirmaciones después del cambio?
Revisa destinatarios de datos, contexto y límites; ejecuta de nuevo los casos de evaluación aplicables antes de sostener aptitud. Conserva la evidencia anterior como anterior. La continuidad no autoriza cambiar límites ni repetir un efecto cuya ejecución es incierta.
Artefactos: decisión de cambio, evaluación y registro de ejecución. Reglas: ASILO-R-003, R-006, R-007, R-008. Evidencia pendiente: configuración nueva, casos ejecutados y riesgo residual.
Estos recorridos no cubren por sí solos todas las obligaciones. Para declarar aplicación, revisa el conjunto de requisitos, sus condiciones y excepciones.