# Important Repos Analysis Audit Report

Date: 2026-03-28

## Executive Summary

Current scan results are not yet sufficient to support efficient and accurate cross-module logical analysis across the important repository set.

The current state is uneven:

- `tidb-management-service` is relatively strong on runtime interface and method dependency coverage.
- `oneconfig`, `infra-cd`, `aws-shared-cd`, and `app-delivery` contain strong raw source evidence for config and deployment analysis.
- However, the deployment/config side has not been converted into tracked, analysis-ready knowledge artifacts comparable to `interfaces/*.json` and `service-mapping/*.json`.

Practical consequence:

- manual analysis is already possible for some end-to-end questions
- efficient knowledge-base-native analysis is not yet possible
- cross-repo joins still rely on opening raw source trees and inferring relationships by hand

## Final Verdict

Verdict: `Partial, but not analysis-ready`

Reason:

The current knowledge base can support selected runtime-centric analysis, but it cannot yet support reliable and low-friction joins across:

`runtime service -> config source -> deployment repo -> environment/cluster target`

This is mainly a representation gap, not a total evidence gap.

## Evidence Base

Tracked KB evidence used:

- `knowledge/repos/tidb-management-service/deep-scan-state.json`
- `knowledge/repos/tidb-management-service/interfaces/*.json`
- `knowledge/repos/tidb-management-service/service-mapping/*.json`
- `knowledge/repos/app-delivery/meta.json`
- `knowledge/repos/aws-shared-cd/meta.json`
- `knowledge/repos/infra-cd/meta.json`
- `knowledge/repos/oneconfig/meta.json`

Local source evidence used:

- `/Users/lc/coding/oneconfig/README.md`
- `/Users/lc/coding/oneconfig/Jenkinsfile`
- `/Users/lc/coding/oneconfig/apply.sh`
- `/Users/lc/coding/infra-cd/README.md`
- `/Users/lc/coding/infra-cd/doc/gha.md`
- `/Users/lc/coding/infra-cd/projects/infra-api/Pulumi.dev.yaml`
- `/Users/lc/coding/aws-shared-cd/readme.md`
- `/Users/lc/coding/aws-shared-cd/pool/lib/env.ts`
- `/Users/lc/coding/aws-shared-cd/pool/eks-freetier/Pulumi.dev-us-east-1-f01.yaml`
- `/Users/lc/coding/app-delivery/README.md`
- `/Users/lc/coding/app-delivery/root-app.yaml`
- `/Users/lc/coding/app-delivery/app-registry/dedicated-global-service.yaml`
- `/Users/lc/coding/app-delivery/app-registry/tidb-mgmt-service.yaml`
- `/Users/lc/coding/app-delivery/dedicated-global-service/envs/dev/config.yaml`
- `/Users/lc/coding/app-delivery/serverless-global-service/envs/dev/oneconfig-eventbus.yaml`
- `/Users/lc/coding/tidb-management-service/utilities/dynamicconfig/loader.go`
- `/Users/lc/coding/tidb-management-service/utilities/allowlist/impl.go`

## Audit Matrix

| Repo | Repo type | Current evidence quality | Analysis readiness | Main blocker |
|------|-----------|--------------------------|--------------------|--------------|
| `tidb-management-service` | runtime multi-service | Strong on runtime scan | `Partial to Strong` | joins to config/deployment are not tracked in KB form |
| `oneconfig` | config source-of-truth | Strong in raw repo, weak in KB artifacts | `Partial` | no tracked config-analysis output |
| `infra-cd` | infrastructure/platform delivery | Strong in raw repo, weak in KB artifacts | `Partial` | no tracked platform/deployment-analysis output |
| `aws-shared-cd` | environment/platform deployment | Strong in raw repo, weak in KB artifacts | `Partial` | no tracked environment/deployment-analysis output |
| `app-delivery` | application rollout | Strong in raw repo, weak in KB artifacts | `Partial` | no tracked service-to-cluster deployment mapping output |

## Per-Repo Findings

### 1. tidb-management-service

Current status:

- `deep-scan-state.json` shows 6 primary-service binaries scanned
- interface files and service-mapping files exist for all 6 primary services
- the state file records 603 methods and 78 services
- rescan notes explicitly mention lifecycle/runtime side effects and schema alignment

