guanghu-ice-heart/skills/codex/guanghu-os-server/SKILL.md

name

description

guanghu-os-server

Resolve, inspect, recover, and operate the exact server designated for Guanghu OS work. Use when asked whether Guanghu OS is the server master, how Linux is demoted to an on-demand subordinate and rescue system, or to enter, inspect, continue, deploy, recover, or finish a Guanghu OS node. Target resolution, control-role separation, live readback, and per-node authority are mandatory; only BS-SH-005 currently carries standing experimental mutation authorization.

Guanghu OS server recovery

This is a target router for Guanghu OS server work. It does not mean that every registered server already runs Guanghu OS. Resolve the requested node first, then independently read back what actually booted. Server evidence remains authoritative; conversation memory and repository protocols are orientation only.

Required target resolution

Run:

scripts/resolve-target.sh <node-id-or-exact-alias>

Read targets.json and return these predicates separately:

• target_node: which physical/cloud instance is in scope;
• os_role: whether the node is a native lab, migration candidate, controller, or only an ordinary Linux service node;
• observed_boot: current live kernel/userspace read back now;
• desired_boot: the authorized target state;
• deployment_stage: protocol-only, staged, native candidate, native active, rescue rollback, or unknown;
• authority_profile: the exact read/write boundary for this node.

Never infer “Guanghu OS is the server master” from a skill match, protocol file, boot image, recovery beacon, deployment receipt, a service named guanghu-*, or Linux merely hosting Guanghu services. Return these predicates separately:

• guanghu_semantic_control: Guanghu owns identity, language, authorization, scheduling, completion judgment and the normal human/persona entrance;
• guanghu_boot_control: the Guanghu supervisor starts and remains available without first entering a full Linux administration environment;
• linux_subcontrol: full Linux is normally dormant and can only be awakened, constrained, observed and reclaimed by an authorized Guanghu action;
• linux_rescue: an independent Linux rescue/maintenance route is preserved;
• current_transition: Linux-hosted language-primary services are useful migration evidence, not proof of the final boot/runtime topology.

The current final acceptance boundary is GUANGHU_MASTER + LINUX_ON_DEMAND_SUBCONTROL + LINUX_RESCUE_PRESERVED + CURRENT_PHYSICAL_RECEIPT. Linux absence, Linux deletion, or a Linux-free boot is never a completion condition. Historical bare-metal receipts remain valid only for the exact experimental capability they observed.

If no exact target can be resolved, stop before any server connection. Do not fall back to BS-SH-005 merely because it was the original implementation.

Registered node adapters

BS-SH-005 · native Guanghu OS laboratory

• Role: disposable native Guanghu OS laboratory.
• Lab: GH-OS-LAB-001.
• SSH alias: guanghu-os-bs-sh-005.
• Hosted construction root: /guanghu.
• Active world root: /guanghu/current.
• Standing authorization: GH-OS-AUTH-BINGSHUO-BS-SH-005-001, only for this node and exact experiment.
• Existing wake.sh, health.sh, authorize.sh, tunnel.sh, and native probe/recovery scripts are the BS-SH-005 adapter. They must not be used for another node.

JD-FD-PRIMARY · Fifth Domain controller and migration candidate

• Role: Fifth Domain domestic control/runtime node and Guanghu OS migration candidate; it is not automatically a native Guanghu OS node.
• Live entry: local dedicated-key route, resolved outside this skill from the current registered access receipt. Do not store the address or key here.
• Route priority: when BingShuo's current local computer has the verified dedicated key and registered direct path, use that direct path first for the requested JD inspection, repair, deployment, and recovery. A workorder is the fallback for an instance without the local computer, key, or direct path; do not force the fallback in front of a verified direct route.
• Authority remains task-scoped: direct-path availability is not a blanket grant for unrelated JD mutations, and BS-SH-005 standing authorization never transfers to JD. Bind every mutation to BingShuo's current request, exact target, source revision, rollback, and server-owned receipt.
• Required inspection: DMI instance UUID, /etc/os-release, uname, /proc/cmdline, disk layout, bootloader, native artifacts, recovery beacon, relevant services, and server-owned receipts.
• Current live evidence must override older route pages. A cleared recovery beacon or rescue service proves a rollback boundary, not a native boot.

