apple-dev: adopt prefixed Swift naming

ROADMAP.md

@@ -841,7 +841,7 @@ Completed Milestone 23 by adding the `cloud-inference-skills` child plugin, ship
 
 ## History
 
-- Added repo-wide SwiftData and SwiftUI guidance that requires SwiftData-backed SwiftUI screens to stay directly driven by SwiftData's Apple-integrated data path, with regression coverage for every SwiftUI or SwiftData skill entrypoint and stale snippet wording.
+- Re-contained SwiftData persistence guidance in a dedicated Apple Dev skill and SwiftUI composition in its architecture skill, while introducing the explicit three-letter Swift prefix and Xcode-friendly concatenated filename grammar.
 - Made Socket worktree-first for implementation work while keeping the base `main` checkout as the clean coordination and release-verification surface.
 - Aligned Socket documentation-source routing away from generic documentation aggregators by making Xcode MCP `DocumentationSearch` the Apple SDK default, Dash MCP/HTTP the preferred local-docs path for installed docsets across supported stacks, and canonical upstream docs/source the fallback when Dash/local coverage is missing or stale.
 - Added the first repo-local Socket Steward prototype under `.agents/socket-steward`, giving the superproject a Python and OpenAI Agents SDK maintainer-agent scaffold with offline docs, guidance, and marketplace audits before any write-capable or background-service behavior.

