cat ./posts/clawpatch-husky-prepush.en.md
# The two-stage Husky gates used by this CMS: formatting, types, tests, and secret checks at commit time; structure, E2E, dependency audit, and review before push.
+---+ | 名 | +---+
名無し
ほげぼげ
This CMS uses Husky pre-commit and pre-push as two different gates: fast feedback before a commit and repository-specific verification before a push. The exact commands matter more than a generic checklist.
*Diagram: return fast failures before commit and reserve repository-wide verification for pre-push.*
Both hooks invoke pnpm; they do not hard-code an old Corepack release. package.json declares the package-manager version and the Nix development shell enables Corepack. Because .npmrc disables install scripts, a fresh install should not be assumed to have activated hooks: verify git config core.hooksPath after the approved setup.
set -eu
pnpm run format:check
pnpm run typecheck
pnpm run test
pnpm run secrets:staged
pnpm run clawpatch:precommitBiome, TypeScript, Node tests, redacted staged-secret scanning, and the Clawpatch status gate run in order. set -eu stops the commit at the first non-zero exit. This hook does not independently run ESLint or a production build.
set -eu
pnpm run verify:push
pnpm run secrets:historyverify:push adds admin structure coverage, ad-slot auditing, admin-route E2E, dependency auditing, and a dirty-tree Clawpatch review. Gitleaks then scans Git history. These checks cover the failure modes of this CMS rather than pretending that one generic test command is sufficient.
An unqualified pnpm audit checks installed production and development dependencies. Build, test, hook, and deployment tooling are part of this repository's execution surface, so the release gate uses the full audit rather than narrowing it with --prod.
The pre-commit wrapper parses clawpatch status --json and fails when open findings or active locks remain. The push wrapper runs a bounded review including dirty changes, then applies the same state check. A previous zero count is never embedded as a permanent claim; every push evaluates current JSON.
Hooks can be bypassed or absent, so they are feedback, not the only protection. Release verification also runs a production build, and protected branches should have equivalent server-side checks.