@imagina-build/ias-cli 0.2.2 → 0.3.0

package/README.md

@@ -5,25 +5,26 @@
 - Node 22 o posterior, sin dependencias: `util.parseArgs`, `fetch`, `node:crypto` y `node:test`;
 - la configuración de cada app en `ias.json`;
 - las actualizaciones OTA firmadas (`ias update`) y la distribución interna (`ias dist`), que antes eran `tools/expo-ota` y `tools/expo-dist`;
+- la checklist de alta (`ias setup`): comprueba cada paso contra los ficheros y el servidor, hace los que puede aquí (`ias init`, `ias sdk install`, `ias login`, `ias vault init`, la aplicación con `--create-app`, los proyectos de los servicios y el código del runner) y deja los de una persona con su enlace y su comando exacto;
 - el acceso a la API de gestión (`ias login`, pista 1D-2) y la bóveda sellada: las claves del equipo (`ias vault`), las credenciales de firma (`ias credentials`) y las variables (`ias env`), con el formato `ias-vault-2` de [docs/technical/vault.md](../../docs/technical/vault.md);
 - las builds en los runners de IAS o en este Mac (`ias build`, `ias builds`, `ias version`), los envíos a las tiendas (`ias submit`) y lo que el equipo firma para que los runners se fíen (`ias vault approvers|grant|revoke`), con el contrato de [docs/technical/runner-api.md](../../docs/technical/runner-api.md) (pista 2C);
 - salir de EAS paso a paso (`ias migrate eas`, pista 4D).
 
 ## 1. Instalación
 
-No se publica en npm. Desde este repositorio:
+Se publica en npm como `@imagina-build/ias-cli`, y desde este repositorio se puede usar sin instalar nada:
 
 ```bash
 node packages/cli/bin/ias.mjs --help
 ```
 
-Para tenerlo como `ias` en el Mac:
+Para tenerlo como `ias` en el Mac desde el clon:
 
 ```bash
 npm install --global ./packages/cli
 ```
 
