---
name: guanghu-os-server
description: 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:

```bash
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:

```bash
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.