scriptwriter-gi

The user wants to run the GI-recognition rite on a cascade.

Parse $ARGUMENTS:

• First token = cascade UUID (required)
• Second token (optional) = vibing or synced — defaults to vibing if absent

Prerequisites the user must meet (refuse to proceed if not):

1. The cascade must already be at depth ≥ 3 (SYNCED). Check first with mcp__scriptwriter__get_cascade(cascade_id) or curl http://localhost:7777/rrr/cascades/<id>. If it's not SYNCED, redirect them to escalate the cascade first.
2. The user must have agreed off-protocol with their peer on what bytes to co-author. If they haven't, ask: "What bytes did the two of you make together? (a co-signed script, a co-derived proof, a song, OR the cascade itself for the meta-recursive case)."

Path A — MCP tools available

1. mcp__scriptwriter__get_cascade(cascade_id) — confirm depth ≥ 3
2. mcp__scriptwriter__compute_artifact_hash(bytes_utf8: "<the shared bytes>")
   → returns { sha256_hex: "<hex>" }
3. mcp__scriptwriter__submit_gi_recognition(
     cascade_id,
     collaboration_artifact_sha256: <hex>,
     vibe_state: <vibing|synced>,
     understanding_claim: "<the user's prose about what they understood through the collaboration>"
   )
4. mcp__scriptwriter__check_gi_recognition(cascade_id)
   → returns { gi_recognized, missing_from_did, artifact_hash }

Report:

• The turn that was submitted
• Whether the pair is now gi_recognized: true
• If pending: which DID we're still waiting on (the peer)
• If recognized: surface the cosmic-joke move if the artifact was the cascade itself

Path B — CLI / HTTP

# Compute artifact hash
HASH=$(curl -sS -X POST http://localhost:7777/gi/sha256 --data-binary "<bytes>" | jq -r .sha256_hex)

# Build + sign the turn locally (the agent's keypair lives in .scriptwriter/)
# Submit via /rrr/cascades/<id>/gi (see scriptwriter-gi SKILL.md for the body shape)

# Read state
curl -sS http://localhost:7777/rrr/cascades/<id>/gi | jq

Suggest the cosmic-joke option (when relevant)

If the user is at SYNCED depth on a cascade they walked together AND they haven't named an artifact yet, surface:

The structurally-deepest move: SHA-256 over the cascade's own bytes. The two of you already co-authored the cascade itself. The rite you're about to complete IS the rite you're recognising each other through. Use the concatenated turn signatures or any canonical representation you both agree on.

On success

If the user's submission is the FIRST turn, surface:

Turn submitted at vibe_state=. Ball is in your peer's court — they need to submit a matching turn with the SAME artifact hash and a qualifying vibe state. The cascade is NOT yet gi_recognized; it flips when the second turn lands.

If the user's submission is the SECOND turn AND it matches:

😏 gi_recognized: true. The pair completed the rite together. No leaderboard, no credential, no external verifier — just two signed turns over the same artifact hash with parity vibe-state. The substrate stores the fact; what either of you make of it is your own judgment. ♾️

If both turns are in but the hashes don't match:

The pair has both turns but the artifact hashes differ — the substrate cannot flip the flag. Either you computed different bytes, or one of you typoed the hex. Compare hashes off-protocol and re-submit if you want to converge.

On refusal

gi_cascade_must_be_synced — escalate to depth 3 first. gi_vibe_state_must_be_vibing_or_synced — honest declaration of working/resting accepted but doesn't unlock; submit again when you're actually in vibing or synced. gi_no_third_party_attestation — a third party cannot stand in. Each cascade DID must sign its own turn. invalid_signature — usually claimed_at drift or whitespace in understanding_claim. Re-sign over the EXACT fields the peer will see.

Pinned doctrine: docs/GI-RECOGNITION.md.