@vectros-ai/cli 0.16.0 → 0.20.0

package/AUTHORING.md

@@ -69,6 +69,16 @@ A name must be 2–50 chars: a lowercase letter, then lowercase letters / digits
    `dataScope: {}` when a shared/tenant-wide resource is what you intend
    (warnings — they print but don't fail).
 
+   A schema may also declare `expectedScopeDims` — the ownership dimensions
+   its records are typically scoped by, e.g. `expectedScopeDims: [org,
+   client]`. Purely advisory (never sent to the platform, never runtime-
+   enforced): it lets the lint warn when a role/`accessProfile` clause grants
+   `r`/`u`/`d` on that typeName (via a type-qualified action like
+   `records:r:case`) but its `dataScope` names only SOME of the declared
+   dims — reads never require full-dimension coverage the way creates do, so
+   a clause naming one of two declared dims silently leaves the other
+   unconstrained. Omit the field entirely and this lint never fires.
+
 `validate` accepts a file path **or** a bundled blueprint name.
 
 ### 3. `plan` — preview before you mint
@@ -87,6 +97,30 @@ A name must be 2–50 chars: a lowercase letter, then lowercase letters / digits
     + seed 1 record(s)
 ```
 
+**A blueprint whose `accessProfile` composes roles (`roleIds:`) previews every
+composed role's clauses individually**, not flattened, because two clauses
+sharing an action set can still carry different `dataScope`:
+
+```
+  Plan for blueprint 'my-thing' (v1.0.0) → context 'mcp':
+    + schema 'thing' (2 fields, HYBRID) lookup: [externalId]
+    + context 'mcp' (MCP — my-thing)
+    + principal 'my-thing-sp' (SERVICE)
+    + role 'case-handler' (1 clause, actions [records:cru])
+      clause 1: actions [records:cru], dataScope: scope:org=[${{ self.scope.org }}]
+    + role 'hr-admin' (1 clause, actions [records:r])
+      clause 1: actions [records:r], dataScope: (none — unconstrained)
+      assumable: scope:org=[org_engineering, org_sales]
+    + profile via role(s) [case-handler, hr-admin] (composed — each role's own clauses, concatenated in order)
+    + key my-thing-<machine> (mint 1 scoped ssk_*)
+    + seed 1 record(s)
+```
+
+A role's `assumable` line only appears when the blueprint's top-level
+`roleAssumable:` map names that role — it's shown because it's
+security-relevant (what a holder of the role may become via `POST
+/v1/auth/token/assume`), not just that the role was declared.
+
 `bootstrap` shows the same plan and asks for confirmation before minting
 (`--yes` skips the prompt for CI/agents). ⚠️ **`--no-merge` is NOT a dry run** — it still
 mints/reconciles for real; it only changes where the resulting credential goes, printing the MCP
@@ -172,8 +206,19 @@ accessProfile:
   # capabilities: [member-lifecycle]
   # A SEPARATE gated dimension from allowedActions — named platform effects a
   # resource:ops verb can't express (e.g. creating/removing an identity in
-  # your tenant). Only 'member-lifecycle' is admitted today; every other name
-  # is hard-rejected, same posture as the scope gate. See "Capabilities" below.
+  # your tenant). 'member-lifecycle' and 'delegate-principal-stamp' are
+  # admitted today; every other name is hard-rejected, same posture as the
+  # scope gate. See "Capabilities" below.
+  #
+  # Instead of allowedActions (+ optional dataScope/capabilities), accessProfile
+  # may declare `roleIds: [<roleId>, ...]` — one or more roles declared below,
+  # in `roles:`, composed additively (each role's own clauses, concatenated in
+  # the order listed; a single roleId is equivalent to the platform's
+  # deprecated singular roleId reference). Mutually exclusive with allowedActions; a roleIds-
+  # composed profile has no inline clause of its own, so dataScope/capabilities
+  # are rejected alongside it — author those on the referenced role instead:
+  # accessProfile:
+  #   roleIds: [case-handler, hr-admin]
 
 roles:
   # Optional. Reusable, identity-agnostic access rules — DISTINCT from
@@ -247,14 +292,20 @@ namespaces:
     membershipTargetField: userId
     membershipLevelField: level        # optional; membershipLevels required alongside it
     membershipLevels: [admin, viewer]
+    # tenantWide: true          # optional, default false. Requests registration visible to
+    #                           # EVERY context in the account, not just this blueprint's own —
+    #                           # see below.
     # Registered in the SAME bootstrap-token phase as issuers, before schemas.
-    # Always owned by this blueprint's own contextId (above) — there is no
-    # tenant-wide option, since the platform confines namespace registration to
-    # the credential's own context unconditionally, even for a tenant-wide
-    # request. Registration is create-once, NOT idempotent server-side: a
-    # re-apply matching every declared field converges silently, but one that
-    # disagrees with what's already registered fails the apply rather than
-    # silently overwriting it.
+    # Owned by this blueprint's own contextId (above) by default. `tenantWide: true` opts
+    # out of that, but declaring it is not enough on its own: the applying credential must
+    # separately hold OWNER-only authority, and `bootstrap`/`apply` refuse to even request
+    # it without the explicit `--allow-tenant-wide-namespaces` flag — a blueprint cannot make
+    # this happen by itself. Registration is create-once, NOT idempotent server-side: a
+    # re-apply matching every declared field converges silently, but one that disagrees
+    # with what's already registered fails the apply rather than silently overwriting it —
+    # for a tenant-wide namespace this includes a collision with a DIFFERENT blueprint's
+    # (or a manual) registration of the same name, which always fails rather than being
+    # silently adopted.
 
 identities:
   team:                       # local name — referenced elsewhere as ${{ identities.team }}
@@ -267,10 +318,15 @@ identities:
     # digit (demoOrg, not demo-org) — the same grammar '${{ identities.<name> }}'
     # itself can match. A name outside it is rejected as a parse error at
     # declare time (validate/plan), not silently accepted. Every declared
-    # identity is ensure-exist'd (idempotent by
-    # externalId), whether or not anything below references it, in its OWN
-    # creds-bearing pass — tenant-wide, under the bootstrap credential, BEFORE
-    # either loader phase (not in BLUEPRINT_FIELD_PHASES for that reason).
+    # identity is ensure-exist'd (idempotent by externalId), whether or not
+    # anything below references it, in its OWN creds-bearing pass — under the
+    # bootstrap credential, AFTER the app-context, service principal, and any
+    # namespaces: above are registered, but BEFORE schemas/accessProfile/roles
+    # (not in BLUEPRINT_FIELD_PHASES for that reason). This ordering matters
+    # for a non-'user' kind: an 'org'/'client'/registered-namespace identity is
+    # created IN that namespace, so it can only succeed once the namespace
+    # exists — declare it in namespaces: above (or ensure it's already
+    # registered) before referencing it here with a non-'user' kind.
     # Reference the resolved principal id anywhere one is valid — a schema's
     # userId/scopes, an accessProfile/role dataScope or identityOverrides,
     # seed-record ownership — e.g.:
@@ -411,10 +467,10 @@ boundary, not the file.
 An `accessProfile` or role clause may also declare `capabilities: [...]` —
 named platform effects (like creating or removing an identity in your tenant)
 that a `resource:ops` scope token can't express. This rides its own field,
-separate from `allowedActions`, and has its own allowlist: **only
-`member-lifecycle` is admitted today.** Every other capability name —
-including ones the platform's own registry recognizes — is refused, the same
-fail-closed, deliberately-narrow posture as the scope gate above. `validate`,
+separate from `allowedActions`, and has its own allowlist: **`member-lifecycle`
+and `delegate-principal-stamp` are admitted today.** Every other capability
+name — including ones the platform's own registry recognizes — is refused,
+the same fail-closed, deliberately-narrow posture as the scope gate above. `validate`,
 `plan`, `blueprint-test` and `bootstrap` all report a rejected capability the
 same way they report a rejected scope: nothing mints, and the CLI exits
 non-zero.

package/CHANGELOG.md

@@ -3,6 +3,338 @@
 All notable changes to `@vectros-ai/cli` are documented here.
 This project adheres to [Semantic Versioning](https://semver.org).
 
+## 0.20.0 — 2026-08-27
+
+### Added
+
+- **The capability gate now admits `delegate-principal-stamp`**, alongside the
+  existing `member-lifecycle`. Grantable on an `accessProfile` or role clause's
+  `capabilities: [...]`, same as before — a blueprint can now let an admin
+  role create a membership-shaped record on behalf of a known third-party
+  user, once the clause authorizing the write also explicitly names `userId`
+  in its own `dataScope` (the capability itself may be granted on a
+  different clause of the same role, e.g. via a separately-composed
+  `roleIds` entry — only the write's own verb + `userId` admission must be
+  co-located). Bounded by the SAME app context and record type the clause's
+  `dataScope` already confines the write to — unlike `delegate-mint`/
+  `forensic-read`/`context-directory-read`, this is not tenant-wide, and
+  (like `member-lifecycle`) it is self-signup-eligible.
+- **`vectros identity list-all`** — lists every user in the tenant, for the one
+  recovery case `identity list` can't reach: a user created but never granted
+  access anywhere (the gap between creating a principal and binding it to a
+  context). `identity list` is scoped to the caller's own context by design —
+  a user with no access grant at all is invisible there no matter how many
+  times a create is retried, since a retry with the same `--external-id` just
+  collides with the same invisible row. `list-all` authenticates with your own
+  login session (an account owner) instead of a context-scoped credential, so
+  it can see every user regardless of context. Supports `--external-id`,
+  `--tenant`, `--limit`, and `--json`, matching `identity list`'s conventions.
+- **`vectros blueprint validate`/`plan`: new advisory lint —
+  `partial-datascope-dimension-coverage`** (needs `@vectros-ai/blueprints` ≥
+  0.17.0). Warns when a role/`accessProfile` clause grants `r`/`u`/`d` on a
+  typeName (e.g. `records:r:case`) whose schema declares
+  `expectedScopeDims`, but the clause's `dataScope` names only SOME of those
+  dims — the missing dimension(s) are silently unconstrained for that grant,
+  since reads (unlike creates) never require full-dimension `dataScope`
+  coverage. Opt-in: a schema with no `expectedScopeDims` declared never
+  trips it, and it never fires on an untyped (bare `records:r`) grant.
+  Never runtime-enforced — pure authoring-time visibility into a choice
+  that's easy to make by omission rather than intent.
+- **`bootstrap`/`blueprint-test` now catch a FRESH (first-apply) seed index
+  failure, not just a re-apply's.** A seed create's response always carries
+  `PENDING_INDEX` on a first apply (indexing runs async, after the
+  response), so the existing `seedIndexFailures` summary previously only
+  ever saw a terminal `FAILED` on a later idempotent re-apply — a
+  newly-bootstrapped demo whose seeds failed to index looked silently empty
+  in search/RAG until the operator happened to re-run bootstrap. Every seed
+  still `PENDING_INDEX` after seeding is now re-checked with a bounded,
+  concurrent, best-effort poll (default: 3 attempts, 500ms apart, ≤ ~1.5s
+  added to the happy path) and folded into the same run-summary warning if
+  it settles to `FAILED` within the bound. Deliberately NOT a guarantee — a
+  seed still `PENDING_INDEX` when the bound is exhausted stays silent, so a
+  genuinely slow index (reconcile/quarantine can stall for minutes) never
+  turns a one-shot provisioning command into an unbounded wait.
+- **`vectros issuers` gains `register`/`update`/`delete`** — previously
+  read-only (`list`/`get`). Closes the gap where adding a second IdP, or
+  editing one issuer's `selfSignupPolicies` after initial setup, required
+  hand-authoring a blueprint `issuers:` block and re-running a full apply.
+  `register` is idempotent by issuer id (a repeat returns the existing
+  registration unchanged, not an error); `update` only ever sends the safe,
+  mutable fields (`subClaim`/`emailClaim`/`userinfoUri`/`status`/
+  `selfSignupPolicies`) — trust-anchor fields stay immutable via this route,
+  matching the platform; `delete` uses the same re-type-the-id confirmation
+  as `context destroy` (`--force` for non-interactive use), and is refused
+  server-side while any user is bound through the issuer. All three accept
+  `--tenant test|live` (like their `list`/`get` siblings) so a context
+  living in the `test` tenant is reachable, not just `live`.
+- **New `vectros namespace` command group: `register`/`list`/`get`.**
+  Registering a brand-new scope namespace (e.g. a `practice`/`team` entity
+  dimension) was blueprint-apply-only before this; there was also no way to
+  discover which namespaces already exist without already knowing their
+  names. `register --entity-backed` is what makes a namespace a real
+  identity-entity dimension that `identity create --type <name>` can create
+  entities in. No `update`/`delete` verbs — both are gated to a genuine root
+  API key on the platform side with no provisioning-capability door, so
+  neither could ever succeed for any credential the CLI holds (documented in
+  the command's own module header).
+- **`role create` gains `--assumable <json>`** — a role-level `vectros
+  assume` entitlement grant (JSON map of `scope:<namespace>` → allowed
+  values), previously blueprint-`roleAssumable:`-only. Independent of
+  `--data-scope`: holding broad data-scope reach in a namespace does not by
+  itself grant assuming any value in it.
+- **New `vectros assume --context <c> --scope <ns:value>...`** — re-mints
+  the caller's own verb token with one or more `identity.<namespace>` values
+  switched (`POST /v1/auth/token/assume`), for a caller whose role
+  explicitly grants assuming those values. The CLI's first standalone
+  command reaching this endpoint; entitlement is checked live against the
+  caller's current roles, never a copy frozen into a token at mint time. No
+  `--to-keyring` — the response is an ephemeral bearer token with the same
+  remaining lifetime as the verb token this command itself mints to make the
+  call, not a durable secret.
+
+### Changed
+
+- **`runLoader`'s `provisioned` is now REQUIRED — the self-provisioning
+  fallback is gone.** Internal hardening only, no CLI-facing behavior
+  change: every real caller (`vectros bootstrap`, `blueprint-test`) already
+  always ran `provisionContext` first and passed the result in, so the
+  fallback branch was dead in production. Removing it makes the
+  `provisionContext` → (apply-time identity resolution) → `runLoader`
+  ordering structurally required instead of convention-enforced — a future
+  caller can no longer reproduce the ordering bug the original fix
+  closed by skipping the split. `allowTenantWideNamespaces` and
+  `confirmExistingPrincipal` moved with it: both now live only on
+  `provisionContext`'s own input, where their actual checks have run since
+  that original fix — `runLoader`'s own copies of both parameters were already dead
+  plumbing before this change.
+- **Apply-time identity resolution now REQUIRES `provisionContext`'s result.**
+  Internal hardening only, no CLI-facing behavior change. Closes the other
+  half of the ordering gap above: `runLoader` already required
+  `provisionContext`'s output, but the step between them — resolving a
+  blueprint's declared `identities:` — took a bare client with nothing tying
+  it to `provisionContext` having run first, so a caller could still
+  reproduce the original ordering bug (a non-`user` identity in a namespace
+  the same blueprint also registers racing that registration) with no
+  compiler signal. It now derives which client to use internally instead of
+  each caller doing so independently.
+
+### Fixed
+
+- **`bootstrap`'s post-merge hint is now blueprint-specific, and `--client
+  code` always shows the `claude mcp add` command.** The restart hint used to
+  read "list my tasks" / "add a task to …" for EVERY blueprint (a leftover
+  from when only `task-management` existed) — it now names the actual
+  blueprint applied. The `claude mcp add` line (the idiomatic Claude Code
+  install path) used to print only on `--no-merge` / a declined / a failed
+  merge — a successful auto-merge silently hid it; it's now shown there too.
+- Scrubbed internal issue/MR references, review-process citations, and
+  backend class names out of `packages/cli`'s comments — visible in the
+  published npm package's sourcemaps to anyone who reads mapped source.
+  Comment-only; no behavior change.
+- **Keyring secret-store hardening.** A 0-byte salt file removed by
+  something else mid-poll (a concurrent cleanup, a manual delete of the
+  crash remnant) used to throw a raw `ENOENT` out of `setSecret`; it now
+  restarts salt creation instead, since nothing was ever encrypted under an
+  empty salt in the first place. Also fixed an order-dependent assumption
+  in two `keyring prune` tests (they now pin the processing order they
+  depend on, so a future ordering change fails with a diagnosable message
+  instead of a confusing downstream one).
+
+### Changed
+
+- Bundled `@vectros-ai/sdk` refreshed to the current release's staging build.
+
+## 0.19.0 — 2026-08-27
+
+### Added
+
+- **`vectros bootstrap`/`blueprint apply` mint a blueprint's own AccessProfile
+  from `accessProfile.roleIds`** (needs `@vectros-ai/blueprints` ≥ 0.16.0) —
+  the platform's additive role composition, wired end to end. Roles are
+  created BEFORE the AccessProfile mint (reordered from the prior sequence,
+  where nothing depended on the order), so a `roleIds` reference always
+  resolves on first apply. `vectros blueprint plan` previews the composed
+  form (`profile via role(s) [...]`), and the scope gate / footgun lints /
+  `blueprint-test` harness assertions all read the composed action set —
+  every referenced role's own clauses, concatenated in order — for a
+  `roleIds` profile instead of the (now-absent) inline `allowedActions`.
+- **`vectros access grant --role` and `vectros join --role` are now
+  repeatable — 2+ roles compose additively**, sending the platform's
+  `roleIds` (plural) instead of the deprecated singular `roleId`. `access
+  get`/`access list` render the composed role list; `access explain` now
+  fetches and concatenates every referenced role's clauses instead of only
+  the first (a profile composing 2+ roles previously rendered as "no
+  clauses" — the singular `roleId` the old code followed is absent once a
+  profile composes more than one). A single `--role` still round-trips
+  through the deprecated singular field on an older server response.
+- **An already-registered issuer now actually reconciles on a blueprint
+  re-apply** (needs `@vectros-ai/sdk` ≥ 0.41.0 for the
+  platform's `PUT /v1/auth/issuers/{issuerId}`) — `subClaim`/
+  `emailClaim`/`userinfoUri`/`selfSignupPolicies` now apply on re-apply, the
+  same create-then-reconcile shape the AccessProfile mint already used. The
+  trust-anchor/routing-pin fields (`issuer`/`jwksUri`/`audience`/`contextId`)
+  remain immutable via that route (rotating one still needs delete +
+  re-register), and `status` is reconcilable on the platform endpoint but has
+  no field in `BlueprintIssuerSchema` to author — `vectros blueprint plan`'s
+  legend and the apply-outcome summary both say so explicitly rather than
+  overclaiming full reconciliation.
+  **Behavior change:** editing a trust-anchor field (`issuer`/`jwksUri`/
+  `audience`/`contextId`) on an already-registered issuer and re-running
+  `bootstrap` now FAILS the whole run with the platform's 400, instead of
+  the prior silent no-op (the edit was simply never applied). This is the
+  correct direction — the loader stopped lying about it — but it is a
+  disclosed behavior change: a blueprint whose issuer trust anchor
+  drifted from its live registration will now block on re-apply where it
+  previously succeeded quietly.
+- **A blueprint can now declare `issuers[].userinfoUri`** (needs
+  `@vectros-ai/sdk` ≥ 0.41.0, `@vectros-ai/blueprints` ≥ 0.16.0) — the IdP's
+  OIDC userinfo endpoint, used as a fallback email-resolution source when a
+  presented access token doesn't carry the configured `emailClaim` directly.
+  Lets a blueprint declare this server-side fallback instead of requiring a
+  manual `PUT /v1/auth/issuers/{issuerId}` outside blueprint authoring.
+  `vectros issuers get` now renders it alongside the other issuer fields.
+- **`vectros identity invite --context <c> --role <roleId> --email <e>`** —
+  onboards a person into a context (`POST /v1/users/invite`) without a
+  hand-crafted `curl` call. `--role` resolves directly to
+  `accessProfile.roleId` (a Role's id is already its own user-facing
+  identifier — no separate name lookup). `--accept-url` is required unless
+  `--no-send-email` is given, in which case the response's raw
+  `inviteToken`/`acceptLink` let you deliver the invitation yourself.
+  Authorizes exactly like `access grant`/`role create` — an ordinary
+  context-pinned token minted from your `vectros login` session, not a root
+  key. No separate setup needed.
+
+### Fixed
+
+- **`createRole` (the loader's role mint) now sends `upsert: true`** — without
+  it, an already-existing role's `scopes` were silently left unchanged on a
+  blueprint re-apply, so editing a role's `allowedActions`/`dataScope` and
+  re-running `bootstrap` never actually took effect, contradicting
+  `LoaderResult.roleActions`' own documented "reconciled means updated to
+  match" contract (the same false-convergence class this release fixes for
+  issuers). Pre-existing, caught in review while building `roleIds`
+  composition — now more consequential than before, since a `roleIds`-
+  composed AccessProfile ties the blueprint's own automatic service
+  credential to a role's live (previously possibly-stale) scope.
+- **The bootstrap loader's scope gate now admits an unqualified `profiles:c`
+  when the same clause also declares `capabilities: [member-lifecycle]`** —
+  the platform's own documented pattern for a self-signup/admin role that
+  invites without raw tenant-wide `users:*` could not previously be
+  authored through `vectros blueprint apply`/`validate` at all: the gate's
+  action check and its capability check ran fully independently, so a bare
+  `profiles:c` always rejected regardless of what capabilities accompanied
+  it. The exception is narrow and additive — bare form only (a literal
+  qualifier like `profiles:c:usr_<id>` is still rejected unconditionally,
+  since `member-lifecycle`'s own elevation requires the fully unqualified
+  grant and does nothing to bound a literal-principal risk), same clause
+  only (a sibling clause's capability grants no benefit), every
+  pre-existing call site unaffected (the new parameter is optional).
+- **`vectros blueprint validate`/`bootstrap`/`apply` no longer reject `${{ member.scope.<namespace> }}`
+  (and its `:<level>` form) as an unrecognized placeholder.** This is a real, shipped, server-side
+  mechanism — resolved per request from `org_membership`-shaped records, with no dependency on a
+  separate, unimplemented token-select step that `${{ self.scope.<ns> }}` needs — the CLI's local
+  lint simply hadn't been updated to recognize it, so an otherwise-correct blueprint authored
+  against it failed `validate` outright with a false `datascope-unknown-placeholder` error, even
+  though the platform itself would have accepted it. Found building a real org-membership-based
+  blueprint: a role's `${{ self.scope.org }}` dataScope silently granted nothing (an unresolved
+  self-placeholder matches nothing, not everything) because nothing populates that identity value
+  by default — switching to `${{ member.scope.org }}` is the actual fix for an org_membership-based
+  role, and the lint was wrongly in the way of it.
+- **`vectros access explain` now reports `${{ member.scope.<ns>[:<level>] }}` as undecidable** instead
+  of silently mismodeling the clause as an opaque literal string — the clause normalizer had no MEMBER
+  case at all before this. Same treatment `${{ under.self.* }}` already gets, via `undecidableDims`
+  rather than a false match or a silent denial.
+
+### Changed
+
+- **`@vectros-ai/sdk` repinned to the latest available `0.41.0` build** —
+  picks up the additive role composition's `roleIds` on
+  `AccessProfileRequest`/`AccessProfileResponse` and the issuer-update
+  surface (`IssuerUpdateRequest`, `client.auth.updateIssuer`). No other wire
+  shape changed since the prior pin (verified against the published
+  tarballs, not just source ancestry).
+
+## 0.18.0
+
+### Added
+
+- **`vectros blueprint plan` now renders the fully-expanded, effective
+  per-clause `dataScope` for every declared role** (needs
+  `@vectros-ai/blueprints` ≥ 0.15.0) — not just the role's flattened action
+  set. This is the review-legibility mitigation the `fragments:`/
+  `dataScopeRef` sugar requires: a clause referencing a fragment has already
+  been expanded to a literal `dataScope` by the time the CLI sees it, so the
+  plan shows exactly what will be granted, never the DSL indirection that
+  produced it. Two clauses sharing an action set can legitimately carry
+  different `dataScope`, so this is shown per clause, not flattened across
+  the role the way the action set is.
+- **A blueprint's `roleAssumable` map is now wired through
+  apply** — `vectros bootstrap`/`blueprint apply` passes
+  `roleAssumable.<roleId>` straight through to that role's `createRole`
+  call as `assumable`, unchanged. `vectros blueprint plan` discloses the
+  grant per role (a security-relevant fact the operator approving the plan
+  needs to see, same reasoning as the existing capability disclosure), and
+  `vectros role get`'s human view now shows a role's `assumable` grant
+  (`--json` already did — it prints the SDK response verbatim). Needs
+  `@vectros-ai/blueprints` ≥ 0.15.0 and `@vectros-ai/sdk` ≥ 0.41.0 (the
+  first generated SDK build carrying `Role.assumable`).
+
+## 0.17.0
+### Added
+
+- **`vectros issuers list --context <ctx>` and `vectros issuers get <issuerId>
+  --context <ctx>`** — read a tenant's registered token-exchange issuers
+  without hand-minting a bootstrap token first. `GET`/`LIST /v1/auth/issuers`
+  require provisioning capability AND are context-confined for any non-root
+  caller, so `--context` is a required flag, not a default: a provisioning
+  token minted with no context pin resolves to the platform's `default`
+  context and won't see an issuer registered under any other one. Both verbs
+  now mint a single st_* carrying provisioning capability PINNED to
+  `--context` — a shape the CLI's auth seam couldn't produce before this.
+- **A blueprint's `namespaces[]` entry can declare `tenantWide: true`** (needs
+  `@vectros-ai/blueprints` ≥ 0.14.0), requesting the platform's tenant-wide
+  registration form instead of the blueprint's own context. `bootstrap`/`apply`
+  now REFUSE such a blueprint before anything provisions — naming the
+  namespace(s) — unless invoked with the new `--allow-tenant-wide-namespaces`
+  flag: a static, scriptable opt-in, deliberately not an interactive runtime
+  prompt. This is the human-deliberateness check only; whether the request
+  actually succeeds is still decided server-side by an OWNER-gated platform
+  capability the flag has no bearing on — a non-OWNER credential gets the
+  existing clear failure regardless of the flag. An ordinary blueprint (no
+  `tenantWide` namespace) is completely unaffected.
+- **`vectros blueprint plan`'s namespace preview names a `tenantWide` namespace
+  explicitly** (`TENANT-WIDE — visible to every context`, in place of the usual
+  `owned by '<contextId>'`), and its legend gains a carve-out: unlike an
+  ordinary namespace registration (which converges silently on a matching
+  re-apply), a tenant-wide one never adopts an existing registration, even an
+  exact field-for-field match — a collision always fails.
+
+### Changed
+
+- **A namespace-name collision on a `tenantWide` registration is always a hard
+  failure, never adopted.** The existing read-back-and-reconcile behavior for
+  an ordinary, context-owned namespace (a re-apply matching every declared
+  field converges silently) does NOT extend to a tenant-wide one: a tenant-wide
+  row is co-owned by no single blueprint, so a field-for-field match is not
+  evidence it's safe to treat as "this blueprint's" — it could just as easily
+  be a different blueprint's (or a manual) registration that happens to declare
+  the same shape. The platform's 400 propagates as-is on any collision.
+
+### Fixed
+
+- **`bootstrap`/`apply` now register a blueprint's `namespaces[]` BEFORE
+  creating any identity it declares in `identities[]`.** Previously, apply-time
+  identity resolution ran before namespace registration, so a blueprint
+  declaring `identities:` in a namespace it ALSO registers via `namespaces:`
+  could never succeed — creating that identity requires the namespace to
+  already be registered, and the old ordering always raced the identity create
+  ahead of it. The app-context, service principal, and every declared
+  namespace are now fully provisioned first; identity resolution (and
+  everything downstream) runs after. This is a step-ordering change only — an
+  unaffected blueprint (no `identities:` referencing a namespace it also
+  registers) sees no behavior change, and no CLI flag or blueprint schema
+  changed.
+
 ## 0.16.0
 
 ### Added