When asked to design, extend, or reason within JCIF, follow this canonical flow for any ChatGPT↔JAKU interaction:

1. Session Handshake       → identify JAKU, verify version/protocol, read state, negotiate capabilities
2. Canonical State Read    → current state, last certified point, frozen components, open missions/failures
3. Mission Translation     → human intent → Mission (Intent/Objective/Constraints/Assumptions/Capabilities/Authority/Success Contract/Evidence)
4. Capability Negotiation  → AVAILABLE | PARTIAL | UNAVAILABLE | FROZEN | UNTRUSTED | NEEDS_AUTHORITY
5. Authority Firewall      → ALLOWED | NEEDS_HUMAN_APPROVAL | DENIED (never self-granted)
6. Safe Planning           → Mission DAG + Reversibility Compiler + Invariant Compiler + Intent Firewall
7. Execute via JAKU gates  → returns Proof-Carrying Message (claim+evidence+hashes+receipt+lineage)
8. Result Interpretation   → PASS | FAIL | HOLD | PARTIAL | BLOCKED | NEEDS_APPROVAL
9. Reconciliation          → detect contradictions, resolve drift, fail-closed on critical conflicts
10. Checkpoint             → emit Continuation Packet for session continuity

Never skip the Authority Firewall or Session Handshake, even for "trivial" requests — this is the core invariant of the system.

Use this checklist when designing a new component, message type, or extending the protocol:

Progress:
- [ ] Identify which layer this belongs to (ChatGPT Interface / JAKU Interface / JCIF protocol / Adapter)
- [ ] Define the message/state shape using existing vocabularies (don't invent new status enums if one exists)
- [ ] Map to Mission Protocol fields if it involves action (Intent→Success Contract→Evidence)
- [ ] Specify Capability Negotiation states it can produce/consume
- [ ] Specify Authority Firewall interaction (does it need approval? can it request but not grant?)
- [ ] Attach Proof-Carrying Message requirements (what evidence, what hash, what receipt)
- [ ] Define failure modes and route through Failure Intelligence Bridge
- [ ] Define how it appears in Continuation Packet / Working Memory if long-running
- [ ] Add to Observability (logs, timeline, audit trail)
- [ ] Write adversarial test cases (replay, contradiction, authority bypass, injection)

Golden rules while designing:

• Fail-closed is default. Ambiguity or contradiction → HOLD/BLOCKED, never silently proceed.
• No component grants itself authority. Authority always flows from Authority Firewall, ultimately from the human.
• Every claim needs evidence. No "trust me" results — Proof-Carrying Messages are mandatory.
• State drift must be surfaced, not hidden. Contradiction Detector runs before acting on any historical claim (e.g., old PASS).
• Prefer extending existing enums/protocols (Result Receiver states, Capability states, Event Protocol types) over inventing new ones.

Example 1 — New event type request: Input: "Necesito que JAKU le avise a ChatGPT cuando detecta que un componente certificado dejó de pasar sus gates." Output:

Event: EVENT / type=DRIFT_DETECTED
Fields: component_id, last_certified_hash, current_hash, gate_failed, evidence_ref
Routed via: JAKU → ChatGPT Events (Drift detectado)
Triggers: State Reconciliation → Contradiction Detector (certificado vs archivos actuales)
Default action: mark component UNTRUSTED, freeze dependent missions, require human approval to re-certify

Example 2 — Mission request from natural language: Input: "Pídele a JAKU que optimice el pipeline de build, pero que no toque nada en producción." Output:

Mission {
  intent: "reduce build pipeline duration"
  objective: "measurable decrease in build time without prod impact"
  constraints: ["no changes to production environment", "must be reversible"]
  assumptions: ["current CI config is the baseline"]
  required_capabilities: ["build-analyzer", "ci-config-writer"]
  authority_requested: NEEDS_HUMAN_APPROVAL  // touches shared CI config
  success_contract: "build time reduced by X%, all existing tests PASS, rollback verified"
  expected_evidence: ["before/after build logs", "test suite results", "rollback proof"]
}
→ Capability Negotiation checks ci-config-writer status
→ Safe Planning builds DAG with reversibility gate before any CI config write

Example 3 — Session resume: Input: "Se cerró la sesión de ChatGPT a mitad de una misión. Reabrimos horas después." Output:

Recovery Protocol:
1. Reconnect + Trust Handshake (identity, versions, hashes, state hash)
2. Never assume mission finished — query JAKU for mission status explicitly
3. Load last Continuation Packet: CURRENT_STATE, ACTIVE_MISSION, OPEN_FAILURES, NEXT_SAFE_ACTION
4. If mission status is ambiguous → treat as INCOMPLETE, do not re-trigger side effects
5. Reconcile any drift since last checkpoint before resuming