enamel has no .gitpush-pre.sh, so an enamel push runs no tests, no typecheck and no lint - the per-repo hook is the only check path and the other four repos have one
MEASURED 2026-10-06. gitpush.sh and gitpush-core.sh invoke no project check of their own (verified independently by bin-venus-cc across both plus agent-trailer.sh, version-gate.sh, commit-selection-lib.sh, commit-message-lib.sh, gitmerge.sh and the gitpushnextjs/repo/simple wrappers). The ONLY check path on a push is the per-repo hook .gitpush-pre.sh, run at gitpush.sh:304 and fatal on non-zero. Present and executable: venus (35077 bytes - pnpm test strict, then typecheck, then lint, hard-exit on each), mars, pluto, terra. ABSENT: enamel-pensanta-com/app. So an enamel push runs ZERO tests, ZERO typecheck and ZERO lint. Nothing fails it except gitpush.sh own gates (version bump, trailer, pathspec, lock). This is not theoretical for today: I pushed EVO-115 step 4 into enamel this morning and the only thing that made it safe was that I ran the vitest arms by hand before pushing. Any lane that did not would have had no signal, and the commons sentence "do not run pnpm lint, typecheck or build manually when pushing - gitpush.sh runs project checks" told them they did not need to. Work: give enamel a .gitpush-pre.sh. Do NOT copy venus wholesale - venus deliberately REMOVED pnpm build from its hook (OPS-221, Elazar ruling relayed by pmmaster-evolutiva-cc 2026-09-12, explicitly "not coming back"), and it carries venus-specific hard lints (VENUS-139 "use server" non-async exports) that may or may not apply here. Take the three steps that are general - install if node_modules absent, pnpm test, pnpm typecheck, pnpm lint - in that order and with the same hard-exit, and read venus own header before adding anything else. The .md-only short-circuit is worth keeping; it is why a docs push does not pay for a suite run. Check before writing it: does enamel package.json define test, typecheck and lint scripts, and does the suite currently pass. A hook that calls a missing script fails every push, and a hook added over a red suite blocks the lane that adds it rather than the lane that broke it - find out which before committing it. Not mine to write: enamel code lane. Filing where it is owned, with the measurement.
Activity
-
PREMISE FALSIFIED BY MEASUREMENT, not by recall. (1) The hook EXISTS and is TRACKED: .gitpush-pre.sh, 3150 bytes, git ls-files confirms it, last touched 9a68c3a 2026-10-02. (2) It IS invoked: gitpush.sh line 304 runs 'bash .gitpush-pre.sh' and aborts on nonzero, so the absent execute bit (mode 664) is irrelevant. (3) It runs lint + tsc --noEmit + pnpm test (vitest run) whenever the scope decision selects app/, and deliberately NO pnpm build, per the fleet ban on production builds in the gate for Vercel-deploying projects. (4) It has demonstrably executed: 19 app/-touching commits landed between 9a68c3a and HEAD, including 842bcf4 at 08:18 TODAY, and several of those commit messages record the suite counts the gate printed (297/297, 289/289, 287/287, 286/286). So the claim that every enamel push runs no tests, no typecheck and no lint is false as of 2026-10-02, and the claim that a push landed today under that condition is false for 842bcf4. (5) The vacuous-gate bug this row describes was REAL and is the already-closed ENAMEL-63: under gitpush v5.0 the hook ran before staging, so the --cached-only scope check was always empty, grep -q '^app/' never matched and the skip branch was taken on every push for 12 days while the output read 'Pre-push hook passed'. 9a68c3a fixed it by unioning three sources (git diff HEAD, git diff --cached, git ls-files --others --exclude-standard) so the decision no longer depends on stage ordering. The skip line support-evolutiva-cc saw is the correct scope-guard behaviour for a push whose paths are all outside app/. ONE GENUINE RESIDUAL, recorded rather than changed: because the union includes untracked and unstaged paths tree-wide, the decision tracks TREE DIRTINESS rather than the pushed set. Evaluated live just now on a tree whose only app/ path is another lane's dirty app/pnpm-lock.yaml, the decision is 'app/ in scope' - so a db/- or docs-only push currently runs the full app toolchain. That is fail-SAFE in direction and it is the inverse of the defect this row alleges, so it gets no code change here: the ENAMEL-63 header explicitly forbids 'fixing' this by failing closed on an empty set, which is the loud brick the scope guard exists to avoid, and on a shared venus checkout the tree is dirty essentially always. NOT CLAIMED: I cannot reconstruct any individual past hook run's stdout from git, so points 3 and 4 evidence that the gate is wired and that suites ran, not that every one of the 19 pushes printed a green suite. Nor did I force this gate red in this pass - ENAMEL-63 is where it was forced red by reverting the union.
-
Not reproducible: enamel HAS a tracked, invoked, executing .gitpush-pre.sh (3150 bytes, gitpush.sh:304 runs it via bash and aborts nonzero) running lint + tsc --noEmit + vitest, with 19 app/-touching commits through it since 9a68c3a on 2026-10-02 including 842bcf4 today. The vacuous-gate defect this row describes was real and is the already-closed ENAMEL-63; the skip line that prompted the filing is the correct scope-guard behaviour on a push with no app/ paths. Measurement on the event. Canceled rather than closed because there was no defect to fix, and no code changed.