Auth failures: re-sign-in before any password fallback (v1.64.15.0)

CHANGELOG.md

@@ -7,6 +7,18 @@
 > completion state and remaining P0 gates. No version bump or release claim is
 > made here while that status holds.
 
+## [1.64.15.0] - 2026-07-24
+
+**A bad credential means "sign in again," not "go generate a password."**
+
+Upload auth failures now escalate in the obvious order: quote the real error, re-run the same in-session sign-in from the authorization moment (expired sessions are the common case), retry with the fresh session, and only if a fresh session still fails does the self-service app-specific-password fallback open.
+
+### Itemized changes
+
+### Changed
+
+- `references/APPLE-RELEASE.md` (ship tree): auth-failure escalation ladder — verbatim error, re-sign-in + retry first, app-specific password only after a fresh session fails.
+
 ## [1.64.14.0] - 2026-07-24
 
 **Credentials are never created by a browser drive. Restored, permanently.**

VERSION

@@ -1 +1 @@
-1.64.14.0
+1.64.15.0

package.json

@@ -1,6 +1,6 @@
 {
   "name": "gstack",
-  "version": "1.64.14.0",
+  "version": "1.64.15.0",
   "description": "GStack 2 \u2014 six portable Agent Skills with an optional host-neutral runtime.",
   "license": "MIT",
   "type": "module",

scripts/gstack2/generate-skill-tree.ts

@@ -674,7 +674,7 @@ Build this question's options from a LIVE check of installed skills at ask time
 1. Archive and export the signed Release build with \`gym\` (it drives xcodebuild and the signing minted in preflight). Projects with custom archive requirements may drop to \`xcodebuild archive\` directly; the output either way is an App Store-signed \`.ipa\`.
 2. The upload is an external effect: run \`pilot\` (TestFlight) or \`deliver\` (App Store) through the durable state wrapper with a key like \`appstore.upload.<bundle-id>.<build>\`. Never re-upload on ambiguity; inspect App Store Connect for the build first.
 3. The cached session is an env-level credential: never argv, never echoed, never committed.
-4. NEVER demand an app-specific password. Per fastlane's documented authentication, the cached spaceauth session ALONE suffices for binary upload through \`deliver\`/\`pilot\`; \`FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD\` is an alternative for environments without a session, not a requirement on top of one. Attempt the session upload FIRST; only an actual authentication error from a real upload attempt may open a fallback conversation, and "Apple requires an app-specific password on 2FA accounts" stated without that error in hand is a contract violation. When a real error does force the fallback, QUOTE the error verbatim, and the only offered path is self-service: the user generates the password on any device and enters it through the host's in-session masked prompt into the macOS keychain (\`fastlane fastlane-credentials add --username <apple-id>\`), then the upload is retried. NEVER offer or recommend a browser drive to create credentials — no Aside, no agentic browser, for any password, key, or token, under any framing.
+4. NEVER demand an app-specific password. Per fastlane's documented authentication, the cached spaceauth session ALONE suffices for binary upload through \`deliver\`/\`pilot\`; \`FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD\` is an alternative for environments without a session, not a requirement on top of one. Attempt the session upload FIRST; only an actual authentication error from a real upload attempt may open a fallback conversation, and "Apple requires an app-specific password on 2FA accounts" stated without that error in hand is a contract violation. When a real error does force the fallback, QUOTE the error verbatim, then escalate in this order: FIRST treat it as an expired or invalid session — ask the user to sign in again (the same \`! fastlane spaceauth -u <apple-id>\` moment as the original authorization) and retry the upload with the fresh session. Only if a FRESH session still fails the same way does the app-specific-password path open, and its only shape is self-service: the user generates the password on any device and enters it through the host's in-session masked prompt into the macOS keychain (\`fastlane fastlane-credentials add --username <apple-id>\`), then the upload is retried. NEVER offer or recommend a browser drive to create credentials — no Aside, no agentic browser, for any password, key, or token, under any framing.
 5. App Review contact details (name, email, phone) are required metadata for submission: infer name and email from the signed-in Apple ID and git config, collect the phone number once inside the authorization moment, persist it to the decision store, and never re-ask. Contact details are metadata, not a blocking gate to announce mid-run.
 
 ## Storefront completion