diff --git a/CHANGELOG.md b/CHANGELOG.md index 3459cb2c07..4a39b4ebd1 100644 --- a/CHANGELOG.md +++ b/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.3.0] - 2026-07-24 + +**The app record was never a manual gate.** +**One CLI command creates it, session-cached, headless.** + +Apple's public API refuses to create app records, and every release guide treats that as the moment you open a browser. The Apple release adapter now uses `asc web apps create` instead: an Apple web-session flow (the same mechanism fastlane produce has used for a decade) that creates the app record from the terminal with name, bundle ID, and SKU. With a cached session it is fully headless. A fresh login can even resolve two-factor codes programmatically via `--two-factor-code-command` when you point it at a local code source, so an autonomous agent can run the entire release without a browser. What still is not CLI: the membership purchase, first API-key download, agreements, and banking/tax — those keep the consent-gated browser drive from v1.64.2.0. + +### Itemized changes + +### Changed + +- `references/APPLE-RELEASE.md` (ship tree): app-record creation and bundle ID registration move from web residue to the CLI path (`asc web apps create`, `asc web bundle-ids`), with cached-session headless operation, programmatic 2FA resolution when the user approves a local code source, and no password storage or echo. Web residue shrinks to membership purchase, first `.p8` generation, agreements, banking/tax. + ## [1.64.2.0] - 2026-07-23 **The App Store "manual gate" mostly isn't.** diff --git a/VERSION b/VERSION index a85fd64b76..7bb30f551e 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -1.64.2.0 +1.64.3.0 diff --git a/package.json b/package.json index 985d5d0719..74aee2d265 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "gstack", - "version": "1.64.2.0", + "version": "1.64.3.0", "description": "GStack 2 \u2014 six portable Agent Skills with an optional host-neutral runtime.", "license": "MIT", "type": "module", diff --git a/scripts/gstack2/generate-skill-tree.ts b/scripts/gstack2/generate-skill-tree.ts index 7f468a561f..a606363424 100644 --- a/scripts/gstack2/generate-skill-tree.ts +++ b/scripts/gstack2/generate-skill-tree.ts @@ -681,7 +681,9 @@ The App Store Connect API covers nearly all remaining work; drive it from a CLI, Through the CLI: description, keywords, and localizations; screenshot upload per required device size; TestFlight groups and testers as an intermediate distribution before review; attaching the uploaded build to the version; Submit for Review; and review-status monitoring afterward. Submission is an external effect like the upload: run it through the durable state wrapper with a key like \`appstore.submit..\`. -The API cannot create the initial app record (name, bundle ID, SKU, primary language), generate the first API key, accept agreements, or configure banking and tax; those live on the App Store Connect website — but they are form fields, not judgment, so never present them as a manual gate without first offering the agentic-browser drive per \`references/THIRD-PARTY-ACTIONS.md\`. With consent, drive the app-record form and the Users and Access → Integrations key generation directly on the user's logged-in session, saving the downloaded \`.p8\` to a user-approved path outside the repository. The only steps that are genuinely the user's are Apple ID sign-in, two-factor confirmation, and payment; hand off for those moments and resume. A manual checklist is the fallback when no agentic browser is available or the user declines. The same 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 public API cannot create the initial app record — but the CLI can: \`asc web apps create --name --bundle-id --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 \`) 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. `; } diff --git a/skills/ship/references/APPLE-RELEASE.md b/skills/ship/references/APPLE-RELEASE.md index 4e5f912fda..dbffcf97bc 100644 --- a/skills/ship/references/APPLE-RELEASE.md +++ b/skills/ship/references/APPLE-RELEASE.md @@ -44,4 +44,6 @@ The App Store Connect API covers nearly all remaining work; drive it from a CLI, Through the CLI: description, keywords, and localizations; screenshot upload per required device size; TestFlight groups and testers as an intermediate distribution before review; attaching the uploaded build to the version; Submit for Review; and review-status monitoring afterward. Submission is an external effect like the upload: run it through the durable state wrapper with a key like `appstore.submit..`. -The API cannot create the initial app record (name, bundle ID, SKU, primary language), generate the first API key, accept agreements, or configure banking and tax; those live on the App Store Connect website — but they are form fields, not judgment, so never present them as a manual gate without first offering the agentic-browser drive per `references/THIRD-PARTY-ACTIONS.md`. With consent, drive the app-record form and the Users and Access → Integrations key generation directly on the user's logged-in session, saving the downloaded `.p8` to a user-approved path outside the repository. The only steps that are genuinely the user's are Apple ID sign-in, two-factor confirmation, and payment; hand off for those moments and resume. A manual checklist is the fallback when no agentic browser is available or the user declines. The same 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 public API cannot create the initial app record — but the CLI can: `asc web apps create --name --bundle-id --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 `) 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.