# TiCDC Metadata Read-Replay Canary

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "ticdc-metadata-replay-canary-2026-08-27",
  "problems": [
    {
      "problemId": "cloud-ticdc-metadata-unavailable-hard-stop",
      "summary": "Cloud TiCDC tickets with exact org, source cluster, and changefeed context were forced to human_required before evidence because Auto-oncall had no managed TiCDC metadata operation.",
      "status": "optimized_verified",
      "applicability": "TiDB Cloud TiCDC topology diagnostics with typed orgId, clusterId, and an exact changefeed display ID.",
      "issueKeys": ["TCID-13093"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/TCID-13093#problem:cloud-ticdc-metadata-unavailable-hard-stop"
      ],
      "signalTextIncludesAny": [
        "cdc_configuration_meta_unavailable",
        "cdc_configuration_meta_missing",
        "TCID-13093"
      ],
      "observedThrough": "2026-08-31",
      "effectiveAt": "2026-08-27T09:24:53Z",
      "verifiedAt": "2026-08-31T08:58:19Z",
      "attemptedAction": "Add typed Managed Clinic TiCDC architecture evidence that exact-matches the business changefeed, binds the startup-marker query to its TiCDC instance and creation window, keeps version/deployment/control-plane dimensions independent, and removes an unsupported replication-progress scenario from topology-only tickets; verify with TCID-13093 after deployment.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/TCID-13093?focusedCommentId=23731608"
    }
  ]
}
-->

