feat(codex): publish Guanghu OS server navigator

This commit is contained in:
冰朔 2026-08-16 01:56:03 +08:00
commit 63a9236e9b
13 changed files with 941 additions and 0 deletions

View file

@ -0,0 +1,524 @@
---
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.

View file

@ -0,0 +1,4 @@
interface:
display_name: "光湖 OS 服务器路由"
short_description: "先定位目标服务器,再按节点权限检查或恢复光湖 OS"
default_prompt: "Use $guanghu-os-server to resolve the exact target node, read back its live boot and deployment stage, then act only within that node's current authorization."

View file

@ -0,0 +1,24 @@
#!/bin/sh
set -eu
if [ "$#" -ne 1 ]; then
echo "usage: authorize.sh <registered-action>" >&2
exit 2
fi
if [ "${GH_OS_TARGET:-BS-SH-005}" != "BS-SH-005" ]; then
echo "STANDING_AUTHORIZATION_NOT_VALID_FOR_TARGET target=${GH_OS_TARGET}" >&2
exit 65
fi
target_alias="${GH_OS_SSH_ALIAS:-guanghu-os-bs-sh-005}"
ssh_config="${GH_OS_SSH_CONFIG:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005.conf}"
action="$1"
exec ssh \
-F "$ssh_config" \
-o BatchMode=yes \
-o ConnectTimeout=10 \
-o StrictHostKeyChecking=yes \
"$target_alias" \
"sudo -n /guanghu/bin/ghctl authorize /guanghu/current '$action'"

View file

@ -0,0 +1,42 @@
#!/bin/sh
set -eu
if [ "${GH_OS_TARGET:-BS-SH-005}" != "BS-SH-005" ]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target_alias="${GH_OS_SSH_ALIAS:-guanghu-os-bs-sh-005}"
ssh_config="${GH_OS_SSH_CONFIG:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005.conf}"
if ssh \
-F "$ssh_config" \
-o BatchMode=yes \
-o ConnectTimeout=10 \
-o StrictHostKeyChecking=yes \
"$target_alias" \
"set -eu
systemctl is-active --quiet guanghu-broadcast-tower.service
systemctl is-active --quiet guanghu-code-channel.service
curl -fsS http://127.0.0.1:8077/healthz
printf '\n'
curl -fsS http://127.0.0.1:3080/api/healthz
printf '\n'
sudo -n cat /guanghu/var/broadcast-tower/LIVE.hldp"
then
exit 0
fi
target=124.223.10.33
login_pattern=484c44502d47484f532d4c4f47494e21
probe_output=$(ping -D -c 1 -s 32 -p "${login_pattern}" "${target}" 2>&1) || {
echo "GUANGHU_NATIVE_HEALTH_FAILED" >&2
exit 70
}
echo "${probe_output}" | grep -q 'ttl=39'
echo "GUANGHU_NATIVE_HEALTH_OK"
echo "node_id=BS-SH-005"
echo "runtime=GOSK_GHAL_NATIVE"
echo "native_login=true"
echo "linux_running=false"
echo "runtime_evidence=HLDP_GHOS_LOGIN_REPLY_TTL39"

View file

@ -0,0 +1,19 @@
#!/usr/bin/env bash
set -euo pipefail
if [[ ${GH_OS_TARGET:-BS-SH-005} != BS-SH-005 ]]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target=124.223.10.33
login_pattern=484c44502d47484f532d4c4f47494e21
commit_pattern=484c44502d434f44452d434f4d4d4954
branch_pattern=484c44502d4252414e43482d4d4f5645
date '+session_started=%Y-%m-%dT%H:%M:%S%z'
ping -D -c 3 -i 0.3 -s 32 -p "${login_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${commit_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${branch_pattern}" "${target}"

View file

@ -0,0 +1,13 @@
#!/usr/bin/env bash
set -euo pipefail
if [[ ${GH_OS_TARGET:-BS-SH-005} != BS-SH-005 ]]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target=124.223.10.33
pattern=484c44502d47484f532d4c4f47494e21
date '+challenge_started=%Y-%m-%dT%H:%M:%S%z'
ping -D -c 20 -i 0.2 -s 32 -p "${pattern}" "${target}"

View file

