V1.0.0-alpha.1

[leogdion]

Summary by CodeRabbit

• New Features

  • Added Combine-based network monitoring with reactive publishers for path status, reachability, and ping capabilities.
  • Added connectivity observer for cross-device messaging with reactive state management and type-safe message handling.

• Documentation

  • Added comprehensive README with usage examples and architecture overview.
  • Added developer guide and DocC documentation.

• Chores

  • Set up dev containers for Swift 6.1, 6.2, and nightly builds.
  • Configured GitHub Actions workflows for CI/CD, code analysis, and code review.
  • Established code style and linting standards with format and lint tools.
  • Added build scripts and project configuration.

• Tests

  • Added initial test structure.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This PR establishes a new Swift package called SundialKitCombine with complete project infrastructure. It includes development container configurations, GitHub Actions CI/CD workflows, linting and formatting tooling, Swift package manifest, Combine-based observer modules for network and connectivity monitoring, automation scripts, and comprehensive documentation.

Changes

Cohort / File(s)	Summary
Development Containers \.devcontainer/devcontainer.json`, `.devcontainer/swift-6.1/devcontainer.json`, `.devcontainer/swift-6.1-nightly/devcontainer.json`, `.devcontainer/swift-6.2/devcontainer.json`, `.devcontainer/swift-6.2-nightly/devcontainer.json``	Introduces Swift dev container configurations for versions 6.1, 6.2, and nightly builds, each with common-utils and git features, git safe.directory configuration, elevated runtime capabilities, and VSCode LLDB and Swift extension customizations.
CI/CD Workflows \.github/workflows/SundialKitCombine.yml`, `.github/workflows/claude-code-review.yml`, `.github/workflows/claude.yml`, `.github/workflows/codeql.yml``	Adds GitHub Actions workflows for multi-environment Swift builds (Ubuntu/macOS with coverage and Codecov), Claude-based code review, CodeQL security analysis, and interactive Claude code assistance on comments.
Linting & Formatting Config \.swift-format`, `.swiftlint.yml`, `.periphery.yml``	Establishes SwiftFormat, SwiftLint, and Periphery configurations with rules for indentation, complexity limits, naming conventions, visibility enforcement, and dead code detection.
Project Manifests Package.swift, project.yml, \.mise.toml``	Defines Swift package with SundialKit dependency, targets, and compiler settings; Xcode project configuration with lint target; and mise tool versions for swift-format, swiftlint, and periphery.
Package Configuration \.gitignore`, `.spi.yml`, Package.resolved``	Adds comprehensive gitignore patterns, Swift Package Index documentation target, and package dependency lock with SundialKit 2.0.0-alpha.1.
Core Source Code Sources/SundialKitCombine/ConnectivityObserver.swift, Sources/SundialKitCombine/NetworkObserver.swift, Sources/SundialKitCombine/SundialLogger.swift	Introduces MainActor-isolated Combine observers for connectivity (with session delegates, publishers, and state tracking) and network monitoring (with path status and ping capability); adds platform-aware logging utility.
ConnectivityObserver Extensions Sources/SundialKitCombine/ConnectivityObserver+Methods.swift, Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift, Sources/SundialKitCombine/ConnectivityObserver+SessionLifecycle.swift, Sources/SundialKitCombine/ConnectivityObserver+StateChanges.swift	Provides initializers, activate/send methods, session delegate handlers for message/context/data reception, lifecycle callbacks, and state change handlers for reachability and companion app states.
Session Extensions Sources/SundialKitCombine/ConnectivitySession.swift	Adds async extension method to wrap callback-based binary message sending into async/await pattern.
Tests Tests/SundialKitCombineTests/SundialKitCombineTests.swift	Adds minimal XCTest placeholder with testable module import.
Automation Scripts Scripts/ensure-remote-deps.sh, Scripts/header.sh, Scripts/lint.sh, Scripts/preview-docs.sh	Implements scripts for enforcing remote package dependencies, adding copyright headers, orchestrating linting/formatting/build, and previewing DocC documentation with auto-rebuild and watcher support.
Documentation README.md, Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md, CLAUDE.md, LICENSE	Provides project overview, usage examples, architecture details, developer guidance, and MIT license.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ConnectivityObserver
    participant Session as ConnectivitySession
    participant Combine as Combine Publishers

    User->>ConnectivityObserver: init(session, messageDecoder?)
    User->>ConnectivityObserver: activate()
    ConnectivityObserver->>Session: setDelegate(self)
    
    rect rgba(200, 220, 255, 0.3)
        Note over Session,Combine: Activation Flow
        Session->>ConnectivityObserver: activationDidCompleteWith(state, error?)
        ConnectivityObserver->>ConnectivityObserver: Update state publishers
        ConnectivityObserver->>Combine: emit activationCompleted
    end
    
    rect rgba(220, 200, 255, 0.3)
        Note over Session,Combine: Message Reception Flow
        Session->>ConnectivityObserver: didReceiveMessage(message, replyHandler)
        ConnectivityObserver->>Combine: emit messageReceived
        alt Decoder Available
            ConnectivityObserver->>ConnectivityObserver: Decode message
            ConnectivityObserver->>Combine: emit typedMessageReceived
        end
    end
    
    rect rgba(220, 255, 200, 0.3)
        Note over User,Combine: Send Flow
        User->>ConnectivityObserver: send(messagable, options)
        ConnectivityObserver->>Session: sendMessageData(binary)
        Session-->>ConnectivityObserver: Result
        ConnectivityObserver->>Combine: emit sendResult
    end

Loading

sequenceDiagram
    participant User
    participant NetworkObserver
    participant Monitor as PathMonitor
    participant Ping as PingType
    participant Main as Main Thread

    User->>NetworkObserver: init(monitor, ping?, queue)
    User->>NetworkObserver: start()
    
    NetworkObserver->>Monitor: Subscribe to path changes
    Monitor->>Monitor: Detect network status
    
    rect rgba(200, 220, 255, 0.3)
        Note over Monitor,Main: Path Update
        Monitor-->>NetworkObserver: pathUpdateHandler(newPath)
        NetworkObserver->>Main: Task `@MainActor`
        Main->>NetworkObserver: Update pathStatus, isExpensive, isConstrained
    end
    
    alt Ping Enabled
        rect rgba(220, 200, 255, 0.3)
            Note over NetworkObserver,Main: Periodic Ping
            NetworkObserver->>Ping: shouldPing(onStatus:)
            Ping-->>NetworkObserver: true/false
            NetworkObserver->>Ping: performPing
            Ping-->>NetworkObserver: onPing(result)
            NetworkObserver->>Main: Task `@MainActor`
            Main->>NetworkObserver: Update pingStatus
        end
    end

Loading

Estimated Code Review Effort

🎯 4 (Complex) | ⏱️ ~45 minutes

• Public API additions: Multiple new public initializers, methods, and publishers on ConnectivityObserver and NetworkObserver require careful validation for correctness and API consistency.
• Concurrency patterns: Extensive use of @MainActor, async/await, Task, and @Sendable closures across multiple delegate handlers demands close scrutiny.
• Session lifecycle management: Complex state transitions through activation, message reception, and state changes across multiple extensions require tracing.
• Handler implementations: Session delegate methods with error handling, optional decoding, and publisher emission need individual reasoning.
• Script complexity: lint.sh and preview-docs.sh contain conditional logic and cross-platform compatibility (sed -i variants, tool detection) that warrant validation.
• Configuration diversity: Multiple distinct configuration formats (SwiftFormat JSON, SwiftLint YAML, devcontainer JSON, shell scripts) with no homogeneous patterns.

Areas requiring extra attention:

• Isolation boundary crossings in ConnectivityObserver delegate methods and state updates
• Optional MessageDecoder logic and error handling paths in message handlers
• Reachability and state synchronization between session and published properties
• Script error handling and sed cross-platform compatibility in ensure-remote-deps.sh and lint.sh
• GitHub Actions workflow permissions and token security in Claude review workflows

Poem

🐰 A Swift new home we've built with care,
Containers, workflows, everywhere!
ConnectivityObserver springs to life,
No more async/await strife!
With linters, logs, and scripts so neat,
SundialKitCombine is complete! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title 'V1.0.0-alpha.1' is a version number that does not describe what was actually changed in the pull request. The PR introduces a comprehensive new Combine-based observation framework with multiple components, configuration files, and documentation.	Replace with a descriptive title that reflects the main changes, such as 'Add SundialKitCombine Combine-based observation framework' or 'Initial SundialKitCombine v1.0.0-alpha.1 implementation'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 80.56% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch v1.0.0

---

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.}

[coderabbitai]

Actionable comments posted: 9

🧹 Nitpick comments (14)

LICENSE (1)

3-3: Verify copyright year.

The copyright year is set to 2022, but the PR is dated November 2025. Confirm this reflects the actual package creation date or update to the current year if the package is being newly released for this version cycle.

.devcontainer/swift-6.1/devcontainer.json (1)

32-32: Remove trailing whitespace.

Line 32 has trailing whitespace on the closing brace. Apply this fix for JSON formatting consistency:

-} 
+}

.devcontainer/devcontainer.json (1)

32-32: Remove trailing whitespace.

Line 32 has trailing whitespace on the closing brace. Apply this fix for JSON formatting consistency:

-} 
+}

.devcontainer/swift-6.2/devcontainer.json (1)

32-32: Remove trailing whitespace.

Line 32 has trailing whitespace on the closing brace. Apply this fix for JSON formatting consistency:

-} 
+}

.devcontainer/swift-6.1-nightly/devcontainer.json (1)

4-8: Consider aligning username and remoteUser for a smoother dev UX

common-utils is configured for user vscode while the devcontainer runs as remoteUser: "root". That can lead to surprising behavior (different home dir, missing shell config). Consider switching remoteUser to vscode or updating the feature config so they match.

Also applies to: 31-31

.gitignore (1)

15-18: Minor duplication of IDE ignore entries

.idea and .vscode are listed twice. This is harmless but slightly noisy; you could drop one of the duplicates to keep the file tidy.

Also applies to: 163-165

.github/workflows/claude-code-review.yml (1)

21-27: Review whether id-token: write is actually needed

The job grants id-token: write but the current step only appears to need repo read + the CLAUDE_CODE_OAUTH_TOKEN secret and gh for comments/queries. If the action doesn’t rely on OIDC, you can drop id-token: write to tighten permissions slightly.

Also applies to: 34-57

Tests/SundialKitCombineTests/SundialKitCombineTests.swift (1)

5-9: Replace the dummy test with actual test coverage.

The placeholder test doesn't validate any functionality. Consider adding tests for the SundialKitCombine module's public API, particularly the ConnectivityObserver and related messaging functionality.

Would you like me to help generate initial test cases for the core functionality?

.github/workflows/codeql.yml (1)

55-56: Hardcoded Xcode version may require maintenance.

The Xcode path is hardcoded to version 16.4. As new Xcode versions are released, this will need manual updates. Consider whether this aligns with your Xcode version management strategy across workflows.

Scripts/ensure-remote-deps.sh (1)

19-42: Make dependency matching more resilient to Package.swift formatting changes

The grep/sed patterns assume the dependency line is exactly .package(name: "SundialKit", path: "../../"). Any change in spacing, the relative path (e.g. ../SundialKit), or additional arguments will cause the script to fall into the “Unknown dependency format” path even though the dependency is valid.

Consider loosening the match (e.g. allow arbitrary whitespace and flexible path: values, or drive LOCAL_PATH via an env var) so minor manifest edits don’t break CI unexpectedly.

Scripts/lint.sh (1)

22-29: Harden directory handling and command error tracking (macOS portability + STRICT mode)

A few small tweaks would make this script more robust:

• readlink -f (Line 24) is not supported by the default readlink on macOS, so SCRIPT_DIR can be computed incorrectly on many local dev machines.
• pushd $PACKAGE_DIR / popd (Lines 70, 93) are neither quoted nor checked, so a missing or space-containing path can cause subtle failures.
• header.sh (Line 87) is invoked directly, so its failures are ignored even in STRICT mode.

You can address all of these with something along these lines:

-if [ -z "$SRCROOT" ]; then
-	SCRIPT_DIR=$(dirname "$(readlink -f "$0")")
-	PACKAGE_DIR="${SCRIPT_DIR}/.."
-else
-	PACKAGE_DIR="${SRCROOT}"
-fi
+if [ -z "${SRCROOT:-}" ]; then
+  SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+  PACKAGE_DIR="${SCRIPT_DIR}/.."
+else
+  PACKAGE_DIR="${SRCROOT}"
+fi
@@
-pushd $PACKAGE_DIR
+pushd "$PACKAGE_DIR" || exit 1
@@
-$PACKAGE_DIR/Scripts/header.sh -d  $PACKAGE_DIR/Sources -c "Leo Dion" -o "BrightDigit" -p "SundialKitCombine"
+run_command "$PACKAGE_DIR/Scripts/header.sh" -d "$PACKAGE_DIR/Sources" -c "Leo Dion" -o "BrightDigit" -p "SundialKitCombine"
@@
-popd
+popd || exit 1

This keeps STRICT mode semantics consistent (all key steps counted via run_command) and avoids platform-specific breakage when resolving the script directory. Based on static analysis hints.

Also applies to: 70-71, 87-87, 93-93

Package.swift (1)

1-45: Confirm toolchain compatibility and scope of experimental/unsafe Swift settings

The manifest enables a large set of upcoming (enableUpcomingFeature) and experimental (enableExperimentalFeature) flags plus strict concurrency and other diagnostics via unsafeFlags for all targets (including tests). That’s powerful, but it tightly couples the package to specific Swift 6.x toolchains and may break consumers or CI environments that lag behind.

It might be worth:

• Verifying that all targeted environments (local dev, CI, and downstream users) run a toolchain that understands this full set of feature flags.
• Considering whether some of the unsafeFlags (e.g. -enable-testing, strict concurrency) should be limited to debug or test configurations rather than all builds.

Also applies to: 61-79

Sources/SundialKitCombine/ConnectivityObserver.swift (1)

87-144: Ensure ConnectivitySession.delegate is weak/unowned to avoid retain cycles

ConnectivityObserver holds a strong reference to session and sets session.delegate = self in init. If the underlying ConnectivitySession implementation also holds a strong reference to its delegate, you’ll end up with a retain cycle and a leaking observer.

Please confirm that ConnectivitySession (and its concrete implementations like WatchConnectivitySession) use a weak/unowned delegate reference; if not, it would be good to update them accordingly.

Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (1)

75-92: Consider extracting duplicate logic.

Both sessionDidBecomeInactive and sessionDidDeactivate have identical implementations. Consider extracting the common logic into a private helper method to reduce duplication.

Apply this diff to refactor:

+  private nonisolated func updateActivationState(from session: any ConnectivitySession) {
+    let activationState = session.activationState
+    Task { @MainActor in
+      self.activationState = activationState
+    }
+  }
+
  /// Handles when session becomes inactive.
  nonisolated public func sessionDidBecomeInactive(_ session: any ConnectivitySession) {
-    // Extract value before crossing isolation boundary
-    let activationState = session.activationState
-
-    Task { @MainActor in
-      self.activationState = activationState
-    }
+    updateActivationState(from: session)
  }

  /// Handles session deactivation.
  nonisolated public func sessionDidDeactivate(_ session: any ConnectivitySession) {
-    // Extract value before crossing isolation boundary
-    let activationState = session.activationState
-
-    Task { @MainActor in
-      self.activationState = activationState
-    }
+    updateActivationState(from: session)
  }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e364090 and 124af15.

📒 Files selected for processing (29)

• .devcontainer/devcontainer.json (1 hunks)
• .devcontainer/swift-6.1-nightly/devcontainer.json (1 hunks)
• .devcontainer/swift-6.1/devcontainer.json (1 hunks)
• .devcontainer/swift-6.2-nightly/devcontainer.json (1 hunks)
• .devcontainer/swift-6.2/devcontainer.json (1 hunks)
• .github/workflows/SundialKitCombine.yml (1 hunks)
• .github/workflows/claude-code-review.yml (1 hunks)
• .github/workflows/claude.yml (1 hunks)
• .github/workflows/codeql.yml (1 hunks)
• .gitignore (1 hunks)
• .mise.toml (1 hunks)
• .periphery.yml (1 hunks)
• .spi.yml (1 hunks)
• .swift-format (1 hunks)
• .swiftlint.yml (1 hunks)
• LICENSE (1 hunks)
• Package.swift (1 hunks)
• README.md (1 hunks)
• Scripts/ensure-remote-deps.sh (1 hunks)
• Scripts/header.sh (1 hunks)
• Scripts/lint.sh (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver+Methods.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivitySession.swift (1 hunks)
• Sources/SundialKitCombine/NetworkObserver.swift (1 hunks)
• Sources/SundialKitCombine/SundialLogger.swift (1 hunks)
• Tests/SundialKitCombineTests/SundialKitCombineTests.swift (1 hunks)
• project.yml (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (3)

Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (2)

Sources/SundialKitCombine/SundialLogger.swift (1)

• error (118-120)

Sources/SundialKitCombine/ConnectivityObserver+Methods.swift (1)

• send (140-171)

Sources/SundialKitCombine/ConnectivityObserver.swift (1)

Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (4)

• session (44-72)
• session (121-144)
• session (147-174)
• session (177-202)

Sources/SundialKitCombine/ConnectivityObserver+Methods.swift (3)

Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (4)

• session (44-72)
• session (121-144)
• session (147-174)
• session (177-202)

Sources/SundialKitCombine/SundialLogger.swift (1)

• error (118-120)

Sources/SundialKitCombine/ConnectivitySession.swift (1)

• sendBinaryData (34-56)

🪛 actionlint (1.7.8)

.github/workflows/SundialKitCombine.yml

21-21: duplicate value {"nightly": "true", "version": "6.1"} is found in matrix "swift". the same value is at line:19,col:13

(matrix)

---

23-23: duplicate value {"nightly": "true", "version": "6.2"} is found in matrix "swift". the same value is at line:20,col:13

(matrix)

🪛 Shellcheck (0.11.0)

Scripts/lint.sh

[warning] 70-70: Use 'pushd ... || exit' or 'pushd ... || return' in case pushd fails.

(SC2164)

---

[warning] 93-93: Use 'popd ... || exit' or 'popd ... || return' in case popd fails.

(SC2164)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Analyze (swift)

🔇 Additional comments (17)

.periphery.yml (1)

1-1: LGTM!

The Periphery configuration appropriately retains public APIs during dead code analysis, suitable for a package exposing public interfaces.

.spi.yml (1)

1-5: Verify platform scope aligns with Package.swift.

The SPI configuration targets only iOS for SundialKitCombine documentation. Confirm this reflects the intended platform support, or add additional platform targets (macOS, watchOS, tvOS) if the package should support them.

README.md (1)

1-13: LGTM!

The README clearly positions SundialKitCombine within the SundialKit v2.0.0 ecosystem and appropriately describes its role as a Combine-based Layer 2 observation plugin. The subrepo context is noted, and backward compatibility messaging is clear.

.devcontainer/swift-6.2/devcontainer.json (1)

1-32: Clarify devcontainer hierarchy.

This file duplicates the configuration in .devcontainer/devcontainer.json exactly. Clarify the intended hierarchy:

• Is .devcontainer/devcontainer.json the default for Swift 6.2?
• Is .devcontainer/swift-6.2/devcontainer.json a versioned variant for users explicitly selecting Swift 6.2?
• If they're identical, consider consolidating or clarifying their purpose in documentation.

.devcontainer/swift-6.2-nightly/devcontainer.json (1)

3-3: The swiftlang/swift:nightly-6.2-noble image is official and properly maintained.

The Swift project publishes nightly 6.2 Docker images under the swiftlang/swift namespace, and swift.org install pages list 6.2-nightly container tags (e.g., 6.2-nightly-jammy, 6.2-nightly-rhel-ubi9, 6.2-nightly-debian-12). Additionally, Swift 6.2 (stable) was released on September 15, 2025, meaning the stable toolchain is already production-ready.

Having separate devcontainers for stable and nightly variants is standard practice in development environments. The nightly image is a legitimate, officially supported option for developers who want the latest builds, and its presence does not diminish the stability of the primary devcontainers.

Likely an incorrect or invalid review comment.

.swift-format (1)

1-70: SwiftFormat configuration looks consistent with the linting strategy

The rules here line up well with the stricter SwiftLint settings (documentation, no force unwrap/try, ordered imports, etc.). I don’t see any obvious contradictions or misconfigurations.

Sources/SundialKitCombine/SundialLogger.swift (1)

32-188: Cross‑platform logging wrapper looks solid

The conditional SundialLogger design (OSLog Logger on Apple, FallbackLogger with print on other platforms) is consistent and keeps the call‑site API aligned (error / info / debug on named subsystems). I don’t see functional issues here.

project.yml (1)

1-13: LGTM!

The project configuration correctly references the lint script and properly configures the aggregate target with dependency analysis disabled, which is appropriate for a linting task.

.github/workflows/claude.yml (1)

1-50: LGTM!

The Claude Code integration workflow is properly configured with appropriate triggers, permissions, and secret handling for CI result access.

.github/workflows/SundialKitCombine.yml (2)

16-24: Matrix configuration is correct; actionlint warning is a false positive.

The static analysis tool flagged lines 21 and 23 as duplicates, but this is incorrect. The matrix intentionally includes both stable and nightly builds for Swift 6.1 and 6.2:

• Line 19: Stable Swift 6.1
• Line 20: Stable Swift 6.2
• Line 21: Nightly Swift 6.1
• Line 23: Nightly Swift 6.2

These are distinct matrix combinations differentiated by the nightly flag.

---

143-163: Lint job dependency ensures builds pass before linting.

The lint job correctly depends on both Ubuntu and macOS builds, ensuring code compiles successfully before running expensive linting operations. The STRICT lint mode is appropriate for CI.

Sources/SundialKitCombine/ConnectivitySession.swift (1)

33-57: LGTM!

The async wrapper for binary message sending is well-implemented:

• Properly uses withCheckedContinuation to bridge callback-based API to async/await
• Correctly handles both success and failure paths
• Maintains message provenance through both code paths
• Includes helpful comment explaining the empty reply data for binary messages
• Appropriate internal visibility

Sources/SundialKitCombine/ConnectivityObserver+Methods.swift (1)

36-171: Async send API and transport selection look correct and well-structured

The extension’s public API surface appears solid:

• The platform-gated convenience initializer sensibly chooses WatchConnectivitySession vs NeverConnectivitySession.
• activate() is a thin, clear wrapper over session.activate().
• sendMessage(_:) properly falls back from immediate send to application context and finally to a missingCompanion error, publishing sendResult in all branches.
• send(_:) cleanly separates binary vs dictionary transports, enforces reachability for binary sends, and consistently publishes send results while surfacing failures via throw.

I don’t see any functional or concurrency issues here; this is ready to ship as-is.

Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift (4)

41-72: LGTM: Correct actor isolation pattern.

The combination of @MainActor extension with nonisolated delegate methods and Task { @MainActor in ... } blocks correctly handles cross-isolation updates. Extracting session values before crossing the isolation boundary (lines 50-54) avoids potential data races.

---

131-142: LGTM: Robust error handling.

The pattern of logging decode failures while still publishing raw messages (lines 128-129) ensures that messages aren't lost even when decoding fails. This is good defensive coding.

---

52-63: LGTM: Proper platform guards.

The iOS-specific isPaired property is correctly guarded with #if os(iOS) both when extracting (lines 52-54) and when setting (lines 61-63). This pattern is consistently applied throughout the file.

---

177-202: No changes required — this is an intentional design pattern.

The code correctly reflects the underlying WatchConnectivity API limitation: binary messages don't support reply handlers. Since ConnectivityReceiveResult requires a reply context (either .replyWith(replyHandler) or .applicationContext), binary messages cannot be wrapped in this type.

However, binary messages are fully supported and automatically decoded to typed forms via the typedMessageReceived publisher, as documented. Users who send or receive binary messages should use the typed publisher, which is the intended design pattern.

Likely an incorrect or invalid review comment.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Fix indentation to match other devcontainer files.

Indentation in the features section uses 4+ spaces inconsistently compared to stable Swift devcontainers which use 2-space indentation. Normalize to match .devcontainer/devcontainer.json and .devcontainer/swift-6.1/devcontainer.json:

  "features": {
-      "ghcr.io/devcontainers/features/common-utils:2": {
-          "installZsh": "false",
-          "username": "vscode",
-          "upgradePackages": "false"
-      },
-      "ghcr.io/devcontainers/features/git:1": {
-          "version": "os-provided",
-          "ppa": "false"
-      }
+    "ghcr.io/devcontainers/features/common-utils:2": {
+      "installZsh": "false",
+      "username": "vscode",
+      "upgradePackages": "false"
+    },
+    "ghcr.io/devcontainers/features/git:1": {
+      "version": "os-provided",
+      "ppa": "false"
+    }

🤖 Prompt for AI Agents

.devcontainer/swift-6.2-nightly/devcontainer.json around lines 5 to 13: the
features block uses inconsistent 4+ space indentation; normalize the JSON to use
2-space indentation for these entries to match .devcontainer/devcontainer.json
and .devcontainer/swift-6.1/devcontainer.json (adjust spaces before keys and
nested values so each nesting level is two spaces).

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Remove inline comments for consistency across devcontainer variants.

This nightly variant includes inline JSON comments (lines 21, 23, 25, 29, 35, 38) while stable Swift devcontainers omit them. Remove these comments to maintain consistent style across all devcontainer configurations:

  },
-  // Configure tool-specific properties.
  "customizations": {
-      // Configure properties specific to VS Code.
      "vscode": {
-          // Set *default* container specific settings.json values on container create.
          "settings": {
              "lldb.library": "/usr/lib/liblldb.so"
          },
-          // Add the IDs of extensions you want installed when the container is created.
           "extensions": [
              "sswg.swift-lang"
          ]
      }
  },
-  // Use 'forwardPorts' to make a list of ports inside the container available locally.
-  // "forwardPorts": [],
-
-  // Set `remoteUser` to `root` to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
  "remoteUser": "root"

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Configure tool-specific properties.
	"customizations": {
	// Configure properties specific to VS Code.
	"vscode": {
	// Set *default* container specific settings.json values on container create.
	"settings": {
	"lldb.library": "/usr/lib/liblldb.so"
	},
	// Add the IDs of extensions you want installed when the container is created.
	"extensions": [
	"sswg.swift-lang"
	]
	}
	},
	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],
	// Set `remoteUser` to `root` to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
	"remoteUser": "root"
	// Configure tool-specific properties.
	"customizations": {
	"vscode": {
	"settings": {
	"lldb.library": "/usr/lib/liblldb.so"
	},
	"extensions": [
	"sswg.swift-lang"
	]
	}
	},
	"remoteUser": "root"

🤖 Prompt for AI Agents

.devcontainer/swift-6.2-nightly/devcontainer.json lines 21 to 39: this file
contains inline JSON comments on several lines which should be removed for
consistency with other devcontainer variants; delete the comment tokens and
their text (lines ~21, 23, 25, 29, 35, 38) so the file contains only valid JSON
properties and normal spacing, making sure no trailing commas or accidental
syntax errors are introduced when removing the comment lines.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

Verify that the tool versions are current and secure.

Ensure the pinned versions of swift-format (602.0.0), swiftlint (0.61.0), and periphery (3.2.0) are the latest stable releases and have no known security issues.

---

🌐 Web query:

What are the latest stable versions of swift-format, swiftlint, and periphery Swift tools as of November 2025?

💡 Result:

As of November 15, 2025:

• swift-format — 602.0.0 (latest stable listed). [1]
• SwiftLint — 0.62.2 (released Oct 28, 2025). [2]
• Periphery — 3.2.0 (latest stable listed). [3]

Sources: [1] Swift Package Index — swift-format. [2] GitHub releases — realm/SwiftLint. [3] Swift Package Index — periphery.

---

Update swiftlint to version 0.62.2.

SwiftLint 0.62.2 was released Oct 28, 2025, but the current pinned version is 0.61.0. swift-format (602.0.0) and periphery (3.2.0) are both current.

🤖 Prompt for AI Agents

In .mise.toml around lines 1 to 6, the pinned swiftlint version is 0.61.0 and
needs to be updated to 0.62.2; change the swiftlint entry value from "0.61.0" to
"0.62.2", then re-run any dependency sync/lockfile update commands your
toolchain uses (and run swiftlint or CI checks locally) to ensure the new
version integrates cleanly.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

pattern_matching_keywords is both opt‑in and disabled

The pattern_matching_keywords rule is listed in opt_in_rules and again in disabled_rules. SwiftLint will treat the rule as disabled, but the config is contradictory and may surprise future maintainers. Consider removing it from one of the lists to make the intended behavior explicit.

Also applies to: 125-132

---

---

🏁 Script executed:

#!/bin/bash
# Search for pattern_matching_keywords in .swiftlint.yml with context
rg -n 'pattern_matching_keywords' .swiftlint.yml -C5

Length of output: 523

---

🏁 Script executed:

#!/bin/bash
# Extract the full structure around opt_in_rules and disabled_rules
rg -n -A20 'opt_in_rules:' .swiftlint.yml | head -40

Length of output: 579

---

🏁 Script executed:

#!/bin/bash
# Extract the full structure around disabled_rules
rg -n -A20 'disabled_rules:' .swiftlint.yml | head -40

Length of output: 217

---

🏁 Script executed:

#!/bin/bash
# Count total lines to verify line numbers
wc -l .swiftlint.yml

Length of output: 18

---

🏁 Script executed:

#!/bin/bash
# Show lines 55-65 to see the context at line 59
sed -n '55,65p' .swiftlint.yml

Length of output: 314

---

🏁 Script executed:

#!/bin/bash
# Show lines 120-135 to see the context at 125-132
sed -n '120,135p' .swiftlint.yml

Length of output: 280

---

pattern_matching_keywords is both opt‑in and disabled

The pattern_matching_keywords rule is listed in opt_in_rules (line 59) and again in disabled_rules (line 132). SwiftLint will treat the rule as disabled, but the config is contradictory and may confuse future maintainers. Remove it from one of the lists to make the intended behavior explicit.

🤖 Prompt for AI Agents

In .swiftlint.yml around line 59 (and referenced at line 132), the rule
pattern_matching_keywords appears in both opt_in_rules and disabled_rules
causing a contradiction; remove it from one list to make intent explicit — if
you want the rule enabled keep it only in opt_in_rules and delete it from
disabled_rules, otherwise remove it from opt_in_rules and leave it in
disabled_rules; commit the updated .swiftlint.yml so the rule is defined in only
one place.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add error handling and consider creating backups before modifying files.

The script modifies Swift files in-place without creating backups or checking for write errors. If the script fails mid-operation or encounters an error, source files could be corrupted or partially modified.

Consider these improvements:

  # Remove all consecutive lines at the beginning which start with "// ", contain only whitespace, or only "//"
  awk '
  BEGIN { skip = 1 }
  {
    if (skip && ($0 ~ /^\/\/ / || $0 ~ /^\/\/$/ || $0 ~ /^$/)) {
      next
    }
    skip = 0
    print
  }' "$file" > temp_file
+ 
+  # Check if awk succeeded
+  if [ $? -ne 0 ]; then
+    echo "Error processing $file"
+    rm -f temp_file
+    exit 1
+  fi

  # Add the header to the cleaned file
- (echo "$header"; echo; cat temp_file) > "$file"
+  (echo "$header"; echo; cat temp_file) > "$file.new"
+  if [ $? -eq 0 ]; then
+    mv "$file.new" "$file"
+  else
+    echo "Error writing $file"
+    rm -f temp_file "$file.new"
+    exit 1
+  fi

  # Remove the temporary file
  rm temp_file

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	# Remove all consecutive lines at the beginning which start with "// ", contain only whitespace, or only "//"
	awk '
	BEGIN { skip = 1 }
	{
	if (skip && ($0 ~ /^\/\/ / || $0 ~ /^\/\/$/ || $0 ~ /^$/)) {
	next
	}
	skip = 0
	print
	}' "$file" > temp_file
	# Add the header to the cleaned file
	(echo "$header"; echo; cat temp_file) > "$file"
	# Remove the temporary file
	rm temp_file
	# Remove all consecutive lines at the beginning which start with "// ", contain only whitespace, or only "//"
	awk '
	BEGIN { skip = 1 }
	{
	if (skip && ($0 ~ /^\/\/ / || $0 ~ /^\/\/$/ || $0 ~ /^$/)) {
	next
	}
	skip = 0
	print
	}' "$file" > temp_file
	# Check if awk succeeded
	if [ $? -ne 0 ]; then
	echo "Error processing $file"
	rm -f temp_file
	exit 1
	fi
	# Add the header to the cleaned file
	(echo "$header"; echo; cat temp_file) > "$file.new"
	if [ $? -eq 0 ]; then
	mv "$file.new" "$file"
	else
	echo "Error writing $file"
	rm -f temp_file "$file.new"
	exit 1
	fi
	# Remove the temporary file
	rm temp_file

🤖 Prompt for AI Agents

In Scripts/header.sh around lines 86 to 101, the current in-place modification
using awk and a temp file lacks backups and error handling which can corrupt
source files; create a safe workflow that (1) creates a backup of "$file" (e.g.,
copy to "$file.bak" or a timestamped backup) before any changes, (2) use a
secure temporary file from mktemp for processing, (3) check the exit status of
awk and each subsequent command and abort/restore the backup if any command
fails, (4) write the final output atomically by moving the temp file into place
(mv) only on success, and (5) install a trap to remove temp files on exit and to
restore the backup on unexpected failures.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

Unused error parameter.

The error parameter (line 150) is declared but never used in the method body. Should this error be logged, published, or handled in some way? The session(_:activationDidCompleteWith:error:) method provides a pattern for error handling if needed.

If the error should be used, consider applying this diff:

  nonisolated public func session(
    _ session: any ConnectivitySession,
    didReceiveApplicationContext applicationContext: ConnectivityMessage,
    error: (any Error)?
  ) {
    Task { @MainActor in
+     if let error = error {
+       if #available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *) {
+         SundialLogger.combine.error(
+           "Application context error: \(String(describing: error))"
+         )
+       }
+     }
+
      // Send to raw publisher
      let result = ConnectivityReceiveResult(
        message: applicationContext, context: .applicationContext
      )

---

🏁 Script executed:

#!/bin/bash
# Search for the activationDidCompleteWith method to understand error handling pattern
rg -n "activationDidCompleteWith" --type swift -A 20 -B 2

Length of output: 2246

---

🏁 Script executed:

#!/bin/bash
# Search for all session delegate methods in the file to see overall error handling patterns
rg -n "nonisolated public func session" --type swift -A 15 -B 1 "Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift"

Length of output: 4627

---

🏁 Script executed:

#!/bin/bash
# Check if the error parameter is documented or referenced anywhere else
rg -n "error.*Error\?" --type swift "Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift"

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for properties related to error handling in the observer class
rg -n "Error\|error" --type swift "Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift" | head -30

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for the class definition and property declarations
rg -n "@Published\|var.*Error\|let.*Error" --type swift "Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift"

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Look at broader context - check for the main ConnectivityObserver class file
fd -e swift -n "ConnectivityObserver\.swift$" "Sources/"

Length of output: 230

---

🏁 Script executed:

#!/bin/bash
# Find the main ConnectivityObserver file (not the delegate extension)
find Sources -name "*.swift" -type f | xargs grep -l "class ConnectivityObserver"

Length of output: 52

---

🏁 Script executed:

#!/bin/bash
# Look at the full delegate file to understand the context better
cat "Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift" | head -50

Length of output: 1837

---

🏁 Script executed:

#!/bin/bash
# Search for activationError property in the main class file
find Sources -name "*.swift" -type f | xargs grep -n "activationError"

Length of output: 332

---

🏁 Script executed:

#!/bin/bash
# Search for all @Published properties related to errors or messages
grep -n "@Published" "Sources/SundialKitCombine/ConnectivityObserver.swift" | grep -i "error\|message"

Length of output: 73

---

🏁 Script executed:

#!/bin/bash
# Check the full ConnectivityObserver class for all @Published properties
grep -n "@Published" "Sources/SundialKitCombine/ConnectivityObserver.swift"

Length of output: 381

---

🏁 Script executed:

#!/bin/bash
# Look for how messageReceived/typedMessageReceived publishers are defined
grep -n "messageReceived\|typedMessageReceived" "Sources/SundialKitCombine/ConnectivityObserver.swift" | head -10

Length of output: 211

---

Unused error parameter should be logged.

The error parameter (line 150) is declared but never used. Unlike activationDidCompleteWith which stores its error in a @Published property, no applicationContextError property exists. However, the method already logs decoding errors (lines 167-172), so the application context error should be logged similarly for consistency.

The suggested diff aligns with existing error handling patterns in the codebase.

🤖 Prompt for AI Agents

In Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift around lines
147 to 174, the incoming error parameter is unused; mirror existing decoding
error handling by logging the session-provided error when it's non-nil. Inside
the Task @MainActor block (before or alongside decoding), check if error != nil
and, under the same availability guard used for decoding errors, call
SundialLogger.combine.error("Failed to receive application context:
\(String(describing: error))"); keep the existing raw and decoded flows
unchanged.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Critical: Reply handler is not being called.

Lines 198-200 indicate that the reply handler must be called to complete the send operation, but the call is commented out. This will cause the sender's side to hang indefinitely, waiting for a response.

If the reply handler should remain disabled, please clarify why and remove the "IMPORTANT" comment. Otherwise, uncomment line 200 to ensure proper completion:

  // IMPORTANT: Must call reply handler to complete the send operation on sender's side
  // Send empty Data as acknowledgment since we don't have a reply payload
- // replyHandler(Data())
+ replyHandler(Data())

Run the following script to check if this pattern is used elsewhere in the codebase:

---

🏁 Script executed:

#!/bin/bash
# Search for other replyHandler usages in delegate methods
rg -nP 'replyHandler.*Data\(\)' --type swift

Length of output: 97

---

---

🏁 Script executed:

#!/bin/bash
# Search for all replyHandler usages in the file
rg -nP 'replyHandler' Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift -A2 -B2

Length of output: 861

---

🏁 Script executed:

#!/bin/bash
# Find all delegate method signatures with replyHandler parameter
ast-grep --pattern 'func $_($_: any ConnectivitySession, $$$replyHandler: @escaping @Sendable (Data) -> Void$$$) { $$$ }'

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Show the didReceiveMessage handler for comparison
rg -nP 'func session.*didReceiveMessage[^D]' Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift -A20

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check the entire ConnectivityObserver+Delegate.swift file structure
wc -l Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift && head -20 Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift

Length of output: 869

---

🏁 Script executed:

#!/bin/bash
# Search for method definitions that have replyHandler parameter
rg -nP 'replyHandler:\s*@escaping' Sources/SundialKitCombine/ --type swift -B5

Length of output: 1301

---

🏁 Script executed:

#!/bin/bash
# Check if there are any WatchConnectivityDelegate or similar protocol definitions
fd -e swift -x grep -l 'protocol.*ConnectivityDelegate\|protocol.*Session' {} \;

Length of output: 0

---

---

🏁 Script executed:

#!/bin/bash
# Find ConnectivityReceiveResult definition and usage
rg -n 'ConnectivityReceiveResult' Sources/SundialKitCombine/ --type swift -B2 -A2

Length of output: 1504

---

🏁 Script executed:

#!/bin/bash
# View the full didReceiveMessage method (lines 120-174)
sed -n '120,174p' Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift

Length of output: 2095

---

🏁 Script executed:

#!/bin/bash
# View the full didReceiveMessageData method (lines 176-202)
sed -n '176,202p' Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift

Length of output: 1045

---

🏁 Script executed:

#!/bin/bash
# Search for messageReceived publisher definition to understand how replyHandler context is used
rg -n 'messageReceived.*Publisher\|messageReceived.*send' Sources/SundialKitCombine/ --type swift -B1 -A1

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check if there's any documentation or protocol definition for the delegate pattern
rg -n 'ConnectivitySession\|ConnectivityDelegate' Sources/SundialKitCombine/ --type swift | head -20

Length of output: 0

---

---

🏁 Script executed:

#!/bin/bash
# Find ConnectivityReceiveResult definition
fd -n -e swift -x grep -l 'struct ConnectivityReceiveResult\|enum ConnectivityReceiveResult\|class ConnectivityReceiveResult' {} \;

Length of output: 230

---

🏁 Script executed:

#!/bin/bash
# Search for the definition and all context cases
rg -n 'ConnectivityReceiveResult\|enum.*Context\|case.*replyWith' Sources/ --type swift -A3 -B1 | head -60

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check the exact signature of ConnectivityReceiveResult init
rg -n 'init.*ConnectivityReceiveResult\|struct ConnectivityReceiveResult' Sources/ --type swift -A10

Length of output: 0

---

---

🏁 Script executed:

#!/bin/bash
# Search entire repo for ConnectivityReceiveResult definition
find . -name "*.swift" -type f | xargs grep -l "struct ConnectivityReceiveResult\|enum ConnectivityReceiveResult\|class ConnectivityReceiveResult" 2>/dev/null

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Look for where replyWith context case is defined
rg -n 'case replyWith\|\.replyWith' --type swift -B3 -A1

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check imports in the delegate file to understand dependencies
head -50 Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift

Length of output: 1837

---

Critical: Reply handler must be called or intentionality clarified.

The binary message handler receives replyHandler but the call at line 200 is commented out. The non-binary message handler correctly preserves the reply handler via ConnectivityReceiveResult(message: message, context: .replyWith(replyHandler)) (line 128), while the binary handler has no equivalent mechanism.

Either uncomment line 200 to call the reply handler:

  // IMPORTANT: Must call reply handler to complete the send operation on sender's side
  // Send empty Data as acknowledgment since we don't have a reply payload
- // replyHandler(Data())
+ replyHandler(Data())

Or remove the "IMPORTANT" comment and document why the reply handler is intentionally not called.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	/// Handles received binary message data with reply handler.
	nonisolated public func session(
	_ session: any ConnectivitySession,
	didReceiveMessageData messageData: Data,
	replyHandler: @escaping @Sendable (Data) -> Void
	) {
	Task { @MainActor in
	// Decode and send to typed publisher
	if let decoder = self.messageDecoder {
	do {
	let decoded = try decoder.decodeBinary(messageData)
	self.typedMessageReceived.send(decoded)
	} catch {
	// Decoding failed - log the error
	if #available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *) {
	SundialLogger.combine.error(
	"Failed to decode binary message: \(String(describing: error))"
	)
	}
	}
	}
	// IMPORTANT: Must call reply handler to complete the send operation on sender's side
	// Send empty Data as acknowledgment since we don't have a reply payload
	// replyHandler(Data())
	}
	}
	/// Handles received binary message data with reply handler.
	nonisolated public func session(
	_ session: any ConnectivitySession,
	didReceiveMessageData messageData: Data,
	replyHandler: @escaping @Sendable (Data) -> Void
	) {
	Task { @MainActor in
	// Decode and send to typed publisher
	if let decoder = self.messageDecoder {
	do {
	let decoded = try decoder.decodeBinary(messageData)
	self.typedMessageReceived.send(decoded)
	} catch {
	// Decoding failed - log the error
	if #available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *) {
	SundialLogger.combine.error(
	"Failed to decode binary message: \(String(describing: error))"
	)
	}
	}
	}
	// IMPORTANT: Must call reply handler to complete the send operation on sender's side
	// Send empty Data as acknowledgment since we don't have a reply payload
	replyHandler(Data())
	}
	}

🤖 Prompt for AI Agents

In Sources/SundialKitCombine/ConnectivityObserver+Delegate.swift around lines
176 to 202, the binary message handler receives a replyHandler but currently
does not call it (the reply call is commented out) and does not forward it to
the typed receiver like the non-binary handler does; restore consistent behavior
by either (A) calling replyHandler(Data()) before exiting the Task to
acknowledge the sender, or (B) preserve and forward the reply handler to
downstream consumers by wrapping the decoded message in a
ConnectivityReceiveResult with context .replyWith(replyHandler) (matching the
non-binary handler), and remove the commented-out line and "IMPORTANT" note
accordingly so the reply path is explicit and executed.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

Doc example doesn’t match the actual API

The example shows:

• let observer = NetworkObserver() (no generic arguments / dependencies)
• Usage of observer.$isReachable

But the type requires MonitorType and PingType inits, and there is no isReachable property—only pathStatus, isExpensive, isConstrained, and pingStatus. It would be good to update the example to match the real initializers and published properties (or add a convenience type/property if the example reflects the intended API).

Also applies to: 64-66

---

I'll verify the claims in the review by examining the actual NetworkObserver implementation.

---

🏁 Script executed:

```shell
#!/bin/bash
# Locate and inspect NetworkObserver.swift
find . -name "NetworkObserver.swift" -type f | head -1 | xargs cat

