Guard the mesa driver swap on its end state

mesa-va-drivers-freeworld Provides mesa-va-drivers, so once the swap has run
once it becomes the only thing providing the name we ask dnf to remove. The
command then resolves to removing and installing the same package in a single
transaction and exits with "conflicting requests", which reported
install-packages as a failed stage on every run after the first even though
the machine was already in the desired state.

The failure also produced misleading output, because dnf explored removing
mesa-dri-drivers and surfaced unrelated complaints from steam, lutris and
tigervnc-server-common.

Check for the freeworld package with rpm -q and skip the swap when it is
already installed.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01TFG55mJBiH2tV38tXcNzJ9

setup/scripts/install-packages

@@ -1405,8 +1405,17 @@ soft "the multimedia group update" \
 sync
 log "Swapping ffmpeg-free for ffmpeg"
 soft "the ffmpeg swap" sudo dnf swap -y 'ffmpeg-free' 'ffmpeg' --allowerasing
+# mesa-va-drivers-freeworld Provides mesa-va-drivers, so once the swap has been
+# done it is the only thing providing the name we ask dnf to remove. `dnf swap`
+# then resolves to removing and installing the same package in one transaction
+# and fails with "conflicting requests", which reports install-packages as a
+# failed stage on every subsequent run. Guard on the end state instead.
+if rpm -q mesa-va-drivers-freeworld >/dev/null 2>&1; then
+	log "mesa-va-drivers-freeworld is already installed; swap not needed"
+else
 	log "Swapping mesa-va-drivers for mesa-va-drivers-freeworld"
 	soft "the mesa driver swap" sudo dnf swap -y mesa-va-drivers mesa-va-drivers-freeworld
+fi
 log "Upgrading Multimedia group with optional packages"
 soft "the optional Multimedia upgrade" sudo dnf4 group upgrade -y --with-optional Multimedia
 log "Installing GStreamer plugins (bad, good, base)"

user/agents/skills/ticket/SKILL.md

@@ -751,6 +751,35 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
         write `mr.md` before that verdict is reached.
    Findings that need no code change (mentions, disclosures) get addressed in
    `mr.md`'s Additional Notes or the Jira fields as usual.
+
+   **The verdict is the gate and it is not negotiable.** Ready to Open MR is what
+   goes on record with the Lead, so never reason your way past it because the
+   remaining items look harmless. That judgment is not yours to make.
+
+   **Don't confuse the verdict with the handoff's recommendation.** They are
+   different fields in different files for different readers. The audit's
+   `Verdict` says whether the branch is ready to become an MR, and that is the
+   gate. The handoff's `Recommendation` (`Merge`, `Merge after conditions`) is
+   advice to the maintainer about merging it, and `Merge after conditions` is
+   normal and expected at a Ready verdict. Never treat the recommendation as a
+   blocker or report it as one.
+
+   **Reruns converge by giving the audit more, not by repeating the command.**
+   When a rerun is needed, the user is running it, so every rerun costs them.
+   Make each one count:
+   - **Feed it context on the first run.** It reviews the diff, and left alone it
+     re-derives intent from the branch name and re-raises decisions that are
+     already settled. Ask the user to point it at the ticket's
+     `resources/ticket.md` and `plan.md`. This is the cheapest thing that reduces
+     repeat findings.
+   - **Answer its decisions explicitly in the rerun.** When it parks a finding
+     under "Decide before opening", write the decision and its reasoning into the
+     prompt for the next run, so it can reclassify rather than re-ask. A silent
+     rerun on an unchanged diff re-asks the same question.
+   - **Say so when it finds new things in unchanged code.** That means the earlier
+     run was an incomplete pass, not that the branch got worse. Tell the user
+     plainly, because it is the audit's problem to fix and it changes how much
+     weight the next run deserves.
 8. Read `~/.agents/skills/ticket/templates/mr.md` — this is the org's MR template,
    copied into this skill so it still works even though the original
    `.claude/docs/mr/template.md` no longer exists in the command-center repo. `mr.md`
@@ -775,7 +804,9 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
      verified" if you actually ran a build and it passed).
    - Replace `<!-- Paste the Pre-MR handoff here -->` with the exact content of the
      latest `pre-mr-review` handoff file (the one with verdict Ready to Open MR) —
-     paste it verbatim, don't summarize it.
+     paste it verbatim, don't summarize it. Its `Recommendation` line is the
+     audit's advice to the maintainer and is left exactly as written, including
+     `Merge after conditions`.
 
      The handoff section of `mr.md` is GENERATED OUTPUT, not something you author.
      It is the block that states whether the branch is ready to merge, so it must be