- Optimization ID: `ticdc-metadata-replay-canary-2026-08-27`
- Owner: Scenario classification policy and Managed Clinic Provider Executor
- Source: Clinic TiCDC metadata capability from
  [tidbcloud/nutshell-skills#204](https://github.com/tidbcloud/nutshell-skills/pull/204),
  canary case `TCID-13093`
- Implementation status: typed architecture-evidence, exact Managed Tool
  installation upgrade, and language-independent topology-only routing deployed
  and verified by read and write replays
- Effective status: `optimized_verified`

## Bounded problem

Auto-oncall currently normalizes every ticket-specific TiCDC diagnostic to
`human_required + provider:none` with
`cdc_configuration_meta_unavailable`, even when a Cloud ticket supplies an
exact organization, source cluster, and changefeed display ID. Clinic now has
canonical TiCDC changefeed metadata, but the Agent9 Managed Clinic Tool does
not yet expose a sanitized operation.

## Candidate change

- Add one bounded `ticdc_changefeeds_list` operation to Managed Clinic. Expose
  display identity, state, architecture, downstream type, checkpoint, and
  sanitized TiCDC cluster facts; keep sink configuration, credentials, filter
  rules, and kernel/internal IDs inside the Tool Sandbox.
- Allow `newarch` as a safe count-only log marker when runtime architecture is
  independently load-bearing.
- Admit only `TCID-13093`, only through a manual `mode=read` replay, and only
  with an exact typed Cloud target and changefeed reference.
- The original 2026-08-27 canary preserved the then-current CDC hard stop for
  the active worker, continuation, `mode=write`, and every other ticket. Later
  scenario admission is tracked by its own optimization record.

The 2026-08-31 follow-up replaces the Agent-authored architecture log selector
with `ticdc_changefeed_architecture_evidence`. The Managed Clinic Provider
Executor now exact-matches the business-facing changefeed, preserves TiCDC
version, deployment type, top-level Dataflow arch, and explicit control-plane
architecture as independent facts, and queries the exact
`changefeed-<display-id>-ticdc-*` stream only when the explicit architecture
field is empty. The deterministic Router also removes
`ticdc-replication-progress` when the frozen ticket has a positive topology
signal and no progress signal.

## Verification evidence

Direct read-only Clinic checks before implementation found two changefeeds on
source cluster `1379661944646415973`. Changefeed display ID
`2092776420211023872` reported a dedicated TiCDC deployment in running/normal
state, while a bounded historical log query found one
`TiCDC(new arch) server created` line with `newarch=true`. These checks prove
the Provider capability but do not prove the Auto-oncall diagnostic chain.

The source change merged as
[tidbcloud/aisupport#1117](https://github.com/tidbcloud/aisupport/pull/1117),
and the Agent9 staging Pod running source SHA `1a5290d823e9d6f2a26f8567aa21ba9627ad6aa0`
became Ready at `2026-08-27T09:24:53Z`. Managed Clinic v17 was installed on the
Evidence Agent with package digest
`ebb514025d48db9c2bee11401a31d4d522d1893ed140a5cce8861214d2e3e99f`.

Post-deployment `mode=read` replay
`10d8483f-9331-4594-aa6f-9666691bae85` completed with HTTP 200. Agent9
Operation `op_6832814b764e469aa8a2160f72e3a63e` executed the exact v17 package and
successfully returned `ticdc_changefeeds_list` metadata for the target
Changefeed: `normal`, dedicated TiCDC, `running`, version `v9.0.0-beta.1`, and
matching source cluster. A second v17 Operation
`op_31f5c3f659db473698e3a30a75a6f4bc` completed the one allowed refinement.
Evidence acquisition and response generation both reported `complete` with no
Provider failure codes. The replay stayed read-only: Jira, database evaluation,
and Feishu publication all reported `not_requested`.

The final response improved materially over the historical acknowledgement by
providing the dedicated/running facts, but correctly remained
`human_required`: `controlPlaneArch` was null and the replay's bounded log query
returned zero `newarch` markers. The complete diagnostic path took about 8m50s.

On 2026-08-31, a direct canonical Clinic read reproduced the missed evidence
inside the historical window. The matching stream was bound to
`changefeed-2092776420211023872-ticdc-0` and contained one
`TiCDC(new arch) server created` marker at `1787791877785248196` nanoseconds.
The prior replay selector required the different literal `newarch=true`, which
the actual line did not contain. The exact instance-bound selector plus actual
startup marker returned one stream and one line. Local Managed Clinic v21 and
scenario contract tests now cover this case, including another unrelated
changefeed on the same source cluster, and pass 111/111 focused tests. This is
Provider-capability evidence only; it is not yet a deployed replay result.

The first v21 deployment canary created run
`994a78b0-7965-4405-95d2-9cecc3ae80bf`. Its trace proved that the v21 bundle
was loaded but the Evidence Agent installation still referenced Managed Clinic
v20, so the typed architecture operation was unavailable and the Agent fell
back to `ticdc_changefeeds_list`. The Japanese topology-only ticket also
received a deterministic English `ticdc-replication-progress` fallback because
the local signal regex did not recognize the Japanese architecture wording,
even though the Scenario Router had already selected
`ticdc-deployment-topology`. This replay therefore remains failed verification,
not evidence that the architecture is unknown.

The typed architecture operation and scenario change merged in
[tidbcloud/aisupport#1164](https://github.com/tidbcloud/aisupport/pull/1164).
The installation and multilingual-routing follow-up merged in
[tidbcloud/aisupport#1167](https://github.com/tidbcloud/aisupport/pull/1167)
at source SHA `c40fc6943015ad22b9bf4eb07307250e18c18799`. Staging release workflow
`33372962270` installed Managed Clinic v21 on the exact Evidence Agent while
preserving its policy and Organization Auth. The live analysis Deployment then
reported the exact source SHA and became 1/1 Ready with `/`, `/healthz`, and
`/readyz` returning HTTP 200.

Post-deployment read replay `b4a30550-cb20-4a85-b7d0-40fa0ef41f90` completed
successfully with only `ticdc-deployment-topology`. It executed
`managed_auto_oncall_clinic` v21, package digest
`5b98f328052929b51eef27c1901a0f96400b17b612815a97d2650287adcd6501`,
and operation `ticdc_changefeed_architecture_evidence`. The result exact-matched
display ID `2092776420211023872`, kept dedicated deployment and TiCDC version
`v9.0.0-beta.1` independent, and found exactly one target-bound
`TiCDC(new arch) server created` marker in the changefeed creation window. All
runtime stages succeeded and the evaluation verdict was `ai_better`.

The authorized write replay `12b27e83-f3c4-4c8c-8bea-62b87f8d61d1` reproduced
the same single scenario and v21 evidence path. Database run `150169` is
`succeeded` with decision `internal_only`; its evaluation is `comparable` with
verdict `ai_better`. Jira updated the existing internal comment `23731608`.
Direct readback of that exact comment confirmed `public=false` and the expected
new-architecture, independent dedicated deployment, TiCDC version, and separate
source TiDB version statements. No customer-visible comment or issue transition
was performed.

## Unresolved gaps

- The customer-language mismatch remains a separate answer-selection and
  presentation issue; it is not repaired by this bounded CDC optimization.
- One allowlisted case does not establish precision, latency, or safe answer
  quality for the wider `ticdc_or_data_pipeline` population.

## Next validation action

Replay a wider recent Cloud TiCDC cohort and monitor whether semantic Scenario
Router selections remain precise across languages and whether the typed
architecture evidence continues to avoid version-based inference. Track any
customer-language presentation mismatch as a separate optimization problem.