diff --git a/plugins/agent-portability-skills/.codex-plugin/plugin.json b/plugins/agent-portability-skills/.codex-plugin/plugin.json index 09bb9ce6..0d85ba49 100644 --- a/plugins/agent-portability-skills/.codex-plugin/plugin.json +++ b/plugins/agent-portability-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "agent-portability-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Maintainer skills for Socket-owned agent skill portability, Codex plugin surfaces, and host adapter guidance.", "author": { "name": "Gale", diff --git a/plugins/agent-portability-skills/pyproject.toml b/plugins/agent-portability-skills/pyproject.toml index 1d9f66a3..31273df0 100644 --- a/plugins/agent-portability-skills/pyproject.toml +++ b/plugins/agent-portability-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "agent-portability-skills-maintenance" -version = "8.5.4" +version = "8.5.5" description = "Maintainer-only Python tooling baseline for Agent Portability Skills." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/agent-portability-skills/uv.lock b/plugins/agent-portability-skills/uv.lock index 79b97159..ee566a70 100644 --- a/plugins/agent-portability-skills/uv.lock +++ b/plugins/agent-portability-skills/uv.lock @@ -8,7 +8,7 @@ resolution-markers = [ [[package]] name = "agent-portability-skills-maintenance" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/agentdeck/.codex-plugin/plugin.json b/plugins/agentdeck/.codex-plugin/plugin.json index 30e6f1e7..e76cc7ee 100644 --- a/plugins/agentdeck/.codex-plugin/plugin.json +++ b/plugins/agentdeck/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "agentdeck", - "version": "8.5.4", + "version": "8.5.5", "description": "Local Codex runtime utilities for thread, hook, and app-server workflows.", "author": { "name": "Gale", diff --git a/plugins/android-dev-skills/.codex-plugin/plugin.json b/plugins/android-dev-skills/.codex-plugin/plugin.json index d6ade2b6..aa90f8a3 100644 --- a/plugins/android-dev-skills/.codex-plugin/plugin.json +++ b/plugins/android-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "android-dev-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Android, Kotlin, Java, Gradle, Android Gradle Plugin, testing, lint, UI implementation, and release-readiness workflow skills.", "author": { "name": "Gale", diff --git a/plugins/apple-dev-skills/.codex-plugin/plugin.json b/plugins/apple-dev-skills/.codex-plugin/plugin.json index 2a0b40cc..0dda8f6a 100644 --- a/plugins/apple-dev-skills/.codex-plugin/plugin.json +++ b/plugins/apple-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "apple-dev-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Apple development workflows for Codex, including media and audio repair, XcodeGen migration, Xcode coding intelligence, SwiftUI animation and architecture, Core Animation, Apple typography, SF Symbols, AppKit architecture, Icon Composer app icons, Safari extensions, DeviceCheck/App Attest, Swift OpenAPI clients, and DocC authoring guidance.", "author": { "name": "Gale", diff --git a/plugins/apple-dev-skills/pyproject.toml b/plugins/apple-dev-skills/pyproject.toml index afe84a7c..e40047f5 100644 --- a/plugins/apple-dev-skills/pyproject.toml +++ b/plugins/apple-dev-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "apple-dev-skills-maintainer" -version = "8.5.4" +version = "8.5.5" description = "Maintainer tooling for the apple-dev-skills repository" requires-python = ">=3.10" dependencies = [] diff --git a/plugins/apple-dev-skills/shared/agents-snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/shared/agents-snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/shared/agents-snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/shared/agents-snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/apple-typography-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/apple-typography-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/apple-typography-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/apple-typography-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/apple-ui-accessibility-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/apple-ui-accessibility-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/apple-ui-accessibility-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/apple-ui-accessibility-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/avaudio-engine-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/avaudio-engine-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/avaudio-engine-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/avaudio-engine-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/avfoundation-media-pipeline-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/avfoundation-media-pipeline-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/avfoundation-media-pipeline-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/avfoundation-media-pipeline-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/bootstrap-swift-package/assets/AGENTS.md b/plugins/apple-dev-skills/skills/bootstrap-swift-package/assets/AGENTS.md index 9c1a570b..7d8e85d7 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-swift-package/assets/AGENTS.md +++ b/plugins/apple-dev-skills/skills/bootstrap-swift-package/assets/AGENTS.md @@ -100,7 +100,9 @@ - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/bootstrap-swift-package/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/bootstrap-swift-package/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-swift-package/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/bootstrap-swift-package/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/assets/AGENTS.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/assets/AGENTS.md index f0b4964a..1b1d070b 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/assets/AGENTS.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/assets/AGENTS.md @@ -21,6 +21,8 @@ - Prefer Xcode-aware tooling or `xcodebuild` over ad hoc filesystem assumptions when project structure or target membership is involved. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. - Use the standard top-level Xcode app repository layout: `Sources/`, `Tests/`, `Shared/`, `Extensions/`, `Configurations/`, `Scripts/`, and `Packages/`. - `Sources/` owns the main app target implementation and app-owned resources/support files. `Tests/` owns all test targets. `Shared/` owns reusable source intended to be compiled into the app and extension targets. `Extensions/` owns extension target roots, one folder per extension. `Configurations/` owns `.xcconfig` layers. `Scripts/` owns project-local automation and build helper scripts. `Packages/` owns local Swift packages only when a real package boundary is justified. - Keep those top-level roots stable; do not invent parallel names such as `AppSources`, `TestSources`, `Config`, `BuildScripts`, or `LocalPackages` for ordinary Xcode app repos. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/core-animation-layer-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/core-animation-layer-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/core-animation-layer-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/core-animation-layer-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/coreaudio-modernization-repair-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/coreaudio-modernization-repair-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/coreaudio-modernization-repair-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/coreaudio-modernization-repair-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/coremedia-timing-samplebuffer-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/coremedia-timing-samplebuffer-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/coremedia-timing-samplebuffer-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/coremedia-timing-samplebuffer-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/devicecheck-app-attest-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/devicecheck-app-attest-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/devicecheck-app-attest-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/devicecheck-app-attest-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/explore-apple-swift-docs/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/format-swift-sources/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/format-swift-sources/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/format-swift-sources/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/format-swift-sources/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/safari-extension-control-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/safari-extension-control-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/safari-extension-control-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/safari-extension-control-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/sf-symbols-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/sf-symbols-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/sf-symbols-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/sf-symbols-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/structure-swift-sources/SKILL.md b/plugins/apple-dev-skills/skills/structure-swift-sources/SKILL.md index fac43885..15e9328e 100644 --- a/plugins/apple-dev-skills/skills/structure-swift-sources/SKILL.md +++ b/plugins/apple-dev-skills/skills/structure-swift-sources/SKILL.md @@ -71,7 +71,7 @@ Use this skill as the top-level workflow for structural cleanup inside existing - for Swift packages, prefer directories grouped by layer and feature, such as `API//.swift` and `Features//.swift` - for Xcode app projects, ensure important app-facing source directories such as `Views/`, `Controllers/`, and `Models/` - for SwiftUI views, keep view files in `Views/`, require exactly one SwiftUI `View` component per file, and keep that component's Xcode SwiftUI preview in the same file - - when splitting grouped SwiftUI views, create one `.swift` file per view component and pair it with `+Model.swift` and `+Modifier.swift` files when those concerns exist + - when splitting grouped SwiftUI views, create one `.swift` file per view component, require any SwiftUI view model for that component to live in `+Model.swift`, and place view-specific modifiers in `+Modifier.swift` 7. Finish with `format-swift-sources` again so the moved or split files end in a normalized state. ## Inputs diff --git a/plugins/apple-dev-skills/skills/structure-swift-sources/references/layout-rules.md b/plugins/apple-dev-skills/skills/structure-swift-sources/references/layout-rules.md index 99e0425c..aed1b58b 100644 --- a/plugins/apple-dev-skills/skills/structure-swift-sources/references/layout-rules.md +++ b/plugins/apple-dev-skills/skills/structure-swift-sources/references/layout-rules.md @@ -15,7 +15,8 @@ - Keep SwiftUI views in `Views/`. - Require one SwiftUI `View` component per file, named `.swift`, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one file; split related child views into their own files instead. -- When a view has a paired model type, use `+Model.swift`. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not use grouped model files, shared view-model files, or view-cluster models for SwiftUI views. - When a view needs extracted modifiers, use `+Modifier.swift`. - Move files into their proper layer directory rather than leaving them flat at the project root. diff --git a/plugins/apple-dev-skills/skills/structure-swift-sources/references/source-organization-rules.md b/plugins/apple-dev-skills/skills/structure-swift-sources/references/source-organization-rules.md index ac6c9d62..f9135382 100644 --- a/plugins/apple-dev-skills/skills/structure-swift-sources/references/source-organization-rules.md +++ b/plugins/apple-dev-skills/skills/structure-swift-sources/references/source-organization-rules.md @@ -14,6 +14,7 @@ - `+Persistence.swift` - `+Validation.swift` - `+Modifier.swift` +- Do not use `+Models.swift` for SwiftUI view models. SwiftUI view models use the per-view `+Model.swift` rule instead. - Treat Swift access control as part of the design; confirm the extracted file shape still supports the intended visibility. ## MARK Rules @@ -36,6 +37,8 @@ - Require exactly one SwiftUI `View` component per file. Do not group multiple `View` component types in one Swift file, even when the views are small, private, nested, or part of the same feature. - Name each view file after its component, such as `.swift`, and keep that component's Xcode SwiftUI preview in the same file. +- SwiftUI view models are always per-view, with no exceptions: if `.swift` has a view model, it must live in `+Model.swift` and belong only to that one `View` component. +- Do not share one SwiftUI view model across multiple views, view families, screens, flows, or view clusters, and do not collect multiple SwiftUI view models in one shared model file. - When an existing file contains multiple SwiftUI view components, split it into one file per view before adding more behavior. - Once any one view has more than `3` chained modifiers, strongly consider extracting a custom `ViewModifier`. - Place that modifier in `+Modifier.swift` when the modifier belongs to one view family. diff --git a/plugins/apple-dev-skills/skills/swiftui-animation-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/swiftui-animation-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/swiftui-animation-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/swiftui-animation-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/SKILL.md b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/SKILL.md index ef5a2655..b9120c31 100644 --- a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/SKILL.md +++ b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/SKILL.md @@ -19,7 +19,9 @@ It is not the Apple-docs router, not the accessibility workflow, and not the Xco Each SwiftUI `View` component must live in its own Swift file named for that view, and that file must carry the view's own Xcode SwiftUI preview. Do not group multiple `View` component types in one file, even when the views are small, related, nested, or currently used only by one parent. Split them into separate files so Xcode previews remain discoverable, isolated, and reliable. -Keep supporting code in explicit paired files instead of bundling extra view types together: use `+Model.swift` for view-local models, `+Modifier.swift` for view-specific modifiers, and other narrowly named support files when needed. A file may contain private helper values or small non-`View` helpers for that one component, but it must not contain another SwiftUI `View` component. +SwiftUI view models are always per-view, with no exceptions. If a SwiftUI view has a view model, that model belongs to exactly that `View` component and must live in the matching `+Model.swift` file. Do not share a SwiftUI view model across multiple views, view families, screens, flows, or view clusters, and do not place multiple SwiftUI view models in one shared model file. + +Keep supporting code in explicit paired files instead of bundling extra view types together: use `+Model.swift` for that view's model, `+Modifier.swift` for view-specific modifiers, and other narrowly named support files when needed. A file may contain private helper values or small non-`View` helpers for that one component, but it must not contain another SwiftUI `View` component. ## When To Use @@ -85,6 +87,7 @@ Keep supporting code in explicit paired files instead of bundling extra view typ - wrapper-heavy layers added only to look architectural - control flow hidden in modifiers that obscure who owns the action - multiple SwiftUI `View` component types grouped into one file, especially when that prevents one file-local Xcode preview per component + - one SwiftUI view model shared across a view cluster or stored outside the matching `+Model.swift` file 6. Return one recommendation path with: - the ownership boundary - the chosen transport diff --git a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/anti-patterns-and-corrections.md b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/anti-patterns-and-corrections.md index 31924631..3d2705df 100644 --- a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/anti-patterns-and-corrections.md +++ b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/anti-patterns-and-corrections.md @@ -35,6 +35,19 @@ Correction: - keep that component's Xcode SwiftUI preview in the same file as the component - move view-local models, modifiers, and support code into explicit paired files such as `+Model.swift` and `+Modifier.swift` +## Shared SwiftUI View Models + +Bad shape: + +- one SwiftUI view model owns state for multiple views, a view family, a screen flow, or a small view cluster +- multiple SwiftUI view models are collected in a shared model file instead of living beside their matching view files + +Correction: + +- make SwiftUI view models per-view only +- put the model for `.swift` in `+Model.swift` +- split shared view-model state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer + ## Wrapper-Heavy Architecture Bad shape: diff --git a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/swiftui-app-architecture-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/AGENTS.md b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/AGENTS.md index a16e27c2..72f3b598 100644 --- a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/AGENTS.md +++ b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/AGENTS.md @@ -23,6 +23,8 @@ - Prefer Xcode-aware tooling or `xcodebuild` over ad hoc filesystem assumptions when project structure or target membership is involved. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. - Use the standard top-level Xcode app repository layout: `Sources/`, `Tests/`, `Shared/`, `Extensions/`, `Configurations/`, `Scripts/`, and `Packages/`. - `Sources/` owns the main app target implementation and app-owned resources/support files. `Tests/` owns all test targets. `Shared/` owns reusable source intended to be compiled into the app and extension targets. `Extensions/` owns extension target roots, one folder per extension. `Configurations/` owns `.xcconfig` layers. `Scripts/` owns project-local automation and build helper scripts. `Packages/` owns local Swift packages only when a real package boundary is justified. - Keep those top-level roots stable; do not invent parallel names such as `AppSources`, `TestSources`, `Config`, `BuildScripts`, or `LocalPackages` for ordinary Xcode app repos. diff --git a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/append-section.md b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/append-section.md index 31b5bd7b..cf9e721f 100644 --- a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/append-section.md +++ b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/assets/append-section.md @@ -21,6 +21,8 @@ - Prefer Xcode-aware tooling or `xcodebuild` over ad hoc filesystem assumptions when project structure or target membership is involved. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. - Use the standard top-level Xcode app repository layout: `Sources/`, `Tests/`, `Shared/`, `Extensions/`, `Configurations/`, `Scripts/`, and `Packages/`. - `Sources/` owns the main app target implementation and app-owned resources/support files. `Tests/` owns all test targets. `Shared/` owns reusable source intended to be compiled into the app and extension targets. `Extensions/` owns extension target roots, one folder per extension. `Configurations/` owns `.xcconfig` layers. `Scripts/` owns project-local automation and build helper scripts. `Packages/` owns local Swift packages only when a real package boundary is justified. - Keep those top-level roots stable; do not invent parallel names such as `AppSources`, `TestSources`, `Config`, `BuildScripts`, or `LocalPackages` for ordinary Xcode app repos. diff --git a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/sync-xcode-project-guidance/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-coding-intelligence-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/xcode-coding-intelligence-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/xcode-coding-intelligence-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/xcode-coding-intelligence-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-swift-core.md b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-swift-core.md index d2f89658..d7e27209 100644 --- a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-swift-core.md +++ b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-swift-core.md @@ -52,7 +52,9 @@ Use this snippet in repository `AGENTS.md` files when you want cross-project Swi ## SwiftUI and State Architecture - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-xcode-project-core.md b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-xcode-project-core.md index 0a18bc34..9e821519 100644 --- a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-xcode-project-core.md +++ b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/snippets/apple-xcode-project-core.md @@ -61,7 +61,9 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom. - Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file. - Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent. -- Prefer straight, top-down data flow with small focused controller classes that own matching state for a view or small view cluster. +- SwiftUI view models are always per-view, with no exceptions: the model for `.swift` must live in `+Model.swift` and must not be shared with any other SwiftUI view. +- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, or view-cluster models. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer. +- Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior. - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer. - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. diff --git a/plugins/apple-dev-skills/tests/test_structure_swift_sources_workflow.py b/plugins/apple-dev-skills/tests/test_structure_swift_sources_workflow.py index 58044ebb..017b2e5d 100644 --- a/plugins/apple-dev-skills/tests/test_structure_swift_sources_workflow.py +++ b/plugins/apple-dev-skills/tests/test_structure_swift_sources_workflow.py @@ -123,6 +123,21 @@ def test_swiftui_structure_requires_one_view_and_preview_per_file(self) -> None: self.assertIn("Do not group multiple `View` component types in one Swift file", source_rules_text) self.assertIn("Require one SwiftUI `View` component per file", layout_rules_text) + def test_swiftui_view_model_structure_is_per_view_only(self) -> None: + skill_text = (ROOT / "skills/structure-swift-sources/SKILL.md").read_text(encoding="utf-8") + source_rules_text = (ROOT / "skills/structure-swift-sources/references/source-organization-rules.md").read_text( + encoding="utf-8" + ) + layout_rules_text = (ROOT / "skills/structure-swift-sources/references/layout-rules.md").read_text( + encoding="utf-8" + ) + + self.assertIn("require any SwiftUI view model for that component to live in `+Model.swift`", skill_text) + self.assertIn("SwiftUI view models are always per-view", source_rules_text) + self.assertIn("Do not share one SwiftUI view model", source_rules_text) + self.assertIn("must live in `+Model.swift`", layout_rules_text) + self.assertNotIn("When a view has a paired model type", layout_rules_text) + if __name__ == "__main__": unittest.main() diff --git a/plugins/apple-dev-skills/tests/test_swiftui_app_architecture_workflow.py b/plugins/apple-dev-skills/tests/test_swiftui_app_architecture_workflow.py index f70f6b29..55a7d4cd 100644 --- a/plugins/apple-dev-skills/tests/test_swiftui_app_architecture_workflow.py +++ b/plugins/apple-dev-skills/tests/test_swiftui_app_architecture_workflow.py @@ -63,6 +63,20 @@ def test_view_components_require_file_local_previews(self) -> None: self.assertIn("Grouped SwiftUI View Files", anti_patterns_text) self.assertIn("keep that component's Xcode SwiftUI preview in the same file", anti_patterns_text) + def test_swiftui_view_models_are_per_view_only(self) -> None: + skill_text = self.read("skills/swiftui-app-architecture-workflow/SKILL.md") + anti_patterns_text = self.read( + "skills/swiftui-app-architecture-workflow/references/anti-patterns-and-corrections.md" + ) + shared_snippet_text = self.read("shared/agents-snippets/apple-xcode-project-core.md") + + self.assertIn("SwiftUI view models are always per-view, with no exceptions", skill_text) + self.assertIn("matching `+Model.swift` file", skill_text) + self.assertIn("Shared SwiftUI View Models", anti_patterns_text) + self.assertIn("put the model for `.swift` in `+Model.swift`", anti_patterns_text) + self.assertIn("SwiftUI view models are always per-view, with no exceptions", shared_snippet_text) + self.assertNotIn("own matching state for a view or small view cluster", shared_snippet_text) + if __name__ == "__main__": unittest.main() diff --git a/plugins/apple-dev-skills/tests/test_xcode_guidance_sync_workflow.py b/plugins/apple-dev-skills/tests/test_xcode_guidance_sync_workflow.py index c990e428..b18322b4 100644 --- a/plugins/apple-dev-skills/tests/test_xcode_guidance_sync_workflow.py +++ b/plugins/apple-dev-skills/tests/test_xcode_guidance_sync_workflow.py @@ -86,6 +86,8 @@ def test_sync_creates_agents_template(self) -> None: self.assertIn("Prefer enums, enum cases with associated values", agents_text) self.assertIn("Require one SwiftUI `View` component per file", agents_text) self.assertIn("Xcode SwiftUI preview in the same file", agents_text) + self.assertIn("SwiftUI view models are always per-view, with no exceptions", agents_text) + self.assertIn("+Model.swift", agents_text) self.assertTrue(Path(tmpdir, ".swiftformat").is_file()) self.assertTrue(Path(tmpdir, "Scripts/repo-maintenance/hooks/pre-commit.sample").is_file()) self.assertTrue(Path(tmpdir, "Scripts/repo-maintenance/validate-all.sh").is_file()) @@ -132,6 +134,8 @@ def test_sync_appends_section_to_existing_agents(self) -> None: self.assertIn("Prefer enums, enum cases with associated values", agents_text) self.assertIn("Require one SwiftUI `View` component per file", agents_text) self.assertIn("Xcode SwiftUI preview in the same file", agents_text) + self.assertIn("SwiftUI view models are always per-view, with no exceptions", agents_text) + self.assertIn("+Model.swift", agents_text) self.assertTrue(Path(tmpdir, ".swiftformat").is_file()) self.assertTrue(Path(tmpdir, "Scripts/repo-maintenance/hooks/pre-commit.sample").is_file()) self.assertTrue(Path(tmpdir, "Scripts/repo-maintenance/release.sh").is_file()) diff --git a/plugins/apple-dev-skills/uv.lock b/plugins/apple-dev-skills/uv.lock index dcffec98..e269007b 100644 --- a/plugins/apple-dev-skills/uv.lock +++ b/plugins/apple-dev-skills/uv.lock @@ -4,7 +4,7 @@ requires-python = ">=3.10" [[package]] name = "apple-dev-skills-maintainer" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/cardhop-app/.codex-plugin/plugin.json b/plugins/cardhop-app/.codex-plugin/plugin.json index 7b7493a8..fc9674ef 100644 --- a/plugins/cardhop-app/.codex-plugin/plugin.json +++ b/plugins/cardhop-app/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cardhop-app", - "version": "8.5.4", + "version": "8.5.5", "description": "Cardhop.app workflow guidance plus a bundled local MCP server for contact capture and updates on macOS.", "author": { "name": "Gale", diff --git a/plugins/cardhop-app/mcp/pyproject.toml b/plugins/cardhop-app/mcp/pyproject.toml index 4a753313..10e52f37 100644 --- a/plugins/cardhop-app/mcp/pyproject.toml +++ b/plugins/cardhop-app/mcp/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "cardhop-app-mcp" -version = "8.5.4" +version = "8.5.5" requires-python = ">=3.13" dependencies = [ "fastmcp>=3.0.2", diff --git a/plugins/cardhop-app/mcp/uv.lock b/plugins/cardhop-app/mcp/uv.lock index 6b5f762e..1fa9940c 100644 --- a/plugins/cardhop-app/mcp/uv.lock +++ b/plugins/cardhop-app/mcp/uv.lock @@ -138,7 +138,7 @@ wheels = [ [[package]] name = "cardhop-app-mcp" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } dependencies = [ { name = "fastmcp" }, diff --git a/plugins/cloud-deployment-skills/.codex-plugin/plugin.json b/plugins/cloud-deployment-skills/.codex-plugin/plugin.json index ae0b8cc1..6cc7814e 100644 --- a/plugins/cloud-deployment-skills/.codex-plugin/plugin.json +++ b/plugins/cloud-deployment-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cloud-deployment-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for routing cloud deployment work through official provider plugins, MCP servers, CLIs, and Socket-owned deployment guidance.", "author": { "name": "Gale", diff --git a/plugins/cloud-inference-skills/.codex-plugin/plugin.json b/plugins/cloud-inference-skills/.codex-plugin/plugin.json index 3c9b0deb..7d6c4096 100644 --- a/plugins/cloud-inference-skills/.codex-plugin/plugin.json +++ b/plugins/cloud-inference-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cloud-inference-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Cloud AI inference workflow skills for routing model serving, training, conversion, and GPU infrastructure work across Runpod, Hugging Face, AWS, Vast.ai, CoreWeave, and similar providers.", "author": { "name": "Gale", diff --git a/plugins/dotnet-skills/.codex-plugin/plugin.json b/plugins/dotnet-skills/.codex-plugin/plugin.json index 09ad31bd..1a9c47c7 100644 --- a/plugins/dotnet-skills/.codex-plugin/plugin.json +++ b/plugins/dotnet-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "dotnet-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for choosing, bootstrapping, building, testing, packaging, diagnosing, and maintaining .NET projects with F# and C# as equal first-party languages.", "author": { "name": "Gale", diff --git a/plugins/game-dev-skills/.codex-plugin/plugin.json b/plugins/game-dev-skills/.codex-plugin/plugin.json index 87f927ef..4a24a19d 100644 --- a/plugins/game-dev-skills/.codex-plugin/plugin.json +++ b/plugins/game-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "game-dev-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Apple platform game development workflow skills for SpriteKit, SceneKit, GameplayKit, controller input, haptics, profiling, and game-stack routing.", "author": { "name": "Gale", diff --git a/plugins/network-protocol-skills/.codex-plugin/plugin.json b/plugins/network-protocol-skills/.codex-plugin/plugin.json index f1969587..e83598e6 100644 --- a/plugins/network-protocol-skills/.codex-plugin/plugin.json +++ b/plugins/network-protocol-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "network-protocol-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for choosing, planning, implementing, and diagnosing modern application transports and real-time networking protocols, including QUIC, HTTP/3, WebRTC, Media over QUIC, WebTransport-adjacent handoffs, protocol maturity checks, and stack-specific implementation routing.", "author": { "name": "Gale", diff --git a/plugins/productivity-skills/.codex-plugin/plugin.json b/plugins/productivity-skills/.codex-plugin/plugin.json index 86ea6fd3..1ea1057b 100644 --- a/plugins/productivity-skills/.codex-plugin/plugin.json +++ b/plugins/productivity-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "productivity-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Broadly useful productivity workflows for Codex.", "author": { "name": "Gale", diff --git a/plugins/productivity-skills/pyproject.toml b/plugins/productivity-skills/pyproject.toml index e24d4b32..bf5dc822 100644 --- a/plugins/productivity-skills/pyproject.toml +++ b/plugins/productivity-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "productivity-skills-maintenance" -version = "8.5.4" +version = "8.5.5" description = "Maintainer-only Python tooling baseline for productivity-skills." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/productivity-skills/uv.lock b/plugins/productivity-skills/uv.lock index 0a14c41d..47679410 100644 --- a/plugins/productivity-skills/uv.lock +++ b/plugins/productivity-skills/uv.lock @@ -228,7 +228,7 @@ wheels = [ [[package]] name = "productivity-skills-maintenance" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/python-skills/.codex-plugin/plugin.json b/plugins/python-skills/.codex-plugin/plugin.json index f0eaaed0..bc5bb638 100644 --- a/plugins/python-skills/.codex-plugin/plugin.json +++ b/plugins/python-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "python-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Bundled Python-focused Codex skills for uv bootstrapping, project implementation, diagnostics, packaging, tooling, CI, upgrades, FastAPI, FastMCP, and pytest workflows.", "author": { "name": "Gale", diff --git a/plugins/python-skills/pyproject.toml b/plugins/python-skills/pyproject.toml index ed9a71c4..a1e12fbd 100644 --- a/plugins/python-skills/pyproject.toml +++ b/plugins/python-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "python-skills-maintainer" -version = "8.5.4" +version = "8.5.5" description = "Maintainer tooling for the python-skills repository" requires-python = ">=3.11" dependencies = [] diff --git a/plugins/python-skills/uv.lock b/plugins/python-skills/uv.lock index 38caf80e..4b564153 100644 --- a/plugins/python-skills/uv.lock +++ b/plugins/python-skills/uv.lock @@ -251,7 +251,7 @@ wheels = [ [[package]] name = "python-skills-maintainer" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/reverse-engineering-skills/.codex-plugin/plugin.json b/plugins/reverse-engineering-skills/.codex-plugin/plugin.json index d13413bb..59cb3f88 100644 --- a/plugins/reverse-engineering-skills/.codex-plugin/plugin.json +++ b/plugins/reverse-engineering-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "reverse-engineering-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Workflow skills for reverse engineering, decompilation, disassembly, symbol, and artifact-analysis tasks.", "skills": "./skills/", "author": { diff --git a/plugins/rust-skills/.codex-plugin/plugin.json b/plugins/rust-skills/.codex-plugin/plugin.json index a288c4b1..01fd428e 100644 --- a/plugins/rust-skills/.codex-plugin/plugin.json +++ b/plugins/rust-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "rust-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Rust, Cargo, rustup, crate, workspace, CLI, library, package, CI, testing, linting, and formatting workflow skills.", "skills": "./skills/", "author": { diff --git a/plugins/server-side-jvm/.codex-plugin/plugin.json b/plugins/server-side-jvm/.codex-plugin/plugin.json index d3e6403f..dc507b3a 100644 --- a/plugins/server-side-jvm/.codex-plugin/plugin.json +++ b/plugins/server-side-jvm/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "server-side-jvm", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for choosing, building, testing, and maintaining server-side JVM backend projects with Java and Scala as equal first-party languages and future Clojure support planned.", "author": { "name": "Gale", diff --git a/plugins/server-side-swift/.codex-plugin/plugin.json b/plugins/server-side-swift/.codex-plugin/plugin.json index 29a6fbb4..abc2efc4 100644 --- a/plugins/server-side-swift/.codex-plugin/plugin.json +++ b/plugins/server-side-swift/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "server-side-swift", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for bootstrapping, syncing, building, running, containerizing, deploying, and maintaining server-side Swift services, including Vapor, Hummingbird, hb, persistence, Swift OpenAPI, RPC-fit decisions, SwiftNIO, observability, auth, app sync, Docker, Apple Containerization, Fly.io, and SwiftPM-first workflows.", "author": { "name": "Gale", diff --git a/plugins/spotify/.codex-plugin/plugin.json b/plugins/spotify/.codex-plugin/plugin.json index 36c2db25..8fa36530 100644 --- a/plugins/spotify/.codex-plugin/plugin.json +++ b/plugins/spotify/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "spotify", - "version": "8.5.4", + "version": "8.5.5", "description": "Placeholder plugin repository for future Spotify-focused Codex workflows.", "author": { "name": "Gale", diff --git a/plugins/swift-lang/.codex-plugin/plugin.json b/plugins/swift-lang/.codex-plugin/plugin.json index 06714f69..ea288d4d 100644 --- a/plugins/swift-lang/.codex-plugin/plugin.json +++ b/plugins/swift-lang/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "swift-lang", - "version": "8.5.4", + "version": "8.5.5", "description": "Shared Swift language skills for API style, error handling, functional pipelines, formatting, source organization, and modernization cleanup.", "skills": "./skills/", "author": { diff --git a/plugins/swiftasb-skills/.codex-plugin/plugin.json b/plugins/swiftasb-skills/.codex-plugin/plugin.json index fa562b5d..ab1f9dd2 100644 --- a/plugins/swiftasb-skills/.codex-plugin/plugin.json +++ b/plugins/swiftasb-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "swiftasb-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for explaining SwiftASB and building SwiftUI, AppKit, and Swift package integrations on top of it.", "author": { "name": "Gale", diff --git a/plugins/things-app/.codex-plugin/plugin.json b/plugins/things-app/.codex-plugin/plugin.json index 93146494..832eb4ba 100644 --- a/plugins/things-app/.codex-plugin/plugin.json +++ b/plugins/things-app/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "things-app", - "version": "8.5.4", + "version": "8.5.5", "description": "Things.app skills and a bundled local MCP server for reminders, planning digests, and structured task workflows.", "author": { "name": "Gale", diff --git a/plugins/things-app/mcp/pyproject.toml b/plugins/things-app/mcp/pyproject.toml index 2a70b746..f06f29d4 100644 --- a/plugins/things-app/mcp/pyproject.toml +++ b/plugins/things-app/mcp/pyproject.toml @@ -7,7 +7,7 @@ packages = ["app"] [project] name = "things-mcp" -version = "8.5.4" +version = "8.5.5" requires-python = ">=3.13" dependencies = [ "fastmcp>=3.0.2", diff --git a/plugins/things-app/mcp/uv.lock b/plugins/things-app/mcp/uv.lock index 26663d78..cff60d0a 100644 --- a/plugins/things-app/mcp/uv.lock +++ b/plugins/things-app/mcp/uv.lock @@ -1241,7 +1241,7 @@ wheels = [ [[package]] name = "things-mcp" -version = "8.5.4" +version = "8.5.5" source = { editable = "." } dependencies = [ { name = "fastmcp" }, diff --git a/plugins/things-app/pyproject.toml b/plugins/things-app/pyproject.toml index 990731a5..40797e73 100644 --- a/plugins/things-app/pyproject.toml +++ b/plugins/things-app/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "things-app-maintenance" -version = "8.5.4" +version = "8.5.5" description = "Maintainer-only Python tooling baseline for things-app skills and plugin packaging." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/things-app/uv.lock b/plugins/things-app/uv.lock index 3d0589d0..9ed6a756 100644 --- a/plugins/things-app/uv.lock +++ b/plugins/things-app/uv.lock @@ -120,7 +120,7 @@ wheels = [ [[package]] name = "things-app-maintenance" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/web-dev-skills/.codex-plugin/plugin.json b/plugins/web-dev-skills/.codex-plugin/plugin.json index 7f9a8b7d..8585feff 100644 --- a/plugins/web-dev-skills/.codex-plugin/plugin.json +++ b/plugins/web-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "web-dev-skills", - "version": "8.5.4", + "version": "8.5.5", "description": "Codex skills for focused web and Expo native-boundary workflows.", "author": { "name": "Gale", diff --git a/pyproject.toml b/pyproject.toml index 424fee6f..4b17119f 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "socket-maintenance" -version = "8.5.4" +version = "8.5.5" description = "Root uv tooling baseline for the socket superproject." requires-python = ">=3.11" dependencies = [] diff --git a/uv.lock b/uv.lock index 4bb680f2..f804f514 100644 --- a/uv.lock +++ b/uv.lock @@ -286,7 +286,7 @@ wheels = [ [[package]] name = "socket-maintenance" -version = "8.5.4" +version = "8.5.5" source = { virtual = "." } [package.dev-dependencies]