[Lumos-789]

Plugin type (required) / 插件类型（必填）

• UI Plugin / 是 UI 插件 — provides MCP Apps interactive pages / 提供 MCP Apps 交互页面
• Standard plugin / 普通插件（非 UI） — does not provide MCP Apps interactive pages / 不提供 MCP Apps 交互页面
• Not applicable / 不适用 — repository-only changes; no plugin content changed / 仅仓库级改动，不涉及插件内容

Affected plugin name(s) / 涉及的插件名称：delivery-video

What / 改动内容

EN — Adds delivery-video, which turns a real screen recording of working software into a delivery video with narration, word-synced subtitles and a deterministic quality gate — plus a feedback mode that binds a defect report to one specific cut of that video.

• preflight.py / render.py / verify_delivery.py are real commands; the gate rejects truncated video, stripped audio, a re-encoded resolution, and a tampered or missing feedback report.
• 1.1.2 binds the report content into the evidence chain: a normalized hash of the feedback.json fields plus the exact markdown bytes are written into quality_gate/report.json and recomputed by verify_delivery.py.
• Evidence, not vibes: every take records the artifact SHA256 and the checks that produced DELIVERY=PASS.

中文 — 新增 delivery-video：把真实录屏做成带旁白、逐字字幕与确定性质量闸的交付视频，并支持把缺陷反馈绑定到某个具体成片。1.1.2 把反馈报告的内容哈希与 markdown 字节哈希纳入证据链，改标题／改正文／删 markdown 都会判 FAIL。

Visible behavior and testing / 可见行为与测试

• python3 -m unittest discover -s tests → 18 passed; node --test tests/test_plugin.mjs → 3 passed (Python 3.14.4, Node 24.15.0).
• Feedback-tamper matrix verified in tests/test_feedback_binding.py: clean pass, edited issue.title, edited issue.actual, edited markdown, deleted markdown — the last four exit non-zero with a specific message instead of DELIVERY=PASS.
• Full pipeline exercised on real takes (preflight → tts → subtitles → render → gate) with a real recording.

Not covered by this round / 本轮未覆盖：

• A PASS sample from animated source material is still outstanding: the static fixtures used so far are correctly rejected by the motion checks (T301/T304), so the gate's happy path is proven by the unit tests rather than by a live take.

Version and marketplace registration / 版本与市场注册

• New plugin directory external_plugins/delivery-video/ (18 files, 128 KiB), manifest and marketplace.json entry both at 1.1.2.
• Category productivity; icon added at the repo-root path the entry uses (assets/delivery-video/icon.png, 512×512).
• description_i18n carries en and zh-CN, identical in both files; README.md / README_CN.md both present.

Dependencies, network, permissions, side effects / 依赖、网络、权限与副作用

• Python 3.10+ and Node for the bundled scripts; ffmpeg/ffprobe for rendering and the video checks.
• edge-tts for narration uses Microsoft's public TTS endpoint over the network — this is the only network dependency, and it is documented in both READMEs.
• Writes the artifact, quality_gate/report.json, feedback.json, feedback.generated.md and evidence files under the project's output directory.
• No credentials, no telemetry, no bundled binaries.

Licensing / provenance / 许可与来源

• MIT (LICENSE ships in the plugin directory); code written for this submission.
• Narration is synthesised by edge-tts (MIT) at run time; no voice assets are redistributed.

Self-check / 自查清单

• Plugin name is unique kebab-case; new external plugin directory is external_plugins/delivery-video/; existing fixes retain ownership / 插件名唯一且 kebab-case，外部新增插件位于 external_plugins/delivery-video/，已有插件修复保留原归属
• Usage category is set independently of publisher ownership / 用途分类 category 已填写，与维护归属分开：productivity
• Plugin type and affected names are declared above / 已在上方声明插件类型与涉及的插件名称
• version bumped in BOTH plugin.json and marketplace.json (artifacts are immutable) / plugin.json 与 marketplace.json 两处版本号已同步升级：1.1.2
• README.md (EN) and README_CN.md (中文) both updated and equivalent / 中英文 README 均已更新且语义一致
• description_i18n has both en and zh-CN / description_i18n 包含 en 与 zh-CN
• No secrets, machine-specific paths, or private dependencies / 不含密钥、机器专属路径或私有依赖
• Model/API/network dependencies documented / 模型、API、网络依赖已写明（见上方依赖小节与两个 README）
• python3 scripts/validate.py passes on this branch, and the plugin artifact was built through the same build_zip() code path CI uses (size and sha256 in the comment below). The full python3 scripts/build_dist.py needs the repo's UI-plugin pnpm build and fails identically on upstream main (excalidraw: incomplete build), so CI runs it here — see the note above. / 本地 validate.py 通过，本插件产物用 CI 同一条 build_zip() 路径打出（体积与 sha256 见下方评论）；完整 build_dist.py 依赖仓库自带 UI 插件的 pnpm build，在 main 上同样失败，交由 CI 执行

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[jacksonliuyn]

