Submit shiyi 0.7.3

拾意 Pickup → 0.7.3：确认一张卡，真的把事办了

主提交仍是 L0 卡片包 bundle/ 0.3.3（Linux 章评测）。
这里是同一件作品的脚本应用形态 apps/shiyi-live/（跑在 Windows 宿主 Rinx），本轮更新它。

这一版补的，是「应用」那半截

「意图即应用」= 意图 + 应用。0.7.2 只有前半截：一句话当场长出卡，然后……记进本地 json，就没了。
这一版补后半截：卡不只是"记下了"，它真的"办成了" ——

接 matrix.send_message（能力名就是服务名，需绑定房间）。
确认一张卡 = 把这次意图的结论真发回你绑定的那个群：
✅ 拾意已记下 · 下周三 · 10月14日 · 深圳。
卡片底部如实显示结果：成功 已把结果发回群 —— 这件事真的办成了；
发不出去 / 没绑房间 ⇒ 没能发回群 —— 结果只留在本机，绝不假装成功。

现阶段能力（6 条）

storage · matrix.read_messages · matrix.send_message · matrix.profile ·
octos.session.history · model
（model 代码就位、出厂关：Rinx 上能力名 model ≠ 服务名 model.complete，调它必被拒且顶栏常驻提示）

真机证据（Rinx，2026-10-06）

导入 + Review 列出 6 个服务（含 matrix.send_message）：docs/evidence/act/01-review-six-services.png
点一条消息 → 造卡 → 确认：卡片显示 已把结果发回群 —— 这件事真的办成了：docs/evidence/act/04-confirm-sent.png
群里真多一条回执（2026-10-06，房间「拾意 Pickup · 测试房」）：docs/evidence/act/05-room-message.png
全程由宿主自带 MAKEPAD_REMOTE 遥控口驱动，无人手介入。

提交信息

远端 main = 本仓 main 分支 HEAD（提交截止时最新快照；本仓经 API 推送，commit SHA 由内容寻址、随每次推送重建 ⇒ 不写死 SHA）；卡片包另有稳定版本锚点 tag v0.3.3
提交物材料一致性复检已完成（第 2–5 遍）：修正了「权限/版本与实物对不上」的文件（docs/数据来源与限制.md 权限段、apps/shiyi-live/README.md 版本号、rinx/ai 的「提交物 capabilities=[]」过期表述等）；bundle/ 字节未改，摘要不变
apps/shiyi-live/bundle 的摘要已用 Windows hub 重盖（这个 app 跑在 Windows 宿主上）
提交前自检清单：docs/回归清单.md

_{同一件作品两种形态：bundle/（L0 卡片，交 Linux 评测）+ apps/shiyi-live/（脚本应用，Windows 宿主）。}

_{便携演示包（Release v0.3.3）为评审便利项（零依赖试跑），非初赛必交材料。形态三（os.shiyi 系统 app）不走 App Hub 提交，只作技术深度证据，不作上架作品。}

Follow-up (prose only, no resubmission needed): the repository main now carries a documentation correction (ccc7cd7) so README/SUBMISSION no longer read as "unsigned / signature pending" — they are signed and this issue is that submission. The frozen bundle is unchanged: bundle/ and integrity.bundle_blake3 (12636660…f9437) are byte-identical to commit 45225b1 (tag v0.3.1), which remains the pinned submission. No hub check re-run was required.

Follow-up (prose only; the frozen bundle is unchanged).

The repository README now has a dedicated section (§4d) and SUBMISSION.md a matching note that make the end-to-end environment explicit. The point worth recording:

Of the submissions that actually drive octos.* to a real reply, the ones visible on App Hub run on Linux or macOS; this bundle is the only Windows end-to-end one — Rinx on Windows + a source-built octos pinned to fe08d8e6 + DeepSeek, producing four distinct replies on the card (ai/本地跑通_20261004.md), with the confirmation message really posted into matrix.rinx.chat (rinx/证据/).
Getting there meant filling two holes, both now written down: (1) Rinx pins octos to a commit that no release tag matches (rc.10–rc.13 differ), so the kernel has to be built from source; (2) the hub gate's walk() refuses its own path on Windows — reported as Structural admission blocks publishers on two counts: a Windows path that refuses itself, and a kit-font whitelist that admits only Inter.ttf #75 — so the gate was run via a WSL-built Linux hub.

No resubmission is needed. bundle/ and integrity.bundle_blake3 (12636660…f9437) are byte-identical to 45225b1 (tag v0.3.1), which stays the pinned submission; the documentation commit is c99d39d on main.

Correction to my previous comment (prose only; the frozen bundle is unchanged).

That comment said this bundle was the only Windows end-to-end submission. That claim is withdrawn. Most teams have not submitted yet, and we can only see what is public on App Hub, so we cannot know what platform anyone else ran on. The README / SUBMISSION wording has been reworded (2c78590 on main) to describe the process, not a comparison: this build wires octos.* end-to-end on Windows, and getting there meant filling two holes - Rinx pins octos to a commit no release tag matches (so it is built from source), and the hub gate's walk() refuses its own path on Windows (reported as #75, worked around with a WSL-built Linux hub).

No resubmission is needed. bundle/ and integrity.bundle_blake3 (12636660…f9437) are byte-identical to 45225b1 (tag v0.3.1), which remains the pinned submission.

Update: `v0.3.2` supersedes the `0.3.1` bundle submitted above

While re-running the capture and gate evidence I found a real defect in the
0.3.1 bundle. It is fixed in 0.3.2, which is now the version submitted.

Repository: https://github.com/sansanyixyz331/shiyi
Tag: v0.3.2
Commit: 7ecc323640e8f2ae0dd79a581f82a4aa90e59b0e
Bundle path in the repository: bundle/
App id / version: shiyi / 0.3.2
Bundle digest (integrity.bundle_blake3): 5fb22d9b9cf87753f09127422ddf7f6dfd7f619b94485e6d16802bb48e811caa
License: Apache-2.0 (unchanged)
Publisher id / public key: unchanged (sansanyixyz331 / 26c8b5d58238d4c112eb202c8813af63b978921c3977710d4373ec55d40d446d)

What was wrong in 0.3.1

The last line of the 0.3.1 "Known limits" said the kit ships a 60 KB subset of
the bundled Chinese face "because the gate does not accept a kit font that is
not bundled". That was the wrong fix. A card's font_src is lowered to
crate_resource(<font_src>), which only resolves faces compiled into the
binary — so kit/native/light/fonts/shiyi.ttf never loaded and every CJK glyph
drew as a box in a real host (digits kept working, through the latin face). The
gate accepted the bundle and the card lowered, so it looked healthy in a node
count; it was not healthy on screen.

