feat: co-version onto @propustka/* 0.0.6 (native auth, seeded provisioning key)

propustka is fully native now (it issues its own tokens, no Cloudflare Access),
published as @propustka/* 0.0.6. Roll vozka onto it:

- Pin bump ^0.0.5 → ^0.0.6 (config, core, worker).
- Drop reconcileAccess + AppAccess entirely — no CF Access edge to reconcile; per-path
  gates are runtime SDK config in each app. reconcileSchema auth { clientId, clientSecret }
  → { adminKey } (one px_ bearer); the plan loses its reconcile-access step.
- vozka-config drops the `access` field + the AppAccess/AccessAppDecl/AccessRule re-exports.
- Worker auth seam (src/iam.ts): IamClient.authenticate is gone → PropustkaAuth over the IAM
  binding (gates: service + human), with a vozka-synthesized dev-persona AuthContext for DEV.
  Set-Cookie (refreshed px_token) attached centrally in handleApi; 401 carries loginUrl.
- Collapse PROPUSTKA_CLIENT_ID/_SECRET → one PROPUSTKA_PROVISIONING_KEY across cli/runner/worker.
- @vozka/cli generates one px_ provisioning key + writes one Environment secret.

Stage 1 (deploying propustka itself from the platform pipeline) stays deferred to the account
bring-up — it also needs propustka's OIDC + signing config in the Environment.

typecheck + 208 tests + lint + format all green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01AYk5MFbQjvsWEsPZDeeHWa

Author: matej21

CLAUDE.md

@@ -1,15 +1,15 @@
 # vozka
 
 A deploy control plane for a Cloudflare Workers ecosystem. An app declares its full deploy surface
-— CF resources (`oblaka-iac`), propustka Access/authz, and a build pipeline — in one
+— CF resources (`oblaka-iac`), propustka authz (`schema`), and a build pipeline — in one
 `vozka.config.ts`; vozka provisions + deploys it (CLI today; control-plane Worker + dashboard).
 
 ## Tech Stack
 
 - **Bun** — runtime + workspaces. Libraries run TypeScript directly (`exports.bun` → `src`); no build step.
 - **TypeScript** strict, ESM (`"type": "module"`) everywhere.
 - **Cloudflare Workers** — Worker + Durable Objects + Containers + D1 + Queues + R2.
-- `oblaka-iac` (CF provisioning DSL), `@propustka/*` (Access edge + IAM), `@buzola/*` (SPA router).
+- `oblaka-iac` (CF provisioning DSL), `@propustka/*` (native auth + IAM, no Cloudflare Access), `@buzola/*` (SPA router).
 
 ## Commands
 
@@ -50,6 +50,10 @@ resource primitive and the propustka declaration types, so a `vozka.config.ts` n
 - **`oblaka-iac` resolves from npm, pinned to `^0.0.17`** (the first published version with the programmatic
   `deploy()` the engine calls). The old `file:../oblaka` override is gone. vozka + oblaka + propustka are a
   co-versioned suite — bump the pin deliberately (every package + the runner image's `docker/package.json`).
+  **`@propustka/* ^0.0.6`** is the native-auth model (propustka issues its own tokens, no Cloudflare Access):
+  `reconcileSchema({ adminKey })` is the only reconcile, `PropustkaAuth` is the request-auth front door,
+  the provisioning credential is one seeded `px_` key (`PROPUSTKA_PROVISIONING_KEY`). Bumping it again is a
+  suite-wide co-version.
 - **`config`, `core`, `worker`, `runner` relax exactly two strict flags** (`noUncheckedIndexedAccess`,
   `noPropertyAccessFromIndexSignature`) ONLY to tolerate oblaka's raw-TS source — `runner` joined the set
   when it began hosting `vozka-runner.config.ts` (the executor split), the same reason `worker` relaxes

MIGRATION.md

@@ -5,10 +5,10 @@ Cloudflare account — never one vozka spanning accounts (vozka is single-accoun
 
 ## Current state (today)
 
-| Account       | propustka | Apps deployed via `.github/workflows/deploy.yml`                                            |
-| ------------- | --------- | ------------------------------------------------------------------------------------------- |
-| **contember** | live      | **opice** (`deploy/prod` only), **poplach** (`deploy/prod`)                                  |
-| **mangoweb**  | live      | **poplach** (`deploy/mangoweb`), **revizor** (`deploy/mangoweb`, mangoweb-only — no opice)   |
+| Account       | propustka | Apps deployed via `.github/workflows/deploy.yml`                                           |
+| ------------- | --------- | ------------------------------------------------------------------------------------------ |
+| **contember** | live      | **opice** (`deploy/prod` only), **poplach** (`deploy/prod`)                                |
+| **mangoweb**  | live      | **poplach** (`deploy/mangoweb`), **revizor** (`deploy/mangoweb`, mangoweb-only — no opice) |
 
 revizor's `deploy.yml` carries a `deploy/prod → contember` target option, but it was never configured
 (only the `mangoweb` GitHub Environment exists, `REVIZOR_HOSTNAME = revizor.mgwsite.com`) — so revizor is

bun.lock

@@ -1,8 +1,12 @@
 # `@vozka/cli init` — per-account base bring-up (design)
 
-Status: **Phase A built** (`@vozka/cli`, `vozka init <account>`); **Phase B pending** the propustka refactor.
-Supersedes the `scripts/bootstrap-*.ts` wizard (kept as legacy until the CLI is proven). Decided 2026-06-26
-with the operator.
+Status (2026-06-27): **Phase A built** + **Phase B landed except Stage 1 wiring**. propustka native-auth is
+published (`@propustka/* 0.0.6`) WITH the seed-from-env primitive (`PROPUSTKA_PROVISIONING_KEY`); vozka is
+co-versioned onto it — `reconcileAccess`/`AppAccess` dropped, `reconcileSchema({ adminKey })`, the worker
+auth migrated to `PropustkaAuth`, the key collapsed to one `px_`, and `@vozka/cli` generates it. The ONE
+remaining Phase B item is **wiring Stage 1 (propustka's own deploy) into `platform.yml`** — deferred to the
+account bring-up (#24) because it needs propustka's OIDC + signing config provisioned into the Environment.
+Supersedes the `scripts/bootstrap-*.ts` wizard (kept as legacy until the CLI is proven). Decided 2026-06-26.
 
 ## Goal
 
@@ -59,32 +63,56 @@ by BOTH stages — no minting, no propustka checkout, no branch-mismatch.
 | **propustka (Stage 1)** | reads it from env and **idempotently upserts** it as an admin/provisioning credential at deploy — the machine analog of `PROPUSTKA_BOOTSTRAP_ADMINS`. _(= the seed-from-env primitive to add in the propustka refactor.)_ |
 | **vozka (Stage 2)**     | reads the **same** key and authenticates its `reconcileSchema`/`reconcileAccess` calls with it                                                                                                                            |
 
-### ⚠️ Key SHAPE is the one open item — depends on the new propustka auth model
-
-- **Old model:** `PROPUSTKA_CLIENT_ID` + `PROPUSTKA_CLIENT_SECRET` (Access service-token / client-credentials
-  pair). vozka reads both today.
-- **New model (refactor):** credentials are single `px_` bearer keys (`issueKey`/`mintFromKey`). Then the
-  provisioning key is likely **one `px_` token**, not an id/secret pair — e.g. env `PROPUSTKA_PROVISIONING_KEY`.
-  The CLI generates `px_<random>`; propustka Stage 1 upserts a credential whose hash = hash(token) under a
-  stable identity (so re-deploy is a no-op / rotation); vozka presents the token as a bearer.
-- **Co-version implication:** if provisioning auth collapses to a single key, vozka's `@propustka/client`
-  reconcile auth changes from `(client_id, client_secret)` to one key — that's part of the
-  `@propustka/* ^0.0.5 → ^0.0.6` bump (the co-versioned suite). Confirm the exact surface against the new
-  `@propustka/client`.
-
-**To finalize the seeded-key env contract + the vozka co-version change, I need:** the new propustka
-provisioning auth shape (single `px_` key vs id/secret), the seed-from-env env name propustka will read, and
-the `@propustka/client` reconcile auth signature in the new version.
+### Key SHAPE — RESOLVED (2026-06-27, against propustka `feat/propustka-native-auth`)
+
+- **Single `px_` bearer.** A propustka credential is ONE opaque `px_<random>` token (SHA-256-hashed in the
+  `credentials` table, plaintext returned once by `issueKey`). NOT an id/secret pair. So the provisioning key
+  is one token in **one** env var (proposed `PROPUSTKA_PROVISIONING_KEY`), not `PROPUSTKA_CLIENT_ID`/`_SECRET`.
+- **Reconcile auth = `adminKey` bearer.** `reconcileSchema({ url, app, schema, adminKey })` sends
+  `Authorization: Bearer ${adminKey}` (the `px_`). vozka passes the single provisioning key as `adminKey`.
+- **No `reconcileAccess` / no `AppAccess`.** CF Access is fully removed; the old `reconcileAccess` +
+  `AppAccess`/`AccessAppDecl`/`AccessRule` are DELETED from `@propustka/*`. Per-path gating is now `AppGates`,
+  **pure runtime SDK config consumed by `PropustkaAuth` in each app — NOT reconciled at deploy** and not a
+  vozka concern. So vozka's whole "reconcile access" step + the `access` field on `defineApp` go away.
+- **`IamClient.authenticate(request)` is gone** (caller resolution is now server-side `resolveCaller`); the
+  app-side request-auth surface is `PropustkaAuth`. vozka's control-plane worker auth must migrate to it.
+
+### The ONE missing primitive on the propustka side — seed-from-env
+
+propustka has `IAM_BOOTSTRAP_ADMINS` (admit a human by email at resolution time) but **no machine analog**:
+nothing reads a `px_` from env and admits it as a provisioning admin. Recommended (idiomatic, no DB writes):
+in `worker/src/auth.ts resolveCaller`, alongside the local-dev bypass + the bootstrap-admin email check, add a
+`PROPUSTKA_PROVISIONING_KEY` env — when a presented bearer's hash equals `hashToken(env)`, resolve a synthetic
+global-admin caller (`permissions: [{ action: '*', scope: null, source: 'bootstrap' }]`), no `credentials`
+row. Idempotent by construction (env compare), rotatable (change the env), no chicken-and-egg, no migration.
+
+**Still required from propustka before vozka Phase B can land:** (1) the seed-from-env primitive above;
+(2) bump `@propustka/core` + `@propustka/client` 0.0.5 → 0.0.6 and **publish** (the branch is unmerged,
+unpublished — vozka on `^0.0.5` still resolves the OLD model).
 
 ## Build phases + dependencies
 
 - **Phase A — propustka-agnostic CLI plumbing (buildable now).** `packages/cli` skeleton; `init` flow; CF
   token → account/zones; repo scaffold from templates; GitHub App (manifest flow, public-when-cross-org —
   already wired in `f58b910`); GitHub Environment + secrets/vars; `.env`; trigger. Treats the provisioning
   key as an opaque env value, so it needs nothing from propustka.
-- **Phase B — seeded key + propustka Stage 1 + vozka co-version (after the propustka refactor lands).**
-  Finalize the key shape; wire Stage 1 (propustka deploy + seed) into `platform.yml`; bump vozka's
-  `@propustka/*` pin + adapt reconcile auth; drop any temporary escape.
+- **Phase B — seeded key + propustka Stage 1 + vozka co-version (after propustka publishes 0.0.6).** This is
+  BIGGER than "finalize the key shape" — the native-auth refactor reshapes the whole reconcile + auth surface.
+  All of it is coupled to the `@propustka/* ^0.0.5 → ^0.0.6` bump (it won't typecheck against 0.0.5), so it
+  lands as one change:
+  1. **Drop `reconcileAccess` entirely** (`core/deploy.ts`, `core/runtime.ts`): no successor — gates are
+     runtime SDK config. Remove `ReconcileAccessError`, `AccessReconciler`, the access reconcile call.
+  2. **`reconcileSchema` auth** `{ clientId, clientSecret }` → `{ adminKey }` (one `px_` bearer).
+  3. **Config surface** (`vozka-config`): drop `AppAccess`/`AccessAppDecl`/`AccessRule` import + re-export and
+     the `access` field on `defineApp`; per-app configs (poplach/revizor) drop their `access` block.
+  4. **Worker auth seam** (`worker/iam.ts`): `IamClient.authenticate(request)` is gone → migrate to
+     `PropustkaAuth`; rework `BootstrapAdminAuthContext`/the guard.
+  5. **Key threading**: collapse `PROPUSTKA_CLIENT_ID` + `_SECRET` → one `PROPUSTKA_PROVISIONING_KEY` across
+     `core/cli.ts`, `runner/protocol.ts`, `worker/run-lifecycle.ts`, `worker/env.ts`.
+  6. **@vozka/cli**: generate one `px_` (not `{clientId, clientSecret}`); one Environment secret
+     `PROPUSTKA_PROVISIONING_KEY`; update `init.ts` + `templates/platform.yml` + README.
+  7. **Pin bump** `^0.0.5 → ^0.0.6` in every package.json + `docker/package.json`.
+  8. **Wire Stage 1** propustka deploy into `platform.yml` (propustka already ships a `vozka.config.ts`).
 
 ## Out of scope / later
 

docs/cli-init-design.md

@@ -25,8 +25,11 @@ the bring-up surface (it triggers CI, it does not deploy from the laptop).
   reuses external resources (GitHub App, vault key) instead of orphaning them.
 - **App visibility is DERIVED:** public iff any install repo is in a different org than the App's owner org
   (GitHub forbids a private App installing cross-org). Same-org stays private.
-- **The provisioning key is a SEEDED key (Phase B):** the CLI generates it; propustka Stage 1 will SEED it,
-  vozka Stage 2 USES it. No local-propustka mint. Until Phase B lands the account is intentionally not live.
+- **The provisioning key is a SEEDED `px_` key:** the CLI generates one opaque `px_` bearer
+  (`PROPUSTKA_PROVISIONING_KEY`); propustka (≥ 0.0.6) admits a bearer matching it as a synthetic admin
+  (`resolveCaller`), and vozka reconciles its schema with it. No local-propustka mint. Stage 1 (deploying
+  propustka itself from this pipeline) is deferred to the account bring-up — it also needs propustka's OIDC
+  and signing config in the Environment.
 - **`@vozka/core` owns the deploy.** This package never runs `wrangler`/oblaka/the engine — it triggers the
   scaffolded GitHub Actions pipeline, which calls `vozka platform deploy`.
 

packages/cli/CLAUDE.md

@@ -9,7 +9,7 @@
  * into `.env`, `gh` over stdin, and child env — never through `log.ts`.
  */
 