-Sin el repositorio, desde npm, donde cada push a `main` que toca `packages/cli`, `packages/sdk` o `packages/shared` publica la versión de su `package.json` si aún no está ([`.github/workflows/packages.yml`](../../.github/workflows/packages.yml) y [`scripts/publish.mjs`](scripts/publish.mjs)). Se publican como `@imagina-build/ias-cli` y `@imagina-build/ias`, en la organización `imagina-build` de npm. Instalar no pide token:
+En npm, cada push a `main` que toca `packages/cli`, `packages/sdk` o `packages/shared` publica la versión de su `package.json` si aún no está ([`.github/workflows/packages.yml`](../../.github/workflows/packages.yml) y [`scripts/publish.mjs`](scripts/publish.mjs)). Se publican como `@imagina-build/ias-cli` y `@imagina-build/ias`, en la organización `imagina-build` de npm. Instalar no pide token:
 
 ```bash
 npm install --global @imagina-build/ias-cli
@@ -43,36 +44,45 @@ npm run pack:release --prefix packages/cli -- ./release
 
 | Comando | Qué hace |
 | --- | --- |
+| `ias setup [status\|next\|check\|services\|reset] [--create-app] [--name "…"] [--ios-bundle-id <id>] [--android-package <id>] [--apple-team-id <id>] [--app <código>] [--services <lista>] [--team <código>] [--local-builds] [--all] [--build <perfil>] [--publish] [--message "…"] [--wait] [--open] [--item <op://…>] [--dry-run]` | La checklist de alta de una app: comprueba cada paso contra los ficheros y el servidor, hace los que puede aquí (`ias init`, `ias login`, `ias sdk install`, `ias vault init`, la aplicación con `--create-app`, los proyectos OTA y de distribución y el código de alta del runner) y dice qué tiene que hacer una persona. Un paso no avanza mientras el anterior no esté hecho. `next` hace el siguiente; `check` sale con 1 mientras falte algo; `services` elige `updates`, `distribution` y `push`; `reset` olvida el estado local. |
 | `ias init [--app <código>] [--force] [--dry-run]` | Escribe `ias.json` a partir de `app.json`, `eas.json`, `ota.config.json` y `dist.config.json`. Dice de dónde sale cada parte y qué se queda fuera. |
 | `ias doctor` | Comprueba Node, `git`, `op`, Xcode y sus herramientas (`plutil`, `security`, `sips`, `unzip`), `aapt2` del SDK de Android y la configuración de la app. En una app con `package.json`, también el SDK `@imagina-build/ias`: instalado, de una versión compatible con la de `ias` (la misma *major* y, mientras es 0, la misma *minor*) y con su plugin en `app.json`; si la app no lo usa, es un aviso. No abre ningún secreto. |
 | `ias sdk install [--from <origen>] [--dry-run]` | Instala `@imagina-build/ias` con el gestor de paquetes de la app (`packageManager` de `package.json` o su lockfile: npm, yarn, pnpm o bun), añade su plugin al final de los `plugins` de `app.json` sin tocar lo demás (con `app.config.*` no lo toca y dice qué añadir) y dice qué falta: `ias init`, `expo-updates`, `expo-notifications` y `expo-task-manager`, y un prebuild o una build nueva. El paquete sale de `--from` (un `.tgz`, su URL, una carpeta o una versión), de `IAS_SDK_SOURCE`, del `packages/sdk` del repositorio si `ias` corre desde un clon (compilado), o de npm como `@imagina-build/ias@^<versión de ias>`. |
-| `ias update publish\|republish\|rollback-to-embedded\|retire\|restore\|list\|check` | Las actualizaciones OTA, con el comportamiento de `tools/expo-ota` ([README](../../tools/expo-ota/README.md)). `rollback` vale por `rollback-to-embedded`. `--channel` firma con la clave de ese canal y `--rollout <1-100>` empieza con ese porcentaje de las instalaciones (§3.1). |
+| `ias update init\|publish\|republish\|rollback-to-embedded\|retire\|restore\|list\|check` | Las actualizaciones OTA, con el comportamiento de `tools/expo-ota` ([README](../../tools/expo-ota/README.md)). `init` crea el proyecto OTA, su clave de firma y su token en 1Password y escribe `ias.json` (Fase 2). `rollback` vale por `rollback-to-embedded`. `--channel` firma con la clave de ese canal y `--rollout <1-100>` empieza con ese porcentaje de las instalaciones (§3.1). `check` comprueba el canal por defecto de `app.json` y, con `--channel <canal>`, pide el manifiesto como una build de ese canal y lo verifica con su certificado de `ias.json`. |
 | `ias update promote <grupo> --to <canal>` | Publica un grupo en otro canal: comprueba sus bytes con el certificado de su canal y vuelve a firmar el contenido en este Mac con la clave del de destino, con un `id` y un `createdAt` nuevos. Nunca copia una firma (API.md §36.11). |
 | `ias update rollout <grupo> <porcentaje>\|pause\|complete` | Sube o baja el porcentaje de un despliegue (de 1 a 99; 100 lo completa), lo pausa o lo completa (API.md §36.9). |
 | `ias update channels` | Los canales del proyecto con su keyid y su certificado, y si este Mac firma para cada uno. |
-| `ias dist upload\|list\|retire\|restore` | La distribución interna, con el comportamiento de `tools/expo-dist` ([README](../../tools/expo-dist/README.md)). |
-| `ias login [--team <código>]` | Autoriza este ordenador con una passkey (autorización de dispositivo, RFC 8628) y guarda su token personal (`iasp_…`), que es de un equipo (§4). |
+| `ias dist upload\|list\|retire\|restore` | La distribución interna, con el comportamiento de `tools/expo-dist` ([README](../../tools/expo-dist/README.md)). `ias dist init` crea el proyecto y su token en 1Password (Fase 2). |
+| `ias login [--name "…"] [--team <código>] [--no-browser]` | Autoriza este ordenador con una passkey (autorización de dispositivo, RFC 8628) y guarda su token personal (`iasp_…`), que es de un equipo (§4). |
 | `ias logout` | Revoca el token guardado (`DELETE /me/token`) y lo borra. No toca `IAS_TOKEN`. |
 | `ias whoami` | De quién es el token, de qué equipo, de dónde sale y sus alcances. |
 | `ias teams` | Los equipos de la persona, con su rol en cada uno, y cuál es el del token (`GET /teams`). |
-| `ias apps [<código>]` | Las aplicaciones que ve el token, o una en detalle. |
+| `ias apps [<código>]` | Las aplicaciones que ve el token, una en detalle, una nueva (`--create`) o sus servicios (`--services`). `--create --dry-run` enseña el mismo plan que `ias setup --create-app --dry-run` y no crea nada. |
+| `ias apps store <código> [--check] [--register-bundle-id] [--set-asc-app-id <id>]` | La identidad de la app en App Store Connect: sin flags enseña el bundle id, el app record que IAS guarda y el formulario del alta; `--register-bundle-id` registra el App ID si falta, `--check` lee Apple y guarda el Apple ID, y `--set-asc-app-id` lo guarda a mano. La clave de App Store Connect sale de la bóveda y se abre en este Mac. |
 | `ias usage [--month AAAA-MM]` | Lo que el equipo del token ha usado en un mes (minutos de build, artefactos, OTA, notificaciones, sincronización, dispositivos), por aplicación y con sus límites; con un límite agotado, las builds, las notificaciones o los dispositivos que cubre se rechazan con `limit_exceeded` (`GET /team/usage`, manage-api §17). |
-| `ias vault init\|status` | Crea la clave de recuperación y la de firma del equipo en 1Password y registra sus públicas, con una aprobación con passkey; o compara las del servidor con las de 1Password y verifica la lista firmada de runners (§5). |
-| `ias vault approvers` | Firma con la clave del equipo las passkeys de los `owner` que pueden aprobar una build de tienda (`ias-approvers-1`), después de enseñarlas con su huella y lo que cambia desde la versión firmada, y la sube (§5.2). |
-| `ias vault grant\|revoke <runner>` | Deja a un runner abrir las credenciales del equipo (la lista firmada y una envoltura en cada sobre) o se lo quita cuando el panel ya lo revocó (§5.2). |
-| `ias credentials import\|list\|show\|rotate\|retire` | Sella en este ordenador y sube las credenciales de firma, con sus metadatos sin secreto; las lista, enseña quién puede abrirlas y quién las firmó, las sustituye por una versión nueva y las retira (§5). |
+| `ias vault init\|status` | Crea la clave de recuperación y la de firma del equipo en 1Password (`--item` elige el ítem) y registra sus públicas, con una aprobación con passkey; o compara las del servidor con las de 1Password y verifica la lista firmada de runners (§5). `init --dry-run` no crea el ítem ni registra nada. |
+| `ias vault approvers` | Firma con la clave del equipo las passkeys de los `owner` que pueden aprobar una build de tienda (`ias-approvers-1`), después de enseñarlas con su huella y lo que cambia desde la versión firmada, y la sube (§5.2). `--dry-run` enseña la versión que firmaría y no firma ni sube. |
+| `ias vault grant\|revoke <runner>` | Deja a un runner abrir las credenciales del equipo (la lista firmada y una envoltura en cada sobre) o se lo quita cuando el panel ya lo revocó (§5.2). `--dry-run` dice qué lista firmaría y qué sobres cambiaría, sin firmar, subir ni tocar un sobre. |
+| `ias policy init\|check\|sign\|show\|status\|diff\|simulate` | La política firmada de quién aprueba cada build o envío y cuántos: `init` escribe `ias.policy.json` equivalente a hoy, `sign` la firma con la clave del equipo y pide una passkey, y el resto la comprueban, enseñan, comparan o simulan (§5.3). El fichero se da como argumento (`ias policy simulate ias.policy.json …`) o con `--file`; `check`, `show`, `status`, `diff` y `sign` aceptan `--item`. El servidor la aplica al crear y al aprobar trabajos de tienda, y el runner la verifica antes de abrirlos. |
+| `ias credentials generate\|import\|list\|show\|rotate\|retire\|revoke` | Sella en este ordenador y sube las credenciales de firma, con sus metadatos sin secreto; las lista, enseña quién puede abrirlas y quién las firmó, las sustituye por una versión nueva y las retira (`retire` toma el `id` o el nombre, y `--dry-run` no retira). `generate ios` hace o reutiliza el certificado de distribución y el perfil de App Store de la app; `revoke` quita el certificado en Apple con la aprobación de un propietario y lo retira; `generate android_upload_keystore` crea la clave de subida de Android con `keytool` y la guarda en 1Password (§5). |
 | `ias env list\|set\|pull\|delete` | Las variables de cada entorno. `EXPO_PUBLIC_*` siempre en claro; las demás, selladas salvo `--plain`. `pull` escribe `.env.local` sin los secretos. |
-| `ias build [--platform ios\|android\|all] [--profile <perfil>] [--message "…"] [--wait] [--local]` | Manda el commit de un árbol limpio a un runner de IAS con el perfil de `ias.json`, abre la aprobación de una build de tienda y sigue su registro hasta que acaba; con `--wait` baja los artefactos. Con `--local`, la hace en este Mac con `@imagina-build/ias-runner` (§6). |
+| `ias build [--platform ios\|android\|all] [--profile <perfil>] [--message "…"] [--wait] [--out <carpeta>] [--detach] [--local] [--credentials <op://…\|carpeta>]` | Manda el commit de un árbol limpio a un runner de IAS con el perfil de `ias.json`, abre la aprobación de una build de tienda y sigue su registro hasta que acaba; con `--wait` baja los artefactos. Con `--local`, la hace en este Mac con `@imagina-build/ias-runner` (§6). |
 | `ias builds list\|view\|logs\|cancel\|download` | Las builds de la aplicación: la lista, una en detalle, su registro (`--follow`), cancelarla y bajar sus artefactos comprobados (§6). |
-| `ias submit <build> [--track <pista>] [--wait]` | Manda una build de tienda a App Store Connect o a Google Play, siempre como borrador, después de que un `owner` lo apruebe con su passkey (§6). |
+| `ias submit <build> [--track <pista>] [--release-status draft\|inProgress\|completed] [--rollout <1-99>] [--changes-not-sent-for-review] [--wait]` | Manda una build de tienda a App Store Connect o a Google Play, después de que un `owner` lo apruebe con su passkey (§6). En Play sale **como borrador** por defecto; `inProgress` con `--rollout` y `completed` solo si la política de la pista lo permite (docs/plans/gaps/03-google-play-rollout.md). `--track` acepta `internal`, `alpha`, `beta`, `production`, una pista cerrada o una de un factor de forma (`wear:production`). `--changes-not-sent-for-review` aplica el commit sin enviarlo a revisión: una persona lo envía desde Play Console, y hasta entonces no llega a testers ni a usuarios (con un borrador es redundante). |
+| `ias releases list\|view <pista>\|policy <pista>` | `list` y `view` son solo lectura del estado de cada pista de Google Play (sin flags; `--refresh` encola un trabajo que solo lee Play y espera). `policy` enseña la política de la pista; con `--mode`, `--max-percent`, `--step` o `--min-minutes` la cambia un owner. |
+| `ias rollout <pista> [--percent <1-99> \| --halt \| --resume [--percent <1-99>] \| --complete] [--version-code <n>] [--wait] [--dry-run]` | Mueve la release que ya está en una pista de Google Play: sin flags solo lee y dice el siguiente paso; cada acción es un trabajo con su passkey, sin artefacto. Nunca baja el porcentaje (para parar, `--halt`). |
+| `ias testflight <build> [--groups <nombre>…] [--what-to-test "…"] [--locale <locale>] [--notes-file <json>] [--notify] [--wait] [--dry-run]` | Reparte a grupos de TestFlight una build que ya está en App Store Connect, con su «What to Test» y su aprobación; sin `--groups` usa `ias.json` › `submit.<perfil>.ios.testflight.groups` y, si no hay, lista los grupos que la app tiene y da el comando exacto (nunca crea uno) (§6). |
+| `ias testflight distribute\|review\|status <build>` | `distribute` es la forma explícita de `ias testflight <build>`: lo mismo, con las mismas opciones. `review` envía la build a Beta App Review: es otro comando, con su propia passkey y su aviso, y solo hace falta para testers externos. `status` es solo lectura: procesamiento, grupos, idiomas y estado de la revisión (§6). |
 | `ias version get\|set` | Los números de build que guarda el servidor por plataforma, los que toma `autoIncrement`; `set` los trae de EAS o de `app.json` y solo los deja subir (§6). |
 | `ias push send\|messages\|cancel\|devices\|credentials` | Las notificaciones push: envía una ahora, la programa con `--at` o cuenta a quién llegaría con `--dry-run`; el historial con sus cifras; los dispositivos, con solo el principio y el final de su token; y las credenciales de APNs y FCM, que aprueba un propietario con su passkey (§5.1). |
 | `ias devices list [--status <estado>]` | Los iPhone y iPad de quien prueba la app, con su estado (pendiente, aprobado, en Apple, rechazado), la versión del perfil que los lista y el enlace de registro (§6.1). |
-| `ias devices sync [--yes] [--no-resign] [--detach]` | Da de alta en Apple los dispositivos aprobados, regenera el perfil ad hoc con todos ellos, lo sella y lo firma en la bóveda, y pide que un runner firme de nuevo la última build interna de iOS, sin compilarla (§6.1). |
-| `ias webhooks list\|create\|delete\|test` | Los webhooks salientes de la aplicación: la lista, uno nuevo con sus eventos (`--events build.failed,device.pending` o `all`; imprime su secreto, una vez), borrarlo y mandarle una prueba. Cada evento llega como un POST firmado con `IAS-Signature` (docs/technical/manage-api.md §16.1). |
-| `ias github link <owner/name>` | Vincula el repositorio de GitHub de la aplicación: sus etiquetas, ramas y pull requests lanzan los flujos de `ias.json`. La primera vez imprime lo que hay que poner en el webhook de GitHub (el secreto, una vez); el token de GitHub lo carga un propietario en el panel, con una passkey (§16.2). |
+| `ias devices sync [--yes] [--force] [--no-resign] [--detach] [--dry-run]` | Da de alta en Apple los dispositivos aprobados, regenera el perfil ad hoc con todos ellos, lo sella y lo firma en la bóveda, y pide que un runner firme de nuevo la última build interna de iOS, sin compilarla (§6.1). `--dry-run` enseña los dispositivos, el perfil y la nueva firma que encolaría, sin llamar a Apple, escribir en la bóveda ni crear un trabajo. |
+| `ias webhooks list\|create\|delete\|test` | Los webhooks salientes de la aplicación: la lista, uno nuevo con sus eventos (`--events build.failed,device.pending` o `all`; imprime su secreto, una vez), borrarlo y mandarle una prueba. `create --dry-run` y `delete --dry-run` dicen qué harían sin crear, borrar ni enseñar un secreto. Cada evento llega como un POST firmado con `IAS-Signature` (docs/technical/manage-api.md §16.1). |
+| `ias github link <owner/name>` | Vincula el repositorio de GitHub de la aplicación: sus etiquetas, ramas y pull requests lanzan los flujos de `ias.json`. `--dry-run` dice qué vincularía, sin vincular ni enseñar el secreto. La primera vez imprime lo que hay que poner en el webhook de GitHub (el secreto, una vez); el token de GitHub lo carga un propietario en el panel, con una passkey (§16.2). |
 | `ias workflows list\|run` | Los flujos de `ias.json` en un commit del repositorio, y lanzar uno a mano (`ias workflows run release --ref main [--wait]`) (§16.3). |
 | `ias migrate eas [profiles\|prepare\|import <carpeta>\|version\|env\|checklist]` | Sale de EAS paso a paso: los perfiles de `eas.json` a `ias.json`, una carpeta fuera del proyecto para `eas credentials`, las credenciales selladas en la bóveda, los números de build y las variables de EAS en el servidor, y lo que queda por hacer en expo.dev y en las tiendas. Sin paso, dice en qué punto está (§8). |
+| `ias tokens create\|list\|revoke` | Los tokens de robot de la aplicación para la CI: crea uno y lo guarda en 1Password (sin imprimirlo), los lista sin su valor y revoca uno por su `id` o su nombre (`--dry-run` no revoca). Un `owner` con token personal; la API ya no obliga a crearlo en el panel (§2.1). |
+| `ias runners code` | Un código de alta de runner, de un solo uso y 30 minutos, con la orden para el Mac del runner. Un `owner`; después, `ias vault grant`. |
 
 Cada comando tiene su ayuda: `ias update --help` o `ias update publish --help`. `--project <carpeta>` elige la app; si no, la carpeta actual.
 
@@ -84,6 +94,116 @@ Cada comando tiene su ayuda: `ias update --help` o `ias update publish --help`.
 
 **Códigos de salida**: `0` si funciona, `1` si falla y `2` si la línea de órdenes no se entiende (un comando o una opción que no existen, o falta un argumento).
 
+### 2.1 `ias setup`: la checklist de alta
+
+`ias setup` lleva una app de Expo de cero a su primera build y su primera actualización. No es un asistente que
+pregunta: es una lista de pasos que se comprueba contra los ficheros del proyecto y el servidor, así que se puede
+repetir en cualquier momento y desde cualquier ordenador.
+
+| Acción | Qué hace |
+| --- | --- |
+| `ias setup` | El estado: cada paso con lo que ha encontrado, lo que falta y cuál es el siguiente. |
+| `ias setup next` | Hace el siguiente paso automático, o explica qué tiene que hacer una persona (con el enlace del panel y el comando exacto). `--all` encadena los automáticos hasta el primero que necesita a alguien; `--open` abre su enlace. |
+| `ias setup next --build <perfil>` | Hace la primera build con ese perfil (`preview` por ejemplo) y se detiene; es explícito por coste y cuota. |
+| `ias setup next --publish` | Publica la primera actualización OTA después de una build correcta. |
+| `ias setup check [paso]` | Vuelve a comprobar todo (o un paso) y sale con `1` mientras falte algo obligatorio. Es la puerta de la CI. |
+| `ias setup services updates,distribution,push` | Los servicios de la app; se guardan para las siguientes ejecuciones. Sin argumentos, los enseña. |
+| `ias setup reset` | Olvida el estado local. No borra nada del proyecto. |
+
+Los pasos, en orden: `environment` (Node, `git`, `op`), `project` (`ias.json`), `login`, `application` (la crea una
+persona en el panel; con `--create-app`, el CLI), `services` (crea el proyecto OTA y el de distribución, enciende push y
+escribe su install key), `stores` (opcional: el bundle id, el app record y el paquete de Play que IAS guarda; nunca
+llama a Apple), `sdk` (`ias sdk install` con los módulos de Expo de los servicios), `vault` (`ias vault init`),
+`credentials` (`ias credentials generate ios` para iOS, `generate android_upload_keystore` para Android, e `ias credentials
+import` para lo que venga de fuera), `signing` (opcional: comprueba, solo con las credenciales del servidor, si el
+certificado de distribución y el perfil de App Store existen y son válidos, y propone `ias credentials generate ios`),
+`runner` (crea el código de alta y espera al registro), `build`, `testflight` (opcional: si hay una build de tienda de iOS
+en App Store Connect, propone `ias testflight <build>`; `--all` no lo ejecuta nunca), `updates`, `distribution`, `push`
+y `ci`.
+`stores`, `signing`, `testflight`, `push` y `ci` son opcionales; `runner` lo es con `--local-builds`. Un paso con servicio solo
+cuenta si ese servicio está elegido.
+
+- **Se deriva, no se recuerda.** Que `ias.json` exista, que `GET /vault` tenga sus claves o que haya una build
+  terminada se comprueba cada vez. Lo único local es un fichero de estado fuera del repositorio
+  (`$XDG_STATE_HOME/ias/setup/`, o `~/Library/Application Support/ias/setup/`), sin secretos: `ias build` exige un
+  árbol limpio y un `.ias/` en el proyecto lo ensuciaría.
+- **Nada fuera de orden.** Un paso bloqueado no se ejecuta y lo dice: `[ ] sdk  finish application first`.
+- **Lo que ya existía se reutiliza.** `ias setup` llama a `ias init`, `ias sdk install`, `ias login` y `ias vault init`;
+  no cambia sus reglas ni sus salidas.
+- **`--json`** devuelve `{ app, server, services, complete, counts, steps, next }`; cada paso trae `status` (`done`,
+  `ready`, `locked` u `optional`), `detail`, `fix`, `command` y `url` cuando los hay.
+
+El plan y las decisiones están en [`docs/plans/PLAN-ONBOARDING.md`](../../docs/plans/PLAN-ONBOARDING.md). Con la Fase 2,
+`services` crea el proyecto OTA y el de distribución (con su clave y su token en 1Password) y `runner` crea el código
+de alta; el alta ya solo necesita a una persona para los ficheros de Apple y Google y para aprobar con passkey.
+
+
+### 2.2 Alta de los proyectos, de la clave y de los tokens
+
+La Fase 2 quita artisan y el panel del alta. Un `owner` con su token personal (no un token de robot) crea la
+aplicación, sus proyectos y sus tokens; el CLI lo guarda en 1Password y deja en `ias.json` solo la referencia `op://`:
+
+```bash
+ias apps --create --code mi-app --name "Mi app" --services updates,distribution,push
+ias apps mi-app --services updates,distribution,push   # cambia los servicios; no apaga uno con piezas
+ias apps store mi-app         # la identidad en App Store Connect; si falta el app record, el formulario y el comando
+ias update init      # clave RSA + certificado, proyecto OTA, token
+ias dist init        # proyecto de distribución y su token
+ias credentials generate ios                            # certificado de distribución y perfil de App Store (reutiliza lo válido)
+ias credentials generate android_upload_keystore        # clave de subida de Android
+ias tokens create --name "GitHub Actions" --scopes apps:read,builds:create --days 90
+ias runners code     # un código de alta de runner, para ias-runner register
+```
+
+- **`ias apps --create`** crea la aplicación con el código, el nombre y los identificadores que se le den (o los de
+  `app.json` desde `ias setup --create-app`). `--services` enciende servicios. No crea secretos.
+- **`ias update init`** hace la clave RSA y un certificado autofirmado de 10 años en `certs/ota-certificate.pem` (va en
+  git), crea el proyecto con `POST /apps/<app>/updates` y guarda la clave y el token en el ítem de 1Password
+  (`op://IAS/<app> OTA` por defecto). Nunca imprime la clave ni el token; con `--dry-run` no hace nada. Si el
+  proyecto ya existe con el mismo certificado, no lo toca ni rota el token. Si existe con otro, para: rotar el
+  certificado pide una build nueva.
+- **`ias dist init`** hace lo mismo con el proyecto de distribución y su token (`op://IAS/<app> distribution`).
+- **`ias credentials generate android_upload_keystore`** hace un PKCS12 con contraseñas aleatorias con `keytool`, lo
+  guarda como adjunto de `op://IAS/<app> Android upload` (con las contraseñas en campos `CONCEALED`) y lo sella en la
+  bóveda por el mismo camino que `ias credentials import`.
+- **`ias credentials generate ios`** hace lo mismo con la firma de iOS, en una sola orden: reutiliza el certificado de
+  distribución del equipo que la bóveda tiene y Apple sigue listando, y el perfil de App Store del bundle id que lo
+  contiene; si faltan, crea aquí la clave RSA-2048 y el CSR, pide el certificado a Apple con la clave de App Store
+  Connect de la bóveda, monta y valida el `.p12`, lo sella y deja la copia de recuperación en
+  `op://IAS/<equipo> Apple Distribution <serie>`. El perfil de tienda se sella sin dispositivos (`devices: 0`). Si hay
+  varios certificados pide `--certificate <sha1|id>`; `--rotate` hace uno nuevo **con la aprobación de un propietario**
+  (conserva el `id` de la credencial y sube la versión; Apple no deja tener dos y el comando no revoca nada salvo que se
+  le pida con `revoke`); `--if-expiring <días>` decide cuándo renovar; `--no-profiles` deja el perfil de App Store para
+  después y la salida dice el comando que falta (`ias credentials generate ios`); `--dry-run` no escribe nada ni pide
+  aprobaciones. Si Apple tiene **varios perfiles de App Store utilizables** del bundle id, no elige: los lista y pide
+  `--profile <uuid|nombre>`; con uno válido lo reutiliza. `--sync-capabilities` habilita en el App ID lo que pide
+  `app.json` › `expo › ios › entitlements` (solo lo que falta, nunca deshabilita) y avisa de que Apple invalida todos
+  los perfiles del App ID, el ad hoc incluido: después, `ias devices sync --force`. `--delete-previous` borra en Apple,
+  tras sellar y subir el nuevo, el perfil de App Store que este sustituye (nunca el ad hoc, ni el de otra credencial ni en un
+  `--dry-run`), preguntando antes. Los comandos `generate apple_distribution_certificate` y `generate apple_provisioning_profile` repiten
+  solo una parte; el ad hoc sigue siendo de `ias devices sync`.
+- **`ias credentials revoke <id>`** es para un certificado comprometido, no para renovar. Lo hace un `owner`: lee Apple,
+  enseña la serie, el SHA-1, los perfiles y las apps afectadas, pide la aprobación con passkey, y **solo entonces**
+  hace `DELETE /v1/certificates/{id}` y retira la credencial. Un rechazo o una caducidad no borran nada en Apple; si el
+  certificado ya no está, retira igual y lo dice. Después hay que regenerar los perfiles con
+  `ias credentials generate ios` (y `ias devices sync --force` para las builds internas). `--json` da un documento
+  estable, `--dry-run` solo el inventario.
+- **`ias tokens create`** crea un token de robot (`iasr_…`) con sus alcances y días y lo deja en
+  `op://IAS/<app> CI`; `list` los enseña sin su valor y `revoke` los mata. En la CI, `IAS_TOKEN` se lee de ese ítem.
+- **`ias runners code`** pide el código de alta (30 minutos, un solo uso) y enseña la orden para el Mac del runner; el
+  runner queda pendiente hasta `ias vault grant`.
+
+**Nombres en 1Password.** Los ítems que crea el CLI van al vault `IAS` (se puede cambiar con `--item`), con el código
+de la app y un propósito: `<app> OTA`, `<app> distribution`, `<app> CI`, `<app> Android upload`. Los campos nuevos son
+kebab-case (`private-key`, `certificate`, `key-id`, `token`, `project`, `server`; `keystore`, `store-password`,
+`key-alias`, `key-password`). Los ítems y referencias de antes (`op://Private/...`, `private-key.pem`, `credential`)
+siguen leyéndose: no se renombra nada. La bóveda del equipo también usa `op://IAS/IAS vault <host>` por defecto; si ya
+existe en `Private`, se apunta con `vault.item`, `IAS_VAULT_ITEM` o `--item`.
+
+Nada de esto imprime un secreto: la clave, las contraseñas y los tokens viajan por la entrada estándar de `op` y se leen
+con `op read`. El servidor solo recibe el certificado público; el registro de acciones guarda el proyecto y el keyid,
+nunca el token.
+
 ## 3. `ias.json`
 
 Va en la raíz de la app, junto a `app.json`, y en git: no lleva secretos. Su esquema es [`schema/ias.schema.json`](schema/ias.schema.json) (JSON Schema 2020-12), que también usarán el runner y el SDK. `src/schema.mjs` lo valida sin dependencias.
@@ -112,12 +232,12 @@ Va en la raíz de la app, junto a `app.json`, y en git: no lleva secretos. Su es
 | Campo | Qué es |
 | --- | --- |
 | `app` | El código de la aplicación en IAS (`apps:create`). También es el del proyecto de distribución, salvo que `distribution.project` diga otro. |
-| `server` | El origen de IAS. Por defecto, `https://ias.imagina.build`, que todavía no responde. Las OTA van al servidor de `updates.url` de `app.json`, que es al que preguntan las builds; sin ella, al de este campo (§3.2). |
+| `server` | El origen de IAS. Por defecto, `https://ias.imagina.build`, ya en servicio. Mientras dure la migración de dominio, `sync.domibi.com` responde la misma API sin redirección, así que sirve cualquiera de los dos; la aprobación del login (§4) se hace en el panel del dominio de `APP_URL`, todavía `sync.domibi.com`. Las OTA van al servidor de `updates.url` de `app.json`, que es al que preguntan las builds; sin ella, al de este campo (§3.2). |
 | `build`, `submit` | Los perfiles de `eas.json`, sin credenciales. La Fase 2 (`ias build`) los completa. |
 | `updates` | La firma del canal por defecto (`keyId`, `certificate` y `privateKey`), el `token` del proyecto OTA, `envFile` y `bundleEnv`. El servidor, el proyecto, el certificado y el keyid salen de `app.json` o, si no los tiene, de `ias.json`, como los escribe el plugin de `@imagina-build/ias` (§3.2). `channels`, la firma de los demás canales (§3.1). |
 | `distribution` | El `token` del proyecto de distribución y, si no es el de `app`, su `project`. |
 | `workflows` | Lo que lanza GitHub (una etiqueta, una rama o un pull request) y en qué pasos: `build` y `submit` (§3.0). |
-| `vault` | `item`: el ítem de 1Password de la bóveda (`op://<bóveda>/<ítem>`), si no es `op://Private/IAS vault <host del servidor>`. |
+| `vault` | `item`: el ítem de 1Password de la bóveda (`op://<bóveda>/<ítem>`), si no es `op://IAS/IAS vault <host del servidor>`. |
 
 ### 3.0 Flujos (`workflows`)
 
@@ -211,7 +331,7 @@ Con el plugin de `@imagina-build/ias` en los `plugins` de `app.json` (`packages/
 
 El material de firma se sella **en este ordenador** con `ias-vault-2` ([docs/technical/vault.md](../../docs/technical/vault.md)): para la clave de recuperación del equipo y para los runners de la lista que firmó el equipo, y firmado con la clave de firma del equipo. El servidor guarda el sobre y los metadatos, y no puede abrirlo ni firmarlo.
 
-**Las claves del equipo** viven en un ítem de 1Password (`vault.item`, `IAS_VAULT_ITEM` o `--item`; por defecto `op://Private/IAS vault <host>`), con los campos de docs/technical/vault.md §2.2.
+**Las claves del equipo** viven en un ítem de 1Password (`vault.item`, `IAS_VAULT_ITEM` o `--item`; por defecto `op://IAS/IAS vault <host>`), con los campos de docs/technical/vault.md §2.2.
 - `ias vault init` (un `owner`) las crea con `node:crypto`, crea el ítem con `op item create` pasándole la plantilla por stdin, y registra las públicas (`POST /vault/keys`). El servidor responde `202 approval_required`: el CLI abre la aprobación, enseña los dos `kid` para compararlos con los del panel y pregunta cada 3 s hasta que se aprueba. Si el ítem ya existe (un intento anterior sin aprobar), registra sus claves.
 - `ias vault status` lee solo las públicas de 1Password, las compara con las del servidor y verifica la lista firmada de runners. Sale con 1 si algo no cuadra.
 
@@ -235,7 +355,7 @@ El material de firma se sella **en este ordenador** con `ias-vault-2` ([docs/tec
 - El CLI saca los metadatos con `@imagina-build/ias-shared/credentials` (`metadataOf`), genera el `id` (un UUID), sella el texto en claro del tipo (docs/technical/vault.md §3.5) y sube `{ id, type, name, metadata, envelope }` a `/apps/<app>/credentials` o, si es del equipo, a `/team/credentials`.
 - Una credencial que ya está (el mismo certificado, perfil o clave) se salta; `ias credentials rotate <id>` la sustituye por la versión siguiente. `--dry-run` lo hace todo menos subirla.
 
-`ias credentials list` (con `--all`, también las retiradas), `show <id>` (con `--verify`, comprueba la firma con la clave de 1Password), `rotate <id>` y `retire <id>`.
+`ias credentials list` (con `--all`, también las retiradas), `show <id>` (con `--verify`, comprueba la firma con la clave de 1Password), `rotate <id>` (si cambia el SHA-1 de un certificado, pide la aprobación de un `owner`), `retire <id>` y `revoke <id>` (Apple y retirada, con passkey).
 
 **`ias env`**:
 - `ias env set NOMBRE [valor] --environment <entorno>`: `EXPO_PUBLIC_*` siempre en claro (y `--secret` da error). Cualquier otra se sella como `environment_variable` salvo `--plain`, y su valor llega con `--from op://…|env:NOMBRE|-`, nunca en la línea de órdenes. Una secreta que ya existe conserva su `id` y sube de versión.
@@ -268,6 +388,25 @@ Un runner solo se fía de la clave de firma del equipo y del panel que fijó al
 
 Ninguno imprime ni escribe una clave privada: la de firma y la de recuperación se leen con `op read` a memoria.
 
+### 5.3 La política de aprobación (`ias policy`)
+
+Qué passkeys pueden aprobar cada build de tienda y cada envío, y cuántas, por aplicación, plataforma, perfil, tipo y, en un envío, tienda y pista ([docs/technical/vault.md](../../docs/technical/vault.md) §2.5). La fuente es **`ias.policy.json`**, versionable en el repositorio; la firma se hace aquí, con la clave del equipo de 1Password, y el servidor solo la guarda y la verifica.
+
+| Comando | Qué hace |
+| --- | --- |
+| `ias policy init [--out <fichero>] [--version <n>] [--not-after <fecha>] [--force]` | Lee `GET /team/approvers` y escribe una política **equivalente a hoy**: una regla comodín (`app`, `platform`, `profile`, `type`, `target` y `track` en `*`), `count: 1` y todos los owners con passkey. La versión es la siguiente a la del servidor y caduca en 180 días, salvo que se diga otra cosa. No firma. |
+| `ias policy check [fichero]` | Valida forma y semántica, verifica la firma si la tiene, y compara versión, miembros (cada uno necesita passkey en el `ias-approvers-1` vigente), fecha y cobertura con el servidor. Sale con 1 si hay algo que arreglar y dice el comando o la edición exactos. |
+| `ias policy sign [fichero] [--item <op://…>] [--yes]` | Enseña versión, caducidad, hash, diff y reglas; pide confirmación; lee la clave privada del ítem de la bóveda (solo en memoria), firma el texto canónico y hace `PUT /team/policy` con el documento firmado. El servidor responde 202 con una aprobación `vault.policy.upload`: el CLI abre el panel y espera a que un `owner` compare el hash y apruebe con su passkey. Nunca imprime la clave. |
+| `ias policy show [--item <op://…>]` | La política del servidor, verificada con la clave del equipo (comparada con 1Password cuando está), con versión, caducidad, hash y cada regla con sus miembros. |
+| `ias policy status [--item <op://…>]` | Si hay política, si la firma verifica, cuándo caduca, qué reglas no tienen bastantes passkeys, qué combinaciones de app y perfil no cubre y si `ias.policy.json` es la del servidor. Sale con 1 solo si la del servidor no verifica. |
+| `ias policy diff [fichero]` | Las reglas que entran, cambian o salen y los miembros que entran o salen, entre la política del servidor y el fichero. |
+| `ias policy simulate [fichero] --platform <ios\|android> --profile <perfil> [--app <código>] [--type build\|submit\|testflight\|release] [--target …] [--track …]` | Lo que decidiría el fichero local: la regla que gana (la más específica) y quiénes pueden aprobar, o la denegación. El fichero va como argumento o con `--file` (la forma de antes). Sale con 1 si ninguna regla casa. |
+
+- **Matching**: casa una regla cuyos seis campos sean `*` o el valor del trabajo; gana la de más campos concretos. Dos reglas que empaten hacen inválido el documento. Sin regla, se deniega: no hay regla implícita.
+- **Se aplica desde ahora.** El servidor guarda, verifica y sirve la política, y la aplica al crear un trabajo de tienda (`409 policy_unmatched` antes de la URL de subida) y al aprobarlo (solo los miembros de la regla, y el trabajo encola al llegar a `count` personas distintas). Si la política rota, los trabajos que esperaban caducan con `policy_changed`; `JobDispatcher` solo da un trabajo con política a un runner con `capabilities.policy >= 1`, y el runner verifica la firma, la versión, la caducidad, la regla y las N aserciones antes de descargar código. `ias build`, `ias submit`, `ias testflight` y `ias rollout` enseñan la regla y el progreso («policy ios-production · 1 of 2»). Sigue sin haber delegación (`ias-approvers-2`), aprobación por lotes ni política para OTA, y un equipo sin política se comporta exactamente como antes: `ias setup` no la pide y `ias setup next --all` no la firma.
+- **Solo sube la versión.** Volver a una política anterior exige una versión mayor con el contenido anterior. `sign` avisa y no firma una versión que no suba; el servidor la rechaza con `409 policy_version_backwards`.
+- **Con `--json`**, todos devuelven un documento estable (`file`, `version`, `hash`, `problems`, `added`, `allowed`…), sin claves.
+
 ## 6. Las builds y los envíos a las tiendas
 
 Con el contrato de [docs/technical/runner-api.md](../../docs/technical/runner-api.md) §4 y §6. Una build de tienda necesita un token personal (`ias login`) y la aprobación de un `owner` con su passkey; una interna vale también con un token de robot con `builds:create`.
@@ -284,10 +423,20 @@ Con el contrato de [docs/technical/runner-api.md](../../docs/technical/runner-ap
 
 **`ias builds`**: `list [--status <estado>] [--platform]`, `view <id>`, `logs <id> [--follow]`, `cancel <id>` (quien la lanzó o un `owner`) y `download <id> [--kind ipa,dsyms] [--out <carpeta>]`. El registro es el que mandó el runner, ya limpio de secretos.
 
-**`ias submit <build>`**: una build de tienda que acabó bien va a App Store Connect (con el Apple ID de `--asc-app-id` o de `submit.<perfil>.ios.ascAppId`) o a Google Play (la pista de `--track`, de `submit.<perfil>.android.track` o `internal`), **siempre como borrador** (D7): la revisión se pide en la tienda. La aprueba un `owner` con su passkey y la manda el runner con las claves de la bóveda. `--wait` espera a que acabe y dice qué respondió la tienda.
+**`ias submit <build>`**: una build de tienda que acabó bien va a App Store Connect (con el Apple ID de `--asc-app-id`, de `submit.<perfil>.ios.ascAppId` o del que guardó `ias apps store --check` en la aplicación) o a Google Play (la pista de `--track`, de `submit.<perfil>.android.track` o `internal`), **como borrador por defecto** (D7, acotada por el plan 03): la revisión se pide en la tienda. En Android, `--release-status inProgress --rollout <1-99>` sirve un porcentaje y `--release-status completed` la sirve a todos, solo si la política de la pista lo permite; sin política, el servidor responde `release_policy_required` con el comando. `ias.json` › `submit.<perfil>.android.releaseStatus|rollout` propone lo mismo y cae a borrador con un aviso si la política no lo permite (un flag explícito, no). La aprueba un `owner` con su passkey y la manda el runner con las claves de la bóveda. Sin ningún Apple ID, `ias submit` falla antes de crear el envío con `asc_app_missing` y el comando que lo arregla. `--wait` espera a que acabe y dice qué respondió la tienda.
 
 **`ias version get|set`**: los últimos números de build por plataforma. `set --ios <n> --android <n>` o `set --from-app-json` (un `owner`) los fija, por ejemplo al traerlos de EAS; solo suben.
 
+**`ias releases` y `ias rollout`** (contrato en [docs/technical/manage-api.md](../../docs/technical/manage-api.md) §19 y [docs/technical/runner-api.md](../../docs/technical/runner-api.md) §6.2): el estado de cada pista de Google Play, su política y el movimiento de una release que ya está allí. `ias releases list` y `ias releases view <pista>` son **solo lectura** y no piden flags; `--refresh` encola un trabajo `release_status` que solo lee Play (sin passkey) y espera. `ias releases policy <pista>` enseña la política y, con `--mode`/`--max-percent`/`--step`/`--min-minutes`, la cambia un `owner` (el panel edita la misma). `ias rollout <pista>` sin flags solo lee y dice el siguiente paso; `--percent <1-99>`, `--halt`, `--resume [--percent]` y `--complete` crean un trabajo `release` con su passkey y **sin artefacto**, con el `versionCode` en el texto canónico. La política (techo, paso y espera) vive en el servidor; repetir el estado actual responde `{changed:false}` sin trabajo.
+
+**`ias testflight`** (contrato en [docs/technical/manage-api.md](../../docs/technical/manage-api.md) §18 y [docs/technical/runner-api.md](../../docs/technical/runner-api.md) §6.1): después de `ias submit --wait` en iOS, el build está en App Store Connect y Apple lo procesa. `ias testflight <build>` lo reparte a grupos de TestFlight que ya existen:
+- los grupos salen de `--groups` o de `submit.<perfil>.ios.testflight.groups` de `ias.json`; si no hay ninguno, el comando lee el estado, lista los grupos que la app tiene y da el comando exacto, sin crear nada;
+- el «What to Test» sale de `--what-to-test` con `--locale` (`es-ES` por defecto), de `--notes-file` (varios idiomas) o del mensaje de la build;
+- `--notify` avisa a los testers (apagado por defecto), `--dry-run` enseña el plan y no crea nada, y `--wait` sigue el trabajo;
+- el plan se aprueba con passkey y el runner lo aplica con la clave de App Store Connect de la bóveda. El servidor no ve el `.p8`.
+
+`ias testflight review <build>` es **otro comando y otra aprobación**: envía el build a Beta App Review, que solo necesitan los testers externos y que Apple puede rechazar. `ias testflight status <build>` solo lee: procesamiento (`PROCESSING`, `VALID`, `FAILED`), grupos, idiomas con notas, aviso y estado de la revisión. Los grupos, las notas y el estado viven en `testflight_builds`; los límites son de Apple (100 testers internos, 10.000 externos, 90 días por build, 6 envíos a revisión cada 24 h). Distribuir no envía a revisión: son dos decisiones.
+
 ### 6.1 Los dispositivos de quien prueba y las nuevas firmas
 
 Con el contrato de [docs/technical/manage-api.md](../../docs/technical/manage-api.md) §15 y [docs/technical/runner-api.md](../../docs/technical/runner-api.md) §11. Es lo que hacen `eas device:create` y `eas build:resign`.
@@ -367,6 +516,11 @@ Después, `ias migrate eas prepare`; en la carpeta que imprime, `EAS_NO_VCS=1 ea
 - `src/cli.mjs`: el enrutador.
   - Cada comando es una carpeta de `src/commands/` con un `index.mjs`, así que uno nuevo no toca el enrutador.
   - `vault`, `credentials` y `env` son de la pista 1D; `push`, de la 3B; `migrate`, de la 4D (`project.mjs`: la app y la carpeta de `prepare`; `eas-cli.mjs`: lo que se ejecuta y se lee de eas-cli; un fichero por paso); `build`, `builds`, `submit`, `version` y `vault approvers|grant|revoke`, de la 2C; `devices`, de la 4B (`asc.mjs`: la API de App Store Connect; `sync.mjs`: `ias devices sync`). `build/follow.mjs` (seguir y bajar), `build/source.mjs` (el commit y su tarball) y `build/profile.mjs` (el perfil resuelto) los comparten `build`, `builds` y `submit`; `vault/team.mjs`, los tres de confianza.
+- `src/setup.mjs` y `src/setup-state.mjs`: la checklist, sus pasos y el estado local (fuera del repositorio, sin
+  secretos). `src/provisioning.mjs`: el alta de los proyectos OTA y de distribución, la clave y los tokens;
+  `src/ota-key.mjs` hace la clave RSA y el certificado, y `src/op.mjs` los ítems de 1Password.
+- `src/commands/init/`, `src/commands/doctor/`, `src/commands/sdk/` y `src/commands/setup/`: la configuración, las
+  comprobaciones y la checklist de alta.
 - `src/config.mjs`: carga `ias.json` o los ficheros viejos.
 - `src/schema.mjs` y `schema/ias.schema.json`: el esquema y su validador.
 - `src/ota.mjs` y `src/dist.mjs`: lo que no necesita red. `src/http.mjs`: las peticiones.
@@ -389,6 +543,15 @@ No usan red real, claves reales ni 1Password: el certificado lo crea `openssl` e
 - `ias update` y `ias dist`, con las pruebas de `tools/` portadas;
 - `ias.json`: el esquema, el cargador y sus negativas, y lo que `ias update` toma de él cuando `app.json` lo deja al plugin de `@imagina-build/ias` (`test/config.test.mjs`);
 - `ias init` con la configuración de jscheduler-app y jero-invoices-app;
+- `ias setup` (`test/setup.test.mjs`): el estado fuera del repositorio, los servicios, la checklist completa, el bloqueo
+  de un paso mientras el anterior no está hecho, `ias init` dentro de `next`, los módulos de Expo del SDK, el paso
+  `services` creando el proyecto OTA con la clave y el token en 1Password, y las salidas para personas y `--json`;
+- `ias apps --create` y `--services` (`test/applications.test.mjs`), y `ensurePush` escribiendo `push.installKey`;
+- `ias update init`, `ias dist init`, `ias credentials generate android_upload_keystore`, `ias tokens create` y `ias runners code` (`test/provisioning.test.mjs`): la clave,
+  el certificado, el proyecto, el ítem de 1Password, `ias.json`, la idempotencia y `--dry-run`, sin que la clave ni el
+  token salgan en una salida ni en un argumento de `op`;
+- la skill de `.claude/skills/ias` (`test/skill.test.mjs`): su referencia de comandos es la que genera
+  `scripts/sync-cli-reference.mjs` a partir de `loadCommands`, y todos sus enlaces existen;
 - `ias doctor` con programas simulados;
 - `ias sdk install` y el SDK en `ias doctor` (`test/sdk.test.mjs`): el gestor de cada lockfile, de dónde sale el paquete, el plugin en `app.json` sin perder lo que había, lo que falta y cada estado del SDK, con un gestor de paquetes simulado;
 - los `.tgz` del CLI y del runner y la copia que se publica (`test/pack.test.mjs`): llevan `shared/` (el runner, también el validador de `ias.json`), funcionan sin el repositorio al lado, `ias build --local` encuentra el runner instalado junto al CLI, y la copia sale pública y sin `private`;

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@imagina-build/ias-cli",
-    "version": "0.2.2",
+    "version": "0.3.0",
     "description": "The command line of Imagina Application Services (IAS): ias.json, OTA updates, internal distribution and the checks of a project.",
     "type": "module",
     "bin": {

package/schema/ias.schema.json

@@ -491,13 +491,57 @@
                     "additionalProperties": false,
                     "properties": {
                         "ascAppId": {
-                            "description": "The Apple ID of the app in App Store Connect.",
+                            "description": "The Apple ID of the app in App Store Connect. It wins over the one saved in the application (ias apps store --check); leave it out to use that one.",
                             "type": "string",
                             "pattern": "^[0-9]+$"
                         },
                         "appleTeamId": {
                             "type": "string",
                             "pattern": "^[A-Z0-9]{10}$"
+                        },
+                        "testflight": {
+                            "description": "TestFlight after the submission (docs/plans/gaps/04-testflight.md §3.6): the groups ias testflight distributes to when no --groups is given, the «What to Test» by locale, and whether the testers are notified. Beta App Review is never sent by this: it is ias testflight review, with its own approval.",
+                            "type": "object",
+                            "additionalProperties": false,
+                            "properties": {
+                                "groups": {
+                                    "description": "The TestFlight groups by name, at most 20. They must exist in App Store Connect: IAS never creates one.",
+                                    "type": "array",
+                                    "maxItems": 20,
+                                    "uniqueItems": true,
+                                    "items": {
+                                        "type": "string",
+                                        "minLength": 1,
+                                        "maxLength": 100
+                                    }
+                                },
+                                "notes": {
+                                    "description": "The «What to Test» by locale: at most 8 locales of App Store Connect and 4000 characters each.",
+                                    "type": "object",
+                                    "maxProperties": 8,
+                                    "propertyNames": {
+                                        "enum": [
+                                            "ar-SA", "ca", "cs", "da", "de-DE", "el", "en-AU", "en-CA", "en-GB", "en-US",
+                                            "es-ES", "es-MX", "fi", "fr-CA", "fr-FR", "he", "hi", "hr", "hu", "id",
+                                            "it", "ja", "ko", "ms", "nl-NL", "no", "pl", "pt-BR", "pt-PT", "ro",
+                                            "ru", "sk", "sv", "th", "tr", "uk", "vi", "zh-Hans", "zh-Hant"
+                                        ]
+                                    },
+                                    "additionalProperties": {
+                                        "type": "string",
+                                        "minLength": 1,
+                                        "maxLength": 4000
+                                    }
+                                },
+                                "notify": {
+                                    "description": "Notify the testers when the build is added (off by default).",
+                                    "type": "boolean"
+                                },
+                                "betaReview": {
+                                    "description": "Advisory only: whether external testers are expected. It never sends the build to Beta App Review; that is ias testflight review.",
+                                    "type": "boolean"
+                                }
+                            }
                         }
                     }
                 },
@@ -525,6 +569,7 @@
                             "maximum": 1
                         },
                         "changesNotSentForReview": {
+                            "description": "Google Play: apply the commit without sending the release for review; a person sends it from Play Console (off by default).",
                             "type": "boolean"
                         }
                     }

package/shared/vault/index.mjs

@@ -581,3 +581,28 @@ export { PLAINTEXT_TYPES, PlaintextError, decodePlaintext, encodePlaintext, vali
 // The passkeys that may approve a store job, signed by the team with the same key (docs/technical/vault.md §2.4). approvers.mjs
 // imports this module; it only defines functions at its top level, so the cycle is safe either way it is entered.
 export { APPROVERS_FORMAT, APPROVER_ALGORITHMS, APPROVER_LIMITS, approverAlgorithm, approverFingerprint, approversText, signApprovers, validateApprovers, verifyApprovers } from './approvers.mjs';
+// The signed approval policy (ias-policy-1, docs/technical/vault.md §2.5): which passkeys approve which job and how
+// many. policy.mjs imports this module; it only defines functions at its top level, so the cycle is safe either way.
+export {
+  POLICY_FORMAT,
+  POLICY_LIMITS,
+  POLICY_FIELDS,
+  POLICY_PLATFORMS,
+  POLICY_TARGETS,
+  POLICY_TYPES,
+  DRAFT_SIGNATURE,
+  PLAY_TRACK,
+  isNotAfter,
+  jobOf,
+  policyHash,
+  policyText,
+  ruleAndSpecificityFor,
+  ruleFor,
+  signPolicy,
+  simulate,
+  specificityOf,
+  summary,
+  validatePolicy,
+  validatePolicyDraft,
+  verifyPolicy,
+} from './policy.mjs';