Length of output: 5074

---

Update example to match actual API and document timer lifecycle

The documentation example at lines 36–63 contains two issues:

1. Init mismatch: Example shows NetworkObserver() with no arguments, but the initializer requires at least a monitor parameter. Even the convenience initializer (when PingType == NeverPing) requires monitor: MonitorType.

2. Missing property: Example references $isReachable, which does not exist. The available published properties are pathStatus, isExpensive, isConstrained, and pingStatus.

3. Timer lifecycle: start() can be called multiple times without calling stop(), which orphans previous timers on the run loop (since only the latest timer is retained in self.timer). There is no deinit to clean up. Consider calling timer?.invalidate() at the start of setupPingTimer() or documenting the requirement to call stop() before calling start() again.

[codecov]

Codecov Report

❌ Patch coverage is 0.90909% with 218 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@7afd90c). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...ndialKitCombine/ConnectivityObserver+Methods.swift	0.00%	56 Missing ⚠️
...Combine/ConnectivityObserver+MessageHandling.swift	0.00%	48 Missing ⚠️
Sources/SundialKitCombine/NetworkObserver.swift	0.00%	40 Missing ⚠️
...ombine/ConnectivityObserver+SessionLifecycle.swift	0.00%	24 Missing ⚠️
...ources/SundialKitCombine/ConnectivitySession.swift	0.00%	16 Missing ⚠️
Sources/SundialKitCombine/SundialLogger.swift	0.00%	13 Missing ⚠️
...urces/SundialKitCombine/ConnectivityObserver.swift	0.00%	11 Missing ⚠️
...KitCombine/ConnectivityObserver+StateChanges.swift	0.00%	10 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##             main      #2   +/-   ##
======================================
  Coverage        ?   0.90%           
