Proposal: add real-host release lifecycle validation to the plugin-development Skill / 建议增加真实宿主发布门禁

[iiwish]

Proposal

Add a short, vendor-neutral release lifecycle gate to the official cordis-plugin-development Agent Skill.

The current Skill is strong at inspecting live capabilities, defining immutable Cordis Packages, running/updating them, and handling approval or repair. A distributable DSH Profile Bundle has one additional boundary: the packed release artifact should prove that it can install, boot, register, execute, uninstall, and reboot in an exact real host. Generated source and a successful cordis_run alone cannot prove that boundary.

Suggested Skill text

The following could be inserted after the standard development workflow without requiring any particular test product:

## Validate a distributable Plugin

Before releasing a Plugin as a DSH Profile Bundle:

1. Test the packed artifact, not only the repository source.
2. Install it beside an exact supported DSH version in a disposable environment.
3. Boot the real host and assert the declared rows, Services, Tools, and other public capabilities.
4. Exercise the smallest deterministic capability path without relying on model selection.
5. Uninstall the Plugin, reboot the same profile, and check for owned capability, process, port, and filesystem residue.
6. Retain the exact artifact identity, DSH version, scenario, result, reproduction command, and machine-readable evidence.

Use an external runner when host boot or Tool registration is part of the behavior under test. An in-host Tool cannot diagnose a host that fails before that Tool registers. Do not weaken declared expectations merely to obtain a pass, and do not describe a lifecycle pass as a security certification or model-quality evaluation.

This complements unit tests, manifest/preflight checks, plugin doctors, and multi-bundle composition checks rather than replacing them.

Reference implementation and evidence

DSH Testkit v0.3.0 is one unofficial community implementation of this workflow. It is not proposed as a mandatory dependency or an official endorsement.

• One-command setup: pnpm dsh-test init
• Real-host lifecycle: pack → install → boot → register → deterministic exercise → uninstall → reboot → residue check
• Agent Skill: project-local .agents/skills/dsh-testkit/SKILL.md plus optional DSH runtime registration
• Reviewed implementation: PR #12
• Public release workflow: GitHub Actions run
• npm SLSA provenance: attestation
• Community context and maintainer recruitment: Show & Tell #2038

Because the repository's current contribution policy does not accept external pull requests, I am proposing the wording here rather than opening a PR.

Would maintainers prefer this release boundary in the built-in Agent Skill, in the plugin tutorial, or in both with the Skill linking to the longer guide?

---

中文摘要

建议在官方 cordis-plugin-development Skill 中增加一段与具体工具无关的发布前真实宿主生命周期验证：测试实际打包产物，在精确 DSH 版本中完成安装、启动、能力注册、确定性调用、卸载、同 profile 重启和残留检查，并保留机器可读证据。

这不是要求官方依赖 DSH Testkit。Testkit v0.3.0 只是已经通过公共 npm、真实 DSH profile 和 provenance 验证的社区参考实现。核心目标是让 Agent 在“写完插件”和“发布 bundle”之间主动想起这条独立边界。

[iiwish]

Follow-up evidence: dsh-testkit@0.3.1 applies this proposed boundary to a real public template repository root.

The first root run exposed two runner defects that source-only and synthetic fixtures had not revealed: Git-resolution logs were retained but absent from the strict report artifact set, and legitimate prepare output could precede the final npm pack --json array. Both were fixed fail-closed in PR #13, then the released public package passed package → install → assemble → boot → register → deterministic exercise → uninstall → reboot → cleanup against the template.

The adoptable integration is open at bugmaker2/dsh-plugin-template#1. Its generated project Skill, exact scenario, and least-privilege Action show how the vendor-neutral text above can become a default Agent/release habit without making Testkit an official dependency.

中文补充：把门禁真正接入公开模板后确实发现了仅靠源码测试和合成 fixture 没暴露的问题；v0.3.1 修复后，公共 npm 产物已在模板仓库根目录完整通过。这也说明官方 Skill 或插件教程中加入“测试实际打包产物、卸载后重启并保留证据”是一个独立且有现实价值的边界。