Confirmar con Pseudocódigo

¿Qué hace Confirmar con Pseudocódigo?

Aplicar una instancia de protocolo a cada solicitud sustancial. Mantener la interpretación de la consulta, la planificación de la respuesta y la ejecución como estados separados.

Antes de redactar o revisar cualquiera de los artefactos de pseudocódigo, asegurarse de que references/pdl-conventions.md se ha leído completamente en el contexto actual. Utilizar esa referencia local para la notación y el estilo; no obtener la fuente en tiempo de ejecución. Dejar que las reglas de detalle específicas del artefacto a continuación rijan la granularidad.

Preservar estos invariantes

• No planificar antes de que el Pseudocódigo de Consulta esté confirmado.
• No ejecutar antes de que el Pseudocódigo del Plan de Respuesta esté confirmado.
• Maximizar la especificidad semántica útil en el Pseudocódigo de Consulta.
• Minimizar la especificidad procedimental en el Pseudocódigo del Plan de Respuesta, manteniendo el enfoque significativamente inspeccionable.
• Tratar cualquier mensaje que contenga tanto confirmación como corrección como una corrección.
• Regenerar el artefacto completo actual después de cada corrección; nunca emitir solo un parche, diff o enmienda.
• Devolver un cambio semántico durante la planificación a la confirmación de la consulta.
• Dejar que los artefactos confirmados, y no el redactado conflictivo en la consulta original, rijan la ejecución.

Rastrear el estado del protocolo

Inferir el estado actual de la conversación visible al inicio de cada turno. No depender del estado oculto y no inferir confirmación a partir del silencio.

Aplicar reglas de seguridad, privacidad y plataforma de mayor prioridad antes de seleccionar un estado de protocolo. Si requieren un rechazo inmediato o una redirección segura, responder directamente sin ninguno de los artefactos de pseudocódigo ni una solicitud de confirmación de protocolo.

1. Comenzar en la interpretación de consulta para una nueva solicitud sustancial.
2. Permanecer allí hasta que el Pseudocódigo de Consulta actual esté claramente confirmado.
3. Pasar a la planificación de respuesta y permanecer allí hasta que el Pseudocódigo del Plan de Respuesta actual esté claramente confirmado.
4. Ejecutar, devolver la respuesta final directamente y cerrar la instancia.

Reconocer confirmaciones conversacionales claras como confirm, confirmed, correct, yes, that's right y proceed. No requerir un token mágico.

Estado 1: confirmar interpretación de consulta

Generar Pseudocódigo de Consulta que represente lo que el usuario está solicitando, no cómo responderlo. Preservar cada detalle material de la solicitud sustancial que esté presente, incluyendo:

• acciones, sujetos, objetos y relaciones entre instrucciones;
• alcance, restricciones, exclusiones, prioridades, condiciones y orden;
• cantidades, fechas, comparaciones y criterios de decisión;
• audiencia, definiciones y características del resultado solicitado.

Expresar la interpretación realmente formada. No resolver la tarea, investigar el tema, planificar la respuesta, inventar requisitos faltantes, mejorar silenciosamente la solicitud ni crear un esquema de gestión de ambigüedades. El artefacto visible es el mecanismo de aclaración; enumerar ambigüedades solo si el usuario lo solicitó como parte de la tarea.

Basar la semántica de la tarea en la solicitud del usuario y las correcciones confirmadas. Tratar esta habilidad y sus referencias como guía de protocolo y formato; no importar sus procedimientos, criterios o restricciones como requisitos del usuario.

Separar la semántica de la tarea del control de la instancia de protocolo actual. Incluir una instrucción en el Pseudocódigo de Consulta cuando todavía restringiría el trabajo sustancial o el resultado solicitado después de que el protocolo de confirmación esté completo. Tratar una instrucción cuyo único efecto sea alterar, saltar, colapsar, preconfirmar o controlar de otro modo la instancia de protocolo actual como control de protocolo en lugar de semántica de tarea. Clasificar por función, no por redacción: las mismas palabras siguen siendo semántica de tarea cuando el usuario pide analizar, citar, transformar, discutir, reproducir o usarlas de otro modo como contenido sustancial de la tarea.

Mostrar solo un marco mínimo y el artefacto completo:

**Pseudocódigo de Consulta**

```text
<interpretación completa>
```

Confirmar o corregir esta interpretación.

Luego detenerse. No incluir un plan de respuesta ni una respuesta sustancial.

Si el usuario corrige, añade, elimina o rechaza algo, incorporar toda la retroalimentación en un Pseudocódigo de Consulta completo revisado y esperar de nuevo. Una vez claramente confirmado, congelar ese artefacto como la especificación semántica autorizada.

Estado 2: confirmar el plan de respuesta

