Atlas de límites

Entender

Una arquitectura auditable permite seguir una responsabilidad desde la interfaz hasta el paquete que la implementa. El mapa no sustituye al código: indica dónde empezar a verificar.

El mapa también puede mentir desde el manifiesto: el DriftDetector compara lo que milpa.json declara contra lo que el código trae en #[PluginMetadata]. Cuando divergen, el reporte lo nombra (MILPA_MANIFEST_DRIFT), porque el contrato que enseña es el que corre, no el que se escribe: un milpa.json con drift enseña a humanos y agentes una forma que ya no existe, y toda decisión tomada desde ese manifiesto hereda la brecha. El arreglo es regenerativo, no manual: php coa coa:plugins manifest <Plugin> (comando del host) reescribe el manifiesto desde el código, que es la fuente de verdad.

Ver

Abrir Atlas de límites

Selecciona un paquete y sigue sus relaciones y fuentes primarias.

Abrir artifact

Hacer

Ejecuta la práctica en tu checkout y conserva la salida como evidencia.

Consultar la referencia senior (paquetes fuente)

Verificar

Demuestra que puedes aplicar la unidad. El progreso solo avanza al aprobar la evaluación.

Criterios evaluados

Ubica al dueño de boot, capabilities, tools, gates y estado.
Sustenta cada afirmación importante con una fuente primaria.

Evaluación calificable

Resuelve los 4 escenarios. Esta unidad exige 4 de 4 respuestas correctas.

0 intentos

Pregunta 1 de 4doctor confirma que el kernel arrancó y /reports responde por HTTP, pero inspect:tools no muestra GenerateReport. ¿Qué límite conviene auditar primero?

El registro y el pipeline de tools en tool-runtime, empezando por ToolRegistry.La secuencia general de boot en runtime, porque toda ausencia posterior pertenece al kernel.El event store, porque una tool no existe hasta que deja un evento persistido.

Pregunta 2 de 4Un tutorial afirma: «Core ejecuta y persiste las aprobaciones porque define VerificationResult». ¿Cuál es la corrección arquitectónica más precisa?

Mantener la afirmación: quien define un tipo necesariamente es dueño de toda su ejecución y persistencia.Separar responsabilidades: Core define el contrato triestado; Workflow implementa la maquinaria y Orchestrator/Event Store aportan proceso e historia según el caso.Mover VerificationResult a Academy para que la interfaz y la experiencia educativa tengan un solo dueño.

Pregunta 3 de 4Una nueva tarjeta del atlas dice que un paquete «es dueño de la autorización», pero solo enlaza a la portada de la organización y no identifica interface, manifest ni archivo. ¿Cómo debe publicarse?

Como hecho verificado, porque el nombre del paquete hace plausible la responsabilidad.Como detalle interno estable, sin fuente, para no distraer al lector con enlaces.Como hipótesis pendiente, o no publicarse, hasta terminar en una fuente primaria que sostenga la afirmación.

Pregunta 4 de 4El milpa.json de ReportsPlugin declara que provee exports, pero el #[PluginMetadata] del código ya no la declara. Un tutorial cita ese manifiesto como evidencia de la capacidad. ¿Cuál es la lectura correcta?

El manifiesto manda: si milpa.json declara exports, la capacidad existe y el mapa puede citarla como hecho verificado.Es MILPA_MANIFEST_DRIFT: el contrato que enseña es el que corre, no el que se escribe — toda decisión tomada desde ese manifiesto hereda la brecha, y el arreglo es regenerarlo desde el código con php coa coa:plugins manifest ReportsPlugin (comando del host).Basta con editar milpa.json a mano para quitar exports; mantener sincronizados manifiesto y código es disciplina del editor.

La calificación valida respuestas en este navegador; no certifica identidad.

Rutas

Atlas de límites

Al terminar podrás

Entender

Ver

Hacer

Verificar

Fuentes primarias

Al terminar podrás

1Entender

2Ver

3Hacer

4Verificar

Fuentes primarias

Entender

Ver

Hacer

Verificar