mirror of
https://github.com/hanzoai/dev.git
synced 2026-10-25 03:32:32 +00:00
5f8f3a994a
Add a new `codex-reward-signals` crate and wire it into the TUI so the
Hanzo router gets production training feedback. Signals are content-free:
a response id, an enum, and (for ratings) a small integer — never any
prompt/response/file/code text.
Signals emitted:
- rating (1..3) on exit via a one-shot prompt; 0/Esc/Enter => dismiss
- regenerate on backtrack/re-run of a turn
- abandon on Ctrl+C interrupt mid-generation
The client POSTs {gateway_base}/v1/feedback with the same bearer token the
model client uses, fire-and-forget and silent on any failure. The exit
rating uses a bounded (<=1500ms) synchronous send since a detached task
would be killed on process exit. Gated to the Hanzo gateway; opt out via
HANZO_FEEDBACK=0|false|off or config `reward_signals = false`.
Response ids (previously discarded from ResponseEvent::Completed) are now
threaded through SamplingRequestResult -> turn state -> TurnCompleteEvent
-> app-server Turn.response_id -> ChatWidget.last_request_id.
Bumps hanzo-node to 0.6.53.
Co-authored-by: hanzo-dev <[email protected]>
Co-authored-by: Hanzo Dev <[email protected]>
codex-protocol
This crate defines the "types" for the protocol used by Codex CLI, which includes both "internal types" for communication between codex-core and codex-tui, as well as "external types" used with codex app-server.
This crate should have minimal dependencies.
Ideally, we should avoid "material business logic" in this crate, as we can always introduce Ext-style traits to add functionality to types in other crates.