docs(ql3): record exact cutover alpha milestone

docs/QINGLONG_3_0_ARCHITECTURE_RFC.md

@@ -1,8 +1,10 @@
 # QingLong 3.0 Architecture RFC
 
-- D-426b2a/ADR-0523（源码候选，尚未形成新阶段实物）：修复 D-426b 的真实架构矛盾：受认证 `local-data-directory.adoption.apply` 必然在 target 启动前改变 activation 中记录的 SQLite 内容摘要，因此旧 classifier 会把“apply 后未产生任何 target 写入”的合法停止错误判为 `reconciliation_required`。现仅为 `docker-target` adopted Application v4 发布 no-replace 私有 `service/adopted-target-baseline.json`，绑定 activation/legacy commitment、Application semantic digest、data application commit/receipt、target path/device/inode/SHA-256 和 sidecar-clear 事实；v4 target start/stop 必须闭合该基线，缺失或漂移进入 `manual_review`，启动后写入进入 `reconciliation_required`，未写入才得到 `rollback_candidate`。v3/fresh 与历史 journal shape/activation 语义保持不变；新停止证据同时保留真实 `targetMatchesActivation` 并增加 `baselineKind/baselineDigest/targetMatchesBaseline`。Local Owner CLI 完整包级门为 `308 total / 301 pass / 7 conditional skip / 0 fail`。没有新增 workspace package、依赖、daemon、listener、timer、watcher 或稳态资源。本切片仍不能冒充 D-426b2 阶段包：必须等 exact 上传 bundle 实跑 reviewed stage、transform/verify、Owner 强认证 apply/verify、真实 legacy stop、target start/stop 与 clean rollback，再生成同源双架构 artifact；当前可交付升级实物仍是 D-426a。
+- D-426b2b/ADR-0524（已交付同源双架构 headless Alpha 阶段实物）：exact 上传 Trial Kit 已把 D-426b1 的离线 image authority 与 D-426b2a 的 post-apply baseline 接入完整用户切换链。真实 artifact 预演暴露出普通 Application 启动会在 scheduler/recovery 激活期间改变 adopted SQLite，因而不能同时充当“未接收写入”的 clean rollback 证明；3.0 没有放宽 classifier 或重置基线，而是新增显式 `--cutover-probe` 进程，只加载 exact v4 config、验证 legacy/data-application/cutover commitment、以只读 SQLite readiness 打开 target、在数据库外发布 process-bound start/stop receipt，并保持 recovery、plugin recovery、execution、scheduler 和 product admission 全部冻结。Owner target evidence 固定要求 `['--cutover-probe','--config',expectedPath]`，普通 Application 命令不能冒充 probe；依赖审计只允许该 production-process 文件导入只读 readiness subpath，仍拒绝 writable runtime。提交 `79045a0d439074994812d9cd682f933b9e415706` 的显式 Local headless [run 33326143744](https://github.com/whyour/qinglong/actions/runs/33326143744) 为 `42 success / 2 expected scope skip / 0 fail`，两个原生架构均在 exact bundle 上完成 readiness、reviewed stage、Owner credential presentation、transform/apply、真实 legacy stop、probe start/stop 和 clean `rollback_candidate`，finalizer 生成 milestone v5。amd64/arm64/milestone artifact ID 为 `9736356778`/`9736354298`/`9736502478`，GitHub 压缩大小为 `226206170`/`221605850`/`6492` bytes，保留至 2026-09-29；下载后三个仓库离线 auditor 均返回 `compatible=true`。内部 Docker archive digest 为 amd64 `sha256:1e1c5c83fd2c39b3bbe7b194113998a96cbe810e69d34858c3f40d2638837c60`、arm64 `sha256:dcec37f65382d7d8c06f448780878ec2474e45d6e64b2febb764b1836898d2d6`，verification v6 的漏洞、SBOM、128 MiB entrypoint、fresh lifecycle、API cancellation 与 legacy readiness/stage/cutover 全为 `passed`。同 run 的 128 MiB/0.5 CPU/64 PID router stress 记录 x64/arm64 peak `77967360`/`72581120` bytes，但仍明确不是物理设备最低配置承诺。本阶段实物只证明隔离合成数据上的 exact 切换链和“target 未产生业务写入”的 clean rollback candidate；不停止用户真实 2.x、不授权 Legacy restart、写后 reconciliation、生产 cutover、Public Release 或 LTS。
 
-- D-426b1/ADR-0522（源码候选，尚未形成新阶段实物）：D-426a 暴露出真实的离线切换缺口：Trial Kit archive 只有本地 image reference 与 Docker content ID，既有 target barrier 却只接受 registry `name@sha256:...`；伪造 GHCR RepoDigest 或 Alpha release catalog 会污染正式发布权威。现统一引入 `{authority,reference,imageId}` target image identity，正式部署保持 `registry-digest`，离线 Trial Kit 使用 `local-image-id`，两者都同时核对容器 `Config.Image` 与 `.Image` content ID，并把三项绑定进 cutover journal。adopted bundle 新增 `docker-target` service kind，生成 Application v4 与内容绑定的 `service/docker-target.json`，固定 numeric UID:GID、restart=no、network none、read-only rootfs、drop ALL、no-new-privileges、Profile memory/PID 和 exact read-write/read-only mounts；descriptor 不创建或启动容器。没有新增 package、依赖或稳态进程。该切片只有定向源码测试证据，不能替代已交付的 D-426a 双架构 artifact；必须等 D-426b2 在 exact 上传 bundle 上实跑受认证 transform/apply、target start/stop 和 clean `rollback_candidate`，才允许宣称新阶段产物。
+- D-426b2a/ADR-0523（已由 D-426b2b 双架构阶段实物闭合）：修复 D-426b 的真实架构矛盾：受认证 `local-data-directory.adoption.apply` 必然在 target 启动前改变 activation 中记录的 SQLite 内容摘要，因此旧 classifier 会把“apply 后未产生任何 target 写入”的合法停止错误判为 `reconciliation_required`。现仅为 `docker-target` adopted Application v4 发布 no-replace 私有 `service/adopted-target-baseline.json`，绑定 activation/legacy commitment、Application semantic digest、data application commit/receipt、target path/device/inode/SHA-256 和 sidecar-clear 事实；v4 target start/stop 必须闭合该基线，缺失或漂移进入 `manual_review`，启动后写入进入 `reconciliation_required`，未写入才得到 `rollback_candidate`。v3/fresh 与历史 journal shape/activation 语义保持不变；新停止证据同时保留真实 `targetMatchesActivation` 并增加 `baselineKind/baselineDigest/targetMatchesBaseline`。Local Owner CLI 完整包级门为 `308 total / 301 pass / 7 conditional skip / 0 fail`。没有新增 workspace package、daemon、listener、timer、watcher 或稳态资源；D-426b2b 的 exact 上传 bundle 已实跑 reviewed stage、transform/verify、Owner 强认证 apply/verify、真实 legacy stop、只读 target probe start/stop 与 clean rollback，并生成同源双架构 artifact。该闭合仍不授权 target 接受业务写入后的回退。
+
+- D-426b1/ADR-0522（已由 D-426b2b 双架构阶段实物闭合）：D-426a 暴露出真实的离线切换缺口：Trial Kit archive 只有本地 image reference 与 Docker content ID，既有 target barrier 却只接受 registry `name@sha256:...`；伪造 GHCR RepoDigest 或 Alpha release catalog 会污染正式发布权威。现统一引入 `{authority,reference,imageId}` target image identity，正式部署保持 `registry-digest`，离线 Trial Kit 使用 `local-image-id`，两者都同时核对容器 `Config.Image` 与 `.Image` content ID，并把三项绑定进 cutover journal。adopted bundle 新增 `docker-target` service kind，生成 Application v4 与内容绑定的 `service/docker-target.json`，固定 numeric UID:GID、restart=no、network none、read-only rootfs、drop ALL、no-new-privileges、Profile memory/PID 和 exact read-write/read-only mounts；descriptor 不创建或启动容器。没有新增 package、依赖或稳态进程。D-426b2b 已在 exact 上传 bundle 上实跑受认证 transform/apply、真实 target probe start/stop 和 clean `rollback_candidate`，因此该权威不再只是源码候选；正式 Compose catalog 与 Public Release authority 仍未放宽。
 
 - D-426a/ADR-0521（已交付同源双架构 headless Alpha 阶段实物）：二十天研发的阶段产物继续从“只读盘点”推进到仍不触碰生产切换的 side-by-side 暂存。Trial Kit 新增 canonical `upgrade-rehearsal.sh`，只接受操作者从 D-425 完整 evidence 中审核并显式提交的 SQLite/data-directory plan digest；它核对整包与 exact Operator identity 后，在新的 `0700/0600` rehearsal root 内以 read-only legacy bind、无网络、只读 rootfs、drop-all、128 MiB/0.5 CPU/32 PID 顺序执行 SQLite stage/verify/activation 和完整目录 stage/verify。`stage-summary.json` 绑定 source/architecture、两个 reviewed plan、SQLite manifest/activation 与目录 manifest digest，并固定 `legacySource=read_only`、`cutover=not_authorized`。Trial Kit/verification/auditor 升为 `@v7/@v5/@v4`，Local milestone 升为 `@v4` 并绑定双架构 `upgradeRehearsalSha256`；显式 artifact job 必须在将要上传的 exact bundle 上从 readiness plan 接续实跑 rehearsal。提交 `7a8acacb6cb49bda2116bf029fbbfe447ae5d911` 的普通 CI [run 33306005705](https://github.com/whyour/qinglong/actions/runs/33306005705) 为 41 success/3 expected scope skip/0 fail，同源 Kubernetes deployment [run 33306005706](https://github.com/whyour/qinglong/actions/runs/33306005706) 成功；显式 Local headless [run 33306650776](https://github.com/whyour/qinglong/actions/runs/33306650776) 为 42 success/2 Cluster scope skip/0 fail，exact 双架构 bundle 实跑 readiness 与 rehearsal 后生成 amd64 `187,554,547` bytes、arm64 `184,786,163` bytes 和 `6,206` bytes milestone v4，均保留至 2026-09-29。下载后的 milestone checksum 与离线 auditor 返回 `compatible=true`，并确认两个架构的 rehearsal digest 不同。没有 transform/apply、Owner/Secret authority、2.x stop、3.0 target start、cutover、rollback、migration、依赖、package、daemon、listener、timer 或稳态资源增量；D-426b/c 才分别闭合 adopted start/clean rollback 与 write-after reconciliation。
 
@@ -22,7 +24,7 @@
 - 目标版本：QingLong 3.x
 - 作者：QingLong Maintainers
 - 创建日期：2026-07-17
-- 最后更新：2026-08-30
+- 最后更新：2026-08-31
 - 讨论范围：架构与演进路线，不包含最终 UI 视觉方案
 
 最新增量证据（2026-08-29）：