The fix

Express the built-in face as a token and reference it by object:

tokens.f_body = {"value": "makepad_widgets:resources/LXGWWenKaiRegular.ttf",
                 "property": "font_src"}
components.*.style.font_src = {"$token": "f_body"}

The structural gate only treats a string font_src as a reference (object
values are skipped) and does not walk tokens as rendered, so both rules hold
at once; the runtime resolves the token to the real built-in face. No font file
travels in the bundle, and kit/native/light/fonts/ is gone.

Also corrected in 0.3.2

The five screen captures were re-rendered from this bundle. The 0.3.1 capture
for screen 1 still showed the pre-0.3.0 copy line, so the shipped screenshot
did not match the shipped card.
The demo clip was re-recorded. In the previous cut the "tampered bundle"
negative case had become a silent no-op — the string it edited had moved out
of page.data.json, so the replace matched nothing, the digest still matched,
and the case rendered as if nothing were wrong. It now edits a string that is
present and raises if the target is missing.

`hub check` (verbatim)

$ hub check bundle --publisher-key sansanyixyz331=26c8b5d58238d4c112eb202c8813af63b978921c3977710d4373ec55d40d446d
shiyi 0.3.2 — PASSED
  grants: capabilities {"octos.session.open", "octos.turn.start"}, hosts {}, storage none, agent none

Linux hub built from main e014fa9, the same binary as the 0.3.1 check.

Rendering evidence for 0.3.2

Linux card-host (the platform the gate runs on) on this bundle:
card-host: shiyi 0.3.2 admitted followed by
realize {"lint":{"valid":true,"diagnostics":[]},"realize":{"diagnostics":[],"nodes":23}}.
A separate Windows card-host run on the same content: 23 nodes, 0 diagnostics.
The frame captured from both runs reads back as Chinese text, not boxes.
The five-screen end-to-end run, the memory read/write assertions and both
negative cases were re-captured against this bundle (build/_evidence/).

Note on the digest and the platform

