Merge remote-tracking branch 'origin/main' into merge-protocol-v6-into-main

Author: lawrence-forooghian

.cursor/rules/specification.mdc

@@ -23,3 +23,37 @@ swift run BuildTool lint
 ```
 
 Use `--fix` to auto-fix where possible.
+
+## Specification Document
+
+The _Specification Document_ (or simply "the specification" or "the spec") specifies much of the behaviour of this codebase. It lives in the `specification` repository. If you need to consult it and you haven't been told where to find a local copy, ask.
+
+- The specification is structured as a list of specification points, each with an identifier such as `OD1`. Some specification points have subpoints, e.g. `REC2a`, which in turn can have subpoints like `REC2a1`. In the specification's Markdown source, the start of specification point `OD1` is represented by `` `(OD1)` ``.
+- The LiveObjects functionality is referred to in the specification simply as "Objects". The LiveObjects-specific spec points are in a separate file, `specifications/objects-features.md`.
+- If you are given a task that requires knowledge of the specification, you must consult it before proceeding. Never guess its contents.
+- If the specification is unclear, mention this.
+
+## Swift style
+
+- Satisfy SwiftLint's `explicit_acl` rule (all declarations must specify access control level keywords explicitly).
+  - When writing an `extension` of a type, prefer placing the access level on the extension declaration rather than on each individual member.
+  - This does not apply to test code.
+- When the type being initialised can be inferred, use the implicit `.init(…)` form instead of writing the type name explicitly.
+- When the enum type can be inferred, use the implicit `.caseName` form instead of writing the type name explicitly.
+- When writing `JSONValue` or `WireValue` types, use the literal syntax enabled by their `ExpressibleBy*Literal` conformances where possible.
+- When writing a JSON string, use Swift raw string literals instead of escaping double quotes.
+- When importing these modules in library (non-test) code:
+  - Ably: `import Ably`
+  - `_AblyPluginSupportPrivate`: `internal import _AblyPluginSupportPrivate`
+- When writing an array literal that starts with an initialiser expression, start the initialiser on the line after the opening square bracket:
+
+  ```swift
+  // Do this:
+  objectMessages: [
+      InboundObjectMessage(
+          id: nil,
+
+  // Not this:
+  objectMessages: [InboundObjectMessage(
+      id: nil,
+  ```

.cursor/rules/swift.mdc

@@ -21,12 +21,12 @@ let package = Package(
         // TODO: Unpin before release
         .package(
             url: "https://github.com/ably/ably-cocoa.git",
-            revision: "460c1d11333dd58bbc924a3d153d1364b39bbdf0",
+            revision: "68e9b6fc786f0c2c425d095b3cf3366844fd0507",
         ),
         // TODO: Unpin before release
         .package(
             url: "https://github.com/ably/ably-cocoa-plugin-support",
-            revision: "f2468ee39f3e18955b0ec4fe41dc5a9906a72633",
+            revision: "36c529db38154d01537e782f7ed4aa7535fb3237",
         ),
         .package(
             url: "https://github.com/apple/swift-argument-parser",
@@ -72,6 +72,9 @@ let package = Package(
                     package: "ably-cocoa-plugin-support",
                 ),
             ],
+            exclude: [
+                "CLAUDE.md",
+            ],
             resources: [
                 .copy("ably-common"),
             ],

.cursor/rules/testing.mdc

@@ -0,0 +1,15 @@
+# Testing guidelines
+
+- Use the Swift Testing framework (`import Testing`), not XCTest.
+- Do not use `fatalError` in response to a test expectation failure; use Swift Testing's `#require` macro instead.
+- Only add labels to test cases or suites when the label differs from the name of the suite `struct` or test method.
+- Follow the guidelines under "Attributing tests to a spec point" in `CONTRIBUTING.md` to tag unit tests with the relevant specification points. Follow the exact comment format described there. Pay particular attention to the difference between `@spec` and `@specPartial`, and do not write `@spec` multiple times for the same specification point.
+- Add comments explaining when some piece of test data is not important for the scenario being tested.
+- Run the tests to check they pass.
+- When importing these modules in test code:
+  - Ably: `import Ably`
+  - AblyLiveObjects: `@testable import AblyLiveObjects`
+  - `_AblyPluginSupportPrivate`: `import _AblyPluginSupportPrivate` (not `internal import`)
+- When you need to pass a logger to internal components in tests, pass `TestLogger()`.
+- When you need to unwrap an optional value in tests, use `#require` instead of `guard let`.
+- When creating `testsOnly_` property declarations, do not write generic comments describing them; their meaning is already well understood.