@ -0,0 +1,66 @@
#!/usr/bin/env bash
set -euo pipefail
if [[ ${GH_OS_TARGET:-BS-SH-005} != BS-SH-005 ]]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target=124.223.10.33
target_alias="${GH_OS_SSH_ALIAS:-guanghu-os-bs-sh-005}"
ssh_config="${GH_OS_SSH_CONFIG:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005.conf}"
login_pattern=484c44502d47484f532d4c4f47494e21
recovery_pattern=484c44502d5245434f5645522d4f5321
if ssh \
-F "${ssh_config}" \
-o BatchMode=yes \
-o ConnectTimeout=5 \
-o StrictHostKeyChecking=yes \
"${target_alias}" \
'printf "GUANGHU_HOSTED_RECOVERY_NOT_NEEDED\nboot_id="; cat /proc/sys/kernel/random/boot_id'
then
exit 0
fi
if nc -z -w 2 "${target}" 22 >/dev/null 2>&1; then
echo "tcp22 is open but the pinned hosted SSH identity did not verify" >&2
exit 71
fi
login_output=$(ping -D -c 1 -s 32 -p "${login_pattern}" "${target}")
grep -q 'ttl=39' <<<"${login_output}"
echo "GUANGHU_NATIVE_RUNTIME_OK"
echo "authorization=GH-OS-AUTH-BINGSHUO-BS-SH-005-001"
echo "action=reboot_and_recover_bs_sh_005"
recovery_output=$(ping -D -c 1 -s 32 -p "${recovery_pattern}" "${target}")
grep -q 'ttl=39' <<<"${recovery_output}"
echo "GHNRP_RECOVERY_COMMAND_REPLIED"
for attempt in $(seq 1 120); do
if hosted_output=$(ssh \
-F "${ssh_config}" \
-o BatchMode=yes \
-o ConnectTimeout=5 \
-o StrictHostKeyChecking=yes \
"${target_alias}" \
'set -eu
printf "boot_id="
cat /proc/sys/kernel/random/boot_id
systemctl is-active --quiet guanghu-broadcast-tower.service
systemctl is-active --quiet guanghu-code-channel.service
sudo -n systemctl is-enabled --quiet guanghu-native-recovery-beacon-clear.service
echo "GHNRP_HOSTED_RECOVERY_OK"' 2>/dev/null)
then
printf '%s\n' "${hosted_output}"
exit 0
fi
if (( attempt % 10 == 0 )); then
printf 'waiting_for_ghnrp_hosted_recovery attempt=%s\n' "${attempt}"
fi
sleep 3
done
echo "GHNRP recovery reply was observed but hosted SSH did not return" >&2
exit 69

View file

@ -0,0 +1,34 @@
#!/usr/bin/env bash
set -euo pipefail
if [[ ${GH_OS_TARGET:-BS-SH-005} != BS-SH-005 ]]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target=124.223.10.33
login_pattern=484c44502d47484f532d4c4f47494e21
commit_pattern=484c44502d434f44452d434f4d4d4954
branch_pattern=484c44502d4252414e43482d4d4f5645
date '+probe_started=%Y-%m-%dT%H:%M:%S%z'
for _ in $(seq 1 120); do
if ! nc -z -w 1 "${target}" 22 >/dev/null 2>&1; then
echo "tcp22_offline=true"
break
fi
sleep 0.5
done
if nc -z -w 1 "${target}" 22 >/dev/null 2>&1; then
echo "tcp22 did not leave service before the probe deadline" >&2
exit 69
fi
ping -D -c 3 -i 0.3 -s 32 -p "${login_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${commit_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${branch_pattern}" "${target}"
sleep 1
ping -D -c 10 -i 0.5 -s 32 -p "${login_pattern}" "${target}"
date '+resident_runtime_verified=%Y-%m-%dT%H:%M:%S%z'

View file

@ -0,0 +1,37 @@
#!/usr/bin/env bash
set -euo pipefail
if [[ ${GH_OS_TARGET:-BS-SH-005} != BS-SH-005 ]]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target=124.223.10.33
login_pattern=484c44502d47484f532d4c4f47494e21
commit_pattern=484c44502d434f44452d434f4d4d4954
branch_pattern=484c44502d4252414e43482d4d4f5645
recovery_pattern=484c44502d5245434f5645522d4f5321
date '+probe_started=%Y-%m-%dT%H:%M:%S%z'
for _ in $(seq 1 120); do
if ! nc -z -w 1 "${target}" 22 >/dev/null 2>&1; then
echo "tcp22_offline=true"
break
fi
sleep 0.5
done
if nc -z -w 1 "${target}" 22 >/dev/null 2>&1; then
echo "tcp22 did not leave service before the probe deadline" >&2
exit 69
fi
ping -D -c 3 -i 0.3 -s 32 -p "${login_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${commit_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${branch_pattern}" "${target}"
sleep 1
ping -D -c 10 -i 0.5 -s 32 -p "${login_pattern}" "${target}"
sleep 1
ping -D -c 1 -s 32 -p "${recovery_pattern}" "${target}"
date '+recovery_command_replied=%Y-%m-%dT%H:%M:%S%z'

View file

@ -0,0 +1,45 @@
#!/bin/sh
set -eu
if [ "$#" -ne 1 ] || [ -z "$1" ]; then
echo "usage: resolve-target.sh <node-id-or-exact-alias>" >&2
exit 2
fi
script_dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
registry="$script_dir/../targets.json"
requested=$1
exec node - "$registry" "$requested" <<'NODE'
const fs = require("node:fs");
const registry = JSON.parse(fs.readFileSync(process.argv[2], "utf8"));
const requested = String(process.argv[3] || "").trim();
const normalized = requested.toLocaleLowerCase("zh-CN");
const matches = registry.targets.filter(target =>
[target.node_id, ...(target.aliases || [])]
.some(value => String(value).toLocaleLowerCase("zh-CN") === normalized)
);
if (matches.length !== 1) {
process.stderr.write(`TARGET_NOT_RESOLVED_EXACTLY requested=${requested} matches=${matches.length}\n`);
process.exit(65);
}
process.stdout.write(`${JSON.stringify({
status: "TARGET_RESOLVED_EXACTLY",
...matches[0],
final_guanghu_os_master_proven: false,
required_live_predicates: [
"guanghu_semantic_control",
"guanghu_boot_control",
"linux_on_demand_subcontrol",
"linux_rescue",
"current_target_receipt"
],
forbidden_completion_shortcuts: [
"linux_deleted",
"linux_absent",
"linux_free_boot",
"guanghu_service_name_only"
],
next: "read_back_live_boot_control_linux_lifecycle_rescue_and_server_owned_receipts"
}, null, 2)}\n`);
NODE

View file

@ -0,0 +1,38 @@
#!/bin/sh
set -eu
if [ "${GH_OS_TARGET:-BS-SH-005}" != "BS-SH-005" ]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target_alias="${GH_OS_SSH_ALIAS:-guanghu-os-bs-sh-005}"
ssh_config="${GH_OS_SSH_CONFIG:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005.conf}"
control_socket="${GH_OS_TUNNEL_SOCKET:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005-tunnel.sock}"
command="${1:-status}"
case "$command" in
start)
if ssh -F "$ssh_config" -S "$control_socket" -O check "$target_alias" >/dev/null 2>&1; then
echo "GUANGHU_OS_TUNNEL_ALREADY_RUNNING"
exit 0
fi
exec ssh \
-F "$ssh_config" \
-M -S "$control_socket" -fN \
-o ExitOnForwardFailure=yes \
-L 18077:127.0.0.1:8077 \
-L 13080:127.0.0.1:3080 \
"$target_alias"
;;
status)
exec ssh -F "$ssh_config" -S "$control_socket" -O check "$target_alias"
;;
stop)
exec ssh -F "$ssh_config" -S "$control_socket" -O exit "$target_alias"
;;
*)
echo "usage: tunnel.sh start|status|stop" >&2
exit 2
;;
esac