-import { randomBytes, randomUUID } from 'node:crypto'
+import { randomBytes } from 'node:crypto'
 import { findZone, listZones, resolveAccountId, verifyToken } from './cloudflare'
 import { fromEnv, persistEnv } from './envfile'
 import { configureEnvironment, triggerPlatformWorkflow } from './environment'
@@ -55,8 +55,7 @@ export async function runInit(account: string): Promise<void> {
 			VOZKA_VAULT_KEY: vaultKey,
 			GITHUB_APP_PRIVATE_KEY: app.pem,
 			GITHUB_WEBHOOK_SECRET: app.webhookSecret,
-			PROPUSTKA_CLIENT_ID: provisioning.clientId,
-			PROPUSTKA_CLIENT_SECRET: provisioning.clientSecret,
+			PROPUSTKA_PROVISIONING_KEY: provisioning,
 		},
 		vars: {
 			VOZKA_DOMAIN: collected.vozkaDomain,
@@ -146,31 +145,24 @@ async function ensureVaultKey(): Promise<string> {
 	return key
 }
 
-/** The provisioning key (vozka's propustka credential). */
-interface ProvisioningKey {
-	clientId: string
-	clientSecret: string
-}
-
 /**
- * Generate the operator-side provisioning key (the "seeded key"): random, stored once. Phase B wires
- * propustka Stage 1 to SEED it as an admin credential at deploy and vozka Stage 2 to USE it. Until then it
- * is a placeholder — the account is NOT live yet ("clean, wait for propustka"). An operator who already has
- * a key can pre-set PROPUSTKA_CLIENT_ID/_SECRET in env and it is reused verbatim.
+ * Generate the operator-side provisioning key (the "seeded key"): a single opaque `px_` bearer, stored
+ * once. propustka Stage 1 SEEDS it (the `PROPUSTKA_PROVISIONING_KEY` secret — `resolveCaller` admits a
+ * bearer matching it as a synthetic admin) and vozka Stage 2 USES it to authenticate schema reconciles.
+ * Shaped like a propustka-native key (`px_` + 160 bits base64url). An operator who already has one can
+ * pre-set `PROPUSTKA_PROVISIONING_KEY` in env and it is reused verbatim.
  */
-async function ensureProvisioningKey(): Promise<ProvisioningKey> {
-	step('Provisioning key (PROPUSTKA_CLIENT_ID / _SECRET)')
-	const id = fromEnv('PROPUSTKA_CLIENT_ID')
-	const secret = fromEnv('PROPUSTKA_CLIENT_SECRET')
-	if (id !== undefined && secret !== undefined) {
+async function ensureProvisioningKey(): Promise<string> {
+	step('Provisioning key (PROPUSTKA_PROVISIONING_KEY)')
+	const existing = fromEnv('PROPUSTKA_PROVISIONING_KEY')
+	if (existing !== undefined) {
 		ok('Reusing the provisioning key from .env (resume).')
-		return { clientId: id, clientSecret: secret }
+		return existing
 	}
-	const key = { clientId: randomUUID(), clientSecret: randomBytes(32).toString('base64url') }
-	await persistEnv('PROPUSTKA_CLIENT_ID', key.clientId)
-	await persistEnv('PROPUSTKA_CLIENT_SECRET', key.clientSecret)
+	const key = `px_${randomBytes(20).toString('base64url')}`
+	await persistEnv('PROPUSTKA_PROVISIONING_KEY', key)
 	ok('Provisioning key generated + saved to .env.')
-	detail('Phase B: propustka Stage 1 will SEED this; vozka uses it. Until then the account is not live (by design).')
+	detail('propustka Stage 1 seeds this as an admin credential; vozka Stage 2 reconciles with it.')
 	return key
 }
 

packages/cli/src/init.ts

@@ -30,9 +30,11 @@ To close the escape hatch once propustka grants you admin: set the `{{ACCOUNT}}`
 - Bump [`vozka.ref`](./vozka.ref) to a new `contember/vozka` commit/tag and push → redeploys the base.
 - Or _Actions → platform → Run workflow_ manually (build_runner_image stays false).
 
-## Stage 1 — propustka (Phase B)
-
-propustka is the authz root vozka depends on, so it belongs in this repo's pipeline. It's **not wired yet** —
-propustka's deploy is being refactored. Once it lands, Stage 1 deploys propustka here and **seeds** the
-operator-generated provisioning key (`PROPUSTKA_CLIENT_ID`/`_SECRET`) that Stage 2 uses — no minting, no
-local propustka checkout.
+## Stage 1 — propustka (deferred to the account bring-up)
+
+propustka is the authz root vozka depends on, so it belongs in this repo's pipeline. It is native-auth now
+and ships its own `vozka.config.ts`, so Stage 1 can deploy it here and **seed** the operator-generated
+provisioning key — the `PROPUSTKA_PROVISIONING_KEY` secret propustka admits as a synthetic admin (no minting,
+no local propustka checkout) and Stage 2 reconciles with. Wiring it needs propustka's own deploy config in
+this Environment (signing keys, OIDC secret + issuer/client, human email domains). Until then propustka
+deploys via its own repo pipeline; this Environment carries the shared `PROPUSTKA_PROVISIONING_KEY`.