Install lifecycle

All lifecycle steps are audited commands (see Commands); the admin's Eklentiler gallery is just a client of them.

1. Browse — the gallery lists listed first-party extensions by category. Never a price.
2. Consent — a Mozaik-owned screen shows the manifest's scopes with Turkish labels from the platform scope registry (KVKK-sensitive scopes highlighted) and the pii.purposeTR statement with the number of buyer fields the extension will receive.
3. Install — extension.install creates the store's row DISABLED, pins version + a manifest_snapshot, and grants the scopes verbatim. Sandbox-runtime manifests are refused until P2 (ADR 0027).
4. Configure — extension.configure stores the config after server-side Zod validation and normalization (defaults applied, IBANs canonicalized). The admin form is generated from the manifest's JSON Schema. Secrets go through secret.set (write-only; sandbox prefix enforced while config.mode !== "live").
5. Enable — extension.enable requires every required secret present and a valid config, enforces one enabled extension per methodId, and stamps the snapshot. Enable/disable/configure bump the store's catalog generation because payment capabilities and checkout CSP origins project into cached storefront HTML.
6. Upgrade — extension.upgrade moves the pinned version to the platform's current manifest after re-validating the stored config. Never silent.
7. Uninstall — two-step: extension.disable first, then extension.uninstall. The row is deleted; the config is archived in the command's audit result; secrets are KEPT (merchant-owned credentials — secret.delete is explicit); app.{vendor}.* metafields are kept (orders reference them).

A fresh store seeds exactly one row: the unlisted mozaik.flat-shipping floor, installed but disabled, enabled by the merchant's first "Kargo ücreti" save.