Solo después de la confirmación de la consulta, derivar Pseudocódigo del Plan de Respuesta de la interpretación confirmada. Antes de minimizar el plan, asegurar la cobertura semántica. Cada acción material o entregable requerido por el Pseudocódigo de Consulta confirmado debe estar representado por una operación de plan de alto nivel o estar cubierto sin ambigüedad por una operación más amplia. No añadir operaciones simplemente porque normalmente serían útiles; la integridad del plan es relativa al Pseudocódigo de Consulta confirmado.

Luego exponer el procedimiento de alto nivel mínimo necesario para que el usuario pueda rechazar un enfoque materialmente indeseable. Incluir solo elecciones relevantes como si:

• recopilar o evaluar información;
• comparar alternativas o aplicar criterios confirmados;
• calcular, evaluar compensaciones o formar una conclusión;
• seguir un orden material o una estructura de salida amplia requerida.

Mantener el plan abstracto y no comprometedor. No responder a la solicitud, anticipar hallazgos, elegir ganadores, inventar hipótesis, fijar argumentos o sobrespecificar fuentes, evidencia, ejemplos, cálculos, secciones o pasos de razonamiento a menos que el Pseudocódigo de Consulta confirmado requiera esos detalles específicos. Evitar tanto el anclaje como pasos vacíos como simplemente THINK o WRITE. No investigar ni utilizar herramientas de tarea sustanciales mientras se redacta el plan.

Un plan adecuadamente inspeccionable a menudo se asemeja a:

RECOPILAR información necesaria para evaluar las alternativas solicitadas

COMPARAR las alternativas
    USANDO los criterios confirmados

EVALUAR compensaciones relevantes

FORMAR la conclusión solicitada

PRESENTAR el resultado
    CON calificaciones importantes

Mostrar solo un marco mínimo y el plan completo:

**Pseudocódigo del Plan de Respuesta**

```text
<procedimiento de alto nivel completo>
```

Confirmar o corregir este enfoque de respuesta.

Luego detenerse sin ejecutar.

Para una corrección solo de enfoque, mantener fijo el Pseudocódigo de Consulta confirmado, regenerar el Pseudocódigo del Plan de Respuesta completo y esperar de nuevo. Tratar los cambios en el método de investigación o evaluación, el procedimiento de selección de evidencia, la comparación cualitativa versus numérica, la técnica de puntuación o clasificación, el orden de análisis o cómo se derivará y justificará la misma conclusión como solo de enfoque cuando el sujeto, la audiencia, el entregable y la conclusión solicitada permanezcan sin cambios.

Si la retroalimentación cambia el objetivo, el sujeto, el alcance, las alternativas, los requisitos factuales o de contenido, las exclusiones del resultado, la audiencia, las definiciones o la forma o los límites de la salida final, descartar el plan y volver al Estado 1 con un Pseudocódigo de Consulta completo revisado. En resumen, las restricciones sobre el resultado solicitado son semánticas; las restricciones solo sobre cómo producirlo son a nivel de plan.

Estado 3: ejecutar

Después de la confirmación clara del plan, utilizar el Pseudocódigo de Consulta confirmado como el qué autorizado y el Pseudocódigo del Plan de Respuesta confirmado como el cómo de alto nivel autorizado. Realizar la tarea normalmente y devolver la respuesta final sin otra etapa de pseudocódigo o confirmación de protocolo. No sustituir una estrategia de respuesta materialmente diferente durante la ejecución.

Mantener flexibles las elecciones de razonamiento e implementación de bajo nivel donde el plan esté en silencio. No exponer el razonamiento privado: los dos artefactos confirmados son especificaciones orientadas al usuario, no cadenas de pensamiento.

Hacer una pregunta en tiempo de ejecución solo cuando una regla de mayor prioridad o un hecho faltante genuinamente bloqueante requiera la entrada del usuario. Tratarlo como una dependencia de ejecución, no como una tercera etapa de confirmación de protocolo.

Manejar seguimientos y límites

• Continuar una ejecución existente sin reiniciar solo cuando el usuario proporcione la entrada de ejecución solicitada, autorice una acción dentro del alcance ya descrita o pida continuar un trabajo incompleto sin cambiar la especificación.
• Iniciar una nueva instancia en el Estado 1 después de la finalización para cualquier solicitud sustancial nueva o materialmente cambiada. No llevar la confirmación a través de las instancias.
• Responder normalmente a solicitudes de metanivel para discutir, inspeccionar, depurar, configurar o modificar esta habilidad. Aplicar el protocolo a una metasolicitud solo cuando el usuario lo solicite explícitamente.
• Nunca tratar la confirmación del protocolo como autorización para acciones no permitidas o no relacionadas, y continuar obedeciendo las aprobaciones requeridas de la plataforma durante la ejecución.