Problem
After merging main into a feature branch, files introduced on main may contain lint suppressions that are stale under the feature branch's config. If the auto-fix output isn't committed, CI's "Fail build on mutation" step rejects the PR.
This happened on PR #171 (ESLint 10 upgrade): after merging main (which included PR #176 attachments), two files had // eslint-disable-next-line comments for rules not enabled in the new flat config. ESLint --fix removes them, but the removal wasn't committed — causing a CI mutation failure.
Findings
-
The root cause is a workflow gap: merging main into a config-change branch brings in code that hasn't been processed by the new config. The merge itself doesn't run linters.
-
The fix pattern: After any merge of main into a feature branch, run mise //cdk:eslint and mise //cli:eslint (which use --fix), then commit any resulting changes.
-
Where to document: AGENTS.md → "Common mistakes" section, adjacent to the existing Git worktrees bullet. This is where agents read workflow rules on every session start.
-
The broader workflow insight: The complete development workflow is:
issue → worktree → branch → local checks → PR draft → remote checks → PR ready for review
The "local checks" step must include running linters with --fix after merges — not just verifying zero errors. CI checks for mutations (uncommitted auto-fixes), so local development must capture and commit those mutations before pushing.
Proposed addition to AGENTS.md
In the "Common mistakes" section, after the "Git worktrees" bullet:
- **After merging main into a feature branch** — Always run **`mise //cdk:eslint`** and **`mise //cli:eslint`** (which use `--fix`), then commit any resulting changes. Merged-in files may contain stale lint suppressions that the feature branch's config removes. CI's "Fail build on mutation" step will reject uncommitted auto-fixes.
Acceptance criteria
References
Problem
After merging
maininto a feature branch, files introduced on main may contain lint suppressions that are stale under the feature branch's config. If the auto-fix output isn't committed, CI's "Fail build on mutation" step rejects the PR.This happened on PR #171 (ESLint 10 upgrade): after merging main (which included PR #176 attachments), two files had
// eslint-disable-next-linecomments for rules not enabled in the new flat config. ESLint--fixremoves them, but the removal wasn't committed — causing a CI mutation failure.Findings
The root cause is a workflow gap: merging main into a config-change branch brings in code that hasn't been processed by the new config. The merge itself doesn't run linters.
The fix pattern: After any merge of main into a feature branch, run
mise //cdk:eslintandmise //cli:eslint(which use--fix), then commit any resulting changes.Where to document:
AGENTS.md→ "Common mistakes" section, adjacent to the existing Git worktrees bullet. This is where agents read workflow rules on every session start.The broader workflow insight: The complete development workflow is:
The "local checks" step must include running linters with
--fixafter merges — not just verifying zero errors. CI checks for mutations (uncommitted auto-fixes), so local development must capture and commit those mutations before pushing.Proposed addition to AGENTS.md
In the "Common mistakes" section, after the "Git worktrees" bullet:
Acceptance criteria
mise //docs:sync)References
1fd3127onfeat/eslint-10-upgrade