justin/ai-workflow-course
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Module 6 - AI auto resolves merge conflict #97

New Issue
Closed
opened 2026-06-23 08:45:56 -04:00 by justin · 1 comment
justin commented 2026-06-23 08:45:56 -04:00
Owner
Copy Link
Copy Source

Modern frontier models can auto fix merge conflicts and the user never knows. We may need to try to merge manually in the hands on lab to show the conflict. then undo it, then have AI do the merge and show how AI will auto resolve conflicts.

Build scope (AI-ready)

Problem

Module 6's Part C lab teaches conflict resolution by telling the learner to direct the
agent to merge two colliding branches (feature/stats into feature/purge), expecting Git
to stop on a conflict so the learner can read the <<<<<<</=======/>>>>>>> markers
(Learning objective #4). With a current frontier editor-agent that assumption is now wrong:
told to "merge X into Y," the agent often resolves the conflict silently in the same turn
and reports a clean merge. The learner never sees a marker, never practices reading one, and
walks away thinking conflicts just do not happen anymore. The real lesson is the opposite and
sharper: the AI hides conflicts so smoothly you must (a) know what a conflict is and
(b) check git diff after every merge, because an invisible auto-resolution can be subtly
wrong (it can keep the worse side or blend two changes into one that satisfies neither).

Affected files / areas

  • modules/06-branches-sandboxes-for-experiments/README.md (primary):
    • Part C, steps 3-6 (lines ~368-427): the lab flow. Restructure to: witness the
      conflict first, undo it, then let the AI auto-resolve and verify.
    • Key concept "Merge conflicts: when two changes collide" (lines ~158-190): add the
      reality that a frontier agent may resolve the conflict before you ever see a marker.
    • "The AI angle" conflict bullet (lines ~210-215): update so it reflects auto-resolution,
      not "you hand it the conflict."
    • "Where it breaks" plausible-and-wrong bullet (lines ~460-464): strengthen with "you may
      not even know a conflict occurred, which is why the post-merge git diff is the safeguard."
    • Learning objectives #4 (line ~39) and "Check for understanding" (lines ~485-487):
      reword from "Git stops, read the markers" to "see a conflict at least once, then verify the
      AI's resolution even when it is invisible."
  • modules/06-branches-sandboxes-for-experiments/lab/make-conflict.sh: already manufactures a
    real conflict and leaves it mid-merge with both manual and agent instructions, so it still
    works as the deterministic fallback. Light touch only: its on-screen guidance (lines ~74-80)
    could add "look at the markers yourself before handing it to the agent." Do not change its
    mechanic.
  • blog/07-branches-sandboxes.md (sibling surface, lines ~124-158): the public blog mirrors the
    same conflict section and shows git merge feature/stats by hand. Update it to match the
    module's new framing so the two do not drift.

Recommended approach

Rework Part C step 3 onward into a three-beat sequence:

  1. Witness the conflict. Surface the markers before any resolution. Two course-consistent
    ways; pick one and keep the voice:
    • Preferred (keeps "AI drives git"): direct the agent to attempt the merge but stop on
      conflict and show it, not resolve it       ("merge feature/stats into feature/purge; if it
      conflicts, stop and show me the conflict, do not resolve it yet"). This idiom is already
      used and proven in Module 26 (README.md step ~370-385: "stop on the first conflict
      instead of resolving it").
    • Alternative (the issue's literal suggestion): have the learner run git merge feature/stats by hand once to see Git stop. Acceptable because Part C already has the
      learner run verification commands by hand, but it must be framed explicitly as a one-time
      "see the machine" step, not a regression to manual git (see stop-lines).
  2. Undo it. git merge --abort rewinds to before the merge (already documented at line ~190).
  3. Let the AI do it for real and verify. Now direct the agent to "merge feature/stats into
    feature/purge" with no stop-on-conflict guard, and watch it auto-resolve in one turn with no
    markers shown. Then make the verify the punchline: git diff / run the app to confirm the
    invisible resolution is correct (here, the usage string lists both stats and purge).

Land the takeaway in prose: the skill is no longer "resolve markers by hand"; it is "know a
conflict happened and check the AI's silent resolution." Keep the existing stats/purge fiction
and the make-conflict.sh fallback intact.

Target surface(s)

Course content (Markdown). The Module 6 README is the deliverable; the blog mirror and the
make-conflict.sh on-screen text are required follow-ons for consistency. No application/code logic
changes to tasks-app.

Acceptance criteria / how to verify

This repo has no prose test suite; CI only syncs the wiki (.gitea/workflows/sync-wiki.yml).
Verify by:

  1. Run the lab end to end on a real tasks-app: build feature/stats and feature/purge,
    confirm the new step makes the conflict visible at least once (markers appear), confirm
    git merge --abort cleans it, then confirm a plain "merge them" instruction to an editor-agent
    auto-resolves with no markers surfaced and git diff shows the merged usage string.
  2. Fallback still works: from a clean tasks-app, bash make-conflict.sh leaves a real conflict.
  3. De-slop self-check (hard gate per AGENTS.md): grep -n '—' returns nothing in every
    changed file (no em-dash), and no banned words are introduced (prose, delve, leverage, utilize,
    robust, comprehensive, seamless, streamline, etc.).
  4. Internal consistency: Learning objective #4, the Key-concepts section, the AI-angle bullet,
    the Where-it-breaks bullet, and Check-for-understanding all agree with the new Part C flow; the
    blog section tells the same story.
  5. Links/paths in the edited sections still resolve (the cp ... make-conflict.sh path, module
    cross-references).

Stop-lines (do not cross)

  • Do not break the "AI drives git" reframe (AGENTS.md): Module 4 onward, the learner directs
    the agent and verifies; modules must not tell them to type git by hand as the norm. If you use
    the by-hand git merge witness, justify it inline as a deliberate one-time "see the machine"
    step (mirrors how Modules 1-3 teach mechanics by hand on purpose). Preferred path avoids this by
    using the agent's stop-on-conflict idiom.
  • Do not re-teach branch basics or restructure beyond Part C and its dependent sections.
  • Do not change tasks-app code or invent new real commands; stats/purge stay fictional
    usage-string edits, and the collision mechanic stays "two branches edit the same usage line."
  • Do not touch Module 26 (it already handles agent-vs-agent conflicts and owns the
    stop-on-conflict idiom; reuse its pattern, do not duplicate or move it).
  • Honor lesson-vs-lab separation (AGENTS.md): theory shows commands as illustration only; all
    execution stays in the lab.
Modern frontier models can auto fix merge conflicts and the user never knows. We may need to try to merge manually in the hands on lab to show the conflict. then undo it, then have AI do the merge and show how AI will auto resolve conflicts. --- ## Build scope (AI-ready) ### Problem Module 6's Part C lab teaches conflict resolution by telling the learner to direct the agent to merge two colliding branches (`feature/stats` into `feature/purge`), expecting Git to **stop on a conflict** so the learner can read the `<<<<<<<`/`=======`/`>>>>>>>` markers (Learning objective #4). With a current frontier editor-agent that assumption is now wrong: told to "merge X into Y," the agent often **resolves the conflict silently in the same turn** and reports a clean merge. The learner never sees a marker, never practices reading one, and walks away thinking conflicts just do not happen anymore. The real lesson is the opposite and sharper: the AI hides conflicts so smoothly you must (a) know what a conflict *is* and (b) check `git diff` after *every* merge, because an invisible auto-resolution can be subtly wrong (it can keep the worse side or blend two changes into one that satisfies neither). ### Affected files / areas - `modules/06-branches-sandboxes-for-experiments/README.md` (primary): - **Part C, steps 3-6** (lines ~368-427): the lab flow. Restructure to: **witness** the conflict first, **undo** it, then let the AI **auto-resolve** and verify. - **Key concept "Merge conflicts: when two changes collide"** (lines ~158-190): add the reality that a frontier agent may resolve the conflict before you ever see a marker. - **"The AI angle"** conflict bullet (lines ~210-215): update so it reflects auto-resolution, not "you hand it the conflict." - **"Where it breaks"** plausible-and-wrong bullet (lines ~460-464): strengthen with "you may not even know a conflict occurred, which is *why* the post-merge `git diff` is the safeguard." - **Learning objectives #4** (line ~39) and **"Check for understanding"** (lines ~485-487): reword from "Git stops, read the markers" to "see a conflict at least once, then verify the AI's resolution even when it is invisible." - `modules/06-branches-sandboxes-for-experiments/lab/make-conflict.sh`: already manufactures a real conflict and leaves it mid-merge with both manual and agent instructions, so it still works as the deterministic fallback. Light touch only: its on-screen guidance (lines ~74-80) could add "look at the markers yourself before handing it to the agent." Do not change its mechanic. - `blog/07-branches-sandboxes.md` (sibling surface, lines ~124-158): the public blog mirrors the same conflict section and shows `git merge feature/stats` by hand. Update it to match the module's new framing so the two do not drift. ### Recommended approach Rework Part C step 3 onward into a three-beat sequence: 1. **Witness the conflict.** Surface the markers *before* any resolution. Two course-consistent ways; pick one and keep the voice: - **Preferred (keeps "AI drives git"):** direct the agent to *attempt the merge but stop on conflict and show it, not resolve it* ("merge `feature/stats` into `feature/purge`; if it conflicts, stop and show me the conflict, do not resolve it yet"). This idiom is already used and proven in Module 26 (`README.md` step ~370-385: "stop on the first conflict instead of resolving it"). - **Alternative (the issue's literal suggestion):** have the learner run `git merge feature/stats` by hand once to see Git stop. Acceptable because Part C already has the learner run verification commands by hand, but it must be framed explicitly as a one-time "see the machine" step, *not* a regression to manual git (see stop-lines). 2. **Undo it.** `git merge --abort` rewinds to before the merge (already documented at line ~190). 3. **Let the AI do it for real and verify.** Now direct the agent to "merge `feature/stats` into `feature/purge`" with no stop-on-conflict guard, and watch it auto-resolve in one turn with no markers shown. Then make the verify the punchline: `git diff` / run the app to confirm the invisible resolution is correct (here, the usage string lists *both* `stats` and `purge`). Land the takeaway in prose: the skill is no longer "resolve markers by hand"; it is "know a conflict happened and check the AI's silent resolution." Keep the existing `stats`/`purge` fiction and the `make-conflict.sh` fallback intact. ### Target surface(s) Course content (Markdown). The Module 6 README is the deliverable; the blog mirror and the make-conflict.sh on-screen text are required follow-ons for consistency. No application/code logic changes to `tasks-app`. ### Acceptance criteria / how to verify This repo has no prose test suite; CI only syncs the wiki (`.gitea/workflows/sync-wiki.yml`). Verify by: 1. **Run the lab end to end** on a real `tasks-app`: build `feature/stats` and `feature/purge`, confirm the new step makes the conflict *visible* at least once (markers appear), confirm `git merge --abort` cleans it, then confirm a plain "merge them" instruction to an editor-agent auto-resolves with no markers surfaced and `git diff` shows the merged usage string. 2. **Fallback still works:** from a clean tasks-app, `bash make-conflict.sh` leaves a real conflict. 3. **De-slop self-check (hard gate per AGENTS.md):** `grep -n '—'` returns nothing in every changed file (no em-dash), and no banned words are introduced (prose, delve, leverage, utilize, robust, comprehensive, seamless, streamline, etc.). 4. **Internal consistency:** Learning objective #4, the Key-concepts section, the AI-angle bullet, the Where-it-breaks bullet, and Check-for-understanding all agree with the new Part C flow; the blog section tells the same story. 5. **Links/paths** in the edited sections still resolve (the `cp ... make-conflict.sh` path, module cross-references). ### Stop-lines (do not cross) - **Do not break the "AI drives git" reframe** (AGENTS.md): Module 4 onward, the learner *directs* the agent and *verifies*; modules must not tell them to type git by hand as the norm. If you use the by-hand `git merge` witness, justify it inline as a deliberate one-time "see the machine" step (mirrors how Modules 1-3 teach mechanics by hand on purpose). Preferred path avoids this by using the agent's stop-on-conflict idiom. - **Do not re-teach branch basics** or restructure beyond Part C and its dependent sections. - **Do not change `tasks-app` code** or invent new real commands; `stats`/`purge` stay fictional usage-string edits, and the collision mechanic stays "two branches edit the same usage line." - **Do not touch Module 26** (it already handles agent-vs-agent conflicts and owns the stop-on-conflict idiom; reuse its pattern, do not duplicate or move it). - **Honor lesson-vs-lab separation** (AGENTS.md): theory shows commands as illustration only; all execution stays in the lab.
claude added the ai-ready label 2026-06-23 08:49:22 -04:00
justin added the autopilot label 2026-06-23 08:55:49 -04:00
claude added the needs-human label 2026-06-23 09:04:32 -04:00
claude commented 2026-06-23 09:04:32 -04:00
Contributor
Copy Link
Copy Source

🤖 autopilot review gate: VETOED — a human needs to take this.

Fix the issue (or merge by hand if it's a false positive), then remove needs-human to hand it back to autopilot.

🤖 autopilot review gate: **VETOED** — a human needs to take this. - `ineligible`: no [[autopilot.repo]] config declaring deploy/build/test Fix the issue (or merge by hand if it's a false positive), then remove `needs-human` to hand it back to autopilot.
claude removed the autopilot label 2026-06-23 09:08:02 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ai-ready
Scoped and ready to implement
 autopilot
Drive end-to-end autonomously (claude-deck)
 autopilot-careful
Autopilot may scope/implement but never auto-merge
 bug
Defect
 feature
New capability
 needs-human
Autopilot stalled or vetoed — a human must act
 P0
Critical
 P1
High
 P2
Normal
No Label ai-ready needs-human
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
justin (Justin Paul)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: justin/ai-workflow-course#97
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?