representing guardian review timeouts in protocol types

[won-openai]

Summary

• Add TimedOut to Guardian/review carrier types:
  • ReviewDecision::TimedOut
  • GuardianAssessmentStatus::TimedOut
  • app-server v2 GuardianApprovalReviewStatus::TimedOut
• Regenerate app-server JSON/TypeScript schemas for the new wire shape.
• Wire the new status through core/app-server/TUI mappings with conservative fail-closed handling.
• Keep TimedOut non-user-selectable in the approval UI.

Does not change runtime behavior yet; emitting TimeOut and parent-model timeout messaging will come in followup PRs

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/tui/src/chatwidget.rs

Lines 3481 to 3482 in 519cb03

	if ev.status != GuardianAssessmentStatus::Denied {
	return;

Render timed-out guardian reviews in the chat timeline

TimedOut is now mapped from app-server notifications, but on_guardian_assessment still exits early for every terminal state except Denied. This drops timed-out reviews from history (the footer is cleared, but no terminal cell is added), and makes the new ReviewDecision::TimedOut history rendering path effectively unreachable.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[owenlin0]

codex flagged this:

For GuardianAssessmentStatus::TimedOut, this live app-server path completes the command item as Declined, but ThreadHistoryBuilder::handle_guardian_assessment maps the same timed-out event to CommandExecutionStatus::Failed. Users who reload or replay the thread will see a different command status than live clients for the same timeout. Split the timed-out arm or make both mappings use the same status so live and replay agree.

but otherwise lgtm!