The current verification notes mainly cover DeepSeek Harness. Could you also document testing in ZCode? Has the full flow been tested successfully in ZCode: plugin installation → Skill invocation → recording → video generation and verification?

Please include the ZCode version, operating system, and results for each step, and explicitly note any steps that have not yet been verified.

[Lumos-789]

Added the requested ZCode acceptance matrix to the PR body. The tested environment was ZCode CLI 0.17.1 on macOS 27.0.1 (26A434, arm64), Node v24.15.0, Python 3.14.4 and FFmpeg 8.1.1.

• Plugin installation: PASS via a local development marketplace. delivery-video@dev-delivery-video-local 1.0.5 reported skillCount=1, skillRootCount=1 and no diagnostics.
• Skill invocation: PASS with delivery-video:delivery-video; it resolved to the installed cache path, not the old ~/.agents copy.
• Recording: PASS. A fresh headless Playwright capture produced a 1920x1080, 313-frame, 10.433s browser take with matching evidence.
• Video generation: PASS using the installed plugin's render.py render; output was 11.800s, 1920x1080, 30fps, h264 + AAC, SHA256 eecf8d6d599a46a03352177b4cf92e1ce7324a0eee33b86fddc099916544f516.
• Verification: PASS with verify_delivery.py; score 100, zero hard failures, zero warnings, three shots. M111 remains an informational notice.

The full recording → render → verify chain ran in one ZCode Agent session. Not verified in ZCode: installation/update from the public marketplace index, Windows/Linux, an independent visual-critic.json review, and upload/publish. The ZCode CLI headless runner on this app bundle needed a local built-in-provider path shim; that is a launcher/environment issue, not plugin code. No video was uploaded or published.

One ZCode-specific usability note is documented: when ~/.agents/skills/delivery-video already exists, unqualified /skill delivery-video selects the older user copy. Select delivery-video:delivery-video or use /skill delivery-video:delivery-video <task> to invoke the installed plugin.

[Lumos-789]

ZCode acceptance v2: full lifecycle, failure paths, and sample renders

Tested on 2026-11-02 with ZCode CLI 0.17.1 on macOS 27.0.1 (26A434, arm64), Node v24.15.0, Python 3.14.4 and FFmpeg 8.1.1, plus one Linux run inside python:3.11-slim with Debian ffmpeg and fonts-noto-cjk. The plugin was the 1.0.5 build installed from a local development marketplace; every command below ran against the installed cache path, not the source tree.

Install lifecycle

Scenario	Result	Evidence
Fresh install (1.0.5)	PASS	Installed plugin delivery-video@dev-delivery-video-local (1.0.5) [enabled]; plugins list reports skills: 1; skills list shows exactly one delivery-video:delivery-video at .../cache/dev-delivery-video-local/delivery-video/1.0.5/skills/delivery-video/SKILL.md
Manifest validation	PASS	zcode plugins validate succeeds on both the marketplace copy and the installed cache
Update 1.0.4 → 1.0.5	PASS	Installed 1.0.4 from a second local market, bumped that market to 1.0.5, plugins update reported Updated ... from 1.0.4 to 1.0.5 and the cache path moved to 1.0.5
Disable / enable	PASS	plugins disable removes the delivery-video:delivery-video entry from skills list (count 1 → 0); enable restores it (0 → 1)
Uninstall	PASS	plugins uninstall --force removes the plugin from plugins list and from skills list

Skill selection