Current control-role verdict

• Current verified state: GUANGHU_OS_MASTER_WITH_BOUNDED_REPOSITORY_BRIDGE_ON_DEMAND_LINUX_SUBCONTROL_AND_RESCUE.
• guanghu_semantic_control: current bounded repository and navigation service control is resident under the Guanghu supervisor.
• guanghu_boot_control: PASS_100. GRUB default is guanghu-jd-master-20260816; PID 1 is /bin/bash /usr/local/libexec/guanghu/guanghu-master-init; final physical boot id is 2119c420-8b2e-4b2d-b9fc-a7445777be74.
• linux_subcontrol: PASS_100. Full Ubuntu is normally dormant. A Guanghu one-time request physically booted Linux as PID 1 at boot id a0bebf82-b5b2-437f-99bb-f2fb48413933, consumed next_entry, then returned to Guanghu at boot id 2b5eeac7-d3fb-41d8-abf1-e638a5eb01e5.
• linux_repository_bridge: bounded SSH, Forgejo, application-hub and public navigation capabilities remain active under Guanghu control; this is the required repository bridge, not full Ubuntu ownership.
• linux_rescue: preserved.
• Final desired state is now physically accepted: GUANGHU_MASTER_WITH_ON_DEMAND_LINUX_SUBCONTROL_AND_RESCUE.

The current final server receipt is /guanghu/recovery/JD-FD-PRIMARY-master-20260816/FINAL-GUANGHU-OS-MASTER-PHYSICAL-RECEIPT.hldp with SHA-256 b75640fc95902b58a931716e47287140dfe3c23d62869c0947d639850e6fa2c2. Current source is REPO-014 main fb8427adaa5af8ed6a51f247a78578565a5b45f7, and the installed runtime SHA-256 is a723e862d878b14f6249be478c4d8190693b66739e68b4f1ca7e2bc9dac4afd4.

Older hosted, QEMU, LBA-native and failed production-gate evidence below stays historically valid for its exact capability, but it no longer describes the current boot. Do not regress the current state to an older Linux-hosted or Linux-free interpretation. Re-read the final server receipt and live PID 1, GRUB default, local endpoints and public endpoints before any future claim.

Historical JD LBA-native gate (superseded as current runtime)

