@nebulr-group/bridge-cli 0.6.0-beta.2 → 0.6.0-beta.4

package/dist/prompts/mechanisms.md

@@ -0,0 +1,284 @@
+# How Bridge works — the mechanisms and the levels
+
+One page for the rules every Bridge guide builds on. Read it before you write code against a limit, an upgrade prompt or a restyled sign-in page. The per-framework guides (`bridge guide svelte`, `bridge guide nestjs`, …) say *which file*; this page says *why it works* and *which level to pick*.
+
+The examples use the SvelteKit frontend (`@nebulr-group/bridge-svelte`) and the NestJS backend (`@nebulr-group/bridge-nestjs`), the two plugins with this surface today.
+
+## The whole integration
+
+What a developer's repo holds once Bridge is in. Nothing else is required; every other page Bridge needs, it serves.
+
+**Frontend (SvelteKit) — 15 lines in four files, plus one line of `.env`:**
+
+```env
+# .env
+VITE_BRIDGE_APP_ID=your-app-id
+```
+
+```ts
+// src/routes/+layout.ts
+import { bridgeBootstrap } from '@nebulr-group/bridge-svelte';
+export const ssr = false;
+export const load = bridgeBootstrap({ rules: [{ match: new RegExp('^/auth($|/)'), public: true }] });
+```
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script lang="ts">
+  import { BridgeBootstrap } from '@nebulr-group/bridge-svelte';
+  import '@nebulr-group/bridge-svelte/styles';
+  let { children } = $props();
+</script>
+<BridgeBootstrap>
+  {@render children()}
+</BridgeBootstrap>
+```
+
+```svelte
+<!-- src/routes/auth/[...bridge]/+page.svelte — every sign-in page -->
+<script lang="ts">
+  import { BridgeAuthRoutes } from '@nebulr-group/bridge-svelte';
+</script>
+<BridgeAuthRoutes />
+```
+
+With plans, one more four-line file serves the subscription page, the paywall and both checkout return pages:
+
+```svelte
+<!-- src/routes/subscription/[...bridge]/+page.svelte -->
+<script lang="ts">
+  import { BridgeBillingRoutes } from '@nebulr-group/bridge-svelte';
+</script>
+<BridgeBillingRoutes />
+```
+
+**Backend (NestJS) — 4 lines, plus one line of environment.** The lines marked `// +` are Bridge's; the rest is what `nest new` already gave you:
+
+```env
+# .env
+BRIDGE_APP_ID=your-app-id
+```
+
+```ts
+// src/app.module.ts
+import { Module } from '@nestjs/common';
+import { BridgeModule } from '@nebulr-group/bridge-nestjs';                  // +
+import { ExportsController } from './exports.controller';
+
+@Module({
+  imports: [BridgeModule.forRoot({ guard: { global: true } })],            // + every route needs a signed-in user
+  controllers: [ExportsController],
+})
+export class AppModule {}
+```
+
+```ts
+// src/exports.controller.ts
+import { Controller, Post } from '@nestjs/common';
+import { RequireQuota } from '@nebulr-group/bridge-nestjs';                  // +
+
+@Controller('exports')
+export class ExportsController {
+  @Post()
+  @RequireQuota('exports')                                                  // + the plan limit
+  create() {
+    return { exported: true };
+  }
+}
+```
+
+`BRIDGE_APP_ID` must be in the process environment. NestJS does not read `.env` by itself: start with `node --env-file=.env dist/main.js`, or set it in your container or process manager.
+
+**Settings are read for you.** Each field resolves as *explicit option > environment > default*; an empty value counts as unset.
+
+| Frontend | Backend | When to set it |
+|---|---|---|
+| `VITE_BRIDGE_APP_ID` | `BRIDGE_APP_ID` | Always. Missing, Bridge refuses to start and names the variable |
+| `VITE_BRIDGE_API_BASE_URL` | `BRIDGE_API_BASE_URL` | Only for a non-production app (stage, local, self-hosted). Unset means production |
+| `VITE_BRIDGE_HOSTED_URL` | — | Only for a local or self-hosted Bridge. On Bridge's own domains it follows the API address (`api-stage` → `auth-stage`) |
+| `VITE_BRIDGE_DEBUG` | `BRIDGE_DEBUG` | `true` for console logging |
+
+## 1. The server decides; the client decorates
+
+Anyone can call your API with curl, so a limit or a paid feature is enforced on the backend handler, never in the browser. Everything the frontend shows about limits — the upgrade dialog, a disabled button, a hidden panel — explains or anticipates a decision the server already makes. Remove every frontend check and the product is still correct; remove the backend decorator and it is not.
+
+## 2. A POST increments the limit
+
+The backend decorator **is** the increment. There is nothing else to wire: no "report usage" call after the insert, no counter in your database, no endpoint for the frontend.
+
+```ts
+@Post()
+@RequireQuota('exports')
+create() { /* your code */ }
+```
+
+- **Before the handler:** at the plan's limit the request is refused with `402` and a body the frontend understands (`{ code: 'QUOTA_EXCEEDED', metric, used, limit, fix }`). Your handler never runs.
+- **After the handler:** only when it answered **2xx**, Bridge records the use — exactly one write. A handler that throws or answers 4xx/5xx records nothing.
+- **Retries:** a request that sends an `Idempotency-Key` header is counted once per key, however often the client retries.
+- **Fail-closed:** if Bridge cannot answer, the request is refused with `503`, never let through unchecked.
+- A `metered` quota never refuses: past its allowance it bills per unit.
+
+## 3. Counter or gauge
+
+**If deleting it frees room, it's a gauge and your app counts it; if it happened, it's a counter and Bridge counts it.**
+
+| | Counter | Gauge |
+|---|---|---|
+| Examples | exports, API calls, AI completions, emails sent | tickets, projects, stored files, seats |
+| Who counts | Bridge, one event per successful request | Your app — you pass your own count |
+| Resets | every billing period ("40 of 100 this month") | never ("8 of 10 projects") |
+| Configure | `bridge plan quota set <plan> --metric exports --limit 100 --policy hard` (counter is the default) | `bridge plan quota set <plan> --metric tickets --limit 10 --policy hard --kind gauge` |
+| Backend | `@RequireQuota('exports')` | `@RequireQuota('tickets', { current })` on create, `@SyncQuota('tickets', { current })` on delete |
+
+```ts
+@Post()
+@RequireQuota('tickets', { current: (t, self: TicketsController) => self.tickets.countFor(t.id) })
+create() { /* … */ }
+
+@Delete(':id')
+@SyncQuota('tickets', { current: (t, self: TicketsController) => self.tickets.countFor(t.id) })
+remove() { /* … */ }
+```
+
+`current` returns your own count, and that count is what the limit is compared against, so Bridge's copy heals itself if it ever missed an update. There is no decrement and no reservation: every create and delete sends the whole count.
+
+**Seats** (`users`) are a gauge Bridge keeps itself from workspace membership. `@RequireQuota('users')` on your invite handler checks the seat limit and writes nothing.
+
+`bridge plan quota list` shows every metric the app's plans limit, with its kind.
+
+**Every hard quota is also an entitlement** with the same name, true while there is room. So never pair `@RequireEntitlement('exports')` with `@RequireQuota('exports')`: at the cap the entitlement answers `403` before the quota can answer the `402` the frontend knows how to upsell. Use `@RequireEntitlement` for a plan *feature* (`analytics`, `sso`), `@RequireQuota` for a *limit*.
+
+**A plan feature is a hard quota nothing counts.** There is no separate entitlement setting: `bridge plan quota set pro --metric analytics --limit 1 --policy hard` makes `analytics` true on `pro`, and a plan without that quota answers false. Gate it with `@RequireEntitlement('analytics')` on the backend and `<Entitled to="analytics">` in the UI. `app_active` is always there: true while the workspace's subscription is active, trialing, past due or cancelling at period end.
+
+## 4. Three ways to handle a limit in the UI
+
+Pick the lowest level that does the job. Each is optional; level 0 is on without code.
+
+| Level | What the page writes | What the user sees |
+|---|---|---|
+| **0 — nothing** | a plain button calling your API | Your backend refuses at the cap (`402`), and `<BridgeBootstrap>` opens an **upgrade dialog** naming the metric, linking to the subscription page. A workspace member who cannot manage billing is told to ask the owner instead |
+| **1 — one component** | `<QuotaGate metric="tickets">…</QuotaGate>` around the button; `<Entitled to="analytics">…</Entitled>` around a paid feature | The button is disabled at a known hard cap with an upgrade line beside it; the paid feature shows only on a plan that grants it |
+| **2 — your own UI** | `useQuota('tickets')` and `$entitlements.can('analytics')` | Whatever you build from the live numbers |
+
+```svelte
+<script lang="ts">
+  import { QuotaGate, Entitled, useQuota } from '@nebulr-group/bridge-svelte';
+  const tickets = useQuota('tickets');
+</script>
+
+<!-- level 1 -->
+<QuotaGate metric="tickets">
+  <button onclick={createTicket}>New ticket</button>
+</QuotaGate>
+
+<Entitled to="analytics">
+  <a href="/analytics">Analytics</a>
+  {#snippet fallback()}<a href="/subscription">Upgrade for analytics</a>{/snippet}
+</Entitled>
+
+<!-- level 2 -->
+{#if tickets.loading}
+  Loading…
+{:else if tickets.unlimited}
+  Unlimited tickets
+{:else}
+  {tickets.used} of {tickets.limit} tickets
+{/if}
+```
+
+- "Not loaded yet" is never "zero" and never "not allowed": `useQuota` numbers stay `null` while `loading`, `<QuotaGate>` stays enabled while loading, and `<Entitled>` renders nothing (or its `loading` snippet) until `$entitlements.ready`.
+- The dialog catches a `402 QUOTA_EXCEEDED` from the page's own origin, from Bridge, and from any call made with `bridgeFetch()`; a backend on another origin is listed in `billing.apiOrigins`. `billing: { upgradeDialog: false }` turns it off, `billing: { upgradeDialog: MyDialog }` replaces it.
+- Do not write a quota `if`, a "limit reached" toast or a `/quota` endpoint of your own: level 0 already covers the refusal, and the frontend reads quota directly from Bridge.
+
+## 5. Usage reported from the browser trusts the client
+
+An app with no backend that sees the action — local-first, mobile, data on the device — can report usage from the frontend:
+
+```ts
+import { bridge } from '@nebulr-group/bridge-svelte';
+
+bridge.usage.report('exports');                        // a counter: it happened
+await bridge.usage.set('projects', projects.length);   // a gauge: how many exist now
+```
+
+This is **self-reported, trusted-client usage**. Anything in a browser can send any number, so **a frontend alone cannot enforce a limit**: Bridge shows and bills what the client reports, and the client can lie. When the app has a backend, report and enforce there (section 2). Use the browser path only when there is no server to do it.
+
+## 6. Four levels of customising Bridge's pages
+
+The same ladder holds for the sign-in pages (`<BridgeAuthRoutes>`) and the subscription pages (`<BridgeBillingRoutes>`). Climb only as far as you need.
+
+| Rung | What you do | What you own |
+|---|---|---|
+| **0 — nothing** | Bridge's pages render inside your own `+layout.svelte` | Your navigation, header and shell already surround them |
+| **1 — tokens** | Set `--bridge-*` CSS variables in your CSS | Colours, radius, spacing |
+| **2 — frame and heading** | Pass the `frame(page, children)` and `heading(page)` snippets | Everything around the form on every page, and each page's heading |
+| **3 — take over one page** | Create that page's own route file, e.g. `src/routes/auth/login/+page.svelte` | That one page; SvelteKit prefers it over `[...bridge]`, every other page keeps working |
+| **4 — headless** | Build your own UI on `getBridgeAuth()` | Everything |
+
+```svelte
+<!-- rung 2: src/routes/auth/[...bridge]/+page.svelte -->
+<script lang="ts">
+  import { BridgeAuthRoutes } from '@nebulr-group/bridge-svelte';
+</script>
+
+<BridgeAuthRoutes>
+  {#snippet frame(page, children)}
+    <main class="auth-card">{@render children()}</main>
+  {/snippet}
+  {#snippet heading(page)}
+    <h1>{page === 'signup' ? 'Create your account' : 'Welcome back'}</h1>
+  {/snippet}
+</BridgeAuthRoutes>
+```
+
+`heading` replaces only each page's main step (the login credentials step, the signup form, the set-password form); sub-steps such as "Reset your password" keep their own, so two headings never stack. There are no per-page snippets: to change more than frame and heading, take over the page (rung 3). A sign-in page you own navigates itself after sign-in: `<LoginForm onLogin={() => goto(readReturnTo($page.url) ?? '/')} />`.
+
+**The token contract (rung 1).** These `--bridge-*` variables are the supported way to restyle the components; each has a built-in default. Set them on `:root` or on any wrapper.
+
+| Token | Default | Styles |
+|---|---|---|
+| `--bridge-primary` | `#4f46e5` | Primary buttons, selected plan interval, active workspace border |
+| `--bridge-primary-hover` | `#4338ca` | Primary button hover |
+| `--bridge-primary-fg` | `#ffffff` | Text on primary buttons |
+| `--bridge-primary-foreground` | `#ffffff` | Workspace avatar text; plan picker fallback when `--bridge-primary-fg` is unset |
+| `--bridge-primary-light` | `#eff6ff` | Active workspace background |
+| `--bridge-border` | `#d1d5db` | Input and secondary button borders |
+| `--bridge-border-radius` | `6px` | Corners of inputs, buttons, alerts, cards |
+| `--bridge-input-focus` | `#4f46e5` | Input focus ring |
+| `--bridge-foreground` | `#374151` | Password-toggle hover, workspace names |
+| `--bridge-muted` | `#6b7280` | Secondary text, hints, table headings |
+| `--bridge-bg` | `#ffffff` | Plan-change confirmation panel |
+| `--bridge-bg-muted` | `#f5f5f5` | MFA backup code |
+| `--bridge-muted-bg` | `#f3f4f6` | Workspace list hover, plan interval tabs (which fall back to `--bridge-bg-muted`) |
+| `--bridge-alert-error-bg` | `#fef2f2` | Error alert background |
+| `--bridge-alert-error-fg` | `#991b1b` | Error alert text |
+| `--bridge-alert-error-border` | `#fca5a5` | Error alert border |
+| `--bridge-alert-success-bg` | `#f0fdf4` | Success alert background |
+| `--bridge-alert-success-fg` | `#166534` | Success alert text |
+| `--bridge-alert-success-border` | `#86efac` | Success alert border |
+| `--bridge-auth-page-padding` | `3rem 1rem` | Padding of the default sign-in page container |
+| `--bridge-billing-page-width` | `60rem` | Width of the subscription pages and `<BridgePaywallPage>` |
+| `--bridge-billing-page-padding` | `3rem 1rem` | Padding of the subscription pages and `<BridgePaywallPage>` |
+| `--bridge-paywall-bg` | `rgba(15, 23, 42, 0.72)` | Backdrop of the `<BridgePaywall>` overlay |
+| `--bridge-paywall-panel-bg` | `#ffffff` | Panel of the `<BridgePaywall>` overlay |
+
+All default rules use `:where()`, so any selector of yours wins without `!important`. Leaving out `import '@nebulr-group/bridge-svelte/styles'` makes the components headless: plain HTML for you to style.
+
+## 7. Pages Bridge serves, and the one it only offers
+
+- **Sign-in:** `src/routes/auth/[...bridge]/+page.svelte` serves login, signup, the OAuth callback, set password (where signup verification and password-reset emails land), forgot password, magic link, passkey setup and workspace selection. Which methods appear comes from the app's settings at runtime, so turning magic links on needs no code. Hosted and in-app sign-in use the same file; `loginRoute: '/auth/login'` in `bridgeBootstrap()` is the whole switch to in-app.
+- **Subscription:** `src/routes/subscription/[...bridge]/+page.svelte` serves `/subscription`, the paywall `/subscription/plan`, and the checkout return pages `/subscription/success` and `/subscription/error`. Bridge's redirects and upgrade links point there by default.
+- **The paywall** redirects a signed-in workspace with no plan to `/subscription/plan` before any page renders — only when the app has plans and its `paymentsAutoRedirect` setting is on (the default). `bridge app update --payments-auto-redirect false` turns it off.
+- **A `/welcome` onboarding page is offered, never created unasked.** It is a product decision: ask the developer. Only if they say yes, add a one-line page rendering `<BridgePaywallPage />` and `billing: { paywallRoute: '/welcome' }` in `bridgeBootstrap()`.
+- Any other address under a catch-all gets the app's own 404.
+
+## Where the details live
+
+| Topic | Command |
+|---|---|
+| Sign-in, hosted or in-app | `bridge guide svelte` · `bridge guide svelte sdk-auth` |
+| Plans, the subscription pages, the UI levels | `bridge guide svelte billing` |
+| Backend limits and entitlements | `bridge guide nestjs billing` |
+| Backend sign-in and route protection | `bridge guide nestjs` |
+| Feature flags | `bridge guide flags` |
+| Proving sign-in works | `bridge test-user create`, then `bridge test-user verify` |