Scenario	Result	Evidence
Qualified invocation	PASS	Session asked to use delivery-video:delivery-video resolved .../cache/dev-delivery-video-local/delivery-video/1.0.5/skills/delivery-video/SKILL.md and .../scripts/render.py, with a working directory containing Chinese characters and spaces
Bare name with an older ~/.agents/skills/delivery-video present	Expected	The unqualified name loads ~/.agents/skills/delivery-video/SKILL.md; this matches the README note, so the qualified name is required when both copies exist
Natural-language trigger with both copies present	Observation	"record a delivery video for the feature we just finished" also selects the older user copy, because its description matches better and it owns the bare name. On a machine without that manual copy, the plugin Skill is the only match. No plugin change made; README already tells users to use delivery-video:delivery-video

Recording → render → verify (real ZCode Agent session)

One headless ZCode session ran the installed plugin end to end in .../zcode-matrix-.../中文 空格 工作区:

Step	Result	Evidence
Real recording	PASS	Headless Playwright capture of the test page: 1920x1080, 314 frames, 10.467s, evidence SHA256 95c17137cf5b3bd7fccdb32a727ec694f65857736ee94f0d06f3960553633d89
preflight.py	PASS	3 segments OK; one expected warning that TTS was not cached yet
render.py render	PASS	11.800s, 1920x1080, 30fps, h264 + AAC, gate=pass, score 100
verify_delivery.py	PASS	DELIVERY=PASS, 3 shots, 0 hard failures, 0 warnings; M111 stays informational (607 kbps bitrate density)
Re-render determinism	PASS	Second render produced a byte-identical artifact: 1491fe00db39c6947128f016bc360333bc5c61d3e624e29098446d7ad42194f5
Independent render.py gate on the mp4	PASS	GATE=PASS ... score=100 profile=delivery-v1
Key-frame review	PASS	Frames at 1.5s / 5.0s / 9.0s inspected at 1080p: labels, subtitles and the read-back state are all legible

Failure paths

Scenario	Result	Evidence
--require-critic without visual-critic.json	Fails as designed	FAIL: missing independent visual review: .../visual-critic.json, exit 1
Tampered artifact	Detected	Appending bytes to a copy of the mp4 gives FAIL: quality report is not bound to this artifact (video_sha256 missing or mismatched), exit 1
No ffmpeg / ffprobe on PATH	Clean failure	preflight.py, render.py gate and verify_delivery.py each exit 1 with actionable messages such as FAIL: ffmpeg is not on PATH and missing required executable(s): ffmpeg, ffprobe; no Python traceback

Linux host

The same episode was rendered inside python:3.11-slim with Debian ffmpeg and fonts-noto-cjk:

• preflight.py: PASS (3 segments)
• render.py render: PASS, 11.800s, score 100
• verify_delivery.py: PASS, 3 shots, 0 hard failures, 0 warnings
• SHA256: 2e464f799db469e70bbeb890d2487ef2a4df68173c0f493506565746017b3e42

Sample renders for review

Both files come from the same three-segment episode and were gated at score 100:

• screen_demo-macos.mp4 — macOS arm64, sha256 1491fe00db39c6947128f016bc360333bc5c61d3e624e29098446d7ad42194f5
• screen_demo-linux.mp4 — Linux container, sha256 2e464f799db469e70bbeb890d2487ef2a4df68173c0f493506565746017b3e42

These are attached as a pre-release on my fork purely as review evidence, not as a plugin release. Both URLs were re-downloaded and hashed after upload; the hashes above match the rendered files.

ZCode CLI observations (not plugin defects)

• Two marketplaces exposing the same plugin name can both be enabled, which produces two identical delivery-video:delivery-video entries. plugins update delivery-video then requires the qualified delivery-video@<marketplace> form.
• In a non-interactive shell plugins uninstall requires --force; even then, versioned cache directories for a removed development market remain on disk.
• The CLI inside the macOS app bundle needs a built-in-provider config path shim to run headless on this machine. That is a launcher/environment issue, not plugin code, and it is absent on the normal desktop path.

Still not verified in ZCode

Install or update from the public marketplace index (this round used local development marketplaces only), Windows, the desktop GUI flow (all runs above used the CLI headless runner), an independent visual-critic.json review, delivery.md generation, and upload/publish of user videos.

[Lumos-789]

Session IDs behind the matrix above

