plugin: address provisioning workflow review

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

@@ -69,6 +69,7 @@ sync_one \
   "$ROOT_DIR/skills/devicecheck-app-attest-workflow/references/snippets/apple-xcode-project-core.md" \
   "$ROOT_DIR/skills/apple-developer-provisioning-workflow/references/snippets/apple-xcode-project-core.md" \
   "$ROOT_DIR/skills/swiftui-app-architecture-workflow/references/snippets/apple-xcode-project-core.md" \
+  "$ROOT_DIR/skills/swiftdata-workflow/references/snippets/apple-xcode-project-core.md" \
   "$ROOT_DIR/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md" \
   "$ROOT_DIR/skills/sync-xcode-project-guidance/references/snippets/apple-xcode-project-core.md" \
   "$ROOT_DIR/skills/xcode-coding-intelligence-workflow/references/snippets/apple-xcode-project-core.md"

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

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/appkit-app-architecture-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/apple-developer-provisioning-workflow/references/app-store-connect-provisioning.md

@@ -12,7 +12,7 @@ For provisioning REST endpoints, use a **team API key**, not an individual key.
 
 Do not use this App Store Connect key path for Apple Developer Enterprise Program accounts: Apple directs those accounts to the separate Enterprise Program API, and team API keys are unavailable in that program. For portal-only identifier work, Apple documents Account Holder or Admin as the required role for [App ID registration](https://developer.apple.com/help/account/identifiers/register-an-app-id/) and [App Group registration](https://developer.apple.com/help/account/identifiers/register-an-app-group/). Individual enrolments can grant App Store Connect access to additional people, but those people are not Apple Developer Program team members and do not gain Certificates, Identifiers & Profiles access.
 
-Store the one-time-downloaded `.p8` private key locally, along with its key ID and issuer ID. Generate the JWT in memory for the current invocation; it is authorization material, not a project configuration value. Apple advises revocation if a private key is lost or compromised.
+Store the one-time-downloaded `.p8` private key only in Keychain or another approved local secret manager, along with its key ID and issuer ID. Never place the private key or a JWT in project files, logs, shell history, agent transcripts, or client-side code. Generate the JWT in memory for the current invocation and do not persist it; it is authorization material, not a project configuration value. Apple advises revocation if a private key is lost or compromised.
 
 Individual enrollment has an additional constraint: people added in App Store Connect receive App Store Connect access but are not members of the Apple Developer Program team, so they do not receive Certificates, Identifiers & Profiles access. See Apple’s [roles reference](https://developer.apple.com/help/account/access/roles/).
 

plugins/apple-dev-skills/skills/apple-developer-provisioning-workflow/references/customization-flow.md

@@ -2,4 +2,4 @@
 
 The template records non-security preferences only. `preferredDiscoveryMode` may be `xcode-local` or `rest-first`; `preferredCloudKitAdapter` may be `cktool` or `cktool-js`.
 
-Preferences do not authorize mutation, relax secret handling, convert a portal-only operation into API work, or suppress operation-specific confirmation. Store a durable customization file outside the repository through `scripts/customization_config.py`.
+Preferences do not authorize mutation, relax secret handling, convert a portal-only operation into API work, or suppress operation-specific confirmation. Store a durable customization file outside the repository through `scripts/customization_config.py`. Use `effective` to inspect it, `apply --input <yaml-file>` to persist a validated override, and `reset` to remove it.

plugins/apple-dev-skills/skills/apple-developer-provisioning-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/apple-developer-provisioning-workflow/scripts/customization_config.py

@@ -48,6 +48,10 @@ def load(path: Path, *, required: bool) -> dict:
     settings = value.get("settings") or {}
     if not isinstance(settings, dict) or set(settings) - ALLOWED_SETTINGS:
         fail(f"settings in {path} must contain only {sorted(ALLOWED_SETTINGS)}")
+    if "schemaVersion" in value and value["schemaVersion"] != 1:
+        fail(f"schemaVersion in {path} must be 1")
+    if "isCustomized" in value and not isinstance(value["isCustomized"], bool):
+        fail(f"isCustomized in {path} must be boolean")
     return value
 
 
@@ -76,11 +80,30 @@ def write(config: dict) -> None:
     path.write_text(yaml.safe_dump(config, sort_keys=False), encoding="utf-8")
 
 
+def apply(override_path: Path) -> None:
+    override = load(override_path, required=True)
+    config = effective()
+    config["settings"].update(override.get("settings") or {})
+    config["isCustomized"] = True
+    write(config)
+    print(durable_path())
+
+
+def reset() -> None:
+    path = durable_path()
+    if path.exists():
+        path.unlink()
+    print(path)
+
+
 def main() -> None:
     parser = argparse.ArgumentParser(description="Inspect or persist safe workflow preferences.")
     commands = parser.add_subparsers(dest="command", required=True)
     commands.add_parser("path")
     commands.add_parser("effective")
+    apply_command = commands.add_parser("apply")
+    apply_command.add_argument("--input", required=True, type=Path)
+    commands.add_parser("reset")
     set_command = commands.add_parser("set")
     set_command.add_argument("--discovery-mode", choices=["xcode-local", "rest-first"])
     set_command.add_argument("--cloudkit-adapter", choices=["cktool", "cktool-js"])
@@ -90,6 +113,10 @@ def main() -> None:
         print(durable_path())
     elif args.command == "effective":
         print(yaml.safe_dump(effective(), sort_keys=False), end="")
+    elif args.command == "apply":
+        apply(args.input)
+    elif args.command == "reset":
+        reset()
     else:
         config = effective()
         if args.discovery_mode:

plugins/apple-dev-skills/skills/apple-typography-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/apple-ui-accessibility-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/avaudio-engine-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/avfaudio-session-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.

plugins/apple-dev-skills/skills/avfoundation-media-pipeline-workflow/references/snippets/apple-xcode-project-core.md

@@ -47,7 +47,7 @@ Use this snippet in repository `AGENTS.md` files when you want baseline standard
 - Use XCUITest for UI automation, and prefer explicit element wait APIs such as `waitForExistence(timeout:)`, `waitForNonExistence(timeout:)`, and related state waits over fixed sleeps.
 - Keep `.xctestplan` files versioned when test configurations, diagnostics, sanitizers, locale coverage, or selective plan execution matter, and inspect or run them explicitly with `xcodebuild -showTestPlans` and `xcodebuild -testPlan ...`.
 - Prefer normal Xcode and XCTest parallel execution for ordinary Swift Testing, XCTest, and XCUITest runs when the project, scheme, destination, and test plan support it. Do not serialize regular tests just because they use Swift, XCTest, async tests, UI automation, or `.xctestplan` matrices.
-- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time, and call `unload_models` on Gale's live TTS service before the heavy run and `reload_models` after it ends, even when the run fails or is interrupted.
+- Treat tests that load large local AI or ML models, especially models over 500 million parameters, as heavy system-resource tests. Run those tests sequentially, one at a time.
 - Prefer first-party and top-tier Swift ecosystem packages from Apple, `swiftlang`, the Swift Server Work Group, and similarly trusted core Swift projects when they simplify the code and make it easier to reason about.
 - Commonly approved examples include `swift-configuration` and `swift-async-algorithms` when they reduce bespoke code and improve readability.
 - For Apple app projects, prefer Apple-native logging facilities first and allow Swift Logging where it makes the project API clearer.