# Clinic Data Service CI Routing

## Background

Clinic contains independent Go modules at the repository root, under
`clinic_data_service`, and under `cloud_server`. The existing root `all-test`
workflow treats every non-Cloud Server change as a root-module change. As a
result, a pull request that only changes Clinic Data Service runs the root
module's Docker-heavy test suite while never testing the changed nested module.

PR #1710 exposed this mismatch. Its root test job started MySQL, OpenSearch, and
Kibana repeatedly, hit the OpenSearch disk flood-stage watermark, and eventually
lost communication with the GitHub-hosted runner. The failures occurred in root
module packages and were unrelated to the TiCDC change in Clinic Data Service.

## Goal

Route Clinic Data Service changes to a dedicated, bounded CI workflow that uses
the nested module's Go version and dependencies. Do not run the root module test
or image-build workflows for pull requests that only change Clinic Data Service
or its implementation-plan and module-overview documentation.

## Target Contract

- `clinic_data_service/**` changes run module consistency checks, unit tests
  under `pkg`, and an API binary build from the Clinic Data Service module.
- Root Clinic changes continue to use the existing `all-test` and `Clinic CI`
  workflows.
- Cloud Server changes continue to use `CloudServer CI`.
- Implementation-plan and module-overview-only changes do not run a Go module
  test suite.
- Each Clinic Data Service CI matrix job has a 30-minute timeout.

## Implementation

1. Add a `clinic-data-service-changes` path-filter group and exclude Clinic Data
   Service, implementation-plan, module-overview, and CI-routing paths from the
   existing root-module filter. Root workflows use `dorny/paths-filter@v3` with
   `predicate-quantifier: every` so every exclusion is honored; the default
   `some` behavior would incorrectly accept a file that matched another negative
   rule.
2. Add a `Clinic Data Service CI` workflow that selects Go from
   `clinic_data_service/go.mod`, configures private-module access, and uses a
   module-specific cache through `actions/setup-go`. Do not add a second
   `actions/cache` restore over the same Go directories.
3. Run `go mod tidy` with a clean-diff assertion, run every test-bearing package
   under `./pkg/...` with a combined coverage profile, and build
   `cmd/api/main.go` as independent matrix jobs. Selecting test-bearing packages
   avoids the Go 1.25 `covdata` failure observed when a coverage profile includes
   packages without tests.
4. Update the module overview with the new CI ownership.

## Exclusions and Compatibility

The workflow intentionally does not run `go test ./...`. The module root has a
pre-existing test with an obsolete `ClusterSqlDiff` call signature, and the
`clinic_data_service/test` package contains environment-dependent integration
tests that expect a locally running API and external Feishu resources. Those
tests require a separate cleanup and integration-test environment.

This change does not modify runtime code, API behavior, authentication,
configuration, images, or deployment manifests.

## Test Plan

- Validate the workflow YAML and path-filter syntax.
- Confirm through the pull-request checks that a Clinic Data Service source
  change selects the dedicated workflow and skips both root workflows.
- Resolve every test-bearing package under `./pkg/...`, then run them with
  `go test -p 1 -covermode=atomic -coverprofile=coverage.out` from
  `clinic_data_service`.
- Run `go build -trimpath -buildvcs=false ./cmd/api/main.go` from
  `clinic_data_service`.
- Run `go mod tidy` and verify `go.mod` and `go.sum` remain unchanged.

## Release Boundary

Affected source modules are GitHub Actions configuration and documentation.
Required deployment modules are none. No Clinic CD, app-delivery, Kubernetes,
staging, or production deployment is required.