plugins/agent-portability-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-portability-skills",
-  "version": "8.6.0",
+  "version": "8.7.0",
   "description": "Maintainer skills for Socket-owned agent skill portability, Codex plugin surfaces, and host adapter guidance.",
   "author": {
     "name": "Gale",

plugins/agent-portability-skills/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "agent-portability-skills-maintenance"
-version = "8.6.0"
+version = "8.7.0"
 description = "Maintainer-only Python tooling baseline for Agent Portability Skills."
 requires-python = ">=3.11"
 dependencies = []

plugins/agentdeck/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agentdeck",
-  "version": "8.6.0",
+  "version": "8.7.0",
   "description": "Local Codex runtime utilities for thread, hook, and app-server workflows.",
   "author": {
     "name": "Gale",

plugins/android-dev-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "android-dev-skills",
-  "version": "8.6.0",
+  "version": "8.7.0",
   "description": "Android, Kotlin, Java, Gradle, Android Gradle Plugin, testing, lint, UI implementation, and release-readiness workflow skills.",
   "author": {
     "name": "Gale",

plugins/apple-dev-skills/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "apple-dev-skills",
-  "version": "8.6.0",
-  "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.",
+  "version": "8.7.0",
+  "description": "Apple development workflows for Codex, including SwiftData, SwiftUI architecture, media and audio repair, XcodeGen migration, Xcode coding intelligence, Core Animation, typography, SF Symbols, AppKit, Safari, DeviceCheck/App Attest, Swift OpenAPI clients, and DocC.",
   "author": {
     "name": "Gale",
     "email": "mail@galewilliams.com",
@@ -71,6 +71,7 @@
       "Design a DeviceCheck or App Attest flow for this Apple app, keeping DCDevice, DCAppAttestService, server challenges, entitlements, rollout, and backend validation handoffs explicit.",
       "Add or diagnose a generated Swift OpenAPI client in this Apple app using OpenAPIURLSession and current Apple docs.",
       "Help me build, test, or debug this Swift or Xcode project using the repo's Apple workflows.",
+      "Design, migrate, test, or integrate SwiftData persistence using the dedicated SwiftData workflow and current Apple documentation.",
       "Write or review DocC symbol comments, articles, extension files, and landing-page structure for this Swift repository.",
       "Sync the Apple project guidance in this repo without hand-editing Xcode project files, using Productivity Skills when repo-maintenance files must be installed or refreshed."
     ],

plugins/apple-dev-skills/.github/scripts/validate_repo_docs.sh

@@ -126,6 +126,7 @@ active_skill_mds=(
   "./skills/devicecheck-app-attest-workflow/SKILL.md"
   "./skills/appkit-app-architecture-workflow/SKILL.md"
   "./skills/swiftui-app-architecture-workflow/SKILL.md"
+  "./skills/swiftdata-workflow/SKILL.md"
   "./skills/apple-ui-accessibility-workflow/SKILL.md"
   "./skills/explore-apple-swift-docs/SKILL.md"
   "./skills/format-swift-sources/SKILL.md"
@@ -137,7 +138,7 @@ active_skill_mds=(
   "./skills/sync-swift-package-guidance/SKILL.md"
   "./skills/xcode-coding-intelligence-workflow/SKILL.md"
 )
-[[ ${#active_skill_mds[@]} -eq 30 ]] || fail "Expected exactly 30 active skills, found ${#active_skill_mds[@]}."
+[[ ${#active_skill_mds[@]} -eq 31 ]] || fail "Expected exactly 31 active skills, found ${#active_skill_mds[@]}."
 
 shared_xcode_snippet="./shared/agents-snippets/apple-xcode-project-core.md"
 shared_package_snippet="./shared/agents-snippets/apple-swift-package-core.md"

plugins/apple-dev-skills/README.md

@@ -147,6 +147,7 @@ uv run pytest
 - `safari-extension-control-workflow`
 - `sf-symbols-workflow`
 - `structure-swift-sources`
+- `swiftdata-workflow`
 - `swift-openapi-client-workflow`
 - `swift-package-build-run-workflow`
 - `swift-package-testing-workflow`

plugins/apple-dev-skills/ROADMAP.md

@@ -1,5 +1,7 @@
 # Project Roadmap
 
+Swift naming and persistence ownership are now standardized: each project explicitly selects a three-letter prefix, project-owned Swift filenames use concatenated Xcode-friendly names without `+`, runtime/domain values use bare names, `Model` is reserved for persistence, and `swiftdata-workflow` owns SwiftData guidance.
+
 ## Table of Contents
 
 - [Vision](#vision)
@@ -783,7 +785,7 @@ Completed Milestone 53 by adding `devicecheck-app-attest-workflow`, focused refe
 - Tightened Xcode project guidance so tracked `.pbxproj` diffs produced by Xcode, XcodeGen, or other project-aware workflows are treated as critical project state that must be reviewed, staged, and committed before push, merge, release, or cleanup.
 - Updated standalone install guidance so `apple-dev-skills` defaults to Codex's Git-backed marketplace add/upgrade flow without an explicit ref, documents the optional `socket` marketplace path for Gale's broader plugin set, and keeps manual local clone marketplaces as development and fallback paths.
 - Tightened the Swift public API guidance across shared snippets, skill-local snippet copies, and generated `AGENTS.md` templates so public call sites default to streamlined typed APIs, optional defaulted parameters over overloads, request/options structs at four or more public parameters, and enum-backed choice modeling.
-- Aligned Xcode app-project guidance around strict Apple-app MVVM source structure: view-local models beside views as `<ViewName>+Model.swift`, UIKit/AppKit controller support beside views as `<ViewName>+Controller.swift`, app-wide `@Observable` state in `<AppName>App+ViewModel.swift`, directional `Services/Consumed`, `Services/Internal`, and `Services/Provided` folders, and no root `Controllers/` directory.
+- Previously aligned Xcode app-project guidance around strict Apple-app MVVM source structure; the later three-letter-prefix migration superseded its paired-file naming with concatenated Xcode-friendly names while retaining directional service folders and no root `Controllers/` directory.
 - Added strict app-structure drift reporting to `sync-xcode-project-guidance` and updated the XcodeGen bootstrap scaffold so new SwiftUI app projects start with `Sources/Views/Shared`, `Sources/Views/macOS`, `Sources/Views/iOS`, `Sources/Models`, and directional `Sources/Services` folders.
 - Registered Xcode's built-in MCP bridge through the Codex plugin manifest so installed `apple-dev-skills` plugins expose the Xcode-owned MCP path without bundling a separate server package.
 - Added an experimental `xcode_lldb` MCP config entry for Xcode 27 beta-era `xcrun lldb-mcp` investigation while keeping the dedicated debugger workflow planned until startup validation succeeds.

plugins/apple-dev-skills/docs/maintainers/customization-consolidation-review.md

@@ -8,8 +8,8 @@ Record the Milestone 20 audit of the current customization system, decide whethe
 
 ## Current State Summary
 
-- The active skill surface ships `30` separate `references/customization.template.yaml` files.
-- The active skill surface ships `30` separate `scripts/customization_config.py` entrypoints.
+- The active skill surface ships `31` separate `references/customization.template.yaml` files.
+- The active skill surface ships `31` separate `scripts/customization_config.py` entrypoints.
 - Those `customization_config.py` files are functionally identical and exist only because installed skills are expected to keep runtime resources inside the skill directory.
 - The current templates expose `21` knobs total:
   - `20` are documented as `runtime-enforced`

plugins/apple-dev-skills/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "apple-dev-skills-maintainer"
-version = "8.6.0"
+version = "8.7.0"
 description = "Maintainer tooling for the apple-dev-skills repository"
 requires-python = ">=3.10"
 dependencies = []

plugins/apple-dev-skills/shared/agents-snippets/apple-swift-package-core.md

@@ -57,7 +57,8 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 ## Swift Package and Tooling Baseline
 
 - Use Swift Package Manager as the source of truth for package structure and dependencies outside Xcode-managed app workflows.
-- Swift packages that support a SwiftData-backed SwiftUI app must not introduce a repository, store, service, DTO mirror, or view-model cache layer between SwiftData and SwiftUI. Keep reusable package code focused on non-UI boundaries, pure helpers, import/export, migration tooling, sync adapters, or tests while SwiftUI app screens stay directly driven by SwiftData's `ModelContainer`, environment `modelContext`, `@Query`, model objects, and bindings.
+- Choose and record one explicit three-letter uppercase prefix for project-owned Swift files and declarations. Exempt only `Package.swift`, externally generated Swift, and vendored third-party Swift; never use `+` filenames.
+- Use the dedicated SwiftData workflow when a package supports SwiftData persistence or a SwiftData-backed SwiftUI app.
 - Prefer `swift package` subcommands for dependency, target, and manifest-adjacent changes before hand-editing `Package.swift`.
 - Edit `Package.swift` intentionally and keep it readable; agents may modify it when package structure, targets, products, or dependencies need to change, and should try to keep package graph updates consolidated in one change when possible.
 - Keep `Package.swift` explicit about its package-wide Swift language mode. On current Swift 6-era manifests, prefer `swiftLanguageModes: [.v6]` as the default declaration, treat `swiftLanguageVersions` as a legacy alias used only when an older manifest surface requires it, and keep the supported Swift toolchain window focused on the latest stable minor and previous stable minor. Treat Swift `6.2` as the current minimum floor for trait-enabled manifests, not as a ceiling; use newer stable Swift toolchains when available and validated, and refresh this guidance when the maintained floor or window changes. Do not lower `// swift-tools-version:` below `6.2` without an explicit repo policy and a matching guidance update.

plugins/apple-dev-skills/shared/agents-snippets/apple-xcode-project-core.md

@@ -59,13 +59,12 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 ## SwiftUI and State Architecture
 
 - Treat SwiftUI views as component UI: keep them small, composable, reusable, and easy to scan from top to bottom.
-- Use a strict Apple-app MVVM shape for Xcode app projects: views own their own view-local state and actions where feasible, view models stay paired with their owning app or view, persistence and transfer shapes live in `Models/`, and app-wide services live under `Sources/Services/`.
-- Require one SwiftUI `View` component per file, named for that component, with that component's Xcode SwiftUI preview in the same file.
-- Do not group multiple SwiftUI view components into one Swift file, even when the views are small, private, related, nested, or currently used only by one parent.
-- SwiftUI view models are always per-view, with no exceptions: the model for `<ViewFileName>.swift` must live beside the view in `<ViewFileName>+Model.swift` and must not be shared with any other SwiftUI view.
-- Do not create shared SwiftUI view-model files, grouped SwiftUI view-model files, view-cluster models, or unpaired `ViewModel.swift` files. Split shared state into explicit inputs, bindings, environment values, focused values, SwiftData model objects, or a non-SwiftUI boundary when that boundary is genuinely outside the view layer.
-- Put app-wide `@Observable` state beside the app entry point: `WhateverNameApp.swift` owns the single app lifecycle entry, and `WhateverNameApp+ViewModel.swift` owns `@Observable final class WhateverNameAppViewModel`.
-- Put UIKit and AppKit view-controller support beside the matching view under `Sources/Views/` as `<ViewName>+Controller.swift`. Do not create or preserve a root `Controllers/` directory for ordinary app structure.
+- Choose and record one explicit three-letter uppercase prefix for every app or package. Prefix project-owned Swift files and primary declarations; exempt only `Package.swift`, externally generated Swift, and vendored third-party Swift.
+- Never use `+` in project-owned Swift filenames. Concatenate the owner and concern so Xcode navigation, rename, and refactoring keep one consistent grammar.
+- Name views `GEAWhateverView.swift`, paired `@Observable final class` view models `GEAWhateverViewModel.swift`, and extracted modifiers `GEAWhateverViewModifier.swift`.
+- Give independently editable or previewable view components their own files. Small private computed view properties or helper views may remain while they do not clutter focused editing or previews.
+- Prefix extracted child components with their complete composition owner, such as `GEASettingsSheetToggleCard.swift`.
+- Extract a custom `ViewModifier` after more than eight chained modifiers, or earlier when a coherent chain is reusable or obscures the view body.
 - Prefer straight, top-down data flow with state owned at the narrowest view, scene, or app boundary that matches the behavior.
 - Do not build monolithic views, monolithic controllers, or broad shared mutable state when a smaller component boundary would be clearer.
 - Keep updates to view-driving state minimal and localized.
@@ -75,8 +74,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - 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.
-- When SwiftData and SwiftUI are used together, keep them directly coupled in the Apple-designed data-driven UI path: attach the `ModelContainer` at the app or scene boundary, read and mutate through SwiftUI's environment `modelContext`, let `@Query` drive view collections that should stay live with the model context, and pass SwiftData model objects or narrow bindings through the view tree.
-- Do not insert repositories, stores, service layers, mirrored DTO state, view-model cache layers, or other abstraction layers between SwiftData and SwiftUI. Add a separate boundary only for a real non-SwiftUI concern such as import/export, networking, migration tooling, tests, or server sync, and keep SwiftUI screens driven directly by SwiftData.
+- Use the dedicated SwiftData workflow for persistence architecture and its direct SwiftUI integration path.
 - Prefer environment values for shared context that truly belongs to the surrounding hierarchy, not as a dumping ground for unrelated dependencies.
 - Prefer key-path-based APIs, predicates, and sort descriptors when they keep data access direct and readable.
 - Extract repeated chains of view modifiers into custom view modifiers early when that reduces clutter and clearly matches a view or family of views.
@@ -90,10 +88,10 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Keep those top-level roots stable. Do not invent parallel names such as `AppSources`, `TestSources`, `Config`, `BuildScripts`, or `LocalPackages` for ordinary Xcode app repos unless the existing repo already has a deliberate, documented convention.
 - Inside `Sources/`, use this strict app structure by default: `Views/`, `Models/`, and `Services/`. Do not create a root `Controllers/` directory.
 - `Sources/Views/` owns SwiftUI views and UIKit/AppKit view surfaces. Use `Sources/Views/Shared`, `Sources/Views/macOS`, and `Sources/Views/iOS` so shared, macOS-specific, and iOS/iPadOS-specific UI have clear homes.
-- View files are named `<ViewName>.swift`. View-local view models are named `<ViewName>+Model.swift`. UIKit and AppKit controller support files are named `<ViewName>+Controller.swift`. Each paired model or controller file lives beside its matching view in `Sources/Views/` or the appropriate platform/shared subdirectory.
-- `Sources/Models/` owns Core Data persistence models, SwiftData `@Model` types, app datamodels, DTOs, and transfer or persistence shapes that are shared across the app. Service-private request/response shapes may stay inside the owning service folder only when they are not meaningful outside that integration.
+- Use bare prefixed names such as `GEAWhatever.swift` for runtime/domain values. Reserve `GEAWhateverModel.swift` for persistence, and use `GEAWhateverRecord.swift` or `GEAWhateverDTO.swift` only for genuinely additional representations.
+- `Sources/Models/` owns Core Data and SwiftData persistence models plus additional record or transfer representations.
 - `Sources/Services/` owns app-wide and boundary-facing services. Use `Consumed/` for external services the app calls, `Internal/` for services owned only by the app, and `Provided/` for services the app exposes to extensions, helpers, plugins, integrations, or other clients.
-- When an app has a single main app-wide service, put it under `Sources/Services/Internal/` as `WhateverNameAppService.swift`.
+- Name services `GEAWhateverService.swift`; they manage the matching runtime/domain value `GEAWhatever`. `GEAAppService.swift` may manage `GEA`, while `GEAApp.swift` is the lifecycle-entry special case.
 - Use `xcodebuild` for Apple platform integration validation, including scheme, destination or SDK, and configuration-specific build or test runs.
 - Keep `xcodebuild` invocations reproducible in automation by passing explicit schemes, destinations or SDKs, and configurations when relevant.
 - For Codex GUI worktree-first Xcode repos, use a portable `.codex/environments/*.toml` local environment file when the repo wants shared app setup or action buttons. Start from `apple-dev-skills/templates/codex-local-environments/xcode-project.toml`, keep paths repo-relative, and prefer `-derivedDataPath ./DerivedData` or another ignored repo-local build directory instead of user-global DerivedData.