ZCode persists every CLI run as a session. These are the exact session IDs behind the acceptance table, recorded on 2026-11-02 (times Asia/Shanghai) in /Users/black-wood/IdeaProjects/oss-projects/.agents/zcode-matrix-20261102-183213/中文 空格 工作区:

Session ID	Started	What it covered	Result
sess_c9dc2a1a-ce2f-4254-a92e-a15e98aa4ec0	18:33:52	CLI/auth sanity prompt, /private/tmp	PASS: PING-OK
sess_8725d5ea-7cc6-44ce-9982-486235fde7be	18:34:13	Qualified invocation delivery-video:delivery-video	PASS: resolved the installed cache path and its scripts/render.py
sess_dc957781-c2dd-4723-b6ee-4bb0daba6470	18:34:37	Unqualified name with the older ~/.agents copy present	Expected: resolved the user-level copy
sess_58d5ae5f-b7a1-44e8-813c-908095f82cba	18:35:47	Full chain with the installed plugin: preflight → render → verify	PASS: 11.800s, 1920x1080, 30fps, h264+AAC, score 100, sha256 1491fe00db39c6947128f016bc360333bc5c61d3e624e29098446d7ad42194f5
sess_752cab8b-b9a6-4d6d-af7b-b801bef7f3b8	18:40:03	Natural-language trigger with both copies present	Observation: selected the user-level copy; the qualified name selects the plugin

Prior round (the earlier single-session evidence, recorded 18:08 in zcode-e2e.Qx5Y8G): sess_9d5551b4-4d0a-42a3-9026-8d3beb007931 — 11.800s, 1920x1080, 30fps, h264+AAC, score 100, sha256 eecf8d6d599a46a03352177b4cf92e1ce7324a0eee33b86fddc099916544f516.

Full index with the same table: zcode-session-index.md.

To inspect locally, ZCode stores sessions in ~/.zcode/cli/db/db.sqlite (table session, columns id, title, directory, time_created) and writes per-session model I/O to ~/.zcode/cli/rollout/model-io-<session-id>.jsonl.

Two caveats: session IDs are local to the machine that ran the test (-p headless runs are not resumable remotely), and the lifecycle/failure-path checks (zcode plugins ..., missing-ffmpeg runs, tamper test) ran outside Agent sessions, so they have no session id. Those are reproducible with the commands listed in the previous comment.

[Lumos-789]

@jacksonliuyn the ZCode verification you asked for is in the two comments above; linking them here so they are easy to find:

• Full ZCode matrix, with version/OS and per-step results (install lifecycle, Skill invocation, recording, render, verify, failure paths, macOS + Linux): feat(delivery-video): add the delivery-demo and feedback-recorder plugin (1.1.2) #146 (comment)
• Session IDs behind each row of that matrix: feat(delivery-video): add the delivery-demo and feedback-recorder plugin (1.1.2) #146 (comment)
• Sample renders, both gated at score 100: macOS · Linux
• Session index file: https://github.com/Lumos-789/delivery-video-plugin/releases/download/acceptance-zcode-2026-11-02/zcode-session-index.md

Short version: yes, the full chain passes in ZCode CLI 0.17.1 on macOS 27.0.1 (26A434, arm64) — plugin installation → Skill invocation → recording → video generation → verification, plus a Linux container run. Install/update/disable/enable/uninstall and the failure paths (missing ffmpeg, tampered artifact, --require-critic) behave as designed.

Not verified: install/update from the public marketplace index, Windows, the desktop GUI flow, an independent visual-critic.json, delivery.md generation, and upload/publish.

No code changes were needed; the head is still 0806be8.

[Lumos-789]

Case-driven delivery demo (1.0.6 guidance, real run)

1.0.6 adds optional case-driven recording guidance: when a video covers two or more acceptance cases, write the case list first, record one real run per case, and give each case its own result segment. It is guidance only — no new gate.

We exercised this flow on a real local project (an after-sales ticket handover desk, iterated v1 → v2: bulk assignment, closed-ticket guard, audit log) and recorded two acceptance cases with the installed plugin:

• C-01 bulk assignment (21.7s): 3 tickets assigned to one owner, owner read back after refresh, 3 audit entries shown.
• C-02 closed-ticket guard (19.3s): 2 tickets assigned normally, 1 closed ticket skipped with the reason stated on screen; the audit log shows both outcomes.

