App Hub、Cloud Hub、FinOps 统一数据模型

版本：0.1 草稿 · 日期：2026-10-18 · 状态：待用户评审，不代表已实现。

0. 结论

三个视图共用一套事实：GitOps 声明（期望状态）、Terraform state（受管范围）和 Shared CMDB 观察（运行事实）三方对账后，形成同一个资源主键 canonical_id 和同一组标签 app / env / owner / tier。Cloud Hub 沿 provider → account/project → region → network → resource 往下钻取，App Hub 沿 app → service → workload → environment 往上聚合，FinOps 把按 account 进来的账单经同一主键和标签分摊到 app/env。各云原生的 App Hub 或资源中心只做单向输出适配器，不回读成事实。

现有基础比预想的多：CMDB PostgreSQL v1 schema（resources、desired_resources、resource_relations、collection_runs 等）已在 Playbooks 仓库落地，并有 UAT 按需入库证据；GitOps 有 CMDBCollectionScope，并把无只读身份的 provider 显式列为 pending。缺的部分：统一标签（现在只有 GCP 资源带 owner/workload/environment labels，而且 owner 的语义与本方案不同）、应用实体、PoP/配额实体、成本归属，以及定时对账 job。产品页 /products/cloud-hub 的数字目前看是静态数据，接入本模型之前不能当作实测状态。

1. 范围与证据边界

1.1 范围

本文只是设计稿：不创建 Vault 记录、policy、云 IAM、数据库对象或 workflow；文中 YAML/SQL 都是草案，路径与字段都要经评审后才能进入 owner 仓库。

1.2 证据来源与固定版本

1.3 标注约定

• 分类：已有＝白皮书或仓库里有同名、同义的定义，并能引用出处；扩展＝已有定义，但需要增加字段或范围；新增＝源文件和仓库里都找不到。
• 实现状态：沿用 [PE] 1.3 的证据等级。已实现(UAT)＝有白皮书记载的真实运行证据；源码/CI＝代码或合同存在，没有 live 验收；规划＝只在文档中；待验收＝已落地但缺验收；待核验＝本文无法判断。
• 有出处的说法写成“[来源] 章节”；仓库文件写成相对路径。

1.4 本次核对得到的关键现状

1. CMDB PG v1 已有表结构：playbooks/contracts/cmdb-postgresql-v1/migrations/001_initial_schema.sql 定义了 collection_runs、resources、raw_snapshots、resource_observations、desired_resources、resource_relations、monitoring_status 和 6 个视图，与 [CMDB] 4.1 一致。[CMDB] 12 记录 2026-10-09 Shared 主机上的 UAT cmdb 已完成迁移、GCP 入库和 Grafana 只读验证；定时采集未启用。
2. pending 已有声明先例：gitops/topology/shared/cmdb/observability-uat.yaml（kind: CMDBCollectionScope）启用了 GCP 的 compute/cloudrun collector；pending_providers 列出 aws、linode、ucloud、cloudflare、supabase。vultr、hetzner、contabo 不在列表内。
3. 标签现状：只有 GCP 资源声明带 labels，键为 owner（值是 platform-ops-toolkit，即管理工具）、workload、environment、lifecycle。Vultr/Akamai 声明用的是无键的 tags: [web-saas, prod, ...] 列表。tier 只在 GlobalMeshPools.metadata.labels 出现过，取值 out-of-band-network。监控 Vector 模板打的标签是 instance/job/provider/project_id/logical_project/environment/env/service_domain，没有 app。
4. 已有一套 FinOps 标签与分摊规划：billing-service 的 open-platform-finops-control-plane.md 中，FINOPS-003 定义了 managed_by/repository/service/product/team/environment/cost_center/owner，FINOPS-603 定义了 Unallocated/Untagged/Unknown Resource/Shared Platform。该文档自己把分摊引擎标为 🔴 Phase 2。
5. 产品页数据像是静态的：global-mesh 仓库 telemetry_snapshots 表的字符串默认值（如 '225.58k'、'↗ 26.1%'）与页面显示一致；sync_vps_regions.py 里 sync_time 是硬编码的，hetzner/ucloud/contabo 的数量也是常量。GitOps PROD GlobalMeshPools 声明了 41 个 provider-region，页面写的是 48 个 PoP。
6. Observability 栈：仓库 README 写的是 VictoriaMetrics/VictoriaLogs/VictoriaTraces + OpenTelemetry Collector + Grafana，并非 Prometheus + Loki。产品页上 Hetzner 节点文案写着 “Telemetry Hub (Loki/Prom)”，与仓库不一致（见 §6 Q09）。