package/dist/prompts/orientation.md

@@ -0,0 +1,40 @@
+# What Bridge does
+
+Relay this to the developer as it stands, then add one sentence about what their app has today (read it first: `get_app` and `get_setup_status`, or `bridge app get` and `bridge setup status`).
+
+---
+
+Bridge runs everything between signup and invoice for your app, so you don't build it yourself.
+
+- **Login.** People sign up and sign in with a password, a magic link, a passkey, Google, GitHub and other providers, or their company's SSO, with optional two-factor. Bridge serves the pages; your app adds about fifteen lines. *Want to choose how people sign in?*
+- **Teams and workspaces.** Each customer gets a workspace and can invite teammates into it. You decide whether people create their own workspace or join by invitation. *Is your app for single users or for teams?*
+- **Roles and permissions.** Inside a workspace, roles decide who may do what, and your backend checks them on every request. *Who are the different kinds of people in a customer's workspace?*
+- **Payments and plans.** Plans with prices, trials and limits ("3 projects on Free, 50 on Pro"), checkout through your own Stripe account, and an upgrade prompt when someone hits a limit. *Want to set up a free tier and a paid plan?*
+- **Feature control.** Turn any feature on or off for everyone, a percentage of users, one plan or one customer, without a deploy. *Is there a feature you want to roll out carefully or sell on a higher plan?*
+- **Look and feel.** Sign-in and subscription pages in your colours and fonts, inside your own layout, and emails sent in your app's name. *Want the sign-in pages to look like the rest of your app?*
+- **Going live.** A readiness checklist that says exactly what still points at localhost or test keys, and a test sign-in that proves login works end to end. *Ready to check what stands between you and real users?*
+
+---
+
+## Where to go next
+
+Each area has a decision guide: the questions to ask the developer, and the defaults to apply without asking.
+
+| Area | Decision guide | Journey |
+|---|---|---|
+| Login | `bridge guide decision login` | `bridge guide add-login` |
+| Teams and workspaces | `bridge guide decision teams` | `bridge guide add-teams` |
+| Roles and permissions | `bridge guide decision roles` | — |
+| Payments and plans | `bridge guide decision payments` | `bridge guide add-paid-plan` |
+| Feature control | `bridge guide decision feature-control` | `bridge guide add-feature-flag` |
+| Look and feel | `bridge guide decision look-and-feel` | — |
+| Going live | `bridge guide decision going-live` | `bridge guide go-live` |
+
+In an MCP client the same guides are the resources `bridge://guides/decisions/<area>` (areas: `login`, `teams`, `roles`, `payments`, `feature-control`, `look-and-feel`, `going-live`), and the journeys are the server's prompts of the same names.
+
+How limits, upgrade prompts and page customisation actually work, for every area: `bridge guide mechanisms`.
+
+Two rules hold in every guide:
+
+1. **Product questions go to the developer.** What to charge, who may do what, what a plan includes, what users see: ask, and wait for the answer. Never guess them.
+2. **Mechanics you decide.** Where a guide gives a default, apply it and say why in one line. The developer can overrule it.

