All repo history touched by this workstream was rewritten to be attribution-free, per standing user policy. Verifying that rewrite surfaced a new and severe rtk gotcha: rtk-wrapped grep / git log pipelines returned fabricated zero-result output.

What was rewritten

RepoRefs rewritten
mando-climain, release, 4 old tags re-pointed
mandopoc/e2e-tests (head now 2af0c6c9)

The merged source branch was deleted after the rewrite. Any local clone predating this is stale on every listed ref and must re-fetch rather than merge.

Tags were re-pointed, not just branches

Four existing mando-cli tags now point at rewritten commits. A checkout of an old tag by SHA will resolve to an orphaned object. Fetch with --tags --force.

The rtk trap: fabricated zeros during verification

While verifying the rewrite, rtk-wrapped grep and git log pipelines returned zero matches for content that was demonstrably present. The zeros were not a filtered summary — they were wrong.

Only raw rtk proxy git output written to a file is trustworthy

To verify anything about git history, run rtk proxy git ..., redirect to a file, and read the file. Do not trust:

  • rtk-wrapped grep over repo content
  • rtk-wrapped git log / pipelines through grep / wc
  • a zero/empty result from any of the above as evidence of absence

This extends the existing rtk hazard family already recorded in Agent Context:

  1. The test gate — the hook turns --test-threads=1 into a test-name filter, giving exit 0 with 0 passed, N filtered out (two false-green gates before detection, 2026-07-13).
  2. Piped exit codescargo test | grep | tail; echo $? reports tail’s status.
  3. Fabricated zeros (new, 2026-08-05) — grep/log pipelines report no matches where matches exist.

Generalizable rule: an rtk-mediated negative result is never evidence. Positive results can be spot-checked; absences must be re-proven with rtk proxy writing to a file.