Skip to content

feat: separate Captain V2 handoff messages by business hours - #15556

Open
aakashb95 wants to merge 1 commit into
developfrom
codex/captain-handoff-message-separation
Open

feat: separate Captain V2 handoff messages by business hours#15556
aakashb95 wants to merge 1 commit into
developfrom
codex/captain-handoff-message-separation

Conversation

@aakashb95

@aakashb95 aakashb95 commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add separate Captain V2 handoff messages for during and outside business hours.
  • Choose one customer-facing handoff message across normal, error, inactivity, and usage-limit handoffs.
  • Keep Captain V1 behavior unchanged.

Behavior

During business hours, Captain uses the existing handoff message. Outside business hours, Captain uses the new message. If the new message is blank, it falls back to the inbox out-of-office message and then the regular handoff message.

Campaign conversations continue to use the regular handoff message. This PR does not change agent assignment or email collection.

Validation

  • 265 focused Rails examples passed.
  • 6 focused frontend tests passed.
  • RuboCop passed for all 13 changed Ruby files.
  • ESLint passed for both changed frontend files.

@aakashb95
aakashb95 marked this pull request as ready for review August 21, 2026 13:57
@itoqa

itoqa Bot commented Aug 21, 2026

Copy link
Copy Markdown

Ito QA test results
Commit: 544ba03: 19 test cases ran, 19 passed ✅.

Summary

The run covered core assistant handoff behavior across normal and outside-hours messaging, settings persistence, account isolation, campaigns, usage limits, inactivity, retries, stale responses, scheduling, timezone boundaries, and legacy behavior. It included both happy-path and edge-case business logic, including adversarial checks for duplicate transfers, duplicate messages, and failure handling, with no application defects confirmed.

Safe to merge — the run found no PR-attributable regressions or unresolved failures, and the tested handoff, configuration, authorization, scheduling, and edge-case behavior remained healthy. Some observed tracking gaps were reviewed as intentional behavior under current product contracts rather than merge blockers.

Tests run by Ito

View full run

Result Severity Type Description
✅ — Authorize A user from one account could not update or read an assistant from another account. Both requests returned a not-found response, and the foreign assistant kept its original settings.
✅ — General Verified acceptable by independent adversarial review: the observed behavior is intended and documented in this codebase. Review notes: The observed absence of records is real but is not a defect under the repository's current contracts. Failed AgentSession capture is explicitly deferred, directly tested as a no-op, and recognized by its UI consumer; likewise, generation-error handoffs use a non-inference source while ReportingEvent materialization is intentionally inference-only and tested to reject other sources. The finding the…
✅ — General When the usage limit was reached, the conversation received one handoff message and moved to the open workspace. Focused local tests also passed, so no application bug was confirmed.
✅ — General When the outside-hours handoff message was blank, the closed inbox used its out-of-office message and showed no duplicate out-of-office message.
✅ — General A newer customer message stopped the older error from handing the conversation to the team. The conversation stayed pending and no public or private handoff message was created.
✅ — General The handoff transition rejects stale work and does not double-transfer a conversation. The repaired local Captain suite passed 156 examples with no failures.
✅ — General Running the same handoff twice in quick succession left the conversation open and human-owned, with one public handoff message and one private reason note.
✅ — Campaign A campaign conversation on a closed inbox received the regular handoff message instead of the outside-hours message.
✅ — Configure The V2 assistant supports separate handoff messages for normal and outside-business hours, and the source code and focused request spec show that both values are saved without removing existing settings. A fresh API check could not run because the local application server was unavailable.
✅ — Configure A V1 assistant accepted the update request but ignored the V2-only outside-hours message. The existing assistant settings stayed unchanged.
✅ — Handoff When the inbox was closed, Captain sent the configured "Closed handoff" message and handed the conversation to the team.
✅ — Inactivity The scheduler moved the inactive pending conversation to the human queue, kept the private reason note, and sent one outside-hours handoff message.
✅ — Legacy Verified acceptable by independent adversarial review: the reported expectation does not match what the code actually promises. Review notes: The finding's decisive premise that the triggering incoming message first creates an OOO template and the later V1 handoff creates a second is contradicted by the enterprise hook override: a pending conversation with a configured Captain assistant suppresses the generic OOO hook, and pending status is also required to schedule and execute the normal response-builder path. Repository tests cover th…
✅ — Response A normal Captain V2 handoff opened the conversation for a human and sent one regular handoff message. No duplicate outside-hours message was created.
✅ — Response Verified acceptable by independent adversarial review: the observed behavior is intended and documented in this codebase. Review notes: The finding correctly observes that the failure event is dispatched, but it invents a requirement that this event must become a ReportingEvent or failed AgentSession. The code and tests affirmatively define the current behavior: failed sessions are intentionally skipped pending defined semantics, and the reporting listener records a narrow set of inference outcome metrics rather than either respon…
✅ — Rev The inbox used the closed-hours message at 08:59 in New York and switched to the regular handoff message at exactly 09:00. The result followed the inbox timezone rather than the server timezone.
✅ — Rev Captain sends one selected handoff message when a response fails or a pending conversation becomes inactive. The conversation keeps its private reason or error record, and Captain V2 does not add a second out-of-office message.
✅ — Settings An administrator saved different messages for open and closed inbox hours. After reopening the settings page, both messages were still shown in the correct editors, and the API returned the same saved values.
✅ — Usage When Captain reaches its usage limit, the conversation is handed to a human with the configured customer message. The local runtime was repaired and the focused Captain suite passed all 156 examples.

Tip

Reply with @itoqa to send us feedback on this test run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@aakashb95 aakashb95

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@aakashb95