operational-rigor §2: the two-dot ADDITION side over-reports unlanded work (stacked on #220)

[firaen22]

Stacked on #220 — base is that branch, not main. See "Why this is stacked" below; merging it against main would silently lose it.

The claim

what deleting the branch would lose is its unlanded work — the two-dot ADDITION side, or git log <base>..<branch>

Those two are offered as interchangeable. They are not, and the addition side is wrong in exactly the way this same bullet already warns about for the deletion side.

Fixture

merge-base has config.txt = v1. Branch adds featwork.txt and never touches config.txt. Base then moves on: config.txt = v2.

$ git diff main feat        # two-dot, addition side only
+v1
+work

$ git log --oneline main..feat
3c3974b branch's real unlanded work

$ git diff --stat main...feat
 featwork.txt | 1 +

+work is genuine unlanded work. +v1 is not — it is the branch's older copy of config.txt, and deleting the branch loses nothing there. The two-dot addition side over-reports, by the same mechanism that makes the deletion side inconclusive: the base moved on. git log <base>..<branch> and the three-dot diff both report only the real work.

Fix

Route the delete read to git log <base>..<branch> or git diff <base>...<branch>, and say plainly that the addition side is inconclusive for the same reason the deletion side is. Recorded as Provenance result (11).

Why this is stacked on #220

#220 rewrites this paragraph. I first branched this fix from main and tested the interaction:

$ git merge fix/two-dot-addition-side     # into #220's branch
merge rc=0
$ grep "would lose is its unlanded" -A1 skills/operational-rigor/SKILL.md
  the branch would lose is its unlanded work — the two-dot ADDITION
  side, or `git log <base>..<branch>` ...

A clean merge, exit 0, no conflict — and the fix is gone. #220 replaces the whole hunk, so git takes its side wholesale and discards the edit made against the old text. Basing this on main would have produced a merged result that silently kept the defect.

So it is stacked. Merge #220 first, then this. If you would rather have it folded into #220 as a fifth commit, say so and I will move it.

Provenance / attribution

Raised by a gpt-5.6-luna reviewer during #220's round-2 review, where I classified it pre-existing-tracked and deferred it out of scope rather than widening that change. This is the spun-off fix. The reviewer identified the imprecision; the fixture, the mechanism, and the wording are mine.

Checks

python3 .github/checks.py — all checks passed. No added line exceeds §2's 74-column norm.

Round 5 — dual review of this PR

Both families reviewed it; both returned FIX and converged on the Provenance contradiction. Every finding reproduced before it was applied.

• git log and the three-dot diff are complementary, not interchangeable. My first wording offered them as alternatives ("read that off X or Y"). Fixture: a commit plus its revert leaves git log main..feat listing two commits while git diff main...feat is empty — deleting that branch loses no content at all. The text now separates them: log enumerates unique COMMITS, three-dot shows net CONTENT since the merge-base.
• The dots matter on git log too. Fixture: git log main...feat (three dots, symmetric difference) lists the base-side commit as well — recreating the exact over-report this PR exists to stop. The rule now names <base>..<branch> (or ^<base> <branch>) and warns against the three-dot log form. Recorded as result (12).
• Provenance still taught the read this PR withdraws. Its incident paragraph said, in present tense, that the amendment "still reads delete risk off the two-dot ADDITION side" — written during operational-rigor §2: three git claims falsified by fixture #220 and left un-synced here, so a session obeying Provenance as current doctrine got sent back to the withdrawn read. Rewritten to match the rule.
• Result (11) conflated commits with content, and sat under a list dated 2026-08-28 though it was run on the 29th. Split into commits-vs-content, and dated to the day it actually ran.

Coverage note

One reviewer flagged that my own packet file was truncated mid-result-(7), so Provenance results (8)–(10) were not in front of either reviewer. Confirmed — my extraction window cut them. Those three results are unreviewed, not cleared. They are fixture-backed (round 4) but no second lens has seen them.

[F-e-u-e-r]

Landed via owner-curated replacement — closing without merge (this repo's consolidation convention).

Your six-commit head (d04e814) is the primary semantic source of #227 (merge commit 7308a95). Before landing, the maintainer's gate independently re-ran every mechanics claim first-hand on throwaway fixtures (git 2.50.1): 14/14 CONFIRMED, 0 REFUTED, 0 VERSION-SENSITIVE — including your stacked additions (the two-dot ADDITION side over-reports once the base moves; git log <base>..<branch> and git diff <base>...<branch> are complementary, never substitutes, with the commit+revert divergence as the discriminating control; the three-dot log symmetric-difference trap).

Landed = your current semantics + exactly two declared corrections, machine-verified against your frozen diff:

1. MOD-C2c: your provenance's "after prune … both failed" — first-hand execution showed the bare worktree repair invocation returns success (exit 0) while leaving the pointer unrecovered: a silent no-op, not a process-level failure. The landed text states the recovery path is gone even though the command need not fail loudly, and that exit status alone cannot prove a repair succeeded.
2. MOD-DATE: your rule-text marker dated the addition-side over-report to the 08-28 fixtures while your provenance placed results (11)–(12) under 08-29 (the second commit hadn't re-synced the date clause) — both dual-blind reviewers independently converged on this; dates now split by result everywhere.

Your review-history honesty (the packet-truncation note, the prose-review-ran-nothing record) is preserved in the landed provenance — it is why this family required a first-hand execution gate rather than a prose vote, and the landed text is stronger for it. The incident shapes and the squash/empty-two-dot clauses remain unprobed on the #115 queue, deliberately: mechanical truth verified is not guidance effectiveness verified.

Thank you — refuting shipped doctrine with runnable fixtures, then refuting your own first revision's addition-side claim, is the highest-value contribution pattern this repo has seen.