evidence: verify cross-root repository service on JD

This commit is contained in:
冰朔 2026-08-16 00:55:16 +08:00
commit 9b19fee681
6 changed files with 128 additions and 8 deletions

View file

@ -57,6 +57,7 @@ Linux 被唤醒时会真实运行内核、驱动、进程、网络与文件系
|---|---:|
| 有界光湖语言服务控制层 | 100 |
| 京东真实 Forgejo 隔离副本的有界唤醒、读回与收回 | 100 |
| 跨根光湖监督器对仓库服务的唤醒、读回与收回等价门 | 100 |
| 光湖独立先启动并掌握整机启动权 | 0 |
| 完整 Linux 平时休眠、由光湖按需唤醒与收回 | 0 |
| Linux 救援通道保留 | 100 |
@ -68,8 +69,13 @@ Linux 被唤醒时会真实运行内核、驱动、进程、网络与文件系
`REQ-JD-REPO-003` 已进一步证明:根监督器能够只授予 `repository-main-readback`,唤醒
真实 Forgejo 16.0.1 的隔离数据副本,核验固定 `main` 后把它收回到 `DORMANT`;公网仓库
进程 760 未被停止或替换。它证明的是桥的控制方式,不是物理机已经从光湖启动。下一步把
同一生命周期装入跨根启动候选,并先在 QEMU 做服务等价验收。
进程 760 未被停止或替换。它证明的是桥的控制方式,不是物理机已经从光湖启动;随后需要把
同一生命周期装入跨根启动候选,并在 QEMU 做服务等价验收。
该服务等价验收现已通过:根内光湖监督器在 `switch_root` 后完成
`DORMANT -> READY -> readback -> DORMANT`,且京东公网仓库进程与物理启动周期未改变。
下一门改为构建并隔离验证“一次性物理启动候选 + 自动返回 Linux 救援”,仍不能提前把物理
光湖启动或完整 Linux 按需副控记为 100。
## 从迁移态到最终态

View file

@ -18,3 +18,8 @@ QEMU 服务等价后端只模拟这一个已登记能力,不冒充完整 Forge
提供固定提交读回,由同一生命周期控制器执行 `DORMANT -> READY -> verify -> DORMANT`
这条证据要与京东真实 Forgejo 隔离生命周期共同成立,才能说明“控制关系”和“真实仓库实现”
两侧都已验证;任一侧都不能单独推出物理光湖启动或完整 Linux 按需副控为 100。
京东同核 QEMU 的 `REQ-QEMU-CROSS-ROOT-001` 已完成该门。第一次因 BusyBox `wget`
不支持的参数而失败,第二次因只读根拒绝回执写入而失败;修正为受时限约束的兼容读回和
独立 tmpfs 回执面后,第三次从跨根监督、服务唤醒、固定主线读回一直完成到最终无监听状态。
两次失败均未计入部分完成。

View file

@ -148,6 +148,12 @@ root supervisor becomes resident, it must wake the service, read the pinned
fixture. This QEMU gate complements rather than replaces the real Forgejo
shadow proof. See ADR-0182.
JD-hosted QEMU request `REQ-QEMU-CROSS-ROOT-001` now proves this cross-root
service-equivalence gate at `100` and leaves no listener or QEMU process. The
physical node was not rebooted, so physical first boot and complete Linux
on-demand subcontrol remain `0`. See
`deployments/JD-FD-PRIMARY/CROSS-ROOT-REPOSITORY-SERVICE-QEMU-RECEIPT-20260816.hldp`.
## Language-primary boot target
`guanghu-language-primary.target` makes the accepted cognitive-control model

View file