======================================
  Files           ?       9           
  Lines           ?     220           
  Branches        ?       0           
======================================
  Hits            ?       2           
  Misses          ?     218           
  Partials        ?       0           

Flag	Coverage Δ
spm	0.95% <0.95%> (?)
swift-6.1-jammy	6.89% <6.89%> (?)
swift-6.1-jammy-nightly	6.89% <6.89%> (?)
swift-6.1-noble	6.89% <6.89%> (?)
swift-6.1-noble-nightly	6.89% <6.89%> (?)
swift-6.2-jammy	6.89% <6.89%> (?)
swift-6.2-jammy-nightly	6.89% <6.89%> (?)
swift-6.2-noble	6.89% <6.89%> (?)
swift-6.2-noble-nightly	6.89% <6.89%> (?)

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.

[coderabbitai]

Actionable comments posted: 4

🧹 Nitpick comments (1)

Scripts/preview-docs.sh (1)

1-7: Check for required tools at startup.

The script relies on swift, xcrun, and xargs without verifying they're available. Failures will occur only when commands are executed, making debugging harder.

Add a tool availability check function after the usage function:

# Check for required tools
check_requirements() {
  local missing_tools=()
  
  for tool in swift xcrun xargs; do
    if ! command -v "$tool" &> /dev/null; then
      missing_tools+=("$tool")
    fi
  done
  
  if [ ${#missing_tools[@]} -gt 0 ]; then
    echo -e "${RED}Error: Required tools not found: ${missing_tools[*]}${NC}"
    echo -e "${YELLOW}Ensure Xcode command-line tools are installed${NC}"
    exit 1
  fi
}

# Add this call early in the script, after argument parsing
check_requirements

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 124af15 and 899c22a.

📒 Files selected for processing (2)

• Scripts/preview-docs.sh (1 hunks)
• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: Analyze (swift)
• GitHub Check: Build on macOS (watchos, macos-15, /Applications/Xcode_16.4.app, Apple Watch Series 10 (46mm), 11.5)
• GitHub Check: Build on macOS (watchos, macos-26, /Applications/Xcode_26.1.app, Apple Watch Ultra 3 (49mm), 26.0...
• GitHub Check: Build on Ubuntu (noble, 6.1, true)
• GitHub Check: Build on Ubuntu (jammy, 6.1, true)
• GitHub Check: Analyze (swift)

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Port number requires validation.

Line 78 accepts any value as the port without verifying it's a valid integer within the valid port range (1–65535).

Add port validation after argument parsing:

   while [[ $# -gt 0 ]]; do
     case $1 in
       --port)
         PORT="$2"
         shift 2
         ;;

Insert validation after the argument parsing loop (after line 103):

+# Validate port number
+if ! [[ "$PORT" =~ ^[0-9]+$ ]] || [ "$PORT" -lt 1 ] || [ "$PORT" -gt 65535 ]; then
+  echo -e "${RED}Error: Port must be a valid integer between 1 and 65535, got: $PORT${NC}"
+  exit 1
+fi

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In Scripts/preview-docs.sh around lines 77 to 79 and add code after the
argument-parsing loop (after line 103): the PORT assignment currently accepts
any value; validate that PORT is a non-empty numeric integer and within the
valid TCP/UDP port range 1–65535. Implement a check that: 1) ensures PORT is
set, 2) matches only digits (e.g. /^[0-9]+$/), 3) converts to an integer and
verifies 1 <= PORT <= 65535, and if any check fails print a clear error to
stderr and exit with a non-zero status. Keep the validation separate from
parsing and ensure subsequent script logic uses the validated PORT variable.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Build output filtering may hide critical errors.

Lines 158 and 309 pipe swift build to grep to filter output, but this suppresses lines not matching the regex. If the build fails with errors not containing the expected keywords, the user won't see them and troubleshooting becomes difficult.

Use tee to preserve full output while highlighting relevant lines:

-  if ! swift build 2>&1 | grep -E "(Building|Build complete|error:|warning:)"; then
+  if ! swift build 2>&1 | tee /tmp/swift_build.log | grep -E "(Building|Build complete|error:|warning:)"; then
-    echo -e "${RED}Error: Swift build failed${NC}"
-    return 1
-  fi
+    echo -e "${RED}Error: Swift build failed${NC}"
+    echo -e "${YELLOW}Full build output:${NC}"
+    cat /tmp/swift_build.log
+    return 1
+  fi

Similarly for line 309:

-        if swift build 2>&1 | grep -E "(Building|Build complete|error:)" && \
-           swift package dump-symbol-graph 2>&1 | grep -q "Emitting symbol graph"; then
+        if swift build 2>&1 | tee /tmp/swift_build.log | grep -E "(Building|Build complete|error:)" && \
+           swift package dump-symbol-graph 2>&1 | tee /tmp/symbol_graph.log | grep -q "Emitting symbol graph"; then

Also applies to: 309-309

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Hard-coded sleep without robust server startup verification.

Line 248 uses sleep 3 then verifies the process exists with kill -0, but doesn't confirm the server is actually listening on the port. If the server is slow to bind, the 3-second window may be insufficient, causing a false negative. Conversely, if the server fails fast, the check won't catch it reliably.

Implement port connectivity polling with retry logic:

-# Wait for server to start
-sleep 3
+# Wait for server to become ready with retries
+MAX_RETRIES=30
+RETRY_INTERVAL=0.5
+RETRIES=0
 
-# Check if server is still running
-if ! kill -0 "$SERVER_PID" 2>/dev/null; then
-  echo -e "${RED}Error: Preview server failed to start${NC}"
-  echo -e "${YELLOW}Check the output above for errors${NC}"
-  exit 1
+while [ $RETRIES -lt $MAX_RETRIES ]; do
+  # Check if process is still running
+  if ! kill -0 "$SERVER_PID" 2>/dev/null; then
+    echo -e "${RED}Error: Preview server failed to start${NC}"
+    echo -e "${YELLOW}Check the output above for errors${NC}"
+    exit 1
+  fi
+
+  # Check if server is listening on the port
+  if (echo >/dev/tcp/localhost/$PORT) 2>/dev/null; then
+    break
+  fi
+
+  RETRIES=$((RETRIES + 1))
+  sleep $RETRY_INTERVAL
+done
+
+if [ $RETRIES -eq $MAX_RETRIES ]; then
+  echo -e "${RED}Error: Preview server did not start listening on port $PORT after ${MAX_RETRIES}s${NC}"
+  exit 1
 fi

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	sleep 3
	# Check if server is still running
	if ! kill -0 "$SERVER_PID" 2>/dev/null; then
	echo -e "${RED}Error: Preview server failed to start${NC}"
	echo -e "${YELLOW}Check the output above for errors${NC}"
	exit 1
	fi
	# Wait for server to become ready with retries
	MAX_RETRIES=30
	RETRY_INTERVAL=0.5
	RETRIES=0
	while [ $RETRIES -lt $MAX_RETRIES ]; do
	# Check if process is still running
	if ! kill -0 "$SERVER_PID" 2>/dev/null; then
	echo -e "${RED}Error: Preview server failed to start${NC}"
	echo -e "${YELLOW}Check the output above for errors${NC}"
	exit 1
	fi
	# Check if server is listening on the port
	if (echo >/dev/tcp/localhost/$PORT) 2>/dev/null; then
	break
	fi
	RETRIES=$((RETRIES + 1))
	sleep $RETRY_INTERVAL
	done
	if [ $RETRIES -eq $MAX_RETRIES ]; then
	echo -e "${RED}Error: Preview server did not start listening on port $PORT after ${MAX_RETRIES}s${NC}"
	exit 1
	fi

🤖 Prompt for AI Agents

In Scripts/preview-docs.sh around lines 248 to 255, the script currently uses a
fixed sleep then checks the PID, which can produce false negatives if the server
takes longer to bind or fails fast; replace the sleep + kill check with a
port-connectivity polling loop that (1) reads the intended SERVER_PORT (or
extracts it from env/config), (2) attempts to connect to localhost:PORT
repeatedly (using nc, curl --silent --connect-timeout, or bash /dev/tcp) with a
short interval (e.g., 0.5–1s) and a total timeout (e.g., 30s), (3) verifies the
SERVER_PID is still running between attempts, and (4) exits successfully once a
connection is accepted or prints a clear error and exits non-zero if the timeout
elapses or the process dies; ensure you print meaningful status messages and
preserve existing color/error formatting.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Potential orphaned fswatch process on cleanup.

The pipeline fswatch ... | while read ... & captures the subshell PID in WATCH_PID=$!, not the fswatch process itself. When cleanup kills WATCH_PID, the while loop terminates but fswatch continues running as an orphaned process.

To properly capture fswatch's PID, restructure the monitoring:

-    # Use fswatch to monitor Swift file changes only
-    fswatch -r \
-      -e ".*" \
-      -i "\\.swift$" \
-      "${WATCH_PATHS[@]}" | while read -r changed_file; do
-
-      echo ""
-      echo -e "${YELLOW}Swift file changed: $(basename "$changed_file")${NC}"
-      echo -e "${YELLOW}Rebuilding symbol graphs...${NC}"
-
-      # Rebuild Swift and extract new symbols
-      if swift build 2>&1 | grep -E "(Building|Build complete|error:)" && \
-         swift package dump-symbol-graph 2>&1 | grep -q "Emitting symbol graph"; then
-        echo -e "${GREEN}✓ Symbol graphs updated${NC}"
-        echo -e "${BLUE}  DocC will auto-reload the documentation${NC}"
-      else
-        echo -e "${RED}✗ Symbol graph update failed${NC}"
-        echo -e "${YELLOW}  Fix the errors and save to rebuild${NC}"
-      fi
-
-      echo ""
-      echo -e "${BLUE}Watching for changes...${NC}"
-    done &
-    WATCH_PID=$!
+    # Create a named pipe for fswatch output
+    FIFO="/tmp/fswatch_$$"
+    mkfifo "$FIFO" || { echo -e "${RED}Failed to create FIFO${NC}"; exit 1; }
+
+    # Start fswatch in background
+    fswatch -r \
+      -e ".*" \
+      -i "\\.swift$" \
+      "${WATCH_PATHS[@]}" > "$FIFO" &
+    WATCH_PID=$!
+
+    # Read from fswatch output
+    while read -r changed_file < "$FIFO"; do
+      echo ""
+      echo -e "${YELLOW}Swift file changed: $(basename "$changed_file")${NC}"
+      echo -e "${YELLOW}Rebuilding symbol graphs...${NC}"
+
+      # Rebuild Swift and extract new symbols
+      if swift build 2>&1 | grep -E "(Building|Build complete|error:)" && \
+         swift package dump-symbol-graph 2>&1 | grep -q "Emitting symbol graph"; then
+        echo -e "${GREEN}✓ Symbol graphs updated${NC}"
+        echo -e "${BLUE}  DocC will auto-reload the documentation${NC}"
+      else
+        echo -e "${RED}✗ Symbol graph update failed${NC}"
+        echo -e "${YELLOW}  Fix the errors and save to rebuild${NC}"
+      fi
+
+      echo ""
+      echo -e "${BLUE}Watching for changes...${NC}"
+    done
+
+    # Clean up FIFO
+    rm -f "$FIFO"

Also update the cleanup function to ensure fswatch is terminated:

 # Cleanup function
 cleanup() {
   echo ""
   echo -e "${YELLOW}Shutting down...${NC}"
 
   if [ -n "$WATCH_PID" ]; then
-    kill "$WATCH_PID" 2>/dev/null || true
+    kill "$WATCH_PID" 2>/dev/null || true
+    # Ensure fswatch is killed if process tree doesn't inherit
+    pkill -P "$WATCH_PID" fswatch 2>/dev/null || true
   fi

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

README.md (1)

101-121: Minor documentation nits and example ergonomics (non-blocking)

A few small polish items you might want to consider, all non-blocking:

• Several examples declare private var cancellables = Set<AnyCancellable>() but then only use assign(to: &...) (which manages its own lifetime). This is fine conceptually but may confuse readers or generate warnings if they paste the code as-is.
• The name WatchConnectivityObject is reused in multiple, slightly different snippets (basic connectivity vs. typed Messagable usage). Using distinct names (e.g., BasicWatchConnectivityObject, ColorWatchConnectivityObject) could reduce confusion when copy/pasting.
• The “Architecture” section mentions a three-layer architecture but only enumerates Layer 1 and Layer 2. If there’s a third layer (e.g., app integration or the Stream plugin), it might be worth calling it out explicitly for clarity.

These are all documentation-only suggestions; the technical content looks solid.

Also applies to: 175-185, 227-247, 320-375, 383-407, 411-421

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0825dc3 and 70c5854.

📒 Files selected for processing (3)

• Package.swift (1 hunks)
• README.md (1 hunks)
• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md

🧰 Additional context used

🪛 GitHub Actions: CodeQL

Package.swift

[warning] 1-1: Unknown dependency format in Package.swift

🔇 Additional comments (2)

Package.swift (2)

61-63: CodeQL warning on branch-based dependency is expected; migration to version-based requirement depends on official 2.0.0 release

The current dependency on branch: "v2.0.0" is valid and necessary since SundialKit 2.0.0 has not yet been officially tagged. The CodeQL warning about "Unknown dependency format" is expected behavior for branch-based dependencies, as tools cannot infer a concrete semantic version from a branch reference.

Once SundialKit 2.0 is officially released and tagged (currently highest released version is 1.0.0-beta.1), you can migrate to a version-based requirement as suggested:

-    .package(url: "https://github.com/brightdigit/SundialKit.git", branch: "v2.0.0")
+    .package(url: "https://github.com/brightdigit/SundialKit.git", from: "2.0.0")

Keep the branch-based dependency for now; revisit this when 2.0.0 reaches stable release.

---

8-45: I'll verify the specific feature flags used in your manifest against Swift 6.1/6.2 documentation.

I need to verify the status of FullTypedThrows in Swift 6.2 and check the remaining experimental features.

Verify whether FullTypedThrows feature flag is fully supported in Swift 6.1/6.2 toolchains

FullTypedThrows type inference changes originally intended for Swift 6.0 were not implemented and have been removed from the proposal and placed into "Future Directions." Type inference for closures with typed throws functions is part of the FullTypedThrows upcoming feature that was subsetted out of SE-0413. This means enabling .enableUpcomingFeature("FullTypedThrows") may not provide full functionality or could cause build failures if the toolchain doesn't support the incomplete feature set.

The four upcoming feature flags (ExistentialAny, InternalImportsByDefault, MemberImportVisibility) and the experimental macro/move-only flags are all confirmed as supported and correctly categorized for Swift 6.1/6.2. However, remove or conditionally gate FullTypedThrows unless you confirm it's actively used in the codebase, as the type inference changes did not get implemented in Swift 6.0, and have been removed from the proposal.

Review your use of these flags and trim where unnecessary. Even if supported, enabling 20+ experimental/upcoming features globally across all targets tightly couples the package to very recent toolchain snapshots. Consider:

• Removing flags not actually needed in the package logic
• Scoping -enable-testing to test targets only (library targets rarely require it)
• Testing builds with a stable Swift 6.1 release toolchain to catch compatibility issues early

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Installation snippet versioning and LICENSE link robustness

Two small, user-facing nits in this section:

1. Installation snippet versions

   The example uses:

   .package(url: "https://github.com/brightdigit/SundialKitCombine.git", from: "1.0.0")

   Make sure this matches the actual tag you plan to publish (especially since this PR is for v1.0.0-alpha.1). If the first public tag uses a v prefix or a different version, users following the README will get resolution errors. A brief note like “adjust the version to the latest release” would also make the snippet more future-proof.

2. LICENSE link

   The link currently points to:

   [LICENSE](https://github.com/brightdigit/SundialKitCombine/LICENSE)

   That URL typically 404s on GitHub. A relative link is simpler and more robust across branches:

   -This code is distributed under the MIT license. See the [LICENSE](https://github.com/brightdigit/SundialKitCombine/LICENSE) file for more info.
   +This code is distributed under the MIT license. See the [LICENSE](LICENSE) file for more info.

Also applies to: 443-445

🤖 Prompt for AI Agents

In README.md around lines 70-79 (also apply same change at lines 443-445): the
Package.swift snippet hardcodes .package(... from: "1.0.0") which may not match
the actual published tag (v1.0.0-alpha.1) and the LICENSE link points to an
absolute URL that can 404; update the snippet to either match the exact
published tag format or replace the hardcoded version with a brief note telling
users to adjust to the latest release/tag (e.g., “adjust the version to the
latest release/tag”), and change the LICENSE link to a relative path (e.g.,
LICENSE or ./LICENSE) so it works across branches and releases.

[claude]

Pull Request Review: V1.0.0-alpha.1

Overall Assessment

This is a well-structured initial release that introduces Combine-based wrappers for SundialKit's connectivity and network monitoring capabilities. The code demonstrates strong Swift 6 concurrency practices with proper actor isolation. However, there are several areas that need attention before production release.

---

🟢 Code Quality & Best Practices

Strengths

1. Excellent Concurrency Management

   • Proper @MainActor isolation on ConnectivityObserver and NetworkObserver
   • Good use of nonisolated delegate methods with Task hopping to MainActor
   • Values extracted before crossing isolation boundaries (ConnectivityObserver+Delegate.swift:49-54)

2. Clear Architecture

   • Well-organized file structure with logical separation of concerns
   • Good use of extensions to organize functionality
   • Protocol-oriented design with ConnectivitySession abstraction

3. Documentation

   • Comprehensive inline documentation with examples
   • Good use of DocC documentation structure
   • Clear usage examples in comments

4. Platform Support

   • Excellent platform-aware compilation with #if canImport() directives
   • Fallback logging implementation for non-Apple platforms (SundialLogger.swift:102-187)

Areas for Improvement

1. Swift 6 Experimental Features (Package.swift:8-44)

   • Enabling many experimental features can lead to instability
   • Consider: Are all 19 experimental features necessary for an alpha release?
   • Recommendation: Enable only essential features; add others as needed
   • Some features like VariadicGenerics, MoveOnlyClasses may not be used yet

2. Unsafe Compiler Flags (Package.swift:37-44)

   • -enable-testing should not be in production builds
   • Consider moving strict concurrency flags to debug configuration only
   • The -Xfrontend warnings are good for development but verbose for users

---

🔴 Critical Issues

1. Missing Reply Handler Call (ConnectivityObserver+Delegate.swift:198-200)

Location: ConnectivityObserver+Delegate.swift:198-200

// IMPORTANT: Must call reply handler to complete the send operation on sender's side
// Send empty Data as acknowledgment since we don't have a reply payload
// replyHandler(Data())

Issue: The reply handler is commented out, which will cause the sender to timeout waiting for a response.

Impact: This is a blocking bug that will prevent binary message communication from working correctly.

Recommendation:

// Uncomment the reply handler call
replyHandler(Data())

2. No Test Coverage

Location: Tests/SundialKitCombineTests/SundialKitCombineTests.swift

Issue: Only a dummy test exists. For a v1.0.0 release, comprehensive tests are essential.

Missing Test Coverage:

• ConnectivityObserver activation/deactivation
• Message sending and receiving flows
• NetworkObserver path updates
• Error handling scenarios
• Publisher behavior verification
• MessageDecoder integration

Recommendation: Add comprehensive test coverage before promoting to stable release:

• Unit tests for each public API
• Integration tests for message flow
• Mock tests for ConnectivitySession protocol
• Tests for actor isolation behavior

---

🟡 Potential Bugs & Issues

1. Timer Retain Cycle Risk (NetworkObserver.swift:132-141)

Location: NetworkObserver.swift:132-141

While [weak self] is used in the timer closure, the timer itself is not properly invalidated on deinit.

Recommendation:

deinit {
  stop()  // Ensure timer is cleaned up
}

2. Error Swallowing in Delegate Methods

Location: ConnectivityObserver+Delegate.swift:136-141, 165-171, 189-195

Decoding errors are logged but silently swallowed. While this prevents crashes, users have no programmatic way to handle these errors.

Recommendation: Consider adding an error publisher:

public let decodingError = PassthroughSubject<Error, Never>()

3. Dependency on Branch Instead of Version

Location: Package.swift:62

.package(url: "https://github.com/brightdigit/SundialKit.git", branch: "v2.0.0")

Issue: Using branch: instead of from: or exact: means builds are non-deterministic.

Recommendation: Once SundialKit v2.0.0 is tagged, switch to:

.package(url: "https://github.com/brightdigit/SundialKit.git", from: "2.0.0")

4. Platform Availability Mismatch

Location: Package.swift:50-54 vs source files

Package.swift specifies:

• iOS 16+, watchOS 9+, tvOS 16+, macOS 11+

But source files use:

• @available(macOS 10.15, iOS 13, watchOS 6, tvOS 13, *)

Recommendation: Align package platforms with actual minimum requirements or vice versa.

---

⚡ Performance Considerations

1. Combine Publisher Performance

Observation: Using PassthroughSubject is appropriate for this use case, but be aware:

• No replay/buffering of events
• Subscribers must be connected before events occur
• Consider CurrentValueSubject for state that should be immediately available

Current Implementation: Appropriate for message/event streams

2. Actor Hopping Overhead

Location: Multiple Task { @mainactor } calls in delegate methods

Observation: Each delegate callback creates a new Task to hop to MainActor. This is correct for safety but has overhead.

Assessment: Acceptable for typical watch connectivity frequency, but monitor if you're sending high-frequency updates.

---

🔒 Security Concerns

✅ No Critical Security Issues Found

1. Good Practices:

   • No force unwrapping (enforced by SwiftLint)
   • No force try (enforced by SwiftLint)
   • Proper error handling with Result types
   • No sensitive data exposure in logging

2. Minor Considerations:

   • Consider sanitizing logged message contents if they may contain sensitive data
   • Binary message decoding failures are logged with error descriptions (ConnectivityObserver+Delegate.swift:139, 167, 191)

---

📊 Test Coverage

Current State: ❌ Insufficient

Existing Tests: 1 dummy test only

Required for v1.0.0:

• Unit tests for ConnectivityObserver
• Unit tests for NetworkObserver
• Integration tests for message flow
• Publisher behavior tests
• Error handling tests
• Mock-based protocol tests
• Concurrency/actor isolation tests

CI/CD Setup: ✅ Excellent

• Comprehensive matrix testing (Ubuntu + macOS)
• Multiple Swift versions (6.1, 6.2, nightly)
• Multiple platforms (iOS, watchOS)
• Code coverage reporting to Codecov
• CodeQL security scanning

---

📝 Additional Recommendations

1. CI Workflow Improvements

Issue: Xcode 26.x references in CI (SundialKitCombine.yml:52-73)

• These Xcode versions don't exist yet (current is 16.x)
• This suggests CI will fail on these runners

Recommendation: Update to actual Xcode 16.x versions or remove future versions

2. SwiftLint Configuration

The SwiftLint configuration is comprehensive with 80+ opt-in rules. Good practices noted:

• force_unwrapping and force_try are enabled ✅
• missing_docs requires documentation ✅
• Strict file length and function complexity limits ✅

3. Git Configuration

Consider adding .swift-version file for tooling consistency.

4. README & Documentation

The README appears comprehensive based on the diff (444 additions), but ensure:

• Installation instructions are clear
• Minimum deployment targets are documented
• Breaking changes from SundialKit v1.x are noted (if applicable)

---

🎯 Summary

Must Fix Before Release:

1. ❗ Uncomment reply handler in binary message delegate (ConnectivityObserver+Delegate.swift:200)
2. ❗ Add comprehensive test coverage (currently at ~0%)
3. ❗ Fix Xcode version numbers in CI workflow
4. ❗ Change SundialKit dependency from branch to version tag

Should Fix:

1. ⚠️ Reduce experimental Swift features to only what's needed
2. ⚠️ Add deinit to NetworkObserver for timer cleanup
3. ⚠️ Align platform deployment targets between Package.swift and source
4. ⚠️ Consider adding error publisher for decoding failures

Nice to Have:

1. 💡 Add .swift-version file
2. 💡 Move unsafe compiler flags to debug configuration only
3. 💡 Consider adding example project

---

Conclusion

This is a solid foundation for a Combine-based wrapper around SundialKit. The concurrency model is well-designed, and the API surface is clean and intuitive. However, the critical bug in binary message handling and the lack of tests should be addressed before merging to main or releasing as v1.0.0.

For an alpha release, this is acceptable if users understand the limitations, but I'd recommend:

• Fixing the commented reply handler immediately
• Adding test coverage before v1.0.0-beta.1
• Addressing the dependency and CI issues before stable release

Recommended Action: Request changes for critical issues, then approve once fixed.

---

Review conducted using static analysis and manual code inspection. Runtime testing recommended before merge.

[claude]

Code Review: SundialKitCombine v1.0.0-alpha.1

Summary

This is a well-structured initial release that implements a Combine-based observation layer for SundialKit. The code demonstrates strong adherence to Swift 6+ concurrency practices with proper @MainActor isolation and thoughtful architecture.

---

✅ Strengths

Architecture & Design

• Clean separation of concerns: The observer pattern is well-implemented with clear responsibilities
• Strict concurrency compliance: Excellent use of @MainActor isolation without relying on @unchecked Sendable
• Platform awareness: Good use of conditional compilation for platform-specific features
• Comprehensive documentation: CLAUDE.md provides excellent guidance for future development

Code Quality

• Consistent style: Follows project conventions (2-space indentation, 100 char line length)
• Good use of extensions: Code organization into logical extensions (MessageHandling, Methods, StateChanges, SessionLifecycle)
• Proper error handling: Errors are propagated appropriately with typed throws

---

🔍 Issues & Recommendations

1. Critical Bug: Unreachable Reply Handler

Location: ConnectivityObserver+MessageHandling.swift:146-149

The reply handler is commented out, which will cause the sender's continuation to hang indefinitely waiting for a response.

Recommendation: Either uncomment replyHandler(Data()) if acknowledgment is needed, document why it's commented, or remove the method if binary messages with reply handlers aren't supported.

---

2. Potential Race Condition: Timer on Main Thread

Location: NetworkObserver.swift:133-142

Timer.scheduledTimer creates a timer on the current RunLoop, but setupPingTimer isn't marked as @MainActor. If called from a background queue, the timer won't fire.

Recommendation: Mark setupPingTimer as @MainActor to ensure it runs on the main thread.

---

3. Test Coverage: Minimal Testing

Location: Tests/SundialKitCombineTests/SundialKitCombineTests.swift

Only contains a dummy test that always passes. No actual functionality is tested.

Recommendation: Add tests for NetworkObserver state updates, ConnectivityObserver message routing, error handling paths, MessageDecoder error cases, and mock-based testing.

---

4. Inconsistent Error Logging

Location: ConnectivityObserver+MessageHandling.swift:68-74, 104-111, 137-143

Decoding errors are logged but silently swallowed. Users have no way to observe decoding failures.

Recommendation: Add a publisher for decoding errors to allow consumers to monitor and react to decoding issues.

---

5. Missing Property: isReachable

Location: NetworkObserver.swift

The example in documentation references observer.$isReachable (line 57-61), but NetworkObserver doesn't have an isReachable property—only pathStatus.

Recommendation: Either add the property or update documentation examples.

---

6. Script Portability Issue

Location: Scripts/lint.sh:24

readlink -f is not available on macOS by default (GNU coreutils vs BSD).

Recommendation: Use portable shell commands instead.

---

7. Dependency Version Constraint

Location: Package.swift:62

Using from: with an alpha version allows any future alpha/beta/release, which could introduce breaking changes unexpectedly.

Recommendation: Use exact version for alpha releases.

---

8. CI Workflow: Potential Matrix Explosion

Location: .github/workflows/SundialKitCombine.yml:49-111

12 matrix combinations for macOS builds is comprehensive but expensive and slow.

Recommendation: For alpha releases, consider testing only latest Xcode versions and expanding matrix only for release candidates.

---

9. Missing Public API Documentation

Location: Multiple files

Some public methods lack documentation (e.g., ConnectivityObserver.activate(), ConnectivityObserver.sendMessage()).

Recommendation: Add DocC-style documentation to all public APIs per the AllPublicDeclarationsHaveDocumentation rule.

---

10. Logger Fallback Limitations

Location: SundialLogger.swift:102-189

The fallback logger doesn't support the full OSLog API.

Recommendation: Document the limitations in CLAUDE.md.

---

🔒 Security Considerations

✅ No major security concerns identified

• Proper use of Sendable for cross-isolation data
• No force unwrapping in production code paths
• Message validation appears to be handled by underlying SundialKit protocols

Minor recommendation: Consider adding input validation for message sizes to prevent memory exhaustion.

---

📊 Performance Considerations

• The ping timer is scheduled on the main RunLoop. For apps with heavy UI interaction, consider using a background DispatchQueue.
• PassthroughSubject doesn't replay values. Consider using CurrentValueSubject for state publishers if replay semantics are needed.

---

🎯 Overall Assessment

Code Quality: ⭐⭐⭐⭐½ (4.5/5)
Architecture: ⭐⭐⭐⭐⭐ (5/5)
Test Coverage: ⭐⭐☆☆☆ (2/5)
Documentation: ⭐⭐⭐⭐⭐ (5/5)

Verdict

This is a strong foundation for v1.0.0-alpha.1. The architecture is sound, concurrency handling is exemplary, and the code is well-organized.

Main Areas for Improvement:

1. ✋ Block merging until the commented reply handler bug is addressed
2. Add meaningful test coverage before beta
3. Fix timer setup race condition
4. Address documentation gaps

Recommended Next Steps:

1. Fix the reply handler bug (critical)
2. Add basic integration tests
3. Consider the isReachable property inconsistency
4. Update dependency constraint for alpha stability

---

Great work on this initial release! The foundation is solid and follows Swift best practices admirably. 🚀

---

Review conducted by Claude Code using repository guidelines from CLAUDE.md

[coderabbitai]

Actionable comments posted: 3

♻️ Duplicate comments (4)

Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift (2)

87-114: Unused error parameter still not addressed.

The error parameter (line 90) is declared but never used. This was previously flagged. For consistency with other error handling in this codebase, consider logging it:

  Task { @MainActor in
+   if let error = error {
+     if #available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *) {
+       SundialLogger.combine.error(
+         "Application context error: \(String(describing: error))"
+       )
+     }
+   }
+
    // Send to raw publisher

---

125-150: Reply handler still commented out - sender will hang.

The comment on lines 146-147 states the reply handler "MUST" be called, but line 148 is commented out. This was previously flagged as a critical issue. The sender's coroutine will wait indefinitely for a response.

Additionally, unlike the other two handlers, this method doesn't publish to messageReceived (raw publisher). This inconsistency means binary messages are not observable through the raw message stream.

Uncomment the reply handler and consider adding raw publisher support:

        }
      }

-     // IMPORTANT: Must call reply handler to complete the send operation on sender's side
-     // Send empty Data as acknowledgment since we don't have a reply payload
-     // replyHandler(Data())
+     // Call reply handler to complete the send operation on sender's side
+     replyHandler(Data())
    }
  }

