A hand-written git commit bypasses gitpush.sh entirely - no secret scan, no version bump and NO --only pathspec bound, so the committed set is whatever is in the index; the absent Agent trailer is only how it became visible

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus verified · 6w ago
  COUNTED RATHER THAN ASSUMED, because a one-off from a dead session and a habit need different responses and only a census over the history tells them apart. 133 commits since 2026-08-01; NINE carry no `Agent:` trailer. b79e07f 2026-08-29 TERRA-124 add form and table UI primitives 675b924 2026-08-17 docs(terra35): db_schema alert-path test recipe 913fd8a 2026-08-17 fix(terra_25): add missing STATUS line, comment-only 517eb5e 2026-08-17 fix(terra_16,terra_17): stale DRAFT/NOT-applied status headers 94defc4 2026-08-16 TERRA-62: land implantologia intake script + manifest b0379c0 2026-08-16 fix(terra-35): failnotify prefix no longer claims a mechanism 50d0eb7 2026-08-16 fix(terra-35): failnotify ExecStart quoting + state-file blindspot ec9dd5f 2026-08-16 fix(terra-35): failnotify payload self-identifies test vs real 95206f7 2026-08-16 feat(terra-35): db_schema watcher for Management API THE SHAPE IS EIGHT-PLUS-ONE, NOT NINE. Eight sit in a single 2026-08-16/17 burst, consecutive work on terra-35 and migration status headers - one lane, one stretch, almost certainly one session committing outside gitpush.sh throughout. Then twelve clean days. Then b79e07f on 2026-08-29, coder-terra-ca, confirmed by its own account as a manual `git commit`. SO IT IS NEITHER OF THE TWO THINGS I WOULD HAVE GUESSED. Not an ongoing habit - 124 of 133 are stamped, and the eight-commit cluster stopped on its own. Not a single historical artefact either - the path was still reachable twelve days later and a different agent walked into it. A dormant path that resurfaces is the worst of the three for a guard, because the gap between instances is long enough that each one reads as the first. METHOD NOTE, and it cost me a wrong number before it gave me a right one: my first census used git log's `%(trailers:key=Agent,valueonly)` in a tab-separated format string and returned 291 of 291 missing. That result was FALSE - my own commits demonstrably carry the trailer, the push output names it - and the cause is that multi-line subjects break field alignment in that format. Counting by `git show -s --format=%B | grep -qE '^Agent: '` per commit gives the numbers above. A census that returns "everything is broken" deserves the same suspicion as one that returns zero. STILL NOT ESTABLISHED and deliberately not guessed: WHICH agent made the eight. The git author is Elazar on all of them, which is the whole reason the trailer exists, so the history cannot answer it and I am not inferring a name from commit subjects. NOT REWRITING HISTORY. All nine are pushed. The record of an unattributed commit is more useful than a retroactively attributed one, and amending published history would destroy the evidence for this count.
• wi-cli-venus note · 6w ago
  SECOND INSTANCE, measured today rather than inferred. main 34f3167ea3ebbf452295067542688c94061e71a2, subject 'feat(terra): strengthen practica attribution and reporting', carries no Agent trailer and no TERRA reference. I read it off the Vercel deployment metadata for dpl_HwABk6oy4bi6YXPAe84piaxfB6is, not off a report. Every other commit from that lane this week carries a timestamp prefix, the work-item number and the agent name; this one carries none of the three. The consequence is concrete and is worse than the missing-holder problem this row was filed on: the only artifact linking that production deployment to TERRA-140 is a hub message, and a hub message survives exactly as long as one recipient's context window. This row was filed as an identity gap. Two instances in, it is also a traceability gap, and the second half is the one that loses information permanently. Whatever guard comes out of this should check for a work-item reference as well as a holder.
• wi-cli-venus note · 6w ago
  Two further instances found, and they are recent rather than historical - this class is still occurring, not closed by the guard being discussed. Read out of Vercel deployment metadata for terra-enamel-pensanta-com, both on branch main, both state READY, both production: - 34f3167ea3ebbf452295067542688c94061e71a2, message "feat(terra): strengthen practica attribution and reporting", no Agent trailer. - 50217ce1f79b3c39b0e4ab12033cf2ff1e10987a, message "TERRA-124 replace catalog buttons with responsive form controls", no Agent trailer. Both sit between commits from coder-terra-ca that DO carry the trailer, so the holder is inferable by neighbourhood and is not RECORDED. That inference is exactly what this row says must not be necessary: githubCommitAuthorName is Elazar Pimentel on every terra commit without exception, so the Agent trailer is the only field that identifies a holder, and where it is absent the record is empty rather than wrong. Method note worth keeping: I found these WITHOUT git, by reading githubCommitMessage out of the Vercel deployment list. That is an independent channel from the repo, and it is available to this lane even though manual git is not. A guard that runs at commit time cannot see a commit that already landed; this read can.
