# TiCDC Auto Coverage And OP Routing - Optimization ID: `ticdc-auto-coverage-2026-08-31` - Owner: Scenario Classifier and deterministic Auto Coverage Provider routing - Source: recent Cloud and OP TiCDC replays, including `TCID-13093`, `ST-2906`, `APID-29394`, and `NAID-12197` - Implementation status: merged, released, deployed, and replay-verified in staging - Effective status: `optimized_verified` ## Bounded problem The deterministic TiCDC hard stop ran before the ordinary OP and Cloud routing policy. It treated Cloud CDC metadata as mandatory for every environment, even though APID and NAID are OP projects and Wetech OP diagnosis uses metrics and logs rather than Cloud Dataflow metadata. The staging Enabled Coverage list already contained `ticdc_or_data_pipeline`, but the hard stop prevented it from reaching the Provider-backed diagnostic pipeline. ## Intended capability - Treat exact `APID` and `NAID` project keys as OP before considering `orgId`. - Route exact Wetech or `apac-test` OP TiCDC diagnosis to Wetech; keep Manus and other OP TiCDC human-owned with `op_unsupported`. - Route Cloud TiCDC diagnosis to Clinic without making TiCDC metadata a classification prerequisite. Unsupported metadata remains one Provider query outcome while other valid metrics and logs are preserved. - Remove the issue-level CDC replay canary. Ordinary scenario and resolution allowlists own automatic admission. - Keep TiCDC absent from the customer-publication scenario allowlist. Automatic processing writes only the stable Jira `public=false` internal comment and performs no production operation. ## Verification criterion After merge and exact-SHA staging deployment: 1. A Cloud CDC replay enters `evidence_assisted + clinic` without the historical metadata hard-stop flag. 2. A Wetech OP CDC fixture enters `evidence_assisted + wetech`; an unsupported OP CDC fixture remains `human_required + provider:none + op_unsupported`. 3. The active staging configuration contains CDC in Auto Coverage, contains no CDC replay canary, and still excludes CDC from customer publication. 4. At least one representative post-change CDC replay reaches the selected Provider path and its authorized write replay reads back one stable Jira internal comment with `public=false`. ## Deployment and replay evidence Source PRs `tidbcloud/aisupport#1158` and `#1160` merged. The staging template sync PR `tidbcloud/app-delivery#78685` removed the replay canary, and image bump PRs `#78689` and `#78690` deployed source SHA `618ba95340cb56ec82a3f61adbea7cab8cf43337`. The unified release published the same Skill source revision. Deployment generation 85 reached 1/1 updated, ready, and available replicas at `2026-08-31T02:40:53Z`; the Pod had zero restarts, and `/healthz` plus `/readyz` both returned HTTP 200. Live ConfigMap readback retained `ticdc_or_data_pipeline` in Auto Coverage, contained no CDC replay canary, kept `AUTO_ONCALL_CUSTOMER_REPLY_ENABLED=false`, and limited the customer scenario list to `feature_usage_or_capability`. The live read replays proved the deterministic entry boundary but did not complete the Provider and write criterion: - `TCID-13093` run `6e7a44df-2770-4566-99fd-08601d4ef654` selected `ticdc_or_data_pipeline + evidence_assisted + clinic`, with no missing key or CDC metadata hard-stop flag. - `APID-29394` run `5bd2fe01-3346-4d3d-9fdd-c25deca43aa0` on the final SHA selected `APID -> OP`, `human_required`, `provider=none`, and exactly the canonical `op_unsupported` risk. It did not retain the earlier account-specific unsupported alias. - `NAID-12205` selected `NAID -> OP` and the generic unsupported OP boundary. `TCOC-5870` stopped earlier at the existing Jira request-context 404 boundary and supplied no CDC routing evidence. All three routed replays then stopped before the Evidence Agent because the Scenario Router Agent returned `agent9_turn_failed:runtime_error`. Agent9 Session inspection reported `LLM provider request failed`. Independent minimal Router health Session `sess_dda7ec38be944f108b620a90b6ccd612`, containing only an instruction to reply `OK` and no ticket data, tools, files, or output schema, failed twice on `gpt-5.6-sol` with the same runtime error while Agent9 `/livez` and `/readyz` remained HTTP 200. This isolates the current blocker from CDC routing, Clinic, Provider queries, prompt size, and the deployed Skill. At that blocker point, no `mode=write` replay had been attempted and no Jira comment, database evaluation, or Feishu publication had changed. The optimization therefore remained `optimized_unverified` until the post-recovery verification below. ## Post-recovery serial replay verification After Agent9 Codex OAuth refresh recovered, the three replays that had stopped on `agent9_turn_failed:runtime_error` were rerun serially. The read runs all completed through Scenario Router reconciliation and Final Response: - `TCID-13093` run `0e6db9b5-fce8-4187-8177-bdad30f59eb0` entered `evidence_assisted + clinic`. Both `ticdc-replication-progress` and `ticdc-deployment-topology` completed Clinic evidence acquisition and were diagnosed as confirmed. - `APID-29394` run `0f8b3d6c-6a25-4c0b-8d4e-de0eab400d1a` retained the exact `human_required + provider:none + op_unsupported` boundary and completed the Router and Final Response path. - `NAID-12205` run `5437e285-6b55-4f1f-b2ec-fd407b0abca7` retained the generic unsupported OP boundary and completed three bounded TiCDC scenarios, Router reconciliation, and Final Response. The authorized write replays then completed against the same current routing: - `TCID-13093`: DB run `150163`, run `355d2d14-bc66-49bb-a554-ceea1e421b12`, updated existing Jira internal comment `23731608`. - `APID-29394`: DB run `150164`, run `55999b65-38f0-4b27-852c-09893b232699`, updated existing Jira internal comment `23730428`. - `NAID-12205`: DB run `150165`, run `16c7177f-bea1-4661-a055-6a67ff2f10c1`, created Jira internal comment `23759577` because no prior mapping existed. Each run succeeded without an analysis error. Jira readback returned `public=false` for all three exact comment IDs, and the stable `auto-live:v1::initial` mapping count was exactly one per issue. This passes the bounded Cloud Provider, OP control, and private Jira verification criterion. Human review of the resulting drafts remains independent from this capability-level verification. All six long replay HTTP callers lost their response connection after several minutes while the server-side analysis continued. The read runs reached a successful terminal workspace; the write runs additionally persisted the DB run and Jira update. This is a separate generic long-request lifecycle gap; it is not evidence that CDC routing or Agent9 execution failed. ## Next validation action Collect human review of the refreshed drafts. Track the generic long-request connection lifetime separately from this verified CDC routing problem; do not reclassify a completed server-side run as a CDC or Agent9 diagnostic failure.