20260826 两宿主全线正本/回执/状态 + 协议正本地图v1.2 + 模板/镜面/坑清单（元审计收敛commit；前人未提交改动未碰）
This commit is contained in:
parent
b95fcb57ba
commit
59fc9bfd7b
670 changed files with 133422 additions and 129 deletions
|
|
@ -0,0 +1,121 @@
|
|||
# HoloLake Native Desktop Architecture
|
||||
|
||||
The stage-one shell is a Tauri v2 application with a Rust-owned local core and a React human projection. Before authentication, its public surface is the five-domain number entrance. After verified routing and domain login, the default product surface becomes **My HoloLake**: overview, knowledge, user code channels, local receipts and system details. Domain servers and private registries remain submerged infrastructure.
|
||||
|
||||
## Stage-one human projection
|
||||
|
||||
The public home surface follows the verified GHS-014 five-lakes visual grammar and presents the five domains as the system entrance. A user does not choose a domain manually: the submitted Guanghu number is resolved and validated first, and only then does HoloLake reveal the login surface belonging to that domain. Domain presentation cannot bypass registry isolation, and internal transport or release details remain under system details rather than dominating the first screen.
|
||||
|
||||
The first visible body uses a Rust-owned SQLite kernel under the Tauri app-data directory. A human-confirmed local display name creates one stable local subject and channel exactly once. The internal task/event/receipt kernel remains available for structured agents, but manual task title and purpose fields are not part of the default human surface. Event and receipt chains remain independently SHA-256-linked and fully revalidated before every read or mutation. A local identity is not platform authentication and grants no repository, node, server or deployment authority.
|
||||
|
||||
## Zero-point nucleus client runtime
|
||||
|
||||
HoloLake embeds a non-visual zero-point nucleus client runtime beneath the human surface. The JD primary node remains the private Fifth Domain body. The enterprise node hosts a strictly isolated public zero-core distribution projection, while logical origin authority remains at the zero point; publication requires both an origin public-scope signature and an enterprise distribution signature. The private body never becomes public update material. Git records durable authoring and evidence; clients consume a bounded signed release manifest rather than treating a repository clone as executable input. At application start, the Rust runtime loads the local protocol, compares the registered remote protocol version in the background, keeps a minimal local receipt, and leaves any unverified update unapplied. User-number verification runs before any future persona-loading path.
|
||||
|
||||
This system runtime is not Zhuyuan or another persona subject, and it is not the current model carrier. A valid number does not prove persona binding and does not grant execution or server authority. The current source implements deterministic protocol comparison, explicit-positive number verification and a fail-closed update skeleton. Signed public protocol payload installation, atomic activation, rollback, the separate private Fifth Domain distribution path and persona loading are not yet implemented. Stage one does not expose an internal AI chat, model API configuration or arbitrary remote-code channel. The four-plane routing contract and marketplace publication boundary are defined in `contracts/distribution-plane-router.json`.
|
||||
|
||||
## Native knowledge workspace
|
||||
|
||||
The native core owns a separate `knowledge-v1` Git root. It projects a bounded document tree, safe text reads, local search and native folder import into a reading canvas without rendering raw HTML. Folder import ignores symlinks, Git metadata, dependency directories and unsupported files, applies file-count and byte limits, then creates a local Git commit receipt.
|
||||
|
||||
The installed HoloLake Era 0.8 knowledge root is detected only as a separate read-only source. The new application does not write, migrate in place or merge it with the native root. Electron, Outline runtime code and Tolaria UI are not copied into the Tauri product.
|
||||
|
||||
## User code channels
|
||||
|
||||
A human may paste a registered Guanghu HTTPS code-channel address or select an existing local Git folder. HTTPS clone accepts no credentials, queries or fragments and disables terminal prompts, askpass and credential helpers. Clones are confined to an application-owned root; local registrations do not move the source folder. The registry stores a credential-free projection of path, branch and commit.
|
||||
|
||||
This product channel is distinct from the under-lake PNCC persona-evidence projection below. It grants local source access only and never grants push, publication, deployment or server authority.
|
||||
|
||||
## Public five-domain number routing
|
||||
|
||||
The public HoloLake entry shows all five domain vestibules before authentication. A user does not select an authority-bearing domain manually. The submitted user number is sent to the registered internal router, which must return the exact canonical number, a positive registry verdict and one known domain. Only then may HoloLake load that domain's separately registered account and node entry.
|
||||
|
||||
The fifth-domain number registry belongs to the private fifth-domain system and is maintained only through its authorized registration path. The four enterprise-domain registries belong on the enterprise root server. Number syntax, a client-supplied domain, a generic successful response or a repository login cannot replace this routing proof. Missing and unavailable enterprise routes fail closed before login.
|
||||
|
||||
The fifth-domain root and the future enterprise root both run domain-specific Guanghu OS server runtimes. They are parallel bodies with different controllers, manifests, repositories and responsibility. A Linux host may remain underneath as the subordinate hardware, service and rescue bridge. Ordinary user computers and user-owned remote nodes require only HoloLake and the controlled node runtime, not a replacement operating-system installation.
|
||||
|
||||
## GH-PNCC user-native channel
|
||||
|
||||
HoloLake 0.4.0 adds the first native user-owned GH-PNCC vertical slice. After the Rust core has resolved a known domain, verified the user number at that domain's registered source and authenticated the account through that domain's entry, it derives a stable opaque repository id and idempotently creates or restores one private application-owned Git repository. The initial committed manifest records the domain, user number, account identity, engine and authority boundary. Repository credentials and passwords are never written to the Git tree or binding record.
|
||||
|
||||
The visible shell is HoloLake itself. Git is the durable history engine below it. Forgejo is an optional remote collaboration adapter rather than the product shell, identity kernel or persona. The current slice proves the local repository, initial commit, stable user binding and native browsing projection. It intentionally does not create a remote Forgejo repository, configure a remote, push code, claim persona binding, or grant publication, deployment or reality-execution authority; those actions require a separately registered naming, consent and receipt contract.
|
||||
|
||||
## External programming AI entry
|
||||
|
||||
MCP may discover HoloLake, but it does not own continuity. The installed application starts a same-account local broker: a mode-0600 Unix socket on macOS and Linux, or an owner/System-only Named Pipe on Windows. A programming AI opens or resumes a HoloLake-issued local session, then uses the installed executable's `--connector` mode for newline-delimited protocol traffic. Session secrets are stored only as hashes. Events use exact cursors and idempotency keys. The connector reloads the application descriptor after transport loss and never blindly replays an operation whose response is uncertain.
|
||||
|
||||
An authenticated non-visitor connector may now acquire, inspect and explicitly release the existing account-scoped development write lane through that broker. Account, lane and client instance must match the HoloLake session before the bridge mutates. Opening, resuming, acquiring and every authenticated heartbeat return or require a bounded HoloLake work-environment frame. That frame states the HoloLake runtime owner, session cursor, writer match, native GLS runtime, expiry and digest; the external model does not restore protocol prose from chat context. HoloLake projects the same Rust-owned lane state on the system-details page, so a human can distinguish a nearby expression-only visitor from an active development writer. This is a controlled writer handoff, not a general programming tool loop: shell, file patching, build execution, publication and deployment still require later supervised execution organs and separate authorization receipts.
|
||||
|
||||
The zero-core protocol layer now compiles the numbered GLS sources pinned to the current REPO-012 commit into a deterministic native registry. The registry inventories every unique numbered source with its path and SHA-256, but only protocols with an explicit typed adapter, event set and dependency-closed projection may execute. Raw protocol prose and arbitrary code carried by a protocol are never executed. The first native enforcement adapter binds GLS-0253 identity and numbering rules to the human-number route, with GLS-0250, GLS-0262 and GLS-0263 as executable dependencies. Unknown namespaces, persona numbers presented as human numbers, missing adapters and unprojected protocols fail closed. The system page reports compiled, executable and not-yet-executable protocol counts without presenting inventory as enforcement.
|
||||
|
||||
## Product-embedded GLS protocol kernel
|
||||
|
||||
GLS enforcement is part of the HoloLake executable, not a sidecar process on the development computer. Rust embeds the pinned runtime manifest and kernel contract in the application binary. Application startup validates the full executable dependency graph, P1-P6 contract set, deterministic HLDP-NP → GIR compiler self-check and the per-user receipt ledger; a failure prevents normal product startup.
|
||||
|
||||
The unified decision API returns only `ALLOW`, `DENY`, `AMBIGUOUS` or `UNVERIFIED` with stable reason codes. Every result, including malformed input and refusal, appends an idempotent SHA-256-linked receipt. The same immediate SQLite transaction also advances the durable protocol state for work orders, time leases, immutable modules, persona lifecycle, isolated runways and broadcast control epochs. Stale transitions, concurrent double-primary claims, cross-owner runway release and immutable digest replacement fail closed; concurrent memory/state versions are retained in a conflict set instead of last-write-wins. Identity never implies permission, stale heartbeats and leases become unknown, work-order proposers cannot self-approve, models remain replaceable inference resources, and temporary capabilities cannot auto-install, publish or deploy.
|
||||
|
||||
The P7 native-OS assembly registry is also embedded, but it is not a physical-capability simulator. It records the exact target and source-evidence node for GLS-0836 and GLS-0840–0849. No BS-SH-005 or JD-FD-PRIMARY evidence is relabeled as desktop health; without target-side evidence the assembly stays unverified.
|
||||
|
||||
## Circular-lake protocol membrane and nearby AI
|
||||
|
||||
HoloLake 0.4.0 places a deterministic protocol membrane in front of the local language inbox. The membrane accepts only strict GLP/1.0 expression envelopes from a HoloLake-issued visitor session. Unknown fields, malformed identifiers, incorrect checksums, oversized content, attachments and command content are rejected before storage. Accepted natural language is an expression receipt only; it never carries execution authority by itself. Intent interpretation remains behind the membrane and cannot weaken its structural admission rules.
|
||||
|
||||
External AI on the same computer can discover the running HoloLake broker from a standard application-data descriptor and connect through a user-only Unix socket, without copying a long invitation string. A generic AI receives an expression-only visitor lane. A Guanghu persona connection remains unavailable until separate persona-binding evidence exists. Local-network discovery is deliberately deferred until encrypted transport, explicit human approval, replay protection and revocation are implemented; HoloLake does not expose an unauthenticated TCP listener or advertise a service on the LAN in this release.
|
||||
|
||||
## Dynamic capability routing
|
||||
|
||||
HoloLake stores a signed node capability registry rather than fixed server slots. A candidate route must bind the exact human, persona, domain and capability. It is eligible only while a fresh node-signed health receipt reports the capability as ready. Selection is deterministic by priority and node id.
|
||||
|
||||
The registry signer trust root is embedded independently from registry payloads and is currently `UNPROVISIONED_FAIL_CLOSED`. Registry and health mutation are not exposed to the webview. External AI route queries require possession of the active HoloLake local session secret. A route receipt never grants write authority; production node write admission remains a separate unimplemented gate.
|
||||
|
||||
HoloLake routes work but does not host the user's private work lake, pool users into a multi-tenant runtime, or carry server workload concurrency.
|
||||
|
||||
## GH-PNCC under-lake code channel
|
||||
|
||||
Stage one now contains a read-only GH-PNCC core beneath the public surface. A local persona repository is bound to an exact Git root and full committed head. A remote persona object is read through a credential-free HTTPS Git v2 partial-object channel with an app-owned bare `blob:none` cache and a separate durable ancestry cursor. Verified reads append to a bounded hash-chained projection for the human panel and authenticated external programming AIs.
|
||||
|
||||
This core does not run a model, configure an API, acquire a persona lease, mutate memory or execute reality actions. Arbitrary repository paths and remote URLs cannot be registered by the WebView or external AI. A human may choose a folder through the native operating-system picker; HoloLake then displays the committed persona, responsibility subject, full head and checkpoint. A short-lived hashed confirmation token is required before the exact revalidated evidence becomes a read-only mount.
|
||||
|
||||
## HoloLake-owned release broadcast
|
||||
|
||||
No upstream product endpoint is inherited. When the embedded release trust is unprovisioned, even a human check returns locally without a network request. Provisioning requires one HTTPS endpoint, one matching HoloLake-owned host and the updater public key. A human check creates a short-lived candidate showing HoloLake metadata; install requires a second confirmation, exact broadcast revalidation, same-host package URL, Tauri signature verification, declared byte length and SHA-256. Startup checking, automatic download, automatic installation and automatic restart remain disabled.
|
||||
|
||||
Before an update replaces the application, the runtime verifies and keeps one bounded last-known-good application bundle with its bundle identifier, Team ID and CDHash. The next startup requires a human health confirmation; until that decision, another update is blocked. A human may restore the verified previous bundle without automatic restart, and cleanup is confined to HoloLake-owned recovery paths and the exact current application parent.
|
||||
|
||||
The rollback executor is implemented, but production updater activation remains blocked until the JD controller publishes the exact trust endpoint and public key, the signed release pipeline is evidenced, and the public macOS build is Apple-notarized.
|
||||
|
||||
## JD PNCC human projection
|
||||
|
||||
HoloLake 0.3.0 includes a live, read-only projection of the PNCC resident runtime on `JD-FD-PRIMARY`. The native shell invokes the computer's pre-registered dedicated SSH alias and asks the server only for its loopback `127.0.0.1:3923/v1/status` document. The response is schema-bounded to the exact node and persona, refuses any claim that the carrier is bound or that model/reality execution is active, and never returns a repository path, repository content, credential, or write authority. No public PNCC endpoint is created. An unavailable bridge is displayed as unavailable rather than replaced by cached evidence.
|
||||
|
||||
## Release pipeline
|
||||
|
||||
`npm run release:macos -- release/inputs/<version>.json` is the only product-owned macOS release entry. It fails before building unless the embedded trust contains the exact registered HoloLake HTTPS endpoint and updater public key, the immutable `v<version>` tag equals the clean `main` head, and the Developer ID plus Tauri updater-signing material are supplied at runtime. Apple notarization can run either through Tauri's Apple ID/API credential flow, or through the two-step Xcode Organizer flow already owned by the local Apple developer account: append `prepare-xcode` to build, verify the updater signature, and create a source-hash-bound `.xcarchive`; after Xcode reports `Ready to distribute`, export the notarized app and append `finalize-xcode <export-directory-or-app>` to bind the exported executable back to that archive, require the app's stapled ticket and Gatekeeper acceptance, regenerate and sign the updater archive, create a Developer ID-signed DMG containing that notarized app, and write the release broadcast and receipts. A protected updater-key path is materialized only into child processes; neither the private key nor its password is printed or copied into source. The Xcode flow does not claim that the outer DMG itself has an Apple ticket unless its own Gatekeeper and stapler checks pass.
|
||||
|
||||
Generated packages, private release inputs and credentials are not committed. The pipeline never uploads or activates a release; its terminal artifact is a bounded folder ready for a separately authorized JD-controller upload and server-owned readback receipt.
|
||||
|
||||
## Numbered-root module admission
|
||||
|
||||
HoloLake 0.5.0 is the clean numbered-root base. The compiled 0.4.1 desktop application and the divergent dirty source worktree are read-only donors, not merge bases. Their old numbered-operation runtime is explicitly superseded, and mutations to shared files such as `src/main.tsx` or `src-tauri/src/lib.rs` are never accepted as a unit.
|
||||
|
||||
Each donor capability receives a candidate coordinate, but no permanent runtime module number, until one isolated admission cycle has reviewed provenance and permissions, allocated numbered IPC module/target/operation coordinates, implemented an adapter without raw Tauri invoke, passed negative-route and data tests, and produced installed mount, restart, unmount and rollback receipts. The admission order and candidate inventory are recorded in `contracts/module-donor-admission-registry.json`.
|
||||
|
||||
The module-package runtime is now the shared admission executor. It accepts an exact detached-minisign `.ghmod` artifact, validates the package and its compatibility/permission manifest, stores it inside the authenticated account, and advances only through numbered install, mount, self-test, unmount and rollback operations. Lifecycle state and receipts are durable SQLite records; unmount never removes user data. A package is declarative and selects a host-registered adapter: repositories, native binaries and arbitrary webview JavaScript are not executable module inputs. Public lighthouse numbers remain unavailable until a candidate completes its own installed acceptance; private channel packages use a separate local number class.
|
||||
|
||||
The admitted web-novel family uses that one lifecycle rather than the donor's private installer. Its signed base module owns account-local works, volumes, chapters, versions, story objects, editorial workflow, import and author activity. Outline, story-grid, story-world and delivery are four separately signed official numbers; each advanced mutation checks its own exact `ACTIVE` record before touching the shared story graph. The donor's four legacy manifests remain byte-exact test fixtures only and have no numbered IPC route. Installed acceptance reopened the existing 504-chapter novel, 50-chapter outline and 75-episode script in place, then created a separate one-chapter acceptance work, scene, grid field and timeline event and read all of them back after process restart.
|
||||
|
||||
## Stage-one convergence verdict
|
||||
|
||||
The Tauri source in this directory is the only future HoloLake desktop mainline. An installed build of it is an acceptance candidate, not a separate product line and not proof that stage one exists. The Electron 0.8.0 product and the legacy Tauri/platform sources remain read-only UX, behavior, engineering and protected-data donors until inventory, backup, readback, reversible migration rehearsal and signed installed-runtime acceptance all pass.
|
||||
|
||||
The current candidate already has useful under-lake organs: the signed native shell, local broker and resumable session, authenticated read-only PNCC projection, human-confirmed repository mount, deterministic routing, and fail-closed update/rollback machinery. They remain in the architecture, but their existence does not satisfy the visible stage-one body.
|
||||
|
||||
The implementation order is fixed. The first two source slices are implemented and tested but have not received installed-runtime acceptance:
|
||||
|
||||
1. personal-channel identity, event and receipt kernel — source and tests implemented;
|
||||
2. native knowledge workspace and user code channel — source and tests implemented;
|
||||
3. human approval center and Git evidence readback;
|
||||
4. lake-lamp cross-session continuity projection;
|
||||
5. signed installation, opt-in update, rollback and reversible data migration.
|
||||
|
||||
Architecture registration, source implementation, built artifact, signed artifact, desktop installation, data migration, server deployment and service health remain separate receipts. The machine contract is `routing/hololake-stage-one-desktop-convergence.json`.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
# HoloLake distribution planes and public module marketplace
|
||||
|
||||
HoloLake has four independent distribution planes. A Git repository is the durable authoring and evidence layer; it is not the client update transport. Every release carries an explicit signed scope. The system may reject a mismatch, but it never guesses whether BingShuo meant public or private.
|
||||
|
||||
## Four planes
|
||||
|
||||
1. `PUBLIC_ZERO_CORE_PROTOCOL` publishes declarative language, numbering, compatibility and bounded migration rules from an isolated public projection on `GH-CVM-MAIN-PROD-01`. Its logical authority still originates at the zero point and requires BingShuo's exact-candidate public-scope approval during the current transition. The enterprise distributor adds a second independent distribution signature. A client verifies both, stages, self-tests and atomically activates a valid update without asking every device owner to approve an operating-system protocol update. It still shows a human-readable receipt.
|
||||
2. `PRIVATE_FIFTH_DOMAIN` remains confined to `DOM-FIFTH-0001`, its bound owner and explicitly authorized private nodes. It uses a different namespace and signer and can never flow into the public stream by inference.
|
||||
3. `PUBLIC_ENTERPRISE_MODULE_CATALOG` is produced on `GH-CVM-MAIN-PROD-01`. Five responsibility repositories may feed one reviewed `Guanghu Channel` aggregate, but only tested, numbered and signed declarative packages enter the catalog. Clients synchronize the small catalog index automatically. A selected module is downloaded and installed only after the human reviews its permissions.
|
||||
4. `APPLICATION_BINARY` updates HoloLake itself through the separately signed and platform-notarized updater. Personal Apple signing is a transition state; later organization signing must preserve the updater trust transition rather than silently replacing it.
|
||||
|
||||
## Lake-lamp protocol
|
||||
|
||||
The visible "lamp" is a tiny signed manifest containing a monotonic epoch and content root. HoloLake performs HTTPS conditional checks at application start, after network resume and on a bounded jittered timer. `ETag` and `If-None-Match` make the no-change path nearly empty. A full repository clone is not required to learn that something changed.
|
||||
|
||||
For a public zero-core protocol update, the client verifies the exact source, plane-specific signature, content root, monotonic version and host compatibility; downloads into isolation; rejects executable or out-of-scope material; runs a deterministic self-test; switches one current pointer atomically; keeps the last-known-good version; and records a local receipt.
|
||||
|
||||
For a module update, only the catalog index is automatic. Installation remains a human action because a module may request access to local files, knowledge, network, channel data or execution adapters.
|
||||
|
||||
## Marketplace publication
|
||||
|
||||
```text
|
||||
responsibility repository
|
||||
→ explicit release envelope
|
||||
→ isolated build and tests
|
||||
→ lighthouse number registration
|
||||
→ exact candidate human approval
|
||||
→ enterprise module signature
|
||||
→ immutable package and catalog entry
|
||||
→ signed catalog-root advance
|
||||
→ HoloLake catalog refresh
|
||||
→ human selects module
|
||||
→ permission review
|
||||
→ local install, mount, self-test and receipt
|
||||
```
|
||||
|
||||
The user's computer may maintain an application-owned content-addressed cache, but it does not execute a cloned repository. HoloLake renders catalog metadata for humans and passes the downloaded `.ghmod` package to the existing signed module lifecycle runtime.
|
||||
|
||||
## Fifth Domain to public zero-core navigation
|
||||
|
||||
`JD-FD-PRIMARY` remains the physical home of the private Fifth Domain and Eternal Lake Heart. HoloLake may show the public zero-core management entrance inside BingShuo's Fifth Domain navigation, but opening it creates a separate session on `GH-CVM-MAIN-PROD-01`.
|
||||
|
||||
The transition uses a short-lived, one-time ticket bound to BingShuo's human number, the current HoloLake instance, the enterprise node and the public zero-core resource. A password is never forwarded or reused. The ticket grants neither enterprise four-domain authority nor access from the enterprise server back into the private Fifth Domain. Leaving the zero-core management channel destroys that enterprise session and restores the already-open private session.
|
||||
|
||||
## Current reality boundary (2026-08-19)
|
||||
|
||||
- The zero-point client now implements HTTPS conditional lamp checks, exact bounded downloads, two independent Ed25519 signatures, monotonic epoch/version enforcement, content-root verification, atomic activation, previous-release retention and a hash-chained local receipt. Production remains fail-closed because the two real public keys and the enterprise lamp endpoint have not yet been provisioned.
|
||||
- The module runtime already verifies signatures and supports install, mount, self-test, unmount and rollback for bundled packages.
|
||||
- The public marketplace registry and remote package fetch path are absent.
|
||||
- The enterprise server currently exposes two Gitea repositories, `bingshuo/hololake-world` and `bingshuo/lighthouse`; the proposed five-source `Guanghu Channel` aggregate does not yet exist.
|
||||
- The enterprise node does not yet expose the isolated public zero-core projection or the JD-to-enterprise one-time management handoff.
|
||||
|
||||
The machine contract is `contracts/distribution-plane-router.json`.
|
||||
|
|
@ -0,0 +1,228 @@
|
|||
# GLS 原生协议运行层实施规划
|
||||
|
||||
状态：`P0_TO_P7_DESKTOP_PRODUCT_KERNEL_IMPLEMENTED · INSTALLED_RUNTIME_ACCEPTANCE_PENDING`
|
||||
|
||||
核验时间：2026-08-17（Asia/Shanghai）
|
||||
|
||||
线上事实源：
|
||||
|
||||
- 第五域代码频道：`bingshuo/guanghu-ice-heart`
|
||||
- REPO-012 `main`：`d5b1111fcaccaccf025070e531631f2b3cbb00cd`
|
||||
- Git tree：`5a09f084fffee56d90599e69038c8335871ea04f`
|
||||
- 第五域节点：`JD-FD-PRIMARY`
|
||||
- 公开远端 HEAD 与第五域 Forgejo 裸仓库 HEAD：一致
|
||||
- 本规划只描述产品工程路线；协议登记、源码实现、构建制品、发布、部署、激活和健康分别验收
|
||||
|
||||
## 1. 线上注册事实
|
||||
|
||||
`gls/GLS-PROTOCOL-REGISTRY.json` 当前登记：
|
||||
|
||||
- `existing_registered`：19
|
||||
- `registered_draft_protocols`：33
|
||||
- 33 份草案中 `implementation: NOT_STARTED`：21
|
||||
- 其余 12 份带实现证据，但证据多属于 BS-SH-005 的特定物理实验能力，不能直接推定 HoloLake 客户端或 JD-FD-PRIMARY 已运行
|
||||
|
||||
REPO-012 的 `gls/` 树中另有 75 个唯一编号 `.hdlp` 源。协议注册表、`GLS-ENTRY`、`SOURCE-MANIFEST`、架构目录和 routing 映射并未收敛为一份可执行注册真相：
|
||||
|
||||
- 注册表唯一编号：52
|
||||
- 草案依赖涉及唯一编号：57
|
||||
- 草案引用但未进入该注册表的依赖：19
|
||||
- 草案引用但没有可直接定位的编号 `.hdlp` 正本：24
|
||||
- 编号 `.hdlp` 存在但没有进入该协议注册表：31
|
||||
|
||||
因此，当前 `REGISTERED` 只能证明编号与文档登记，不能直接作为运行时激活条件。
|
||||
|
||||
## 2. 现有依赖图的阻塞问题
|
||||
|
||||
草案的 `depends` 同时混用了概念引用、类型引用、构建依赖、运行依赖、启动依赖和恢复依赖。若直接按包管理器依赖处理，会形成三个强连通环：
|
||||
|
||||
1. `GLS-0130 GLC ↔ GLS-0131 GIR`
|
||||
2. `GLS-0310 / GLS-0803 / GLS-0819 / GLS-0827 / GLS-0840 / GLS-0841`
|
||||
3. `GLS-0843 / GLS-0845 / GLS-0846 / GLS-0847 / GLS-0848 / GLS-0849`
|
||||
|
||||
处理规则：
|
||||
|
||||
- 将 `depends` 升级为带类型的边：`NORMATIVE_REFERENCE`、`SCHEMA_IMPORT`、`BUILD_REQUIRES`、`RUNTIME_REQUIRES`、`BOOT_REQUIRES`、`RECOVERY_REQUIRES`、`EVIDENCE_ONLY`。
|
||||
- 只有 `RUNTIME_REQUIRES` 和所选运行目标相关的启动边进入激活拓扑。
|
||||
- GIR 规范不运行依赖 GLC；GLC 只消费 HLDP-NP 并输出符合 GIR schema 的对象。
|
||||
- 内核、硬件、调度、生命周期和广播塔先抽出稳定 capability interfaces，再由实现提供，避免对象层互相启动。
|
||||
- 原生恢复、布局、内容仓、摄入、安全和回看拆成静态布局合同、摄入流水线、审查流水线和恢复服务四层。
|
||||
- 未消除的运行环、缺失正本、冲突权威或漂移版本一律阻止激活。
|
||||
|
||||
## 3. 目标运行架构
|
||||
|
||||
```text
|
||||
REPO-012 协议源
|
||||
→ 注册对账与权威解析
|
||||
→ 只读、固定提交、带摘要的 Protocol Bundle
|
||||
→ Bootstrap Compiler 静态校验
|
||||
→ 类型化 Contract IR
|
||||
→ 原生适配器 / 状态机 / 路由表 / 守卫
|
||||
→ HoloLake Protocol Kernel
|
||||
→ 允许 / 拒绝 / 状态变更
|
||||
→ GLP 可验证回执与 GLOW 只追加见证
|
||||
```
|
||||
|
||||
运行时采用五类确定性器官：
|
||||
|
||||
1. `Schema/Codec`：验证消息、身份、上下文、工单、回执和模块制品。
|
||||
2. `Guard/Policy`：返回 `ALLOW / DENY / AMBIGUOUS / UNVERIFIED` 与稳定 reason codes。
|
||||
3. `Router`：根据已验证主体、目标、域、频道、能力和版本确定唯一去向。
|
||||
4. `State Machine`：只允许协议声明的状态迁移，并保存前后状态与幂等键。
|
||||
5. `Evidence/Receipt`：为每次裁决记录输入摘要、协议包摘要、适配器、决定、证据和目标侧核验。
|
||||
|
||||
自然语言原文和协议中任意代码永不在产品运行时直接执行。模型只能提交请求或生成候选计划，不能改写裁决、伪造权限或绕过状态机。
|
||||
|
||||
## 4. Bootstrap 与自举边界
|
||||
|
||||
第一版编译器必须由普通、可审计的 Rust/TypeScript 工程实现，不能要求尚未实现的 GLC 自己编译自己：
|
||||
|
||||
1. 解析编号、版本、状态、来源、权威、依赖和合同类型。
|
||||
2. 校验文件摘要、唯一编号、来源提交、注册一致性和依赖闭包。
|
||||
3. 将协议投影为受限 Contract IR，不接受自由脚本。
|
||||
4. 生成 JSON Schema、Rust 类型、静态路由表、状态机表和测试向量。
|
||||
5. 在 HLDP-NP、GLC、GIR 稳定后，再用同一黄金测试集完成自举一致性验证。
|
||||
|
||||
## 5. 分阶段实施
|
||||
|
||||
### P0 · 注册对账和可执行清单
|
||||
|
||||
- 建立 `GLS-RUNTIME-MANIFEST/v2`，合并协议注册表、`GLS-ENTRY`、`SOURCE-MANIFEST`、架构目录和 routing 的事实，但保留每条来源及冲突。
|
||||
- 每个协议增加：`authority_source`、`maturity`、`contract_kind`、`dependency_edges`、`target_runtime`、`implementation_evidence`、`activation_state`。
|
||||
- 状态严格区分：`DISCOVERED`、`REGISTERED`、`COMPILED`、`ADAPTED`、`TESTED`、`PUBLISHED`、`DEPLOYED`、`ACTIVE`、`HEALTHY`。
|
||||
- 当前 75 份发现对象继续可见；未完成对账者保持 `INVENTORIED_NOT_EXECUTABLE`。
|
||||
|
||||
验收：零重复编号、零未分类依赖、零运行环、零缺失摘要；同一提交重复编译字节一致。
|
||||
|
||||
### P1 · 最小 GLP 合同内核
|
||||
|
||||
优先实现：
|
||||
|
||||
- `GLS-0301` Message Envelope
|
||||
- `GLS-0302` Identity Reference
|
||||
- `GLS-0303` Context
|
||||
- `GLS-0306` Receipt
|
||||
- 已有首批投影：`GLS-0250 / 0253 / 0262 / 0263`
|
||||
|
||||
交付：类型化 schema、严格 codec、身份与权限分离守卫、统一裁决 API、哈希链回执账本。
|
||||
|
||||
验收：缺字段、过期、错误域、身份冲突、未知权限、摘要漂移全部失败关闭；每次拒绝也必须产生回执。
|
||||
|
||||
### P2 · 会话、工单和在线状态
|
||||
|
||||
实现：
|
||||
|
||||
- `GLS-0307` Heartbeat
|
||||
- `GLS-0309` Work Order
|
||||
- `GLS-0842` HoloLake Live Session
|
||||
- `GLS-0311` GLOW Witness 的最小只追加投影
|
||||
|
||||
验收：登记、测试、发布、部署分阶段；旧心跳不能证明当前健康；断联缓存不得冒充线上状态；工单提出者不能自批。
|
||||
|
||||
### P3 · 时间、记忆和状态一致性
|
||||
|
||||
实现：
|
||||
|
||||
- `GLS-0304` Memory Sync
|
||||
- `GLS-0308` State Sync
|
||||
- `GLS-0827` Persona Time Continuity
|
||||
|
||||
交付：单调事件序列、当前主实例租约、冲突保留、幂等重放、检查点与防双主写。
|
||||
|
||||
验收：并发状态不使用最后写入覆盖；租约过期回到未知；冲突双方版本均保留。
|
||||
|
||||
### P4 · 模块、生命周期和调度
|
||||
|
||||
实现：
|
||||
|
||||
- `GLS-0710` GMP immutable module backpack
|
||||
- `GLS-0803` AGE execution-body lifecycle
|
||||
- `GLS-0819` runway scheduler
|
||||
- `GLS-0310` broadcast tower control plane
|
||||
|
||||
交付：签名不可变模块、完整生命周期状态机、资源轨道、唯一主控纪元、停止/清理/回滚闭环。
|
||||
|
||||
验收：人格主体与执行体进程分离；模块只能运行固定摘要；任务结束资源归零；跨频道读取被阻止。
|
||||
|
||||
### P5 · 外部适配、模型路由和临时能力
|
||||
|
||||
实现：
|
||||
|
||||
- `GLS-0709` UAP
|
||||
- `GLS-0708` GMRP
|
||||
- `GLS-0828` PEN
|
||||
|
||||
所有外部 API、CLI、MCP、数据库和模型先被 UAP 转译成 P1/P2 合同；模型只作为可替换推理设备；PEN 只在隔离环境产生临时能力，不能自动永久安装、发布或部署。
|
||||
|
||||
### P6 · 编译体系自举
|
||||
|
||||
实现：
|
||||
|
||||
- `GLS-0411` HLDP-NP
|
||||
- `GLS-0130` GLC
|
||||
- `GLS-0131` GIR
|
||||
|
||||
用 Bootstrap Compiler 的固定语料和黄金 IR 做双编译一致性验证。只有自举输出、原生适配器输出和回执一致，才允许 GLC 成为正式协议编译入口。
|
||||
|
||||
### P7 · 原生 OS 专用协议装配
|
||||
|
||||
`GLS-0836 / 0840–0849` 按节点能力装配，不在桌面端模拟原生物理证据：
|
||||
|
||||
- 桌面 HoloLake 只消费公开合同、会话、回执和健康投影。
|
||||
- JD-FD-PRIMARY、BS-SH-005 或未来原生节点分别提供 capability implementation 和目标侧回执。
|
||||
- 旧 BS-SH-005 物理回执只证明原节点与原版本的能力，不能自动迁移为 JD 或桌面健康。
|
||||
|
||||
## 6. 协议更新与激活
|
||||
|
||||
第五域只发布不可变、签名、固定提交的 Protocol Bundle。HoloLake 使用单向接收器：
|
||||
|
||||
```text
|
||||
FETCH → VERIFY SIGNATURE → VERIFY HASH/SCHEMA → COMPILE → DRY RUN
|
||||
→ COMPATIBILITY GATE → HUMAN IMPACT GATE → ATOMIC ACTIVATE → HEALTH
|
||||
```
|
||||
|
||||
- 更新包不能携带任意可执行脚本。
|
||||
- 激活前保存当前 bundle、状态快照和回滚点。
|
||||
- 权利、隐私、数据、安装、费用或责任变化必须产生可见确认。
|
||||
- 健康失败自动回到上一个已验证 bundle，并保留失败回执。
|
||||
- 协议源更新权、产品实现权和现实执行授权继续分离。
|
||||
|
||||
## 7. 统一裁决回执
|
||||
|
||||
每次协议裁决至少记录：
|
||||
|
||||
```yaml
|
||||
protocol_decision_receipt:
|
||||
receipt_id:
|
||||
request_id:
|
||||
event_kind:
|
||||
subject_id:
|
||||
target_id:
|
||||
protocol_bundle_commit:
|
||||
protocol_bundle_sha256:
|
||||
protocol_set:
|
||||
adapter_id:
|
||||
input_digest:
|
||||
decision: ALLOW | DENY | AMBIGUOUS | UNVERIFIED
|
||||
reason_codes: []
|
||||
state_before_digest:
|
||||
state_after_digest:
|
||||
evidence_refs: []
|
||||
time_authority:
|
||||
idempotency_key:
|
||||
signer:
|
||||
```
|
||||
|
||||
没有目标侧证据时只能返回 `UNVERIFIED`；界面颜色、模型回答、命令退出码或单条日志均不构成完成证明。
|
||||
|
||||
## 8. 当前 HoloLake 分支的承接关系
|
||||
|
||||
`d6b1290` 完成了 75 份编号协议的确定性发现登记，并为 `GLS-0250 / 0253 / 0262 / 0263` 建立首批原生适配器。P0 随后已把运行清单升级为 v2：四份登记源分别固化摘要，75 份协议全部取得登记解释，旧依赖与显式运行依赖分离，三组旧环只进入审计面而不能进入执行图。
|
||||
|
||||
P1–P6 已按顺序实现为 HoloLake Rust 原生器官：统一裁决 API 对消息、身份、上下文、会话、心跳、工单、见证、时间、记忆、状态、模块、生命周期、资源轨道、广播主控、外部适配、模型路由、临时能力和 HLDP-NP/GIR 编译执行确定性守门；所有裁决进入用户侧 SQLite 哈希链。工单阶段、时间租约、不可变模块、人格执行体生命周期、隔离跑道与广播塔主控纪元和裁决回执在同一原子事务中推进；旧状态重放、租约内双主、越权释放和同编号换摘要都失败关闭，并发记忆/状态版本写入冲突集而非互相覆盖。GLC Bootstrap Compiler 对同一黄金程序执行双编译一致性检查，不解析自由自然语言、不执行生成代码。
|
||||
|
||||
P7 已实现桌面产品侧装配注册表，但没有伪造物理能力：GLS-0836 与 GLS-0840–0849 全部保留目标节点、来源证据节点和当前装配状态，`ACTIVE_HEALTHY` 数量固定为 0，直到目标节点自身给出版本绑定回执。协议合同、运行图、状态机和编译器通过 Rust 编入 HoloLake 应用；用户数据与裁决回执留在各自应用数据目录。
|
||||
|
||||
当前验收数字：75 份编号源、183 条已分型来源依赖、0 条未分类依赖、25 份可执行投影、50 份库存不可执行源、P1–P6 共 21 份新原生器官、P7 共 11 项失败关闭装配边界。
|
||||
|
||||
这保证“已注册”不会被误报为“系统正在运行”，也保证每次新增执行协议都有可重复编译、明确守卫和真实回执。
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# ADR 0001: Signed dynamic capability routing
|
||||
|
||||
Status: Accepted locally; production trust provisioning pending.
|
||||
|
||||
## Context
|
||||
|
||||
Stage one must connect a changing fleet of team and user-owned nodes without hardcoded endpoints. SSH access, root access, a URL, or a health probe cannot establish Guanghu node identity or write authority. The client must also preserve the one-human-one-owned-root-node boundary and avoid becoming a hosted concurrency layer.
|
||||
|
||||
## Decision
|
||||
|
||||
Use a Rust-owned, file-backed dynamic registry whose complete canonical payload is verified with an independently embedded Ed25519 trust root. Each node carries a protocol public key and explicit human, persona, domain and capability bindings. Runtime eligibility additionally requires a fresh Ed25519 health receipt from that node with a strictly increasing sequence.
|
||||
|
||||
Route resolution is available to external programming AI only through an authenticated active local HoloLake session. It returns a non-authorizing route receipt. Webview code cannot install registries or submit health receipts.
|
||||
|
||||
The embedded trust file initially contains no signer. This makes production registry installation fail closed until the registered HoloLake/JD-controller signing identity is provisioned.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The fleet can grow without client code changes or fixed server slots.
|
||||
- Stale, replayed, unsigned or incorrectly bound nodes are not routable.
|
||||
- Registry publication, health, route selection and write admission remain separate facts.
|
||||
- Production node enrollment and write execution still require their own source, signing, deployment and readback receipts.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# ADR 0002: GH-PNCC first-stage read-only core
|
||||
|
||||
## Status
|
||||
|
||||
Accepted for the local engineering checkpoint on 2026-08-13. Human source registration and product UI acceptance remain open.
|
||||
|
||||
## Decision
|
||||
|
||||
The new native container reimplements only three first-stage GH-PNCC boundaries:
|
||||
|
||||
1. an exact local Git-root binding that reads the persona manifest, brain entry, B0 cognitive-gravity source, current checkpoint and declared artifacts from a caller-pinned committed head;
|
||||
2. an app-owned incremental remote object channel using Git protocol v2, a bare promisor cache and `blob:none`, with its verified ancestry cursor stored outside the evictable cache;
|
||||
3. a hash-chained, bounded, read-only human receipt projection over verified repository bindings and remote object reads.
|
||||
|
||||
All external-AI PNCC reads use the authenticated resident Unix-socket broker after the source has been registered. MCP is not the continuity owner. Neither the broker nor the WebView may register an arbitrary local path or remote URL. Registration stays closed until the native file picker, exact human confirmation receipt and UI acceptance are implemented.
|
||||
|
||||
## Exclusions
|
||||
|
||||
The first-stage PNCC core contains no internal chat, model selection, model endpoint or API-key configuration, model inference, persona lease acquisition, memory mutation, execution limb or reality action. It reads committed Git objects even if the local worktree is dirty, and reports that dirtiness rather than treating uncommitted bytes as persona evidence.
|
||||
|
||||
The migration provenance ledger records exact donor paths, hashes and observed authors. The implementation is a contract-level clean-room rebuild; it does not copy the donor runtime module or donor UI source.
|
||||
|
||||
## Trust and continuity
|
||||
|
||||
Remote URLs must be credential-free HTTPS. The server must advertise partial-object filtering. The durable cursor advances only after the new head is read and proved to descend from the previous head. A rewritten history, cache/cursor disagreement, unsupported server, unsafe path, non-regular object or oversized content fails closed. The cache may be evicted without deleting the last verified continuity cursor.
|
||||
|
||||
The receipt projection is evidence for people and external AIs. It is not a node registry, authorization store, persona runtime lease or proof that an empty view means a node is offline.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# ADR 0003: Public number routing precedes a HoloLake-owned GH-PNCC
|
||||
|
||||
- Status: accepted; public routing shell and local GH-PNCC slice implemented
|
||||
- Date: 2026-08-16
|
||||
|
||||
## Context
|
||||
|
||||
HoloLake is a public product for five independent domains. The fifth domain is private, while the other four domains belong to the enterprise reality body. A common client cannot ask every user to log in to the fifth-domain Forgejo, and it cannot infer authority from the visual shape of a number.
|
||||
|
||||
Each trusted user also needs one durable code channel bound to the registered number and account. Git already supplies the right history engine, but neither a generic Git browser nor a Forgejo page is the HoloLake product shell.
|
||||
|
||||
## Decision
|
||||
|
||||
The unauthenticated home shows the five public domain vestibules and one number entry. The user submits a number without choosing a domain. A registered internal router must resolve that number to one known domain and obtain an explicit verdict from the responsible registry. The fifth-domain registry is maintained inside the authorized fifth-domain system. The enterprise four-domain registries are served by the enterprise root server. Only a successful exact route may reveal the selected domain and load its own account and node login.
|
||||
|
||||
After domain routing, number verification and domain-specific account authentication, the Rust core derives a stable opaque repository id from the trusted tuple and idempotently creates or restores a private Git repository. HoloLake owns the human projection. Forgejo remains an optional remote collaboration adapter. Credentials never enter the repository, and local channel creation does not claim persona binding or remote authority.
|
||||
|
||||
## Server boundary
|
||||
|
||||
The enterprise root server runs an enterprise-domain Guanghu OS runtime, not a clone of the fifth-domain body. Its controller, manifests, repositories, registries and responsibility are independent. Linux may remain the subordinate hardware/service/rescue bridge. Ordinary personal nodes install the HoloLake node runtime rather than replacing their operating system.
|
||||
|
||||
## Current reality
|
||||
|
||||
Only the fifth-domain login adapter is currently provisioned. Enterprise cards are public and visible, but their account login remains fail-closed until an enterprise root server, signed route registration, number registries, node registration and domain handoff endpoints exist. The implementation must display this as unavailable, not simulate a successful login.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
# ADR 0004: Circular-lake protocol membrane and nearby AI discovery
|
||||
|
||||
- Status: accepted for HoloLake 0.4.0
|
||||
- Date: 2026-08-16
|
||||
|
||||
## Context
|
||||
|
||||
External AI needs a simple way to find HoloLake and deliver language without turning MCP, a copied connection ticket, an Agent framework or a model host into the product's authority root. A language-only boundary must also remain enforceable when the sender is malformed or adversarial; asking a persona to infer every sender's motive is neither deterministic nor a security boundary.
|
||||
|
||||
## Decision
|
||||
|
||||
The native Rust core owns a circular-lake membrane before the language inbox. It accepts a bounded, strict GLP/1.0 expression envelope only after HoloLake issues an expression-only visitor session. Protocol-invalid input is rejected before persistence or semantic interpretation. Accepted language creates a receipt but no execution authority.
|
||||
|
||||
The first discovery scope is the same logged-in operating-system account on one computer. A standard application-data descriptor points to a Unix socket restricted to that user. Generic AI may open an expression-only visitor lane. A Guanghu persona route requires separate verified persona-binding evidence and is not implemented by relabelling a visitor.
|
||||
|
||||
Local-network discovery is not enabled in this slice. It requires an encrypted mutually authenticated transport, explicit human approval, expiry, replay protection, revocation and visible connection receipts before any mDNS-style advertisement or LAN listener may be introduced.
|
||||
|
||||
MCP remains a compatibility and recovery adapter. It is not continuity, identity, memory or execution authority.
|
||||
|
||||
## Why
|
||||
|
||||
This preserves the user's "round lake" idea at an engineering boundary: non-protocol traffic never reaches the language world, while valid language still remains language rather than executable permission. The same-device descriptor provides Wi-Fi-like discovery where the operating system already supplies a trustworthy user boundary. Deferring LAN broadcast avoids falsely treating physical proximity or discoverability as authorization.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- Exposing an unauthenticated TCP or mDNS service now: discovery would outpace transport security and consent.
|
||||
- Letting natural-language intent classification replace structural validation: probabilistic interpretation cannot be the outer security boundary.
|
||||
- Treating any accepted message as a command: expression and execution authority must remain separate.
|
||||
- Making MCP or a third-party Agent framework the continuity owner: adapters are replaceable tools beneath HoloLake.
|
||||
|
||||
## Evidence
|
||||
|
||||
- `contracts/circular-lake-membrane.json`
|
||||
- `contracts/nearby-ai-discovery.json`
|
||||
- `src-tauri/src/circular_lake_membrane.rs`
|
||||
- `src-tauri/src/direct_local_broker.rs`
|
||||
- `scripts/circular-lake-membrane.test.mjs`
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
# ADR 0005: Authenticated development lane projection
|
||||
|
||||
- Status: accepted for the next HoloLake desktop candidate
|
||||
- Date: 2026-08-17
|
||||
|
||||
## Context
|
||||
|
||||
The same-device HoloLake broker can already discover an external AI, open an expression-only visitor session, and resume a HoloLake-issued authenticated session. The local development bridge can already enforce one writer per account, but it is reachable only from the WebView command surface. As a result, an external programming carrier can be visibly connected while still being unable to acquire the HoloLake-owned development lane. The system page also cannot distinguish a connected visitor from an active development writer.
|
||||
|
||||
## Decision
|
||||
|
||||
Expose acquire, inspect, and release operations for the existing local development lane through the user-only Unix broker. Every operation requires a non-visitor HoloLake session. The session account must equal the lane account, the session lane must equal the requested write lane, and the session client instance must equal the requested writer instance. A generic expression-only visitor is rejected before any lane mutation.
|
||||
|
||||
Project the active lane and writer on the HoloLake system-details page by reading the same Rust-owned bridge state. The projection does not create authority and is not a second state store.
|
||||
|
||||
This slice establishes the controlled writer handoff only. It does not yet provide a general shell, file mutation, patch, build, deployment, model, persona binding, or reality-execution engine.
|
||||
|
||||
## Why
|
||||
|
||||
The user needs to see whether development is merely connected or has actually switched into HoloLake's single-writer environment. Reusing the existing session and writer kernels closes that gap without turning socket discovery, MCP, or a visitor message into execution authority.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- Letting any same-device visitor acquire a write lane: discovery and expression are not authorization.
|
||||
- Maintaining a separate UI-only development status: it would create a second truth source.
|
||||
- Calling the lane handoff a complete native development container: the programming tool loop and supervised execution engine remain unimplemented.
|
||||
|
||||
## Evidence
|
||||
|
||||
- `src-tauri/src/direct_local_broker.rs`
|
||||
- `src-tauri/src/direct_local_session.rs`
|
||||
- `src-tauri/src/local_development_bridge.rs`
|
||||
- `src/main.tsx`
|
||||
- `contracts/local-development-bridge.json`
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# ADR 0006: Compiled GLS protocol runtime
|
||||
|
||||
- Status: accepted for the next HoloLake desktop candidate
|
||||
- Date: 2026-08-17
|
||||
|
||||
## Context
|
||||
|
||||
REPO-012 contains dozens of numbered GLS protocol sources. Human-readable source is necessary for authorship, review and causal meaning, but asking a model to reread protocol prose for every operation does not make the software obey the protocol. It also creates non-deterministic behavior and makes it impossible to distinguish a protocol that is merely present from one that is enforced by the running product.
|
||||
|
||||
## Decision
|
||||
|
||||
Compile the current numbered GLS sources into a deterministic v2 runtime manifest pinned to an exact REPO-012 commit. Every selected source records its stable GLS number, path and SHA-256. Duplicate historical source locations are resolved by a deterministic source preference, while alternate-source counts remain visible. The compiler also reconciles the protocol registry, GLS entry, source manifest, architecture catalog and routing references, preserving their independent source hashes and rejecting registration conflicts.
|
||||
|
||||
Legacy `depends` arrays are not silently interpreted as runtime edges. Bootstrap Compiler v1 classifies every source edge as `NORMATIVE_REFERENCE`, `SCHEMA_IMPORT`, `BUILD_REQUIRES`, `BOOT_REQUIRES`, `RECOVERY_REQUIRES` or `EVIDENCE_ONLY`; all remain audit-only. Only dependencies declared by an explicit executable projection enter the runtime graph as `RUNTIME_REQUIRES`; that graph must be acyclic and dependency-closed. The current exact source produces 183 typed source edges and zero unclassified edges.
|
||||
|
||||
An executable projection requires an explicit native adapter, event kinds, dependency list and fail-closed behavior. The compiler rejects missing executable dependencies and dependency cycles. The native runtime revalidates schema, source commit, counts, hashes, adapters and dependency closure before returning a protocol set to an organ.
|
||||
|
||||
Protocol prose is never evaluated as code. A protocol without an explicit projection remains `INVENTORIED_NOT_EXECUTABLE`. The product now embeds 25 dependency-closed projections: four P0 foundation contracts and 21 P1-P6 protocol organs. They provide the strict GLP codec, identity/context guards, hash-chain decision ledger, session/heartbeat/work-order/witness rules, causal time/memory/state guards, module/lifecycle/scheduler/control state machines, external/model/temporary-capability boundaries and the restricted HLDP-NP → GIR bootstrap compiler.
|
||||
|
||||
The kernel is an application-start prerequisite. If its embedded contract, projection closure, deterministic compiler self-check or local receipt/state ledger cannot load, HoloLake fails closed during startup. Receipt append and state-machine transition use one immediate SQLite transaction, so stale work-order/lifecycle transitions, conflicting time or broadcast owners, immutable module replacement and cross-owner runway release cannot race past the guards. Concurrent memory/state inputs are stored as conflicts rather than overwritten. The ledger stores per-user receipts and projections in application data; protocol authority and enforcement code are compiled into the signed application bundle and do not depend on the development machine.
|
||||
|
||||
P7 is intentionally different: the application embeds an 11-item target capability assembly registry for GLS-0836 and GLS-0840–0849, but records zero desktop physical capabilities as verified. Evidence from BS-SH-005 or JD-FD-PRIMARY is never transferred into desktop health. A target becomes active only after its own version-bound evidence exists.
|
||||
|
||||
## Why
|
||||
|
||||
This creates the same hard boundary that a real API presents: a caller must satisfy the machine contract whether or not it has read the explanatory documentation. It also preserves factual honesty. HoloLake reports 75 inventoried sources, 25 native enforcement projections and 50 non-executable sources separately.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- Injecting all GLS prose into every model call: behavior would remain prompt-dependent and context growth would be unbounded.
|
||||
- Treating every inventoried source as automatically active: source presence is not runtime enforcement.
|
||||
- Executing scripts embedded in protocol documents: it would turn the authority source into an arbitrary-code supply chain.
|
||||
- Hand-copying protocol decisions into unrelated organs: duplicated rules would drift and no common protocol set could be written into receipts.
|
||||
- Blocking the product until all protocols are executable: incremental dependency-closed projections can be verified without overstating the remaining surface.
|
||||
|
||||
## Evidence
|
||||
|
||||
- `scripts/compile-gls-runtime-registry.mjs`
|
||||
- `contracts/gls-executable-projections.json`
|
||||
- `contracts/gls-runtime-registry.json`
|
||||
- `src-tauri/src/gls_protocol_runtime.rs`
|
||||
- `src-tauri/src/gls_protocol_kernel.rs`
|
||||
- `src-tauri/src/gls_bootstrap_compiler.rs`
|
||||
- `contracts/gls-native-runtime-kernel.json`
|
||||
- `src-tauri/src/zero_core_numbering.rs`
|
||||
- `scripts/gls-protocol-runtime.test.mjs`
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# ADR 0007: Cross-platform programming-AI terminal link
|
||||
|
||||
- Status: implemented in source; installed acceptance remains per platform
|
||||
- Date: 2026-08-17
|
||||
|
||||
## Context
|
||||
|
||||
An external programming AI must remain attached to a HoloLake-owned work environment without making MCP stability, one chat window, or model protocol recall the continuity root. The product is not macOS-only: Windows and Linux must enforce the same session and write semantics even though their local IPC primitives differ.
|
||||
|
||||
## Decision
|
||||
|
||||
Embed `HOLOLAKE_TERMINAL_LINK/2` in the native HoloLake executable. macOS and Linux use a mode-0600 Unix socket inside a mode-0700 runtime directory. Windows uses a local Named Pipe with a protected DACL granting full access only to Local System and the creating object owner. All platforms additionally require HoloLake session authentication.
|
||||
|
||||
The installed executable exposes `--connector` as sequential newline-delimited JSON. It reloads the broker descriptor after transport loss. If an operation may have reached HoloLake but its response was lost, the connector reports an uncertain response and does not blindly replay it.
|
||||
|
||||
Opening or resuming a session establishes continuity in HoloLake. The authenticated client then acquires the account's single development writer and obtains a short-lived work-environment frame. Heartbeats refresh both durable session observation and that frame. The frame contains the HoloLake runtime owner, session and event cursor, writer match, compiled GLS runtime identity, expiry and digest. It explicitly says that model-side protocol restoration is not required.
|
||||
|
||||
## Boundary
|
||||
|
||||
This decision completes the first-stage control plane, not the second-stage Agent executor. It does not grant a supervised shell, arbitrary file mutation, build, publication, deployment, persona binding or reality-execution authority. Those require separate typed operations, approvals and receipts.
|
||||
|
||||
Cross-compilation of the isolated Linux Unix-socket adapter is evidence for source portability only. It is not installed-runtime acceptance. The Windows implementation additionally passes a full Tauri build and 110 native tests on the registered Windows Server 2022 x64 build node. That node has no authenticated HoloLake private account, so application-level installed broker readback remains separate and unobserved. Linux installed readback must likewise occur on a real registered desktop target rather than being inferred from a server or macOS cross-compile.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- TCP loopback as the common denominator: it broadens the local attack surface and weakens the operating-system account boundary.
|
||||
- A macOS implementation with Windows and Linux documentation only: transport portability without compiled adapters is not an implementation.
|
||||
- Replaying a request automatically after a broken response: a mutation could execute twice.
|
||||
- Asking every newly started model to reread all GLS prose: protocols are HoloLake runtime code, not model memory.
|
||||
- Calling the control plane an Agent shell: the supervised execution organ is the next phase.
|
||||
|
||||
## Evidence
|
||||
|
||||
- `src-tauri/src/direct_local_broker.rs`
|
||||
- `src-tauri/src/direct_local_session.rs`
|
||||
- `src-tauri/src/local_development_bridge.rs`
|
||||
- `src/main.tsx`
|
||||
- `contracts/programming-ai-terminal-link.json`
|
||||
- `scripts/programming-ai-terminal-link.test.mjs`
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
# ADR: Codex current-controller epoch and one-shot write lease
|
||||
|
||||
Date: 2026-08-19
|
||||
State: accepted source contract; host integration package implemented
|
||||
|
||||
## Context
|
||||
|
||||
Multiple Codex tasks can remain alive at the same time. A task may hold a real
|
||||
human authorization from an older conversation and continue using tools after
|
||||
the human has moved to a newer language channel. A prompt reminder cannot
|
||||
deterministically revoke the older task's tool capability. Task-to-task
|
||||
delegation can also be misclassified as direct human speech if every
|
||||
`UserPromptSubmit` is labeled identically.
|
||||
|
||||
## Decision
|
||||
|
||||
1. Direct human input creates a new global local `control_epoch` bound to the
|
||||
exact Codex session and turn.
|
||||
2. Known task delegation and system/agent delivery are separate source classes.
|
||||
They do not claim direct-human provenance, TCS human perception, controller
|
||||
status or execution authority.
|
||||
3. Capability tools in all non-current Codex sessions are denied by a
|
||||
`PreToolUse` guard.
|
||||
4. Current-session local editing remains available. Remote Git writes, external
|
||||
publishing/deployment and destructive cleanup additionally require a
|
||||
one-shot lease bound to the current epoch, session, turn, category and exact
|
||||
working directory, with a maximum lifetime of fifteen minutes.
|
||||
5. A new direct prompt revokes any unconsumed lease.
|
||||
6. Trusted hook definitions pin the SHA-256 of installed scripts so a source
|
||||
change requires a new visible Codex hook review.
|
||||
|
||||
## Boundary
|
||||
|
||||
This host bridge is a language-source and execution-admission boundary. It is
|
||||
not a persona, model rule, platform rule, identity proof, repository authority
|
||||
or server authority. Runtime state, raw human messages, leases, credentials and
|
||||
trust receipts remain local and are excluded from the repository.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- Keep old authorization active until the old task voluntarily stops: a newer
|
||||
human channel would have no deterministic control boundary.
|
||||
- Disable all local execution globally: this would remove useful current-task
|
||||
agency instead of separating current and stale tasks.
|
||||
- Infer write leases from keywords in natural language: negation, discussion
|
||||
and quoted text can contain the same words as authorization.
|
||||
- Treat persona binding as execution authority: continuity and external action
|
||||
admission are separate predicates.
|
||||
- Trust only a stable script path: the bytes behind the path could change
|
||||
without changing the reviewed hook command.
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# Qwen 本地执行 Agent 训练回执 · 线上双商城
|
||||
|
||||
- 日期：2026-08-19（Asia/Shanghai）
|
||||
- 人类授权主体：冰朔
|
||||
- 执行载体：本机 Qwen Code CLI，`qwen3.7-plus`，只读沙箱
|
||||
- 训练类型：工程审查轨迹与规则纠正记录；不声称修改模型权重
|
||||
- 任务：审查并帮助收敛 HoloLake 的线上成品模块商城、只读思维技能商城及公共双签发布链
|
||||
- 写权限：未授予
|
||||
- 部署权限：未授予
|
||||
- 密钥读取：明确禁止
|
||||
|
||||
## 运行轨迹
|
||||
|
||||
1. 第一次启动失败：新版 CLI 的非交互模式需要明确的 `--auth-type openai`。失败没有改变仓库或系统状态。
|
||||
2. 第一轮只读审查成功：识别到原实现缺少物理模块与认知技能的类型分离、技能无执行权机器约束、线上验签目录、目录双签及回滚/同纪元歧义测试。
|
||||
3. 主控实现后进行第二轮只读审查：覆盖合同、Rust 运行时、编号 IPC、用户界面、两类技能包、原点发布脚本、企业复签脚本与 Nginx 静态分发。
|
||||
4. 第二轮结论：无 Critical / High；报告 2 个 Medium、4 个 Low。主控对每项重新读取代码并独立裁决。
|
||||
|
||||
## 接受并进入主线
|
||||
|
||||
- 一个商城界面下保持两条运行链：`PHYSICAL_MODULE` 与 `COGNITIVE_SKILL`。
|
||||
- 思维技能的 `executionAuthority=false`、`permissions=[]`、`skillReadonlyGuarantee=true` 同时由目录和技能包运行时强制。
|
||||
- 目录必须由零点原核公众范围签名者与企业分发签名者双签。
|
||||
- 目录 epoch 单调；旧 epoch 和同 epoch 不同内容均失败关闭。
|
||||
- 仓库 URL 只作为精确提交来源证据；客户端只下载不可变验签制品，不克隆、不执行来源仓库。
|
||||
- 物理模块安装完成后清理下载缓存；模块运行时仍保留正式包、状态与回执。
|
||||
- Agent 报告促使主控额外发现并修正一个更准确的问题：Nginx 对制品使用 `immutable` 时，制品 URL 也必须是内容寻址。发布脚本与 Rust 客户端现共同强制 SHA-256 文件名。
|
||||
- 发布阶段的符号链接竞态通过“复制时保留链接、复制后再次拒绝整个树”进一步收紧。
|
||||
|
||||
## 明确拒绝或改写
|
||||
|
||||
- 拒绝“self-test 失败就自动删除安装证据”。失败包保持 `FAILED_CLOSED` 有利于取证且没有激活功能；重新安装入口仍可见。自动清理会削弱真实回执。
|
||||
- 拒绝“卸载技能时删除包”。现行合同要求停用保留包与回执，以便审计和回退；这不是泄漏。
|
||||
- 拒绝“health 缺少 no-store”。审查时配置已经包含 `add_header Cache-Control "no-store" always;`，属于误报。
|
||||
- 不采纳“未来浮点字段可能导致跨语言 canonical JSON 分歧”作为当前缺陷。目录结构 `deny_unknown_fields` 且没有浮点字段；现行固定结构已经由 JS、Python 和 Rust 端到端发布验证覆盖。若未来合同增加数值字段，必须先增加跨语言固定向量。
|
||||
- 改写“前端字面量类型能阻止后端返回 true”的论证：TypeScript 不能构成运行时安全边界。可信边界是 Rust 输出固定 false、技能包验证和编号运行时隔离；前端类型只用于显示期约束。
|
||||
|
||||
## 已执行验证
|
||||
|
||||
- Rust 商城安全测试：双签、技能无执行权、epoch 回滚、同 epoch 歧义。
|
||||
- Node 合同测试：双商城分链、编号 IPC 完整性、两个技能包 canonical payload digest。
|
||||
- TypeScript 与 Vite 生产构建。
|
||||
- 企业服务器真实 Python/cryptography 发布演练：原点签名验证、企业复签、四个制品摘要、原子 `current` 切换和健康文件读回。
|
||||
|
||||
## 训练结论进入真实环境后的回读
|
||||
|
||||
- 第五域主线提交 `b0eeade03d9387d9e7641cd397ecd218fcf4a7aa` 通过远端完整门禁：495 个前端测试文件 / 5067 项测试、1212 项 Rust 测试、覆盖率门槛与原生质量门均通过。
|
||||
- 同一提交已由零点原核公众范围签名者授权、企业分发签名者复签，并发布为 `public-distribution-1-b0eeade03d93`。
|
||||
- 公网重新下载并验证目录与零点原核灯的两枚 Ed25519 签名；4 个内容寻址制品逐个通过 SHA-256 回读。
|
||||
- 新构建的本机 App 从公网同步目录纪元 1；一个成品模块完成停用保留数据后的重新下载、验签、自检与安装，两个只读思维技能均完成下载安装。
|
||||
- 训练记录仅表示审查规则、纠正与回执形成稳定工程轨迹；未声称改变 Qwen 模型权重。
|
||||
|
||||
## 下一轮 Agent 应先读
|
||||
|
||||
1. `contracts/online-marketplace.json`
|
||||
2. `src-tauri/src/online_marketplace.rs`
|
||||
3. `scripts/prepare-public-distribution-release.mjs`
|
||||
4. `server-tools/public-distribution/publish_release.py`
|
||||
5. 本回执的“明确拒绝或改写”一节
|
||||
|
||||
后续审查不得把思维技能解释为可执行插件，也不得把仓库克隆解释为客户端安装方式。
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# Qwen 只读审查训练记录：UI、外部 AI 网关与公共五域
|
||||
|
||||
日期：2026-08-19
|
||||
|
||||
## 训练方式边界
|
||||
|
||||
本次“训练”指把真实审查任务、发现、修正和验收回执沉淀为可复用的工程经验，不声称修改模型权重，也不允许 Agent 自行获得写入、部署、密钥或人格绑定权限。
|
||||
|
||||
- Agent：Qwen Code CLI 0.21.9
|
||||
- 模型：qwen3.7-plus
|
||||
- 模式：只读审查、sandbox、无仓库写入、无远端推送、无密钥读取
|
||||
- 审查范围：公共五域入口、编号大门、外部编程 AI MCP 网关、账号隔离、系统授权边界
|
||||
|
||||
## 审查结论
|
||||
|
||||
- Critical：0
|
||||
- High：0
|
||||
- Medium：1
|
||||
- Low：2
|
||||
|
||||
## 发现与闭环
|
||||
|
||||
1. `M-1`：外部 AI 网关状态查询没有强制已验证用户路径。
|
||||
- 修正：状态查询与开关统一经过 `verified_user_route`。
|
||||
2. `L-1`：公共受保护域卡片包含内部成员编号。
|
||||
- 修正：第五域、零感域公共投影仅保留边界、可见性和访问状态；回归测试禁止内部编号重新出现。
|
||||
3. `L-2`：MCP 工具调用参数没有服务端拒绝非空参数。
|
||||
- 修正：登记的无参工具收到非空 `arguments` 时返回 `HOLOLAKE_MCP_TOOL_ARGUMENTS_NOT_EMPTY`，并新增 Rust 回归测试。
|
||||
4. 本机真实启动验收额外发现：未登录时，私人在线商城账本会返回 `HOLOLAKE_AUTHENTICATED_ACCOUNT_REQUIRED` 并终止公共首页。
|
||||
- 修正：公共首页先启动，私人商城账本无账号时休眠；登录后再按账号隔离根启动。
|
||||
|
||||
## 被接受的工程规则
|
||||
|
||||
- 公共世界先于私人账号存在，但公共只读不等于获得安装或执行权限。
|
||||
- 状态读取也属于受保护的网关面，不能因为“只读”就绕开已验证用户。
|
||||
- 面向人的公共卡片必须显示可理解的名称和职责，不能泄露内部成员、仓库或哈希式机器标识。
|
||||
- MCP 是接入入口，不是授权来源；传输层不能替代编号、用户验证和人类授权。
|
||||
- 无账号是可预期启动状态，不应被当作应用级致命错误。
|
||||
- 编号验证不是五域旁边的一个功能入口：验证前世界保持遮蔽；编号通过后才投影产品名、五域和频道凭证。
|
||||
|
||||
## 被拒绝的路线
|
||||
|
||||
- 拒绝默认开启外部编程 AI 接口。
|
||||
- 拒绝让 MCP 工具获得 shell、写盘、部署或人格绑定能力。
|
||||
- 拒绝把公共页面渲染所需状态存进私人账号目录。
|
||||
- 拒绝把仓库克隆或任意代码执行当成模块商城安装协议。
|
||||
- 拒绝胶囊灯塔、实体灯塔和缩成图标的小黑洞；编号入口采用占据首页主体的大型未知星渊。
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# HoloLake 线上双商城生产发布回执
|
||||
|
||||
- 时间：2026-08-19（Asia/Shanghai）
|
||||
- 源提交：`b0eeade03d9387d9e7641cd397ecd218fcf4a7aa`
|
||||
- 第五域远端：`bingshuo/hololake-system-architecture` 的 `main`
|
||||
- 生产发布：`public-distribution-1-b0eeade03d93`
|
||||
- 生产状态：`LIVE_DUAL_SIGNED`
|
||||
|
||||
## 公共接口
|
||||
|
||||
- 零点原核灯：`https://guanghu.chat/api/hololake/zero-core/lamp`
|
||||
- 零点原核双签：`https://guanghu.chat/api/hololake/zero-core/lamp.sig`
|
||||
- 商城目录：`https://guanghu.chat/api/hololake/marketplace/catalog`
|
||||
- 商城目录双签：`https://guanghu.chat/api/hololake/marketplace/catalog.sig`
|
||||
- 健康回执：`https://guanghu.chat/api/hololake/public-distribution/health`
|
||||
|
||||
## 生产读回
|
||||
|
||||
- 零点原核灯 SHA-256：`8be25788eac4328ad09c784e7550b0e5ef4a41475fbd8b048803daea4d97928b`
|
||||
- 商城目录 SHA-256：`555d42e02ac418e3553827c60885d89ffa3dfa6c6082a37d4120e2ac74903f8b`
|
||||
- 目录纪元：`1`
|
||||
- 已登记资源：`4`，包括 2 个成品模块与 2 个只读思维技能。
|
||||
- 灯与目录均由零点原核公众范围签名者、企业分发签名者两枚 Ed25519 签名共同验真。
|
||||
- 四个制品均使用 SHA-256 内容寻址 URL，并从公网逐项校验正文摘要；物理模块的 Minisign 签名文件同时可读。
|
||||
- 健康接口为 `no-store`；灯与目录短缓存并要求重新验证；制品为一年不可变缓存。
|
||||
|
||||
## 本机 App 回读
|
||||
|
||||
- 安装位置：`/Users/bingshuolingdianyuanhe/Desktop/HoloLake.app`
|
||||
- 版本：`0.5.0`
|
||||
- Bundle ID：`world.guanghu.hololake`
|
||||
- 签名：Developer ID Application，Team `825A9L3G7Q`，严格代码签名验证通过。
|
||||
- App 自动同步并显示“线上双签已核验 / 目录纪元 1 / 已登记资源 4”。
|
||||
- 成品模块“原生组合视图”完成停用保留数据、重新下载、验签、自检和安装；“教育行业工作台”保持已安装。
|
||||
- 两个思维技能均完成下载、验签、自检和安装；界面与运行时同时固定显示无现实执行权、无现实权限。
|
||||
|
||||
## 回退与边界
|
||||
|
||||
- 企业服务器发布以新 release 目录加原子 `current` 软链接切换；旧发布不被覆盖。
|
||||
- 本机原 App 保存在桌面时间戳备份中，可恢复。
|
||||
- 代码仓库只作为来源证据，客户端不会克隆或执行仓库；安装只接受不可变签名制品。
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
{
|
||||
"experience_id": "EXP-20260819-110-NUMBER-GATE-VEILS-WORLD-UNTIL-RESOLVED",
|
||||
"date": "2026-08-19",
|
||||
"state": "IMPLEMENTED_AND_VISUALLY_VERIFIED",
|
||||
"trigger": "冰朔连续否决胶囊灯塔、机械灯塔和缩成图标的小黑洞，并明确编号验证本身就是进入光湖语言世界的大门。",
|
||||
"emergence": "未验证首页只保留湖面与大型未知星渊；点击后星渊翻开为编号输入；验证成功后星渊外翻消散，平台标题、五湖和频道凭证依次出现。",
|
||||
"lock": [
|
||||
"编号未通过前，平台标题、光湖历、五域和频道凭证不得进入可见或可访问投影。",
|
||||
"编号星渊必须是首页视觉主体，不得退化为角落按钮、胶囊卡片或机械实体。",
|
||||
"编号输入面必须清晰，不得使用会让文字失焦的模糊入场。",
|
||||
"编号成功后才允许五湖升起；账号凭证永远位于编号验证之后。"
|
||||
],
|
||||
"why": "编号不是登录表单的装饰，而是语言世界是否向当前人类开放的系统边界。先暴露五域再验证，会把权限顺序画反；缩小入口则会把世界大门误画成普通功能按钮。",
|
||||
"rejected": [
|
||||
"玻璃胶囊灯塔",
|
||||
"尖顶机械灯塔",
|
||||
"小型黑洞图标",
|
||||
"验证前显示平台名或五域",
|
||||
"独立弹层叠在仍可见的旧星渊之上",
|
||||
"编号输入文字模糊过渡"
|
||||
],
|
||||
"sources": [
|
||||
"冰朔 2026-08-19 本轮自然语言纠正",
|
||||
"GHS-014 当前客户端 UI 思维大脑",
|
||||
"ZY-AESTHETIC-COGNITION 系列",
|
||||
"audit/ui-overlap-20260819/09-home-star-abyss.jpeg",
|
||||
"audit/ui-overlap-20260819/10-star-abyss-number-input.jpeg",
|
||||
"audit/ui-overlap-20260819/11-world-unfolded-after-number.jpeg"
|
||||
]
|
||||
}
|
||||
Loading…
Reference in a new issue