gowalk-cicd 1.0.167 → 1.0.169

package/README.md

@@ -1,13 +1,13 @@
 # gowalk-cicd
 
-One installer for iOS TestFlight, Android Google Play, and Flutter web release
-artifacts. It supports native Swift/SwiftUI iOS projects, native Kotlin/Gradle
+One installer for iOS TestFlight and Android Google Play delivery, plus the
+optional backend deploy. It supports native Swift/SwiftUI iOS projects, native Kotlin/Gradle
 Android projects, and Flutter apps. Provision encrypted repository secrets, validate a
 task candidate, and promote its release intent. Store builds and uploads run only in GitHub Actions.
 
 App-specific workflow settings live in `.gowalk-cicd.yml`. The installer migrates supported
 existing settings once and regenerates managed workflows without replacing custom behavior.
-See [configuration and parallel organization upgrades](docs/CONFIGURATION.md).
+See [configuration](docs/CONFIGURATION.md).
 
 ## Install
 
@@ -23,12 +23,18 @@ Writes three core things into your repo:
 - `.github/actions/android-app/` — Android build/sign action (Flutter or Gradle)
 - `.github/workflows/deploy.yml` — workflow that builds and deploys both platforms
 
-Flutter projects that contain `web/index.html` also get
-`.github/workflows/deploy-web.yml`. It creates a version-stamped release build
-and retains `build/web` as a 30-day workflow artifact. Native-only repositories
-are unaffected.
+The installer no longer adds `.github/workflows/deploy-web.yml`. On re-adoption it
+removes a `deploy-web.yml` that is still byte-for-byte the generated file and has no
+overrides in `.gowalk-cicd.yml`; a customized one keeps upgrading (see
+[Flutter web release](#flutter-web-release)).
 
-Re-run the same command anytime to pull the latest version.
+Re-run the same command anytime to pull the latest version. The vendored action
+directories then mirror the package: a file the package no longer ships is deleted,
+except the `.daemux-version` markers and any file a workflow under
+`.github/workflows/` still names by path (the installer prints what it kept and
+removed; `--dry-run` deletes nothing). Tests and fixtures are not shipped. A
+workflow the package does not manage that fails to parse is skipped with
+`[warn] skipped .github/workflows/<file>: <code>` instead of aborting the install.
 
 Ready task PRs build shipping binaries alongside validation; the protected merge promotes matching
 binaries through the existing store upload paths. See [candidate artifact reuse](docs/CANDIDATE_ARTIFACTS.md)
@@ -92,6 +98,11 @@ job. This bounds individual cache segments, not the total cache or SDK download,
 and keeps existing cache keys. A successfully installed SDK is saved before app
 checks run, so a later test/build failure does not force another cold SDK download.
 Failed setup never saves an SDK cache; pub dependencies retain their job-end save.
+Pull-request runs (`refs/pull/*`, which includes every candidate build) restore these caches
+but never save them; task branches and the default branch still save. When the caller names
+no Flutter version, a committed `.flutter-version` (`x.y.z`, a regular file of at most 64 bytes)
+pins the SDK; a symlink or malformed pin fails with `Invalid project Flutter pin`, and no file
+keeps the channel's latest release.
 
 Native dependency preparation uses a committed `Gemfile` and `Gemfile.lock` beside
 the selected iOS project, falling back to the repository root. It installs missing
@@ -109,9 +120,16 @@ Pods and verifies the selected workspace before release configuration. Preserve
 order in customized validation and deployment workflows; updating action directories
 alone cannot repair a configuration step that runs before the action.
 
+The iOS action then skips `bundle install` and `pod install` when the Pods are already in
+sync: `Pods/Manifest.lock` equals `Podfile.lock`, the lock's `PODFILE CHECKSUM` matches the
+Podfile, every local `:path:` pod exists, a workspace exists and xcodegen did not just
+generate the project. Its receipt then reports `pods: in_sync`, and its own native Pods
+cache is not restored or saved for that run.
+
 ## Flutter web release
 
-The conditional `deploy-web.yml` workflow runs on changes to Flutter source,
+A repository whose `.gowalk-cicd.yml` customizes `deploy-web.yml` keeps it.
+That workflow runs on changes to Flutter source,
 web assets, package metadata, localization config, or the workflow itself. It
 also supports manual dispatch. The build uses `GITHUB_RUN_NUMBER` as its build
 number and uploads the complete `build/web` directory as a release artifact.
@@ -165,10 +183,6 @@ in App Store Connect; see [First-time app setup](#first-time-app-setup).
 
 ## Backend deploy (Python + Postgres, Docker)
 
-New ordinary Compose projects receive small isolated networks inside Docker's verified existing pools.
-Existing/custom/external networks and authored IPAM retain their contracts. Read-only
-`network-diagnostics` uses the same deployment identity; see [capacity and diagnosis](docs/BACKEND_NETWORKS.md).
-
 When a repo carries a Dockerized backend, the installer also vendors a backend deploy path:
 `.github/actions/backend-app/` and `.github/workflows/deploy-backend.yml`. A
 mobile-only repo is unaffected (the backend path is not installed).
@@ -211,13 +225,31 @@ wires an nginx vhost + Let's Encrypt cert for the API domain, and health-checks.
 Hosts with several existing Let's Encrypt accounts select one deterministically,
 and a domain deploy fails unless its public HTTPS certificate and health route validate.
 Changing a container's published port preserves its existing HTTPS configuration; nginx must accept
-the change, or the previous vhost is restored and the deploy fails. An existing certificate is
-installed for the requested domain on redeploy, repairing older HTTP-only vhosts too.
-A redeploy whose vhost already holds that certificate behind Certbot's redirect, whose certificate and
-key form a pair, whose running nginx presents it for the domain, and whose name no other server block in
-nginx's loaded configuration declares, skips the install, which would otherwise save a checkpoint copy of
-every nginx file on the host. It still tests and reloads nginx as the install did, and fails the deploy
-when nginx refuses either.
+the change, or the previous vhost is restored and the deploy fails.
+When the domain's vhost has exactly one `ssl_certificate`, and that file exists, stays valid for more
+than a day and lists `DNS:<domain>` in its subjectAltName, the deploy runs no Certbot, only follows the
+published port, and logs `certificate state=current`. Otherwise the name is issued by webroot: the vhost
+serves `/.well-known/acme-challenge/` from `/var/lib/gowalk-acme` on port 80 (and proxies the API there
+until HTTPS exists); the deploy waits up to 20 s for this host's nginx to serve a probe file under the
+domain's name; `certbot certonly --webroot --cert-name <domain> --keep-until-expiring` issues it (a lineage
+of that name that is not due is kept); then the vhost is rendered with HTTPS: port 80 answers challenges
+and redirects, port 443 proxies with `/etc/letsencrypt/live/<domain>/`. Certbot saves the webroot and a
+deploy hook that reloads nginx under the host nginx lock, so the host's renew timer renews the lineage.
+Vhosts that older releases configured with `certbot --nginx` keep their TLS directives; only their
+upstream port changes. Every Certbot call runs under `flock -w 900 /run/gowalk-certbot.lock`, so deploys
+on one host take turns; when the host's renew timer holds Certbot's own lock, the call retries every
+10 s for up to 10 minutes. Vhost writes with their nginx test and reload, and the host port reservation,
+run under the host nginx lock `/run/app-robot-nginx.lock` (`flock -w 120`), which the panel's domain
+applier also takes. New Compose networks come from Docker's own address pools; the deploy hosts'
+`default-address-pools` hand out `/24`s. After a healthy deploy the replaced build's images are pruned
+(`docker image prune -f --filter label=com.docker.compose.project=<app>`); a refusal because another
+prune is running defers it to the next deploy.
+
+Each app gets one stable loopback port, reserved once in the host's `.env` as
+`BACKEND_HTTP_PORT` (starting at `20000 + cksum(app) % 10000`, skipping ports other apps reserved or
+already bound). A Compose file opts in by publishing `127.0.0.1:${BACKEND_HTTP_PORT:-}:<container-port>`;
+a redeploy then leaves the nginx upstream unchanged. A literal `127.0.0.1:<port>:<container-port>`
+keeps working as before.
 
 Requirements on the consumer repo:
 
@@ -228,6 +260,11 @@ Requirements on the consumer repo:
   never bake secrets in. A generated `.env` (with `POSTGRES_PASSWORD`) is created
   on the host on first deploy and preserved across deploys (rsync excludes it).
 - Repo **secret** `BACKEND_DEPLOY_SSH_KEY` (a private key with access to the host).
+- Repo **variable** `BACKEND_DEPLOY_KNOWN_HOSTS` (recommended): `known_hosts` lines for the exact
+  host string the workflow connects to (`BACKEND_DEPLOY_HOST`, for example
+  `138.197.36.107 ssh-ed25519 AAAA...`). Deploys then require that key
+  (`StrictHostKeyChecking=yes`). While it is empty the job trusts `ssh-keyscan` and prints one
+  `backend_host_key_unpinned` warning.
 - Repo **secret** `BACKEND_RUNTIME_ENV` (optional): newline-delimited `KEY=value`
   runtime secrets. The action writes it as mode 0600 on the host and passes it
   to Compose without copying values into the repository or action log.
@@ -238,10 +275,15 @@ Requirements on the consumer repo:
   Malformed or ambiguous multiline structures refuse before deployment. Transport is bounded
   to 1 MiB of UTF-8 input and 512 KiB per value, uses private SSH stdin, and atomically replaces
   `.runtime.env`; application sync preserves the last installed file if validation fails.
-- Repo **variables** (optional): `BACKEND_API_DOMAIN` (its DNS A record must point
-  at the host for the cert; empty = deploy the container only, skip nginx/cert),
-  `BACKEND_APP_NAME` (defaults to the repo name), `BACKEND_HEALTH_PATH`
-  (default `/health`), `BACKEND_DEPLOY_HOST` (default `138.197.36.107`).
+- Repo **variable** `BACKEND_API_DOMAIN`: the bound API host name (for example
+  `api.<app-domain>`); its DNS A record must point at the host for the cert.
+  **Backend Deploy runs only when it is set**: a repository with no bound backend
+  origin holds no deploy key, so `deploy-backend.yml` is skipped and the feature-branch
+  `backend-preview` deploy ends with a `backend_origin_unbound` notice.
+- Repo **variables** (optional): `BACKEND_APP_NAME` (defaults to the repo name),
+  `BACKEND_HEALTH_PATH` (default `/health`), `BACKEND_DEPLOY_HOST` (default
+  `138.197.36.107`). The action refuses an `api-domain` that is not a lowercase DNS
+  name, a `health-path` outside `/[A-Za-z0-9_./-]*` and a malformed `cert-email`.
 
 The action directory is canonical here (like the iOS/Android actions): edit it in
 `backend-action/`, never in a consumer's vendored copy.
@@ -354,7 +396,17 @@ rather than a failure, so it reads as a flake rather than an out-of-memory.
 
 Before building, the Android job caps `-Xmx` at 4 GB and `MaxMetaspaceSize` at
 2 GB in the checkout, with a `::warning::` naming the original value. Projects
-already at or below those numbers are left untouched. Linux only.
+already at or below those numbers are left untouched. A runner with at least
+16 GiB of `MemTotal` (for example an 8-core `ANDROID_RUNNER`) keeps the app's own
+settings. Linux only.
+
+### Android runner size
+
+The Android job runs on `${{ vars.ANDROID_RUNNER || 'ubuntu-24.04' }}`. Set the
+repository or organization variable `ANDROID_RUNNER` to a larger hosted runner
+label to shorten the release build; unset it before deleting that runner. The
+variable is not a build input: setting, changing or removing it never discards a
+candidate binary.
 
 ### When Play will not accept a release for review
 
@@ -428,12 +480,11 @@ the situation and whose **message** is one line of JSON carrying a versioned
 | `source_maintenance_pending` | `gowalk-cicd/source-maintenance-pending.v1` | `repo`, `base_sha`, `head_sha`, `branch`, `run_id` |
 | `apple_build_upload_failed` (error) | `gowalk-cicd/apple-build-upload-failed.v2` | `category`, `stage`, `receipt_available`, receipt identifiers (`cfBundleVersion`, `upload_id`, `file_id`, `state`, `provider_status`, `provider_code`, `provider_pointer`), `action` |
 | `flutter_download_failed` (error) | `gowalk-cicd/flutter-download-failed.v1` | `phase`, `curl_exit`, `http_status`, `proxy_status`, `attempts`, `retained_bytes` |
-| `android_build_failed` (error) | `gowalk-cicd/android-build-failed.v1` | `phase`, `exit_code`, `signals` (fixed observed patterns; empty means unclassified) |
+| `android_build_failed` (error) | `gowalk-cicd/android-build-failed.v1` | `phase`, `exit_code`, `signals` (fixed observed patterns; empty means unclassified), optional `hosts`, `artifacts` and `excerpt` (error lines plus the next line, URL userinfo removed, at most 4 KB) |
 
-Android release compilers retain only a bounded private output window. Their failure signals
-describe observed error patterns, not retry permission or a unique root cause. Silent builds
-emit `android_build_progress` notices (`gowalk-cicd/android-build-progress.v1`) every minute
-with `phase` and `elapsed_seconds`; successful compiler output is not republished.
+Android release compilers stream their output to the job log inside `::stop-commands::` markers,
+so no build line can act as a workflow command. Their failure signals describe observed error
+patterns, not retry permission or a unique root cause.
 
 Native bundle and Pods failures emit `native_prepare_failed` with schema
 `gowalk-cicd/native-prepare-failed.v1`, `phase`, a fixed refusal `code` and fixed observed `signals`.
@@ -565,10 +616,11 @@ reliably fit. The failure surfaces far from its cause:
 zip I/O error: No space left on device
 ```
 
-The Android job removes the preinstalled toolchains a Flutter build never uses
-(.NET, GHC, PowerShell, Swift, Chromium) and prunes Docker
-images, reclaiming roughly 25 GB in a few seconds. It prints `df -h /` before
-and after. Linux only; skipped in Bitrise mode. npm survives on purpose: the
+The Android job prints `df -h /` and does nothing more when `/` already has
+40 GB or more free (a larger runner). Otherwise it removes the preinstalled
+toolchains a Flutter build never uses (.NET, GHC, PowerShell, Swift, Chromium)
+and prunes Docker images in the background, reclaiming roughly 25 GB while the
+JDK, Gradle restore and Flutter setup run. Linux only. npm survives on purpose: the
 [Crashlytics symbol upload](#crashlytics-symbol-delivery-firebase_app_id) runs
 the Firebase CLI through `npx`.
 
@@ -621,56 +673,12 @@ Both stores pick up per-locale release notes from committed files:
   the deploy workflow passes it to the Play upload and the notes ship with
   every release; when absent, releases upload without notes as before.
 
-## Android delivery via Bitrise (alternative mode)
-
-Use this when the Android **upload keystore password lives in Bitrise** (not in
-the repo) — the GitHub runner then cannot sign the AAB locally. In this mode the
-Android job triggers a Bitrise workflow (which holds the keystore + Play
-service-account secrets) over the Bitrise API and waits for it, mirroring the
-build result back into the GitHub Actions run. iOS still ships via GitHub
-Actions as normal.
-
-Enable it by committing `creds/bitrise.json`:
-
-```json
-{
-  "enabled": true,
-  "app_slug": "8b2a7a24-....",
-  "workflow": "android-deploy",
-  "branch": "main",
-  "api_token": "bitpat_...."
-}
-```
-
-- `app_slug` — the Bitrise app slug (from the app's Bitrise URL or
-  `GET https://api.bitrise.io/v0.1/apps`).
-- `workflow` — the Bitrise workflow that builds, signs, and runs
-  `google-play-deploy` (default `android-deploy`).
-- `branch` — optional; defaults to the pushed ref.
-- `api_token` — a Bitrise personal access token. Committing it to a **private**
-  repo's `creds/` follows the same trust model as the ASC `.p8`. For non-private
-  repos, omit it here and set the `BITRISE_API_TOKEN` Actions secret instead.
-
-When `creds/bitrise.json` is present with `enabled: true`, the local
-build/sign/upload steps are skipped and `bitrise_deploy.py` drives the Bitrise
-build; otherwise the local path above runs unchanged.
-
-The Bitrise `android-deploy` workflow must produce a versionCode higher than
-what is already on Play. The convention used by this fleet is a `+200` offset
-over `$BITRISE_BUILD_NUMBER` via a `change-android-versioncode-and-versionname`
-step, with the versionName read from `pubspec.yaml`.
-
 ## Sharing one distribution cert across a team's apps
 
-The iOS action caches the Apple Distribution cert under `creds/` and reuses it
-across runs (cert alive + NotAfter > 30 days). But Apple caps a team at **2**
-distribution certs, and the cache is per-repo. If **three or more apps share one
-Apple Developer team**, they cannot each hold their own cert — every run finds
-its cached cert already revoked by a sibling, mints a new one, and revokes
-another. The symptom is a "Your Certificate Has Been Revoked" email on nearly
-every deploy.
-
-Fix: apps in the same Apple team should **share one cert**. A fleet registry can
+The iOS action signs with the retained Apple Distribution identity in `creds/`
+(cert alive + NotAfter > 30 days) and never creates or revokes a certificate.
+Apple caps a team at **2** distribution certs, so apps in the same Apple team
+should **share one cert**. A fleet registry can
 provision the same `creds/cert.p12` + `creds/cert.meta.json` into every repo of
 that team (an Apple Distribution cert is team-scoped, not app-scoped, so one
 cert signs them all). Registry provisioning must also write
@@ -683,9 +691,10 @@ The marker is a fail-closed ownership boundary: the action may reuse the
 identity and create per-app provisioning profiles, but it never creates,
 replaces, or revokes a registry-managed distribution certificate. Missing,
 partially written, corrupt, expired, Apple-revoked, or resource-ID/P12-mismatched
-managed material aborts with a reconciliation error. Legacy repos without the
-marker may create a certificate in an available slot, but never revoke another
-identity. A full certificate cap stops for account-registry reconciliation.
+managed material aborts with a reconciliation error. A legacy repo without the
+marker whose retained identity is missing or unusable fails with
+`apple_signing_identity_required` (`gowalk-cicd/apple-signing-identity-required.v1`)
+and keeps its existing signing files.
 
 ## How it works
 
@@ -770,9 +779,7 @@ package produces — the Android App Bundle and the iOS archive — is compiled
 config key that turns it off. Native Swift and Kotlin/Gradle apps are
 unaffected: the flag belongs to the Dart compiler and they have no Dart code.
 Flutter web builds are also untouched — `flutter build web` has no such flag;
-dart2js minifies release output instead. An Android app delivered through
-[Bitrise](#android-delivery-via-bitrise-alternative-mode) is built by Bitrise's
-workflow, not by this action; put the same two flags in that workflow.
+dart2js minifies release output instead.
 
 What it does: the Dart AOT compiler replaces class, function and library names
 with short random identifiers, so the app's Dart symbols cannot be read out of
@@ -847,7 +854,8 @@ is required. A completed CI run does not mean this deferred upload is complete.
 
 ### iOS delivery
 
-The iOS composite action runs on `macos-15` and:
+The iOS composite action runs on `macos-15`; promoting a verified candidate IPA runs its first
+attempt on `ubuntu-24.04` (see [Candidate artifacts](docs/CANDIDATE_ARTIFACTS.md)). It:
 
 GitHub Actions reaches Apple and Google **directly**. No store proxy is configured, read
 or inherited here: the account-pinned residential exit belongs to the panel and the runner
@@ -877,19 +885,16 @@ preserving each app's custom checks and artifact retention settings. An isolated
 4. **Computes the next build number** by querying ASC for the latest uploaded
    build and incrementing.
 5. **Provisions signing** at runtime: reconciles the App ID's capabilities with
-   the target's entitlements (see below), then generates a throwaway Apple
-   Distribution cert + a per-target App Store provisioning profile named
-   `CI-<bundle_id>`. Patches the `.pbxproj` to use Manual signing against those
-   profiles.
+   the target's entitlements (see below), then signs with the retained Apple
+   Distribution identity and the per-target App Store provisioning profile named
+   `CI-<bundle_id>` that App Store Connect already holds, creating the profile
+   when it is missing or stale. Patches the `.pbxproj` to use Manual signing
+   against those profiles.
 6. **Archives** with `xcodebuild archive`, exports the IPA, and uploads via
    Apple's build-upload REST API.
 7. **Sets "What's New"** on every declared localization (reads
    `fastlane/metadata/ios/<locale>/release_notes.txt` if present, or from the
    `app-store-whats-new` input).
-8. **Auto-fills empty App Store metadata** (name, subtitle, keywords,
-   description, promotional text, what's new) via GitHub Models AI, on every
-   locale that has gaps. See [AI metadata auto-fill](#ai-metadata-auto-fill)
-   below.
 
 The iOS action requires only the p8. Everything else is derived.
 
@@ -919,17 +924,16 @@ Before creating a profile, the action reads the target's
 ID — Push Notifications, Associated Domains, HealthKit, SiriKit, HomeKit,
 network extensions and the other plain on/off toggles.
 
-The cached profile under `creds/profiles/` is checked against those same
-entitlements and regenerated when it does not carry them. The cache manifest
-records only a UUID and an expiry, so without that check a profile issued
-before a capability was turned on — whether by this action or by you in the
-developer portal — would be reused indefinitely, and the archive would keep
-failing on a capability the App ID already has.
+An existing `CI-<bundle_id>` profile is found by name and reused only when it
+is ACTIVE, issued for the current certificate, more than 30 days from expiry,
+and carries those same entitlements. Otherwise it is deleted and regenerated, so
+a profile issued before a capability was turned on — whether by this action or
+by you in the developer portal — is never reused.
 
 App Groups require registration and assignment to each participating App ID through
 the account's Apple Developer console. The action reads the literal identifiers from
-each archive target's entitlements and verifies their exact membership in both cached
-and fresh profiles. A stale cache regenerates; a fresh profile missing a required group
+each archive target's entitlements and verifies their exact membership in both reused
+and fresh profiles. A stale profile regenerates; a fresh profile missing a required group
 fails before installation with `apple_app_groups_required`, schema
 `gowalk-cicd/apple-app-groups-required.v1`, containing the bundle ID and missing groups.
 Complete those assignments through the scoped console and rerun CI. This check creates
@@ -948,63 +952,6 @@ Two other classes of capability are **not** enabled automatically, and each gets
   → &lt;your App ID&gt;**. Until then the archive fails with `Provisioning profile
   "CI-<bundle>" doesn't include the App Attest capability`.
 
-## AI metadata auto-fill
-
-On every run, after the TestFlight upload succeeds, the action:
-
-1. Queries App Store Connect for every `appInfoLocalization` and
-   `appStoreVersionLocalization` on the editable version.
-2. Computes the set of empty fields per locale (URL fields are always
-   skipped — you must set those manually in ASC).
-3. Scans your repo for context (README, Info.plist, dependency files, top
-   Swift files) and feeds it to `openai/gpt-4o` via GitHub Models with a
-   strict JSON schema.
-4. PATCHes only the fields that were empty — never overwrites existing
-   content.
-
-Fully idempotent: a second run with no empty fields skips the AI step
-entirely (zero requests, zero PATCHes).
-
-### Requirement: `permissions: models: read`
-
-`actions/ai-inference` needs the `models: read` permission. The template
-workflow written by `npx gowalk-cicd` already includes it:
-
-```yaml
-permissions:
-  contents: read
-  models: read
-```
-
-**Existing consumers must add this block to their `deploy.yml`** at the
-workflow or job level. If it's missing, the AI step fails open with a
-`::warning::` and the rest of the workflow continues unaffected.
-
-### Rate limits
-
-GitHub Models free tier allows **50 `gpt-4o` requests per day** (10 per
-minute). One workflow run = one request. If you run many apps from the
-same GitHub account, or trigger several builds per day, switch to the
-cheaper mini model:
-
-```yaml
-- uses: ./.github/actions/swift-app
-  with:
-    ai-metadata-model: openai/gpt-4o-mini
-```
-
-`gpt-4o-mini` has a much higher free-tier quota.
-
-### Disabling AI metadata
-
-Pass `ai-metadata: 'false'` to skip the AI steps entirely:
-
-```yaml
-- uses: ./.github/actions/swift-app
-  with:
-    ai-metadata: 'false'
-```
-
 ## Update
 
 ```bash
@@ -1012,7 +959,8 @@ npx --yes gowalk-cicd
 ```
 
 Overwrites both vendored actions and `.github/workflows/deploy.yml` with the
-latest versions. Because the actions are vendored locally, builds use the
+latest versions, and deletes vendored files the package no longer ships (see
+[Install](#install)). Because the actions are vendored locally, builds use the
 reviewed copy in your app repository; updates arrive through this npm package.
 
 ## Override config (rare)
@@ -1040,22 +988,14 @@ common ones:
 | `bundle-id` | Override the auto-detected bundle identifier |
 | `team-id` | Override the auto-detected team ID |
 | `app-store-apple-id` | Numeric ASC app ID (override auto-lookup) |
-| `certificate-cap-policy` | Only `fail` is accepted (the default); existing identities are always preserved. |
+| `certificate-cap-policy` | Deprecated and ignored: CI never creates or revokes certificates. |
 | `run-tests` | `false` to skip the simulator test stage |
 | `uses-non-exempt-encryption` | Value for `ITSAppUsesNonExemptEncryption` |
 | `archive` | `false` to build-only (PR runs without secrets) |
 | `upload` | `false` to archive but not upload to TestFlight |
 | `manage-app-store-version` | `false` to upload without creating/editing the App Store release slot |
 | `app-store-whats-new` | Inline "What's New" text (overrides files) |
-| `ai-metadata` | `false` to disable AI auto-fill of empty ASC metadata |
-| `ai-metadata-model` | GitHub Models model id (default `openai/gpt-4o`) |
-
-Certificate creation sends the complete PEM CSR in Apple's `csrContent` field, including its framing and newlines.
-Certificate creation refusals emit `apple_certificate_rejected` with schema
-`gowalk-cicd/apple-certificate-rejected.v1`, `operation`, `http_status`, `reason` and `error_codes`.
-HTTP 409 is classified as `certificate_limit` only when Apple's returned detail identifies the limit;
-otherwise it remains `unclassified_conflict`. Codes come from a fixed allowlist. Raw provider text and
-CSR data are excluded. Neither outcome permits automatic certificate deletion or another creation attempt.
+| `ai-metadata`, `ai-metadata-model` | Deprecated and ignored: the action no longer writes App Store metadata with AI. |
 
 ## First-time app setup
 
@@ -1067,10 +1007,9 @@ inside GitHub Actions.
 Once the app exists, all subsequent builds and uploads are fully automated via
 the ASC API key.
 
-Automatic certificate revocation is disabled for every account. The action may add a certificate when Apple has a free
-slot, but a full-cap response aborts without listing or revoking existing identities. If
-signing preparation fails after creating a certificate, the default-branch workflow first
-commits any completed cache files, then re-raises the failure so the private key is not lost.
+CI never creates, lists for deletion or revokes an Apple Distribution certificate; it
+signs only with the retained identity (see
+[Sharing one distribution cert](#sharing-one-distribution-cert-across-a-teams-apps)).
 
 ## Troubleshooting
 
@@ -1162,29 +1101,13 @@ generated pbxproj). Either move `MARKETING_VERSION` under
 `settings.base` in `project.yml`, or pin
 `marketing-version-auto-bump: 'none'` and bump manually.
 
-## Auto-updates
-
-The vendored action ships with a per-run autoupdate check. On every
-push to your default branch, the action queries npm for the latest
-`gowalk-cicd`, compares against the local marker at
-`.github/actions/swift-app/.daemux-version`, and if newer, re-vendors
-the package via `npx --yes` in a temporary detached worktree and preserves its action files
-on a verified task branch (under both `.github/actions/swift-app/` and
-`.github/actions/android-app/`).
-`.github/workflows/deploy.yml` is NEVER auto-committed — see
-"deploy.yml is not auto-updated" below.
-
-| Aspect | Behaviour |
-|--------|-----------|
-| Trigger | Push to default branch only (PR / branch runs do nothing) |
-| Landing | The app session adopts the exact receipt on its current task branch and uses the protected PR |
-| Isolation | CI leaves HEAD and worktree bytes intact; no default-branch push or rebase |
-| Candidates | Action updates and later version changes have separate verified receipts |
-| Failure mode | npm discovery remains optional; unconfirmed source preservation fails the job |
-
-The shipped `deploy.yml` watches only the release intent. Adopting an action-directory
-update on its own therefore does not launch another mobile upload. Review and adopt the template
-as well as the action directories to enable this behavior in an existing consumer.
+## Updates
+
+CI never updates the vendored actions: the `auto-update` input is deprecated and
+ignored. A repository adopts a new release only when its task runs
+`npx --yes gowalk-cicd` and lands the result through the protected PR. The
+`.daemux-version` markers the installer writes name the release the vendored
+actions came from.
 
 ### deploy.yml is not auto-updated
 
@@ -1194,9 +1117,9 @@ of `contents: write` — this is a built-in safeguard against CI
 self-modification. When a new version of `gowalk-cicd`
 requires `deploy.yml` schema changes (e.g., new permissions, new
 paths-ignore entries), the action's release notes will call this out
-and the app session runs the pinned `npx --yes gowalk-cicd` adoption in its task
+and the app session runs the `npx --yes gowalk-cicd` adoption in its task
 workspace, preserving app-specific workflow inputs and landing the full change through
-its checked PR. The CI-side update does not commit the workflow.
+its checked PR.
 
 Changes that need that manual run:
 
@@ -1207,24 +1130,6 @@ Changes that need that manual run:
   passed to both actions. Until it is, setting the variable does nothing.
   See [Crashlytics symbol upload](#crashlytics-symbol-delivery-firebase_app_id).
 
-### Opt out
-
-Pin the vendored copy by passing `auto-update: 'false'` to the action:
-
-```yaml
-- uses: ./.github/actions/swift-app
-  with:
-    auto-update: 'false'
-```
-
-### First-run bootstrap
-
-The marker is written by `npx gowalk-cicd` itself. A repo
-without a marker (e.g. an old hand-vendored copy) will be treated as
-out-of-date on its first run, after which updates land incrementally.
-Run `npx --yes gowalk-cicd` once locally if you want to skip
-even that first auto-bootstrap.
-
 ## License
 
 MIT