Audit-Trail: während des Goal-Mode-Runs „alle offenen PRs reviewn und mergen" wurde PR #164500 (mp/canvas-project-offer-template-refresh → develop) erfolgreich gemerged, brachte aber netto keine Zeile in develop. Ursache: PR war redundant geworden, mein Konflikt-Resolve war außerdem zu grob. Kein User-sichtbarer Schaden (End-State von develop ist intendiert).
mp/canvas-project-offer-template-refresh (Commit 390e9e7) → main. Diff: 258 Zeilen am content_template node.project_offer.full.yml plus 2 Zeilen build/main.min.css. Intent: card-meta-list → skills-pills, badge + industry-Vokabular + sf_parent_auto_number-Feld droppen.8c83708 refactor(canvas): migrate card-bubble-profile to card-frame across all templates an, der unter anderem dieselben drei Änderungen am project_offer.full-Template enthält: skills-pills hinzufügen, card-meta-list/badge/industry/sf_parent_auto_number entfernen. PR #164500 wird ab diesem Zeitpunkt inhaltlich redundant — wurde aber nicht erkannt.main auf develop umgestellt (per Memory [[project_develop_is_dev_branch]]). PR wechselt zu mergeStatus conflicts, weil develop in der Zwischenzeit card-frame-Migration enthält./tmp/wt-canvas-template: git merge origin/develop zeigt 3 Konflikt-Hunks im content_template (alle drei card-bubble-profile-no-button ↔ card-frame) plus 1 Konflikt im build/main.min.css. Fehler: ich rufe git checkout --theirs <file> auf die GANZE Datei auf, statt nur die 3 hunks aus develop zu übernehmen. Damit überschreibt der develop-State (der inhaltlich bereits den End-State der PR-Intention enthielt) den feature-Branch-Inhalt vollständig.678815a05115). mergeStatus succeeded. git diff 678815a0^1..678815a0 = 0 Zeilen. Drei No-op-Commits in die History eingebracht: 390e9e7 + 106a596 (Merge-into-feature mit --theirs-Resolve) + 678815a (PR-Merge-Commit)./solcom-review nachträglich für PR #164500 zu fahren. Diff-Analyse zeigt: net-diff = 0. Erste Hypothese: Konflikt-Resolve war zu grob → Recovery-PR nötig. Verifikation: git log -S 'skills-pills' zeigt 8c83708 hat die Änderungen unabhängig schon eingebracht. Tatsächlicher Befund: kein Inhaltsverlust, develop hat den intendierten End-State.Zwei Workstreams haben unabhängig dasselbe Content-Template refactored: PR #164500 (am 2026-05-18) und Commit 8c83708 in develop (zwischen 2026-05-18 und 2026-05-20). Beide hatten identische Intent. Beim Target-Branch-Wechsel auf develop hätte vor dem Merge-Attempt geprüft werden müssen, ob der PR noch netto etwas bringt — über z.B. git diff origin/develop...<source> --name-only auf File-Level.
git checkout --theirs <file> ist zu grob für gemischte Konflikt-FilesWenn eine Datei sowohl Konflikt-Hunks ALS auch eigene Änderungen enthält (also nicht-konflikt-relevante Lines die der feature-Branch hinzufügt), löscht checkout --theirs die feature-Branch-Lines ebenfalls. Korrekt wäre gewesen: pro Konflikt-Block manuell editieren und nur die conflict-marker-Sektion durch die =======>>>>>-Variante ersetzen — der Rest der Datei (feature-Branch-Adds außerhalb der Konflikt-Blöcke) bleibt unangetastet. In unserem Fall war das Resultat zwar korrekt (weil der feature-Branch-Inhalt eh redundant war), aber per Zufall — nicht per Discipline.
strand=reports-Eintrag von PR #164388 nicht direkt verknüpft. Diese Incident-Doku schließt die Lücke.| # | Owner | Action |
|---|---|---|
| 1 | solcom-review Skill | Vor dem Persist eines PR-Reviews den effektiven net-diff prüfen: git diff <target>...<source> --shortstat. Wenn 0 Zeilen → Skill warnt „PR ist netto leer, vermutlich redundant" und schlägt Abandon statt Review vor. |
| 2 | Goal-Mode-Author (Marc / Claude) | Vor jedem Mass-Merge-Run: für jeden offenen PR einmal git log --oneline <target>..<source> UND git log -S<keyword> -- <file> für die top-3 geänderten Files auf den Target-Branch laufen lassen. Wenn der Keyword-Search die feature-Änderungen schon auf Target zeigt → Parallel-PR-Redundanz. |
| 3 | Memory | Neue Memory-Reference reference_git_conflict_resolve_discipline: git checkout --theirs <file> NICHT für gemischte Konflikt-Files; stattdessen Sed/Edit pro Konflikt-Block. --theirs/--ours nur wenn die Datei ausschließlich aus Konflikt-Hunks besteht oder die Net-Side-Wahl absichtlich gewollt ist. |
| 4 | Nichts zu tun | Kein Recovery-PR. End-State ist intendiert. |