Both renders passed the built-in delivery gate at score 100 and verify_delivery.py. Each case ran with its own port and its own SQLite database, so one case's result state cannot bleed into the next.

Videos and the case list (prerelease release assets, not committed to git):

• C-01: https://github.com/Lumos-789/delivery-video-plugin/releases/download/demo-cases-2026-11-02/C-01-bulk-assign.mp4
  SHA256 7988c38d35842675173d65687d9ab5612e78bc953a0e7aec38ac3f67b37060d2
• C-02: https://github.com/Lumos-789/delivery-video-plugin/releases/download/demo-cases-2026-11-02/C-02-closed-guard.mp4
  SHA256 d56f95ebcfbad5acfe748e63f5d125962bb5e8fd899347e764671f14b45cb999
• Case list: https://github.com/Lumos-789/delivery-video-plugin/releases/download/demo-cases-2026-11-02/cases.md
• Release: https://github.com/Lumos-789/delivery-video-plugin/releases/tag/demo-cases-2026-11-02

Both SHA256 values were re-verified against the downloaded release assets. Demo data is synthetic; no independent visual critic was run for these two renders.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[Lumos-789]

1.1.1 feedback report videos — ZCode verification (2026-11-04)

Updated this PR in place to 1.1.1: full payload re-sync, marketplace.json version/description/description_i18n matching plugin.json verbatim, new examples/feedback-episode.example.json.

Environment: ZCode CLI 0.17.1, macOS arm64, Python 3.14.4, FFmpeg 8.1.1. Installed with zcode plugins update delivery-video@dev-oss-projects → 1.0.6 → 1.1.1, then ran two real Agent sessions with zcode -p --mode yolo, forcing the qualified skill name delivery-video:delivery-video.

Session	Episode	Steps	Artifact
sess_093bf999-816a-452d-9a8b-a4ad5d7e259a	feedback (intent: "feedback")	preflight PASS → render gate=pass score 100, 13.500s → verify DELIVERY=PASS	SHA256 1c09efecbcb5758a1fab876176b7c4cb0eeab1a2849271c45a14d382928185a6
sess_56fa275f-98f3-402f-a9e6-19690b6fc9d2	delivery (regression)	preflight PASS → render gate=pass score 100, 12.600s → verify DELIVERY=PASS	SHA256 375f1bd830db2fca55d09d35c72a39bebbebdc4bf20799c0038bd5abcdb7a005

In both sessions the agent resolved the scripts from the installed cache ~/.zcode/cli/plugins/cache/dev-oss-projects/delivery-video/1.1.1/skills/delivery-video/scripts/, not from the repo checkout.

Feedback artifacts: feedback.json (issue ZCODE-VERIFY-1, severity critical) and feedback.generated.md. Frame inspection confirmed P1 CRITICAL + REPRO chips with the repro panel on segment 1 and P1 CRITICAL + ACTUAL on segment 2.

Repo-side gates for the same commit: npm test PASS (12 Python + 3 Node), plugin_acceptance.py PASS delivery-video@1.1.1, marketplace_check.py OK, public release gate 0 blocking findings.

Not covered: uploading/publishing to a customer channel (none was performed), external visual-critic.json review, and a Windows/Linux host re-run.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[Lumos-789]

Third round — review & simplification (2026-11-05)

No new features. Most of what this round fixed is documentation that described behaviour the code does not have — worth flagging because a reviewer reading only the docs would draw the wrong conclusions:

Doc said	Code does
speed is "clamped" to 0.3x–3x	it is hard-checked: preflight FAIL / RenderError, never silently adjusted
output must be "h264 + AAC"	only h264 / 1080p30 are hard; non-AAC is warning E102 and the run still reports DELIVERY=PASS
--require-critic enforces E401	E401 does not exist; the real message is missing independent visual review: …
the AI-tone red line catches "this is not X, it's Y"	the only pattern is the Chinese 这…不是…而是/是
demo-stage defaults to crop [260,64,1340,780]	window captures default to that; demo-stage evidence is validated against the full 1920×1080 frame

Also removed: the quality_gate-reviewed fallback (no producer, no test, no docs — it could only fire for a directory nobody creates), a set of constants preflight.py had copied from render.py while already importing from it, and three duplicated blocks (case list, feedback rules, browser-evidence contract) that now point at their single source.

