S26 R06 · PROCESO02 · Observador superviviente de proceso

Estado de este corte: protocolo y banco precomprometidos; ninguna ejecución de los catorce casos. La compilación preparatoria no cuenta como ejecución. Los resultados se incorporarán en un documento separado, preservando los esperados de este banco.

Objeto, corte y sedes

Continuación de R06 T03/T04/T08 desde Lenguaje 3f306da4e4896a0738ef1bb3a9775a42219437b2 y laboratorio e04e51d2d9f17d9aebb4545e950c789d00fac67e. Se conservan las ramas main y lab/playground-sv-permanente. LOCAL01 acreditó pánicos desenrollables dentro de un proceso; este banco contrasta una frontera entre dos procesos bajo un mismo anfitrión confiable.

Se reutilizan ReceivedBytes, admit, AdmittedDelivery, Capture y certify, el conjunto literal I0205-01 conservado en R05 y su oráculo. No hay cambios del núcleo, IR, gramática, perfiles fuente ni campañas anteriores. Pilares, perfiles/contratos/ensamblaje y transición secuencial se han leído completos; sus identidades se cotejan con el corte indicado. Las obligaciones específicas proceden de R06 §§3–5, R02 y las sedes R2-0/LIG allí enlazadas.

Antecedente instrumental conservado

PROCESO01 no pudo abrir el canal Unix: el entorno devolvió EPERM antes de crear el hijo. No se ejecutó ningún caso de comportamiento. Esta variante cambia el transporte a tuberías anónimas y conserva aquel intento, sus fuentes y sus oráculos; no presenta el impedimento como conformidad ni utiliza sus resultados para cerrar discriminadores.

Protocolo fijado antes del ensayo

El padre conserva en RAM las aperturas y escribe apertura.json antes de lanzar cada hijo. Cada caso reserva dos identificadores instrumentales, Pnn-A y Pnn-B, ligados al mismo encargo de prueba; inicialmente se selecciona A. El emisor es observador-R06-PROCESO02, con ámbito de una instancia de campaña. No hay reutilización entre casos, identidad global, permiso de reintento ni persistencia de la correlación acreditada. B sólo se utiliza para el control explícito de selección en P07.

Dos tuberías anónimas heredadas de Command/Stdio::piped separan los mensajes hijo→padre del control padre→hijo. La tubería de mensajes transporta piezas con magia/versionado de ocho bytes R06P02\0\x01, longitud de cuerpo u32 big endian y tres campos JSON: intento, clase, contenido. Las clases admitidas son captura, informe y barrera. La completitud requiere cabecera, longitud exacta del cuerpo recibido y decodificación válida. EOF no constituye un informe. Se conserva el canal literal en canal.bin y el prefijo procesado.

El hijo admite el conjunto existente y copia el descriptor del objeto admitido. Envía esa captura y el recibo obtenido mediante certify. El padre compara la captura y la codificación del recibo con la geometría, contexto y recibo del oráculo fijado. Esto cualifica entrega documental local desde un hijo controlado; no acredita una pantalla, adquisición física ni independencia frente a un hijo arbitrariamente malicioso que falsifique una captura.

El primer informe de cada intento se conserva íntegro. Un duplicado idéntico en bytes queda identificado sin reemplazarlo; un segundo informe distinto genera conflicto, conserva ambas piezas y deja de ofrecer concordancia del intento seleccionado. Un informe de A recibido tras seleccionar B se conserva como tardío de A. B exige su propia captura e informe correlacionados; el contenido igual no sustituye la identidad del intento. Los mensajes de un intento no abierto se conservan como ajenos y no producen recepción atribuida.

Las barreras anteriores al aborto y posteriores a la escritura esperan un byte de liberación del padre. En P04 el padre termina al hijo en la barrera posterior a la escritura mediante Child::kill. P07 cambia la selección en una barrera antes de liberar los informes. Se observa la salida del hijo mediante try_wait, distinguiendo código y señal. Los códigos de salida nunca crean un recibo.

En los casos de cierre de canal, truncamiento o rechazo de cabecera, el hijo permanece esperando una orden por la dirección inversa del canal. En P10 envía la barrera espera_sin_informe y queda esperando esa orden. El padre inicia el plazo de 150 ms sólo después de recibir esa barrera, para acreditar que el estímulo alcanzó el punto fijado. El padre guarda frontera.json antes de liberar o terminar administrativamente al hijo; allí la terminación debe permanecer no observada. La salida final posterior se registra aparte. El agotamiento de un plazo no se transforma en muerte de proceso ni ausencia de efecto.

