@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/supabase/POWER.md

@@ -0,0 +1,67 @@
+````markdown
+---
+inclusion: manual
+name: supabase
+description: "Use when the task is specifically Supabase: managed Postgres with RLS, auth, storage, edge functions, branching, and product decisions that depend on Supabase platform behavior."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Supabase
+
+## Purpose
+
+Use when the task is specifically Supabase: managed Postgres with RLS, auth, storage, edge functions, branching, and product decisions that depend on Supabase platform behavior.
+
+## When to Use
+
+- The stack is Supabase and platform features such as RLS, auth, storage, or edge functions affect the answer.
+- The task depends on how managed Postgres behavior interacts with Supabase product surfaces.
+- You need Supabase-specific migration, policy, or operational guidance.
+
+## Instructions
+
+1. Confirm which Supabase surfaces are in play: Postgres, RLS, Auth, Storage, Realtime, or Edge Functions.
+2. Separate pure Postgres design from platform policy and developer-experience constraints.
+3. Design schema, policies, and integration boundaries together so access control stays coherent.
+4. Validate migrations, branching, and operational rollout against Supabase’s managed posture.
+5. Report platform-specific limits, coupling, and rollback considerations explicitly.
+
+### Baseline standards
+
+- Treat RLS and auth flows as core design inputs, not afterthoughts.
+- Keep database policy logic understandable and testable.
+- Use plain Postgres reasoning first, then add Supabase-specific constraints.
+- Make platform lock-in or coupling explicit when it affects long-term architecture.
+
+### Constraints
+
+- Avoid mixing product policy and schema logic without clear ownership.
+- Avoid overcomplicating RLS rules with no test strategy.
+- Avoid assuming Supabase convenience removes the need for migration discipline.
+- Avoid treating Supabase as generic Postgres when platform behavior clearly matters.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File | Load when |
+| --- | --- |
+| `references/supabase-checklist.md` | You need deeper Supabase guidance for RLS, auth, storage, platform coupling, and managed rollout decisions. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with supabase best practices in this project"
+- "Review my supabase implementation for issues"
+````

package/workflows/powers/supabase/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: supabase
+description: "Use when the task is specifically Supabase: managed Postgres with RLS, auth, storage, edge functions, branching, and product decisions that depend on Supabase platform behavior."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Supabase
+
+## Purpose
+
+Use when the task is specifically Supabase: managed Postgres with RLS, auth, storage, edge functions, branching, and product decisions that depend on Supabase platform behavior.
+
+## When to Use
+
+- The stack is Supabase and platform features such as RLS, auth, storage, or edge functions affect the answer.
+- The task depends on how managed Postgres behavior interacts with Supabase product surfaces.
+- You need Supabase-specific migration, policy, or operational guidance.
+
+## Instructions
+
+1. Confirm which Supabase surfaces are in play: Postgres, RLS, Auth, Storage, Realtime, or Edge Functions.
+2. Separate pure Postgres design from platform policy and developer-experience constraints.
+3. Design schema, policies, and integration boundaries together so access control stays coherent.
+4. Validate migrations, branching, and operational rollout against Supabase’s managed posture.
+5. Report platform-specific limits, coupling, and rollback considerations explicitly.
+
+### Baseline standards
+
+- Treat RLS and auth flows as core design inputs, not afterthoughts.
+- Keep database policy logic understandable and testable.
+- Use plain Postgres reasoning first, then add Supabase-specific constraints.
+- Make platform lock-in or coupling explicit when it affects long-term architecture.
+
+### Constraints
+
+- Avoid mixing product policy and schema logic without clear ownership.
+- Avoid overcomplicating RLS rules with no test strategy.
+- Avoid assuming Supabase convenience removes the need for migration discipline.
+- Avoid treating Supabase as generic Postgres when platform behavior clearly matters.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File | Load when |
+| --- | --- |
+| `references/supabase-checklist.md` | You need deeper Supabase guidance for RLS, auth, storage, platform coupling, and managed rollout decisions. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with supabase best practices in this project"
+- "Review my supabase implementation for issues"

package/workflows/powers/supabase/references/supabase-checklist.md

