# Live Comment Context and Continuation Recovery ## Current Design - Dry-run replay and live analysis both materialize `input/comments.md` through the reply-safe customer-only actor filter. - The worker builds `SupportCase.comments` from the Jira issue field, which may be truncated, even though the continuation poller already reads paginated JSM and Jira platform comments. - A continuation adds only its triggering internal comment to the resumed Codex thread. Other L1, internal, support, and bot comments are hidden. - Continuations re-run the Enabled Coverage Gate. TCID-12920 comment `23179066` was enqueued as job `60043`, then skipped as `operation_request / human_required`, so Jira received no response. - A successful initial diagnostic preflight can write Jira without starting a Codex thread. TCID-12920 has no `auto_oncall_conversations` row, so the current resume-only continuation would also fail after the coverage skip is removed. ## Risks - Reusing dry-run filtering in live mode hides the exact L1/internal context an explicitly mentioned bot is expected to use. - Reading comments after the trigger creates time-travel context and makes a continuation non-reproducible. - Silently falling back to the truncated issue comment field would create two competing sources of truth. - Letting an explicit continuation bypass trigger-validity or safety boundaries could broaden automation into production operations; only autonomous business filters are bypassed. - Retrying the already-skipped TCID-12920 job before deployment would only reproduce the current skip and could create confusing audit history. ## Target Contract - Paginated Jira Service Management comments, joined with Jira platform ADF mention metadata, are the canonical live comment source. - Dry-run/replay keeps the existing reply-safe customer-only filter and replay cutoff. It must not ingest L1, support, internal, bot, target, or later bodies. - Live initial analysis receives the complete ordered Jira comment timeline available when the worker executes, subject only to existing bounded payload and attachment limits. - Continuation receives the complete ordered Jira comment timeline through the source `@bot` comment inclusive. Comments after that source ID are excluded. - Done, the autonomous issue allowlist, L1 Oncaller, and Enabled Coverage remain mandatory where applicable for initial jobs. An exact internal ADF `@bot` continuation bypasses all four after trigger validity checks, including when the issue is resolved or closed, because it is an explicit human invocation rather than autonomous discovery. - An exact internal ADF mention is an explicit continuation request. The worker still classifies the case and records Auto Coverage details, but does not skip the continuation merely because the enabled scenario/resolution lists exclude it. Unsafe or operational requests must return `human_required`; they must not execute operations or create a customer-visible reply. - If an issue has a persisted Codex thread, continuation uses `resumeThread`. If no thread exists because the initial diagnostic preflight completed without Codex, continuation may start one new thread from the canonical bounded live timeline. The resulting thread ID becomes the issue conversation mapping. - A read path never creates jobs, conversations, Jira comments, or compatibility files. There is no fallback to display-name mention matching, body regexes, or the truncated Jira issue comment field. - Production remains disabled. This rollout changes staging code only and does not enable customer-visible replies, issue transitions, or production actions. ## Implementation Steps 1. Split dry-run reply-safe comment selection from live full-timeline selection and add a continuation source-comment cutoff. 2. Hydrate worker live comments from the paginated canonical Jira APIs after the L1 gate and before classification; validate the source mention from that same snapshot. 3. Route exact continuation requests directly past Done, autonomous issue allowlist, L1 Oncaller, and Enabled Coverage filtering while preserving classification, safety output, internal-only delivery, and audit records. 4. Add controlled continuation thread start when no persisted thread exists, while preserving normal resume behavior and saving the resulting thread ID. 5. Update prompts, repository invariants, and the superseded continuation plan. 6. Run local contract tests before PR/deployment, then deploy through the normal staging image/app-delivery workflow. 7. After the new image is live, requeue TCID-12920 job `60043` once and verify its run plus idempotent continuation Jira response by source comment ID. ## Verification Checklist - [x] Dry-run still excludes L1/support/internal/bot and later comments. - [x] Live initial includes public customer, L1, internal, and bot comments. - [x] Live comments come from the paginated source and never the truncated issue field as a fallback. - [x] Continuation includes every ordered comment through the trigger and none after it. - [x] Continuation bypasses L1 Oncaller and Enabled Coverage filtering; its classification may still be `human_required`. - [x] Continuation discovery includes Done issues and ignores the autonomous issue allowlist. - [x] Existing conversations use `resumeThread`. - [x] Missing conversations start one bounded continuation thread and persist it. - [x] Public comments, plain-text mentions, wrong accounts, bot-authored comments, empty bodies, and oversized triggers remain ineligible. - [x] Typecheck, focused tests, full tests, and Kustomize renders pass locally. - [ ] Code and generated app-delivery image PRs are merged. - [ ] Staging pod runs the merged image and remains Ready with prod still disabled. - [ ] Logs, DB job/run/gate/conversation state, and the Jira continuation comment prove TCID-12920 completed after the one-time requeue. ## Out of Scope - No customer-visible continuation reply, Jira transition/close, production operation, prod cutover, secret-model change, or webhook implementation. - No reconstruction of historical Codex messages from Jira when a valid thread already exists; Jira timeline hydration supplements the canonical live turn. - No compatibility path for old workspaces and no cleanup from read endpoints.