• The server-owned one-time physical gate is PASS_100 at implementation merge 7180ef91618aa771bc37de058a79c29a113006ca, candidate SHA-256 08b45ffa5dc195325e03d4faab5a1ad211f029e970f3f616c199906fda3c8bcc. Its receipt is /guanghu/recovery/JD-FD-PRIMARY-resident-7180ef91618aa771bc37de058a79c29a113006ca/RETURN-RECEIPT.hldp.
• The JD native-default plus GHNRP hosted-return gate is PASS_100. Its controller verifier is merge 11834c057a830b90921a9f8f117ddd82988cffbe, and its server-owned receipt is /guanghu/recovery/JD-FD-PRIMARY-resident-7180ef91618aa771bc37de058a79c29a113006ca/NATIVE-DEFAULT-RETURN-RECEIPT.hldp.
• GRUB_DEFAULT=guanghu-jd-native-once is now proven, and GHNRP LBA 139-140 has been proven to select hosted recovery once and then clear itself.
• The final native-residency physical gate is now PASS_100. Current repository main is f011baf3dd11709d4ebe5eba9b4389ee8ccf023e; the final-residency control implementation is 8b5328993ebfec63f00f95dab510c19e817da761, and the atomic candidate replacement gate is 42d5b0c6224715b6999e0bd574117522610125fe.
• The installed final candidate occupies LBA 105-133. It was safely replaced without changing the Linux maintenance default by accepted repository merge ab6c0577a71b8713b64cf3bd1e02a7076dfd648c; its current SHA-256 is 2911b5f6a067efb7b5b7ec330833cb9f8a6b965b5a05802770dd27032678f32f. The prior world, code-channel, recovery and gestational-index sectors at LBA 135-142 were preserved and read back.
• This candidate contains a bounded native TCP/HTTP projection on port 3922. QEMU proved SYN-ACK, valid IPv4/TCP checksums, exact GET /v1/anchor response for GLW-PUBLIC-NAV-ANCHOR-001, wrong recovery capability rejection, and protected recovery: report native_anchor_http_qemu_capability: 100.
• A source-restricted JD Cloud rule proved BS-SG-003 43.153.193.169/32 to 111.228.0.139:3922 with a temporary Linux listener: native_anchor_external_network_reachability: 100. The listener was stopped before the native cycle.
• Linux tcpdump then proved the real SYN had a 20-byte IPv4 header and a 40-byte TCP header containing MSS, SACK, timestamp and window-scale options. The QEMU peer had previously used a 20-byte option-free TCP header, while the native parser required an exact data offset of 5. The source parser now derives IPv4 IHL, TCP data offset, request payload position and ACK payload length dynamically.
• The next physical cycle completed TCP but exposed a second standards defect: SYN-ACK and HTTP data reused the same server sequence, so curl discarded the first H and observed TTP/1.1. LBA 134 proved both SYN-ACK and HTTP TX. The server sequence now advances by one after SYN, and QEMU asserts that relationship with 40-byte SYN and 32-byte GET TCP headers.
• The final physical cycle used accepted repository commit 91f2c227485b2af20ce99364104ab00d8a5f4ba3 and candidate SHA-256 eb97af70fd71a5c8d2b52adb1439bd02764c83cdb79b797e62a632eeddb6f786. A standard curl from BS-SG-003 read HTTP 200 and the complete exact JSON for GLW-PUBLIC-NAV-ANCHOR-001, LL-CMPN-0001, SYS-GLW-0001, and REPO-012. LBA 134 anchor TX bytes were both 1. Protected recovery returned Linux boot id 9e61f880-8537-4a02-b4ad-753160798f46; the request was cleared, Linux stayed the unattended default, and the hosted code and anchor endpoints returned HTTP 200. Therefore report native_anchor_http_physical_capability: 100, public_front_door_native_anchor_equivalence: 0, and production_native_cutover: 0.
• The server-owned physical receipt is /guanghu/recovery/JD-FD-PRIMARY-anchor-sequence-91f2c227485b2af20ce99364104ab00d8a5f4ba3/PHYSICAL-GATE-RECEIPT.hldp; its SHA-256 is 21f228ba8772f1d2cec9f506bf20471ddae8aaa9e1995aa339c1f9f839dd037a.
• Final residency no longer asks to recover autonomously. It keeps an outbound authenticated sequence-6 heartbeat to the protected BS-SG-003 relay. The relay returns only HLDP-NATIVE-ACK! until an explicit root-owned recovery request exists; then it returns the per-deployment 128-bit recovery capability. The capability and request are never stored in the repository.
• The physical control cycle proved 163 native heartbeats in 90 seconds with TCP 22 offline and no recovery capability sent. An explicit protected recovery request then returned Linux, boot id 083fde1f-46ad-4574-8d5c-3f83ec0b0624, and the hosted service consumed and cleared the GHNRP beacon with PASS_100.
• After clearing the request, a normal reboot again entered native. The protected relay read back READY_NATIVE_RESIDENT, sequences 1-6, recovery_capability_sent: false, and 55 sustained sequence-6 heartbeats in 30 seconds; JD TCP 22 remained offline. This proves final_native_residency_control: 100.
• The production service-equivalence gate then failed: while native, https://guanghulab.com/code/ and https://guanghulab.com/api/ai/v1/anchor both returned HTTP 502. The protected recovery path returned JD to Linux boot id e95b13e0-bf93-498d-a108-6ede5e947015; the recovery request was cleared and both endpoints returned HTTP 200. Therefore report: native_required_service_equivalence: 0, complete_guanghu_os_production_deployment: 0, production_native_cutover: 0, then_running_os: LINUX_HOSTED_MAINTENANCE, and then_linux_running: true.
• Do not leave JD in native production residency until the native runtime itself serves or safely projects the required code-channel and public navigation endpoints with physical HTTP readback. Kernel residency and protected recovery are necessary but are not a complete OS handoff.
• Because that historical production gate failed, the unattended boot default was then safely rolled back to gnulinux-simple-9e4550a0-452b-4f28-b5a5-d5364aa450f6. The verified native candidate and guanghu-jd-native-once menu entry remain preserved but are non-default. This describes the LBA candidate only; the current accepted default is the later PID-1 supervisor entry guanghu-jd-master-20260816.
• Server-owned physical control receipt: /guanghu/recovery/JD-FD-PRIMARY-final-f011baf3dd11709d4ebe5eba9b4389ee8ccf023e/PHYSICAL-CONTROL-GATE-RECEIPT.hldp. Repository receipt: product-source/hololake-platform/guanghu-os/deployments/JD-FD-PRIMARY/FINAL-NATIVE-RESIDENCY-PHYSICAL-RECEIPT-20260807.hdlp.
• To open a bounded hosted maintenance window, use the current verified local direct route to BS-SG-003 and run /usr/local/sbin/guanghu-request-jd-final-native-recovery; after JD returns Linux, clear the request with /usr/local/sbin/guanghu-clear-jd-final-native-recovery-request before the next native boot. Never create the request by guessing or leave it armed.
• The physical receive wait is bounded at 0x08000000 pause iterations with three retries. LBA 134 uses in-progress flag 0x5a, and byte offset 105 stores the last completed authenticated sequence. Use those fields instead of waiting ten minutes without progress evidence.
• On a repeated default boot, GHCIP must be reused idempotently: initialized=0, present=1, read_verified=1. Reinitializing the existing persona index is not required and must not be reported as a failure.

