jjbrunton/Sauci
1
0 Fork 0
mirror of https://github.com/jjbrunton/Sauci.git synced 2026-10-31 10:19:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(release): authorize scoped store uploads

Browse Source
This commit is contained in:
jjbrunton committed 2026-08-31 10:08:03 +01:00
1 parent 3fc6f8aa1a
commit 8bf93f372b
3 files changed
+48 -46
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.codex/skills/release-mobile/SKILL.md
+16 -19
View File
@@ -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