gitpush split: emit the pushed SHA to a durable reconcilable trace
coder-mars-cc, 2026-08-31, measured on Mars: six commits landed 08-25..27; five had already been reviewed and PASSED, but those verdicts existed only as hub messages and were never written to a work item. From the ledger a verdict issued-but-not-recorded is indistinguishable from one that never happened, so audit re-reviewed all six. Duplicated review work is the measured cost; the silent self-perpetuating record gap is the larger one. bwi exposes events per-workitem only (/workitems/{id}/events), no global search, so reconciling 'does a verdict exist for this SHA' means walking every item - expensive enough that nobody runs it, which is why the gap persisted. ASK: the push tool leaves a durable, reconcilable trace of the pushed SHA in a known location, turning that walk into a diff. NOT asked: enforce review, gate the push, or know what a verdict is - that is coder-mars-cc's lane and Elazar has not ruled on enforcement. NOTE FOR WHOEVER BUILDS IT: gitpush.sh already resolves both short and full SHA at :1428 and hands them to gp_send_review, which sends them over the HUB - i.e. the request side is exactly as ephemeral as the verdict side coder-mars-cc measured, so a hub message is not the fix. Scope, format and location are UNDECIDED and go to Elazar; do not build before he rules.
Activity
-
parent=#3117
-
DONE, and the row's own history on this is wrong in a way worth leaving on the record. WHAT SHIPPED. gitpush-core.sh v1.8 then v1.9 (10eb8de, cf2b841), gitpush.sh v5.4, gitpushnextjs.sh v1.2, gitpush-trace.test.sh v1.2 (42 checks, new). The pushed-SHA trace is now ONE function, gpc_push_trace, called from gpc_push and nowhere else, on all three of its success returns, behind GITPUSH_NO_TRACE. Format is the shipped 8-column header TSV at $GITPUSH_TRACE_DIR/pushed.tsv (default ~/.local/state/gitpush), unchanged apart from the new `version` column, because gitpushvercelstatus.sh:94 reads that path. CORRECTION TO MY OWN RECONCILIATION ON OPS-173. I reported on that row that no pushed-SHA trace existed anywhere in the tree. That was FALSE. I had searched two files - gitpush.sh and gitpush-core.sh - and wrote "anywhere". The trace shipped 2026-09-01 in 19adc46 as gpn_trace inside gitpushnextjs.sh, with a live reader and a green test. A surprising PASS line in gitpushnextjs.test.sh is what made me look. I was one commit away from shipping a SECOND, 7-column implementation of the thing gitpush-core.sh exists to prevent forking. OPS-173's reconciliation event should be read with that clause struck. THE PROPERTY THE TRACE ASSERTS is not "the push command exited 0". gpc_push's third success return is downstream of gitmerge.sh, which can return 0 having published nothing, so a row is written only for a commit proven to be an ancestor of refs/remotes/<remote>/<branch>. A trace failure is never fatal and says the push SUCCEEDED; bookkeeping may not change a push's verdict. THE CONSOLIDATION'S OWN DEFECT, FOUND BY LOOKING AT THE FILE RATHER THAN THE SUITE. Moving the trace into gpc_push gave it to every caller, including five of the seven sibling suites, which drive real pushes against throwaway /tmp remotes and had nothing to isolate before the move. Measured on the first full run after v1.8: 19 fixture rows against ONE real push in the shared pushed.tsv, and one of those rows carried `bin-venus-cc` - only the remote column told it from a genuine push. v1.9 fixes it twice: the suites export GITPUSH_TRACE_DIR, and a remote under the temp root is refused LOUDLY when the target is the shared default. The guard is bound to the shared FILE, not to the shape of the remote, so an isolated caller's /tmp remote is still recorded - gitpush-trace.test.sh [10b] asserts exactly that, and an `overguard` mutant that drops the scoping reddens 21 checks. The 19 rows were pruned after a backup; the file now holds its header and two real pushes. CONTROLS SEEN TO FAIL. Six mutants of gitpush-core.sh: nolanding (5 red, incl. the load-bearing [3d] "no row for a commit that never reached the remote"), nosentinel (3), notabscrub (1, forged 12 columns from 8), trimcalls (3, the wiring checks), noguard (2), overguard (21). SRC is overridable precisely so these can be run. MEASURED COVERAGE. All seven gitpush suites green after the change (12/15/7/7/6/29/42), and a full suite run adds ZERO rows to the shared trace, measured before and after rather than asserted. NOT exercised: any host but venus, and gitpushhtml.sh/gitpushreact.sh/gitdeploy.sh, which do not exist yet (OPS-180/182/178) and will inherit the trace from gpc_push when they do. STILL OPEN, AND IT IS THE ROW'S ACTUAL ASK, NOT A DETAIL. The trace is host-local: ~/.local/state/gitpush/pushed.tsv on each of venus, whey and lezama. This row asks for a "durable, reconcilable trace", i.e. one place to diff against git log. Three per-host files are not that. Moving it to /data-venus/gitpush/ would break the shipped default that gitpushvercelstatus.sh reads, and the location was already decided once by the poll that settled "appended TSV". That is a decision, not a defect - raising it, not taking it.
-
Consolidated into gitpush-core.sh v1.9; 42-check control forced red against six mutants; the host-local path question is raised, not taken.