chore: Update SundialKit.yml

[leogdion]

No description provided.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a3d8a9da-617f-47d5-9183-9f43b05a3e1c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch atleast-v1.0.0-beta.4

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[leogdion]

update swift-format and SwiftLint rules

[leogdion]

these need to be updated to use the new swift extension

[leogdion]

comment these out

[leogdion]

remove this for now

[leogdion]

comment this out for now

[leogdion]

comment this out

[leogdion]

make all matrices fail fast false temporarily

[leogdion]

keep Xcode 16.4 runs

[claude]

PR Review: CI/CD & Tooling Configuration Update

This is a solid infrastructure modernization. Here's my feedback organized by severity:

---

Potential Issues

actions/checkout@v6 may not exist
The PR bumps actions/checkout to @v6 across SundialKit.yml, but the latest stable release is @v4. sundial-demo.yml still uses @v4, creating an inconsistency. If v6 doesn't exist this will break every CI job. Recommend pinning to @v4 until v6 is actually released.

Same concern applies to codecov/codecov-action@v6 and sersoft-gmbh/swift-coverage-action@v5 — verify these versions exist before merging.

Release tags run a reduced test matrix
The configure job only sets full-matrix=true for refs/heads/main pushes and PRs. Tag pushes (v*.*.*) fall through to the reduced matrix, skipping build-macos-full (iOS, watchOS, tvOS, visionOS) and build-android. For a release cut this seems like the wrong tradeoff — you probably want the full suite on release tags.