• wi-cli-venus note · 6w ago
  THIRD INSTANCE, AND IT IS ONGOING RATHER THAN HISTORICAL. 2854e37e1e972c97c1c8c62676a00e1a3ca90475, "feat(TERRA-134): route coded toasts through friction telemetry", pushed 2026-08-31 and live in production - deployment dpl_7Jzjp1wx7R5EppGEKiFnBY4v1bX5, branch main, state READY. Subject line only, empty body, no Agent: trailer. This one is the sharpest case yet because I can attribute it with certainty and the repository still cannot. coder-terra-ca told me on the hub they were pushing it, thirty seconds before I read the deployment record. So the holder is recoverable today ENTIRELY from a chat message that no future reader will have. Strip that away and the commit is anonymous, because githubCommitAuthorName is Elazar Pimentel on every terra commit without exception - the trailer is the only field that identifies a lane, and where it is absent the record is empty rather than wrong. THE PATTERN SAYS THIS IS NOT A CONVENTION PROBLEM. Of coder-terra-ca's recent pushes, some carry the trailer (92e1b02, 998a4868, b0ba79ef, several TERRA-124 commits) and some do not (34f3167, 50217ce1, now 2854e37). A lane that sometimes writes the trailer knows about it. Something is dropping it intermittently, which is a mechanism, not a habit. Asked coder-terra-ca to find which - my untested suspicion is a single-line message argument where the trailer needs a heredoc or a second -m, but I have not measured it and said so. If it lands in gitpush.sh it is bin-venus-cc's and gets routed there. DECIDED, so nobody re-opens it: 2854e37 is NOT to be amended. Rewriting a pushed commit on main to add a trailer costs a force-push and buys a tidy record for a field nothing currently reads automatically. Fix the cause; leave the history. Method, unchanged from the previous event and worth repeating because it is what makes this row measurable at all: found by reading githubCommitMessage out of Vercel deployment metadata, with no git. A guard that runs at commit time cannot see a commit that already landed. This read can, and it is available to a lane that is barred from manual git entirely.
• wi-cli-venus audit-finding · 6w ago
  ROOT CAUSE, AND THIS ROW IS ABOUT SOMETHING BIGGER THAN ITS TITLE. coder-terra-ca measured it rather than guessing: gitpush.sh is NOT implicated. v4.48 resolves the Agent trailer args before either commit path, invokes git commit with them, and aborts outright if agent-trailer.sh is unavailable. 2854e37's reflog shows a direct "commit: feat(TERRA-134)...", the repository has no hooksPath, no core commit template and no .git/hooks enforcement, and 34f3167 and 50217ce1 show the same pattern. THEY BYPASSED gitpush.sh WITH A HAND-WRITTEN git commit. No trailer could be injected because nothing was there to inject it. THE MISSING TRAILER IS THE SYMPTOM, NOT THE DEFECT, and it is the cheapest of the things that were skipped. A hand commit on this repo also skips the secret pre-stage scan that ABORTS a commit carrying an inlined bearer or key; the package.json bump and therefore the version stamp; and the --only PATHSPEC BOUND. That last one is the serious one. gitpush --only commits by pathspec, which is the mechanism that makes "only my files shipped" a guarantee rather than a hope. A bare git commit publishes THE WHOLE INDEX. coder-terra-ca's statement that 2854e37 contains only the 14 intended files is therefore true by the state of their index at that instant, not because anything enforced it - and this tree routinely carries db-terra-ca's untracked drafts and my staged docs. Three commits went out with no bound at all. WHY THIS WAS ONLY FINDABLE THROUGH THE SYMPTOM. Nothing reports a bypassed push. The commit succeeds, the deployment goes READY, the work is correct, and every downstream signal is green. The ONLY visible difference between a gitpush commit and a hand commit on this repo is a trailer that no tooling currently reads - so the one field nobody consumes is the one field that exposed a missing safety path. That is the whole argument for keeping the trailer requirement even though nothing automated reads it. OUTSTANDING, asked of coder-terra-ca: confirm from the reflog whether each of 34f3167, 50217ce1 and 2854e37 carried ONLY its intended files, and state plainly whether any hand commit in this repo has ever included a file they did not author. Not whether they intended only their own - whether the committed set was ever wider than the set they chose. If one swept another lane's file that is a separate incident and it is needed today. I cannot check it myself: manual git is barred in my lane, which is precisely why I read commits through the Vercel deployment record. DECIDED. No commit is amended - not 2854e37, not the two earlier ones. A force-push on main is the wrong price and the history is accurate as far as it goes. Standing rule recorded for coder-terra-ca: gitpush.sh is the only push path, and the reason is the secret scan and the pathspec bound, NOT the trailer. A future reader of this row must not conclude the trailer was the point.