README.md (1)

33-33: Inconsistent platform version in Overview section.

Line 33 states "iOS 13+" but the Requirements section (lines 62-65) and Package.swift correctly specify iOS 16+ as the minimum. This is part of the broader platform support inconsistency already flagged.

Sources/SundialKitCombine/NetworkObserver.swift (1)

46-61: Documentation example doesn't match the actual API.

The example shows NetworkObserver() with no arguments and uses observer.$isReachable, but:

1. The default initializer at line 195 only works when both MonitorType == NWPathMonitor and PingType == NeverPing (requires canImport(Network))
2. There is no isReachable property - available properties are pathStatus, isExpensive, isConstrained, and pingStatus

Update the example to match the actual API:

  /// ```swift
  /// import SundialKitCombine
+ /// import SundialKitNetwork
  ///
  /// let observer = NetworkObserver()
  /// observer.start()
  ///
  /// // Observe path status changes
  /// observer.$pathStatus
  ///   .sink { status in
  ///     print("Network status: \(status)")
  ///   }
  ///   .store(in: &cancellables)
  ///
- /// // Observe reachability
- /// observer.$isReachable
- ///   .sink { isReachable in
- ///     print("Reachable: \(isReachable)")
+ /// // Observe expensive connection
+ /// observer.$isExpensive
+ ///   .sink { isExpensive in
+ ///     print("Expensive: \(isExpensive)")
  ///   }
  ///   .store(in: &cancellables)
  /// ```

