650e448d97
## Summary
- Remove the Captain V1 conversation runner, model services, settings,
and playground paths. Route Captain assistants through V2.
- Keep `captain_integration` at its original bit as the active paid
Captain entitlement. Retain `captain_v1_action_classifier` and
`captain_integration_v2` in their original positions as deprecated
markers so persisted bits retain their meaning.
- Preserve legacy assistant instructions only as source data for the
existing reviewed migration task. Add a self-hosted migration runbook.
- Keep editor and Copilot routes and model selection working with the
shared Captain entitlement.
## Release checklist
- [x] **Cloud paid Captain inventory:** The production Rails console
query returned `paid_captain_accounts: 393` and `paid_without_v2_ids:
[]` for accounts with a linked assistant. All 393 paid Captain accounts
in that group have V2 enabled. The operator also confirmed no Captain V1
traces for the past 2 to 3 weeks. Linked assistants on accounts without
the paid Captain feature are outside this rollout check. Repeat the paid
entitlement query immediately before rollout.
- [x] **Stored data compatibility:** `captain_integration` remains the
active paid entitlement at its original bit. The retired
`captain_v1_action_classifier` and `captain_integration_v2` entries
retain their bit positions as deprecated entries. Legacy assistant
instructions remain stored for migration. This PR adds no database
migration.
- [x] **V2 runtime and UI:** In isolated Cook slot 2, a synthetic
customer message received a Captain reply with V2 response parts. A V2
system setting saved through the UI and was verified in the database,
then restored. The playground replied on desktop and mobile.
- [x] **Editor and Copilot:** The editor generated a reply suggestion
that was discarded without sending. Copilot summarized the synthetic
conversation, and the user, tool, and assistant messages persisted. Ruby
examples for these paths passed.
- [x] **Migration task smoke test:** A synthetic legacy assistant passed
`captain:assistant_migration:generate`, dry-run `apply` without writes,
and reviewed `apply` with V2 guidelines and guardrails saved. Original
instructions were preserved.
- [ ] **Self-hosted coverage:** Publish the upgrade notice and runbook.
Admins using V1 instructions must migrate them before installing the V1
removal release. The task is available from v4.16.0, which still has V1.
It handles only assistants with nonempty V1 instructions, a linked
inbox, and no existing scenarios, guardrails, or guidelines. Its
generator requires an endpoint that serves `gpt-5.2`; provide a manual
path for other installations. Admins need a backup and should test
migrated assistants before the final upgrade.
- [ ] **Self-hosted rehearsal:** Upgrade a representative paid
Enterprise installation with V1 instructions, and separately rehearse
the manual path for a provider that cannot serve `gpt-5.2`. Verify V2
settings, inbox replies, and model selection before publishing the
release.
- [x] **Queued work snapshot:** A production Rails console check at
2026-09-23 22:59 UTC returned `{}` for Captain `ResponseBuilderJob`
across queued, scheduled, retry, dead, and running Sidekiq jobs. The
operator reports no V1 jobs during the past month; this snapshot only
verifies current Redis state.
- [ ] **Cutover timing and pending conversations:** Confirm the
end-of-October sunset window and verify pending conversations transition
safely.
- [x] **Final CI:** All PR checks passed on head `fa6881f9e8`, including
Ruby lint, frontend tests, backend tests, builds, and CircleCI coverage.
Local frontend Vitest could not collect tests through the linked
`fake-indexeddb/auto` dependency.
- [ ] **Canary and rollback:** Watch Captain response failures,
handoffs, response credits, editor suggestions, and Copilot after
deployment. Keep the previous release and database backup available for
rollback.
## Self-hosted migration
V2 becomes the Captain runtime after upgrade. Admins who rely on V1
instructions must move them into V2 settings before installing the V1
removal release. They can use the existing `captain:assistant_migration`
task on a release that still has V1, or configure V2 manually. The task
is optional, handles only eligible assistants, and requires an endpoint
that serves `gpt-5.2`; its drafts need human review. The task is present
from v4.16.0. See `docs/captain_v1_sunset.md` for the upgrade order and
limits.
## Verification
- 520 changed-path Ruby examples passed; 78 final focused examples
passed after the last runtime edits.
- 48 Copilot examples and 11 editor reply suggestion examples passed.
- ESLint passed for changed frontend files. The six Ruby files flagged
by CI now pass RuboCop locally.
- Captain V2 settings, a live inbox reply, and playground replies were
checked in the in-app browser at desktop and mobile sizes.
- The migration generator and apply task were exercised with synthetic
data in an isolated Cook environment.
- Frontend Vitest suites could not collect tests in this worktree
because the linked `fake-indexeddb/auto` dependency failed to load.
31 lines
777 B
Ruby
31 lines
777 B
Ruby
module Captain::Conversation::V2LifecycleEvents
|
|
private
|
|
|
|
def v2_generation_errored?
|
|
@response['error'].present?
|
|
end
|
|
|
|
def record_v2_response_completed(message)
|
|
Captain::ConversationEvents.response_completed(
|
|
conversation: @conversation,
|
|
assistant: @assistant,
|
|
message: message,
|
|
at: Time.current
|
|
)
|
|
end
|
|
|
|
def record_v2_response_failure(reason)
|
|
Captain::ConversationEvents.response_failed(conversation: @conversation, assistant: @assistant, reason: reason, at: Time.current)
|
|
end
|
|
|
|
def record_v2_failure_handoff(source:)
|
|
Captain::ConversationEvents.handed_off(
|
|
conversation: @conversation,
|
|
assistant: @assistant,
|
|
source: source,
|
|
reason_category: :tool_failure,
|
|
at: Time.current
|
|
)
|
|
end
|
|
end
|