dsh-release-selfcheck: A Pre-Release Self-Check Checklist for DeepSeek Harness

What Does It Do?

It is a DSH plugin for DeepSeek Harness that turns pre-release checking into a checklist an Agent can run automatically. It targets the failure mode where every CI job is green and the logs show nothing unusual, yet the release is still wrong or incomplete. Once installed, the Agent walks through the checklist before publishing, uploading installers, switching download links, or creating a Release, covering artifact manifests, version consistency, platform architecture, upload filtering, site go-live, and release discipline. It is maintained by feely0208 under the MIT license and written in Shell.

Core Features

• Artifact manifest comparison: checks the expected list against the actual directory item by item, so both extra and missing files get questioned.
• Version consistency checks: verifies package versions, git tags, multiple sites, and multiple product lines do not overwrite each other.
• Platform and architecture validation: unpacks binaries to inspect headers instead of trusting file names, and confirms bundled payload architecture matches the package.
• Live link probing: extracts download links from live pages and sends a HEAD request to each one, where 403 means the origin lacks the file and 000 means a network hiccup.
• Release discipline checks: confirms whether the main program is formally released, whether add-on releases are marked Pre-release, and what latest points to.
• Known false positives section: documents which observations are normal so the checks do not flag healthy releases.

How to Use This Plugin?

After enabling it in DSH, the Agent automatically carries this checklist into any release-related conversation, with no manual trigger needed. The skill ships a runnable script whose path is replaced with the real full path at registration time, exposing subcommands for viewing current config and inferred values, comparing artifact manifests, checking version consistency, probing live links one by one, and reviewing release discipline. All configuration is optional and auto-inferred when unset: the repo root is found by walking up from the current directory, the repo slug comes from git remote origin, and cross-site version comparison is skipped when no main site is given. The script only handles what can be checked mechanically, so judgments like whether an architecture is correct or a manifest is reasonable still need a human or the Agent; it relies on the harness skill capability and silently skips when that capability is missing, without affecting profile startup.

How to Troubleshoot This Plugin?

The checks themselves can produce false alarms, so the README includes a dedicated known-false-positives section: a .blockmap file in a download directory is normal, and sensitive-looking words in a lock file may just be a base64 coincidence, so neither should be treated as a problem. If a verification step rejects a perfectly good package, the assertion is usually at fault — asserting on the output of unzip -l is unreliable, and you should assert on a checkable final result instead. If you see a false failure where the uploader deliberately skips a class of files while the verifier compares the whole directory, the verifier and uploader are not using the same filtering rules, and both need to share one rule set. If a live link probe returns 403, the origin genuinely lacks that file; if it returns 000, it is usually a network hiccup and can be retried before drawing conclusions.