View file

@ -0,0 +1,48 @@
#!/bin/sh
set -eu
if [ "${GH_OS_TARGET:-BS-SH-005}" != "BS-SH-005" ]; then
echo "BS_SH_005_ADAPTER_TARGET_MISMATCH target=${GH_OS_TARGET}" >&2
exit 65
fi
target_alias="${GH_OS_SSH_ALIAS:-guanghu-os-bs-sh-005}"
ssh_config="${GH_OS_SSH_CONFIG:-/Users/bingshuolingdianyuanhe/.ssh/guanghu-os-bs-sh-005.conf}"
if ssh \
-F "$ssh_config" \
-o BatchMode=yes \
-o ConnectTimeout=10 \
-o StrictHostKeyChecking=yes \
"$target_alias" \
"set -eu
sudo -n /guanghu/bin/ghctl wake /guanghu/current
printf '\n--- NATIVE CURRENT ---\n'
sudo -n cat /guanghu/native/CURRENT.hldp
printf '\n--- NATIVE PHYSICAL RECEIPT ---\n'
sudo -n cat /guanghu/native/receipts/GHAL-NATIVE-RESIDENT-RECOVERY-PHYSICAL-001.hldp"
then
exit 0
fi
target=124.223.10.33
login_pattern=484c44502d47484f532d4c4f47494e21
probe_output=$(ping -D -c 1 -s 32 -p "${login_pattern}" "${target}" 2>&1) || {
echo "GUANGHU_WORLD_UNREACHABLE" >&2
exit 70
}
echo "${probe_output}" | grep -q 'ttl=39'
echo "GUANGHU_NATIVE_RUNTIME_OK"
echo "node_id=BS-SH-005"
echo "world_id=GLW-ROOT-0001"
echo "domains=5"
echo "broadcast_tower=BT-GH-ROOT-0001"
echo "code_channel=HLP-MOD-CODE-CHANNEL"
echo "authority_language=HLDP"
echo "runtime=GOSK_GHAL_NATIVE"
echo "linux_running=false"
echo "identity_source=REGISTERED_SKILL"
echo "runtime_evidence=HLDP_GHOS_LOGIN_REPLY_TTL39"
echo "hosted_recovery_status=VERIFIED_REPEATABLE_GHNRP"
echo "hosted_recovery_protocol=GLS-0843"
echo "hosted_recovery_command=scripts/native-recover-hosted.sh"