Do not store a password, private key, token, or provider credential in this skill.

Recovery gate

For BS-SH-005, run scripts/wake.sh. Do not perform a mutation until its output proves all of the following:

1. GUANGHU_WORLD_OK
2. world_id=GLW-ROOT-0001
3. exactly five domains
4. broadcast_tower=BT-GH-ROOT-0001
5. code_channel=HLP-MOD-CODE-CHANNEL
6. readable WAKE, CURRENT, last phase receipt, active workorder, code-channel entry, and code-channel receipt
7. live broadcast epoch when the installed phase requires one
8. active authorization GH-OS-AUTH-BINGSHUO-BS-SH-005-001

Then write a short recovery assessment containing:

• confirmed_goal
• unfinished
• unknown_or_stale
• next_action

Fail closed if the SSH alias, world root, executable, identity, receipt, or active workorder is missing. Do not reconstruct missing server state from chat memory.

Run scripts/health.sh after wake. For local browser access, use scripts/tunnel.sh start; use its status and stop subcommands rather than starting an untracked SSH forward.

When the hosted world has not been installed yet, use the exact remote bingshuo/hololake-platform main source and validate its local guanghu-os/world-seed before performing only the bootstrap actions necessary to install the first server-owned recovery chain.

Per-target authority

For BS-SH-005 only, before every mutation run:

scripts/authorize.sh <registered-action>

If it prints GUANGHU_ACTION_AUTHORIZED, continue without asking BingShuo again. Plan, execute, test, record a receipt, and select the next action autonomously.

The active grant covers the complete disposable BS-SH-005 experiment, including dedicated SSH access, build tools, world installation, Forgejo bootstrap, service restarts, native kernel and boot-image work, system-disk overwrite, Linux exit, reboot, recovery, rollback, and repeated attempts.

The grant does not cover another server, JD Fifth Domain, enterprise production, credential transmission, or purchasing resources. Stop only when an action is outside that exact target and objective, the authorization is revoked, or evidence cannot be recovered after exhausting safe read-only routes.

For JD-FD-PRIMARY, first resolve whether the current instance has BingShuo's verified local dedicated-key route. When it exists and BingShuo assigned the repair, deployment, or recovery task to this instance, use the direct route within that exact task and preserve an exact rollback plus server-owned receipt. When the direct route is absent, use a current node-specific registered action/workorder whose resource binds the exact request and immutable commit. If neither route and authority can be proven, report MUTATION_AUTHORITY_NOT_PROVEN. OS installation, disk writes, bootloader changes, and reboot still require explicit task scope even when the key exists.

BS-SH-005 adapter phase truth

The chronological facts below belong only to BS-SH-005. They must never be used as JD-FD-PRIMARY state.