Verification: 18 Python + 3 Node tests pass (re-run), tools/plugin_acceptance.py and the public-release gate are clean, and the install lifecycle matrix passes for 1.1.2.

Payload: re-synced, 18 files, verified blob-by-blob against Lumos-789/delivery-video-plugin@1a32ddd. Note the payload lives at external_plugins/delivery-video/ (plugin name) even though the repo is delivery-video-plugin — the marketplace entry's source points there.

Not verified this round: no new recording was produced; the quality-gate logic and thresholds are byte-identical to 1.1.2 as reviewed above.

[Lumos-789]

A real render was run on 1.1.2 (2026-11-05)

Not a new recording for delivery, but a live exercise of the whole pipeline with a genuine 1920×1080@30 take captured from a real browser session:

preflight.py → PREFLIGHT=PASS (2 segments, both in range) → render.py render → edge-tts narration synthesized, subtitles word-synced, segments concatenated, gate executed → verify_delivery.py.

The gate rejected my footage, correctly. Four attempts against the same static source:

Attempt	Gate
full frame, 2 segments	gate=fail score 80 — T301 longest freeze 4.7 s, T304 frozen frames 87 %
tighter crop	score 80 — same two
shorter narration (0.36x → 0.71x)	score 88 — T301 cleared, T304 68 %
1.4 s windows, +80 % narration rate	score 90 — T304 62 %

verify_delivery.py reported DELIVERY=FAIL issues=2 and exit 1 every time. The source was a scripted fixture scene that holds still for 2.5 s per step, so it cannot pass a "no long static stretches" rule — the rule doing its job rather than a defect.

What this confirms: the render path, TTS, subtitle timing and both gate implementations run end-to-end on 1.1.2; the hard-failure thresholds fire and are not advisory.

What it does not confirm: a passing sample on 1.1.2. Producing one needs footage with sustained motion (real interaction, scrolling, typing), which this round did not have.

[panda920]

✅ Internal validation passed. A ZCode maintainer will review the change next; after acceptance, release checks run separately and this PR is closed automatically.

[Lumos-789]

Re-pushed this branch as ac6daaf1 and fixed two classes of defect that were ours, not the repository's. Nothing about the plugin's behaviour changed.

1. The PR now follows .github/PULL_REQUEST_TEMPLATE.md. The body had drifted into hand-written prose and lost the two parts a reviewer checks first: the Plugin type declaration and the Self-check list. Both are back, the five sections CONTRIBUTING asks for are filled in (problem / visible behaviour and testing / version and marketplace registration / dependencies and side effects / licensing), and the title carries the (<plugin-name>) scope the template requires for the squash commit on main.

2. The entry named the repo-root assets/delivery-video/icon.png, but that file was never uploaded with the branch — the catalogue would have shown a broken icon. It is committed now (512×512) and the entry uses the same absolute CDN form as every other icon-bearing entry in marketplace.json.

Re-verified against the branch itself (not a local checkout):

check	result
python3 scripts/validate.py @ ac6daaf1	OK: 53 plugin(s) validated
plugin artifact via build_zip() — the same code path CI runs	51884 B, sha256 cd575def52a9c92f77cd7b5ecc53ab169e0442cdef74477484cad7575bb18f3f
assets/delivery-video/icon.png	present, 512×512
README.md + README_CN.md in the payload	both present

Request: the earlier validate status was bound to a3377d7c, so it is stale after this push. Could you re-run the external validation on ac6daaf1? The full build_dist.py still needs the repository's UI-plugin pnpm build and fails identically on main (excalidraw: incomplete build; run pnpm build first), which is why I am relying on CI for that step.

中文摘要：本轮只补元数据与载荷完整性 —— 恢复了模板要求的插件类型声明与自查清单、标题加上 (插件名) scope（模板说明该标题会成为 main 上的 squash commit）、把条目引用的根级图标真正提交并以 CDN 绝对地址引用。分支上 validate.py 通过，插件产物按 CI 同一代码路径打包成功（体积与 sha256 见上表）。旧的 validate 状态绑定在 a3377d7c 上已失效，请在 ac6daaf1 上重跑一次校验。