feat: ship dual-signed online module marketplace
This commit is contained in:
parent
3153771bf2
commit
b0eeade03d
40 changed files with 5774 additions and 111 deletions
|
|
@ -10,9 +10,9 @@ The first visible body uses a Rust-owned SQLite kernel under the Tauri app-data
|
|||
|
||||
## Zero-point nucleus client runtime
|
||||
|
||||
HoloLake embeds a non-visual zero-point nucleus client runtime beneath the human surface. It is the minimum controlled projection of the BingShuo system controller, whose private body remains on the JD primary node; the public repository records evolution checkpoints rather than containing that private body. 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.
|
||||
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 protocol-payload installation, private registry distribution and persona loading are not yet implemented. Stage one does not expose an internal AI chat, model API configuration or arbitrary remote-code channel.
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,53 @@
|
|||
# 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` 切换和健康文件读回。
|
||||
|
||||
## 下一轮 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. 本回执的“明确拒绝或改写”一节
|
||||
|
||||
后续审查不得把思维技能解释为可执行插件，也不得把仓库克隆解释为客户端安装方式。
|
||||
Loading…
Reference in a new issue