Harden WATCHLIST release and runtime contracts

[dd3ok]

Summary

• harden WATCHLIST structure, safety, lifecycle, storage, and semantic contract validation
• align vendor installation guidance, privacy rules, README, maintainer docs, and deterministic CI
• make the seven-file runtime package and v0.4.2 release flow reproducible and fail-closed

Why

The main branch mixed permissive structural checks, duplicated or ambiguous guidance, historical release metadata without a published release, and runtime claims that were not consistently separated from deterministic evidence.

Impact

• runtime bundle remains Python-free and contains exactly seven files
• deterministic checks do not call an LLM or network service
• real vendor runtime smoke remains explicitly pending until recorded against an exact commit

Validation

• 166 unit tests
• release-ready metadata check for 0.4.2
• policy marker and semantic corpus checks (36 semantic / 24 trigger cases)
• strict template and example validation
• exact package-shape check (7 files)
• Python 3.8 syntax, Bash fence syntax, relative Markdown links, and git diff --check
• independent code, documentation, and vendor cross-review: no remaining P0-P2 findings

[dd3ok]

Self-review completed against PR head 91f4eca5cf5c7c4a83bdde448b3d1f6098826ca4.

Findings: no remaining P0-P2 issues.

Checked:

• remote PR head and 44-file scope match the reviewed local commit
• validator and semantic contracts fail closed, including the seven previously identified false-pass mutations
• deterministic Python contains no vendor SDK or network import; CI permissions remain contents: read
• runtime archive is pinned to the exact seven-file manifest and contains no Python runtime dependency
• release commands are exact-SHA, clean-tree, fail-stop, and publish-time revalidated
• docs/vendor/storage/privacy guidance matches the tested contracts
• secret-pattern scan found only the intentionally fake ghp_... negative-test fixture, which is asserted to be rejected

Local validation: 166 tests; 36 semantic cases; 24 trigger cases; release-ready 0.4.2; policy/package/template/example checks; Python 3.8 syntax; Bash fence syntax; relative links; diff whitespace.

GitHub CI is tracked separately below; this is a comment review because authors cannot approve their own PR.

[gemini-code-assist]

Code Review

This pull request significantly updates the documentation, packaging, and validation logic for the watchlist-md skill. Key changes include clarifying storage and privacy policies, hardening the repository release process, and improving the robustness of the skill's installation and validation scripts. The reviewer provided a valuable suggestion to improve the cleanup of temporary files in the Claude Code installation script by using a trap command, which I have included in the feedback summary.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

This script for updating an existing Claude Code installation is much more robust, especially with the backup mechanism. However, there's a small resource leak on failure.

The temporary directory created by mktemp on line 122 is not cleaned up if the mv command on line 127 fails. This could leave temporary files in the user's cache directory.

You can use a trap to ensure the temporary directory is always removed on script exit. You're already using this pattern in docs/maintainers/release.md, so applying it here would improve consistency and robustness.

Suggested change

	staging_parent=$(mktemp -d "${staging_root}/watchlist-md.XXXXXX")
	staging="${staging_parent}/watchlist-md"
	cp -R "${source}" "${staging}"
	test -f "${staging}/SKILL.md"
	mv "${target}" "${backup}"
	if mv "${staging}" "${target}"; then
	rmdir "${staging_parent}"
	echo "Previous install: ${backup}"
	else
	mv "${backup}" "${target}"
	exit 1
	fi
	staging_parent=$(mktemp -d "${staging_root}/watchlist-md.XXXXXX")
	trap 'rm -rf -- "$staging_parent"' EXIT
	staging="${staging_parent}/watchlist-md"
	cp -R "${source}" "${staging}"
	test -f "${staging}/SKILL.md"
	mv "${target}" "${backup}"
	if mv "${staging}" "${target}"; then
	rmdir "${staging_parent}"
	trap - EXIT
	echo "Previous install: ${backup}"
	else
	mv "${backup}" "${target}"
	exit 1
	fi

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91f4eca5cf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Bump the release instead of reusing 0.4.2

The parent changelog already had a ## [0.4.2] - 2026-06-10 release section while VERSION was also 0.4.2, but this change replaces that historical 0.4.2 entry with a new 2026-07-17 release. When v0.4.2 has already been tagged or consumed, the documented release guard will either fail on the existing tag/release or the changelog will rewrite a prior release; these shipped changes need a new version heading and corresponding VERSION bump instead of reusing 0.4.2.

Useful? React with 👍 / 👎.