Strengths:

- good binary coverage
- good method-level dependency coverage
- explicit runtime-side-effect capture
- enough evidence for service-internal and method-level reasoning

Weaknesses:

- join to deployment/config is mostly outside the tracked scan outputs
- runtime outputs do not yet expose direct structured links to `oneconfig`, `app-delivery`, `infra-cd`, or `aws-shared-cd`

Assessment:

- strong runtime half
- not enough by itself for cross-module reasoning

### 2. oneconfig

Current source evidence:

- `README.md` defines branch-to-environment mapping:
  - `dev` -> dev env, nightly namespace
  - `staging` -> staging env, staging namespace
  - `prod` -> prod env, prod namespace
  - `personal/${name}` -> dev env, `${name}` namespace
- `apply.sh` converts each top-level service directory into `ConfigMap` objects named `oneconfig-{dir}`
- `Jenkinsfile` derives `STAGE` and `NAMESPACE` from branch name and runs `./apply.sh`

Why it matters:

- this repo is clearly a source-of-truth candidate for runtime config
- the environment mapping is explicit
- the delivery mechanism is explicit
- the output object model is explicit: repo path -> configmap name -> namespace

Observed gap:

- there is no tracked KB artifact that indexes:
  - all config groups
  - branch/env/namespace mapping
  - generated configmap names
  - likely runtime consumers

Assessment:

- strong raw evidence
- weak KB representation
- cross-repo reasoning still requires manual source reading

### 3. infra-cd

Current source evidence:

- `README.md` identifies ownership: Infra API deployment plus multi-account management
- `doc/gha.md` documents automation paths that create PRs to bump versions or secrets
- `projects/infra-api/Pulumi.dev.yaml` shows environment-specific infra API configuration
- `projects/*/Pulumi.{dev,staging,prod}.yaml` exist across infra subprojects

Why it matters:

- this repo is a strong platform-layer source
- it encodes stack names, base clusters, IAM stack references, regions, and environment-specific infra settings
- it is likely the platform bridge between service delivery repos and underlying infra APIs/accounts

Observed gap:

- none of this is represented in a tracked analysis file under `knowledge/repos/infra-cd/`
- there is no normalized mapping for:
  - project -> environment -> cluster/platform target
  - source-of-truth boundaries
  - downstream repos or services affected

Assessment:

- enough source evidence to analyze manually
- not enough structured KB output to analyze efficiently

### 4. aws-shared-cd

Current source evidence:

- `readme.md` documents branch-to-environment behavior:
  - `main` for dev
  - `release-*` for staging
  - prod is partly documented as TBD in the README, but prod stack files exist
- `pool/lib/env.ts` formalizes valid environments: `dev`, `staging`, `prod`
- many `Pulumi.*.yaml` files exist under `pool/eks-freetier/` and `pool/ack-freetier/`
- stack files carry region, env, namespace, hosted-zone, and image/runtime infra configuration

Why it matters:

- this repo models environment and regional deployment topology directly
- it provides strong evidence for platform and environment boundaries
- it likely controls a major part of runtime placement for shared/serverless infrastructure

Observed gap:

- no tracked deployment-topology artifact in the KB
- no normalized mapping from stack file -> environment -> region -> runtime service groups
- branch/environment behavior is documented, but not formalized in tracked output

Assessment:

- strong platform-environment evidence in source
- poor KB joinability

### 5. app-delivery

Current source evidence:

- `README.md` defines the deployment model: ArgoCD + Kustomize overlays by environment and region
- `root-app.yaml` points ArgoCD at `app-registry`
- `app-registry/*.yaml` materializes service-to-cluster deployment mapping
- examples:
  - `app-registry/tidb-mgmt-service.yaml`
  - `app-registry/dedicated-global-service.yaml`
- these files map service deployment to:
  - env list
  - cluster name
  - overlay path
  - destination namespace

Why it matters:

- this repo is the clearest deployment join between runtime service names and target clusters/namespaces
- it already contains directly useful links such as:
  - `dedicated-global-service` -> `dev/staging/prod` -> `*-base-us-west-2` -> namespace `tidb-management-service`
  - `tidb-mgmt-service` -> `dev/staging/prod` -> `*-base-us-west-2` -> namespace `tidb-management-service`

