[Proposal] Decide whether request_id_ref is required, and whether a host may derive request_id #305

Part of issue #118. Raised in the PR #272 review.

The problem

request_id_ref is optional on toolCallResult (specification/v0.1.0/hooks/tool-call-result.json requires only tool, exit_status and outputs), and hooks.md applies the record-it rule only "when present". A host that leaves the field out skips the check completely. A careful attacker leaves it out, and only a careless one gets recorded.

PR #272 makes the reference hosts send it. The shim derives the request's request_id from the host's call id (Claude Code tool_use_id, OpenCode callID) and sends the same value as the result's request_id_ref, so it needs no state. Other implementations have no reason to send it.

That derivation raises its own question. request-envelope.json calls request_id a "unique identifier for this hook invocation", and §17.1's recovery for REPLAY_DETECTED is to regenerate it. A derived id repeats if a host asks twice about one call. PR #272 handles that by retrying once with a random id and giving up the pairing for that call, but the spec says nothing either way.

Decision needed

1. Make request_id_ref required on toolCallResult in a future version? That's a breaking schema change.
2. Or keep it optional and require the Guardian to record a result that carries none, as a request_id_ref_absent finding?
3. Or leave it optional and say plainly that the rule only catches results that carry a reference?
4. May a host derive request_id from its own call id, as long as each invocation still gets a unique one? Or should the pairing key travel as its own field, so request_id stays random?

Constituencies

Observed Agent implementers, Guardian implementers, auditors and incident responders.