package/dist/shape.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Tenant metadata keys the platform writes for its own conversion-pixel
+ * bookkeeping (tracking.service.ts, tenant.service.ts). Never app data.
+ */
+export declare const INTERNAL_TENANT_METADATA_KEYS: string[];
+/** A tenant without the platform's pixel bookkeeping in `metadata`. */
+export declare function shapeTenant<T>(tenant: T): T;
+/**
+ * A plan without the payment provider's ids: each quota's `providerRefs`
+ * (Stripe price and meter ids) is dropped. Prices and quotas otherwise stay
+ * whole — `create_plan` and friends still return the full plan.
+ */
+export declare function shapePlan<T>(plan: T): T;
+/**
+ * Roles with each privilege named once. Every role used to carry the full
+ * privilege object (id, key, description) for every privilege it grants, so a
+ * five-role app repeated the same descriptions five times. Now each role lists
+ * privilege KEYS — what code and create_role/update_role take — and the
+ * descriptions appear once, in `privileges`.
+ */
+export declare function shapeRoleList(roles: unknown[]): {
+    roles: Array<Record<string, unknown>>;
+    privileges: Record<string, string>;
+};
+//# sourceMappingURL=shape.d.ts.map

package/dist/shape.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shape.d.ts","sourceRoot":"","sources":["../src/shape.ts"],"names":[],"mappings":"AAUA;;;GAGG;AACH,eAAO,MAAM,6BAA6B,UAA+C,CAAC;AAE1F,uEAAuE;AACvE,wBAAgB,WAAW,CAAC,CAAC,EAAE,MAAM,EAAE,CAAC,GAAG,CAAC,CAU3C;AAED;;;;GAIG;AACH,wBAAgB,SAAS,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,GAAG,CAAC,CAYvC;AAOD;;;;;;GAMG;AACH,wBAAgB,aAAa,CAAC,KAAK,EAAE,OAAO,EAAE,GAAG;IAC/C,KAAK,EAAE,KAAK,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC;IACtC,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACpC,CAkBA"}