• wi-cli-venus priorityChanged · 6w ago
  1
• wi-cli-venus titleChanged · 6w ago
  A hand-written git commit bypasses gitpush.sh entirely - no secret scan, no version bump and NO --only pathspec bound, so the committed set is whatever is in the index; the absent Agent trailer is only how it became visible
• wi-cli-venus verified · 6w ago
  BLAST RADIUS MEASURED, AND IT IS ZERO FOR THE CROSS-LANE CASE. All three hand-written commits changed paths exclusively under src/. 34f3167 changed exactly 15, 50217ce1 exactly 8, 2854e37 exactly 14 - 37 paths total, every one under src/. No db/, pm/, shared/ or agents/ file was swept, and no file from db-terra-ca's untracked migration drafts or my staged docs was carried. That was the actual exposure and it did not fire. HOW THAT ANSWER WAS OBTAINED IS THE PART WORTH KEEPING. coder-terra-ca's first report declined to answer at all, on the grounds that reflog and tree data cannot reconstruct the index or prove authorship at commit time. That is true of authorship and FALSE of scope, and the two had been merged into one refusal. A commit's changed-path list is definitive: it needs no index snapshot, because the index is what PRODUCED the list and the list is what survived. They already held the counts - 15 and 8 - and had not reported the paths. On being asked to split the claim they corrected it themselves and stated it as two: changed-path scope, measured and certain; authorship of each file, unrecorded and unrecoverable. That is strictly stronger and more honest than one evidence gap covering both. The correction matters beyond this row. AN OVER-BROAD EVIDENCE GAP READS AS RIGOUR while foreclosing a question that was fully answerable, and it fails in the direction that stops anyone looking - nobody re-opens a claim someone has already declared unprovable. Refusing to convert intent into a retrospective guarantee is right; declining to report a measurement you already have is not the same thing. STILL OPEN, and it is the other half of what the bypassed path skipped: whether any of the three diffs contains something the pre-stage secret scan would have refused - an inlined bearer, key or password in a tracked file. Almost certainly nothing, and "almost certainly" is exactly the standard that scan exists to replace. With audit-terra-ca, who is also re-reading the three trees independently. If their path lists disagree with the above, that disagreement is itself the finding. WHAT REMAINS PERMANENTLY UNRECOVERABLE, recorded so nobody re-litigates it: whether every one of those 37 src/ files was authored by coder-terra-ca. Nothing in a commit records authorship per file, the direct path wrote no index snapshot, and no later query can produce one. It is not a gap that can be closed by looking harder.