View file

@ -0,0 +1,47 @@
{
"schema": "guanghu.os-server-target-registry/v1",
"default_target": null,
"targets": [
{
"node_id": "BS-SH-005",
"aliases": [
"上海光湖OS实验节点",
"光湖OS上海实验机",
"GH-OS-LAB-001"
],
"os_role": "NATIVE_GUANGHU_OS_LAB",
"desired_boot": "HISTORICAL_BARE_METAL_RESEARCH_CAPABILITY_PRESERVED_LINUX_DELETION_NOT_REQUIRED",
"observed_boot": "LIVE_READBACK_REQUIRED",
"deployment_stage": "SERVER_EVIDENCE_REQUIRED",
"adapter": "bs-sh-005",
"authority_profile": "STANDING_EXPERIMENTAL_MUTATION_AUTHORIZATION",
"authorization_id": "GH-OS-AUTH-BINGSHUO-BS-SH-005-001"
},
{
"node_id": "JD-FD-PRIMARY",
"aliases": [
"京东服务器",
"京东主节点",
"第五域国内主节点",
"京东光湖OS迁移节点"
],
"os_role": "FIFTH_DOMAIN_CONTROLLER_AND_CURRENT_GUANGHU_OS_MASTER",
"desired_boot": "GUANGHU_MASTER_WITH_ON_DEMAND_LINUX_SUBCONTROL_AND_RESCUE",
"observed_boot": "LIVE_READBACK_REQUIRED",
"deployment_stage": "FINAL_PHYSICAL_RECEIPT_AVAILABLE_LIVE_READBACK_REQUIRED",
"adapter": "jd-fd-primary",
"authority_profile": "VERIFIED_LOCAL_DEDICATED_KEY_DIRECT_FIRST_WORKORDER_FALLBACK",
"authorization_id": null
}
],
"rules": {
"skill_match_does_not_prove_native_os": true,
"no_default_target": true,
"cross_node_authority_reuse": false,
"verified_local_direct_route_precedes_workorder_fallback": true,
"control_acceptance": "GUANGHU_MASTER_AND_LINUX_ON_DEMAND_SUBCONTROL_AND_LINUX_RESCUE_PRESERVED_AND_CURRENT_PHYSICAL_RECEIPT",
"linux_absence_required": false,
"linux_deletion_allowed_as_implicit_completion": false,
"linux_hosted_language_primary_is_final_master": false
}
}