package/dist/shape.js

@@ -0,0 +1,74 @@
+/*
+ * TBP-709 (D) — what `bridge … list` shows, minus the platform's internals.
+ *
+ * The REST DTOs these come from also serve the dashboards and the SDKs, so
+ * they are left alone; the trimming happens at the presentation layer.
+ * Port of bridge-api's MCP `shape.ts` (same functions, same tests) so the
+ * CLI lists and the MCP lists cannot drift. Every function is pure and leaves
+ * its input untouched.
+ */
+/**
+ * Tenant metadata keys the platform writes for its own conversion-pixel
+ * bookkeeping (tracking.service.ts, tenant.service.ts). Never app data.
+ */
+export const INTERNAL_TENANT_METADATA_KEYS = ['pendingPixelEvents', 'conversionTracking'];
+/** A tenant without the platform's pixel bookkeeping in `metadata`. */
+export function shapeTenant(tenant) {
+    if (!tenant || typeof tenant !== 'object')
+        return tenant;
+    const metadata = tenant.metadata;
+    if (!metadata || typeof metadata !== 'object')
+        return tenant;
+    const kept = Object.fromEntries(Object.entries(metadata).filter(([k]) => !INTERNAL_TENANT_METADATA_KEYS.includes(k)));
+    return { ...tenant, metadata: kept };
+}
+/**
+ * A plan without the payment provider's ids: each quota's `providerRefs`
+ * (Stripe price and meter ids) is dropped. Prices and quotas otherwise stay
+ * whole — `create_plan` and friends still return the full plan.
+ */
+export function shapePlan(plan) {
+    if (!plan || typeof plan !== 'object')
+        return plan;
+    const quotas = plan.quotas;
+    if (!Array.isArray(quotas))
+        return plan;
+    return {
+        ...plan,
+        quotas: quotas.map((q) => {
+            if (!q || typeof q !== 'object')
+                return q;
+            const { providerRefs: _drop, ...rest } = q;
+            return rest;
+        }),
+    };
+}
+/**
+ * Roles with each privilege named once. Every role used to carry the full
+ * privilege object (id, key, description) for every privilege it grants, so a
+ * five-role app repeated the same descriptions five times. Now each role lists
+ * privilege KEYS — what code and create_role/update_role take — and the
+ * descriptions appear once, in `privileges`.
+ */
+export function shapeRoleList(roles) {
+    const privileges = {};
+    const shaped = (roles ?? []).map((role) => {
+        const r = (role ?? {});
+        const granted = Array.isArray(r.privileges) ? r.privileges : [];
+        const keys = [];
+        for (const p of granted) {
+            if (typeof p === 'string') {
+                keys.push(p);
+                continue;
+            }
+            if (!p || typeof p.key !== 'string')
+                continue;
+            keys.push(p.key);
+            if (!(p.key in privileges))
+                privileges[p.key] = p.description ?? '';
+        }
+        return { ...r, privileges: keys };
+    });
+    return { roles: shaped, privileges };
+}
+//# sourceMappingURL=shape.js.map