El hijo transfiere una única vez los descriptores 0 y 1 heredados a objetos File mediante dos llamadas unsafe a File::from_raw_fd. La precondición es el hijo nuevo creado por el padre con ambas tuberías, sin otros propietarios Rust ni uso de stdin()/stdout() en esa rama. Así puede cerrar realmente la escritura y seguir esperando control. La invocación manual de la modalidad interna hijo no pertenece al perfil acreditable. No hay reinterpretación de memoria del núcleo ni interfaz FFI nueva.

El padre lee bloques de hasta 512 bytes desde un hilo que posee la salida del hijo y los entrega por sync_channel de capacidad uno. El consumidor impone las cuotas del protocolo. Pueden coexistir un bloque en lectura y otro en la cola, además del prefijo recibido. Se conserva EOF emitido por el lector; perder el lector sin EOF es error instrumental. Al terminar el hijo, el padre cierra el receptor y recoge el hilo. No se garantiza esta recogida si el anfitrión pierde control de los procesos o aparecen descendientes que retengan el descriptor, excluidos del montaje.

Oráculos previos

Cada caso exige simultáneamente su estado de canal, código/señal final, presencia de captura, recepción seleccionada, lectura local y conservación de apertura; añade los controles específicos de la tabla. Una discrepancia se conserva y provoca salida 1. Un fallo instrumental detiene la campaña con error, sin contar casos posteriores como ejecutados. Las dos campañas utilizarán los mismos oráculos, con compilación debug y release sin debug_assertions.

Recursos y cobertura

• Linux x86-64; tuberías anónimas, dos procesos vivos como máximo y un hilo lector auxiliar del padre, catorce casos secuenciales y ninguna conexión de red. El mismo ejecutable identificado actúa como padre e hijo. No se crean sockets ni se requieren permisos adicionales.
• Cuerpo de mensaje: 16384 bytes. Canal recibido: 65536 bytes más un byte centinela; el exceso se conserva como prefijo y no se analiza. Hasta ocho mensajes analizados por caso y dos intentos; no hay cola de reintentos.
• Archivos de entrada: 8192 bytes por pieza auxiliar; la admisión conserva sus cuotas propias. Lectura del efecto: 1024 bytes. Salida por archivo: 1048576 bytes. No se acredita una cota global de RAM o CPU.
• Recepción: 1500 ms desde la creación del hijo; en P10 se sustituye por 150 ms desde la barrera observada. Espera final: 2 s. El padre supervisa la espera del hijo; éste no tiene un temporizador autónomo. Los tiempos son recursos del ensayo, no primitivas semánticas ni prueba de vigencia. No se derivan garantías de tiempo real.
• Directorios nuevos bajo control del operador. El hijo sólo produce el efecto local declarado en P03/P04; su salida estándar es exclusivamente la tubería de mensajes y su entrada estándar, la tubería de control. La salida de error del hijo se descarta; no se interpreta como informe. El límite de fallos se observa mediante canal y estado del proceso. No se ensayan procesos descendientes ni herencia hostil de descriptores.

La separación sobrevive a la terminación del hijo dentro de este perfil. No prueba supervivencia del padre, del anfitrión o de la energía, integridad física de RAM, durabilidad ni aislamiento frente a privilegios. La lectura del archivo inicial o modificado sólo describe ese destino local al terminar; no acredita ausencia universal de efectos. Todas las observaciones conservan efecto_externo=NO_ACREDITADO, sin acción dependiente ni reintento automático. Escribir o sincronizar evidencia no constituye una transacción durable.

Las cuotas agregada/de mensajes tienen guardas, pero P11 sólo cualifica el exceso de cuerpo. No se presenta este banco como cobertura exhaustiva de agotamiento de recursos, autenticación de productor o variantes de protocolo. T07 y la integración completa permanecen pendientes; cero casos globales S26 cerrados.

Reproducción y trazabilidad

Después de publicar este precompromiso, desde esta carpeta:

/opt/sv-rust-1.98.0/bin/cargo build --offline --locked --target-dir /tmp/r06p2-build
/tmp/r06p2-build/debug/sv_s26_r06_proceso02 ../../r05/fixture /tmp/r06p2-debug
/opt/sv-rust-1.98.0/bin/cargo build --release --offline --locked --target-dir /tmp/r06p2-build
/tmp/r06p2-build/release/sv_s26_r06_proceso02 ../../r05/fixture /tmp/r06p2-release

La compilación se realiza sobre el árbol del Lenguaje; el espejo conserva las mismas piezas, sin constituir otra distribución compilable por sus rutas relativas. FUENTES.json identifica las fuentes recibidas. Las fechas y los identificadores de Git son evidencia de procedencia del expediente, no autoridad del resultado semántico.

El seguimiento de este incremento se identifica por S26/PROCESO02 y la revisión de Sucesos. No se asigna un nuevo identificador RETP. S22/Bis y el orden catálogo/cierre → S24 conservan su estado.