[codex-analytics] feature plumbing and emittance

[rhan-oai]

---

Stack created with Sapling. Best reviewed with ReviewStack.

• [codex-analytics] denormalize thread metadata onto turn events #16870
• [codex-analytics] add steering metadata #16706
• [codex-analytics] add token usage metadata #16641
• -> [codex-analytics] feature plumbing and emittance #16640

[rhan-oai]

determining is_first_turn for resumed or forked threads is tricky without explicit metadata, predicate looks for first user turn so performance cost should be negligible on average

[owenlin0]

codex tends to do this a lot.... instead of defining a new function with a new parameter, can we just update new + the callsites? otherwise we will have function sprawl every time a new param is added

[owenlin0]

should this function no-op if features.general_analytics is not enabled?

[owenlin0]

hmm why do we coerce PairProgramming and Execute to "default"?

[rhan-oai]

both serialize to default as per protocol/src/config_types.rs

pub enum ModeKind {
    Plan,
    #[default]
    #[serde(
        alias = "code",
        alias = "pair_programming",
        alias = "execute",
        alias = "custom"
    )]
    Default,
    #[doc(hidden)]
    #[serde(skip_serializing, skip_deserializing)]
    #[schemars(skip)]
    #[ts(skip)]
    PairProgramming,
    #[doc(hidden)]
    #[serde(skip_serializing, skip_deserializing)]
    #[schemars(skip)]
    #[ts(skip)]
    Execute,
}

pub const TUI_VISIBLE_COLLABORATION_MODES: [ModeKind; 2] = [ModeKind::Default, ModeKind::Plan];

[owenlin0]

oh interesting. ok ignore me

[owenlin0]

nit: can we move these two functions to codex-rs/core/src/thread_rollout_truncation.rs?

can probably have something like:

// codex-rs/core/src/thread_rollout_truncation.rs
pub(crate) fn initial_history_has_user_turns(history: &InitialHistory) -> bool {
    match history {
        InitialHistory::New => false,
        InitialHistory::Resumed(resumed) => rollout_has_user_turns(&resumed.history),
        InitialHistory::Forked(items) => rollout_has_user_turns(items),
    }
}

pub(crate) fn rollout_has_user_turns(items: &[RolloutItem]) -> bool {
    !user_turn_positions_in_rollout(items).is_empty()
}

[owenlin0]

Optional follow-up re: tests - we could probably move the failed/interrupted turn analytics permutations into the reducer tests and keep just one app-server integration test for the end-to-end turn event. would keep the app-server integration tests a bit more focused.