🧹 Nitpick comments (1)

CLAUDE.md (1)

112-112: Use proper heading syntax for better document structure.

The "Message Types" section uses bold text instead of a Markdown heading, which can affect document parsing and navigation.

Apply this diff:

-**Message Types**
+### Message Types

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 70c5854 and 6aaf2a3.

📒 Files selected for processing (13)

• .github/workflows/SundialKitCombine.yml (1 hunks)
• .github/workflows/codeql.yml (1 hunks)
• CLAUDE.md (1 hunks)
• Package.resolved (1 hunks)
• Package.swift (1 hunks)
• README.md (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver+SessionLifecycle.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver+StateChanges.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivityObserver.swift (1 hunks)
• Sources/SundialKitCombine/ConnectivitySession.swift (1 hunks)
• Sources/SundialKitCombine/NetworkObserver.swift (1 hunks)
• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• Package.resolved

🚧 Files skipped from review as they are similar to previous changes (3)

• Sources/SundialKitCombine/SundialKitCombine.docc/Documentation.md
• Sources/SundialKitCombine/ConnectivitySession.swift
• Sources/SundialKitCombine/ConnectivityObserver.swift

🧰 Additional context used

🧬 Code graph analysis (2)

Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift (3)

Sources/SundialKitCombine/ConnectivityObserver+SessionLifecycle.swift (1)

• session (50-78)

Sources/SundialKitCombine/ConnectivityObserver+Methods.swift (1)

• send (140-171)

Sources/SundialKitCombine/SundialLogger.swift (1)

• error (118-120)

Sources/SundialKitCombine/ConnectivityObserver+SessionLifecycle.swift (1)

Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift (3)

• session (53-76)
• session (87-114)
• session (125-150)

🪛 actionlint (1.7.8)

.github/workflows/SundialKitCombine.yml

21-21: duplicate value {"nightly": "true", "version": "6.1"} is found in matrix "swift". the same value is at line:19,col:13

(matrix)

---

23-23: duplicate value {"nightly": "true", "version": "6.2"} is found in matrix "swift". the same value is at line:20,col:13

(matrix)

🪛 LanguageTool

CLAUDE.md

[uncategorized] ~229-~229: The official name of this software platform is spelled with a capital “H”.
Context: ...s) ## CI/CD GitHub Actions workflows (.github/workflows/): - SundialKitCombine.yml...