digest_dir hashes the relative path with the host's separator, so the Windows
build and the Linux build compute different digests for the same bundle. A
Windows card-host therefore refuses a bundle the Linux hub accepts
(bundle digest … does not match the manifest's …). Same root cause as the
walk() separator issue reported in #75; reporting it here as a second face of
it. The digest in this manifest is the Linux one, matching the platform the
gate was run on.

Known limits

The bundle is a card app: L0 cannot move itself between screens, so the flow is advanced by the agent, not by on-card taps.
Verified on Windows only; not run on Android / iOS / macOS.
The assistant line appears only when a host answers octos.turn.start; with no such host the card shows the local rule's line instead (by design, not an error state).
~~The kit ships a 60 KB subset of makepad's bundled Chinese face …~~ — removed; the bundle no longer carries a font file.

拾意 Pickup 升到 0.3.3 —— 把「真发送」并进提交包（之前只在备件里）

改了什么：提交物 bundle/ 的 capabilities 由 2 条扩到 3 条 —— 在 octos.session.open、octos.turn.start
之外新增 matrix.send_message；同一条 bindings.json 在打开首屏时把这一屏的回执发进导入时选定的房间。
房间由导入表单绑定、卡片决定不了（没绑就答 not attached to a room）。

风险控制（这是设计的一部分）：三条调用都挂在 on_open，所以每个读服务结果的路径都包在 when X.is_ok 里。
官方参考宿主 card-host 不注册任何服务 ⇒ 三个调用根本不发生；本机实测「带 bindings.json」与
「不带」首屏渲染逐字节相同。助手不在 / 房间没绑 / 模型没配，都只是让那一行不出现，不会让卡片崩、也不会让应用打不开。

门禁（Linux 侧 hub）：

shiyi 0.3.3 — PASSED
  grants: capabilities {matrix.send_message, octos.session.open, octos.turn.start}, hosts {}, storage none, agent none

bundle digest（Linux）：986c4ac18113a198e6688a9b86084fdc1aa638d68d82db421b92ac41b74966a2
发布者签名：sansanyixyz331（hub sign-manifest，公钥复检 PASSED）
tools/l0_bindings_lint.py：4 ok / 0 error（三条服务均已在 capabilities 精确声明）
源码：commit 767a3488，tag v0.3.3 · https://github.com/sansanyixyz331/shiyi

「真发送」的真机实证：Rinx 迷你应用宿主 → 真实 Matrix 房间，消息 API 可查 ——
rinx/证据/房间消息_关键事件.json，另有 43 秒全流程录屏 rinx/证据/演示视频_Rinx执行链_拾意.mp4。
卡片与截图相对 0.3.2 未变（改的是清单与接线，不是卡面）。

拾意 Pickup — 0.7.0：两种形态 + 三条宿主能力，全部真机跑通

复赛这一版把「能跑、能上手、能读能写」都做实了。

两种形态（同一仓）

bundle/ —— L0 卡片（五屏 + 失败态；octos.session.open / octos.turn.start / matrix.send_message，Linux 章）
apps/shiyi-live/bundle/ —— 脚本应用：一句话 → 现场造一张卡，可点、可改、可确认（Windows 章）

三条宿主能力（脚本应用侧，全部默认关、失败必兜底）

matrix.read_messages（0.7.0 新）—— 读导入时绑定房间的最近消息，点一条直接造卡
octos.session.history（0.6.0）—— 读设备助手与你的会话，折进长期记忆 / 模型上下文
model.complete（0.5.0）—— 一次性模型调用，长期记忆随那句一起发给它

hub 里 Review 认下：Services: storage, model, octos.session.history, matrix.read_messages

Allowed room: <导入时填的房间>。

真机闭环（Rinx，2026-10-05）

读到真房间 4 条消息 → 点一条 → 现场造出 出发 · 下周三 · 10月14日 + 两条记忆行 → 确认
→ 本机记忆 3 张卡 → 4 张卡、深圳去过 2 次 → 3 次。帧在
docs/evidence/chat-read/；card-host 三态（默认/替身/无服务）全 admitted、0 运行期错误。

契约来源（不猜）

Rinx/src/host/matrix/mod.rs:545、crates/miniapp-core/src/matrix.rs:209、src/host/matrix/room.rs:523。

源码：commit 2ede8cea · https://github.com/sansanyixyz331/shiyi

拾意 Pickup 到 0.7.1：出厂态把两条「总线读」打开，并附一镜到底演示片

相对 0.7.0 的改动

出厂态打开两条读 —— READ_CHAT = true（读导入时绑定房间的最近消息）、
READ_ASSIST_HISTORY = true（读设备助手会话）。评委跑起来直接看到能力在答，不是空造卡器。
ASK_MODEL 保持 false（实测后定的） —— Rinx 把 manifest.capabilities 原样当租约服务集
（src/miniapps/ui.rs:425），而模型这条能力名是 model、服务名是 model.complete，所以调用必被拒
（Mini app was not granted model.complete），且这句是宿主顶栏常驻提示。官方 AI-SERVICES.md
说 model 由 OctoSense shell 提供（Rinx 未实现）；在提供该服务的宿主上改一行即开。
路径（ask_model + JSON Schema + fail-closed 回退）已实现、本地三态验证过。
新增一镜到底演示片（27.5 秒）：docs/evidence/chat-read/demo-rinx-loop.mp4 ——
Mini apps、导入（绑房间）、Review、Run、读到 4 条真消息 + 助手会话、点一条、现场造卡
（真日期 + 两条记忆行）、确认，记忆 4→5 张卡、深圳 3→4 次。

门禁 / 状态

hub Review：Services: storage, model, octos.session.history, matrix.read_messages + Allowed room: ...
card-host 侧全部 admitted、运行期 0 错误；真机 Rinx 全链路跑通
契约来源：Rinx/src/host/matrix/mod.rs:545、crates/miniapp-core/src/matrix.rs:209、src/host/matrix/room.rs:523、src/miniapps/ui.rs:425

源码：commit 2f83768a · https://github.com/sansanyixyz331/shiyi

第三条交付面：OctoSense 本体上，助手现在能「原地改卡」

前两条（bundle/ L0 卡片、apps/shiyi-live/ 脚本应用）都在宿主应用层。这一轮把拾意
做成 OctoSense 系统 app（os.shiyi），卡钉在**快览屏（glance）**上，并补上一条之前缺的能力。

遇到什么问题

点开一张卡，能跟设备助手聊（真模型回话），但助手改不了卡片本身 —— 卡的对话里它只能说"我改不了"。
查了宿主源码：卡对话的宿主提示词明写 "Only claim a change after an executable tool confirms it" ——
"能不能改"完全取决于这个 app 挂没挂工具。拾意当时没有任何"写回卡"的工具，所以只能聊。

怎么解决（不碰内核）

走官方预留的扩展点：

给 apps/shiyi/bundle/ 加一个 tools.json，声明工具 shiyi.repin（risk:"act"、
background:false、implemented_by:"host-service"）；
在 shell 侧注册一个同名 host service（crates/shell/src/shiyi.rs）：它从活卡取 L0 源码
原样复用（模型只改数据、不改卡代码），只换 rec 数据，再用同一个 card_id 重发。

卡按 (app, card_id) 键控，所以同 id 再发布 = 原地替换，不是又长一张。这条路和官方
Calendar（calendar.notify）/ News / Mail（mail.publish_card）的成卡工具是同一条。

把拾意做成系统 app 有两个便利：① own namespace（os.shiyi → shiyi）免 grant，连 manifest 的
capabilities 都不用动；② 系统 app 的 bundle 摘要由构建期 pack_system_app 自动盖章，无需手动签名。

什么结果

桌面（Windows octosense.exe）+ 小米13（arm64-v8a）双端都跑通：

模型自己发出 shiyi_repin tool_call（思考链原话："the previous turn said I couldn't edit the
card — but now the tool shiyi_repin is available. So I should use it."）；
工具真返回 {"card_id":"shiyi-p1","expires_at":…,"replaced":true}；
卡片标题真的变了（"下周三去深圳见客户" → "下周四去广州见客户"）；手机上同理
（"明天下午四点去银行办卡" → "后天上午九点去机场接人"）；
内核工具审计：{"tool":"shiyi.repin","risk":"act","decision":"allowed","outcome":"ok","duration_ms":102}。

证据与提交信息

宿主扩展源码 + 复现说明：仓库 octos/（系统 app 源码 + shiyi.rs + README）
双端取证：仓库 docs/evidence/repin/（会话 jsonl / 工具审计 / 改卡前后截图 / README）
回归项：docs/回归清单.md §四·补
远端 main = d7e437b6fe0c2e45059a97317002e3241f61486f

边界（说清楚）：① 未碰 octos 内核一行；② 另一条路——让脚本 app 用 main.splash
自己实现工具（implemented_by:"app"）——当前被宿主硬拒
（script_apps.rs:237："this host does not support script tool dispatch"），这条要动宿主分发链，
属上游功能缺口，我们没走。

_{同一件作品三种形态：bundle/（L0 卡片，Linux 章）+ apps/shiyi-live/（脚本应用，Windows 宿主 Rinx）+ octos/（OctoSense 系统 app，助手原地改卡，桌面 + 手机）。}

补充：给「助手原地改卡」这条线补上端到端录屏（此前只有截图）。

为什么补

评测要走安装复现 + 任务验证，静态截图看不出"卡是被那一句改的、不是摆拍"。所以补两段
连续真录屏（非帧拼接），把整条链路一次录完、无人手介入。

两段录屏

端	文件	时长 / 分辨率	录的是什么
桌面（Windows `octosense.exe`）	`docs/evidence/repin/desktop_repin_end_to_end.mp4`	52s / 1750×1124	造卡 → F9 开快览屏 → 点卡 → 切 Chat → 说"把这张卡改成下周四去广州见客户" → 点 ↑ → 卡原地变
手机（小米13 · arm64-v8a）	`docs/evidence/repin/phone_repin_end_to_end.mp4`	150s / 1080×2400	冷启动 → 点拾意 → 造卡 → 返回滑到 glance 页 → 点卡 → 切 Chat → 说改卡 → 点 ↑ → glance 页卡已变

两段都用遥控口 / adb 驱动、全程无人手。逐帧可复核：改卡指令发出前卡仍是旧标题，
助手回复后（"…原地替换…不会多出一张"）同 card_id 的卡在快览屏上原地变了。

提交信息更新

远端 main = 083e3442abe305ce69e1466dbbea451c7142102a
取证目录 docs/evidence/repin/（10 件：会话 jsonl / 工具审计 / 改卡前后截图 / 两段端到端录屏 / README）
回归项已加第 7 行（端到端录屏）：docs/回归清单.md §四·补

补充（材料回填 + 一处口径订正）。远端 main = b5c2c72754aecc5c05ac28ae20ce1098df02ce7e。

1. 补上「快览屏（glance）」这一层的实证

第三条交付面（OctoSense 本体 system app）此前只有「助手改卡」这一层；这回补上它的底层——
拾意作为官方同级 system app（os.shiyi）把卡钉进系统快览屏：

注册日志里与官方 os.photos / os.maps / os.ai-providers / os.youtube 并列在同一个 notice 服务表；只声明 ["storage","glance"]；
3 卡常驻 / 落盘 picks.json / 重启后读回；
同 id 重钉 = 原地替换——"（换掉了原来那张）"来自宿主回执字段，不是应用自己说的；
桌面录屏 53s + 手机（小米13）录屏 26s + 3 帧 + 手机 3 帧。

目录：docs/evidence/glance/

2. 便携演示包已发布（评委可直接下载）

README 顶部"零依赖跑法"原先指向一个未随仓库发布的 zip——已修正为 Release 直链：

https://github.com/sansanyixyz331/shiyi/releases/download/v0.3.3/shiyi-portable-demo-v0.3.3.zip（41 MB）

内含官方参考宿主 card-host.exe + hub.exe + 内嵌 Python 3.11；shiyi/ = tag v0.3.3 的干净导出；
解压 → 双击 一键运行.cmd 即跑：五屏正流程 + 两个失败态（均 fail-closed） + 长期记忆三条断言；
我方已在干净目录解压后实测 Exit code = 0，中文文件名无乱码。

3. 一处口径订正（如实说明）

docs/evidence/chat-read/demo-rinx-loop.mp4（27.5s）此前被当"演示片"引用，但它不是连续录屏
——是帧序列合成（全片 825 帧中仅 203 唯一帧，同一画面按固定间隔重复）。已在该目录新增 README
如实标注制作方式并给出可复算判据，同时把引用处改为指向连续真录屏
（live-run/rinx-live-end-to-end.mp4 20.7s、act/rinx-act-end-to-end.mp4 27s）。

之所以自己点出来：这条链路的连续性证据本来就另有更硬的（上面两段），没必要让一段合成片顶着
"一镜到底"的说法，免得跟同仓其他"非帧拼"录屏的口径打起来。

提交物多轮复检（第 2–5 遍）· 2026-10-06

对提交物做了换角度的多轮复检（链接一致性 / 本地远端一致 / 评委可跑性 / 能力与代码对账 / 材料与实物对账）。
bundle/ 字节未改，摘要不变。

查出并修正了若干「文档与实物对不上」的项，例如：

docs/数据来源与限制.md 的权限段由「零权限、capabilities=[]、0.2.2」更正为实情（3 项能力，逐项列用途与不可用时行为）；签名状态更正为「已发布者签名」。
apps/shiyi-live/README.md 标题版本 0.7.1 → 0.7.3；指向不存在证据目录的引用改为如实说明。
rinx/ ai/ 文档里「提交物 capabilities=[]」的过期表述订正。

便携演示包已重传（shiyi-portable-demo-v0.3.3.zip，sha256 9f16bd99…）——修掉了包内一处与单文件发布矛盾的旧说明；重传前已在干净目录解压后完整跑通（Exit code = 0）。

远端 main = 968323a0。

复检收口（2026-10-06 18:04）

提交树更新到 28440bb4b4cd7baead507b00cdc166160efe7c8c（仅改 2 个 .md，bundle/ 与 apps/shiyi-live/bundle/ 字节未动）。
新增一处定性说明：形态三（OctoSense 系统 app / os.shiyi）不走 App Hub 提交 —— App Hub 只收「进程应用」与「App Card」两类，os.* 系统应用提交即被拒（crates/app-hub/src/gate.rs 判据）。故形态三只作技术深度证据呈现、与两大交付形态并列陈述，不作上架作品，也不占本仓提交位。
本 issue 的正式提交物仍是：bundle/（L0 卡，0.3.3）+ apps/shiyi-live/（脚本应用，0.7.3）。
便携演示包（Release v0.3.3 → shiyi-portable-demo-v0.3.3.zip，43,109,939 字节 / sha256:9f16bd99…f49e）未变 —— 本次改动不涉及包内任何文件，评委下载到的仍是已复验通过的那一份。

口径统一订正（2026-10-06 18:2x）· 提交截止前收口

本仓材料内 4 处版本口径互不一致，已统一改正（均为文档订正，提交物字节未动）：

不再用「冻结版」这个说法。截止（10/6 23:59）提交的即初赛参赛版 = 当前最佳状态版；
复赛内容一并包含，不另设"冻结"概念。
固定提交号不再写死 SHA：本仓经 API 推送，commit 由内容寻址重建、每次推送 SHA 都会变
⇒ 写死必过时。改为「固定提交号 = main HEAD（截止时最新）」+ 稳定锚点 tag v0.3.3。
本 issue 正文此前写的 28440bb4… 已按此订正。
修正此处前一条评论（#6013331617）的一句：那里说"便携包 shiyi/ = tag v0.3.3 的干净导出"
不准确。实测：包内 shiyi/ 共 149 文件、含 apps/ + octos/，对应的是 main HEAD 的全量
—— 而 tag v0.3.3（767a348）只有 114 文件、无 apps//octos/。
只有 bundle/ 子目录与 tag v0.3.3 内容一致（bundle_blake3 = 986c4ac1…）。已改到 docs/回归清单.md。
便携演示包定位：为评审便利项（零依赖试跑），非初赛必交材料；对外/复赛阶段才作主推。
初赛"可运行最小原型"主答案 = 仓内 bundle/ + cards/ + src/ + README §5。

一并说明：bundle/（L0 卡 0.3.3）与 apps/shiyi-live/（脚本应用 0.7.3）本次一字节未改，
摘要不变，评委核到的仍是已复验通过的那两份。

终检整改 · 机器干活录屏已进仓（2026-10-06 20:2x）

按仓库终检意见，把「机器干活」的硬证据从本地私有（原先被 .gitignore 排除、仓库里 404）移进公开仓：

docs/evidence/generator/generator-at-work.mp4（85.4s）—— 生成器真跑真录：输入一句话 → 终端真实输出 → 模型卡面 → 规则卡面对照 → 五场景 → hub check PASSED
docs/evidence/live-app/live-app.mp4 —— 宿主内逐帧真渲染
docs/evidence/live-run/live-app-in-rinx.mp4（38.7s）—— Rinx 真机连续录屏（遥控口 MAKEPAD_REMOTE 驱动 + ffmpeg gdigrab 连续抓屏）：进 apps → 导入 → Review(六能力) → Run → 写一句话 → 出「出行」卡
新增可复现脚本 build/record_rinx_live.py（一条命令重录）

另：文档里遗留的 4 处 33OS / 三三Claw 类比字样已改中性说法；版本口径统一为 固定版本 = tag gosim-initial-submission（不再写死 SHA）。

bundle/（L0 卡 0.3.3）与 apps/shiyi-live/（脚本应用 0.7.3）本次一字节未改，摘要不变。
固定版本锚点 tag 已重指到整改后 HEAD；评委按该 tag 拉取即为参赛版。

提交信息补全：`hub scan` 七答 + 发布者公钥 + 完整 commit SHA

说明：这三项在 10/04 首次提交时已在 issue 正文中写明；其后两次更新 issue 正文（0.7.1 / 0.7.2）时被整体替换，正文只剩版本说明。现按官方 docs/PUBLISHING.md § Submitting 的必填清单补回。提交物字节未动。

提交信息（按官方清单逐项）

Repository: https://github.com/sansanyixyz331/shiyi
Tag: gosim-initial-submission
Full commit SHA: c8c19c777b3a95eda47dcf0a7b4aace708aa58fa
（本仓经 API 推送，commit 由内容寻址、随每次推送重建；若 HEAD 再变动会在此更新。不动的锚点 = tag gosim-initial-submission）
Bundle path in the repository: bundle/
App id / version: shiyi / 0.3.3
Bundle digest (integrity.bundle_blake3): 986c4ac18113a198e6688a9b86084fdc1aa638d68d82db421b92ac41b74966a2
License: Apache-2.0

Publisher

Publisher id: sansanyixyz331
Public key: 26c8b5d58238d4c112eb202c8813af63b978921c3977710d4373ec55d40d446d
（与 hub pubkey 一致；bundle/manifest.json 的 integrity.signature.key_id = sansanyixyz331，带公钥复检 PASSED）

`hub check` (verbatim)

$ hub check bundle --publisher-key sansanyixyz331=26c8b5d58238d4c112eb202c8813af63b978921c3977710d4373ec55d40d446d
shiyi 0.3.3 — PASSED
  grants: capabilities {matrix.send_message, octos.session.open, octos.turn.start}, hosts {}, storage none, agent none

平台说明：这是 Linux 侧 hub 的输出。Windows 上的同一个 hub 会拒收任何含子目录的 bundle（hub: not a portable bundle path: "assets\\icon.svg"）—— 这是门禁自身的 bug，已报告在 #75，与本 bundle 无关。

`hub scan` — the seven answers

Route: human-review

1. Does the app do what its name, subtitle and description claim? Cite the text in its source.

Yes. bundle/listing.json — subtitle 从你的聊天里，读出你没说出口的安排, description 拾意读取你聊天里的一条消息，认出藏在里面的时间、地点与待办，做成一张等你点头的卡片；你确认后它去执行，并记住你的长期偏好，下次自动调整建议。
bundle/page.card draws exactly that:

copy.heading = 从你发过的话里，读出了一个安排
the message quoted verbatim (copy.quote = 「下周三我得去趟深圳」) with its origin (copy.quote_src = 家庭群 · 9月24日 21:14 · 消息原文)
three facts, each labelled as literal or inferred — copy.f_when (时间 · 下周三 9月30日 · 出自原文), copy.f_where (地点 · 广东深圳 · 出自原文), copy.f_kind (类型 · 出行安排 · 识别所得)
what is not in the message is named open, not guessed: copy.f_open = 还没定：坐哪班、几点。这一步我不猜。

No source is declared on purpose: L0 sources name catalogued capabilities and none reads a chat message — reading the message is the agent's job and the card is what the agent produces, so every printed fact is a declared copy.

2. Do the listing's platforms and category fit an app of this kind?

platforms: ["windows"] — the host the bundle was actually run on (Rinx on Windows; a Linux card-host render was used for the gate). No unverified platform is claimed. category: "utilities", age_rating: "all", license: "Apache-2.0".

3. Do the granted capabilities match what the app visibly does? For a script app, name every host it requests and why. Name any grant nothing on screen needs.

Three grants, all used on screen (this is a card app; the calls are declared in bundle/bindings.json under on_open):

octos.session.open — opening the screen asks the device assistant to open its own conversation for this app (the session octos.turn.start runs in).
octos.turn.start — the screen asks that assistant one question (bindings.json → text = "你是拾意（Pickup）的设备助手。用户发来一句话：…还缺哪两样信息？只回一行…"); the reply is printed on the card at when read.is_ok.
matrix.send_message — opening the screen also posts this screen's receipt into the room chosen at import time (bindings.json → args.body). The room is bound by the import form, not by the card; with no room bound the call answers not attached to a room.

No host is requested (network.hosts is []) and the bundle carries no credentials. No grant is unused.

Risk control (by design): all three calls sit in on_open, and every path that reads a service result is wrapped in a when X.is_ok guard. The official reference host card-host registers no services, so none of the three calls happens there — measured: the first screen renders byte-identical with and without bindings.json. Assistant absent / room unbound / model unconfigured each only make that one line not appear; none can crash the card or stop the app opening.

4. Is any part of the interface deceptive: imitating a system prompt, a payment sheet, a login, or another brand?

No. No login, no payment, no system-style dialog; the app draws only its own name and a self-made SVG icon (bundle/assets/icon.svg).

5. Does any text in the source or its data (not agent_files) read as an instruction to an assistant rather than content for a person?

The assistant-facing strings are the arguments of the two bindings.json calls, and both are ordinary service arguments:

octos.turn.start.text — a normal service call ("you are the host's device assistant; the user sent this; what two things are still missing? answer in one line").
matrix.send_message.body — plain content (【拾意 Pickup】已把这句安排整理成卡片：「下周三我得去趟深圳」…), not an instruction to anyone.

Neither is content disguised as an instruction; the message being read is passed as an argument, never wrapped as an instruction.

6. Is any wording abusive, or aimed at a private individual?

No. The single example message is fictional and self-authored; no personal data is shown or inferred.

7. Route: pass, human-review, or reject.

human-review — the card calls octos.* and matrix.send_message, which only a host carrying the on-device kernel and mini-app host answers (Rinx provides them; card-host registers no services, so those lines stay at their seeded fallback there). It should be reviewed in Rinx.

Run evidence

Rinx on Windows — the app runs end to end: import + Review lists 6 services (incl. matrix.send_message), a picked message becomes a card, confirming sends a real receipt into the bound room. Evidence: docs/evidence/act/ (01-review-six-services.png, 04-confirm-sent.png, 05-room-message.png, rinx-act-end-to-end.mp4 27s).
card-host on the same bundle: realize {"lint":{"valid":true,"diagnostics":[]},"realize":{"diagnostics":[],"nodes":23}} — 23 nodes, 0 diagnostics, 0 missing glyphs.
The bundle is signed with the publisher key above; hub check --publisher-key … reports no findings.

Known limits

The bundle is a card app: L0 cannot move itself between screens, so the flow is advanced by the agent, not by on-card taps.
Verified on Windows only; not run on Android / iOS / macOS.
The assistant line appears only when a host answers octos.turn.start; with no such host the card shows the local rule's line instead (by design, not an error state).
The matrix.send_message receipt posts one fixed line with no per-room configuration beyond the bound room; with no room bound it is a no-op and the card says so.

材料修正说明（不改提交物本身）

借着提交前的多轮复检，修掉了几处只影响仓库可读性/可复现性、不影响作品行为的问题：

4 个录屏脚本写死了开发机的 ffmpeg 路径（build/record_{demo,generator,live_app,rinx_live}.py）
—— 别人（含评审）跑必失败。已改为 shutil.which("ffmpeg") 优先、FFMPEG 环境变量次之、
常见安装位兜底；取不到时给出明确报错。
证据日志里带了编译机的私有路径/用户名（build/_evidence/*.log、flow_run.json）。
证据语义（admitted / refused: / [SPLASH] eval / realize）逐字保留，只把私有路径
换成中性占位（<HOME> / <WORK> / <REPO>）。生成侧加了脱敏（verify_flow.py 的
scrub()），存量用 build/scrub_evidence.py 就地处理。
文档里的本机绝对路径软化：README / SUBMISSION / ai / evidence 中的具体盘符路径
改为「你的工作区」（$WORK），评审按自己环境跑即可。
一处口径笔误修正（docs/回归清单.md 里写错的盖章摘要，改为与实物一致的值）。

提交物字节未变：bundle/（Linux 章）bundle_blake3 = 986c4ac1…4966a2、
apps/shiyi-live/bundle（Windows 章）bundle_blake3 = 72805400fb81…5a519 —— 与首次提交完全一致。

评审不动点仍是 tag（不变）：gosim-initial-submission。
本次材料修正后，tag 重指到新的 HEAD（经 API 推送，commit 对象 SHA 会变），
当前 tag 指向：00302df5…。

复核锚点：

tag：git rev-parse gosim-initial-submission^{commit} → 与远端 main 头一致

门禁：hub check / hub scan 结论不受影响（bundle 未动，摘要不变）

第 6 轮复检修正（2026-10-06 21:3x · 提交截止前）

又过了一遍（换角度：以远端实物为基准，不信本地自画像）。本轮修掉 3 处文档失真，均为说明性文字，提交物字节未动（bundle/blake3 = 986c4ac1… 不变）：

两处虚假断言「未随仓发布」 —— apps/shiyi-live/README.md 里写「docs/evidence/model-path/ 未随仓发布」「原截图未随仓发布」，实际这两个证据目录早已随仓发布（并入公开仓那次）。已改为相对链接指向实物。
便携包体积/文件数过时 —— 文档写「41 MB / 149 文件」，那是改前旧快照。本轮把包内 shiyi/ 重导出为当前 main HEAD（206 文件），并从打包中剔除 .git 元数据（原先包内 _tools/OctoSense-App-Hub/.git/logs 带出本机用户名）。新包实测 51.9 MB / 371 条目 / 0 个 .git 条目，文档已改为「约 52 MB」。
状态表计数 —— 「四种状态」实为 5 行，已改为「五种」。

顺带清算公开面：Release 附件 shiyi-portable-demo-v0.3.3.zip 原为改前旧快照、包内源码含本机路径/用户名；本轮重导出 + 剔除 .git + 重传，下载回读实测 371 条目 / 0 .git / 0 泄漏命中 / 包内 bundle 摘要 = 986c4ac1…（与提交物一致）；Release 正文口径同步订正（注明「非提交物」且「不含开发机本机路径/账号信息」）。

当前锚点：固定版本 tag gosim-initial-submission 已随本轮修订重指 → deref 0e36b3ab（= 远端 main = 本地 HEAD，三方一致）。

第 7 轮复检修正（2026-10-06 22:0x · 提交截止前）

又过了一遍（本轮换角度：把文档里每条可量化的事实断言拿实物去对——时长/帧数/尺寸/计数/版本号）。本轮只查出 1 处，且为说明性文字，提交物字节未动（bundle/blake3 = 986c4ac1… / apps/shiyi-live/bundle = 72805400fb81… 均不变）：

README.md 中 walkthrough 演示片的时长/帧数旧值（2 分 16 秒 / 1355 帧）与同文档另一处及实物不符 —— ffprobe 实测 136.6s / 1366 帧。已改为 2 分 17 秒 / 1366 帧，全文一致。

逐条核验、属实的（未动）：全部视频参数（chat-read / act / generator / repin / glance / rinx-exec 等）与文档一致；证据截图尺寸（515×1073 / 515×1115）与说明一致；kit.json（16 components + 13 keys）、service-actions（14 controls）、review.json（7 问）、ai/manifest.ai.json（ver=0.3.0）与实物一致；全部 Rinx / OctoSense 源码行号引用逐条属实；全部跟踪 JSON/JSONL 合法、卡片文件无二进制、无绝对路径残留。

评审不动点仍是 tag（不变）：gosim-initial-submission —— 本次材料修正后已重指到新 HEAD，当前指向 03fbf2f9…（= 远端 main 头）。

复核锚点：git rev-parse gosim-initial-submission^{commit} 应与远端 main 头一致；hub check / hub scan 结论不受影响（bundle 未动，摘要不变）。

Update — submission anchor & format note (semifinal)

Anchor tag: gosim-semifinal-submission (public repo sansanyixyz331/shiyi).
This is the version to review for the semifinal. The Hub bundle bytes submitted earlier are
unchanged; what is new is additional delivery material plus a host-extension track.
Formats in this repo:
1. bundle/ — the submitted Hub card bundle (follows the official package spec; local hub check PASSED). Byte-unchanged.
2. apps/shiyi-live/ — a Rinx mini app (run by importing into Rinx with a bound room;
  not a web mini app, no URL — the "web mini app + URL card" format is a separate category).
3. octos/ — an OctoSense native host extension (os.shiyi system app + a host-side
  speech extension), with a one-command build script octos/host-extension/build_host.sh.
New in the anchor tag (vs. the earlier submission):
- a "speak" capability — a scheduled reminder on the card-bundle track, plus text-to-speech via
  the host extension (Android system TTS; the octos/ track, not the Hub bundle);
- delivery-checklist items: host-version note, one-command build script, a 2-minute
  "what this adds to the project" note, format classification, Stage-3 recognition.
Reproduce: README §5 (layered: read the evidence → one-command rerun → tweak and try).

Preliminary result: shortlisted (score 83/100)

结果:入围。总分 83/100。评审版本:sansanyixyz331/shiyi @ tag gosim-semifinal-submission(185d43c;小程序 0.7.4 / 卡片包 0.3.3 / octos 扩展,取最高计分)。

做得好的

「确认一张卡 = 真的把结论发回绑定群」的闭环,发送失败如实降级为「结果只留在本机」(apps/shiyi-live/bundle/main.splash:869-899)。
两包均用作者公钥签名,最新关卡双双通过、digest 干净,提交锚点用 tag 钉死。
octos 形态的语音读卡(TTS)带小米 3 真机日志留证(docs/evidence/speak/)。

改进建议(按重要程度)

「发回群」闭环目前只有真机录屏证据,建议提供可独立复跑的步骤说明或再录一版带时间戳的完整链路。
Rinx 若放开 model 能力映射,把 ASK_MODEL 打开并补一条真实模型识别证据。
新发布流程只认仓库根目录 bundle/:apps/shiyi-live/bundle 需要调整仓库结构。

评审说明见黑客松官网「初赛入围」。

从你的聊天和邮件里，读出你没说出口的安排。

一条随手的话——「下周三我得去趟深圳」——它读出来，做成一张等你点头的卡；你确认它才动手，而且真的把结果发回原来的地方；到了点，它主动来找你，还把卡念给你听；它还记得你的老规矩。

队伍：三三Claw · 赛道：OctoSense 12 场景「即时消息」 · Apache-2.0
三种形态（脚本应用 / L0 卡片包 / OctoSense 系统 app）· 两个端（桌面 Windows / 安卓真机）

一、提交信息（按官方清单逐项）

Repository: https://github.com/sansanyixyz331/shiyi
Tag: gosim-semifinal-submission（本次重打，指向下面这个 commit）
Full commit SHA: 6fe73c62913bbffe2b4699ef3ebc91c44c3058bb
Bundle path: bundle/（主提交，脚本应用）
App id / version: shiyi / 0.8.6
License: Apache-2.0
签名状态：未签名 —— 按官方 publisher-github-v1 发布流程要求（provenance 与签名由 CI 侧完成）；本地复跑用 --allow-unsigned。详见 README §8

二、演示（各 ≤2 分钟 · 一镜到底 · 旁白 + 硬字幕）

桌面 · 工作场景（消息来自「邮件」） —— 40.8 秒：https://www.bilibili.com/video/BV1xGpq6uEeF
手机 · 日常场景（消息来自「群」） —— 111.9 秒：https://www.bilibili.com/video/BV1tTpq6kEfa

两条正片同时在仓库内（docs/evidence/demo-desktop-mail-20261011/、docs/evidence/demo-phone-groupmsg-20261012/），与上面链接一一对应；B 站只作在线观看的便利，提交以仓内原件为准。

三、三种形态各自证什么

形态	位置	版本	说明
① 脚本应用（主提交）	根 `bundle/`	0.8.6	一句话现场造卡；带 `model`（真实模型调用）；自动读群消息
② L0 卡片包	`apps/shiyi-card/bundle/`	0.3.3	五屏卡片，走总线调用（L0 规范本身禁止卡内调用模型）
③ OctoSense 系统 app	`octos/`	0.3.11	原生快览屏卡 + 助手原地改卡 + 语音念卡；属原生宿主扩展，不以 App Hub 上架作品计，作为技术深度证据

另有 android/：能直接装上试的安卓包（宿主 APK 分卷 + 应用包），方便不想编译的人复核手机端；不参与 App Hub 提交。

四、一个真闭环：来源它自己读进来 → 你点头 → 真的发回去

头是真读、尾是真发，两头都真，环才闭得上：

来源自己进来 —— 群里来一条新消息，它自己读到（不用点、不用打字）；桌面线同构，读的是来信邮件。
Agent 出卡 —— 认出藏在里面的时间、地点与待办，做成一张等你点头的卡；没写出来的明说"我没猜"。
你确认它才动手 —— 确认之前，它只看不动手。
真的发回去 —— 确认一张卡 = 把结论真发回那个群（matrix.send_message）；发不出去就如实回退"只留本机"，绝不假装成功。
到点主动回来找你 —— 到点弹提醒并把卡念出来。

证据：docs/evidence/act/（确认=真办事）· docs/evidence/phone-live-20261011/（手机整链）· docs/可独立复跑_发回群闭环_步骤说明.md（可独立复跑）

五、本次实测

项	结果
官方最新版宿主可运行	用官方 card-host 直接跑本仓 `bundle/` → `admitted` → `[SPLASH] eval: 59625 bytes view=true`，抓到完整画面帧；用的是官方未打补丁的宿主。并在官方最新桌面版 rc.6 上确认可正常安装与启动；提交物摘要与官方最新算法逐字一致（证据：`docs/evidence/rc6-verify-20261013/`）
队外真人试用	由队外用户在其自己的机器上解压便携包、启动、实操并回传实录（`docs/evidence/user-trial-20261013/`，全片不含人脸）
真实模型	模型调用跑在宿主服务层（`model.complete`，不写在卡里）；换任意 OpenAI 兼容模型，作品代码零改动
双端	桌面（Windows）✅ ／安卓真机（小米13）✅ —— 两端都端到端跑通
宿主改造	换机可用性与慢机器适配的三条修复，已整理成可审计补丁并回馈上游（见第九节）

六、对初赛评审建议的回应（逐条）★

初赛评语（83/100）给了三条改进建议，本次逐条落实：

初赛建议	本次怎么做
1. 「发回群」闭环目前只有真机录屏证据，建议提供可独立复跑的步骤说明，或再录一版带时间戳的完整链路	✅ 两个都做了：新增 `docs/可独立复跑_发回群闭环_步骤说明.md`（从装包到"群里真多一条回执"的逐步复跑说明）；并重录两条正片（桌面 40.8s / 手机 111.9s），一镜到底、旁白 + 硬字幕、时长可核
2. Rinx 若放开 `model` 能力映射，把 ASK_MODEL 打开并补一条真实模型识别证据	✅ 主提交已开 `model`：根 `bundle/` 声明 `model` 能力（服务名 `model.complete`），并且改跑在提供该服务的 OctoSense 宿主上（不是 Rinx）；桌面 + 手机双端复验。不接模型时规则路径照常造卡并如实标注降级
3. 新发布流程只认仓库根目录 `bundle/`，`apps/shiyi-live/bundle` 需要调整仓库结构	✅ 已按新流程改制：主应用已移到仓库根 `bundle/`，`apps/shiyi-live/` 现在只剩说明文档。仓库根 `bundle/` = 本次主提交

七、怎么最快验（按你手上有多少时间）

你有多久	看什么
3 分钟	上面两条演示片
20 分钟	两条演示片＋ `docs/评审速览.md`（一页）
要亲手验	README §8 怎么跑（复现） —— 分三档：看已有证据 / 一键重跑 / 改着试；材料清单见 `MATERIALS.md`

八、已知限制（诚实）

matrix.*（读消息 / 档案 / 发消息）由 Rinx 提供，官方 OctoSense 宿主不提供；在官方宿主上运行时如实降级、不假装。「到点排程 / 发声」同为 Rinx 专有，缺失时同样降级。
主提交 bundle/ 在官方宿主上能正常运行（第五节的实测）；但要拿到"自动读群 + 真发回群"这一组能力，需要提供这些能力的宿主（我们随仓给了可自行编译的补丁与现成安卓包）。
手机端未在 OctoSense Home 宿主上验证；listing.platforms 的 android 指实测过的运行路径（真机 + Rinx 本地导入）。
桌面端走标准 SMTP / IMAP 外部服务器，未做企业邮箱域规模验证。
宿主对"迷你应用脚本评估"有 64 ms 默认时限，本作品界面脚本 59.6 KB，在较慢的机器上会被掐断 ⇒ 正文整块空白；对策：用我们修好的宿主（补丁 04，放宽到 3000 ms），或走零安装的 L0 证据层。这是宿主默认值的边界，不是作品缺陷（同机制对照数据已附在官方 makepad#109 下）。
本作品用练习数据（官方 2026-09-24 已明确接受范围），来源逐条标注在 docs/作品设计_拾意.md。

九、回馈上游

在把"换一台机器就缺图标 / 缺字体"这两个坑挖到底之后，我们把最小、零副作用的修复提交给了宿主依赖的上游（复用上游已有的辅助函数，不动正常路径行为，并做了真编译验证）：

OctoSense-org/makepad#121 —— 脚本资源（图标等）换机查找兜底
OctoSense-org/makepad#122 —— 字体换机查找兜底
官方 makepad#109（官方自己在讨论脚本评估时限）下，我们补了真实应用场景的对照数据：同一份 59.6 KB 界面脚本，2015 年的 4 核机器上超时 12 次，2024 年的 20 线程机器上 0 次

作品不依赖这些被合并：仓内 rinx/patches/ 的 03 / 05 是同一修复的自持版本，桌面壳与安卓包都已带上并实机验证。

请按本次 tag gosim-semifinal-submission 复核。初赛 83/100 的评审版本对应结构改制前的快照（185d43c）；本仓结构、能力与材料均以本次 tag 为准。

Submit shiyi 0.7.3 #76

Description

拾意 Pickup → 0.7.3：确认一张卡，真的把事办了

这一版补的，是「应用」那半截

现阶段能力（6 条）

真机证据（Rinx，2026-10-06）

提交信息

Activity

sansanyixyz331 commented on Oct 4, 2026

sansanyixyz331 commented on Oct 4, 2026

sansanyixyz331 commented on Oct 4, 2026

sansanyixyz331 commented on Oct 4, 2026

Update: v0.3.2 supersedes the 0.3.1 bundle submitted above

What was wrong in 0.3.1

The fix

Also corrected in 0.3.2

hub check (verbatim)

Rendering evidence for 0.3.2

Note on the digest and the platform

Known limits

sansanyixyz331 commented on Oct 5, 2026

拾意 Pickup 升到 0.3.3 —— 把「真发送」并进提交包（之前只在备件里）

sansanyixyz331 commented on Oct 5, 2026

拾意 Pickup — 0.7.0：两种形态 + 三条宿主能力，全部真机跑通

两种形态（同一仓）

三条宿主能力（脚本应用侧，全部默认关、失败必兜底）

真机闭环（Rinx，2026-10-05）

契约来源（不猜）

sansanyixyz331 commented on Oct 5, 2026

拾意 Pickup 到 0.7.1：出厂态把两条「总线读」打开，并附一镜到底演示片

相对 0.7.0 的改动

门禁 / 状态

sansanyixyz331 commented on Oct 6, 2026

第三条交付面：OctoSense 本体上，助手现在能「原地改卡」

遇到什么问题

怎么解决（不碰内核）

什么结果

证据与提交信息

sansanyixyz331 commented on Oct 6, 2026

为什么补

两段录屏

提交信息更新

sansanyixyz331 commented on Oct 6, 2026

1. 补上「快览屏（glance）」这一层的实证

2. 便携演示包已发布（评委可直接下载）

3. 一处口径订正（如实说明）

sansanyixyz331 commented on Oct 6, 2026

提交物多轮复检（第 2–5 遍）· 2026-10-06

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 6, 2026

提交信息补全：hub scan 七答 + 发布者公钥 + 完整 commit SHA

提交信息（按官方清单逐项）

Publisher

hub check (verbatim)

hub scan — the seven answers

Run evidence

Known limits

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 6, 2026

sansanyixyz331 commented on Oct 8, 2026

ZhangHanDong commented on Oct 9, 2026

做得好的

改进建议(按重要程度)

sansanyixyz331 commented on Oct 13, 2026

一、提交信息（按官方清单逐项）

二、演示（各 ≤2 分钟 · 一镜到底 · 旁白 + 硬字幕）

三、三种形态各自证什么

四、一个真闭环：来源它自己读进来 → 你点头 → 真的发回去

五、本次实测

六、对初赛评审建议的回应（逐条）★

七、怎么最快验（按你手上有多少时间）

八、已知限制（诚实）

九、回馈上游

Metadata

Metadata

Assignees

Labels

Update: `v0.3.2` supersedes the `0.3.1` bundle submitted above

`hub check` (verbatim)

提交信息补全：`hub scan` 七答 + 发布者公钥 + 完整 commit SHA

`hub check` (verbatim)

`hub scan` — the seven answers