The AI coding setup for native iOS apps.

Set up guardrails for AI coding agents in this Swift repository: lint rules that catch what agents get wrong, a dead-code check, the compiler at its strictest, all enforced so that nothing can bypass them, and a ratchet if the codebase already has violations. Do the work yourself. Ask me before changing CI, the Swift language version, deleting files, or making a call only I can make. Commit nothing until I have seen your report.

Principles
- Use existing, maintained tools: SwiftLint, Apple's swift-format, Periphery and the compiler's own checks. Do not write Swift-based custom SwiftLint rules; a regex custom rule is fine for a ban.
- A rule is worth enforcing only if it catches something real in this codebase. A style preference that fights the code's existing style is not.
- Every check fails the build. No warnings: a warning nobody has to act on is noise. Nothing can be switched off from inside the code.
- Existing violations are handled by a ratchet, never by leaving a useful rule off or at warning.
- One lint step in CI, one config file per tool, each rule from one source.

1. Survey
- Identify the project: Xcode project or workspace, Swift Package Manager, or both; targets and platforms; Swift tools version and language mode; how dependencies arrive; the CI runner (a macOS runner is needed to build).
- Check what already exists: SwiftLint (version, config, how it runs: build phase, plugin, CI), swift-format or SwiftFormat, Periphery, pre-commit hooks, CI steps.
- Check the compiler settings on every target: warnings as errors, the Swift language mode, strict concurrency checking.
- Time a clean build and the current lint run.
- List every way a check can be bypassed today: `// swiftlint:disable` comments, rules at warning with strict off, lint that runs only in Xcode and not in CI, a build phase that lints but does not fail, targets the lint config excludes, CI steps allowed to fail.

2. Measure without changing the repo
Use a scratch config file (swiftlint lint --config scratch.yml --reporter json). Do not edit the real configs yet. Confirm the installed version's flags with swiftlint lint --help before relying on one.
Candidates:
- SwiftLint's default rules.
- Opt-in rules that catch real bugs rather than style, for example: force_unwrapping, implicitly_unwrapped_optional, unowned_variable_capture, weak_delegate, overridden_super_call, prohibited_super_call, fatal_error_message, empty_count, first_where, contains_over_filter_count. Read each rule's description on the SwiftLint rule directory before proposing it; skip pure formatting rules, which swift-format owns.
- Analyzer rules unused_import and unused_declaration only if Periphery is not chosen: they need a compiler log (swiftlint analyze --compiler-log-path) and overlap with it.
- A ban on disable comments: a custom_rules entry whose regex matches swiftlint:disable in comments, at error. Check whether a disable comment can switch off this rule itself; if it can, also add the same pattern to a grep that runs in CI.
- swift-format in lint mode (swift format lint --strict) with the repo's formatting settings, so formatting is one tool, not SwiftLint rules too.
- Periphery for unused code: periphery scan. Check periphery scan --help for an option that fails the run on results and for a baseline; note which exist.
- Compiler: warnings as errors (SWIFT_TREAT_WARNINGS_AS_ERRORS in Xcode, -warnings-as-errors for a package), and strict concurrency checking or the Swift 6 language mode. Measure how many warnings and errors each would produce; do not change them yet.
For each rule or setting report: violations, files, how many autocorrect, one example. Time the runs.

3. Decide
Put each rule in one of two groups:
- Enforce: it catches real problems here, such as crashes, retain cycles, data races, unsafe unwraps, dead code.
- Off: style that conflicts with this codebase's conventions, false positives, or a duplicate of another tool. Each one gets a one-line reason in the config.
A rule with zero violations stays enforced: it costs nothing and catches the first regression.
The Swift 6 language mode and strict concurrency can be a large migration. Treat them separately: say what turning them on would take, and let me decide.
Then, from the total violations of the rules you enforce:
- Few (roughly under 50, fixable in a day): fix them now. No ratchet.
- More: ratchet. Enforce every chosen rule at error and baseline the existing violations.
Show me the table and your decision before changing anything.

4. Install, after I agree
- One .swiftlint.yml at the root, covering every target that has code. List every disabled rule with its reason. Set strict: true so warnings fail.
- If ratcheting SwiftLint: write the baseline once (write_baseline in the config, or the matching flag), commit it, and point baseline at it. From then on new violations fail. SwiftLint does not fail on a baseline entry that no longer occurs, so add a CI check that regenerates the baseline and fails if it differs from the committed one, then commit the smaller file whenever it shrinks. Never regenerate it to absorb new violations.
- If ratcheting Periphery or compiler warnings and the tool has no baseline: commit the current count and fail CI if it rises; lower the number as it falls.
- swift-format: a .swift-format file with the repo's settings; CI runs swift format lint --strict over all sources.
- Turn on warnings as errors for every target now if the count is zero or fixed in this change; otherwise ratchet the count.
- Pre-commit: a committed hook (a script in the repo, enabled by a documented one-line setup command) that runs swift-format lint and SwiftLint on the staged Swift files with the same configs as CI, and shows its output. CI runs everything over the whole codebase on a macOS runner. No CI step may be allowed to fail.
- Before running autocorrect across the codebase, show me how many files it would change.

5. Verify
- For each enforced rule, plant a violation in a scratch file, confirm the run fails with a message that says what to do instead, then remove it. Include a planted swiftlint:disable comment.
- If ratcheting, confirm that a new violation fails, that fixing a baselined one fails CI until the committed baseline shrinks, and that a pre-commit run on one file passes.
- Report lint and build time before and after.

6. Write the decisions into a "## Guardrails" section of AGENTS.md
The configs are the list of rules, and each disabled rule's reason sits beside it there; do not restate them. The section holds what no config can: baselines or none, disable comments or none, the compiler settings chosen and the Swift 6 migration plan if one was deferred, triggers that would reopen a decision, the burn-down order with counts if ratcheting, rules considered and declined with the reason and what would change it, and a "Last reviewed: <date> at <commit>" line. Keep it under about 40 lines.

Report
The survey, the rule table with decisions, ratchet or not with counts, the compiler settings before and after, lint and build time before and after, the files changed, and anything you could not do.