2. 统一实体模型

2.1 实体关系总览

erDiagram
  PROVIDER ||--o{ CLOUD_ACCOUNT : has
  PROVIDER ||--o{ REGION : offers
  REGION ||--o{ POP : hosts
  CLOUD_ACCOUNT ||--o{ QUOTA : limits
  CLOUD_ACCOUNT ||--o{ RESOURCE : owns
  REGION ||--o{ RESOURCE : locates
  RESOURCE ||--o{ RESOURCE_RELATION : links
  RESOURCE ||--o{ RESOURCE_LABEL : carries
  RESOURCE ||--o| DESIRED_RESOURCE : reconciles
  APP ||--o{ APP_SERVICE : contains
  APP_SERVICE ||--o{ APP_WORKLOAD : runs_as
  APP_WORKLOAD ||--o{ WORKLOAD_BINDING : bound_by
  WORKLOAD_BINDING }o--|| RESOURCE : targets
  CLOUD_ACCOUNT ||--o{ COST_LINE_ITEM : bills
  COST_LINE_ITEM ||--o{ COST_ALLOCATION : splits_to
  COST_ALLOCATION }o--o| APP : attributes
  RECONCILE_RUN ||--o{ WORKLOAD_BINDING : produces
  COLLECTION_RUN ||--o{ RESOURCE : observes

2.2 实体清单

2.3 主键与标识规则

1. 资源身份只认 CMDB 的 canonical_id。它由 cmdb_observations_v1.py 根据 provider/account/project/kind/native ID 派生，名称和 IP 都不是身份（[CMDB] 4.1、[IAM] 10）。
2. GitOps 侧的 resource_key 沿用 Toolkit resource-aggregation-model.md 的写法 <project>/<env>/<provider>/<declaration>（例：svc.plus/uat/akamai/open-platform）。
3. App 侧的键全部用小写加连字符（遵循 [PE] 8.5.2 第 6 条）。app 的值优先沿用现有的 labels.workload 和 ResourceMatrix.resources[].target_domain（如 web-saas、ai-workspace、agent-proxy-jp，见 §6 Q02 中关于区域后缀的问题）。
4. scope 记录资源实际归属；采集运行在 Shared 上执行，并不把资源改记为 shared（[IAM] 3）。
5. 跨环境共用的资源用 resource_relations 表示，不复制成多条资源（[IAM] 3）。

2.4 统一标签规范（新增，需评审）

规则：

• 标签写在 GitOps 声明的 labels（GCP）或 provider 适配后的等价字段上，由 IaC renderer 下发到云资源。provider 不支持键值标签时，IaC adapter 负责编码，具体方式待核验。
• CMDB 观察到的标签以 source=provider_api 写入 resource_labels，声明中的标签以 source=gitops_declared 写入；两者不一致时记为 drifted。
• 缺少 app 或 env 的资源进入“未归属”（§3.3），不按名称猜测。按规则推断的结果必须标 source=inferred_rule 并单独展示。
• 本表只是标签规范的草案，不替代 FINOPS-003。两套键如何合并，见 §6 Q01。

2.5 GitOps 侧示例 YAML（草案）

格式遵循 gitops/docs/gitops-declaration-standard.md：单文档、apiVersion/kind/metadata{name,project,environment}/spec，只用 YAML，不含秘密。拟放在 topology/shared/hub/，先例是 topology/shared/cmdb/；路径待决，见 §6 Q12。

# topology/shared/hub/app-catalog.yaml（草案，新增 kind）
apiVersion: gitops.svc.plus/v1alpha1
kind: ApplicationCatalog
metadata:
  name: svc-plus-apps
  project: svc.plus
  environment: shared
spec:
  label_keys: [app, env, owner, tier]
  apps:
    - app: web-saas
      owner: platform            # 团队标识，非个人
      lifecycle: persistent
      services:
        - service: console
          tier: edge
        - service: accounts
          tier: control
        - service: billing
          tier: control
        - service: postgresql
          tier: data
      workloads:
        - env: uat
          runtime_mode: selfhost
          resource_refs:
            - resources/<project>/uat/gcp/web-saas.yaml
          compose_ref: compose/web-saas/docker-compose.yml
        - env: prod
          runtime_mode: serverless
          topology_ref: topology/prod/serverless/runtime-topology.yaml
    - app: observability
      owner: platform
      lifecycle: persistent
      services:
        - service: observability-server
          tier: platform
      workloads:
        - env: shared
          runtime_mode: selfhost
          resource_refs:
            - resources/<project>/shared/gcp/<observability-declaration>.yaml

# topology/shared/hub/provider-accounts.yaml（草案，新增 kind；ID 一律用占位符）
apiVersion: gitops.svc.plus/v1alpha1
kind: ProviderAccountCatalog
metadata:
  name: svc-plus-provider-accounts
  project: svc.plus
  environment: shared
spec:
  providers:
    - provider: gcp
      provider_class: iaas
      terraform_tree: gcp-cloud
      accounts:
        - account_ref: "<gcp-account-ref>"
          project_ref: "<gcp-project-id>"
          scope: prod
          identity_ref: kv/prod/svc.plus/cloud/gcp/<gcp-project-id>/federation/cmdb-readonly
          identity_status: pending_verification
          cost_source: pending
    - provider: hetzner
      provider_class: vps
      terraform_tree: null       # 当前无 Terraform tree / 无身份合同
      accounts: []
      coverage_status: pending
      reason: account-and-readonly-identity-pending

# 现有 resources/<project>/<env>/gcp/*.yaml 的 labels 扩展（片段）
labels:
  app: web-saas            # 由现有 workload 迁移
  env: prod                # 由现有 environment 迁移
  owner: platform          # 语义改为责任团队
  tier: data
  managed_by: platform-ops-toolkit   # 承接原 owner 的语义（待决）
  lifecycle: persistent

CMDBCollectionScope 的扩展点：在 pending_providers 中补上 vultr、hetzner、contabo；给每个 collector 增加 quota 与 labels 两个采集产品。这两项为新增 kind 能力，需要 IaC collector 支持后才能启用。

2.6 CMDB 侧 PG 表结构草案（003_hub_model.sql）

本草案只做追加（additive），沿用 001 的约定：SET LOCAL ROLE cmdb_owner、CHECK 枚举、writer 只拿指定表的 SELECT/INSERT/UPDATE、reader 只读视图、没有 down 迁移。未经评审不能放进 contracts/cmdb-postgresql-v1/migrations/。

BEGIN;
SET LOCAL ROLE cmdb_owner;
SET LOCAL search_path = cmdb, pg_catalog;

CREATE TABLE IF NOT EXISTS provider_catalog (
    provider text PRIMARY KEY CHECK (provider ~ '^[a-z0-9-]+$'),
    provider_class text NOT NULL CHECK (provider_class IN
        ('iaas','vps','edge','serverless','managed_database','existing_inventory')),
    terraform_tree text,
    coverage_status text NOT NULL DEFAULT 'pending' CHECK (coverage_status IN
        ('enabled','pending','unsupported','pending_verification')),
    gitops_ref text NOT NULL,
    updated_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE IF NOT EXISTS cloud_accounts (
    provider text NOT NULL REFERENCES provider_catalog(provider),
    account_ref text NOT NULL,
    project_ref text NOT NULL DEFAULT '',
    scope text NOT NULL CHECK (scope IN ('shared','sit','uat','prod','unknown')),
    identity_ref text,                  -- 逻辑 KV 路径引用，非秘密
    identity_status text NOT NULL DEFAULT 'pending' CHECK (identity_status IN
        ('verified','pending','unsupported','pending_verification')),
    cost_source text NOT NULL DEFAULT 'pending' CHECK (cost_source IN
        ('billing_api','billing_export','price_book','none','pending')),
    gitops_ref text NOT NULL,
    PRIMARY KEY (provider, account_ref, project_ref)
);

CREATE TABLE IF NOT EXISTS regions (
    provider text NOT NULL REFERENCES provider_catalog(provider),
    region_ref text NOT NULL,
    country_code text,
    source text NOT NULL CHECK (source IN ('provider_api','gitops_declared','external_inventory')),
    PRIMARY KEY (provider, region_ref)
);

CREATE TABLE IF NOT EXISTS pops (
    pop_id text PRIMARY KEY,
    provider text NOT NULL,
    region_ref text NOT NULL,
    role text,
    source text NOT NULL CHECK (source IN ('gitops_declared','provider_api','external_inventory')),
    gitops_ref text,
    FOREIGN KEY (provider, region_ref) REFERENCES regions(provider, region_ref)
);

CREATE TABLE IF NOT EXISTS quotas (
    provider text NOT NULL,
    account_ref text NOT NULL,
    project_ref text NOT NULL DEFAULT '',
    region_ref text NOT NULL DEFAULT '',
    quota_kind text NOT NULL,
    limit_value numeric,
    used_value numeric,
    run_id text NOT NULL REFERENCES collection_runs(run_id),
    observed_at timestamptz NOT NULL,
    PRIMARY KEY (provider, account_ref, project_ref, region_ref, quota_kind, run_id),
    FOREIGN KEY (provider, account_ref, project_ref)
        REFERENCES cloud_accounts(provider, account_ref, project_ref)
);

CREATE TABLE IF NOT EXISTS resource_labels (
    canonical_id text NOT NULL REFERENCES resources(canonical_id),
    label_key text NOT NULL CHECK (label_key IN ('app','env','owner','tier')),
    label_value text NOT NULL CHECK (label_value ~ '^[a-z0-9-]+$'),
    source text NOT NULL CHECK (source IN ('provider_api','gitops_declared','inferred_rule')),
    run_id text NOT NULL,
    observed_at timestamptz NOT NULL,
    PRIMARY KEY (canonical_id, label_key, source)
);

CREATE TABLE IF NOT EXISTS apps (
    app_key text PRIMARY KEY,           -- <project>/<app>
    project text NOT NULL,
    app text NOT NULL,
    owner text NOT NULL,
    lifecycle text NOT NULL,
    gitops_ref text NOT NULL
);

CREATE TABLE IF NOT EXISTS app_services (
    service_key text PRIMARY KEY,       -- <app_key>/<service>
    app_key text NOT NULL REFERENCES apps(app_key),
    service text NOT NULL,
    tier text NOT NULL CHECK (tier IN ('client','edge','control','compute','data','platform'))
);

CREATE TABLE IF NOT EXISTS app_workloads (
    workload_key text PRIMARY KEY,      -- <service_key>@<env>/<workload>
    service_key text NOT NULL REFERENCES app_services(service_key),
    env text NOT NULL CHECK (env IN ('shared','sit','uat','prod')),
    runtime_mode text NOT NULL CHECK (runtime_mode IN ('selfhost','serverless','hybrid','existing')),
    gitops_path text NOT NULL
);

CREATE TABLE IF NOT EXISTS reconcile_runs (
    run_id text PRIMARY KEY,
    kind text NOT NULL CHECK (kind IN ('cloud_hub','app_hub','finops','export')),
    gitops_sha text NOT NULL,
    iac_sha text,
    toolkit_sha text NOT NULL,
    inputs_sha256 text NOT NULL,
    started_at timestamptz NOT NULL,
    completed_at timestamptz,
    outcome text NOT NULL CHECK (outcome IN ('running','success','partial','failed')),
    receipt jsonb NOT NULL DEFAULT '{}'::jsonb
);

CREATE TABLE IF NOT EXISTS workload_bindings (
    workload_key text NOT NULL REFERENCES app_workloads(workload_key),
    canonical_id text NOT NULL REFERENCES resources(canonical_id),
    binding_source text NOT NULL CHECK (binding_source IN ('label_match','gitops_declared','relation')),
    match_state text NOT NULL CHECK (match_state IN ('matched','drifted','declared_only','observed_only')),
    reconcile_run_id text NOT NULL REFERENCES reconcile_runs(run_id),
    PRIMARY KEY (workload_key, canonical_id)
);

-- 覆盖状态：无身份 provider 显示 pending，不显示为成功零资源
CREATE OR REPLACE VIEW v_cloud_hub_coverage AS
SELECT a.provider, a.account_ref, a.project_ref, a.scope,
       CASE WHEN p.coverage_status <> 'enabled' OR a.identity_status <> 'verified' THEN 'pending'
            WHEN lr.outcome IS NULL THEN 'never_observed'
            WHEN lr.outcome = 'failed' THEN 'failed'
            WHEN lr.outcome = 'partial' OR NOT lr.scope_complete THEN 'partial'
            WHEN lr.completed_at < now() - interval '15 minutes' THEN 'stale'
            ELSE 'complete' END AS coverage,
       lr.completed_at AS last_complete_at
FROM cloud_accounts a
JOIN provider_catalog p USING (provider)
LEFT JOIN LATERAL (
    SELECT outcome, scope_complete, completed_at FROM collection_runs c
    WHERE c.account_ref = a.account_ref AND c.project_ref = a.project_ref
    ORDER BY started_at DESC LIMIT 1) lr ON true;

CREATE OR REPLACE VIEW v_unattributed_resources AS
SELECT r.canonical_id, r.provider, r.account_ref, r.project_ref, r.scope, r.resource_kind,
       CASE WHEN NOT EXISTS (SELECT 1 FROM resource_labels l
                             WHERE l.canonical_id = r.canonical_id AND l.label_key = 'app'
                               AND l.source <> 'inferred_rule') THEN 'untagged'
            ELSE 'unknown_app' END AS reason
FROM resources r
WHERE r.lifecycle = 'present'
  AND NOT EXISTS (SELECT 1 FROM workload_bindings b
                  WHERE b.canonical_id = r.canonical_id AND b.match_state = 'matched');

INSERT INTO schema_migrations (version, description)
VALUES ('003', 'Hub model: providers, accounts, regions, PoPs, quotas, labels, apps, bindings')
ON CONFLICT (version) DO NOTHING;
COMMIT;

授权沿用 001：cmdb_writer 对新表有 SELECT/INSERT/UPDATE；cmdb_reader 只读 v_cloud_hub_coverage、v_unattributed_resources 以及后续的 App/FinOps 视图；cmdb_auditor 读 reconcile_runs 的脱敏视图（[IAM] 9.4）。

FinOps 表（cost_line_items、cost_allocations）放在哪个数据库是待决项（§6 Q07），这里只列字段要点：

• cost_line_items：provider, account_ref, project_ref, charge_period_start/end, service_name, sku, native_resource_id NULL, region, billed_cost numeric(20,6), effective_cost numeric(20,6), currency, cost_role ∈ {authoritative, adjustment, estimated}, source ∈ {billing_api, billing_export, price_book}, source_run_id, tags jsonb。成本角色引用 FINOPS-601；金额用 numeric，不用现有 cloud_vendor_costs.cost_amount 的 DOUBLE PRECISION（见 Q08）。
• cost_allocations：line_id, bucket ∈ {attributed, untagged, unknown_resource, shared_platform, unallocated, pending_provider}, app_key NULL, env NULL, allocated_cost, rule_ref, reconcile_run_id。bucket 前五类对齐 FINOPS-603；pending_provider 是新增，用来表示“无身份/无账单来源”，与“已知为 0”区分。

3. 三个视图

3.1 Cloud Hub

要回答的问题：我们在哪些 provider/account/region 有资源？每个范围的采集是否完整、新鲜？配额还剩多少？PoP 的实测状态如何？哪些 provider 仍是 pending？

数据来源：

计算/对账逻辑：

1. 覆盖状态按 v_cloud_hub_coverage 计算：provider 未启用或身份未 verified → pending；最近一次 run 为 failed/partial → 照实展示；完整成功但超过 freshness（[CMDB] 6：15 分钟）→ stale。
2. 资源计数只统计 lifecycle='present' 的资源（002 已在 v_provider_summary 中这样做）。Compute 计实例数，Serverless 计服务数，revision 不计入（[CMDB] 5）。
3. 删除只能走 missing_candidate → deletion_confirmed（[CMDB] 6），对账 job 不能直接删除。
4. 三方差异：同时在 GitOps 声明、cmdb.json/state、provider 观察中出现 → matched；只在声明中 → declared_only；只在观察中 → observed_only；属性不一致 → drifted（[CMDB] 6，写回 desired_resources.observed_match）。
5. “上次同步”显示 max(collection_runs.completed_at)，按 provider 分别展示，不能用一个全局时间戳。

与产品页现有模块的对应：

3.2 App Hub

要回答的问题：某个 app 由哪些 service/workload 组成？每个环境跑在哪些云资源上？声明与实际是否一致？健康状况如何？哪些资源不属于任何 app？

数据来源：GitOps ApplicationCatalog（新增）、resources/ 中的 labels、topology/<env>/<mode>/runtime-topology.yaml（EdgeRoutingConfig）、compose/ + .doco-cd.*.yml（当前实际部署路径；services/ 是未启用的 K8s/Flux 路线，见 services/README.md）、releases/（SelfhostRelease）、CMDB resources/resource_labels/resource_relations、Observability 指标。

计算/对账逻辑：

1. 绑定优先级：gitops_declared（catalog 中的 resource_refs 解析出 resource_key → desired_resources.canonical_id）> label_match（观察到的 app+env 标签对应唯一 workload）> relation（经 resource_relations 继承，例如数据盘 → VM）。
2. 声明绑定与标签绑定指向不同 workload 时记为 drifted，不自动改写任何一方。
3. 健康状态不在 CMDB 内计算。Observability 按 app/env 标签聚合（需要先在 Vector 模板中加入 app 标签，属新增），CMDB 只保存 monitoring_status（已有表）。容器 running 不算健康（[PE] 6.1）。
4. Serverless workload 用产品指标和健康检查回执，不报“缺少主机探针”告警（[CMDB] 8）。
5. 环境混用的情况照实展示，不以声明为准做“修正”。例如 [PE] 11.9（2026-10-14）记录 web-saas-uat 主机读取 .env.prod：App Hub 应把这类 workload 标为 drifted。

与产品页现有模块的对应：“应用架构拓扑”的五层（端-边-控-算-数）对应 tier，节点是 app_services，连线来自 resource_relations 和 EdgeRoutingConfig 的 upstream。“工程生命周期”对应 releases/ + Toolkit 回执，本模型只给出关联键（app_key、tag/digest、run ID），不重建发布证据链（[PE] 10.1）。

3.3 FinOps

要回答的问题：每个 account 本期花了多少？其中多少能归到 app/env？未归属的有多少、为什么？哪些 provider 没有账单来源（pending）？

数据来源：

计算/对账逻辑：

1. 账单先落到 CloudAccount 下（provider, account_ref, project_ref），对不上账号的行进入 unknown_resource，不丢弃。
2. 有 native_resource_id 的行，经 resources 找到 canonical_id，再经 workload_bindings(matched) 或 resource_labels(app, env) 归到 app/env → attributed。
3. 资源存在但没有 app 标签 → untagged；资源属于 Shared 平台（如 observability、vault）→ shared_platform，二次分摊规则留待后续决定（FINOPS-602）；账单只有账号/服务级、没有资源 ID → unallocated。
4. provider 没有身份或没有账单来源 → pending_provider，金额显示“未知”，不显示 0。
5. 总成本只计 authoritative + adjustment；allocated 不重复求和；estimated 只用于对比（FINOPS-601）。
6. Free tier 抵扣、共享额度按 billing account / organization 计（[PE] 7.2.2），不能按环境重复计算。

与产品页现有模块的对应：公开页没有 FinOps 模块；[GM] 3.2 的“FinOps 混合多云成本对账”表是方案对比的估算，不是账单数据，不能作为本视图的数据。/panel/finops 未看到，暂不映射。

3.4 三档权限在三个视图中的落地

沿用 [IAM] 2.1/2.4 的 reader/operator/admin，三层分别授权、不继承：

collector 是云账号层 reader + CMDB 服务层 operator 特化（cmdb_writer），不是 OS operator（[IAM] 2.4）。输出适配器需要写入目标云的 App Hub，必须单独设置写身份，不能复用 collector 的只读身份（见 Q10）。

3.5 统一状态语义（三视图一致）

4. 对账与同步流程

flowchart LR
  subgraph SRC[事实输入]
    G[GitOps 固定 SHA<br/>catalog / resources / topology / labels]
    S[IaC cmdb.json<br/>Terraform 受管范围]
    P[Provider 只读 API<br/>cmdb.observations.v1]
    X[external_inventory<br/>带 TTL]
    B[账单 API / export / Price Book]
    M[Observability 指标<br/>按 app/env 聚合]
  end
  G --> R[Toolkit 对账 job<br/>固定 owner SHA]
  S --> R
  P --> I[Playbooks 入库<br/>render_ingest_sql.py] --> DB[(Shared CMDB<br/>schema cmdb)]
  X --> I
  R --> DB
  B --> F[成本归属<br/>落点待决] --> DB
  M -.健康摘要.-> DB
  DB --> V1[Cloud Hub 视图]
  DB --> V2[App Hub 视图]
  DB --> V3[FinOps 视图]
  DB --> E[输出适配器<br/>单向导出]
  E --> GA[各云原生 App Hub / 资源中心]
  GA --- NB[禁止回读为事实]

sequenceDiagram
  participant T as Toolkit 对账 job
  participant G as GitOps@SHA
  participant C as CMDB (cmdb_writer)
  participant O as 输出适配器
  T->>G: 读取 catalog / resources / labels（缺声明即失败）
  T->>C: 读取最近完整 collection_runs 与 resources
  T->>T: 计算 desired↔observed↔state 匹配与 bindings
  T->>C: 事务写入 reconcile_runs / workload_bindings / desired_resources.observed_match
  T->>C: 写入成本归属（若该阶段启用）
  T-->>T: 生成脱敏 receipt（SHA、输入 hash、计数）
  O->>C: 只读 matched 绑定
  O->>O: 渲染目标云 App Hub 结构（不含秘密）
  O-->>C: 写 export receipt（成功/失败），不回写资源事实

对账规则：

1. 输入固定：GitOps/IaC/Playbooks/Toolkit 都使用固定 SHA；缺少声明、SHA 不匹配、目标被 inputs 覆盖时直接失败（[PIPE] 4.1、[PE] 2 原则 6）。
2. 只用完整范围：对账只消费 scope_complete = true 的 run；partial 或 failed 范围保留旧绑定，并标记 stale（[CMDB] 4.2）。
3. 幂等：同一 inputs_sha256 重放结果不变；旧 run 不能覆盖新 run（[CMDB] 4.2、[IAM] 10）。
4. 单向：输出适配器只读 CMDB；目标云 App Hub 里的人工改动不回流，下次导出会被覆盖或报告冲突（导出语义待决）。
5. 禁止副作用：对账 job 不执行 Terraform apply、DNS、SSH、探针安装，也不加载 backend 凭据（[IAM] 4.2）。
6. 回执分离：采集 receipt、入库 receipt、对账 receipt、导出 receipt 各自独立，用 correlation ID 关联（[IAM] 10）。
7. 调度：在 Toolkit 中新增一个 workflow，或复用 [CMDB] 9 拟议的 DAG validate-scope → collect → normalize-and-commit → verify-receipt → publish，在其后追加 reconcile → export；Toolkit 现有 workflow 目录中没有对账或采集入口（新增）。

5. 总对照表

计数：共 37 项，其中已有 17 项、扩展 11 项、新增 9 项。“已有”只表示有出处，不等于已实现，实现状态见最后一列。

6. 与白皮书冲突或待决问题

7. 分阶段实施建议

推进顺序遵循 [PE] 12.2：owner 先落地 → caller 切换 → UAT 验证 → 清理旧路径 → 归并文档。任何一步缺少 receipt 都不进入下一步。H1 之前不改任何云资源；H3 之前，产品页上的静态数字应标注“演示数据”（需用户确认）。