mellions-issue-remediationlisted

<!-- Mellions Engineer | LetA Tech Ltd. | leta@letatech.ca --> # Remediating a work item Turns a work item into verified code and then into a closed one: a worktree, the change, its proof, the resolution attacked, the pull request, the merge, the close. The repository's own manual defines what production-grade means there; this skill enforces only that the bar is **applied and demonstrated**. ## A remediation, not a narrow patch **A failing fixture is a claim about the world.** Establish what it asserts and whether that is true *before* touching it. One corrected because the evidence says it encodes the wrong semantics is legitimate, with the reasoning in the pull request; one edited because it was red is fabricated compliance evidence, as is an assertion moved to match the behaviour. ## Workflow **1 — Read everything, and establish the ground.** From the work item in full, its plan, and the repository's `CLAUDE.md`, establish: the branch to work from and target; the release branch, which is never a base for implementation; the verification commands; and any path that must not enter the diff without authorization. Where none declares the base, `git symbolic-ref refs/remotes/origin/HEAD` gives the remote's default — a candidate, not a declaration, and where a release branch is kept it names the one this step forbids. What merged pull requests mostly target settles it (`gh pr list -s merged --json baseRefName`). Say in the body that the base was inferred. No plan on the