docs(release): authorize scoped store uploads

.codex/skills/generate-release/SKILL.md

@@ -13,9 +13,13 @@ drafting notes and [references/artifact-verification.md](references/artifact-ver
 before accepting a build.
 
 A request to generate or create a release authorizes the scoped version edits,
-release notes, local builds, release commits, and one local annotated tag. It
-does not authorize pushing commits or tags, uploading binaries, submitting a
-store release, changing signing credentials, or regenerating native projects.
+release notes, local builds, release commits, and one local annotated tag. When
+the request also specifies a mobile release, upload, or store-submission
+workflow, it authorizes the requested store upload within its stated platform
+and destination scope after the exact artifact has been verified. It does not
+authorize pushing commits or tags, changing signing credentials, regenerating
+native projects, a public rollout, App Review submission, or additional
+TestFlight distribution unless the request explicitly includes that action.
 
 ## Defaults
 

.codex/skills/release-mobile/SKILL.md

@@ -18,13 +18,13 @@ so routine release builds must package those checked-in sources. Do not run
 `expo prebuild` first; native regeneration is a separate reviewed change.
 
 Use the package scripts in `apps/mobile/package.json`; they create artifacts only.
-Never infer upload or submission authority from build authorization. Store upload
-uses a separately authorized command.
+An explicit request for a mobile release, upload, or store-submission workflow
+authorizes the requested store upload within its stated platform and destination
+scope. Building an artifact alone does not authorize an upload.
 
-## Upload authorization gate
+## Upload execution
 
-After an artifact passes verification, stop immediately before the external
-upload and ask the user for confirmation. The request must identify:
+Before an external upload, independently verify and report:
 
 - the platform, exact artifact path, bundle/package identifier, public version,
   build number, signature identity, and SHA-256 digest;
@@ -33,24 +33,21 @@ upload and ask the user for confirmation. The request must identify:
 - that the upload does not authorize a public rollout or App Review submission.
 
 For iOS, inspect the current App Store Connect automatic-distribution behavior
-before asking. If the build would be distributed automatically, name the exact
-TestFlight groups or testers in the request and include that effect in the fresh
-authorization. If the effect cannot be established, stop; changing an automatic-
-distribution setting also requires separate authorization.
+before uploading. If the build would be distributed automatically, report the
+exact TestFlight groups or testers. If the effect cannot be established, stop;
+changing an automatic-distribution setting is a separately authorized action.
 
-Even when the original request includes building, releasing, uploading, or
-submitting, require this fresh confirmation once the exact verified artifact and
-destination are known. End the request with: `Upload this verified artifact to
-<destination> now?` A clear affirmative response authorizes one upload of that
-artifact to that destination, plus only any automatic TestFlight distribution
-explicitly disclosed in the request. Run `eas submit` with the explicit
+Once these details match the user's stated scope, upload without requesting a
+second confirmation. Run `eas submit` with the explicit
 `--platform`, `--profile production`, `--path`, and `--wait` arguments; never
 select `--latest`. If the result is ambiguous, inspect EAS and the store before
-doing anything else, do not retry, and ask again before another upload.
+doing anything else; do not retry unless the user explicitly authorizes another
+upload.
 
-Apply this gate to every upload method, including EAS, Fastlane, Xcode Organizer,
-and the store consoles. A later public rollout, App Review submission, or
-additional TestFlight distribution requires another fresh authorization.
+Apply this policy to every upload method, including EAS, Fastlane, Xcode
+Organizer, and the store consoles. A public rollout, App Review submission, or
+additional TestFlight distribution requires separate explicit authorization
+unless it was expressly included in the original request.
 
 Preserve platform signing and local EAS versioning. After a build, verify that
 tracked changes are limited to the expected version metadata, then independently