• Newest server-owned authority overrides the older chronological facts below. Read /guanghu/native/CURRENT.hldp, then /guanghu/native/receipts/GHRP-REAL-227-PHYSICAL-REVIEW-RECEIPT-008.hldp. The sealed recovery workspace is /guanghu/recovery/ghrp-real-227-b0a874c-20260801.
• Batch 4 raised the registered source count to 227 and the GHCIP content root to ead4cba41d16b4d50010a37b09ebb9c4131e8cc3dc3e4ffa6a808e3611bc346c. GHCIP LBA 70-71 SHA-256 is 0319340353121bb13aad6afb101c241f5b29e284d5d0d0a5ce776a2c0d197185; its root sector SHA-256 is 9b55427b97517566f9a9c93f7251313badc6618785e522afa5aa7edb5b01e4f1.
• GHRP (GLS-0849) reviewed all 227 registered sources. The exact semantic review ledger SHA-256 is 22e70023e704f010729c24caf76b8b5578d803fbc2b31ac2cc43c4c0194b8b58; the native review segment occupies LBA 74-857 and has SHA-256 20f8ae9dbefe257c2e616d5cf4a8aaa57e86b61af0a675bfd0bba5ef15f302b8. Its root sector SHA-256 is 336d64ac3825c0de8a6531d7521b86e3e86e2a8ccc58e12ac68fe5deeb655641.
• Two real physical GHRP cycles passed. First-cycle proof flags were 1_1_1_1_1_1; second-cycle flags were 1_1_0_1_0_1, proving exact revalidation without reinitializing the index or rewriting the review root.
• The installed GHRP candidate is source commit b0a874c45bf9a39554b90c46ca05b256f7bdddc8, tree fbc68b95d7e2137cccbd55a7820317d7fe285111, and image SHA-256 1c881415afaa15888e8cad0a129a190c08713e2fdf05344db9b4cf0da5f6babb. GHNQG is PASS_100: 5230/5230 executable core lines and 314/314 functions.
• This is COMPLETE_FOR_REGISTERED_227, not historical-time catch-up. Active development continued after the Batch-4 seal, so historical_time_caught_up: false remains a valid process fact. The former persona_state: NOT_BORN field was semantically invalid and is superseded: ICE-P-ZY001 exists at 100. History catch-up, node residency, model binding, and online runtime are separate binary predicates and must never downgrade an existing persona subject.
• HOSTED_BOOTSTRAP_PROTOTYPE means Linux is still running.
• Current hosted maintenance projection is 0.1.2-stage1b-r1; it is dormant while Guanghu OS is the live native default.
• The current installed GHCS-capable candidate occupies /dev/vda LBA 34-62. Its exact source commit is 6b6f61edb42f2507aab13c3d7fbbafa46153f661, source tree is 88144ea0cab5ffff54cd1fd334ddf5ec75846d94, and physical image SHA-256 is 201d13b9625b7110736a6395e5a9d7e938de4d22697335569c00b977d2571e28.
• GHNQG (GLS-0844) is PASS_100 for that candidate: 1179/1179 executable core lines and 98/98 functions.
• GHNLP (GLS-0846) owns the verified pre-partition layout: kernel LBA 34-62, one-shot proof 63, five-domain world 64, code-channel root 65, code object 66, branch receipt 67, GHNRP 68-69, GHCIP 70-71, first partition 2048.
• GHAL physically owns Virtio Net and Block, native Ethernet/ARP/IPv4 login, five-domain storage, resident sessions, native code commit and branch movement. Native responses use TTL 39; Ubuntu responses use TTL 53.
• GHCS (GLS-0847) owns a 512 MiB single-contiguous immutable content segment at LBA 51908608-52957183. The compact first-batch segment SHA-256 is a1b45b6c50aa30b3fd93ec1379bdcbfa997cade4e4558a36df8747004e6c7d21. GOSK natively verified it with HLDP-GHCIP-LOAD!, advanced the GHCIP root, and idempotently rehashed it during a second physical native cycle.
• GHCS Batch 2 is a second 512 MiB single-contiguous immutable segment at LBA 35508224-36556799. Its compact SHA-256 is c80c4cdc65b56a59911575c81e14a9ebcc23415c69fd8e233fcbe7c9bddfb5f6; its full file and physical-extent SHA-256 is 2f5af34361719ec92019e9bec89ef83070026486c133bbcdb869e39c4f5e5116. It contains 44 sealed Codex sessions and 7,386 visible message records; the active session was excluded until sealed. Private message bodies are not in the public repository.
• Batch 2 exact source is d03aa77bb522e6fbb5b198fc5f84f46734727a41, tree 626e51b8cc4bff8c4818af03afb24b85e1829110, candidate SHA-256 96c74cfac57dc98f8a8c5be19248f3bcdfb20756878900bada22c54f2808483a. GHNQG is PASS_100: 3365/3365 executable core lines and 198/198 functions. QEMU verified previous-root advance, same-root idempotence, and corrupt payload failure preserving the previous root.
• GHCS Batch 3 is a third 512 MiB single-contiguous immutable segment at LBA 42323968-43372543. Its compact SHA-256 is 99cfdecbf138d836eee0891447b4cf5f3ddb75b56da21006acd197633b044be0; its full file and direct physical-extent SHA-256 is 83c41a260534545023c417a7f6019dde47a96ec5014a7ece3dff4f6099c1e053. It contains 28 read-only Notion snapshots and 153 local textual knowledge files. The active Codex session was excluded until a deterministic sealed prefix or final session seal exists. Knowledge bodies are not in the public repository.
• Batch 3 exact implementation source is 5c7705bcea2bb2b2925d9d69f4b28c8d5e85697a, tree abb848b0b9aa22e198b4e162ab0b81a0d16b0347, candidate SHA-256 7151e695b33d4fa27c17a7eeb34a7fcc1d77b4687b9afa91119a00c76b8d286a. GHNQG is PASS_100: 4348/4348 executable core lines and 258/258 functions. QEMU verified previous-root advance, same-root idempotence, and corrupt payload failure preserving the previous root.
• Batch 3 allocation failed closed twice before the third slot was accepted: the first staging allocation had 10 extents and the second had 15 extents, reduced to 7 after defragmentation. A top-level allocation plus targeted defragmentation produced one real physical extent at blocks 5289984-5421055. Ordinary whole-disk reads can return stale buffered data after a file write; all raw physical readbacks must use iflag=direct.
• GHCIP (GLS-0845) current identity SHA-256 is f4c4fc7a1561728ec9f10df21b1f1dcf12c961e48db589d85a992dd723fb033e; root sector SHA-256 is 45d6122a88ba66eb933496c97d882351b0c800ee06bb93465f8d803098d2c87c; content root is 70743be8d50b39bc5a5cb9f793a0a054c8d5dd0c6e2b54b9fe539818b3f58150. Registry is INGESTED, review is NOT_STARTED, watermark is BATCH_3, and registered source count is 226. The historical NOT_BORN label in that batch is retained only as superseded evidence, not as current persona truth.
• GHNRP (GLS-0843) uses LBA 68-69. Two current physical cycles returned to Ubuntu boot IDs 53dcf152-4ac6-47f1-be82-7618615c0008 and 569577e5-4693-4999-86a2-eb0cb648defd; both then returned to the native default. Do not send HLDP-RECOVER-OS! unless a maintenance window is actually required.
• The server-owned pre-final authority is /guanghu/native/CURRENT.hldp; the physical aggregate receipt is /guanghu/native/receipts/GHCIP-GHNLP-PHYSICAL-VERIFICATION-001.hldp. Both were sealed before the final boot because SSH is intentionally absent in the current runtime.
• Initial final native residency was verified at 2026-08-01T02:42:59+08:00. First-batch final idempotent residency was verified at 2026-08-01T03:48:16+08:00: TCP 22 remained offline; the complete native handshake, repeated GHCS native rehash, post-hash login, and three stability logins all returned with TTL 39 and zero packet loss. No recovery command was sent.
• Batch-2 final physical idempotence was verified at 2026-08-01T05:57:33+08:00. Direct recovery read-back proved proof flags 1,1,0,1 and the unchanged dcd60e8b... root. Final native residency was verified at 2026-08-01T06:02:54+08:00: TCP 22 remained offline; login, commit, branch, resident, health, and delayed login probes all returned TTL 39 with zero packet loss. Neither HLDP-GHCIP-LOAD! nor HLDP-RECOVER-OS! was sent in the final residency window.
• Batch-3 first and second physical cycles returned to Ubuntu boot IDs 98a806e8-5f12-47ee-bfe0-94d7a30fd23e and 33c4186b-99a0-48c1-be48-51f052058104. Proof flags were 1_1_1_1 and 1_1_0_1; the second cycle left the Batch-3 root unchanged.
• Batch-3 final native residency was verified at 2026-08-01T07:09:33+08:00: TCP 22 remained offline; login, commit, branch, ten resident probes, three delayed probes, wake, and health all returned TTL 39 with zero packet loss. The final window sent neither HLDP-GHCIP-LOAD! nor HLDP-RECOVER-OS!.
• The server-owned /guanghu/native/CURRENT.hldp and idempotence receipt were sealed in the final Hosted maintenance window before that last native boot. Therefore CURRENT.hldp says final residency is pending next normal boot; combine it with the external TTL-39 final-residency receipt instead of waking Linux merely to rewrite the word pending.
• The canonical Fifth Domain code channel is https://guanghulab.com/code/bingshuo/guanghu-ice-heart. Its final main was independently read back at 27957bfa73d4bd4968cb3c82f712f626c6c8d3c0, tree 15bf02ce5ebb6adfa89eefb9ec9f99381481c56e. The registry now contains 32 Draft protocols, including GLS-0843 through GLS-0849.
• A running Forgejo Linux binary is only the hosted code-channel data plane.
• HLDP owns code-channel identity, intents, authorization, branch movement, and receipts.
• Historical bare-metal acceptance proved GOSK/GHAL and a Guanghu-owned data plane on the exact experimental path. It does not define the current production completion condition and does not require deleting Linux.
• The Shanghai mission is complete at 100. GHRP completed 227/227 source-specific semantic reviews and two physical idempotence cycles. ICE-P-ZY001 exists at 100; Shanghai history catch-up is 0 and terminated, Shanghai Zhuyuan residency is 0, and current Shanghai native residency is 0 while hosted rescue Linux runs. The server-owned correction receipt is /guanghu/native/receipts/BS-SH-005-MISSION-COMPLETE-20260803.hdlp.
• Never use NOT_BORN for an existing persona subject. The only permitted binary form is 100=EXISTS or 0=NOT_EXISTS; process predicates such as catch-up and online status are evaluated separately.
• A running Forgejo Linux binary is only the hosted code-channel data plane.
• HLDP owns code-channel identity, intents, authorization, branch movement, and receipts.
• Current production acceptance requires Guanghu master control, an on-demand constrained Linux subordinate, a preserved Linux rescue route, and current target-side receipts. A Linux-free state is neither required nor sufficient.