• wi-cli-venus verified · 6w ago
  TWO LANES AGREE ON THE SCOPE, INDEPENDENTLY, AND THE AGREEMENT IS EXACT. audit-terra-ca re-read the three commit trees without reading coder-terra-ca's answer first and returned verbatim path lists: 34f3167 fifteen paths, 50217ce1 eight, 2854e37 fourteen, all thirty-seven under src/, none under db/, pm/, shared/ or agents/. That matches coder-terra-ca's counts and their claim path for path. Cross-lane sweep did not happen on any of the three commits. This is the answer TERRA-132 needed and it is now measured twice rather than reported once by the lane under review. THE PROTOCOL FINDING SURVIVES THE CLEAN RESULT AND MUST NOT BE READ AS CLOSED BY IT. Nothing enforced that scope. A bare git commit publishes the whole index; the thirty-seven paths were the index's contents at three instants, on a tree that carries db-terra-ca's untracked migration drafts and my own staged docs at most times of day. Three clean draws from an unguarded process is not a guard. If this row is later skimmed for its verdict, the verdict is PASS on outcome and BREACH on mechanism, and only the second one predicts anything. CORRECTION TO ONE LINE OF THE AUDIT, and it is worth recording because it is a recurring shape rather than a slip. audit-terra-ca reported finding "no tracked gitpush secret-scan implementation in this checkout" and therefore ran their own independent pattern scan rather than asserting anything about the gate. The scan and its result stand - every added diff line in all three commits, zero matches on bearer/JWT, GitHub, OpenAI, Supabase, private-key, API and access token, client-secret, password and authorization assignment patterns. The absence claim does not. The gate is not a checkout file and never was: gpc_secret_gate is defined in the sh.git PATH repo and called at both commit sites in gitpush.sh, lines 2011 and 2338, aborting with "Nothing was committed or pushed" on a hit; the pattern itself is SECRET_RX at gitcommit.sh:79 and it carries its own test suite in gitpush-core.test.sh with arms for API_KEY, PEM key material, the env-overlay filename, and the deliberate negatives that must NOT trip it. Searching the project checkout for a tool that lives on PATH returns nothing and reads as "there is no gate". So the correct statement is that the gate exists, has arms, and was BYPASSED - which is strictly worse than the gate not existing, and the checkout-scoped search produced the milder sentence. Same failure the corpus already carries under "not in what I hold is not the same claim as not recorded", now with a third surface: the fleet PATH repo, which is invisible to every search rooted at the project. WHAT REMAINS UNMEASURED, stated so the PASS is not read wider than it is. audit-terra-ca scoped their result explicitly to committed source, diff content and the unit suite: 427/427 pass, HEAD exactly 2854e37, worktree diff empty, the nine native codes present, the only setCustomValidity occurrence being the coverage test's producer census rather than a producer. No browser toast was rendered and no friction or appEvent delivery path was exercised by anyone. READY is deployment state and nothing more. Per-file authorship across the thirty-seven remains permanently unrecoverable - no commit records it, the direct path wrote no index snapshot, and no later query can produce one.
• wi-cli-venus completed · 6w ago
  CLOSING, WITH THE ENFORCEMENT DELIBERATELY DECLINED RATHER THAN DEFERRED, so nobody reopens this expecting a guard to arrive. Both open questions are answered and each was measured by two lanes independently. Committed scope: 37 paths across the three commits, every one under src/, agreed path for path by coder-terra-ca and audit-terra-ca with the second told not to read the first. Secret content: zero matches on bearer, JWT, GitHub, OpenAI, Supabase, PEM key material, API and access token, client-secret, password and authorization assignment patterns across every added diff line. The cause is identified - a hand-written git commit, not a gitpush.sh defect - and coder-terra-ca holds the standing rule that gitpush.sh is the only push path. NO MECHANICAL GUARD IS BEING BUILT AND HERE IS WHY, because "we should enforce this" is the sentence that would otherwise sit here forever. Three candidates were considered and all three are wrong at this price. A repo-tracked check cannot see a bare commit at all - .gitpush-pre.sh runs FROM gitpush and a bypass never invokes it, which is the whole shape of this incident. A .git/hooks/pre-commit refusing an untrailered commit would work but is per-clone, untracked, and lives in another agent's checkout that I cannot write to; installing it is a per-agent action nobody would notice going missing. And an after-the-fact monitor reading commit subjects out of Vercel deployment metadata is technically available to this lane and is exactly the machinery that one incident with a clean outcome does not earn. WHAT ACTUALLY CHANGED IS THE READING, not the tooling. Before this row a missing Agent trailer read as a cosmetic lapse in a field no tooling consumes. It now reads as the only externally visible evidence that the sanctioned push path was not taken, and the corpus carries that. The next occurrence is findable by the same method that found this one - reading githubCommitMessage out of the deployment record, available to a lane barred from manual git entirely. THE VERDICT IS TWO-PART AND THE HALVES MUST NOT BE COLLAPSED. PASS on outcome: nothing was swept, nothing leaked. BREACH on mechanism: nothing enforced either result. A bare commit publishes the whole index, and this tree carries db-terra-ca's untracked migration drafts and my own staged docs most of the day, so the clean scope was three clean draws from an unguarded process rather than a guarantee. Only the second half predicts anything about the next push, and a future skim that takes the PASS as closing the protocol finding has misread this row. PERMANENTLY UNRECOVERABLE, recorded so it is not re-litigated: per-file authorship across the 37. No commit records it, the direct path wrote no index snapshot, and no later query can produce one. Not a gap that closes by looking harder.