release

Release — the DOS kernel

Semver: major.minor.patch. Patch = bug fix, minor = new feature, major = breaking.

DOS is a substrate, not an app. This skill is the DOS-context adaptation of the job release skill. It is deliberately thinner: DOS single-sources its version from pyproject.toml (one marker, not four), ships no release-asset zip archive, screenshots, versioned-install snapshot, plan-state regeneration, apply-loop gate, or fanout/dispatch manifest. The dist artifacts — one wheel per OS/arch, each embedding its native dos-hook fast-path binary at dos/_bin/ (docs/286), plus a pure-source sdist — are built by CI (publish.yml via scripts/build_wheels.py), never by this skill locally. The verification step is the kernel test suite + the truth syscall, not an apply pipeline. If you find yourself reaching for any of those job-only ceremonies, you're in the wrong repo's skill.

One exception — the plugin's native hook binaries. The Claude Code plugin (claude-plugin/) bundles the compiled dos-hook fast-path binaries (docs/125 GHF4), committed into claude-plugin/bin/ so a marketplace install (a git clone) is a direct install. They are NOT a release asset and NOT in the wheel — they live in the git tree. Step 5.5 rebuilds them so a release never ships a stale binary against changed Go source.

Trunk is master (there is no main branch in DOS). Every git push in this skill targets master. Master-direct is the deliberate branching model for now (a trunk+lane-branch PR cutover is planned, evidence-triggered — not a dev branch); this skill assumes it.

This repo is PUBLIC and the tag is a publish trigger (the 2026-06-10 cutover). Three consequences every release run must respect:

1. A push IS publication. origin is the public anthony-chaudhary/dos-kernel. The machine-local pre-push hook (.git/hooks/pre-push) runs the leak scanner (scripts/leak_scan.py, a gitignored sync of the canonical ../dos-private/tools/leak_scan.py) and is fail-closed: a hit — or a missing scanner — refuses the push. On a refusal: scrub and amend, never --no-verify ("a leak is a refusal, not a warning"). Details in the runbook's Public-repo push gates section.
2. Pushing the vX.Y.Z tag starts the PyPI publish pipeline. publish.yml fires on every v* tag: it builds the per-platform wheels + sdist, asserts tag == pyproject.toml version, refuses to upload any SHA without a green ci.yml run on it (the ci-green witness gate — it polls while CI finishes), then pauses at the protected pypi environment for the operator's approval before the OIDC Trusted-Publishing upload. So Step 6's tag push is also the publish request, and Step 7.4 is "surface/approve the pipeline," not "run twine."
3. Release notes are public documents. docs/releases/vX.Y.Z.md ships to the world (and into the GH release body). No dev-machine absolute paths, hostnames, or personal identifiers; private-SUBJECT prose (operator process, fleet audits, launch mechanics) is born in dos-private, never here — the CLAUDE.md route-privacy-at-authoring-time rule, applied to the notes you draft in Step 3.