(GITHUB)

🪛 markdownlint-cli2 (0.18.1)

CLAUDE.md

112-112: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: claude-review
• GitHub Check: Analyze (swift)
• GitHub Check: Analyze (swift)

🔇 Additional comments (11)

Sources/SundialKitCombine/ConnectivityObserver+StateChanges.swift (2)

46-53: LGTM!

The value extraction before crossing the isolation boundary is correctly implemented. This ensures Sendable compliance when dispatching to the MainActor.

---

61-74: LGTM!

The platform-specific handling for isPaired (iOS-only) is correctly guarded with #if os(iOS), and the value extraction pattern is consistent with other handlers.

Sources/SundialKitCombine/ConnectivityObserver+SessionLifecycle.swift (2)

50-78: LGTM!

The activation completion handler correctly:

1. Extracts all session state before crossing the isolation boundary
2. Updates published properties on the MainActor
3. Publishes success/failure through activationCompleted publisher

The error handling pattern with Result<ActivationState, Error> is clean and idiomatic.

---

86-108: LGTM!

Both lifecycle handlers (sessionDidBecomeInactive and sessionDidDeactivate) follow the established pattern of extracting values before crossing the isolation boundary and updating state on the MainActor.

Sources/SundialKitCombine/ConnectivityObserver+MessageHandling.swift (1)