Additional config/runtime evidence:

- `dedicated-global-service/envs/dev/config.yaml` contains `configCenterAddr: kubernetes:///config-center.devops:8080`
- `serverless-global-service/envs/dev/oneconfig-eventbus.yaml` defines `ConfigMap` data for `oneconfig-eventbus`

Observed gap:

- these relationships are still only encoded as raw manifests
- there is no tracked KB output that indexes:
  - service -> overlay path
  - service -> cluster
  - service -> namespace
  - service -> config references
  - service -> dependent platform repo

Assessment:

- strongest current deployment-side repo for service-level joins
- still not KB-native enough for efficient cross-module analysis

## Gold Scenario Validation

### Scenario 1

Question:

Can we trace one runtime service to deployment target?

Result: `Yes, manually`

Evidence:

- `tidb-management-service` exists as a scanned runtime repo
- `app-delivery/app-registry/tidb-mgmt-service.yaml` maps it to:
  - `dev-base-us-west-2`
  - `staging-base-us-west-2`
  - `prod-base-us-west-2`
  - namespace `tidb-management-service`

Verdict:

- accurate enough with manual lookup
- not efficient enough because the join is not materialized in KB output

### Scenario 2

Question:

Can we trace config source to runtime consumption?

Result: `Yes, partially and manually`

Evidence:

- `oneconfig/README.md` and `oneconfig/Jenkinsfile` define branch/env/namespace mapping
- `oneconfig/apply.sh` shows config becomes `ConfigMap` named `oneconfig-{dir}`
- `tidb-management-service/utilities/dynamicconfig/loader.go` consumes config through the OneConfig remote provider
- `tidb-management-service/utilities/allowlist/impl.go` also reads remote allow-list config through the same provider

Verdict:

- there is enough evidence to argue a real config delivery chain exists
- consumer-to-config-path mapping is not indexed centrally, so repeated analysis will stay expensive

### Scenario 3

Question:

Can we trace deployment structure to environment topology?

Result: `Yes, partially and manually`

Evidence:

- `aws-shared-cd/readme.md` documents branch/environment behavior
- `aws-shared-cd/pool/lib/env.ts` formalizes environment values
- stack files under `pool/*/Pulumi.*.yaml` encode region and environment
- `infra-cd/projects/*/Pulumi.{dev,staging,prod}.yaml` encode infra platform topology

Verdict:

- source evidence is sufficient for manual reconstruction
- no tracked topology artifact currently exists in KB

## Key Conclusion

The main problem is not lack of information.

The main problem is lack of structured, tracked, joinable outputs for deployment and configuration repositories.

Today the KB is strongest at:

- runtime interface discovery
- runtime method dependency mapping

Today the KB is weakest at:

- config-source indexing
- deployment topology indexing
- service-to-cluster mapping as first-class KB data
- cross-repo joins expressed as tracked artifacts

## Minimum Work Required

To make important-repo analysis genuinely efficient and accurate, the next minimum deliverables should be:

1. A standardized repo-level analysis artifact for `deployment_config` repositories.
2. A tracked index for `oneconfig`:
   - branch -> env -> namespace
   - config dir -> configmap name
   - likely consumer repos/services
3. A tracked index for `app-delivery`:
   - service -> applicationset
   - service -> envs
   - service -> cluster
   - service -> namespace
   - service -> overlay path
4. A tracked index for `infra-cd` and `aws-shared-cd`:
   - project/stack -> env
   - project/stack -> region
   - project/stack -> cluster/platform boundary
   - project/stack -> downstream service classes
5. A cross-repo join layer linking:
   - runtime binary/service names
   - app-delivery service directories
   - oneconfig config groups
   - infra/platform stack ownership

## Recommended Next Step

Do not rescan more runtime repos first.

Instead, build the missing deployment/config analysis outputs for:

1. `oneconfig`
2. `app-delivery`
3. `infra-cd`
4. `aws-shared-cd`

Only after those outputs exist should we revisit the full question of cross-module analysis readiness.