@ -0,0 +1,69 @@
schema: guanghu.jd-cross-root-repository-qemu-receipt/v1
receipt_id: JD-FD-PRIMARY-cross-root-repository-qemu-0759625
issued_at: 2026-08-16T00:52:14+08:00
development_id: DEV-20260815-001
development_id_role: EVIDENCE_NAMESPACE_ONLY_NOT_ACTIVE_LANE
node_id: JD-FD-PRIMARY
node_dmi: f3d4b730-7f02-452f-975b-7091a4800431
source_commit: b7925420ff161301704800c98e2b15bea2a01c40
source_tree: 815aacf80273ad264e36ef8adcaa5abb6f59b686
workorder_sha256: 93416b8d0f2ce2d6e45ea81e8cdfd34f03dbb61e2df1f0485307ae28cfbc2189
root_image_sha256: 1c71f1dd3d150b9be4df510c6760ec680670b9c44fc4e62bfa752896a883b6d9
root_image_size: 134217728
accepted_serial_sha256: 041824dad20c0e48bea12ecc4887695434a14ada3c3d5b9c599c423acc840b2a
accepted_serial_size: 32842
trigger: The real Forgejo shadow lifecycle passed on the Linux host, but the same bounded controller had not yet executed after switch_root under the root Guanghu supervisor.
emergence:
- The portable lifecycle controller and loopback repository service were added to the read-only cross-root fixture.
- Attempt 1 reached the root supervisor but BusyBox wget 1.30.1 crashed because its unsupported -T option was used; no pass receipt was accepted.
- The readback was changed to BusyBox timeout wrapping supported wget arguments.
- Attempt 2 completed service wake, readback, verification, and reclaim, then failed when the read-only root rejected the final receipt write; no pass receipt was accepted.
- A 1 MiB volatile receipt plane was mounted at /guanghu/receipts while the root image remained read-only.
- Attempt 3 completed cross-root supervision, bounded repository readback, final DORMANT verification, and QEMU poweroff.
lock:
- GUANGHU_FIRST_BOOT_SUPERVISOR_ACTIVE
- GUANGHU_SWITCH_ROOT_INIT_ACTIVE
- GUANGHU_ROOT_SUPERVISOR_ACTIVE
- GUANGHU_CROSS_ROOT_PERSISTENCE_VERIFIED
- GUANGHU_REPOSITORY_BRIDGE_LIFECYCLE_PASS_100 request=REQ-QEMU-CROSS-ROOT-001 final=DORMANT
- GUANGHU_CROSS_ROOT_REPOSITORY_SERVICE_EQUIVALENCE_VERIFIED request=REQ-QEMU-CROSS-ROOT-001 final=DORMANT
why: The real Forgejo proof establishes that the Linux repository implementation can obey the bounded lifecycle, while this proof establishes that Guanghu retains the same lifecycle authority after switch_root. Neither proof alone is sufficient.
rejected:
- Counting either failed attempt as partial completion.
- Making the root image writable merely to obtain a receipt.
- Sharing the live Forgejo data path or attaching the physical JD disk.
- Treating a one-capability loopback service as full Forgejo, physical boot, or complete Linux on-demand subcontrol.
accepted_run:
attempt: 3
qemu_exit: 0
qemu_boot_id: 25ec94fe-5032-4dbd-a6aa-8dbe76cd4807
request_id: REQ-QEMU-CROSS-ROOT-001
capability: repository-main-readback
observed_main: b7925420ff161301704800c98e2b15bea2a01c40
initial_state: DORMANT
active_state: READY
final_state: DORMANT
live_readback:
physical_boot_id_before_and_after: 68d4a3c9-c866-4f4a-be2e-0aa5f41a61b1
repository_service: active
repository_pid_before_and_after: 760
public_code_http: 200
public_repository_http: 200
public_main: b7925420ff161301704800c98e2b15bea2a01c40
host_port_39301_after: ABSENT
residual_qemu_processes: 0
physical_boot_files_changed: false
physical_reboot_performed: false
claims:
jd_host_qemu_cross_root_repository_service_equivalence: 100
combined_bounded_repository_bridge_control_model: 100
physical_guanghu_first_boot: 0
linux_on_demand_subcontrol: 0
final_guanghu_os_master: 0
next_gate: Build and QEMU-verify a one-time physical-boot candidate that includes bounded repository control and automatic return to the preserved Linux rescue entry before any real reboot.
sources:
- /guanghu/recovery/JD-FD-PRIMARY-cross-root-repository-qemu-0759625/WORKORDER.hldp
- /guanghu/recovery/JD-FD-PRIMARY-cross-root-repository-qemu-0759625/qemu-cross-root-repository-attempt-3.serial.log
- /guanghu/recovery/JD-FD-PRIMARY-cross-root-repository-qemu-0759625/qemu-cross-root-repository.serial.log
- /guanghu/recovery/JD-FD-PRIMARY-cross-root-repository-qemu-0759625/qemu-cross-root-repository-attempt-2.serial.log
- ADR-0182