53-76: LGTM!

The dictionary message handler correctly:

1. Creates a ConnectivityReceiveResult with the reply handler context for downstream consumers
2. Publishes to raw publisher first, ensuring messages aren't lost on decode failure
3. Gracefully handles decoding errors with logging while still delivering raw messages

.github/workflows/codeql.yml (1)

1-82: LGTM!

The CodeQL workflow is well-configured with appropriate triggers, permissions, and build steps. The Xcode 16.4 selection aligns with the project's Xcode 16.0+ requirement.

.github/workflows/SundialKitCombine.yml (2)

51-54: Verify future runner and Xcode versions are available.

The workflow references macos-26 runner with Xcode 26.1 and 26.0, which are future versions beyond the current Xcode 16.x series. Ensure these runners and Xcode versions are available in your GitHub Actions environment before this workflow runs.

Based on learnings, forward-looking configurations are acceptable if intentional, but they may cause workflow failures if the infrastructure isn't ready yet.

---

78-79: I'll search for information about iOS simulator device names and iPhone naming conventions to verify whether "iPhone 16e" is valid.

Now let me verify the iOS version:

Let me check how GitHub Actions references iOS simulator device names:

Based on my research, I can now provide a comprehensive analysis and rewrite the review comment.

The verification has confirmed that:

The iPhone 16e is an entry-level iPhone model released on February 28, 2025, and the iPhone 16e was originally supplied with iOS 18.3 for release on February 28, 2025. iOS 18.5 was released on May 13, 2025, so both the device and OS version are valid.

However, the concern in the original review comment is legitimate from a CI/CD perspective: For GitHub Actions runners, a fresh list of devices is maintained in the Wiki of this project, indicating that simulator availability depends on what's pre-installed in GitHub Actions macOS runners. Since iPhone 16e is a very recent device (February 2025), it may not yet be available in the standard pre-installed simulators on GitHub Actions runners, which typically lag behind the latest device releases.

---

Verify iPhone 16e simulator availability in GitHub Actions runners.

The device name and iOS version are technically valid, but GitHub Actions maintains a list of pre-installed simulator devices, and it's recommended to verify device availability since UDID and OS version can change when runner images are updated. Since iPhone 16e was released in February 2025, it may not yet be included in the standard macos-latest runner image. Consider verifying that this simulator is available in your GitHub Actions environment or using a more established device like iPhone 16 or iPhone 16 Pro as an alternative.

Sources/SundialKitCombine/NetworkObserver.swift (1)

64-64: Availability attributes more permissive than package platforms.

The @available annotation specifies macOS 10.15, iOS 13, watchOS 6, tvOS 13, but Package.swift declares minimum platforms as iOS 16, watchOS 9, tvOS 16, macOS 11. This means the code advertises broader compatibility than the package enforces.

Verify whether:

1. The package platforms should be relaxed to match the availability attributes, or
2. The availability attributes should be updated to match the package platforms

This relates to the broader platform support inconsistency flagged in the README.

CLAUDE.md (1)

229-229: Correct the GitHub capitalization.

The official product name is "GitHub Actions" with a capital "H".

Apply this diff:

-GitHub Actions workflows (`.github/workflows/`):
+GitHub Actions workflows (`.github/workflows/`):

Likely an incorrect or invalid review comment.

Package.swift (1)

62-62: Dependency verified as available and accessible.

The SundialKit repository exists and version 2.0.0-alpha.1 is published and accessible. No action required.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Remove duplicate matrix entries.

The matrix contains duplicate entries for Swift 6.1 and 6.2. Lines 19-20 define non-nightly builds for these versions, while lines 21-24 define nightly builds with the same version numbers. However, the way the matrix is structured, lines 21 and 23 create duplicates because they specify the same version without additional distinguishing keys that affect the container selection.

The intended logic appears to be:

• Build with stable Swift 6.1 and 6.2
• Build with nightly Swift 6.1 and 6.2

Apply this diff to fix the matrix structure:

     matrix:
       os: [noble, jammy]
       swift:
         - version: "6.1"
+           nightly: false
         - version: "6.2"
+           nightly: false
         - version: "6.1"
           nightly: true
         - version: "6.2"
           nightly: true

Or if the intention is to only test nightly OR stable builds (not both), remove the duplicate entries:

     matrix:
       os: [noble, jammy]
       swift:
         - version: "6.1"
         - version: "6.2"
-        - version: "6.1"
-          nightly: true
-        - version: "6.2"
-          nightly: true

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	swift:
	- version: "6.1"
	- version: "6.2"
	- version: "6.1"
	nightly: true
	- version: "6.2"
	nightly: true
	swift:
	- version: "6.1"
	nightly: false
	- version: "6.2"
	nightly: false
	- version: "6.1"
	nightly: true
	- version: "6.2"
	nightly: true

🧰 Tools

🪛 actionlint (1.7.8)

21-21: duplicate value {"nightly": "true", "version": "6.1"} is found in matrix "swift". the same value is at line:19,col:13

(matrix)

---

23-23: duplicate value {"nightly": "true", "version": "6.2"} is found in matrix "swift". the same value is at line:20,col:13

(matrix)

🤖 Prompt for AI Agents

.github/workflows/SundialKitCombine.yml around lines 18 to 24: the Swift matrix
currently has duplicate plain-version entries (6.1 and 6.2) and separate nightly
flags that create ambiguous duplicates; replace the flat list with unique matrix
entries that pair version and nightly as explicit objects (e.g., { version:
"6.1", nightly: false }, { version: "6.2", nightly: false }, { version: "6.1",
nightly: true }, { version: "6.2", nightly: true }) so each combination is
distinct, or if you only want stable OR nightly builds remove the unwanted group
entirely so no duplicate version-only entries remain.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Correct the Swift version reference.

The text refers to "Swift 6.2 upcoming features," but Package.swift line 1 declares swift-tools-version: 6.1, and line 12 of this file confirms "Swift 6.1+ with strict concurrency enabled."

Apply this diff to correct the version:

-The package enables extensive Swift 6.2 upcoming features and experimental features (see `Package.swift:8-45`):
+The package enables extensive Swift 6.1 upcoming features and experimental features (see `Package.swift:8-45`):

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	The package enables extensive Swift 6.2 upcoming features and experimental features (see `Package.swift:8-45`):
	The package enables extensive Swift 6.1 upcoming features and experimental features (see `Package.swift:8-45`):

🤖 Prompt for AI Agents

In CLAUDE.md around line 126, the text incorrectly refers to "Swift 6.2 upcoming
features" while Package.swift declares swift-tools-version: 6.1 and the file
notes "Swift 6.1+ with strict concurrency enabled"; update the sentence to
reference Swift 6.1 (or "Swift 6.1+" if you want to allow newer 6.x) and keep
the parenthetical pointer to Package.swift:8-45 intact, ensuring the wording
mentions strict concurrency enabled if present elsewhere in the doc.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Extensive experimental features enabled - ensure compatibility.

The manifest enables 18 experimental features and 4 upcoming features. While this aligns with the project's Swift 6.1+ strict concurrency goals documented in CLAUDE.md, these features may have stability or compatibility implications.

Consider verifying that all experimental features compile successfully across the target platforms, especially on the minimum supported versions (iOS 16, watchOS 9, tvOS 16, macOS 11).

---

🏁 Script executed:

#!/bin/bash
# Verify the package builds with all experimental features enabled
swift build --build-tests

Length of output: 43

---

I cannot verify the build directly in this environment since the Swift compiler isn't available. Let me gather information about the experimental features and check the codebase for build configuration context.

Let me check the codebase for CI/CD configuration and platform specifications to verify the experimental features across target platforms.

---

🏁 Script executed:

```shell
#!/bin/bash
# Look for CI/CD workflow files
fd -e yml -e yaml -e yaml.lock | head -20

Length of output: 11

---

🏁 Script executed:

#!/bin/bash
# Check Package.swift for deployment targets and platform specifications
cat Package.swift | head -100

Length of output: 2651

---

Let me check the CI configuration and verify the Swift tools version compatibility.

Let me check the CI configuration file to understand the build setup:

---

🏁 Script executed:

#!/bin/bash
# Check the project.yml CI configuration
cat project.yml

Length of output: 252

---

Let me search for specific information about Swift 6.1 compatibility with Swift 6.2 features:

---

🌐 Web query:

Swift 6.1 compiler supports Swift 6.2 upcoming features enableUpcomingFeature

💡 Result:

Short answer: No — the Swift 6.1 compiler only exposes the upcoming-feature flags it ships with. An upcoming feature added in the Swift 6.2 toolchain won’t be available to Swift 6.1; to enable a Swift 6.2 upcoming feature you must use a Swift 6.2 (or later/nightly) toolchain that defines that feature flag. [1][2][3]

Sources:

• Swift.org blog: Using Upcoming Feature Flags / how -enable-upcoming-feature works. [1]
• Swift 5.8 / Swift.org notes explaining the mechanism and that features are provided by the compiler/toolchain. [2]
• Third-party flag index showing separate listings for Swift 6.1 vs Swift 6.2 toolchains. [3]

---

Update swift-tools-version to 6.2 to enable Swift 6.2 upcoming features.

The Swift 6.1 compiler only exposes the upcoming-feature flags it ships with. An upcoming feature added in the Swift 6.2 toolchain won't be available to Swift 6.1. The package currently specifies swift-tools-version: 6.1 but attempts to enable Swift 6.2 features (ExistentialAny, InternalImportsByDefault, MemberImportVisibility, FullTypedThrows). This will fail at build time with unrecognized feature flag errors.

Update the first line of Package.swift to // swift-tools-version: 6.2 to resolve the compilation failure.

🤖 Prompt for AI Agents

In Package.swift around lines 8 to 45, the package enables Swift 6.2
upcoming-feature flags but the package manifest still declares
swift-tools-version 6.1; update the first line of Package.swift to "//
swift-tools-version: 6.2" so the 6.2 upcoming features are recognized by the
tools and ensure the CI/toolchain uses Swift 6.2 or newer.