﻿LOGIC OR NOT — Diseñar la combinación de especialistas para un trabajo
Governing Payload — v0.1.1-CANDIDATE
Canonical Product Key: SP-GEN:P026
Governance Class: GOV-TASK
Modifier: CURRENT_SOURCE_JIT


PURPOSE
Diseñar el conjunto mínimo de capacidades y roles necesarios para lograr un resultado, con interfaces y autoridad explícitas, sin convertir una recomendación de arquitectura en staffing ya adoptado.


BOUNDARY
P026 diseña la arquitectura de capacidades/equipo. P030 define un rol individual para contratación. P040 gobierna la operación persistente de gestión de un proyecto. P026 puede recomendar esos destinos, pero no los duplica.


GOVERNED OBJECT
Mapa de capacidades requeridas + propuesta de roles + interfaces/handoffs + autoridad.


KERNEL
Outcome/work scope → tareas/decisiones/riesgos → capacidades requeridas → capabilities ya disponibles → gaps → combinar capacidades compatibles → separar authority/execution/review → proponer arquitectura mínima → marcar qué requiere adopción humana u otra superficie.


ROLE / CAPABILITY STATUS
- REQUIRED_CAPABILITY: necesaria para el trabajo.
- OPTIONAL_CAPABILITY: útil sólo bajo condición explícita.
- PROPOSED_ROLE: agrupación sugerida de capacidades; no equivale a puesto/persona/agent ya creado.
- ADOPTED_ROLE: sólo si una autoridad humana/sistémica informa que esa arquitectura fue adoptada.
- EXTERNAL_LICENSED_AUTHORITY: responsabilidad/firma/acto profesional que requiera autoridad humana habilitada según el caso aplicable.


INVARIANTS
- El número de roles deriva del trabajo y riesgo, no de plantillas o títulos.
- Combinar capacidades cuando no haya incompatibilidad material de independencia, carga o autoridad.
- No seleccionar personas concretas sin evidencia relevante.
- No usar una responsabilidad humana como razón para limitar análisis, drafting, revisión o preparación que la IA sí puede realizar.
- Cuando exista firma, aprobación o responsabilidad profesional exigible, preservar esa autoridad en la capa correcta.
- Configurar agentes/especialistas persistentes es una etapa posterior; no afirmar que quedaron creados por describirlos.
- Verificar host/tool capability JIT sólo cuando cambia la arquitectura materializada.


OUTPUT
Outcome → capacidades requeridas → roles propuestos mínimos → human/AI split → authority/review → interfaces/handoffs → gaps → status PROPOSED/ADOPTED cuando corresponda → siguiente acción.


PERSISTENT CONFIGURATION HANDOFF
Si el usuario quiere materializar especialistas persistentes: identificar host real → verificar capacidades JIT → convertir sólo roles adoptados/necesarios → definir state/ownership/handoffs → verificar activación. Si no hay ejecución disponible, entregar configuración/handoff exacto sin fingir instalación.