@@ -0,0 +1,19 @@
+# Supabase Checklist
+
+Load this when Supabase platform behavior is more important than generic Postgres guidance.
+
+## Surface identification
+
+- Confirm whether the task is about Postgres, RLS, Auth, Storage, Realtime, or Edge Functions.
+- Separate plain database design from product-surface coupling.
+
+## Access control
+
+- Treat RLS and auth rules as core design work.
+- Keep policies understandable and testable.
+- Re-check who is authorized at the database boundary, not only in app code.
+
+## Rollout
+
+- Make migration, branching, and rollback posture explicit.
+- Note platform coupling and lock-in where it affects long-term architecture.

package/workflows/powers/swift-pro/POWER.md

@@ -0,0 +1,118 @@
+````markdown
+---
+inclusion: manual
+name: swift-pro
+description: "Use for modern Swift 6.1-era application and systems engineering with strong concurrency, protocol boundaries, package structure, and Apple-platform correctness."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Swift Pro
+
+## Purpose
+
+Use for modern Swift 6.1-era application and systems engineering with strong concurrency, protocol boundaries, package structure, and Apple-platform correctness.
+
+## When to Use
+
+- Building or refactoring Swift application, package, or platform code.
+- Tightening Swift concurrency, Sendable safety, and package structure.
+- Improving protocol boundaries, async code, and testability.
+
+## Instructions
+
+1. Confirm platform targets and package boundaries.
+2. Keep concurrency annotations and ownership rules explicit.
+3. Prefer protocol-driven seams where they improve testing or substitution.
+4. Reduce shared mutable state and actor-boundary confusion.
+5. Validate with focused tests and compiler-clean concurrency output.
+
+### Baseline standards
+
+- Enable strict concurrency checking (`-strict-concurrency=complete`). Fix all diagnostics.
+- Use `Sendable` conformance on all types that cross isolation boundaries.
+- Prefer `let` over `var`. Mutable state must be justified and contained.
+- Use access control (`public`, `internal`, `private`, `fileprivate`) deliberately. Default to `private`.
+- Keep Swift Package Manager as the primary dependency manager. Pin exact versions in `Package.resolved`.
+
+### Concurrency (Swift 6)
+
+- Use `async`/`await` for all asynchronous work. Eliminate completion handler callbacks in new code.
+- Use `actor` for mutable state that needs thread-safe access. Keep actor methods focused and fast.
+- Use `@MainActor` for UI-bound state and methods. Never call `MainActor.run` from UI code — annotate instead.
+- Use `Task` and `TaskGroup` for structured concurrency. Cancel child tasks explicitly when the parent scope ends.
+- Use `AsyncSequence` and `AsyncStream` for event-driven data flow.
+- Avoid `nonisolated(unsafe)` unless you can prove thread safety with external synchronization.
+
+### Sendable safety
+
+- Value types (`struct`, `enum`) are `Sendable` when all stored properties are `Sendable`.
+- Reference types must explicitly conform to `Sendable` — use `@unchecked Sendable` only with audited manual synchronization.
+- Use `sending` parameter annotation (Swift 6) when transferring ownership of a value into another isolation domain.
+- Closures crossing isolation boundaries must capture only `Sendable` values.
+
+### Protocol-oriented design
+
+- Use protocols to define capability contracts at module boundaries.
+- Prefer protocol extensions for default implementations over base classes.
+- Use `some Protocol` (opaque types) for return types to hide concrete implementations.
+- Use `any Protocol` (existential types) only when dynamic dispatch is genuinely needed — it has runtime cost.
+- Keep protocol requirements minimal. Clients should not be forced to implement methods they don't need.
+
+### Error handling
+
+- Use `throws` for recoverable errors. Use typed throws (`throws(MyError)`) in Swift 6 when the error domain is closed.
+- Define specific error enums per module. Include context (e.g., the ID that wasn't found).
+- Use `Result` when errors must be stored or passed as values.
+- Use `do`/`catch` at the boundary layer (view model, controller). Don't catch errors deep in business logic unless recovery is possible.
+
+### Testing
+
+- Use Swift Testing framework (`@Test`, `#expect`) for new test targets. XCTest for existing targets.
+- Use protocol-based dependency injection for testable architecture. Avoid singletons.
+- Test async code with `await` — Swift Testing supports async test functions natively.
+- Use `confirmation()` for testing actor-isolated behavior.
+- Keep tests fast: mock network and persistence. No real I/O in unit tests.
+
+### Package structure
+
+- Organize code into focused packages/modules with clear public APIs.
+- Use `Package.swift` targets to enforce module boundaries. Keep target dependency graphs acyclic.
+- Export only the public API. Use `internal` for implementation details.
+- Use `@testable import` only in test targets — never in production code.
+
+### Constraints
+
+- Avoid force unwrapping (`!`) without a preceding guard or nil check.
+- Avoid massive view controllers or view models — split into focused components.
+- Avoid `class` when `struct` would suffice — value types are cheaper, safer, and `Sendable` by default.
+- Avoid `DispatchQueue` for new concurrent code — use Swift concurrency instead.
+- Avoid retain cycles from strong `self` captures in closures — use `[weak self]` or `[unowned self]` appropriately.
+- Avoid global mutable state (`static var`) — use actor isolation or dependency injection.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                            | Load when                                                                                                                                 |
+| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `references/swift-concurrency-and-protocols.md` | Swift concurrency migration, Sendable audit, actor design, protocol-oriented architecture, or structured concurrency patterns are needed. |
+| `references/concurrency-patterns.md`            | You need actor design, TaskGroup usage, AsyncSequence/AsyncStream, or MainActor annotation strategies.                                    |
+| `references/sendable-and-isolation.md`          | You need Sendable conformance patterns, isolation boundary crossing, or @unchecked Sendable audit guidance.                               |
+| `references/protocol-and-generics.md`           | You need protocol-oriented design, opaque types, existentials, associated types, or generic constraint patterns.                          |
+| `references/testing-and-packages.md`            | You need Swift Testing framework patterns, dependency injection for tests, or Package.swift module organization.                          |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with swift pro best practices in this project"
+- "Review my swift pro implementation for issues"
+````

package/workflows/powers/swift-pro/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: swift-pro
+description: "Use for modern Swift 6.1-era application and systems engineering with strong concurrency, protocol boundaries, package structure, and Apple-platform correctness."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Swift Pro
+
+## Purpose
+
+Use for modern Swift 6.1-era application and systems engineering with strong concurrency, protocol boundaries, package structure, and Apple-platform correctness.
+
+## When to Use
+
+- Building or refactoring Swift application, package, or platform code.
+- Tightening Swift concurrency, Sendable safety, and package structure.
+- Improving protocol boundaries, async code, and testability.
+
+## Instructions
+
+1. Confirm platform targets and package boundaries.
+2. Keep concurrency annotations and ownership rules explicit.
+3. Prefer protocol-driven seams where they improve testing or substitution.
+4. Reduce shared mutable state and actor-boundary confusion.
+5. Validate with focused tests and compiler-clean concurrency output.
+
+### Baseline standards
+
+- Enable strict concurrency checking (`-strict-concurrency=complete`). Fix all diagnostics.
+- Use `Sendable` conformance on all types that cross isolation boundaries.
+- Prefer `let` over `var`. Mutable state must be justified and contained.
+- Use access control (`public`, `internal`, `private`, `fileprivate`) deliberately. Default to `private`.
+- Keep Swift Package Manager as the primary dependency manager. Pin exact versions in `Package.resolved`.
+
+### Concurrency (Swift 6)
+
+- Use `async`/`await` for all asynchronous work. Eliminate completion handler callbacks in new code.
+- Use `actor` for mutable state that needs thread-safe access. Keep actor methods focused and fast.
+- Use `@MainActor` for UI-bound state and methods. Never call `MainActor.run` from UI code — annotate instead.
+- Use `Task` and `TaskGroup` for structured concurrency. Cancel child tasks explicitly when the parent scope ends.
+- Use `AsyncSequence` and `AsyncStream` for event-driven data flow.
+- Avoid `nonisolated(unsafe)` unless you can prove thread safety with external synchronization.
+
+### Sendable safety
+
+- Value types (`struct`, `enum`) are `Sendable` when all stored properties are `Sendable`.
+- Reference types must explicitly conform to `Sendable` — use `@unchecked Sendable` only with audited manual synchronization.
+- Use `sending` parameter annotation (Swift 6) when transferring ownership of a value into another isolation domain.
+- Closures crossing isolation boundaries must capture only `Sendable` values.
+
+### Protocol-oriented design
+
+- Use protocols to define capability contracts at module boundaries.
+- Prefer protocol extensions for default implementations over base classes.
+- Use `some Protocol` (opaque types) for return types to hide concrete implementations.
+- Use `any Protocol` (existential types) only when dynamic dispatch is genuinely needed — it has runtime cost.
+- Keep protocol requirements minimal. Clients should not be forced to implement methods they don't need.
+
+### Error handling
+
+- Use `throws` for recoverable errors. Use typed throws (`throws(MyError)`) in Swift 6 when the error domain is closed.
+- Define specific error enums per module. Include context (e.g., the ID that wasn't found).
+- Use `Result` when errors must be stored or passed as values.
+- Use `do`/`catch` at the boundary layer (view model, controller). Don't catch errors deep in business logic unless recovery is possible.
+
+### Testing
+
+- Use Swift Testing framework (`@Test`, `#expect`) for new test targets. XCTest for existing targets.
+- Use protocol-based dependency injection for testable architecture. Avoid singletons.
+- Test async code with `await` — Swift Testing supports async test functions natively.
+- Use `confirmation()` for testing actor-isolated behavior.
+- Keep tests fast: mock network and persistence. No real I/O in unit tests.
+
+### Package structure
+
+- Organize code into focused packages/modules with clear public APIs.
+- Use `Package.swift` targets to enforce module boundaries. Keep target dependency graphs acyclic.
+- Export only the public API. Use `internal` for implementation details.
+- Use `@testable import` only in test targets — never in production code.
+
+### Constraints
+
+- Avoid force unwrapping (`!`) without a preceding guard or nil check.
+- Avoid massive view controllers or view models — split into focused components.
+- Avoid `class` when `struct` would suffice — value types are cheaper, safer, and `Sendable` by default.
+- Avoid `DispatchQueue` for new concurrent code — use Swift concurrency instead.
+- Avoid retain cycles from strong `self` captures in closures — use `[weak self]` or `[unowned self]` appropriately.
+- Avoid global mutable state (`static var`) — use actor isolation or dependency injection.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                            | Load when                                                                                                                                 |
+| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `references/swift-concurrency-and-protocols.md` | Swift concurrency migration, Sendable audit, actor design, protocol-oriented architecture, or structured concurrency patterns are needed. |
+| `references/concurrency-patterns.md`            | You need actor design, TaskGroup usage, AsyncSequence/AsyncStream, or MainActor annotation strategies.                                    |
+| `references/sendable-and-isolation.md`          | You need Sendable conformance patterns, isolation boundary crossing, or @unchecked Sendable audit guidance.                               |
+| `references/protocol-and-generics.md`           | You need protocol-oriented design, opaque types, existentials, associated types, or generic constraint patterns.                          |
+| `references/testing-and-packages.md`            | You need Swift Testing framework patterns, dependency injection for tests, or Package.swift module organization.                          |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with swift pro best practices in this project"
+- "Review my swift pro implementation for issues"

package/workflows/powers/swift-pro/references/concurrency-patterns.md

@@ -0,0 +1,165 @@
+# Concurrency Patterns
+
+## Actor design
+
+### Choosing between actor types
+
+| Pattern               | Use when                                                               |
+| --------------------- | ---------------------------------------------------------------------- |
+| `actor`               | Mutable state needs thread-safe access from multiple callers.          |
+| `@MainActor`          | State or methods are bound to the UI thread.                           |
+| Custom `@globalActor` | A subsystem needs serial execution (database, file I/O).               |
+| No actor              | The type is immutable or only accessed from a single isolation domain. |
+
+### Actor reentrancy
+
+```swift
+actor ImageCache {
+    private var cache: [URL: Image] = [:]
+    private var inFlight: [URL: Task<Image, Error>] = [:]
+
+    func image(for url: URL) async throws -> Image {
+        if let cached = cache[url] { return cached }
+
+        // Coalesce concurrent requests for the same URL
+        if let existing = inFlight[url] {
+            return try await existing.value
+        }
+
+        let task = Task {
+            try await downloadImage(url)
+        }
+        inFlight[url] = task
+
+        let image = try await task.value  // suspension point — state may change
+        cache[url] = image
+        inFlight[url] = nil
+        return image
+    }
+}
+```
+
+- Actor methods can suspend and resume. State may change between suspension points.
+- Guard against reentrancy by checking state again after `await` calls.
+- Use `inFlight` dictionaries to coalesce duplicate concurrent requests.
+
+## TaskGroup patterns
+
+### Bounded concurrency with TaskGroup
+
+```swift
+func processAll(_ items: [Item], concurrency: Int = 10) async throws {
+    try await withThrowingTaskGroup(of: Void.self) { group in
+        var iterator = items.makeIterator()
+
+        // Seed the group with initial concurrent tasks
+        for _ in 0..<min(concurrency, items.count) {
+            if let item = iterator.next() {
+                group.addTask { try await process(item) }
+            }
+        }
+
+        // As each task completes, add the next one
+        for try await _ in group {
+            if let item = iterator.next() {
+                group.addTask { try await process(item) }
+            }
+        }
+    }
+}
+```
+
+### Collecting ordered results
+
+```swift
+func fetchAll(ids: [Int]) async throws -> [User] {
+    try await withThrowingTaskGroup(of: (Int, User).self) { group in
+        for (index, id) in ids.enumerated() {
+            group.addTask { (index, try await fetchUser(id)) }
+        }
+
+        var results = Array<User?>(repeating: nil, count: ids.count)
+        for try await (index, user) in group {
+            results[index] = user
+        }
+        return results.compactMap { $0 }
+    }
+}
+```
+
+- TaskGroup results arrive in completion order, not submission order.
+- Use index-based collection when order matters.
+
+## AsyncSequence and AsyncStream
+
+### Building custom AsyncSequence
+
+```swift
+struct TickSequence: AsyncSequence {
+    typealias Element = Date
+    let interval: TimeInterval
+
+    struct AsyncIterator: AsyncIteratorProtocol {
+        let interval: TimeInterval
+        mutating func next() async -> Date? {
+            try? await Task.sleep(for: .seconds(interval))
+            return Task.isCancelled ? nil : Date()
+        }
+    }
+
+    func makeAsyncIterator() -> AsyncIterator {
+        AsyncIterator(interval: interval)
+    }
+}
+
+for await tick in TickSequence(interval: 1.0) {
+    print("Tick: \(tick)")
+}
+```
+
+### AsyncStream with backpressure
+
+```swift
+let (stream, continuation) = AsyncStream.makeStream(of: Event.self, bufferingPolicy: .bufferingNewest(10))
+
+// Producer
+continuation.yield(.userAction("tap"))
+continuation.finish()
+
+// Consumer
+for await event in stream {
+    await handle(event)
+}
+```
+
+- Use `.bufferingNewest(n)` to drop old events under backpressure.
+- Use `.bufferingOldest(n)` to drop new events (queue semantics).
+- Always call `continuation.finish()` when the source completes.
+- Set `continuation.onTermination` to clean up resources when the consumer stops.
+
+## MainActor patterns
+
+### Annotation strategies
+
+```swift
+// Annotate the entire class for UI-bound types
+@MainActor
+class ViewModel: ObservableObject {
+    @Published var items: [Item] = []
+
+    func load() async {
+        let data = await fetchFromNetwork()  // suspends, runs off-main
+        items = data  // back on MainActor
+    }
+
+    // Opt out for non-UI work
+    nonisolated func computeHash() -> String {
+        // runs on caller's isolation domain
+    }
+}
+```
+
+- Prefer class-level `@MainActor` for view models and UI controllers.
+- Use method-level `@MainActor` for specific entry points in otherwise non-UI types.
+- Use `nonisolated` to opt specific methods out of the class-level annotation.
+- Never use `DispatchQueue.main.async` in new code — use `@MainActor` instead.