From 951ca3fe8e7c173005fadd39b56ca5b9bd8d5538 Mon Sep 17 00:00:00 2001 From: firaen22 Date: Fri, 28 Aug 2026 23:06:09 +0800 Subject: [PATCH 1/6] =?UTF-8?q?operational-rigor=20=C2=A72:=20correct=20th?= =?UTF-8?q?ree=20git=20claims=20falsified=20by=20fixture?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Probed the two git bullets against throwaway repos (git 2.50.1) after a two-family prose review returned findings but ran nothing. - `git worktree prune` DOES drop the admin entry when the directory is present and only the `.git` pointer file is gone, and it closes the `git worktree repair` recovery. The old parenthetical said the opposite. - `git diff $(git merge-base A B) B` is not a merge preview: it is the three-dot form the same rule rejects, it collapses to a working-tree diff on unrelated histories, and it misses a rename-induced conflict. `git merge-tree --write-tree` is the preview. - `format-patch` + `am` does not materialize the two-dot deletions. Also: qualify "survives" for renames, and make `--show-toplevel` a comparison rather than a read. Markers narrowed to unprobed-shape. Co-Authored-By: Claude Opus 5 --- skills/operational-rigor/SKILL.md | 76 +++++++++++++++++++++++-------- 1 file changed, 57 insertions(+), 19 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index 63cd099..8942fc7 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -281,21 +281,35 @@ When rigor conflicts with finishing sooner, rigor wins. be READ — but never as a merge preview: a three-way merge applies the branch's changes from the MERGE-BASE, so base-side work the branch never touched survives the merge even though the two-dot shows it as - deletions (those deletions materialize only under `reset --hard`, - re-applying the branch as a patch, or otherwise overwriting the base - with the branch tip — which is why non-empty never justifies - re-applying). Match the read to the action: what a merge would - actually change is the branch's own delta from the merge-base - (`git diff $(git merge-base ) `); what - deleting the branch would lose is its unlanded work — the two-dot - ADDITION side, or `git log ..` (`unprobed` — - contributor incident as shape; see Provenance). + deletions. Survives is not untouched — a branch-side rename of an + enclosing directory still relocates such a file or conflicts on it. + Those deletions materialize when the base is OVERWRITTEN by the + branch tip (`reset --hard`, a force-push, a tip-over-base copy) — + which is why non-empty never justifies re-applying — but NOT under + `format-patch` + `am`, which replays the branch's own commits and + leaves base-only files in place. Match the read to the action: a real + merge preview is `git merge-tree --write-tree `, which + reports the conflicts and the resulting tree; `git diff $(git + merge-base ) ` is the branch's CONTRIBUTION, + not the merge result — note it is the very same computation as the + three-dot form rejected above, and on unrelated histories + `git merge-base` prints nothing, silently degrading the command to a + working-tree diff. What deleting the branch would lose is its + unlanded work — the two-dot ADDITION side, or + `git log ..` (git mechanics above verified against + fixtures 2026-08-28; the incident shape stays `unprobed` — + contributor incident; see Provenance). - **A torn-down worktree can make git act on the ENCLOSING repo instead - of failing** (`unprobed` — contributor incident as shape; see - Provenance). The usual teardown fails LOUDLY: a removed linked + of failing** (prune/repair/discovery mechanics verified against + fixtures 2026-08-28; the incident shape stays `unprobed` — + contributor incident; see Provenance). The usual teardown fails LOUDLY: a removed linked worktree is a dead cwd, sibling paths stop resolving, and commands - there die with "not a git repository" (`git worktree prune` itself - only drops admin entries whose directory is already missing). The + there die with "not a git repository". `git worktree prune` does not + create the silent case below, but it does CLOSE the exit from it: it + drops the admin entry whenever the worktree's `.git` pointer file is + missing — its directory still fully present or not ("gitdir file + points to non-existent location") — and `git worktree repair ` + can rewrite that pointer only until prune has run. The silent case is narrower and worse: the worktree's `.git` pointer file is gone while its directory path still resolves INSIDE the main checkout's tree — git resolves its repository by walking up from cwd, @@ -308,9 +322,12 @@ When rigor conflicts with finishing sooner, rigor wins. notice. So the trigger is positional, not observational: from any long-lived session working in a linked worktree that cleanup could have touched, before the first commit, push, or PR after a merge or - cleanup event, re-verify identity. `git rev-parse --show-toplevel` is - the decisive check — a rebound checkout can be sitting on the very - branch name you expect, so `--abbrev-ref HEAD` alone can false-pass. + cleanup event, re-verify identity. Decide it on `git rev-parse + --show-toplevel` COMPARED against the worktree path you expect: it + does not error in this failure, it succeeds and prints the enclosing + checkout, so reading it without comparing proves nothing. And a + rebound checkout can be sitting on the very branch name you expect, + so `--abbrev-ref HEAD` alone can false-pass. ❌ a create-PR command issued from a session's own already-torn-down worktree directory would have acted on the main checkout — wrong tree, wrong branch — under this session's name; the staged-diff read @@ -1426,9 +1443,30 @@ late merge would have silently regressed them" — was REFUTED on base-side work the branch never touched; the two-dot deletion side materializes only under reset/re-apply/overwrite), which is why the amendment now reads the two-dot as a re-apply hazard and routes merge -and delete decisions to the merge-base delta and the addition side -respectively. Both bullets ship `unprobed` per the covenant; their -probes join the standing #115 queue. +and delete decisions away from it. + +Both bullets' GIT MECHANICS were probed on 2026-08-28 against throwaway +fixtures (git 2.50.1), after a two-family prose review of the same text +returned findings but ran nothing. Three claims failed and are corrected +above. (1) `git worktree prune` does NOT only drop admin entries whose +directory is already missing: with the directory fully populated and +only the `.git` pointer file deleted, `git worktree prune -v` printed +"Removing worktrees/: gitdir file points to non-existent +location" and removed the entry — so prune fires on precisely the silent +state this bullet warns about, and it closes the `git worktree repair` +recovery that works until it runs. (2) `git diff $(git merge-base +) ` is not a merge preview: it is byte-identical to the +three-dot form the same rule rejects, it collapses to a working-tree +diff when the histories are unrelated (`git merge-base` exits 1 printing +nothing), and on a branch that renamed an enclosing directory the merge +CONFLICTED and relocated a base-only file — neither of which that diff +shows. `git merge-tree --write-tree` predicted both. (3) `format-patch` ++ `am` does not materialize the two-dot deletions: replaying the +branch's commits onto the base left the base-only file in place. Also +tightened: `--show-toplevel` succeeds and prints the ENCLOSING checkout +in this failure, so it is decisive only when COMPARED against the path +expected. The incident SHAPE of both bullets remains contributor-reported +and ships `unprobed`; those probes stay on the standing #115 queue. Stable behavioral rules; the environment-specific facts to re-verify now travel with the rules that cite them — the external-systems set in From 33198ea796f7efdd72916686bf4c15c3e5f2788b Mon Sep 17 00:00:00 2001 From: firaen22 Date: Fri, 28 Aug 2026 23:11:08 +0800 Subject: [PATCH 2/6] address codex review: force-push, merge-tree contract, locked worktrees Reproduced all three against fixtures before applying: - a force-push updates a ref and leaves the pushing tree untouched, so it is not in the materializing set - `merge-tree --write-tree` writes and prints a tree even on conflict and exits 1, so read its output rather than gating on status (codex's proposed "reports conflicts and fails" would itself be false) - prune spares LOCKED worktrees; `repair` works off the admin entry, which is why prune ends it Provenance trimmed to fixture results, per the same review. Co-Authored-By: Claude Opus 5 --- skills/operational-rigor/SKILL.md | 61 ++++++++++++++++--------------- 1 file changed, 32 insertions(+), 29 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index 8942fc7..05d6775 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -283,14 +283,17 @@ When rigor conflicts with finishing sooner, rigor wins. never touched survives the merge even though the two-dot shows it as deletions. Survives is not untouched — a branch-side rename of an enclosing directory still relocates such a file or conflicts on it. - Those deletions materialize when the base is OVERWRITTEN by the - branch tip (`reset --hard`, a force-push, a tip-over-base copy) — - which is why non-empty never justifies re-applying — but NOT under + Those deletions materialize when the base CHECKOUT is overwritten by + the branch tip (`reset --hard`, a tip-over-base copy) — which is why + non-empty never justifies re-applying — but NOT under `format-patch` + `am`, which replays the branch's own commits and leaves base-only files in place. Match the read to the action: a real - merge preview is `git merge-tree --write-tree `, which - reports the conflicts and the resulting tree; `git diff $(git - merge-base ) ` is the branch's CONTRIBUTION, + merge preview is `git merge-tree --write-tree `: it + writes and prints the resulting tree either way, adding the conflicted + paths and a conflict message and exiting non-zero when the merge does + not apply cleanly — so read its output, not its status. `git diff + $(git merge-base ) ` is the branch's + CONTRIBUTION, not the merge result — note it is the very same computation as the three-dot form rejected above, and on unrelated histories `git merge-base` prints nothing, silently degrading the command to a @@ -306,10 +309,12 @@ When rigor conflicts with finishing sooner, rigor wins. worktree is a dead cwd, sibling paths stop resolving, and commands there die with "not a git repository". `git worktree prune` does not create the silent case below, but it does CLOSE the exit from it: it - drops the admin entry whenever the worktree's `.git` pointer file is - missing — its directory still fully present or not ("gitdir file - points to non-existent location") — and `git worktree repair ` - can rewrite that pointer only until prune has run. The + drops the admin entry of any UNLOCKED worktree whose `.git` pointer + file is missing — its directory still fully present or not ("gitdir + file points to non-existent location"); `git worktree lock` is what + holds an entry through a prune. `git worktree repair ` rewrites + the pointer from that admin entry, so it works only until prune + removes it. The silent case is narrower and worse: the worktree's `.git` pointer file is gone while its directory path still resolves INSIDE the main checkout's tree — git resolves its repository by walking up from cwd, @@ -1447,25 +1452,23 @@ and delete decisions away from it. Both bullets' GIT MECHANICS were probed on 2026-08-28 against throwaway fixtures (git 2.50.1), after a two-family prose review of the same text -returned findings but ran nothing. Three claims failed and are corrected -above. (1) `git worktree prune` does NOT only drop admin entries whose -directory is already missing: with the directory fully populated and -only the `.git` pointer file deleted, `git worktree prune -v` printed -"Removing worktrees/: gitdir file points to non-existent -location" and removed the entry — so prune fires on precisely the silent -state this bullet warns about, and it closes the `git worktree repair` -recovery that works until it runs. (2) `git diff $(git merge-base -) ` is not a merge preview: it is byte-identical to the -three-dot form the same rule rejects, it collapses to a working-tree -diff when the histories are unrelated (`git merge-base` exits 1 printing -nothing), and on a branch that renamed an enclosing directory the merge -CONFLICTED and relocated a base-only file — neither of which that diff -shows. `git merge-tree --write-tree` predicted both. (3) `format-patch` -+ `am` does not materialize the two-dot deletions: replaying the -branch's commits onto the base left the base-only file in place. Also -tightened: `--show-toplevel` succeeds and prints the ENCLOSING checkout -in this failure, so it is decisive only when COMPARED against the path -expected. The incident SHAPE of both bullets remains contributor-reported +returned findings but ran nothing. Results, each corrected above: +(1) `git worktree prune -v` removed the admin entry of an UNLOCKED +worktree whose directory was fully populated and whose `.git` pointer +file alone was deleted ("gitdir file points to non-existent location"); +a locked worktree in the same state survived. The old text said prune +only drops entries whose directory is already missing. (2) `git diff +$(git merge-base A B) B` was byte-identical (`cmp`) to `git diff A...B`; +on unrelated histories `git merge-base` exited 1 printing nothing; and on +a branch that renamed an enclosing directory the merge conflicted and +relocated a base-only file, which that diff did not show and +`git merge-tree --write-tree` did (tree written and printed, conflicted +path listed, exit 1). (3) `format-patch $(git merge-base A B)..B` + `am` +onto the base left the base-only file in place. (4) A force-push updated +the ref and left the pushing tree untouched, so it is not a materializing +action. (5) `git rev-parse --show-toplevel` exited 0 printing the +enclosing checkout in the rebind case. +The incident SHAPE of both bullets remains contributor-reported and ships `unprobed`; those probes stay on the standing #115 queue. Stable behavioral rules; the environment-specific facts to re-verify now travel From 3170b6576622e5d5bd4631c31ebf0008fa466e30 Mon Sep 17 00:00:00 2001 From: firaen22 Date: Fri, 28 Aug 2026 23:25:50 +0800 Subject: [PATCH 3/6] address grok review: merge-tree contract, repair invocation, stale provenance --- skills/operational-rigor/SKILL.md | 46 +++++++++++++++++++------------ 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index 05d6775..36ddfef 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -284,14 +284,16 @@ When rigor conflicts with finishing sooner, rigor wins. deletions. Survives is not untouched — a branch-side rename of an enclosing directory still relocates such a file or conflicts on it. Those deletions materialize when the base CHECKOUT is overwritten by - the branch tip (`reset --hard`, a tip-over-base copy) — which is why - non-empty never justifies re-applying — but NOT under - `format-patch` + `am`, which replays the branch's own commits and + the branch tip (`reset --hard`, a working-tree copy of the tip) — + which is why non-empty never justifies re-applying — but NOT under + `git format-patch $(git merge-base )..` + + `git am` onto the base, which replays the branch's own commits and leaves base-only files in place. Match the read to the action: a real - merge preview is `git merge-tree --write-tree `: it - writes and prints the resulting tree either way, adding the conflicted - paths and a conflict message and exiting non-zero when the merge does - not apply cleanly — so read its output, not its status. `git diff + merge preview is `git merge-tree --write-tree `. Its + first stdout line is the OID of the merged tree, written either way; + exit 0 means clean and exit 1 means conflicted, with the conflicted + paths and a CONFLICT message following that OID on stdout. Diff that + OID against the base to read the merge's net change. `git diff $(git merge-base ) ` is the branch's CONTRIBUTION, not the merge result — note it is the very same computation as the @@ -299,9 +301,10 @@ When rigor conflicts with finishing sooner, rigor wins. `git merge-base` prints nothing, silently degrading the command to a working-tree diff. What deleting the branch would lose is its unlanded work — the two-dot ADDITION side, or - `git log ..` (git mechanics above verified against - fixtures 2026-08-28; the incident shape stays `unprobed` — - contributor incident; see Provenance). + `git log ..` (the materialization set, the merge-tree + preview and the merge-base longhand were verified against fixtures + 2026-08-28; the squash and two-dot claims above and the incident + shape stay `unprobed` — contributor incident; see Provenance). - **A torn-down worktree can make git act on the ENCLOSING repo instead of failing** (prune/repair/discovery mechanics verified against fixtures 2026-08-28; the incident shape stays `unprobed` — @@ -312,9 +315,11 @@ When rigor conflicts with finishing sooner, rigor wins. drops the admin entry of any UNLOCKED worktree whose `.git` pointer file is missing — its directory still fully present or not ("gitdir file points to non-existent location"); `git worktree lock` is what - holds an entry through a prune. `git worktree repair ` rewrites - the pointer from that admin entry, so it works only until prune - removes it. The + holds an entry through a prune. A bare `git worktree repair` run from + the main checkout rewrites the missing pointer from that admin entry, + so the exit works only until prune removes the entry; the + `repair ` form also restores it but exits 1 with an `error:` + line, so its status reads as a failure it is not. The silent case is narrower and worse: the worktree's `.git` pointer file is gone while its directory path still resolves INSIDE the main checkout's tree — git resolves its repository by walking up from cwd, @@ -1446,7 +1451,8 @@ shipped after the branch's base. The incident's original reading — "a late merge would have silently regressed them" — was REFUTED on 2026-08-28 pre-merge review by execution (a three-way merge preserves base-side work the branch never touched; the two-dot deletion side -materializes only under reset/re-apply/overwrite), which is why the +materializes only when the base checkout is overwritten by the tip, not +under `format-patch` + `am`), which is why the amendment now reads the two-dot as a re-apply hazard and routes merge and delete decisions away from it. @@ -1462,12 +1468,18 @@ $(git merge-base A B) B` was byte-identical (`cmp`) to `git diff A...B`; on unrelated histories `git merge-base` exited 1 printing nothing; and on a branch that renamed an enclosing directory the merge conflicted and relocated a base-only file, which that diff did not show and -`git merge-tree --write-tree` did (tree written and printed, conflicted -path listed, exit 1). (3) `format-patch $(git merge-base A B)..B` + `am` +`git merge-tree --write-tree` did (merged-tree OID on the first stdout +line, then the conflicted path and a CONFLICT message, exit 1; a clean +pair printed the OID alone and exited 0). (3) `format-patch +$(git merge-base A B)..B` + `am` onto the base left the base-only file in place. (4) A force-push updated the ref and left the pushing tree untouched, so it is not a materializing action. (5) `git rev-parse --show-toplevel` exited 0 printing the -enclosing checkout in the rebind case. +enclosing checkout in the rebind case. (6) With the pointer file deleted +and the admin entry present, a bare `git worktree repair` from the main +checkout restored the pointer and exited 0, and `repair ` restored +it too but exited 1 with an `error:` line; after `prune` removed the +entry, both failed and the pointer stayed gone. The incident SHAPE of both bullets remains contributor-reported and ships `unprobed`; those probes stay on the standing #115 queue. From d55ceca8336569cc32626b9c71979d9026e818f9 Mon Sep 17 00:00:00 2001 From: firaen22 Date: Fri, 28 Aug 2026 23:43:39 +0800 Subject: [PATCH 4/6] address round-4 dual review: materialization set, runnable format-patch form, merge-tree exit contract, teardown error strings --- skills/operational-rigor/SKILL.md | 83 ++++++++++++++++++++----------- 1 file changed, 53 insertions(+), 30 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index 36ddfef..a860f46 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -283,34 +283,45 @@ When rigor conflicts with finishing sooner, rigor wins. never touched survives the merge even though the two-dot shows it as deletions. Survives is not untouched — a branch-side rename of an enclosing directory still relocates such a file or conflicts on it. - Those deletions materialize when the base CHECKOUT is overwritten by - the branch tip (`reset --hard`, a working-tree copy of the tip) — - which is why non-empty never justifies re-applying — but NOT under - `git format-patch $(git merge-base )..` + - `git am` onto the base, which replays the branch's own commits and - leaves base-only files in place. Match the read to the action: a real - merge preview is `git merge-tree --write-tree `. Its - first stdout line is the OID of the merged tree, written either way; - exit 0 means clean and exit 1 means conflicted, with the conflicted - paths and a CONFLICT message following that OID on stdout. Diff that - OID against the base to read the merge's net change. `git diff + Those deletions materialize under `git reset --hard `, a + DELETION-AWARE sync of the tip tree (`rsync --delete`; a plain + recursive copy leaves base-only files in place), or piping the two-dot + diff itself into `git apply` — which is why non-empty never justifies + re-applying. They do NOT materialize under + `git format-patch --stdout $(git merge-base ).. + | git am` onto the base, which replays the branch's own commits and + leaves base-only files alone (that pipeline is the runnable form: + bare `format-patch` writes `*.patch` into cwd and bare `git am` then + waits on stdin). Match the read to the action: a real merge preview is + `git merge-tree --write-tree `. Read its EXIT STATUS + first — 0 clean, 1 conflicted, anything else an error whose output is + unspecified (it refuses unrelated histories outright). On 0 and 1 its + first stdout line is the OID of the merged tree, written either way, + with conflicted-file info following on 1. Diff that OID against the + base to read the merge's net change. `git diff $(git merge-base ) ` is the branch's CONTRIBUTION, - not the merge result — note it is the very same computation as the - three-dot form rejected above, and on unrelated histories - `git merge-base` prints nothing, silently degrading the command to a - working-tree diff. What deleting the branch would lose is its - unlanded work — the two-dot ADDITION side, or - `git log ..` (the materialization set, the merge-tree - preview and the merge-base longhand were verified against fixtures - 2026-08-28; the squash and two-dot claims above and the incident - shape stay `unprobed` — contributor incident; see Provenance). + not the merge result — where a merge-base exists it is the same + computation as the three-dot form rejected above, but only the + longhand degrades: on unrelated histories `git merge-base` prints + nothing, the substitution empties, and the command silently becomes a + working-tree diff, which `...` never does. What deleting + the branch would lose is its unlanded work — the two-dot ADDITION + side, or `git log ..` (the materialization set, the + merge-tree preview and the merge-base longhand were verified against + fixtures 2026-08-28; the squash and empty-two-dot claims above and the + incident shape stay `unprobed` — contributor incident; see + Provenance). - **A torn-down worktree can make git act on the ENCLOSING repo instead - of failing** (prune/repair/discovery mechanics verified against - fixtures 2026-08-28; the incident shape stays `unprobed` — - contributor incident; see Provenance). The usual teardown fails LOUDLY: a removed linked - worktree is a dead cwd, sibling paths stop resolving, and commands - there die with "not a git repository". `git worktree prune` does not + of failing** (prune, repair, and the `--show-toplevel` rebind case + verified against fixtures 2026-08-28; the incident shape stays + `unprobed` — contributor incident; see Provenance). Teardown normally + fails LOUDLY, in one of two ways: delete the worktree directory while + it is still your cwd and git dies with "Unable to read current working + directory" before it looks for a repository at all; delete only the + `.git` pointer somewhere OUTSIDE the main checkout and the walk-up + finds nothing, so it dies with "not a git repository". `git worktree + prune` does not create the silent case below, but it does CLOSE the exit from it: it drops the admin entry of any UNLOCKED worktree whose `.git` pointer file is missing — its directory still fully present or not ("gitdir @@ -1451,10 +1462,11 @@ shipped after the branch's base. The incident's original reading — "a late merge would have silently regressed them" — was REFUTED on 2026-08-28 pre-merge review by execution (a three-way merge preserves base-side work the branch never touched; the two-dot deletion side -materializes only when the base checkout is overwritten by the tip, not -under `format-patch` + `am`), which is why the -amendment now reads the two-dot as a re-apply hazard and routes merge -and delete decisions away from it. +materializes when the base checkout is overwritten by the tip or the +two-dot diff is itself applied, not under `format-patch` + `am`), which +is why the amendment now reads the two-dot as a re-apply hazard, routes +the merge preview to `git merge-tree --write-tree`, and still reads +delete risk off the two-dot ADDITION side / `git log ..`. Both bullets' GIT MECHANICS were probed on 2026-08-28 against throwaway fixtures (git 2.50.1), after a two-family prose review of the same text @@ -1479,7 +1491,18 @@ enclosing checkout in the rebind case. (6) With the pointer file deleted and the admin entry present, a bare `git worktree repair` from the main checkout restored the pointer and exited 0, and `repair ` restored it too but exited 1 with an `error:` line; after `prune` removed the -entry, both failed and the pointer stayed gone. +entry, both failed and the pointer stayed gone. (7) Of the overwrite +actions, `git reset --hard ` and `rsync -a --delete` of the tip +tree each removed the base-only file, and piping `git diff +` into `git apply` did too, but a plain `cp -R` of the tip tree +left it in place — so only a deletion-aware overwrite materializes. +(8) Deleting a linked worktree directory while it was the cwd produced +"fatal: Unable to read current working directory", not "not a git +repository". (9) `format-patch --stdout ... | git am` is the runnable +form; bare `format-patch` wrote `0001-*.patch` into cwd and bare +`git am` read stdin. (10) `merge-tree --write-tree` on unrelated +histories exited 128 ("refusing to merge unrelated histories"), outside +its documented 0/1. The incident SHAPE of both bullets remains contributor-reported and ships `unprobed`; those probes stay on the standing #115 queue. From 7332775850d1753bb85836a2087a89ab705bf300 Mon Sep 17 00:00:00 2001 From: firaen22 Date: Sat, 29 Aug 2026 07:36:17 +0800 Subject: [PATCH 5/6] =?UTF-8?q?operational-rigor=20=C2=A72:=20the=20two-do?= =?UTF-8?q?t=20ADDITION=20side=20over-reports=20unlanded=20work?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- skills/operational-rigor/SKILL.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index a860f46..e5ccdb8 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -306,9 +306,14 @@ When rigor conflicts with finishing sooner, rigor wins. longhand degrades: on unrelated histories `git merge-base` prints nothing, the substitution empties, and the command silently becomes a working-tree diff, which `...` never does. What deleting - the branch would lose is its unlanded work — the two-dot ADDITION - side, or `git log ..` (the materialization set, the - merge-tree preview and the merge-base longhand were verified against + the branch would lose is its unlanded work — read that off + `git log ..` or the three-dot `git diff + ...`, NOT the two-dot ADDITION side: once the base has + moved on, that side also carries the branch's older copy of base-side + edits, which deleting the branch does not lose. The addition side is + inconclusive for the same reason the deletion side is (the + materialization set, the merge-tree preview, the addition-side read + and the merge-base longhand were verified against fixtures 2026-08-28; the squash and empty-two-dot claims above and the incident shape stay `unprobed` — contributor incident; see Provenance). @@ -1502,7 +1507,12 @@ repository". (9) `format-patch --stdout ... | git am` is the runnable form; bare `format-patch` wrote `0001-*.patch` into cwd and bare `git am` read stdin. (10) `merge-tree --write-tree` on unrelated histories exited 128 ("refusing to merge unrelated histories"), outside -its documented 0/1. +its documented 0/1. (11) With the base moved on (a base-side edit the +branch predates), the two-dot ADDITION side listed the branch's older +copy of that file alongside its genuine new work, while +`git log ..` and the three-dot diff listed only the new +work — so the addition side over-reports what deleting the branch loses, +by the same mechanism that makes the deletion side inconclusive. The incident SHAPE of both bullets remains contributor-reported and ships `unprobed`; those probes stay on the standing #115 queue. From d04e8140c500daaf38ec0c5f5b7cc238bb2d7344 Mon Sep 17 00:00:00 2001 From: firaen22 Date: Sat, 29 Aug 2026 07:46:38 +0800 Subject: [PATCH 6/6] round-5 review: log and three-dot are complementary; sync Provenance; date result 11 --- skills/operational-rigor/SKILL.md | 45 ++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/skills/operational-rigor/SKILL.md b/skills/operational-rigor/SKILL.md index e5ccdb8..b33f8d5 100644 --- a/skills/operational-rigor/SKILL.md +++ b/skills/operational-rigor/SKILL.md @@ -306,14 +306,21 @@ When rigor conflicts with finishing sooner, rigor wins. longhand degrades: on unrelated histories `git merge-base` prints nothing, the substitution empties, and the command silently becomes a working-tree diff, which `...` never does. What deleting - the branch would lose is its unlanded work — read that off - `git log ..` or the three-dot `git diff - ...`, NOT the two-dot ADDITION side: once the base has - moved on, that side also carries the branch's older copy of base-side - edits, which deleting the branch does not lose. The addition side is - inconclusive for the same reason the deletion side is (the - materialization set, the merge-tree preview, the addition-side read - and the merge-base longhand were verified against + the branch would lose is its unlanded work, and the two-dot ADDITION + side does not measure it: once the base has moved on, that side also + carries the branch's older copy of base-side edits, which deleting the + branch does not lose — inconclusive for the same tip-to-tip reason as + the deletion side. Use two COMPLEMENTARY reads instead, never as + equivalents: `git log ..` enumerates the branch's unique + COMMITS, and `git diff ...` shows its net CONTENT since + the merge-base. They diverge — a commit plus its revert leaves the log + non-empty and the three-dot diff empty. Mind the dots on the log: the + two-dot `..` (or `^ `) is the one you + want; `git log ...` is the SYMMETRIC difference and + lists base-side commits too, recreating the very over-report this + paragraph exists to stop (the materialization set, the merge-tree + preview, the addition-side over-report and the merge-base longhand + were verified against fixtures 2026-08-28; the squash and empty-two-dot claims above and the incident shape stay `unprobed` — contributor incident; see Provenance). @@ -1470,8 +1477,10 @@ base-side work the branch never touched; the two-dot deletion side materializes when the base checkout is overwritten by the tip or the two-dot diff is itself applied, not under `format-patch` + `am`), which is why the amendment now reads the two-dot as a re-apply hazard, routes -the merge preview to `git merge-tree --write-tree`, and still reads -delete risk off the two-dot ADDITION side / `git log ..`. +the merge preview to `git merge-tree --write-tree`, and reads delete +risk off `git log ..` plus `git diff ...` — +treating the two-dot ADDITION side as inconclusive for the same +tip-to-tip reason as its deletion side (result 11). Both bullets' GIT MECHANICS were probed on 2026-08-28 against throwaway fixtures (git 2.50.1), after a two-family prose review of the same text @@ -1507,12 +1516,16 @@ repository". (9) `format-patch --stdout ... | git am` is the runnable form; bare `format-patch` wrote `0001-*.patch` into cwd and bare `git am` read stdin. (10) `merge-tree --write-tree` on unrelated histories exited 128 ("refusing to merge unrelated histories"), outside -its documented 0/1. (11) With the base moved on (a base-side edit the -branch predates), the two-dot ADDITION side listed the branch's older -copy of that file alongside its genuine new work, while -`git log ..` and the three-dot diff listed only the new -work — so the addition side over-reports what deleting the branch loses, -by the same mechanism that makes the deletion side inconclusive. +its documented 0/1. Probed 2026-08-29: (11) with the base moved on (a +base-side edit the branch predates), the two-dot ADDITION side carried +the branch's older copy of that file alongside its genuine new work, +while `git log ..` contained only the branch's unique +commit and `git diff ...` only its net new content — so +the addition side over-reports what deleting the branch loses, by the +same mechanism that makes the deletion side inconclusive. The two reads +are not equivalent: a commit plus its revert left the log listing two +commits and the three-dot diff empty. (12) `git log ...` +(three dots) listed the BASE-side commit as well. The incident SHAPE of both bullets remains contributor-reported and ships `unprobed`; those probes stay on the standing #115 queue.