Graph Spec Compiler

Que es

Convierte una peticion simple en un graph_spec verificable (schema: assets/graph-spec.schema.json): contrato de objetivo, nodos con responsabilidad unica y write_set exacto, edges solo por dependencia causal con payload nombrado, olas topologicas con write_sets disjuntos, guardian final con contexto fresco y manifiesto cerrado, y controles con METHOD y falsificacion (references/fases-de-compilacion.md). El validador scripts/validate_graph_spec.py es determinista y emite hallazgos tipados con --emit-fix para los mecanicos. [CÓDIGO]

El argumento central: el checker de un loop comparte cerebro y contexto con el productor; el graph MUEVE la verificacion a un nodo con contexto fresco. No agrega checkpoints — reubica el check donde puede disentir. [DOC]

Cuando usar

• Objetivos multi-tarea con paralelismo real, fuentes multiples o efectos que exigen aprobacion.
• Usa la menor estructura posible: si una secuencia simple basta, recomendarla y explicar la decision (compone con agent-harness-simplify).
• NO para dibujar diagramas (mermaid-diagramming) ni para orquestacion en codigo JavaScript (dynamic-workflow-forge).

Procedimiento

1. Extrae el objective_contract: resultado, alcance, exclusiones, criterios verificables, supuestos vs datos requeridos, condicion de retiro.
2. Descompon en tareas de responsabilidad unica; clasifica cada par (HARD_DEPENDENCY | SOFT_PREFERENCE | SHARED_INPUT | RESOURCE_CONFLICT | WRITE_CONFLICT | NONE) — edge solo con payload nombrado (references/disciplina-de-escritura.md).
3. Compila desde templates/graph-spec.skeleton.json: olas topologicas, write_sets disjuntos por ola, guardian con allowed_inputs cerrado.
4. Valida: python3 scripts/validate_graph_spec.py <spec.json> --json — cero hallazgos o corrige con --emit-fix. [CÓDIGO]
5. Emite el paquete de aprobacion (templates/approval-package.md) y DETENTE: nada se ejecuta sin APROBAR <graph_id> <version> exactos.

Contract

• Aceptacion: validador con cero hallazgos; paquete de aprobacion completo con mapa de escritura; guardian presente con manifiesto ⊆ allowed_inputs. [CÓDIGO]
• Limites: compila y valida; NO ejecuta olas (eso es graph-run-discipline); no disena los controles en profundidad (graph-controls-designer). falsification_result es una atestacion DECLARADA por el autor: el validador lee JSON y nunca corre el experimento, asi que solo exige que la atestacion exista y nombre su falsification_test. Cero hallazgos significa "el reclamo esta bien formado", jamas "el control fue falsificado" — observarlo de verdad es trabajo del runtime (graph-run-discipline). [CÓDIGO]
• Casos borde: objetivo que no justifica graph (recomendar secuencia simple con razon); efecto de radio global (nodo propio, unico en su ola, con nominal_approval). [EXPLICIT]
• Supuestos: el runtime real puede no soportar paralelismo — entonces el graph se entrega como plan y la ejecucion queda 'No ejecutado'. [SUPUESTO]
• Trade-off: compilar cuesta mas que responder directo; se paga solo cuando dependencias, escrituras o verificacion independiente lo justifican. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · scripts/ automatización local · assets/ recursos estáticos.