@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.0

package/pipeline/skills/shared/external/swiftlint/SKILL.md

@@ -1,82 +1,95 @@
 ---
 name: swiftlint
-description: "Configures and enforces SwiftLint via build tool plugins, run scripts and CI: .swiftlint.yml rule sets, analyzer rules, baselines, autocorrect, swiftlint:disable suppressions, reporter formats, strict and lenient modes, SwiftLintBuildToolPlugin, Xcode run script phases, and rollout strategies for an existing codebase. Use when setting up SwiftLint, configuring or suppressing rules, creating a baseline, choosing plugin vs run script, or wiring it into CI."
+description: "SwiftLint setup and enforcement: build tool and command plugins, Xcode run scripts, CI, .swiftlint.yml rule sets (default, opt-in, analyzer), baselines, --fix autocorrect, swiftlint:disable, reporters, strict/lenient modes, nested and remote configs, custom regex rules, rollout on existing code. Use when installing SwiftLint, configuring, tuning or suppressing rules, creating or shrinking a baseline, choosing plugin vs run script, or wiring lint into CI."
 metadata:
-  source: "dpearson2699/swift-ios-skills (PolyForm Perimeter 1.0.0)"
+  source: multi-agent-pipeline
 ---
 
 # SwiftLint
 
-SwiftLint enforces Swift style and conventions by linting source files against a configurable rule set. It is the most widely adopted Swift linter. This skill covers setup, configuration, rule selection, suppression, CI integration, and rollout strategy.
+SwiftLint checks Swift source against a rule set you configure. It is the
+linter most Swift teams reach for. It only enforces conventions; deciding what
+the conventions are is a separate job. For naming and API shape see
+`swift-api-design-guidelines`; for layering and module design see
+`swift-architecture`.
 
-SwiftLint is a **style enforcement tool**, not a style guide. For underlying Swift naming and design conventions, see `swift-api-design-guidelines`. For architecture patterns, see `swift-architecture`.
+Reference files, loaded on demand:
 
-## Contents
+| File | Load it for |
+|---|---|
+| [Adoption guide](references/adoption-and-configuration.md) | install options, how configs are found and merged, thresholds, env vars, remote parents, the four-phase rollout |
+| [Integrations guide](references/plugins-run-scripts-and-integrations.md) | build tool and command plugins, run script phases, CI recipes, reporters, toolchains, editor, Fastlane, Docker, pre-commit |
+| [Rules and suppressions](references/rules-suppressions-and-baselines.md) | rule categories, rules people hit most, per-rule YAML, suppression syntax and policy, baselines, false positives, generated and test code |
+| [Rule index](references/rule-reference.md) | every rule identifier, grouped by concern, with a one-line summary |
+| [Custom rules and analyzer](references/custom-rules-and-analyze.md) | `custom_rules` regex rules, Swift-source rules, `swiftlint analyze` |
 
