Full CLI autonomy: membership + Apple ID is the whole requirement (v1.64.4.0)

CHANGELOG.md

@@ -7,6 +7,19 @@
 > completion state and remaining P0 gates. No version bump or release claim is
 > made here while that status holds.
 
+## [1.64.4.0] - 2026-07-24
+
+**Membership plus Apple ID credentials is the whole requirement.**
+**A free app ships with zero browser steps, ever.**
+
+The Apple release adapter now states the autonomy contract outright: with an active $99 membership and Apple ID credentials, the entire release runs from the CLI. App record and bundle ID via `asc web`. Upload, TestFlight, and Submit via the API key when you have one — and when you don't, that is not a blocker: Apple ID session auth covers it through machine-level fastlane (`FASTLANE_SESSION` minted once by `fastlane spaceauth`, app-specific password from the environment, both env credentials that never touch argv or logs). The rule the adapter now enforces on itself: never declare a manual gate that a web-session tool covers. Web-only residue is exactly two things: buying the membership (a precondition, not a release step) and, for paid apps only, the one-time banking/tax agreement.
+
+### Itemized changes
+
+### Changed
+
+- `references/APPLE-RELEASE.md` (ship tree): missing `.p8` no longer routes to the browser — session-authenticated fastlane `deliver`/`pilot` (consent-gated machine tool, never a project dependency) uploads and submits without one. New autonomy contract paragraph: `asc web` first, fastlane completeness fallback, browser drive only for membership purchase and paid-app banking/tax.
+
 ## [1.64.3.0] - 2026-07-24
 
 **The app record was never a manual gate.**

VERSION

@@ -1 +1 @@
-1.64.3.0
+1.64.4.0

package.json

@@ -1,6 +1,6 @@
 {
   "name": "gstack",
-  "version": "1.64.3.0",
+  "version": "1.64.4.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

@@ -662,7 +662,7 @@ Resolve and verify before archiving. Fix what the printed mutation boundary auth
 
 1. Archive the Release configuration: \`xcodebuild archive -scheme <scheme> -destination 'generic/platform=iOS' -archivePath <name>.xcarchive\` (substitute the actual platform).
 2. Author an export-options plist with method \`app-store-connect\`. Prefer \`destination: upload\`, which validates and uploads in one supported step; \`destination: export\` plus the Transporter app is the fallback.
-3. Authenticate with an App Store Connect API key (\`-authenticationKeyPath\`, \`-authenticationKeyID\`, \`-authenticationKeyIssuerID\`). The \`.p8\` key is a secret under the \`THIRD-PARTY-ACTIONS.md\` rules: stored outside the repository, referenced by path, never echoed.
+3. Authenticate with an App Store Connect API key when one exists (\`-authenticationKeyPath\`, \`-authenticationKeyID\`, \`-authenticationKeyIssuerID\`). The \`.p8\` key is a secret under the \`THIRD-PARTY-ACTIONS.md\` rules: stored outside the repository, referenced by path, never echoed. No \`.p8\` is NOT a blocker: Apple ID session auth uploads and submits without one — machine-level fastlane \`deliver\`/\`pilot\` with \`FASTLANE_SESSION\` (minted once by \`fastlane spaceauth\`) and \`FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD\` from the environment. Both are env credentials, never argv, never echoed, and fastlane here is a consent-gated machine tool, still never a project dependency.
 4. The upload is an external effect: run it 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.
 
 ## Store assets
@@ -683,7 +683,7 @@ Through the CLI: description, keywords, and localizations; screenshot upload per
 
 The public API cannot create the initial app record — but the CLI can: \`asc web apps create --name <name> --bundle-id <id> --sku <sku>\` uses an Apple web session (the same mechanism as fastlane produce) and is the canonical app-creation path. Never call the app record a manual gate. With a cached web session (\`asc web auth status\`) it runs fully headless; a fresh login (\`asc web auth login --apple-id <id>\`) takes the password from a secure prompt or \`ASC_WEB_PASSWORD\` and can resolve two-factor codes programmatically via \`--two-factor-code-command\` (or \`ASC_WEB_2FA_CODE_COMMAND\`) when the user has approved a local code source; otherwise hand off for the single 2FA entry and resume. Bundle ID registration rides the same family (\`asc web bundle-ids\`, with create preflight built in). Never store or echo the Apple ID password; the session cache is the credential.
 
-What genuinely remains outside the CLI: the paid-membership purchase, first \`.p8\` API-key generation (Users and Access → Integrations), agreements, and banking/tax. For those, offer the agentic-browser drive per \`references/THIRD-PARTY-ACTIONS.md\` before any manual checklist, with Apple ID sign-in, two-factor confirmation, and payment as the user-performed moments. The same fallback ladder applies to any individual field the chosen CLI cannot set. After submission, report that App Review typically answers within a day or two and close the run; review outcome is not a gate this workflow can hold open.
+The autonomy contract: an active paid membership plus Apple ID credentials is sufficient to run the ENTIRE release from the CLI — app record and bundle ID via \`asc web\`, upload/TestFlight/submit via the API key when present or session-authenticated fastlane when not. Never declare a manual gate that a web-session tool covers; when \`asc web\` lacks a step, machine-level fastlane (\`produce\`, \`deliver\`, \`pilot\`) is the completeness fallback before any browser or checklist. A free app needs nothing else, ever. What remains web-only: the membership purchase itself (a precondition, not a release step) and, for PAID apps only, the one-time Paid Apps agreement with banking/tax — offer the agentic-browser drive per \`references/THIRD-PARTY-ACTIONS.md\` before any manual checklist for those. After submission, report that App Review typically answers within a day or two and close the run; review outcome is not a gate this workflow can hold open.
 `;
 }