# In configure job, consider:
if [[ "${{ github.ref }}" == "refs/heads/main" || "${{ github.event_name }}" == "pull_request" || "${{ github.ref }}" == refs/tags/* ]]; then

LINT_MODE: STRICT silently removed
The lint job previously set LINT_MODE: STRICT. It's now removed, so CI runs in non-strict mode unless lint.sh defaults to strict. If CI is supposed to enforce strict linting this is a regression. Worth making this explicit either way.

---

Observations / Minor Items

Commented-out code is noisy
There are substantial commented-out blocks: the entire Windows build job, WASM type matrix, and some exclude rules. If these are planned for a follow-up PR, that's fine, but consider tracking them as GitHub issues instead so the workflow stays readable.

.swift-format rule relaxations
Several rules were toggled to less strict:

• AllPublicDeclarationsHaveDocumentation: false — removes the enforcement of docs on public API
• ValidateDocumentationComments: false — stops checking doc comment correctness
• NoLeadingUnderscores: false — permits _-prefixed names

If these changes are intentional (e.g. the leading underscore change is useful for actor isolation patterns), they're reasonable. But the doc comment relaxations may allow API documentation to degrade over time unless enforced elsewhere.

.swiftlint.yml line_length is aggressive
Setting both warning and error thresholds to 90 gives zero tolerance — the first violation immediately errors. Previous 108/200 allowed warnings before hard failures. Consider a small gap like 90/110 for a better developer experience.

one_declaration_per_file enabled
This is a potentially large-scope change. Any existing file with more than one type/enum/struct will now fail linting. If the codebase is already compliant this is fine, but worth confirming before the rule lands.

function_body_length tightened to 35/50
Down from 50/76. This is quite strict — async/await patterns and switch statements can burn through lines quickly. Worth running the linter locally against the full codebase to see how many new violations this introduces.

---

Positive Changes

• Dynamic matrix via configure job is a clean pattern for avoiding wasted CI minutes on feature branches
• concurrency group with cancel-in-progress is a good addition
• Splitting build-macos into fast and full variants is sensible
• Android support is a nice addition
• Extension rename sswg.swift-lang → swift-server.swift is the correct current extension ID
• Removing the hardcoded mise version and duplicate Swift 6.2 matrix entry are good cleanups
• !cancelled() && needs.configure.result == 'success' guards are more robust than the old ci skip pattern

---

Summary: The architecture of this workflow update is good. The main blocker to address is verifying actions/checkout@v6 exists (or downgrading to @v4), and deciding whether release tags should run the full matrix.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.20%. Comparing base (02a6830) to head (83e7ef3).

Additional details and impacted files

@@               Coverage Diff               @@
##           v2.0.0-alpha.2      #78   +/-   ##
===============================================
  Coverage           65.20%   65.20%           
===============================================
  Files                  31       31           
  Lines                 526      526           
===============================================
  Hits                  343      343           
  Misses                183      183           

Flag	Coverage Δ
spm	66.60% <ø> (ø)
swift-6.1	65.59% <ø> (?)
swift-6.1-jammy	?
swift-6.1-noble	?
swift-6.2	65.59% <ø> (?)
swift-6.2-jammy	?
swift-6.2-jammy-nightly	?
swift-6.2-noble	?
swift-6.2-noble-nightly	?
swift-6.3	65.59% <ø> (?)
ubuntu	65.59% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

PR Review: CI/CD & Tooling Overhaul

This is a solid infrastructure upgrade overall. Here are observations organized by area:

---

✅ Positives

• Concurrency groups with cancel-in-progress: true is a great addition — prevents redundant runs on rapid pushes.
• Dynamic matrix via configure job cleanly separates full vs. fast builds for PRs/main vs. feature tags.
• Conditional coverage upload (if: steps.build.outputs.contains-code-coverage == 'true') is much cleaner than always running it.
• Expanding to Windows and Android targets broadens platform coverage nicely.
• paths-ignore for docs/markdown avoids wasteful CI runs on documentation-only changes.

---

Issues & Concerns

CI Workflow (SundialKit.yml)

1. LINT_MODE: STRICT removed from lint job

The lint job previously had LINT_MODE: STRICT set explicitly. Scripts/lint.sh checks for this env var to enable strict mode. Without it, CI lint will run in normal mode instead of strict, which is a quality regression. Per CLAUDE.md, strict mode is the CI standard.

# Should restore:
env:
  LINT_MODE: STRICT

2. Feature branch push CI is now opt-in via PR only

Previously, pushes to any non-*WIP branch triggered CI. Now, only pushes to main/tags and PRs against main trigger builds. Pushes to feature branches (e.g., feature/something) with no open PR will get no CI. This means broken commits can accumulate undetected until a PR is opened.

Consider adding a broader branches pattern or a workflow_dispatch trigger to catch this.

3. Commented-out type matrix in build-ubuntu

# type: ${{ fromJSON(needs.configure.outputs.ubuntu-type) }}
# exclude:
#   - swift: {version: "6.1"}
#     type: wasm

This looks like incomplete/WIP work left in. Either enable wasm builds or remove the commented-out block before merging.

4. actions/checkout@v6 vs @v4 inconsistency

sundial-demo.yml still uses actions/checkout@v4 in several places while SundialKit.yml moves to @v6. This inconsistency should be resolved — either update all references or pin to the same version intentionally.

5. Windows coverage upload missing files: parameter

The Ubuntu job includes files: ${{ join(fromJSON(steps.coverage-files.outputs.files), ',') }} for precise file targeting. The Windows coverage upload omits this, relying on auto-discovery which may be less reliable on Windows paths.

6. Android only tests Swift 6.2 and 6.3

swift:
  - version: "6.2"
  - version: "6.3"

The library targets Swift 6.1+, but Android builds skip 6.1 testing. This could miss compatibility issues specific to Swift 6.1 on Android.

7. Missing fail_ci_if_error: true on macOS coverage uploads

Ubuntu job has fail_ci_if_error: true but both build-macos and build-macos-full omit it. Codecov failures would silently pass on macOS.

8. brightdigit/swift-build@v1 (floating tag) vs pinned versions

Using @v1 instead of a pinned version like @v1.4.0 means the action could silently change behavior on the next v1.x release. sundial-demo.yml uses the more specific @v1.5.2. Consider using a pinned version or at minimum documenting the intentional use of the floating tag.

---

.swift-format Changes

9. AllPublicDeclarationsHaveDocumentation: false (was true)

Disabling public API documentation enforcement alongside ValidateDocumentationComments: false is a meaningful quality step down. If this is intentional (e.g., docs are enforced elsewhere), it's fine — but worth calling out explicitly in the PR description.

10. NoLeadingUnderscores: false (was true)

Allowing _-prefixed names goes against Swift API Design Guidelines. If there's a specific case driving this (e.g., generated code or async underscore patterns), it's worth documenting why.

---

.swiftlint.yml Changes

11. todo added to disabled_rules

TODO comments will no longer be flagged. For a library aiming for production quality, TODO warnings in CI serve as a useful reminder. Consider using warning_threshold on the todo rule instead of disabling it entirely.

12. line_length warning == error (both 90)

Setting both warning and error to the same value (- 90 / - 90) removes the warning grace period. Any line over 90 chars immediately fails. This is unusually strict and may cause friction. Consider - 90 / - 110 or similar to give a buffer.

13. cyclomatic_complexity error threshold lowered: 12 → 8

This is a fairly aggressive tightening. Ensure existing code doesn't already exceed 8 before merging, or existing CI will break immediately.

---

Minor Nits

• The configure job's if condition only checks head_commit.message for ci skip on non-PR events, which is correct — but documenting this intent in a comment would help future maintainers.
• build-macos now only runs with Xcode_26.4.app. If that runner image doesn't have that Xcode version installed, it will fail silently. The full matrix job handles older versions, which is a good split.

---

Summary

The architecture of the workflow (dynamic matrix, conditional full builds, platform expansion) is a significant improvement. The main concerns worth addressing before merging are: restoring LINT_MODE: STRICT in CI, resolving the commented-out wasm matrix, and the checkout action version inconsistency. The .swift-format changes that disable documentation enforcement deserve an explicit call-out in the PR description since they're a notable policy change.