-- [Recommended Setup](#recommended-setup)
-- [Configuration](#configuration)
-- [Rule Selection Strategy](#rule-selection-strategy)
-- [Suppressions](#suppressions)
-- [Baselines](#baselines)
-- [Autocorrect](#autocorrect)
-- [CI Integration](#ci-integration)
-- [Integration Decision Tree](#integration-decision-tree)
-- [Multiple Configurations](#multiple-configurations)
-- [Common Mistakes](#common-mistakes)
-- [Review Checklist](#review-checklist)
-- [References](#references)
+Upstream docs: https://realm.github.io/SwiftLint/ and the rule directory at
+https://realm.github.io/SwiftLint/rule-directory.html.
 
----
-
-## Recommended Setup
+## Default setup: the build tool plugin
 
-**Default: build tool plugin via `SimplyDanny/SwiftLintPlugins`.**
-
-Add the plugin package to `Package.swift` or via Xcode's package dependencies:
+Start with `SwiftLintBuildToolPlugin`, shipped by the
+https://github.com/SimplyDanny/SwiftLintPlugins package. Pin a version you have
+reviewed rather than floating on the newest one.
 
 ```swift
 // Package.swift
 dependencies: [
-  .package(url: "https://github.com/SimplyDanny/SwiftLintPlugins", from: "<reviewed-version>")
+    .package(url: "https://github.com/SimplyDanny/SwiftLintPlugins", from: "<reviewed-version>")
+],
+targets: [
+    .target(
+        name: "LedgerCore",
+        plugins: [.plugin(name: "SwiftLintBuildToolPlugin", package: "SwiftLintPlugins")]
+    )
 ]
 ```
 
-For SwiftPM targets, apply the plugin:
+- An Xcode project with no `Package.swift` adds the same package from the
+  project's package settings, then turns the plugin on for each target under
+  Build Phases (or accepts it when Xcode offers the trust prompt).
+- After that, each build triggers a lint pass by itself; you do not add a
+  run script.
+- The first build asks whether to trust the plugin. Pick "Trust & Enable All"
+  for SwiftLintPlugins.
 
-```swift
-.target(
-    name: "MyApp",
-    plugins: [.plugin(name: "SwiftLintBuildToolPlugin", package: "SwiftLintPlugins")]
-)
-```
+Why the plugin wins for local work: nobody has to fix their `PATH`, package
+resolution pins the linter version for the whole team, and it runs without
+anyone remembering to.
 
-For Xcode projects without a `Package.swift`, add the package dependency in the project settings, then enable the plugin under the target's Build Phases or the package's plugin trust dialog.
+## Which integration fits
 
-The build tool plugin runs SwiftLint automatically on every build. No run script required.
+| Situation | Use |
+|---|---|
+| SwiftPM package, or Xcode project that has a `Package.swift` | Build tool plugin from `SwiftLintPlugins` |
+| SwiftPM, but you need CLI flags such as `--fix` or `--baseline` | Command plugin: `swift package plugin swiftlint` |
+| Xcode project without SwiftPM, team already on Homebrew | Run script build phase |
+| CI/CD job | Install with Homebrew or pull the Docker image, call `swiftlint` directly |
+| Pre-commit checks | Homebrew install plus `.pre-commit-config.yaml` or a git hook script |
 
-> **First build**: Xcode prompts to trust the plugin. Select "Trust & Enable All" for the SwiftLintPlugins package.
+Setup steps for every row: [integrations guide](references/plugins-run-scripts-and-integrations.md).
 
-For alternatives (run scripts, command plugin, Homebrew CLI), see [references/plugins-run-scripts-and-integrations.md](references/plugins-run-scripts-and-integrations.md).
+## `.swiftlint.yml`
 
-## Configuration
+Put the file at the repository root. For each source file SwiftLint walks up
+the directory tree to find its configuration.
 
-Create `.swiftlint.yml` at the project root. SwiftLint discovers this file by walking up from each source file's directory.
+A reasonable first config:
 
 ```yaml
-# .swiftlint.yml  -  conservative starter config
 disabled_rules:
-  - trailing_whitespace
   - todo
+  - trailing_whitespace
 
 opt_in_rules:
-  - empty_count
+  - accessibility_label_for_image
   - closure_spacing
+  - empty_count
   - force_unwrapping
-  - sorted_imports
-  - vertical_whitespace_opening_braces
   - private_swiftui_state
+  - sorted_imports
   - unhandled_throwing_task
-  - accessibility_label_for_image
+  - vertical_whitespace_opening_braces
 
 included:
   - Sources
@@ -91,249 +104,185 @@ excluded:
 line_length:
   warning: 140
   error: 200
-
 type_body_length:
   warning: 300
   error: 500
-
 file_length:
   warning: 500
   error: 1000
 ```
 
-Key configuration options:
-
-| Key | Purpose |
-|-----|---------|
-| `disabled_rules` | Turn off default-enabled rules |
-| `opt_in_rules` | Turn on rules not enabled by default |
-| `only_rules` | Use _only_ the listed rules (mutually exclusive with `disabled_rules`/`opt_in_rules`) |
-| `analyzer_rules` | Rules requiring compiler logs (run via `swiftlint analyze`) |
-| `baseline` | Path to an existing baseline file used to suppress known violations |
-| `write_baseline` | Path where SwiftLint should write a new baseline file |
-| `included` | Paths to lint (default: current directory) |
-| `excluded` | Paths to skip |
-| `strict` | Elevate all warnings to errors |
-| `lenient` | Downgrade all errors to warnings |
-| `allow_zero_lintable_files` | Suppress the error when no Swift files are found |
-| `reporter` | Output format: `xcode` (default), `json`, `checkstyle`, `sarif`, `csv`, `emoji`, etc. |
+Top-level keys:
 
-For full configuration details including severity tuning, environment-variable interpolation, and nested/remote configs, see [references/adoption-and-configuration.md](references/adoption-and-configuration.md).
+| Key | Effect |
+|---|---|
+| `disabled_rules` | switches off rules that are on by default |
+| `opt_in_rules` | switches on rules that ship disabled |
+| `only_rules` | runs exactly this list and nothing else; cannot be combined with `disabled_rules` or `opt_in_rules` |
+| `analyzer_rules` | rules that need compiler logs; they run only under `swiftlint analyze` |
+| `baseline` | path of an existing baseline whose violations are ignored |
+| `write_baseline` | path where a fresh baseline is written |
+| `included` | paths to lint; the current directory when omitted |
+| `excluded` | paths to skip |
+| `strict` | promotes warnings to errors |
+| `lenient` | demotes errors to warnings |
+| `allow_zero_lintable_files` | finding no Swift files is not an error |
+| `reporter` | output format: `xcode` by default, plus `json`, `checkstyle`, `sarif`, `csv`, `emoji` and more |
 
-## Rule Selection Strategy
+Thresholds, nesting and remote parents: [adoption and configuration](references/adoption-and-configuration.md).
 
-SwiftLint ships with three rule categories:
+## Picking rules
 
-1. **Default rules**  -  enabled automatically, cover widely accepted conventions
-2. **Opt-in rules**  -  disabled by default, enable selectively via `opt_in_rules`
-3. **Analyzer rules**  -  require compiler logs, enabled via `analyzer_rules`
+Rules fall into three buckets:
 
-Browse the full categorized list at <https://realm.github.io/SwiftLint/rule-directory.html>.
+- **Default**: on unless disabled; conventions most Swift code already follows.
+- **Opt-in**: off until listed under `opt_in_rules`; more opinionated.
+- **Analyzer**: need compiler logs; listed under `analyzer_rules`.
 
-**Recommended approach for new projects:**
+The authoritative list with options is the rule directory
+(https://realm.github.io/SwiftLint/rule-directory.html). Do not try to learn
+it by heart or paste it into docs; look a rule up when you need it. The local
+[rule reference](references/rule-reference.md) is an offline index.
 
-1. Start with defaults. Run `swiftlint rules` to see which rules are enabled.
-2. Disable rules that conflict with your team's established conventions.
-3. Add opt-in rules one at a time. Review violations before committing each addition.
-4. Do not use `only_rules` unless you have a specific reason to start from zero.
+Greenfield project:
 
-**Recommended approach for existing codebases:**
+1. Run with defaults. `swiftlint rules` prints what is enabled.
+2. Disable the few defaults that contradict agreed team conventions.
+3. Turn on opt-in rules individually, and look at what each one reports
+   before you commit it.
+4. Leave `only_rules` alone unless you have a concrete reason to begin from an
+   empty set.
 
-1. Start with the default rule set.
-2. Create a baseline (see [Baselines](#baselines)) to suppress all existing violations.
-3. Enforce zero new violations in CI.
-4. Burn down baseline violations incrementally.
+Existing codebase: keep the defaults, capture every current violation in a
+baseline, make CI reject any new violation, then pay the baseline down over
+time. The full plan is the rollout section of
+[adoption and configuration](references/adoption-and-configuration.md).
 
-Do not transcribe or memorize the rule directory. Look up rule identifiers and configuration options at the official rule directory when needed.
+## Suppressing a rule
 
-## Suppressions
-
-Suppress SwiftLint for specific lines when a rule produces a false positive or when the violation is intentional and reviewed.
+Suppress only a confirmed false positive or a violation the team reviewed and
+accepted. Every form names the rule:
 
 ```swift
 // swiftlint:disable:next force_cast
-let view = object as! UIView
+let cell = table.dequeueReusableCell(withIdentifier: "Invoice") as! InvoiceCell
 
-let legacy = try! JSONDecoder().decode(T.self, from: data) // swiftlint:disable:this force_try
+let seed = try! Data(contentsOf: seedURL) // swiftlint:disable:this force_try
 
+func bounds() -> (Double, Double, Double, Double, Double) { (0, 0, 0, 0, 0) }
 // swiftlint:disable:previous large_tuple
-```
 
-Disable for a region:
-
-```swift
 // swiftlint:disable cyclomatic_complexity
-func complexRouter(...) { ... }
+func open(_ link: DeepLink) {
+    // long switch over link kinds
+}
 // swiftlint:enable cyclomatic_complexity
 ```
 
-Disable all rules (use sparingly):
+`// swiftlint:disable all` with a matching `// swiftlint:enable all` turns off
+everything in between. Keep it for generated or legacy code.
 
-```swift
-// swiftlint:disable all
-// ... generated or legacy code ...
-// swiftlint:enable all
-```
+House rules:
 
-**Policy:**
-- Prefer targeted single-rule suppressions over `all`.
-- Always re-enable after the region ends.
-- For generated code, prefer `excluded` paths in `.swiftlint.yml` over inline suppressions.
-- For test targets with different tolerance, use a child configuration (see [Multiple Configurations](#multiple-configurations)).
+- One named rule beats `all`.
+- Close every region with `enable`.
+- Generated sources belong in `excluded`, not behind inline comments.
+- Tests that tolerate more get their own child configuration.
 
-For full suppression syntax, see [references/rules-suppressions-and-baselines.md](references/rules-suppressions-and-baselines.md).
+Syntax details and review policy: [rules and suppressions](references/rules-suppressions-and-baselines.md).
 
 ## Baselines
 
-Baselines let you adopt SwiftLint in an existing codebase without fixing every legacy violation first.
+A baseline lets you switch the linter on today without first fixing years of
+old violations.
 
-**Create a baseline:**
-
-```sh
-swiftlint --write-baseline .swiftlint.baseline
-```
-
-This records all current violations. Future runs compare against this baseline and only report new violations.
-
-**Use the baseline:**
-
-```sh
-swiftlint --baseline .swiftlint.baseline
+```bash
+swiftlint --write-baseline .swiftlint.baseline   # snapshot every current violation
+swiftlint --baseline .swiftlint.baseline         # report only violations not in the snapshot
 ```
 
-In CI, pass `--baseline` so only new violations fail the build. Burn down the baseline over time by fixing legacy violations and regenerating.
-
-For baseline workflows and rollout strategy, see [references/rules-suppressions-and-baselines.md](references/rules-suppressions-and-baselines.md).
+In CI always pass `--baseline`, so only new problems fail the job. Fix old
+violations, regenerate the file, and commit the smaller version.
 
 ## Autocorrect
 
-SwiftLint can fix some violations automatically:
-
-```sh
-swiftlint --fix
-# or the legacy alias:
-swiftlint --autocorrect
-```
+`swiftlint --fix` rewrites what it can; `--autocorrect` is the older spelling
+of the same thing.
 
-**Warnings:**
+- Never put `--fix` in a build phase that runs before compiling. It edits the
+  files being built on every build, which turns builds into an unpredictable
+  edit loop and can hide the real problem.
+- Run it by hand or in a dedicated CI job and read the diff.
+- Only some rules can correct themselves. The "Correctable" column of
+  `swiftlint rules` shows which.
+- Commit or stash your work first.
 
-- **Never run `--fix` as a pre-compile build phase.** Auto-fixes modify source files. If run automatically on every build, this creates an unpredictable edit-build loop and can mask real issues.
-- Run `--fix` manually or in a dedicated CI step, then review the diff.
-- Not all rules support autocorrect. Check `swiftlint rules`  -  the "Correctable" column shows which rules can auto-fix.
-- Always commit or stash before running `--fix`.
+## CI
 
-## CI Integration
-
-CI is the primary enforcement surface. A CI check ensures no one merges code that increases the violation count.
-
-**Recommended CI pattern:**
+CI is where the rules actually bite: a merge that raises the violation count
+should be blocked.
 
 ```yaml
-# GitHub Actions example
 - name: Lint
   run: |
     brew install swiftlint
-    swiftlint --strict --reporter sarif > swiftlint.sarif
+    swiftlint lint --reporter sarif --strict > lint.sarif
 ```
 
-Key CI options:
-
-| Flag | Effect |
-|------|--------|
-| `--strict` | Exits non-zero on warnings (not just errors) |
-| `--reporter sarif` | GitHub Advanced Security compatible output |
-| `--reporter json` | Machine-readable output |
-| `--reporter checkstyle` | Jenkins/SonarQube compatible |
-| `--baseline .swiftlint.baseline` | Only fail on new violations |
-
-For SARIF upload to GitHub code scanning, add `github/codeql-action/upload-sarif` after the lint step.
-
-For full CI recipes and reporter details, see [references/plugins-run-scripts-and-integrations.md](references/plugins-run-scripts-and-integrations.md).
-
-## Integration Decision Tree
-
-Choose how to run SwiftLint based on project shape:
-
-| Scenario | Recommended integration |
-|----------|------------------------|
-| SwiftPM package or Xcode project with `Package.swift` | Build tool plugin via `SwiftLintPlugins` |
-| SwiftPM project needing CLI flags (`--fix`, `--baseline`) | Command plugin: `swift package plugin swiftlint` |
-| Xcode project without SwiftPM, team uses Homebrew | Run script build phase |
-| CI/CD pipeline | Homebrew or Docker install, run `swiftlint` directly |
-| Pre-commit hook | Homebrew install + `.pre-commit-config.yaml` or git hook script |
+- `--strict`: any warning makes the exit code non-zero.
+- `--reporter sarif`: feeds code scanning (GitHub Advanced Security).
+- `--reporter json`: for your own tooling.
+- `--reporter checkstyle`: for Jenkins or SonarQube.
+- `--baseline .swiftlint.baseline`: fail only on new violations.
 
-The build tool plugin is preferred for local development because it requires no PATH configuration, pins the SwiftLint version via package resolution, and runs automatically on build.
+After the lint step, upload the SARIF file with
+`github/codeql-action/upload-sarif`. More recipes (GitLab, Bitrise, Docker,
+annotations): [integrations guide](references/plugins-run-scripts-and-integrations.md).
 
-For detailed setup instructions for each integration, see [references/plugins-run-scripts-and-integrations.md](references/plugins-run-scripts-and-integrations.md).
+## Several configurations
 
-## Multiple Configurations
-
-SwiftLint supports layered configuration files. A `.swiftlint.yml` in a subdirectory inherits from and overrides the parent config.
-
-Common patterns:
-
-- **Relaxed test config**: place a `.swiftlint.yml` in `Tests/` that disables `force_unwrapping` and raises `file_length`
-- **Strict module config**: place a stricter `.swiftlint.yml` in a shared module directory
-- **Remote config**: use `parent_config` with an HTTPS URL to pull a shared team config (caching supported)
+- A nested `.swiftlint.yml` starts from its parent's settings and changes
+  only what it states.
+- Typical uses: a looser `Tests/.swiftlint.yml` that disables
+  `force_unwrapping` and raises `file_length`; a tighter file in a shared
+  module; a `parent_config` pointing at an HTTPS URL for an organisation-wide
+  base, which SwiftLint caches.
 
 ```yaml
-# Tests/.swiftlint.yml  -  child config
+# Tests/.swiftlint.yml
 disabled_rules:
-  - force_unwrapping
   - force_try
-
+  - force_unwrapping
 file_length:
   warning: 800
 ```
 
-You can also pass multiple configs on the CLI:
-
-```sh
-swiftlint --config .swiftlint.yml --config .swiftlint-extra.yml
-```
-
-Later configs override earlier ones for overlapping keys.
-
-For nested config resolution, remote configs, and CLI multi-config details, see [references/adoption-and-configuration.md](references/adoption-and-configuration.md).
-
-## Common Mistakes
-
-1. **Running `--fix` in a build phase.** Auto-fixing on every build creates unpredictable source modifications. Run `--fix` manually.
-
-2. **Using `only_rules` without understanding the implication.** This disables all rules except those listed. Most teams should use `disabled_rules` + `opt_in_rules` instead.
-
-3. **Suppressing with `// swiftlint:disable all` and forgetting to re-enable.** This silently disables all linting for the rest of the file.
-
-4. **Not pinning the SwiftLint version.** Different versions have different default rules. Use the build tool plugin (version pinned via SPM) or pin in your `Brewfile` / CI config.
-
-5. **Excluding too broadly.** Excluding `Tests/` entirely means test code gets no linting. Use a child config with relaxed rules instead.
-
-6. **Ignoring the toolchain mismatch.** SwiftLint must be built with (or compatible with) the same Swift toolchain used to compile your project. Mismatches cause parsing errors. See [references/plugins-run-scripts-and-integrations.md](references/plugins-run-scripts-and-integrations.md) for multi-toolchain guidance.
-
-7. **Adopting too many opt-in rules at once in a large codebase.** This creates an overwhelming number of violations. Add rules incrementally and use baselines.
-
-8. **Not configuring `included` paths.** Without `included`, SwiftLint scans the working directory recursively, which may pick up vendored or generated code.
-
-## Review Checklist
-
-- [ ] `.swiftlint.yml` exists at the project root with explicit `included`/`excluded` paths
-- [ ] SwiftLint version is pinned (via SPM plugin resolution, Brewfile, or CI config)
-- [ ] Build tool plugin is enabled for each target that should be linted
-- [ ] CI runs `swiftlint --strict` (or with `--baseline` for incremental adoption)
-- [ ] No `--fix` / `--autocorrect` in build phases
-- [ ] Inline suppressions target specific rules, not `all`
-- [ ] Inline suppressions include a comment explaining why
-- [ ] Test targets have appropriate config (relaxed rules via child config, not excluded entirely)
-- [ ] Autocorrect changes are reviewed in a separate commit
-- [ ] New opt-in rules are added one at a time with team consensus
-
-## References
-
-- [references/adoption-and-configuration.md](references/adoption-and-configuration.md)  -  Installation paths, `.swiftlint.yml` deep dive, severity tuning, environment variables, nested/remote configs, rollout strategy
-- [references/plugins-run-scripts-and-integrations.md](references/plugins-run-scripts-and-integrations.md)  -  Build tool plugin, command plugin, run scripts, CI recipes, multi-toolchain guidance, VS Code, Fastlane, Docker, pre-commit
-- [references/rules-suppressions-and-baselines.md](references/rules-suppressions-and-baselines.md)  -  Default vs opt-in vs analyzer rules, suppression syntax, baseline workflows, false-positive handling
-- [references/rule-reference.md](references/rule-reference.md)  -  Bundled exhaustive rule index for local lookup; verify current details with `swiftlint rules` or the official rule directory
-- [references/custom-rules-and-analyze.md](references/custom-rules-and-analyze.md)  -  Regex custom rules, Swift custom rules (brief), `swiftlint analyze`, compiler-log workflow
-- [SwiftLint documentation](https://realm.github.io/SwiftLint/)  -  Official docs
-- [SwiftLint rule directory](https://realm.github.io/SwiftLint/rule-directory.html)  -  Full categorized rule list
-- [SimplyDanny/SwiftLintPlugins](https://github.com/SimplyDanny/SwiftLintPlugins)  -  Recommended plugin package
+- On the command line, `swiftlint --config .swiftlint.yml --config .swiftlint-extra.yml`
+  merges both; the later file wins where keys overlap.
+
+## Mistakes that keep showing up
+
+| Mistake | Fix |
+|---|---|
+| `--fix` wired into a build phase | Run it manually or in CI and review the diff |
+| `only_rules` chosen without realising it turns every other rule off | Use `disabled_rules` plus `opt_in_rules` |
+| `swiftlint:disable all` with no `enable` | The rest of the file silently stops being linted; always close the region |
+| Linter version not pinned | Default rule sets change between releases; pin through the SwiftPM plugin, a Brewfile or the CI config |
+| `Tests/` excluded wholesale | Give tests a relaxed child config instead |
+| SwiftLint built for a different Swift toolchain | Parse errors; match the project's toolchain |
+| A dozen opt-in rules enabled at once on a big codebase | Add them one at a time, with a baseline |
+| No `included` paths | SwiftLint crawls the whole working directory, vendored and generated code included |
+
+## Review checklist
+
+- [ ] A root `.swiftlint.yml` exists with explicit `included` and `excluded`.
+- [ ] The SwiftLint version is fixed, by SwiftPM resolution of the plugin, a
+      Brewfile entry or the CI job definition.
+- [ ] The build tool plugin is attached to every target that should be linted.
+- [ ] CI runs `swiftlint --strict`, with `--baseline` while adoption is in progress.
+- [ ] No build phase runs `--fix` or `--autocorrect`.
+- [ ] Inline suppressions name specific rules, never `all`.
+- [ ] Each inline suppression carries a short reason.
+- [ ] Test targets use a relaxed child config rather than being excluded.
+- [ ] Autocorrect output lands in its own commit and is reviewed.
+- [ ] Each new opt-in rule arrives in its own change, after the team agrees.