fix: use consistent SwiftLint rules for local CLI checks

[steipete]

CLI-local SwiftLint pinned an obsolete tool version and disabled checks that the root CI configuration enforces. Both entry points now inherit the same unchanged rule policy from a path-free configuration. Their scan scopes remain separate, because SwiftLint merges parent include paths.

Validation: isolated Codex review found no actionable P0–P2 findings. Root and CLI-local lint pass with SwiftLint 0.65.1. Live executable probes inserted a 160-statement function: CLI-local lint reported it when it was inside CLI, ignored the same probe in Core, and root lint reported the Core violation. All temporary probe files were removed. No runtime behavior or public contract changes.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[cursor]

PR Summary

Low Risk
Tooling-only YAML refactor; no runtime or API changes, though CLI developers may see new lint findings previously suppressed locally.

Overview
Centralizes SwiftLint rule policy in a new shared .swiftlint-rules.yml (analyzer/opt-in/disabled rules, Peekaboo custom AX rules, and length/complexity thresholds).

Root .swiftlint.yml and Apps/CLI/.swiftlint.yml now inherit that file via parent_config and only define include/exclude scan paths. The CLI config drops its local SwiftLint version pin and its long list of disabled rules, so local CLI lint should match the same enforcement as the main repo config (while each config still lints its own paths).

^{Reviewed by Cursor Bugbot for commit 407161a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 12, 2026, 8:49 PM ET / September 13, 2026, 00:49 UTC.

ClawSweeper review

What this changes

Both local SwiftLint entry points inherit shared rule definitions while retaining their separate scan paths.

Merge readiness

✅ Ready for maintainer review

The change remains useful: current main and v4.3.4 retain divergent CLI-local rules. No actionable patch defect was found, and this collaborator-authored PR is protected from automated closure.

Priority: P3
Reviewed head: 407161a47c1c09b33f052e7ea56ebba3f421635f

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused consolidation preserves root policy and scan boundaries, with relevant reported probes and no actionable findings.
Proof confidence	🌊 off-meta tidepool	Not applicable: The collaborator-authored tooling change is exempt from the external-contributor proof gate; its complete body additionally reports SwiftLint 0.65.1 exercising both configurations and correctly detecting CLI/Core probes within their respective scopes.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The collaborator-authored tooling change is exempt from the external-contributor proof gate; its complete body additionally reports SwiftLint 0.65.1 exercising both configurations and correctly detecting CLI/Core probes within their respective scopes.
Evidence reviewed	7 items	Complete introduced change: The pinned base-to-head diff changes only three lint configurations. Root rule definitions move unchanged apart from whitespace; both consuming configurations retain their include/exclude lists. Current main still has divergent CLI policy: The main-branch CLI configuration pins SwiftLint 0.62.2 and separately disables length, complexity, and other checks; the requested consolidation is absent. Latest release comparison: The supplied v4.3.4 release commit also contains the separate CLI rule definitions and version pin.
Findings	None	None.
Security	None	None.

How this fits together

SwiftLint checks Peekaboo’s Swift source for coding-rule violations. Root and CLI-local configurations select files and rules; CI inherits the root configuration with additional existing overrides.

flowchart TD
  A[Swift source files] --> B[Root local checks]
  A --> C[CLI local checks]
  D[Shared rule policy] --> B
  D --> C
  B --> E[CI configuration overrides]
  B --> F[Lint diagnostics]
  C --> F
  E --> F

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Maintain one shared local lint policy, separate scan scopes, and the existing explicit CI exceptions.

Do we have a high-confidence way to reproduce the issue?

Not applicable to a runtime bug: source inspection directly confirms the separate local policies, and the PR reports executable lint probes exercising enforcement and scan isolation.

Is this the best way to solve the issue?

Yes. Sharing the existing root rules through a parent without scan paths removes duplication while preserving each local entry point’s scope and CI overrides.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 4338bc31e6cd.

Labels

Label changes:

• add P3: This is a scoped developer-tooling consistency improvement with no application runtime change.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The collaborator-authored tooling change is exempt from the external-contributor proof gate; its complete body additionally reports SwiftLint 0.65.1 exercising both configurations and correctly detecting CLI/Core probes within their respective scopes.

Label justifications:

• P3: This is a scoped developer-tooling consistency improvement with no application runtime change.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The collaborator-authored tooling change is exempt from the external-contributor proof gate; its complete body additionally reports SwiftLint 0.65.1 exercising both configurations and correctly detecting CLI/Core probes within their respective scopes.

Evidence

What I checked:

• Complete introduced change: The pinned base-to-head diff changes only three lint configurations. Root rule definitions move unchanged apart from whitespace; both consuming configurations retain their include/exclude lists. (.swiftlint-rules.yml:1, 407161a47c1c)
• Current main still has divergent CLI policy: The main-branch CLI configuration pins SwiftLint 0.62.2 and separately disables length, complexity, and other checks; the requested consolidation is absent. (Apps/CLI/.swiftlint.yml:6, 4338bc31e6cd)
• Latest release comparison: The supplied v4.3.4 release commit also contains the separate CLI rule definitions and version pin. (Apps/CLI/.swiftlint.yml:6, 59a805b253c1)
• CI overrides remain intentional and unchanged: The workflow runs .swiftlint-ci.yml, which inherits the root config and retains its own disabled rules. The patch aligns local entry points; it does not eliminate CI-specific exceptions. (.swiftlint-ci.yml:12, 407161a47c1c)
• Dependency configuration contract: The introduced parent_config references directly depend on SwiftLint’s configuration merger. Its official documentation supports relative parent paths and explains that parent and child scan paths merge, supporting the path-free shared configuration: https://github.com/realm/SwiftLint#childparent-configs-locally. (README.md)
• Reported validation and discussion: The complete captured PR body reports SwiftLint 0.65.1 passing both local entry points and executable probes detecting a long function only within the intended scan scope. The supplied SwiftLint CI check passed. These are contributor-reported observations; this review did not execute lint or probes. (407161a47c1c)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.