From 3b1b11bbb378ab74d7898739c7956cf1091f03f1 Mon Sep 17 00:00:00 2001 From: Gale W Date: Wed, 8 Jul 2026 13:28:02 -0400 Subject: [PATCH 1/2] docs: enforce strict xcodegen project roots --- .../.github/scripts/sync_shared_snippets.sh | 1 + .../apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../bootstrap-xcode-app-project/SKILL.md | 4 +- .../assets/AGENTS.md | 6 ++- .../references/project-generators.md | 6 ++- .../snippets/apple-xcode-project-core.md | 7 ++- ...xcodegen-synced-folder-and-config-notes.md | 22 +++++--- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../SKILL.md | 4 +- .../migration-audit-and-promotion.md | 22 +++++--- .../snippets/apple-xcode-project-core.md | 7 ++- .../migrate_xcode_project_to_xcodegen.py | 50 ++++++++++++++++++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../assets/AGENTS.md | 6 ++- .../assets/append-section.md | 6 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../xcodegen-project-maintenance.md | 4 +- .../snippets/apple-xcode-project-core.md | 7 ++- .../xcodegen-project-maintenance.md | 5 +- .../snippets/apple-xcode-project-core.md | 7 ++- .../snippets/apple-xcode-project-core.md | 7 ++- .../xcodegen-project-maintenance.md | 5 +- .../xcodegen/swiftui-app/project.yml.tmpl | 7 +-- .../test_xcode_app_bootstrap_workflow.py | 17 +++++-- .../tests/test_xcodegen_migration_workflow.py | 48 +++++++++++++++++- 40 files changed, 298 insertions(+), 83 deletions(-) diff --git a/plugins/apple-dev-skills/.github/scripts/sync_shared_snippets.sh b/plugins/apple-dev-skills/.github/scripts/sync_shared_snippets.sh index 2366dd09..f03cb690 100755 --- a/plugins/apple-dev-skills/.github/scripts/sync_shared_snippets.sh +++ b/plugins/apple-dev-skills/.github/scripts/sync_shared_snippets.sh @@ -53,6 +53,7 @@ sync_one \ "$ROOT_DIR/skills/xcode-testing-workflow/references/snippets/apple-xcode-project-core.md" \ "$ROOT_DIR/skills/xcode-app-project-workflow/references/snippets/apple-xcode-project-core.md" \ "$ROOT_DIR/skills/bootstrap-xcode-app-project/references/snippets/apple-xcode-project-core.md" \ + "$ROOT_DIR/skills/migrate-xcode-project-to-xcodegen/references/snippets/apple-xcode-project-core.md" \ "$ROOT_DIR/skills/format-swift-sources/references/snippets/apple-xcode-project-core.md" \ "$ROOT_DIR/skills/explore-apple-swift-docs/references/snippets/apple-xcode-project-core.md" \ "$ROOT_DIR/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md" \ 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/SKILL.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/SKILL.md index c5871ab1..d7efe510 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/SKILL.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/SKILL.md @@ -70,7 +70,9 @@ This skill can be discovered from a standalone `apple-dev-skills` install, but i - install `.codex/environments/xcode-project.toml` from `templates/codex-local-environments/xcode-project.toml` and replace the scheme placeholder with the generated app target name - keep the generated `project.yml` aligned with the current XcodeGen project spec concepts: project `options`, `configs`, `configFiles`, targets, sources, schemes, packages, project references, test-plan references, and `minimumXcodeGenVersion` - keep the generated `minimumXcodeGenVersion` on the recent validated baseline declared by the templates; when the baseline is raised, update the templates, docs, and tests together - - prefer XcodeGen `syncedFolder` source roots for app and test source directories when the generated project format is Xcode 16 or newer; use broad recursive source paths with explicit `includes` and `excludes` as the fallback when synchronized folders are not appropriate + - use exactly one top-level `Sources` entry for the app target and exactly one top-level `Tests` entry for the test target when the generated project format is Xcode 16 or newer; prefer `type: syncedFolder` on those broad roots, and use the same broad roots with explicit `includes` and `excludes` as the fallback when synchronized folders are not appropriate + - never split ordinary generated app project paths into separate XcodeGen source entries such as `Sources/App`, `Sources/Resources`, `Sources/Support`, feature subfolders, or `Tests/Tests`; use a separate top-level path only for a separate logical root such as repo-root `Resources` + - create exactly one app lifecycle entry point for the app target; do not create alternate `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants; keep platform or configuration differences inside the single entry point with Swift conditional compilation or runtime conditionals - keep nontrivial build settings in external `.xcconfig` files by default, using shared, target-level, and per-configuration layers wired through the XcodeGen spec instead of duplicating settings inline - install a checked-in external app entitlement plist and wire it through `CODE_SIGN_ENTITLEMENTS` in the app `.xcconfig` so capability changes have a real tracked file owner instead of living only in generated project state - for `xcode`, use a guarded guidance path for now instead of pretending the repo supports full GUI automation already 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 23bbb01f..77267ec9 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 @@ -23,7 +23,11 @@ - If this repo is XcodeGen-backed, treat `project.yml`, `project.yaml`, and any included XcodeGen specs as the source of truth for generated targets, schemes, build settings, build configurations, Swift packages, test-plan references, and file membership. - For XcodeGen-backed projects, edit the spec set and rerun `xcodegen generate` instead of hand-editing generated `.pbxproj` files. - Before running `xcodegen generate`, inspect the current git diff for generated `.xcodeproj` or `.pbxproj` changes. Treat existing project-file diffs as intentional user or Xcode GUI changes by default, promote intentional values into the owning tracked source files first, and only then regenerate. Use XcodeGen specs for structure, `.xcconfig` files for build settings, `.entitlements` files for entitlement keys, `Info.plist` for plist keys, scheme specs or `.xcscheme` files for scheme behavior, and `.xctestplan` files for test-plan content. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for normal app and test directories so Xcode and the filesystem stay aligned for file membership. If that does not fit a repo, use broad recursive source paths with explicit `includes` and `excludes` as the fallback. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` does not fit a repo, use the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes` as the fallback; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. Keep platform, configuration, or feature-flag differences inside that single entry point with Swift conditional compilation or runtime conditionals. - Keep XcodeGen specs readable as project structure: use explicit `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, and templates when they make ownership clearer. - Prefer external `.xcconfig` files for nontrivial build settings, wire them from the XcodeGen spec, keep secrets, personal team IDs, local paths, provisioning profiles, and API tokens out of committed configs, and review config diffs with the spec and generated project diff. - Keep `.xcconfig` layering explicit: a small shared base, target-level configs for app/test/extension identity, then per-configuration configs for Debug, Release, CI, or deployment variants. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/project-generators.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/project-generators.md index 785e23d2..fab2064f 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/project-generators.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/project-generators.md @@ -13,8 +13,10 @@ Describe the supported generator choices for `bootstrap-xcode-app-project`. - The project spec may be YAML or JSON; this skill emits YAML as `project.yml` from `templates/xcodegen/swiftui-app/project.yml.tmpl`. - The generated scaffold should require the recent validated XcodeGen baseline declared in the template. As of this guidance, that baseline is `minimumXcodeGenVersion: 2.45.4`. - Current project-spec concepts this skill should keep aligned include `options.minimumXcodeGenVersion`, `options.projectFormat`, `configs`, `configFiles`, targets, sources, schemes, Swift packages, project references, target templates, scheme templates, and test-plan references. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for normal app and test directories so Xcode and the filesystem stay aligned for file membership without hand-listing ordinary source files in YAML. -- Use broad recursive source paths with explicit `includes` and `excludes` as the fallback when synchronized folders are not appropriate for a repo. Avoid per-file YAML source entries unless a file needs custom compiler flags, build-phase routing, or another exceptional setting. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership without hand-listing ordinary source files in YAML. +- Use exactly one top-level `Sources` entry for the app target and exactly one top-level `Tests` entry for the test target. If a repo has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root. +- Do not split ordinary folders such as `Sources/App`, `Sources/Resources`, `Sources/Support`, feature subfolders, or `Tests/Tests` into separate XcodeGen source entries. Use broad recursive source paths with explicit `includes` and `excludes` as the fallback when synchronized folders are not appropriate for a repo. Avoid per-file YAML source entries unless a file needs custom compiler flags, build-phase routing, or another exceptional setting. +- Create exactly one app lifecycle entry point per app target. Use one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry; put platform, configuration, or product-variant differences inside that single entry point with Swift conditional compilation or runtime conditionals. - Prefer checked-in external `.xcconfig` files for nontrivial build settings and wire them from the XcodeGen spec rather than duplicating settings inline. New app scaffolds should start with shared, target-level, and per-configuration `.xcconfig` layers. - Start app scaffolds with `MARKETING_VERSION = 0.0.1` and `CURRENT_PROJECT_VERSION = 1` in the app `.xcconfig`, and wire generated `Info.plist` version keys to those build settings. - Keep shared Swift language and concurrency defaults in `Shared.xcconfig`, including `SWIFT_VERSION = 6.0`, so every generated target inherits the same language baseline. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/xcodegen-synced-folder-and-config-notes.md b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/xcodegen-synced-folder-and-config-notes.md index 592930e0..d18236c4 100644 --- a/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/xcodegen-synced-folder-and-config-notes.md +++ b/plugins/apple-dev-skills/skills/bootstrap-xcode-app-project/references/xcodegen-synced-folder-and-config-notes.md @@ -2,18 +2,26 @@ ## Decision -- For new XcodeGen-backed app scaffolds that use `projectFormat: xcode16_0` or newer, prefer `syncedFolder` source roots for ordinary app and test source directories. -- Use broad recursive `sources` paths with explicit `includes` and `excludes` as the fallback when synchronized folders do not fit a repo. -- Avoid one YAML entry per ordinary source file. Use per-file source entries only for exceptional compiler flags, build-phase routing, destination filters, or other file-specific behavior. +- For new XcodeGen-backed app scaffolds that use `projectFormat: xcode16_0` or newer, prefer `syncedFolder` roots at the broad top-level directory boundary. +- Use exactly one top-level `Sources` source entry for the app target and exactly one top-level `Tests` source entry for the test target. If a repo has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root. +- Use those same broad recursive paths with explicit `includes` and `excludes` as the fallback when synchronized folders do not fit a repo. +- Avoid subdirectory fragmentation and one YAML entry per ordinary source file. Use narrower source entries only for exceptional compiler flags, build-phase routing, destination filters, target membership, or other file-specific behavior that cannot be represented from the broad root. ## Template Shape -- Keep app source files under `Sources/App` and test files under `Tests/Tests`. -- Keep resources under `Sources/Resources`, including a default `Assets.xcassets` with `AppIcon` and `AccentColor` placeholders. -- Set `options.defaultSourceDirectoryType: syncedFolder` and mark app/test/resource roots with `type: syncedFolder` so the intended behavior is visible at the target boundary. -- Keep support files such as generated `Info.plist` and checked-in entitlements outside the synced source root unless they are intentionally part of that target's buildable folder. +- Keep app source, resources, support files, generated `Info.plist`, checked-in entitlements, feature folders, and nested implementation folders under `Sources/` when they belong to the app target. +- Keep tests under `Tests/` when they belong to the test target. +- Keep resources under `Sources/Resources`, including a default `Assets.xcassets` with `AppIcon` and `AccentColor` placeholders, but do not add `Sources/Resources` as a separate XcodeGen source entry when `Sources` already owns the target root. +- Set `options.defaultSourceDirectoryType: syncedFolder` and mark only the broad target roots with `type: syncedFolder` so the intended behavior is visible at the target boundary. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate ordinary XcodeGen source entries. - Keep `Configurations/` visible as a `fileGroups` entry so `.xcconfig` layers are easy to find in Xcode. +## App Entry Point + +- Create exactly one app lifecycle entry point per app target: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. +- Do not add alternate app entry points, second `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. +- Put platform, configuration, feature-flag, or product-variant differences inside the single entry point using Swift conditional compilation or ordinary runtime conditionals. + ## Entitlements - Prefer a checked-in external entitlement plist for every app, extension, or capability-bearing target. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/SKILL.md b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/SKILL.md index f74f4233..2d55e25e 100644 --- a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/SKILL.md +++ b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/SKILL.md @@ -45,7 +45,7 @@ Convert existing native Apple app projects to the current XcodeGen baseline with - identify build settings that need `.xcconfig` owners - identify entitlements that need checked-in `.entitlements` owners - identify Info.plist values that need checked-in plist or build-setting owners - - identify resources and asset catalogs that need synced resource roots + - identify resources and asset catalogs that must be preserved under the broad app source root or under one separate top-level resource root when the repo actually has that shape - identify schemes and test plans that need explicit tracked files 6. Prepare the migration branch: - add or update `project.yml` @@ -53,6 +53,8 @@ Convert existing native Apple app projects to the current XcodeGen baseline with - add or update `Sources/Support/.entitlements` - add or update `Sources/Support/Info.plist` - add or update `Sources/Resources/Assets.xcassets` + - keep the app target's XcodeGen source declaration collapsed to one top-level `Sources` entry and the test target's declaration collapsed to one top-level `Tests` entry + - preserve exactly one app lifecycle entry point; do not create alternate `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants - preserve existing package, framework, source, resource, script phase, scheme, and test-plan state 7. Generate into a temp or reviewed branch state: - run `xcodegen generate` only after promoted state is represented in tracked source files diff --git a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/migration-audit-and-promotion.md b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/migration-audit-and-promotion.md index 152d76a7..3a07c047 100644 --- a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/migration-audit-and-promotion.md +++ b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/references/migration-audit-and-promotion.md @@ -6,11 +6,12 @@ Use this reference after `scripts/run_workflow.py` has produced a project audit. - Treat `.pbxproj` changes as intentional until reviewed. Xcode often writes GUI build-setting, signing, capability, source-membership, resource, scheme, and package state there. - Promote durable settings into checked-in files before regenerating: - - `project.yml` for project structure, targets, packages, source roots, resource roots, schemes, and test plans + - `project.yml` for project structure, targets, packages, broad source roots, broad resource roots, schemes, and test plans - `Configurations/*.xcconfig` for build settings - `Sources/Support/.entitlements` for capabilities and sandbox entitlements - `Sources/Support/Info.plist` for Info.plist values - `Sources/Resources/Assets.xcassets` for assets, app icons, accent colors, and generated asset symbols +- Preserve exactly one app lifecycle entry point per app target. If migration reveals multiple `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs, collapse the launch behavior back into one entry point and use Swift conditional compilation or runtime conditionals inside that boundary. - Keep `xcodegen generate` as the last step after promotion, not the first step. ## Xcode-Managed To XcodeGen @@ -26,8 +27,11 @@ This is the `xcode-managed-to-xcodegen` path emitted by the audit script. - resource folder with `Assets.xcassets` when missing 3. Write `project.yml` from the inventory: - prefer `options.defaultSourceDirectoryType: syncedFolder` - - prefer `type: syncedFolder` for app, test, and resource roots on Xcode 16 or newer - - use broad recursive paths with explicit includes and excludes only when synced folders are not appropriate + - prefer `type: syncedFolder` for broad top-level roots on Xcode 16 or newer + - use exactly one `Sources` entry for the app target and exactly one `Tests` entry for the test target + - use one separate top-level `Resources` entry only when the repo really has a separate repo-root resource tree + - never split ordinary paths such as `Sources/App`, `Sources/Resources`, `Sources/Support`, feature subfolders, or `Tests/Tests` into separate XcodeGen source entries + - use the same broad recursive paths with explicit includes and excludes only when synced folders are not appropriate 4. Generate and compare: - generate in a temp clone or reviewed branch state - compare key build settings, target membership, schemes, package references, entitlements, and resources @@ -39,9 +43,10 @@ Use this `modernize-xcodegen` path to modernize XcodeGen projects that already h 1. Audit the existing `project.yml` and generated `.pbxproj`. 2. Move inline or generated-only settings into `.xcconfig` files. -3. Add missing external entitlements, Info.plist, resource roots, and asset catalog defaults. -4. Prefer synced folders for app, test, and resource roots when the supported Xcode/XcodeGen versions allow it. -5. Regenerate and verify the generated `.pbxproj` diff is expected. +3. Add missing external entitlements, Info.plist, resource folders, and asset catalog defaults under the broad owning root. +4. Prefer synced folders for broad app, test, and top-level resource roots when the supported Xcode/XcodeGen versions allow it. +5. Collapse any ordinary source-root fragmentation back to one `Sources` entry, one `Tests` entry, and at most one entry for each genuinely separate top-level logical root. +6. Regenerate and verify the generated `.pbxproj` diff is expected. ## Baseline Targets @@ -49,7 +54,10 @@ The current baseline should include: - XcodeGen `minimumXcodeGenVersion` on the current template baseline - `options.defaultSourceDirectoryType: syncedFolder` -- app/test/resource roots marked with `type: syncedFolder` +- app target source membership declared as one broad `Sources` entry marked with `type: syncedFolder` +- test target source membership declared as one broad `Tests` entry marked with `type: syncedFolder` +- no ordinary fragmentation into `Sources/App`, `Sources/Resources`, `Sources/Support`, feature subfolders, or `Tests/Tests` source entries +- exactly one app lifecycle entry point per app target - shared, app, test, Debug, and Release `.xcconfig` layers - `SWIFT_VERSION = 6.0` - Swift concurrency defaults 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/scripts/migrate_xcode_project_to_xcodegen.py b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/scripts/migrate_xcode_project_to_xcodegen.py index 2dd03472..6dc094db 100755 --- a/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/scripts/migrate_xcode_project_to_xcodegen.py +++ b/plugins/apple-dev-skills/skills/migrate-xcode-project-to-xcodegen/scripts/migrate_xcode_project_to_xcodegen.py @@ -31,7 +31,6 @@ "default_source_directory_type": "defaultSourceDirectoryType: syncedFolder", "synced_folder_sources": "type: syncedFolder", "config_files": "configFiles:", - "resources_root": "Sources/Resources", "support_files": "Sources/Support", "version_marketing": "CFBundleShortVersionString: $(MARKETING_VERSION)", "version_build": "CFBundleVersion: $(CURRENT_PROJECT_VERSION)", @@ -112,6 +111,36 @@ def extract_pbxproj_target_names(pbxproj_text: str) -> list[str]: return sorted(cleaned) +def extract_fragmented_source_entries(project_yml_text: str) -> list[str]: + fragments = set() + pattern = re.compile(r"^\s*-\s*(?:path:\s*)?(Sources|Tests|Resources)/([^\s#]+)", re.MULTILINE) + for match in pattern.finditer(project_yml_text): + fragments.add(f"{match.group(1)}/{match.group(2).rstrip(',')}") + return sorted(fragments) + + +def has_broad_source_entry(project_yml_text: str, root_name: str) -> bool: + escaped = re.escape(root_name) + pattern = re.compile(rf"^\s*-\s*(?:path:\s*)?{escaped}\s*(?:$|#)", re.MULTILINE) + return bool(pattern.search(project_yml_text)) + + +def find_app_entry_points(repo_root: Path) -> list[str]: + sources_root = repo_root / "Sources" + if not sources_root.exists(): + return [] + + entries: set[str] = set() + for path in sorted(sources_root.rglob("*.swift"), key=lambda item: str(item)): + if path.name == "main.swift": + entries.add(rel(path, repo_root)) + continue + text = read_text(path) + if re.search(r"^\s*@main\b", text, re.MULTILINE): + entries.add(rel(path, repo_root)) + return sorted(entries) + + def infer_app_name(discovered: dict[str, Any], target_names: list[str]) -> str | None: if target_names: app_targets = [name for name in target_names if not name.lower().endswith(("tests", "uitests"))] @@ -132,10 +161,16 @@ def audit_project_yml(project_yml_path: Path | None) -> dict[str, Any]: text = read_text(project_yml_path) gaps = [name for name, needle in BASELINE_PROJECT_YML_NEEDLES.items() if needle not in text] + if not has_broad_source_entry(text, "Sources"): + gaps.append("sources_root") + if not has_broad_source_entry(text, "Tests"): + gaps.append("tests_root") + fragmented_source_entries = extract_fragmented_source_entries(text) return { "present": True, "path": str(project_yml_path), "baseline_gaps": sorted(gaps), + "fragmented_source_entries": fragmented_source_entries, "uses_synced_folder": "syncedFolder" in text, "uses_config_files": "configFiles:" in text, "declares_minimum_xcodegen": "minimumXcodeGenVersion:" in text, @@ -159,6 +194,7 @@ def audit_files(repo_root: Path, app_name: str | None) -> dict[str, Any]: "asset_catalogs": sorted_relative(asset_catalogs, repo_root), "schemes": sorted_relative(schemes, repo_root), "test_plans": sorted_relative(test_plans, repo_root), + "app_entry_points": find_app_entry_points(repo_root), "expected_app_entitlements": expected_app_entitlements, "has_app_named_entitlements": (repo_root / expected_app_entitlements).exists() if app_name else False, "has_default_assets": (repo_root / "Sources/Resources/Assets.xcassets").exists(), @@ -201,6 +237,18 @@ def build_recommendations( if project_yml_audit["baseline_gaps"]: recommendations.append("Update project.yml for current baseline gaps: " + ", ".join(project_yml_audit["baseline_gaps"]) + ".") + if project_yml_audit.get("fragmented_source_entries"): + recommendations.append( + "Collapse fragmented XcodeGen source entries into broad top-level roots: " + + ", ".join(project_yml_audit["fragmented_source_entries"]) + + ". Use one Sources entry for the app target, one Tests entry for the test target, and one entry per separate top-level logical root only." + ) + if len(file_audit["app_entry_points"]) > 1: + recommendations.append( + "Collapse multiple app lifecycle entry points into one app target entry point: " + + ", ".join(file_audit["app_entry_points"]) + + ". Use Swift conditionals inside the single entry point for variants." + ) if pbxproj_settings: recommendations.append("Promote pbxproj build settings into .xcconfig owners: " + ", ".join(pbxproj_settings) + ".") if not file_audit["xcconfigs"]: 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 ff3920bd..6d3cd8bf 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 @@ -25,7 +25,11 @@ - If this repo is XcodeGen-backed, treat `project.yml`, `project.yaml`, and any included XcodeGen specs as the source of truth for generated targets, schemes, build settings, build configurations, Swift packages, test-plan references, and file membership. - For XcodeGen-backed projects, edit the spec set and rerun `xcodegen generate` instead of hand-editing generated `.pbxproj` files. - Before running `xcodegen generate`, inspect the current git diff for generated `.xcodeproj` or `.pbxproj` changes. Treat existing project-file diffs as intentional user or Xcode GUI changes by default, promote intentional values into the owning tracked source files first, and only then regenerate. Use XcodeGen specs for structure, `.xcconfig` files for build settings, `.entitlements` files for entitlement keys, `Info.plist` for plist keys, scheme specs or `.xcscheme` files for scheme behavior, and `.xctestplan` files for test-plan content. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for normal app and test directories so Xcode and the filesystem stay aligned for file membership. If that does not fit a repo, use broad recursive source paths with explicit `includes` and `excludes` as the fallback. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` does not fit a repo, use the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes` as the fallback; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. Keep platform, configuration, or feature-flag differences inside that single entry point with Swift conditional compilation or runtime conditionals. - Keep XcodeGen specs readable as project structure: use explicit `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, and templates when they make ownership clearer. - Prefer external `.xcconfig` files for nontrivial build settings, wire them from the XcodeGen spec, keep secrets, personal team IDs, local paths, provisioning profiles, and API tokens out of committed configs, and review config diffs with the spec and generated project diff. - Keep `.xcconfig` layering explicit: a small shared base, target-level configs for app/test/extension identity, then per-configuration configs for Debug, Release, CI, or deployment variants. 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 c7073130..2d6514e2 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 @@ -23,7 +23,11 @@ - If this repo is XcodeGen-backed, treat `project.yml`, `project.yaml`, and any included XcodeGen specs as the source of truth for generated targets, schemes, build settings, build configurations, Swift packages, test-plan references, and file membership. - For XcodeGen-backed projects, edit the spec set and rerun `xcodegen generate` instead of hand-editing generated `.pbxproj` files. - Before running `xcodegen generate`, inspect the current git diff for generated `.xcodeproj` or `.pbxproj` changes. Treat existing project-file diffs as intentional user or Xcode GUI changes by default, promote intentional values into the owning tracked source files first, and only then regenerate. Use XcodeGen specs for structure, `.xcconfig` files for build settings, `.entitlements` files for entitlement keys, `Info.plist` for plist keys, scheme specs or `.xcscheme` files for scheme behavior, and `.xctestplan` files for test-plan content. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for normal app and test directories so Xcode and the filesystem stay aligned for file membership. If that does not fit a repo, use broad recursive source paths with explicit `includes` and `excludes` as the fallback. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` does not fit a repo, use the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes` as the fallback; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. Keep platform, configuration, or feature-flag differences inside that single entry point with Swift conditional compilation or runtime conditionals. - Keep XcodeGen specs readable as project structure: use explicit `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, and templates when they make ownership clearer. - Prefer external `.xcconfig` files for nontrivial build settings, wire them from the XcodeGen spec, keep secrets, personal team IDs, local paths, provisioning profiles, and API tokens out of committed configs, and review config diffs with the spec and generated project diff. - Keep `.xcconfig` layering explicit: a small shared base, target-level configs for app/test/extension identity, then per-configuration configs for Debug, Release, CI, or deployment variants. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/xcodegen-project-maintenance.md b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/xcodegen-project-maintenance.md index e7e243e3..5e7312cc 100644 --- a/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/xcodegen-project-maintenance.md +++ b/plugins/apple-dev-skills/skills/xcode-app-project-workflow/references/xcodegen-project-maintenance.md @@ -16,7 +16,9 @@ Authoritative XcodeGen references: - If the request asks for new-project defaults, template changes, minimum XcodeGen versions, or baseline `.xcconfig` layout, route to `bootstrap-xcode-app-project`. - Treat XcodeGen specs as the owner for targets, resources, schemes, packages, project references, test-plan references, configuration-file wiring, generation options, and generated file membership. - Before any regeneration, route existing generated `.xcodeproj` or `.pbxproj` diffs through the narrower build/run or testing workflow so user-made Xcode GUI changes can be promoted into the owning XcodeGen spec, `.xcconfig`, `.entitlements`, `Info.plist`, scheme, or test-plan file first. -- Treat Xcode 16 `syncedFolder` source roots as the preferred file-membership model for new generated app/test source directories, with broad recursive source paths plus explicit `includes` and `excludes` as the fallback. +- Treat Xcode 16 `syncedFolder` roots at the broad top-level directory boundary as the preferred file-membership model for new generated app and test targets. Use exactly one `Sources` entry for the app target and exactly one `Tests` entry for the test target; if a repo has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root. +- Do not split ordinary folders such as `Sources/App`, `Sources/Resources`, `Sources/Support`, feature subfolders, or `Tests/Tests` into separate XcodeGen source entries. Use the same broad top-level recursive source paths plus explicit `includes` and `excludes` as the fallback when synchronized folders are not appropriate. +- Preserve exactly one app lifecycle entry point per app target. Do not add alternate `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants; put platform, configuration, or product-variant differences inside the single entry point with Swift conditional compilation or runtime conditionals. - Treat `.xcconfig` files as the owner for nontrivial build settings, with shared, target-level, and per-configuration layers when a repo uses that layout. - Treat external `.entitlements` files as the owner for app, extension, and capability-bearing target entitlements when `CODE_SIGN_ENTITLEMENTS` points at a checked-in plist. - Do not assume Xcode Build Settings UI edits update `.xcconfig` files; route intentional tracked settings back into the owning config before regeneration. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/xcodegen-project-maintenance.md b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/xcodegen-project-maintenance.md index 98621455..8a5af8de 100644 --- a/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/xcodegen-project-maintenance.md +++ b/plugins/apple-dev-skills/skills/xcode-build-run-workflow/references/xcodegen-project-maintenance.md @@ -25,7 +25,9 @@ Authoritative XcodeGen references: - Keep top-level `schemes` explicit when build, run, archive, profile, analyze, command-line arguments, environment variables, or test-plan behavior matters. Do not rely on generated scheme defaults after the repo has explicit scheme policy. - Declare Swift packages in the spec-level `packages` map and link them through target `dependencies`; do not add package references by hand in the generated project. - Use `projectReferences`, `targetTemplates`, and `schemeTemplates` when they remove real repetition across generated modules, not as ceremony for a tiny one-target project. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for ordinary app, test, resource, and support directories so Xcode and the filesystem stay aligned for file membership. If synchronized folders are not appropriate, use broad recursive source paths with explicit `includes` and `excludes` as the fallback instead of hand-listing every ordinary source file. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate ordinary XcodeGen source entries. If synchronized folders are not appropriate, use the same broad top-level recursive paths with explicit `includes` and `excludes` as the fallback instead of hand-listing every ordinary source file or fragmenting by child directory. - Prefer external `.xcconfig` files for nontrivial build settings and wire them from the XcodeGen spec instead of duplicating build settings inline. - Keep `.xcconfig` layering explicit, with a small shared base config, target-level configs for app/test/extension identity, and per-configuration configs that include the narrower target config and override only what changes. - Prefer external `.entitlements` files for app, extension, and other capability-bearing targets. Wire them through `CODE_SIGN_ENTITLEMENTS` in the owning `.xcconfig`; let Xcode capabilities update the entitlement plist when possible, then review and commit the plist diff. @@ -33,6 +35,7 @@ Authoritative XcodeGen references: - Do not put secrets, personal team IDs, local filesystem paths, provisioning profiles, API tokens, or private signing material in committed `.xcconfig` files. - Do not hand-edit generated `.pbxproj` files to work around spec drift; fix the spec and regenerate. - For ordinary source edits, inspect the relevant `sources` declarations to decide whether new files are already covered or whether the spec needs an explicit source/resource entry. +- For app lifecycle edits, preserve exactly one app entry point per app target. Do not add alternate `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants; put platform, configuration, or product-variant differences inside the single entry point with Swift conditional compilation or runtime conditionals. - After changing specs, `.xcconfig` files, or entitlement-file wiring, run `xcodegen generate` from the spec root, or `xcodegen generate --spec ` when the repo uses a non-default spec path. - If the spec uses environment variables, `preGenCommand`, or `postGenCommand`, preserve the required environment and call that out in the validation notes. - Review the spec diff, `.xcconfig` diff, and generated project diff after regeneration, especially target membership, package references, signing settings, scheme actions, and build-setting churn. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. 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 9ab8fe6e..7449ff3f 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 @@ -64,6 +64,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Keep updates to view-driving state minimal and localized. - Prefer durable identity for types that drive SwiftUI state and view updates. - Treat `App` as the application entry and scene composition boundary, `Scene` as the container for scene-specific lifecycle and environment, and `View` as the component rendering layer. +- Every native app target must have exactly one app lifecycle entry point: one `@main` app type, one `main.swift`, or the platform-equivalent single launch entry. Do not add alternate app entry points, second `@main` types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants. When launch behavior must differ by platform, configuration, or feature flag, keep the single entry point and use Swift conditional compilation or ordinary runtime conditionals inside that boundary. - Use app-level lifecycle concerns at the `App` boundary, scene lifecycle concerns at the `Scene` boundary, and view-local active or presentation behavior inside views. - Use `@Binding` to pass a focused writable piece of parent-owned state into a child view. - Use `@Bindable` when working with an observable model that should project bindings to its mutable properties in a view. @@ -97,8 +98,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard - Only regenerate after that promotion is complete, then review the generated project diff to confirm XcodeGen preserved the intended behavior instead of deleting it. If the owning tracked file is ambiguous, stop and ask before regenerating. - For new XcodeGen-backed app scaffolds, start from the maintained `apple-dev-skills/templates/xcodegen/` templates when available instead of inventing a fresh project-spec shape from memory. - Keep `minimumXcodeGenVersion` on a recent validated release for new scaffolds. Prefer updating the template and validation together when the repo intentionally raises the baseline. -- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` source roots for normal app and test source directories so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. -- If `syncedFolder` behaves poorly for a repo, fall back to broad recursive source paths such as `Sources/App` and `Tests/AppTests` with explicit `includes` and `excludes`; do not fall back to one YAML entry per ordinary source file unless a specific file needs custom flags or build-phase behavior. +- For Xcode 16 or newer project formats, prefer XcodeGen `syncedFolder` roots at the broad top-level directory boundary so file creation, deletion, and organization stay synchronized between Xcode and the filesystem without hand-listing every source file in YAML. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root, not one entry per child folder. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate XcodeGen source entries unless a specific non-ordinary file or folder truly needs custom compiler flags, build-phase routing, destination filters, or target membership that cannot be represented from the broad root. +- If `syncedFolder` behaves poorly for a repo, fall back to the same broad top-level recursive paths such as `Sources`, `Tests`, or `Resources` with explicit `includes` and `excludes`; do not fall back to subdirectory-level fragmentation or one YAML entry per ordinary source file. - Keep XcodeGen specs readable as project structure, not as a dumping ground for every build setting. Use `configs`, `configFiles`, `targets`, `schemes`, `packages`, `projectReferences`, `targetTemplates`, and `schemeTemplates` deliberately so future edits have an obvious owner. - Prefer explicit top-level schemes for app scaffolds once scheme behavior matters. Put build, run, test, profile, analyze, archive, environment variables, command-line arguments, and test-plan references in the scheme spec rather than relying on hidden generated defaults. - Prefer external `.xcconfig` files as the default home for nontrivial build settings. Keep build settings in XcodeGen inline settings only when they are small, local, and clearer there. diff --git a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/xcodegen-project-maintenance.md b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/xcodegen-project-maintenance.md index 5d4799b1..b1e46737 100644 --- a/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/xcodegen-project-maintenance.md +++ b/plugins/apple-dev-skills/skills/xcode-testing-workflow/references/xcodegen-project-maintenance.md @@ -24,13 +24,16 @@ Authoritative XcodeGen references: - Use top-level `schemes` for generated test behavior once the repo needs explicit test actions, coverage settings, command-line arguments, environment variables, test targets, or test-plan references. - Remember that XcodeGen references checked-in `.xctestplan` files by path; it does not create the test-plan file content for you. Create or update the `.xctestplan` through Xcode or a structured JSON-aware edit, then wire the path through the scheme spec. - Use target-level `configFiles` for test bundles when test-only build settings, bundle identifiers, compilation conditions, or host-app settings diverge from the app target. -- For Xcode 16 or newer project formats, prefer `syncedFolder` source roots for ordinary app and test directories so Xcode and the filesystem stay aligned for file membership. If synchronized folders are not appropriate, use broad recursive source paths with explicit `includes` and `excludes` as the fallback instead of hand-listing every ordinary test file. +- For Xcode 16 or newer project formats, prefer `syncedFolder` roots at the broad top-level directory boundary so Xcode and the filesystem stay aligned for file membership. +- Do not fragment ordinary XcodeGen source roots by subdirectory. A standard app target gets one `Sources` source entry that includes all app source, resource, support, generated plist, entitlement, and nested feature folders. A standard test target gets one `Tests` source entry that includes all test subdirectories. If a project has a separate top-level logical root such as `Resources`, use one top-level `Resources` entry for that root. +- Never split `Sources/App`, `Sources/Resources`, `Sources/Support`, feature folders, or `Tests/Tests` into separate ordinary XcodeGen source entries. If synchronized folders are not appropriate, use the same broad top-level recursive paths with explicit `includes` and `excludes` as the fallback instead of hand-listing every ordinary test file or fragmenting by child directory. - Prefer external `.xcconfig` files for nontrivial build settings and wire them from the XcodeGen spec instead of duplicating build settings inline. - Keep `.xcconfig` layering explicit, with a small shared base config, target-level configs for app/test/extension identity, and per-configuration configs that include the narrower target config and override only what changes. - Do not assume Xcode's Build Settings UI writes edited values back into `.xcconfig` files. If a GUI edit creates a generated project override, move intentional tracked test settings into the owning `.xcconfig` before regenerating. - Do not put secrets, personal team IDs, local filesystem paths, provisioning profiles, API tokens, or private signing material in committed `.xcconfig` files. - Keep `.xctestplan` files versioned as ordinary source files, but wire them into schemes through the spec when the scheme itself is generated. - Do not hand-edit generated `.pbxproj` files to add test targets, test files, or test-plan references; fix the spec and regenerate. +- For app lifecycle edits uncovered during test work, preserve exactly one app entry point per app target. Do not add alternate `@main` app types, duplicate `main.swift` files, target-specific app entry files, or parallel app structs for variants; put platform, configuration, or product-variant differences inside the single entry point with Swift conditional compilation or runtime conditionals. - After changing specs, `.xcconfig` files, or entitlement-file wiring, run `xcodegen generate` from the spec root, or `xcodegen generate --spec ` when the repo uses a non-default spec path. - If the spec uses environment variables, `preGenCommand`, or `postGenCommand`, preserve the required environment and call that out in the validation notes. - Review the spec diff, `.xcconfig` diff, and generated project diff after regeneration, especially test target membership, host-app dependencies, test-plan paths, scheme actions, and build-setting churn. diff --git a/plugins/apple-dev-skills/templates/xcodegen/swiftui-app/project.yml.tmpl b/plugins/apple-dev-skills/templates/xcodegen/swiftui-app/project.yml.tmpl index 3c319fde..799e8449 100644 --- a/plugins/apple-dev-skills/templates/xcodegen/swiftui-app/project.yml.tmpl +++ b/plugins/apple-dev-skills/templates/xcodegen/swiftui-app/project.yml.tmpl @@ -9,15 +9,12 @@ configs: Release: release fileGroups: - Configurations - - Sources/Support targets: __APP_NAME__: type: application platform: __XCODEGEN_PLATFORM__ sources: - - path: Sources/App - type: syncedFolder - - path: Sources/Resources + - path: Sources type: syncedFolder info: path: Sources/Support/Info.plist @@ -32,7 +29,7 @@ targets: type: bundle.unit-test platform: __XCODEGEN_PLATFORM__ sources: - - path: Tests/__APP_NAME__Tests + - path: Tests type: syncedFolder dependencies: - target: __APP_NAME__ diff --git a/plugins/apple-dev-skills/tests/test_xcode_app_bootstrap_workflow.py b/plugins/apple-dev-skills/tests/test_xcode_app_bootstrap_workflow.py index 904ad03d..48afa1ce 100644 --- a/plugins/apple-dev-skills/tests/test_xcode_app_bootstrap_workflow.py +++ b/plugins/apple-dev-skills/tests/test_xcode_app_bootstrap_workflow.py @@ -197,8 +197,12 @@ def test_xcodegen_path_can_succeed_with_fake_tools(self) -> None: self.assertIn("schemes:", project_yml) self.assertIn("configFiles:", project_yml) self.assertIn("type: syncedFolder", project_yml) - self.assertIn("Sources/Support", project_yml) - self.assertIn("Sources/Resources", project_yml) + self.assertIn("- path: Sources", project_yml) + self.assertIn("- path: Tests", project_yml) + self.assertNotIn("- path: Sources/App", project_yml) + self.assertNotIn("- path: Sources/Resources", project_yml) + self.assertNotIn("- path: Sources/Support", project_yml) + self.assertNotIn("- path: Tests/DemoAppTests", project_yml) self.assertIn("CFBundleShortVersionString: $(MARKETING_VERSION)", project_yml) self.assertIn("CFBundleVersion: $(CURRENT_PROJECT_VERSION)", project_yml) self.assertIn("Configurations/App-Debug.xcconfig", project_yml) @@ -290,6 +294,8 @@ def test_xcodegen_path_can_succeed_with_fake_tools(self) -> None: self.assertIn("xcode-build-run-workflow", agents_text) self.assertIn("xcode-testing-workflow", agents_text) self.assertIn("XcodeGen plus synced source folders", agents_text) + self.assertIn("A standard app target gets one `Sources` source entry", agents_text) + self.assertIn("Every native app target must have exactly one app lifecycle entry point", agents_text) self.assertIn("Keep XcodeGen specs readable as project structure", agents_text) self.assertIn("Keep `.xcconfig` layering explicit", agents_text) self.assertIn("CODE_SIGN_ENTITLEMENTS", agents_text) @@ -336,7 +342,12 @@ def test_xcodegen_templates_are_checked_in_as_bootstrap_sources(self) -> None: self.assertIn("minimumXcodeGenVersion: 2.45.4", project_template) self.assertIn("defaultSourceDirectoryType: syncedFolder", project_template) self.assertIn("type: syncedFolder", project_template) - self.assertIn("Sources/Resources", project_template) + self.assertIn("- path: Sources", project_template) + self.assertIn("- path: Tests", project_template) + self.assertNotIn("- path: Sources/App", project_template) + self.assertNotIn("- path: Sources/Resources", project_template) + self.assertNotIn("- path: Sources/Support", project_template) + self.assertNotIn("- path: Tests/__APP_NAME__Tests", project_template) self.assertIn("CFBundleShortVersionString: $(MARKETING_VERSION)", project_template) self.assertIn("CFBundleVersion: $(CURRENT_PROJECT_VERSION)", project_template) self.assertIn("schemes:", project_template) diff --git a/plugins/apple-dev-skills/tests/test_xcodegen_migration_workflow.py b/plugins/apple-dev-skills/tests/test_xcodegen_migration_workflow.py index c88b8a8c..cd915e1b 100644 --- a/plugins/apple-dev-skills/tests/test_xcodegen_migration_workflow.py +++ b/plugins/apple-dev-skills/tests/test_xcodegen_migration_workflow.py @@ -89,7 +89,43 @@ def test_audits_existing_xcodegen_project_for_current_baseline_gaps(self) -> Non type: application platform: macOS sources: - - Sources + - path: Sources/App + type: syncedFolder + - path: Sources/Resources + type: syncedFolder + DemoAppTests: + type: bundle.unit-test + sources: + - path: Tests/DemoAppTests + type: syncedFolder +""", + encoding="utf-8", + ) + app_sources = repo / "Sources" / "App" + app_sources.mkdir(parents=True) + (app_sources / "DemoApp.swift").write_text( + """ +import SwiftUI + +@main +struct DemoApp: App { + var body: some Scene { + WindowGroup { Text("Demo") } + } +} +""", + encoding="utf-8", + ) + (app_sources / "DemoAppBeta.swift").write_text( + """ +import SwiftUI + +@main +struct DemoAppBeta: App { + var body: some Scene { + WindowGroup { Text("Demo") } + } +} """, encoding="utf-8", ) @@ -101,8 +137,16 @@ def test_audits_existing_xcodegen_project_for_current_baseline_gaps(self) -> Non self.assertEqual(output["migration_path"], "modernize-xcodegen") self.assertIn("default_source_directory_type", output["project_yml_audit"]["baseline_gaps"]) self.assertIn("config_files", output["project_yml_audit"]["baseline_gaps"]) - self.assertIn("resources_root", output["project_yml_audit"]["baseline_gaps"]) + self.assertIn("sources_root", output["project_yml_audit"]["baseline_gaps"]) + self.assertIn("tests_root", output["project_yml_audit"]["baseline_gaps"]) + self.assertIn("Sources/App", output["project_yml_audit"]["fragmented_source_entries"]) + self.assertIn("Sources/Resources", output["project_yml_audit"]["fragmented_source_entries"]) + self.assertIn("Tests/DemoAppTests", output["project_yml_audit"]["fragmented_source_entries"]) + self.assertIn("Sources/App/DemoApp.swift", output["file_audit"]["app_entry_points"]) + self.assertIn("Sources/App/DemoAppBeta.swift", output["file_audit"]["app_entry_points"]) self.assertTrue(any("current baseline gaps" in phase for phase in output["recommended_phases"])) + self.assertTrue(any("Collapse fragmented XcodeGen source entries" in phase for phase in output["recommended_phases"])) + self.assertTrue(any("Collapse multiple app lifecycle entry points" in phase for phase in output["recommended_phases"])) def test_blocks_when_requested_modernization_has_no_project_yml(self) -> None: with tempfile.TemporaryDirectory() as tmpdir: From 33dfe0a466944ae77d309dae589d34dbb3663a47 Mon Sep 17 00:00:00 2001 From: Gale W Date: Wed, 8 Jul 2026 13:28:33 -0400 Subject: [PATCH 2/2] release: bump socket to 8.5.2 --- plugins/agent-portability-skills/.codex-plugin/plugin.json | 2 +- plugins/agent-portability-skills/pyproject.toml | 2 +- plugins/agent-portability-skills/uv.lock | 2 +- plugins/agentdeck/.codex-plugin/plugin.json | 2 +- plugins/android-dev-skills/.codex-plugin/plugin.json | 2 +- plugins/apple-dev-skills/.codex-plugin/plugin.json | 2 +- plugins/apple-dev-skills/pyproject.toml | 2 +- plugins/apple-dev-skills/uv.lock | 2 +- plugins/cardhop-app/.codex-plugin/plugin.json | 2 +- plugins/cardhop-app/mcp/pyproject.toml | 2 +- plugins/cardhop-app/mcp/uv.lock | 2 +- plugins/cloud-deployment-skills/.codex-plugin/plugin.json | 2 +- plugins/cloud-inference-skills/.codex-plugin/plugin.json | 2 +- plugins/dotnet-skills/.codex-plugin/plugin.json | 2 +- plugins/game-dev-skills/.codex-plugin/plugin.json | 2 +- plugins/network-protocol-skills/.codex-plugin/plugin.json | 2 +- plugins/productivity-skills/.codex-plugin/plugin.json | 2 +- plugins/productivity-skills/pyproject.toml | 2 +- plugins/productivity-skills/uv.lock | 2 +- plugins/python-skills/.codex-plugin/plugin.json | 2 +- plugins/python-skills/pyproject.toml | 2 +- plugins/python-skills/uv.lock | 2 +- plugins/reverse-engineering-skills/.codex-plugin/plugin.json | 2 +- plugins/rust-skills/.codex-plugin/plugin.json | 2 +- plugins/server-side-jvm/.codex-plugin/plugin.json | 2 +- plugins/server-side-swift/.codex-plugin/plugin.json | 2 +- plugins/spotify/.codex-plugin/plugin.json | 2 +- plugins/swift-lang/.codex-plugin/plugin.json | 2 +- plugins/swiftasb-skills/.codex-plugin/plugin.json | 2 +- plugins/things-app/.codex-plugin/plugin.json | 2 +- plugins/things-app/mcp/pyproject.toml | 2 +- plugins/things-app/mcp/uv.lock | 2 +- plugins/things-app/pyproject.toml | 2 +- plugins/things-app/uv.lock | 2 +- plugins/web-dev-skills/.codex-plugin/plugin.json | 2 +- pyproject.toml | 2 +- uv.lock | 2 +- 37 files changed, 37 insertions(+), 37 deletions(-) diff --git a/plugins/agent-portability-skills/.codex-plugin/plugin.json b/plugins/agent-portability-skills/.codex-plugin/plugin.json index 8d7f1121..0ccf2894 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.1", + "version": "8.5.2", "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 37d33b9b..5442a7dc 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.1" +version = "8.5.2" 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 5f0b458c..9724db78 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.1" +version = "8.5.2" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/agentdeck/.codex-plugin/plugin.json b/plugins/agentdeck/.codex-plugin/plugin.json index 979655a3..168e1877 100644 --- a/plugins/agentdeck/.codex-plugin/plugin.json +++ b/plugins/agentdeck/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "agentdeck", - "version": "8.5.1", + "version": "8.5.2", "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 fd208a0b..b38c0bd8 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.1", + "version": "8.5.2", "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 c760a3a3..49d49912 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.1", + "version": "8.5.2", "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 6720d52e..d769eaf0 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.1" +version = "8.5.2" description = "Maintainer tooling for the apple-dev-skills repository" requires-python = ">=3.10" dependencies = [] diff --git a/plugins/apple-dev-skills/uv.lock b/plugins/apple-dev-skills/uv.lock index 6420172e..6d27efcd 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.1" +version = "8.5.2" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/cardhop-app/.codex-plugin/plugin.json b/plugins/cardhop-app/.codex-plugin/plugin.json index 8b10c930..e2d77d53 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.1", + "version": "8.5.2", "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 fb97b401..f9955708 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.1" +version = "8.5.2" 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 2613dce8..08d3ddd1 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.1" +version = "8.5.2" 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 2cf5d0c3..fc85686c 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.1", + "version": "8.5.2", "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 6b458836..8379a846 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.1", + "version": "8.5.2", "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 e978975e..4e656cba 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.1", + "version": "8.5.2", "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 f02d1a92..ecc01c2a 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.1", + "version": "8.5.2", "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 62fc9775..ed79d6d7 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.1", + "version": "8.5.2", "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 98526bcd..a287c0f1 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.1", + "version": "8.5.2", "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 595aa95c..1523a7db 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.1" +version = "8.5.2" 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 42495349..fb89680e 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.1" +version = "8.5.2" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/python-skills/.codex-plugin/plugin.json b/plugins/python-skills/.codex-plugin/plugin.json index 488625ec..2ba409ec 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.1", + "version": "8.5.2", "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 6e88e6ba..e865bd7a 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.1" +version = "8.5.2" 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 1bfc4cb7..98629013 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.1" +version = "8.5.2" 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 447b9fee..a623a806 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.1", + "version": "8.5.2", "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 21392371..d724a346 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.1", + "version": "8.5.2", "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 82f82154..ab7cfc54 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.1", + "version": "8.5.2", "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 13f25a8c..f2f55589 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.1", + "version": "8.5.2", "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 9a7627c0..a6f72547 100644 --- a/plugins/spotify/.codex-plugin/plugin.json +++ b/plugins/spotify/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "spotify", - "version": "8.5.1", + "version": "8.5.2", "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 b445243b..19c0175f 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.1", + "version": "8.5.2", "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 9aff7c63..3b979337 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.1", + "version": "8.5.2", "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 e830e079..93289c41 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.1", + "version": "8.5.2", "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 ad46c56f..dfe3124b 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.1" +version = "8.5.2" 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 daf2122c..23fe3e6e 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.1" +version = "8.5.2" source = { editable = "." } dependencies = [ { name = "fastmcp" }, diff --git a/plugins/things-app/pyproject.toml b/plugins/things-app/pyproject.toml index 0e1d2bd2..5ad85f80 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.1" +version = "8.5.2" 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 ec7107f9..80814bb3 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.1" +version = "8.5.2" 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 5b712f77..d50a6512 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.1", + "version": "8.5.2", "description": "Codex skills for focused web and Expo native-boundary workflows.", "author": { "name": "Gale", diff --git a/pyproject.toml b/pyproject.toml index ed45ecc9..4786feca 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "socket-maintenance" -version = "8.5.1" +version = "8.5.2" description = "Root uv tooling baseline for the socket superproject." requires-python = ">=3.11" dependencies = [] diff --git a/uv.lock b/uv.lock index 6428dba6..144925e2 100644 --- a/uv.lock +++ b/uv.lock @@ -286,7 +286,7 @@ wheels = [ [[package]] name = "socket-maintenance" -version = "8.5.1" +version = "8.5.2" source = { virtual = "." } [package.dev-dependencies]