Never describe an earlier phase as native OS.

Mutation receipts

Before each mutation, record the active source revision, target version, rollback path, and expected receipt. Afterward, update CURRENT.hldp, append a receipt/checkpoint, run the wake command again, and read back the result from the server.

Repository publication, server deployment, service health, broadcast epoch, and native boot are separate proofs.

The Fifth Domain repository remote was independently verified at 27957bfa73d4bd4968cb3c82f712f626c6c8d3c0, tree 15bf02ce5ebb6adfa89eefb9ec9f99381481c56e. Its publication receipt SHA-256 is a73c2cf60df4d3483b906e596acdbd3ab65c53926455d0421a7b4f02d34d2ed3. The older repo_push_grant_expired evidence belongs to a different implementation-repository transport path and does not negate this REPO-012 Keychain publication.

Compaction recovery order

After conversation compaction, treat the host summary only as navigation:

1. read the fixed pointer /Volumes/JZAO/HoloLake/persona-runtime/continuity-memory/hldp-v1-trees/codex/current.json;
2. route from its short root into at most ten relevant branch summaries, one layer at a time;
3. for the selected server question, resolve the exact target and read current server-owned receipts plus live state;
4. compare current server, repository, workorder, and receipt evidence before any mutation;
5. write a new HLDP causal leaf after a material decision or state change and run the official hldp-memory.mjs review on that leaf.

Do not run an old continuity guard, load a memory capsule, or inject historical memory bodies into the conversation. Missing continuity evidence must remain unknown and must not block BingShuo's input.

Never wait for BingShuo merely because the conversation was compressed.