package/dist/shape.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"shape.js","sourceRoot":"","sources":["../src/shape.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH;;;GAGG;AACH,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,oBAAoB,EAAE,oBAAoB,CAAC,CAAC;AAE1F,uEAAuE;AACvE,MAAM,UAAU,WAAW,CAAI,MAAS;IACtC,IAAI,CAAC,MAAM,IAAI,OAAO,MAAM,KAAK,QAAQ;QAAE,OAAO,MAAM,CAAC;IACzD,MAAM,QAAQ,GAAI,MAAiC,CAAC,QAAQ,CAAC;IAC7D,IAAI,CAAC,QAAQ,IAAI,OAAO,QAAQ,KAAK,QAAQ;QAAE,OAAO,MAAM,CAAC;IAC7D,MAAM,IAAI,GAAG,MAAM,CAAC,WAAW,CAC7B,MAAM,CAAC,OAAO,CAAC,QAAmC,CAAC,CAAC,MAAM,CACxD,CAAC,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,6BAA6B,CAAC,QAAQ,CAAC,CAAC,CAAC,CACpD,CACF,CAAC;IACF,OAAO,EAAE,GAAG,MAAM,EAAE,QAAQ,EAAE,IAAI,EAAO,CAAC;AAC5C,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,SAAS,CAAI,IAAO;IAClC,IAAI,CAAC,IAAI,IAAI,OAAO,IAAI,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC;IACnD,MAAM,MAAM,GAAI,IAA6B,CAAC,MAAM,CAAC;IACrD,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC;QAAE,OAAO,IAAI,CAAC;IACxC,OAAO;QACL,GAAG,IAAI;QACP,MAAM,EAAE,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE;YACvB,IAAI,CAAC,CAAC,IAAI,OAAO,CAAC,KAAK,QAAQ;gBAAE,OAAO,CAAC,CAAC;YAC1C,MAAM,EAAE,YAAY,EAAE,KAAK,EAAE,GAAG,IAAI,EAAE,GAAG,CAA4B,CAAC;YACtE,OAAO,IAAI,CAAC;QACd,CAAC,CAAC;KACE,CAAC;AACT,CAAC;AAOD;;;;;;GAMG;AACH,MAAM,UAAU,aAAa,CAAC,KAAgB;IAI5C,MAAM,UAAU,GAA2B,EAAE,CAAC;IAC9C,MAAM,MAAM,GAAG,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;QACxC,MAAM,CAAC,GAAG,CAAC,IAAI,IAAI,EAAE,CAA4B,CAAC;QAClD,MAAM,OAAO,GAAG,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAE,CAAC,CAAC,UAA4C,CAAC,CAAC,CAAC,EAAE,CAAC;QACnG,MAAM,IAAI,GAAa,EAAE,CAAC;QAC1B,KAAK,MAAM,CAAC,IAAI,OAAO,EAAE,CAAC;YACxB,IAAI,OAAO,CAAC,KAAK,QAAQ,EAAE,CAAC;gBAC1B,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;gBACb,SAAS;YACX,CAAC;YACD,IAAI,CAAC,CAAC,IAAI,OAAO,CAAC,CAAC,GAAG,KAAK,QAAQ;gBAAE,SAAS;YAC9C,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;YACjB,IAAI,CAAC,CAAC,CAAC,CAAC,GAAG,IAAI,UAAU,CAAC;gBAAE,UAAU,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,WAAW,IAAI,EAAE,CAAC;QACtE,CAAC;QACD,OAAO,EAAE,GAAG,CAAC,EAAE,UAAU,EAAE,IAAI,EAAE,CAAC;IACpC,CAAC,CAAC,CAAC;IACH,OAAO,EAAE,KAAK,EAAE,MAAM,EAAE,UAAU,EAAE,CAAC;AACvC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nebulr-group/bridge-cli",
-  "version": "0.6.0-beta.2",
+  "version": "0.6.0-beta.4",
   "description": "Bridge platform CLI for AI coding agents and developers",
   "author": "Nebulr Group",
   "license": "MIT",