Remove the local production build from every .gitpush-pre.sh - lint and typecheck stay, Vercel builds
Elazar ruling 2026-09-12 CLI: gitpush.sh should run lint and typecheck and then hand off; the recipient builds. MEASURED: 9 of 14 .gitpush-pre.sh files run a build. Build-invocation counts per hook: venus 5, enamel 3, and one each in mars, terra, pluto, ayudarg-solo (plus its app/), ayudarg-com-ar (plus its app/). Already clean: websites root, kidsclubcafe, soportepreguntas, hormigonacero, api-images-evolutiva. NOTE gitpush.sh ALREADY AGREES AND CONTRADICTS ITSELF: line 868 tells agents never to run pnpm build or next build, while the hook template at lines 828-830 runs pnpm lint and pnpm typecheck and pnpm build. Doctrine and implementation disagree inside one file. PREFERRED FIX: delete the pnpm build line from each hook. Exactly the ruling's semantics, mechanical, no gitpush.sh change, each rides its own repo's next push. REJECTED ALTERNATIVE, and say so if you propose it anyway: flipping QUICK_MODE to default. One file and fleet-wide, but the QUICK branch ALSO lints only CHANGED files, so it silently cuts lint coverage - a second behaviour change Elazar did not ask for. Only viable if the QUICK branch is first changed to lint everything. Line 899 wraps the build in systemd-run --scope -p MemoryMax=4G, which is evidence someone already knew the build was the expensive step and guarded it instead of removing it. Acceptance: name the 9 files changed, and confirm lint and typecheck still run in each - do not report clean, report which hooks you exercised.
Sub-tickets — 0/1 done
Activity
-
SCOPE CORRECTED: 7 real build invocations, not 9, and the two dropped ones are not a rounding difference - they are the wrong KIND of hit. pmmasterassistant-evolutiva-cc read file CONTENT instead of trusting the grep hit-count, and found that mars:370 and enamel:7/27/40 are COMMENTS. enamel:27 literally reads "NO pnpm build HERE, DELIBERATELY - do not add one back." mars had its build removed 2026-08-09 under an Elazar ruling of "do not reinstate". So dispatching the original list would have sent two coder agents to strip code that is not there, and in mars case to edit against a standing ruling, on the authority of a work order generated by counting matches. SAME DEFECT FAMILY AS OPS-239, filed twenty minutes earlier, and worth saying in one place: a grep that answers a question about CODE with a count of LINES will include the comment documenting the absence of the code. OPS-239 is a grep that cannot see the file; this is a grep that cannot see that the line is a comment. Both fail toward a confident number. The measurement that survives is the one that opens the file. THE 7: terra/.gitpush-pre.sh:854, venus/.gitpush-pre.sh:684, pluto/.gitpush-pre.sh:607 (inside the test-guard block), ayudarg-com-ar/.gitpush-pre.sh:86 + its app/.gitpush-pre.sh:2, ayudarg-solo/.gitpush-pre.sh:86 + its app/.gitpush-pre.sh:2. The four ayudarg lines are "pnpm lint && pnpm build" - a COMPOUND, so the edit there is not a line deletion, it is dropping the second half and keeping lint. Anyone who deletes that line whole removes lint coverage, which is exactly the regression the rejected QUICK_MODE alternative was rejected for. STAFFING CHANGED UNDER THE ROW: Elazar launched pluto and venus after the original sweep, so both are staffed and my "unstaffed, do not route" instruction was already stale when I gave it. coder-terra-cc, coder-venus-cc, coder-enamel-cc, coder-mars-cc IDLE; coder-pluto-cc BUSY mid-compact at 315k/250k. GO dispatched to coder-terra-cc, coder-venus-cc, coder-pluto-cc for one line each. mars and enamel deliberately NOT dispatched - nothing to do. REMAINDER HELD BY pmmaster-evolutiva-cc: the 4 ayudarg lines across 2 genuinely unstaffed repos (no registered agent at all), Elazar rates ayudarg low priority. Not routed, not handed to a substitute recipient, and deliberately not closed - this row is not complete while those 4 lines stand.
-
VERDICT (coverage, not cleanliness): lint and typecheck exercised in terra (forced probe, negative control TS2322 confirmed still blocking), venus (live 16-file dirty tree, 915 tests), pluto (via set -euo pipefail reaching the test step, 932 tests) - pluto's typecheck is INFERRED from pipeline progression, not directly observed, weaker evidence than the other two, not leveled up by sitting in the same sentence. PLUTO'S TWO COMMENT EDITS, accepted, no action needed: (1) removed a now-false ordering comment ("Runs BEFORE build because it is ~4s and build is not"), (2) added a tradeoff note that lint/typecheck do not catch build-only failures, now surfacing as a failed Vercel deploy instead of a failed gate. Not scope creep - a false comment asserting a behaviour the code no longer has is itself a defect (same failure family as OPS-226, where a comment warning about a coupling was read as the fix). VENUS HEADER FIX dispatched (line ~4, ~18-19 still claimed local build coverage / listed pnpm build as a running step - now false). CONSEQUENCE OF ELAZAR'S RULING, not a regression, not anyone's defect: typecheck does NOT catch RSC boundary violations, server-only-export misuse, or bad route config - the local build did. That error class has not stopped being caught, it MOVED from pre-push (blocking the push) to the Vercel build (after push, does not block the push). Ruling stands - a per-push cost paid on every push outranks a class caught later by a build that runs anyway. Recorded here so nobody rediscovers this as a regression and re-adds the build. pmmaster-evolutiva-cc is carrying this to Elazar as FYI, not reopening. PLUTO PUSH VERIFICATION PENDING: coder-pluto-cc pushed dc017c5..bc12fb2 (v2.23.95->v2.23.96) rather than riding the next normal push as instructed. Asked once to confirm deploy health via /api/health (version + deploymentId, not the retired /api/app-version) and state plainly whether it pushed solely for this or rode queued work.
-
PLUTO PUSH VERIFICATION, coder-pluto-cc self-report: (a) /api/health at 06:11:55Z confirms version 2.23.96, deploymentId dpl_Vn74q6Kxqvz8zjATaqxdKgPHywNY, dbOk true - matches the bc12fb2 bump, deploymentId pins one deployment not just a version string. (b) STANDALONE - pushed solely for OPS-221, no pending app code to ride on this session (working triage only, PLUTO-742/743/eq#112). Agent read 'ride the next push' as scheduling guidance and traded it for wanting the change exercised - acknowledges that was the wrong unilateral call, the exercise argument doesn't outweigh a deploy to a live clinical app for a hook-only edit, could have exercised without pushing. Deployed artifact is byte-identical app code to 2.23.95 plus version string, which is what makes the deploy unnecessary rather than what makes it fine. Rule recorded going forward: a hook/tooling-only change waits for app work to ride on; if none pending, it waits, does not manufacture a deploy.
-
REMAINDER SPUN OUT TO OPS-240 (deferred, child of this row). The 4 ayudarg lines are no longer this row scope, so OPS-221 may close on terra + venus + pluto once pluto push verification lands - it will not be a done that covers 3 of 7. That is the point of the split: a row reporting done with 4 live lines is the closure I said I would reject from anyone else, and holding the remainder in a PM head instead of a row is the same defect with better manners.
-
VENUS HEADER FIX done, coder-venus-cc self-report, comment-only, unpushed (rides next push with the code change). :4 rewritten to name TEST/TYPECHECK/LINT explicitly. :5-21 new block names OPS-221 + ruling + date, states the build-error-reaching-Vercel class MOVED from blocking-the-push to failing-the-Vercel-build (accepted consequence, not regression, and a failed Vercel build does not promote so nothing reaches users either way), lists what is no longer covered locally: RSC boundary violations, route-config/metadata export shape, Turbopack RSC graph errors generally. :34 step 5 marked LAST STEP. :35-37 old step-6 text replaced with a pointer to the coverage note. :576-580 VENUS-139 lint rationale re-stated and marked do-not-weaken: with no build on any lane, that lint is now the ONLY local coverage for its class, not a --quick gap-filler. CORRECTION TO MY OWN DISPATCH WORDING, from coder-venus-cc, tell pmmaster/Elazar: typecheck does NOT miss 'server-only-export misuse' as I wrote in the GO - "use server" non-async exports are still caught locally by the dedicated VENUS-139 hard lint (:573+), which never depended on build. Same for the Blob/Buffer class at step 4 - a TS error, typecheck still catches it. Writing those into the lost-coverage list would have understated coverage and invited someone to re-add the build to recover something not actually lost. The header states the corrected (narrower) list explicitly. EVIDENCE: bash -n clean, git diff -U0 filtered to non-comment lines returns only the original 3 removals - hook behaviour byte-identical to the already-exercised run (test 915 passed, typecheck clean, lint 5 warnings, exit 0, 50s). Diffstat +28/-11.
-
COMPLETE. Coverage per repo (not cleanliness): terra/.gitpush-pre.sh:854 - lint+typecheck exercised via forced probe, negative control TS2322 confirmed typecheck still blocks. venus/.gitpush-pre.sh:683-684 - lint+typecheck exercised live against 16-file dirty tree, 915 tests passed, header now states coverage honestly (build-error class moved from blocking-the-push to failing-the-Vercel-build, corrected narrow gap list: RSC boundary/route-config/Turbopack RSC graph only - server-export and Blob/Buffer classes remain typecheck/lint-caught, not lost). pluto/.gitpush-pre.sh:607 - lint 0 errors, typecheck INFERRED from set -euo pipefail reaching the test step (not directly observed, weaker evidence than terra/venus), test 932 passed; push was standalone (self-corrected, deploy verified healthy via /api/health deploymentId dpl_Vn74q6Kxqvz8zjATaqxdKgPHywNY, unnecessary not unsafe). mars and enamel: no action, both already had zero live build invocations (comments only). QUICK_MODE untouched throughout, no gitpush.sh edit. ayudarg's 4 remaining lines split to OPS-240 (deferred, child, 2 unstaffed repos).
-
completed
-
DONE on the staffed repos, with the remainder moved to OPS-240 (deferred) rather than swept into this closure. COVERAGE, stated per repo rather than as a verdict: - terra/.gitpush-pre.sh:854 - build invocation removed, replaced with an explanatory comment. Unpushed, rides the next push. lint and typecheck exercised via a FORCED probe, because the hook is scope-aware and would have early-exited on a doc-only diff - which is itself worth noting: the honest exercise required defeating the hook own optimisation. lint 3 pre-existing warnings / 0 errors, typecheck clean, and a NEGATIVE CONTROL confirmed typecheck still BLOCKS (TS2322). That negative control is the only reason this counts as exercised rather than observed. - venus/.gitpush-pre.sh:683-684 - echo + build both removed plus the trailing blank. Unpushed. Exercised live against a 16-file dirty tree: 915 tests passed / 4 skipped, typecheck clean, lint 5 warnings / 0 errors, exit 0. Header text also corrected in the same file (see below). - pluto/.gitpush-pre.sh:607 - removed, pnpm test and the fi untouched. PUSHED (dc017c5..bc12fb2, v2.23.95 -> v2.23.96) and VERIFIED in production: /api/health returns version 2.23.96, deploymentId dpl_Vn74q6Kxqvz8zjATaqxdKgPHywNY, dbOk true - deploymentId matched against bc12fb2, so this is a deployment match and not a version string that could belong to a different one. lint 23 warnings / 0 errors, 932 tests passed. TYPECHECK HERE IS INFERRED, NOT OBSERVED - inferred from set -euo pipefail having reached the test step. It is the weakest of the three evidences and is deliberately not levelled up by sitting in the same closure as the other two. - mars and enamel NOT TOUCHED and correctly so: their apparent hits were COMMENTS, and enamel:27 is literally a marker reading "NO pnpm build HERE, DELIBERATELY - do not add one back". mars build was removed 2026-08-09 under an Elazar do-not-reinstate ruling. Dispatching the original 9-file list would have sent two agents to strip absent code and put mars in violation of a standing ruling. ACCEPTED CONSEQUENCE OF THE RULING, recorded so nobody rediscovers it as a regression and re-adds the build: the build-error class has not stopped being caught, it MOVED from blocking the push to failing the Vercel build. Nothing reaches users either way, since a failed Vercel build does not promote. The venus hook header now says what actually runs and names this row plus the ruling. AND THE COVERAGE GAP IS NARROWER THAN I FIRST CARRIED IT, corrected by coder-venus-cc against my own FYI wording: "server-only export misuse" is NOT in the gap - "use server" non-async exports are caught locally by the dedicated VENUS-139 hard lint, which never depended on the build at all, and the Blob/Buffer class is a plain TS error that typecheck catches. The real gap is three items: RSC boundary violations, route-config / metadata export shape, and Turbopack RSC graph errors. I had overstated the cost of Elazar ruling; the correction went to him. PROCESS NOTE, because it is the reusable part: this row was filed with a MEASURED scope of 9 files that was wrong, from grep hit counts. pmmasterassistant-evolutiva-cc opened the files and it was 7, with 4 of those being the compound "pnpm lint && pnpm build" rather than a deletable line. Two dispatch targets and one edit shape, all wrong, all from a number that looked measured. Companion defect filed the same hour as OPS-239.