docs: record v02 cicd performance measurements

docs/reference/g14-cicd-performance.md

@@ -1,6 +1,6 @@
 # G14 CI/CD 性能分析
 
-本文是 HWLAB G14 CI/CD 性能优化的长期参考，覆盖 `G14` source branch、Tekton PipelineRun、per-service BuildKit 镜像发布、`G14-gitops` promotion、Argo CD sync 和 DEV runtime health。D601 legacy CI/CD、Code Queue runner 和 host 侧临时构建路径不属于本文范围。
+本文是 HWLAB G14 CI/CD 性能优化的长期参考，覆盖 `G14` source branch、`v0.2` 加法 lane、Tekton PipelineRun、per-service BuildKit 镜像发布、GitOps promotion、Argo CD sync 和 runtime health。D601 legacy CI/CD、Code Queue runner 和 host 侧临时构建路径不属于本文范围。
 
 ## 性能模型
 
@@ -32,7 +32,24 @@ G14 Tekton 日志中的分段耗时统一使用 JSON 行事件：`event="g14-cic
 
 ## 当前基线
 
-当前 G14 pipeline 已具备关键架构优化：一分钟 source polling、组件级 lazy build、per-service fan-out、G14 本地 registry、本地 base image、BuildKit-only publish、GitOps/Argo 分离。剩余耗时主要集中在固定开销和镜像构建机制上。
+当前 G14 pipeline 已具备关键架构优化：一分钟 source polling、组件级 lazy build、per-service fan-out、G14 本地 registry、本地 base image、BuildKit-only publish、GitOps/Argo 分离。`v0.2` 进一步引入手动 CLI trigger、`devops-infra` git mirror 只读路径、env image 复用和 code-only boot commit rollout。剩余耗时主要集中在固定开销、GitOps promotion、runtime-ready 等待和镜像构建机制上。
+
+## v0.2 实测对比
+
+以下对比来自 G14 k3s 内 Tekton `PipelineRun`/`TaskRun` 真实对象与 prepare-source JSON timing。按成功样本分组统计，失败样本只用于诊断，不纳入端到端成功基线。`git mirror` 纯读性能用同一 CI tools image 的临时 pod 在集群内测量。
+
+| 场景 | 成功样本 | PipelineRun P50 | `prepare-source` P50 | build wall P50 | 说明 |
+| --- | ---: | ---: | ---: | ---: | --- |
+| `G14` legacy full build，无 mirror | 8 | 512s | 114s | 23s | 14 个 build task，runtime-ready P50 约 249s。 |
+| `v0.2` pre-mirror 9-build | 27 | 391s | 92s | 92s | 9 个保留服务 build task，GitHub/GitOps 读路径仍混在 prepare 阶段。 |
+| `v0.2` mirror 9-build | 1 | 277s | 51s | 75s | source clone 走 mirror，样本量低，只作为趋势样本。 |
+| `v0.2` env-reuse code-only/no-build | 3 | 172s | 49s | 0s | 8 个 task 成功、9 个 build branch skipped；只更新 boot commit/code identity。 |
+
+同口径 P50 加速效果：`v0.2` pre-mirror 9-build 到 env-reuse code-only 约 `2.27x`；`v0.2` mirror 9-build 到 env-reuse code-only 约 `1.61x`；`G14` legacy full build 到 `v0.2` env-reuse code-only 约 `2.98x`。这些倍率只描述已观测的运行类型，不外推到 DB migration、Secret 变更或 runtime 架构变更。
+
+git mirror 本身不是 50 秒级瓶颈。集群内临时 pod 对 `http://git-mirror-http.devops-infra.svc.cluster.local/pikasTech/HWLAB.git` 的实测结果为：`git ls-remote refs/heads/v0.2` P50 约 19ms，`git clone --no-checkout` P50 约 787ms，`git checkout --detach` P50 约 64ms。Tekton `prepare-source` 的 48-65s wall time 是混合耗时，包含 entrypoint/PVC/workspace 启动、proxy/npm probe、source clone、GitOps catalog 读取、`npm ci` 和脚本收尾，不能直接归因给 mirror。
+
+已观测的 prepare-source 内部分段：source clone 经 mirror 后约 0.9-1.1s；GitOps catalog 读取若仍走 canonical GitHub SSH 约 9s；`npm ci --ignore-scripts` 约 15-18s；剩余为 Tekton entrypoint、PVC/workspace、探针和 shell/Node 启动固定开销。只读 catalog lookup/fetch 应与 source clone 一样走 `git-read-url` mirror；GitOps promotion push 仍必须走 canonical GitHub remote。
 
 当前滚动基线量级：