Skip to content

release: correct what the third preset made stale, and declare a version - #21

Merged
yuema137 merged 1 commit into
mainfrom
release/0.1.0-readiness
Sep 10, 2026
Merged

yuema137 merged 1 commit into
mainfrom
release/0.1.0-readiness

Conversation

@yuema137

Copy link
Copy Markdown
Owner

Release-readiness for 0.1.0. Four things a tag would otherwise have shipped as wrong.

1. The hook contract did not mention the standards preset at all

Zero occurrences of "standards" in hook-contract.md. That document exists to say honestly, per requirement, what is specified and what is shipped — a silent omission is precisely the failure it is designed to prevent.

It now names the preset and says plainly that it is not an adapter for anything the contract specifies: it reports a project's own declared checks after a commit, a different axis from the freeze, merge and continuity behaviour, and it blocks nothing.

Claiming it implements H2 would have been the easy and wrong thing: H2 is before a semantic commit, and this reports after one.

Deliberate specification_sha256 baseline update; no requirement changed.

2. A factual error in the platform notes

platforms.md still said the presets "use five groups". Three of them register six. Not wording — a number a reader would check against their own config and find wrong. The Chinese mirror carried it too.

3. The user-facing page advertised two presets while shipping three

hooksStatus read OPTIONAL CONTINUITY + CHECKPOINTS, and the intro named only those two. Someone reading the page had no way to discover the feature we just built.

4. Nothing carried a version

Flagged in the first audit of this repository and still open. A tag makes it worse: a user could not tell which release a project had installed.

The installed copy now ships a VERSION file and --check-hooks reports it:

Installed presets: standards. Skill version 0.1.0. Registration and runtime
files match (claude-code 2.1.267). Commands are portable across machines. …

Deliberately not frontmatter, so no host is asked to tolerate an unknown key, and deliberately no comparison or migration machinery — the question is "which release is this", and a file answers it.

Validation

Ran 167 tests ... OK (skipped=1); --check PASS on 6 translation pairs, the specification baseline, links and fences, and both packages (now 23 / 22 files).

A test pins the version as a plain release string present in both packages, and the coexistence test asserts --check-hooks reports it.

Caught while doing this

The first version of the VERSION read shadowed hook_install.version() — the module-level function that resolves the host CLI version — and broke four tests. Renamed.

Not blocking 0.1.0

Two recorded debts stay open and are documented as such: PostToolUse delivery under an authenticated turn is not directly observed, and merge-guard is unimplemented. 0.1.0 does not claim either.

🤖 Generated with Claude Code

https://claude.ai/code/session_016cCs5DdUjLDkP8V3Z5x6XH

Four things a 0.1.0 tag would otherwise have shipped as wrong.

The hook contract did not mention the standards preset at all. That document
exists to say honestly, per requirement, what is specified and what is shipped,
so a silent omission is the failure it is designed to prevent. It now names the
preset and says plainly that it is not an adapter for anything the contract
specifies: it reports a project's own declared checks after a commit, a different
axis from the freeze, merge and continuity behaviour, and it blocks nothing.
That is a deliberate specification baseline update; no requirement changed.

platforms.md still said the presets "use five groups". Three of them register
six. That was a factual error, not wording, and the Chinese mirror carried it too.

The user-facing hook status still read "continuity + checkpoints", so the page
advertised two presets while shipping three.

Nothing carried a version. The installed copy now ships a VERSION file and
--check-hooks reports it, which is the whole requirement: a user can tell which
release a project has. No frontmatter change, so no host is asked to tolerate an
unknown key, and no comparison or migration machinery, which would be more than
the question needs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016cCs5DdUjLDkP8V3Z5x6XH
@yuema137
yuema137 merged commit f87a22d into main Sep 10, 2026
4 checks passed
@yuema137
yuema137 deleted the release/0.1.0-readiness branch September 10, 2026 04:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant