@nebulr-group/bridge-cli 0.6.5 → 1.0.0-alpha.0

package/dist/prompts/fit-together.md

@@ -1,97 +0,0 @@
-# How roles, plans, limits and flags fit together
-
-Read this before any decision guide that touches who gets what. Every other guide builds on it. MCP: resource `bridge://guides/fit-together`. CLI: `bridge guide fit-together`.
-
-## The one rule for app code
-
-**Every gate in app code is a flag.** A link, a page, a button, an endpoint: if some people get it and others do not, the code asks a flag, and the flag's rule says why: a privilege (`privileges contains "USER_WRITE"`), a plan feature (`bridge:billing.entitlement.analytics eq true`) or a rollout. App code never reads a role, a privilege list, the plan or a plan feature to decide what someone may see or do.
-
-Two things are not gates and are not flags: **numbers** are plan limits (`<QuotaGate>` in the browser, `@RequireQuota` on the backend), and **permission on one specific record** stays in app code ("only the author edits their post").
-
-Before calling the work done, run `npx @nebulr-group/bridge-cli check gates` in the project. It lists every direct role, privilege, plan or plan-feature check with the flag to use instead. Fix each one.
-
-- **SvelteKit:** a piece of UI or a nav link is `<FeatureFlag key="…">`; a page is a route rule `{ match: '/admin/*', featureFlag: 'admin-area', redirectTo: '/' }`.
-- **NestJS:** an endpoint is `@RequireFeatureFlag('…')` on the handler.
-
-## Why a flag
-
-Features should be controlled with feature flags. A flag can switch a route, an API endpoint, a feature or a single piece of code; its rules change without a release and update live when someone's role or plan changes. If a plan sells the feature, include it on the plan as well. This is valuable because the plan is where the customer sees what they are buying: the pricing table, the upgrade dialog and the "not on your plan" reason all read the plan's list, and the flag's rule points at that same list, so changing what Pro includes is one edit in one place.
-
-## One question, one tool
-
-| The question | The tool | How |
-|---|---|---|
-| Is this route, API endpoint, feature or piece of code on for them? | a **flag** | The code asks for the flag by key; the flag's rule decides |
-| Does their plan sell it? | the plan's **features list**, read by the flag's rule | `bridge plan feature add pro analytics`, then the rule `bridge:billing.entitlement.analytics eq true` |
-| How many do they get (projects, exports, seats)? | a **plan limit** | `bridge plan quota set pro --metric exports --limit 100 --policy hard` |
-| How many people fit in a workspace? | a **plan limit** counted from membership (seats) | `bridge plan quota set pro --metric seats --limit 10 --policy hard --kind gauge --source membership` |
-| Who is this person, and may they do this kind of thing? | a flag rule on a **privilege** (preferred) or a **role** | `privileges contains "REPORTS_VIEW"`, or `user.role eq "ADMIN"` |
-| May this person change this one record? | the app's own code | "Only the author edits their post" |
-
-The flag's rule never names plans. It points at `bridge:billing.entitlement.<feature>`, so when Pro gains or loses a feature, the plan changes and no rule has to follow.
-
-## Where a flag is not the tool
-
-- **Numbers are plan limits.** "100 exports a month" or "10 projects" is a quota on the plan, not a flag. Bridge refuses at the limit and the upgrade dialog explains it.
-- **Seats are a plan limit too, counted from membership.** Bridge counts the workspace's active members; the check sits where invites happen (the team page's seat-limit setting, or `@RequireQuota('seats')` on the app's own invite handler), never in a flag or an entitlement.
-- **Permission on one specific record stays in app code.** Whether this person may edit *this* invoice depends on data only the app has (who wrote it, which team owns it). The flag decides whether invoice editing exists for them at all; the app decides the record.
-
-## Access by who someone is
-
-Control it with a flag rule, never with a role check written into the app's code.
-
-- **Prefer a privilege rule** (`privileges contains "REPORTS_VIEW"`) over a role rule (`user.role eq "ADMIN"`). A privilege rule keeps working when roles are renamed or reshuffled. `contains` on `privileges` means the person holds exactly that key: `REPORTS_VIEW` does not match `REPORTS_VIEW_ALL`.
-- **A role rule is fine when the developer means the role itself.** Use the role key exactly as `list_roles` shows it; `ADMIN` and `admin` are different.
-- **An admin-only page is a flag route rule, not a check on the page.** In SvelteKit: `{ match: '/admin/*', featureFlag: 'admin-area', redirectTo: '/' }`, with the flag `admin-area` ruled on a privilege. On the NestJS backend: `@RequireFeatureFlag('admin-area')` on the handler. Both read the same rule.
-- **The team page is the same.** The team link and the team route are gated by a flag ruled on the privilege that manages people (for example `privileges contains "USER_WRITE"`, after `bridge role list`), never by a list of role names.
-- **Roles are the app's own.** What a role can do is only ever "in the default setup". Read the app's real roles and privileges with `list_roles` / `bridge role list` before writing any rule, and never assume what a role grants from its name. In the default setup a new app has Owner, Admin and Member, and Member is the default for everyone after the first person in a workspace.
-
-## The backend sees the same rule
-
-A flag rule on a role, a privilege, the plan or a plan feature gives the same answer in the NestJS backend as in the browser, with no wiring: the plugin fills those in from the verified sign-in and from Bridge's own billing records. Nothing the client sends is used for them. Plan-limit numbers (`bridge:billing.quota.*`) are the one thing a server-side rule cannot see; limits are enforced by the plan-limit decorator anyway.
-
-## Limits: count once, where the action happens
-
-Ask the developer first: **"Does this action call your server?"** Then:
-
-- **Yes, it calls the backend:** the backend counts it. One check on the handler (`@RequireQuota('exports')` in NestJS, `bridge.requireQuota('exports')` in Express) refuses at the limit with `402` and records the use after a successful request. The frontend only shows the count and the upgrade dialog; it does not report the same metric.
-- **No, it happens in the browser** (local-first, data on the device, no server of the developer's own): the browser counts it. `bridge.usage.report('exports')` for something that happened, `bridge.usage.set('projects', n)` for how many exist now, and `<QuotaGate metric="exports">` around the button so it stops at the limit. This is a complete, first-class way to run limits.
-
-Never count one metric in both places: it is counted twice. Never describe browser counting as a lesser or temporary option; ask the question above and follow the answer.
-
-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.
-
-## What people see when something is off
-
-A flag that is off says why, and the app shows each reason differently:
-
-| Why it is off | In the browser | From the backend |
-|---|---|---|
-| Not on their plan | The upgrade dialog, naming the plans that include it | `402 FEATURE_NOT_IN_PLAN` |
-| Their role or privileges | Hidden, or a line telling them to ask an admin | `403 FEATURE_NOT_PERMITTED` |
-| Switched off | Hidden | `403 FEATURE_OFF` |
-
-No upgrade dialog opens by itself. It opens when someone opens a gated route, clicks something gated (SvelteKit: `<FeatureFlag key="analytics" upgrade>` renders an "Upgrade to use this" button), or when the backend refuses with a `402`. A page that only renders a hidden feature opens nothing.
-
-## Worked example
-
-"Analytics on Pro. Only people who manage the workspace see settings. 100 exports a month on Pro."
-
-1. `bridge plan feature add pro analytics --name "Analytics"`, and a flag `analytics` with the rule `bridge:billing.entitlement.analytics eq true`.
-2. `bridge role list` first. Then a flag `workspace-settings` with a privilege rule, e.g. `privileges contains "TENANT_WRITE"` if that is the privilege the app's roles use for it, and a route rule on `/settings/*`.
-3. Ask whether exporting calls the developer's server. If it does: `bridge plan quota set pro --metric exports --limit 100 --policy hard` and `@RequireQuota('exports')` on the export handler. If it does not: the same quota, `bridge.usage.report('exports')` in the browser and `<QuotaGate metric="exports">` around the button.
-4. `npx @nebulr-group/bridge-cli check gates`: nothing left that reads a role, a privilege, the plan or a plan feature directly.
-
-## Exceptions
-
-**Checking a plan feature without a flag is the exception.** `@RequireEntitlement('analytics')` on the backend and `<Entitled to="analytics">` or `$entitlements.can('analytics')` in the UI read the plan's list directly. They are for the rare case where the developer explicitly asks for no flag, and they print a one-time note in development. Mark each such line `// bridge-gate-exception: <reason>` so `check gates` leaves it. Use a flag by default: it can also carry a rollout, a trial group or a one-customer exception later, without a code change.
-
-## Where each piece is decided
-
-| Area | Decision guide |
-|---|---|
-| Flags and their rules | `bridge guide decision feature-control` |
-| Roles and privileges | `bridge guide decision roles` |
-| Plans, features and limits | `bridge guide decision payments` |
-| Who is in a workspace | `bridge guide decision teams` |
-| How limits, the upgrade dialog and page customisation work | `bridge guide mechanisms` |

package/dist/prompts/flags/master.md

@@ -1,220 +0,0 @@
-# Bridge Feature Flags — Master Integration Prompt
-
-You are integrating **Bridge Feature Flags** into a user's application — the flags-only path. No auth scaffolding, no billing components. If the user also wants auth or billing, run `bridge guide` (auth master) or `bridge guide billing` afterwards.
-
-> **The one rule for app code: every gate is a flag.** A link, a page, a button, an endpoint: if some people get it and others do not, the code asks a flag, and the flag's rule says why (a privilege, a plan feature, a rollout). App code never reads a role, a privilege list, the plan or a plan feature to decide what someone may see or do. Numbers are plan limits, and permission on one specific record stays in app code. `bridge guide fit-together` has the whole rule; the last verification step runs `npx @nebulr-group/bridge-cli check gates`.
-
-Flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is listed on the plan and the flag's rule points at `bridge:billing.entitlement.<feature>`, never at plan names; access by who someone is is a rule on a privilege (preferred) or a role, never a role check in code. `bridge guide fit-together` has the whole rule; `bridge guide decision feature-control` has the questions to ask.
-
-This master prompt orchestrates discovery, confirmation, and verification. The **actual install commands, provider shapes, and runnable code snippets live in the per-framework prompts** that ship in each plugin repo's `mcp/` folder. This master does the planning; the per-framework prompts do the wiring.
-
-## Where per-framework prompts live
-
-Each plugin repo owns its own framework-specific prompt under `mcp/feature-flags-prompt.md`. The CLI fetches them on demand:
-
-| Framework | Plugin repo | Fetched by |
-|-----------|-------------|------------|
-| SvelteKit | `bridge-svelte/mcp/feature-flags-prompt.md` | `bridge guide flags --framework svelte` |
-| React | `bridge-react/mcp/feature-flags-prompt.md` | `bridge guide flags --framework react` |
-| Next.js | `bridge-nextjs/mcp/feature-flags-prompt.md` | `bridge guide flags --framework nextjs` |
-| Angular | `bridge-angular/mcp/feature-flags-prompt.md` | `bridge guide flags --framework angular` |
-| NestJS | `bridge-nestjs/mcp/feature-flags-prompt.md` | `bridge guide flags --framework nestjs` |
-| Express | `bridge-express/mcp/feature-flags-prompt.md` | `bridge guide flags --framework express` |
-
-`bridge guide <framework> flags` is an equivalent route — both call the same plugin-repo prompt.
-
-If the CLI returns `HTTP 404 — file may not exist yet in the plugin repo`, the plugin hasn't published its flags guide yet. Tell the user that's the blocker and fall back to `@nebulr-group/bridge-auth-core` directly (it's framework-agnostic and stable). Do NOT improvise an inline integration in this master prompt — the plugin guide is the canonical handover.
-
-## Step 0 — Authenticate
-
-Run `bridge auth login` and wait for it to print "Logged in as <email>".
-
-If the user is using flags **without Bridge Auth** (bring-your-own identity), they still need to be logged into the CLI to fetch app config and manage flags. Login is not the same as runtime identity.
-
----
-
-**At the end of this integration you will output a success message:**
-
-```
-   ██████╗ ██████╗ ██╗██████╗  ██████╗ ███████╗
-   ██╔══██╗██╔══██╗██║██╔══██╗██╔════╝ ██╔════╝
-   ██████╔╝██████╔╝██║██║  ██║██║  ███╗█████╗
-   ██╔══██╗██╔══██╗██║██║  ██║██║   ██║██╔══╝
-   ██████╔╝██║  ██║██║██████╔╝╚██████╔╝███████╗
-   ╚═════╝ ╚═╝  ╚═╝╚═╝╚═════╝  ╚═════╝ ╚══════╝
-
-  ──────────────────────────────────────────────
-   Feature flags are live in [project-name].
-
-    ✅  Flags read from the bulk-evaluate endpoint at boot
-    ✅  Eval context wired: [identity-source]
-    ✅  Telemetry batching enabled
-    ✅  Realtime updates enabled (optional)
-  ──────────────────────────────────────────────
-    Here is what I actually did:
-    [what-i-actually-did]
-
-    And here is what I changed:
-    [what-i-changed]
-  ──────────────────────────────────────────────
-```
-
-Track as you work:
-- **`[project-name]`** — folder name and/or `package.json` name for each project
-- **`[identity-source]`** — how `identity` flows in (Bridge Auth `user.id`, your own session, anonymous bucket ID, etc.)
-- **`[what-i-actually-did]`** — high-level outcomes
-- **`[what-i-changed]`** — every package installed, file modified, env var set
-
-## Mental model (1-minute version)
-
-A flag has:
-
-| Field | Possible values |
-|---|---|
-| `state` | `off` · `on` · `on-with-rule` |
-| `valueType` | `boolean` · `string` · `number` · `json` |
-| `offValue` | typed per `valueType` (returned when state=off) |
-| `onValue` | typed per `valueType` (returned when state=on) |
-| `rule` | branches[] + otherwiseValue + rolloutPct (only when state=on-with-rule) |
-
-Branches are first-match-wins; conditions within a branch AND together; `rolloutPct` is rule-level (0-100) and requires `identity` on the eval context.
-
-Every plugin wraps the same evaluation, and the return type is inferred from the default value, so no casts. On SvelteKit it is `useFlag(key, defaultValue)` in script and `<FeatureFlag key defaultValue>` in markup, both from `@nebulr-group/bridge-svelte/flags`; a whole route is gated by a `featureFlag` rule in `bridgeBootstrap()`.
-
-## Step 1 — Discover projects
-
-Scan the current directory and its immediate subdirectories for `package.json` files. For each one:
-
-1. **Package manager** — detect from lock file:
-   - `bun.lock` / `bun.lockb` → `bun`
-   - `pnpm-lock.yaml` → `pnpm`
-   - `yarn.lock` → `yarn`
-   - `package-lock.json` or none → `npm`
-
-2. **Framework** (from `dependencies` + `devDependencies`):
-   - `svelte` or `@sveltejs/kit` → **SvelteKit**
-   - `react` + `next` → **Next.js**
-   - `react` (without next) → **React**
-   - `@angular/core` → **Angular**
-   - `@nestjs/core` → **NestJS** (backend)
-   - `express` (without `@nestjs/core`) → **Express** (backend)
-
-3. **Existing Bridge plugin?** Check for `@nebulr-group/bridge-<framework>` — if present, the project may already have auth or other Bridge surfaces. Flags can co-exist with auth in the same plugin; the per-framework guide will tell you whether its bootstrap is already in place. On SvelteKit, an app that already calls `bridgeBootstrap()` and renders `<BridgeBootstrap>` has flags running — there is nothing to install or initialise.
-
-4. **Existing flag system?** Look for `launchdarkly-*`, `@unleash/*`, `posthog-js`, `growthbook-*` — warn the user that Bridge flags will run in parallel unless they migrate.
-
-5. **Record** for each project: path, type (frontend/backend), framework, package manager, existing flag system (if any).
-
-## Step 2 — Present findings and confirm
-
-```
-I detected the following projects:
-
-1. ./my-app-ui — SvelteKit 5 (frontend, bun)
-   Existing flags: none
-
-2. ./my-app-api — NestJS 11 (backend, bun)
-   Existing flags: none
-
-Which projects should I wire flags into? (all / select by number)
-```
-
-Wait for confirmation. If specific projects are selected, only integrate those.
-
-**Identity source (frontend + backend both).** Ask:
-
-```
-How should flags identify users?
-
-- Bridge Auth (default if already integrated) — uses the authenticated user's id
-- Your own user model — you pass identity yourself per call / per request
-- Anonymous — every visitor gets a stable random bucket id (no targeting beyond rolloutPct)
-```
-
-Note the answer — Step 4 wires the eval context based on it.
-
-## Step 3 — Get Bridge app context
-
-Run:
-
-```bash
-bridge app get
-bridge info flags
-```
-
-Extract and note:
-- `appId` — needed by every project
-- Existing flags in the app (if any) — useful to show the user what they can already read
-
-If `bridge` CLI is not available or not configured, ask the user for the `appId` directly.
-
-## Step 4 — Fetch the per-framework prompt and follow it
-
-For each confirmed project, fetch the framework-specific flags prompt and follow it verbatim:
-
-```bash
-bridge guide flags --framework <name>
-```
-
-Where `<name>` is one of: `svelte`, `react`, `nextjs`, `angular`, `nestjs`, `express`.
-
-| Framework | Command |
-|-----------|---------|
-| SvelteKit | `bridge guide flags --framework svelte` |
-| React | `bridge guide flags --framework react` |
-| Next.js | `bridge guide flags --framework nextjs` |
-| Angular | `bridge guide flags --framework angular` |
-| NestJS | `bridge guide flags --framework nestjs` |
-| Express | `bridge guide flags --framework express` |
-
-`bridge guide <framework> flags` is an equivalent route — both call the same plugin-repo prompt.
-
-**Every per-framework guide covers this contract:**
-
-- **Install** — the right package + version + import path (when the plugin is already installed for auth, nothing more to install)
-- **Bootstrap** — provider / module / factory setup where the framework needs one (SvelteKit with Bridge Auth needs none: `<BridgeBootstrap>` starts flags, reading the app id from `.env`)
-- **Eval context** — idiomatic placement for `identity` and `attributes`, including how to wire the `identitySource` chosen in Step 2
-- **Reading a flag** — the framework wrapper (`useFlag`, `FeatureFlag`, `signal`, decorator) and the synchronous `evaluateFlag` for non-reactive contexts
-- **Advanced attribute wiring** — the unified `bridge.attributes` write surface and realtime event subscription via `bridge.events.handle`
-- **Telemetry + realtime** — both on by default; how to disable
-- **Troubleshooting** — the most common first-time failures
-
-**Pass these values from this master to the per-framework prompt:**
-- `appId` — from Step 3
-- `baseUrl` — production by default; a stage, local or self-hosted app must set it (SvelteKit reads `VITE_BRIDGE_API_BASE_URL` itself)
-- `packageManager` — from Step 1
-- `mode` — `frontend` (browser projects) or `backend` (NestJS, Express, Next.js server)
-- `identitySource` — from Step 2
-
-**Order:** Frontend first, then backend.
-
-If the CLI returns `HTTP 404`, the plugin hasn't published its flags guide yet. Tell the user that's the blocker and fall back to `@nebulr-group/bridge-auth-core` directly — `new BridgeFlags({ appId, baseUrl, mode })` + `bridge.setContext({...})` + `bridge.flag(...)`. The SDK shape is identical across frameworks; only the bindings differ.
-
-## Step 5 — Verify
-
-For each integrated project:
-
-1. **Build check** — run the project's build command (from `package.json` scripts)
-2. **Eval check** — read one flag (existing or freshly created) and confirm it returns the expected value
-3. **Context check** — confirm `identity` is set when the project uses any rolled-out rule
-4. **Gate check** — `npx @nebulr-group/bridge-cli check gates` in the project: every direct role, privilege, plan or plan-feature check it lists becomes a flag. Run it again until it is clean
-
-If anything fails, diagnose and fix before moving on.
-
-## Step 6 — Tell the developer what they just got
-
-Output the success message at the top of this prompt, personalised for what you actually did. Same rules as the auth master:
-
-- Fill every `[placeholder]` with real values
-- Strip any agent-only notes
-- Group by project if both frontend and backend were integrated
-- **Do not** write any text before the banner — start with the `█` character
-- If a build is broken or flag reads return defaults forever, prepend a single "Heads up:" line before the banner
-
-After delivering the message, the flags integration is complete.
-
-## Reference notes
-
-**Frontend vs backend:** The frontend SDK evaluates flags from a local cache hydrated at boot. The backend SDK (`mode: 'backend'`) evaluates per-request and requires an explicit `identity` for any rule using `rolloutPct < 100` — no anonymous bucketing.
-
-**Flags without Bridge Auth:** Flags work standalone. Pass your own `identity` and `attributes` when `identitySource` is "your own user model". If Bridge Auth is already installed, `user.role`, `privileges`, `tenant.plan` and the `bridge:billing.*` attributes (including `bridge:billing.entitlement.<feature>`) fill the eval context automatically, in the browser and on the NestJS backend alike.

package/dist/prompts/guide-coverage.json

@@ -1,17 +0,0 @@
-{
-  "_comment": "Which per-framework guides exist, keyed by the feature names `bridge guide <framework> <feature>` takes (the file stems under mcp/ in each plugin repo). The one copy: `bridge guide list` reads it from the package, and the Bridge MCP server reads it from GitHub (bridge-cli/main/bridge-cli/prompts/guide-coverage.json). Update it when a plugin adds or removes an mcp/*-prompt.md. `topics` lists the framework-agnostic guides bundled here (`bridge guide <topic>`).",
-  "aliases": { "flags": "feature-flags" },
-  "topics": {
-    "orientation": "What Bridge does: a short map to relay to the developer (bridge guide orientation)",
-    "fit-together": "How roles, plans, limits and flags fit together: the rule every decision guide builds on (bridge guide fit-together)",
-    "mechanisms": "How limits, the upgrade dialog and page customisation work (bridge guide mechanisms)"
-  },
-  "frameworks": {
-    "svelte": ["integration", "sdk-auth", "feature-flags", "billing", "team", "branding"],
-    "react": ["integration", "sdk-auth", "feature-flags", "billing", "team", "branding"],
-    "angular": ["integration", "sdk-auth", "feature-flags", "billing", "team", "branding"],
-    "nextjs": ["integration", "sdk-auth", "feature-flags", "billing", "team"],
-    "nestjs": ["integration", "auth", "feature-flags", "billing", "team"],
-    "express": ["integration", "auth", "feature-flags", "billing", "team"]
-  }
-}

package/dist/prompts/integration-success.md

@@ -1,106 +0,0 @@
-   ██████╗ ██████╗ ██╗██████╗  ██████╗ ███████╗
-   ██╔══██╗██╔══██╗██║██╔══██╗██╔════╝ ██╔════╝
-   ██████╔╝██████╔╝██║██║  ██║██║  ███╗█████╗
-   ██╔══██╗██╔══██╗██║██║  ██║██║   ██║██╔══╝
-   ██████╔╝██║  ██║██║██████╔╝╚██████╔╝███████╗
-   ╚═════╝ ╚═╝  ╚═╝╚═╝╚═════╝  ╚═════╝ ╚══════╝
-
-  ──────────────────────────────────────────────
-   Congratulations — [project-name] now has superpowers.
-
-    ✅  Authentication
-        UI for users to signup and login. Enable more
-        alternatives from the control center.
-
-    ✅  Locked by default
-        Every route protected. Unauth'd users
-        bounce to login automatically.
-
-    ✅  Multi-tenant ready
-        Teams · Orgs · Workspaces · RBAC
-        Tenant context flows through every request.
-
-    ✅  You know who's calling
-        [token-description]
-        One token. Every auth alternative covered.
-
-  ──────────────────────────────────────────────
-    The control center gives you even more powers.
-
-      ›  Billing            Stripe plans & subscriptions    →  bridge guide [framework] billing
-      ›  Feature flags      Per-user, per-plan toggles      →  bridge guide flags
-      ›  Team management    Invites, roles, orgs            →  bridge guide [framework] team
-
-    Run any of those when you're ready.
-
-    Go build the thing that actually matters.
-
-  ──────────────────────────────────────────────
-    Here is what I actually did:
-
-    [what-i-actually-did]
-
-    And here is what I changed:
-
-    [what-i-changed]
-  ──────────────────────────────────────────────
-
----
-AGENT SUBSTITUTION GUIDE (strip this section before outputting)
-
-PLACEHOLDER: project-name
-  Pick the most human-readable name available. Prefer in this order:
-    1. The folder name (e.g. "my-saas-app") — often more meaningful than the package name
-    2. The `name` field in package.json if it's descriptive
-  If both frontend and backend were integrated, combine them:
-    "my-saas-app + my-saas-api" or just the shared root folder name if obvious.
-
-PLACEHOLDER: framework
-  In the "control center" next-steps lines, replace `[framework]` with the
-  framework slug used by `bridge guide` (`svelte`, `react`, `nextjs`, `angular`,
-  `nestjs`, `express`). Use the frontend framework when both frontend and
-  backend were integrated. Leave `bridge guide flags` unchanged — that command
-  auto-detects the framework from `package.json`.
-
-PLACEHOLDER: token-description
-  One short line — the key identifiers the developer uses to access the
-  authenticated user in their specific framework. No explanation.
-  Examples:
-    Svelte:  profileStore · isAuthenticated · tokenStore
-    React:   useProfile() · useIsAuthenticated() · useToken()
-    NestJS:  @CurrentUser() on any endpoint
-    Express: req.user on any protected route
-  If both frontend and backend were integrated, combine on one line:
-    profileStore (frontend) · @CurrentUser() (backend)
-
-PLACEHOLDER: what-i-actually-did
-  3–5 bullet lines drawn from what actually happened in this session.
-  High-level outcomes in plain English — not file names.
-  If both frontend and backend were integrated, group under headings:
-
-    Frontend (my-saas-app):
-    ✅  Auth UI live — signup, login, password reset
-    ✅  All routes protected by default
-
-    Backend (my-saas-api):
-    ✅  All endpoints require a verified JWT
-    ✅  Authenticated user available on every request
-
-PLACEHOLDER: what-i-changed
-  The nitty-gritty. One line per actual change, drawn from what you did in this
-  session. Real package names, real file paths, real URLs, real values. Omit
-  anything that was skipped.
-  If both frontend and backend were integrated, group under headings:
-
-    Frontend (my-saas-app):
-    ✅  @nebulr-group/bridge-svelte installed
-    ✅  src/routes/+layout.ts — export const load = bridgeBootstrap({ rules })
-    ✅  src/routes/+layout.svelte — app wrapped in <BridgeBootstrap>
-    ✅  src/routes/auth/[...bridge]/+page.svelte — <BridgeAuthRoutes /> serves every sign-in page
-    ✅  .env configured with VITE_BRIDGE_APP_ID=abc123
-    ✅  Bridge app configured for http://localhost:5175
-
-    Backend (my-saas-api):
-    ✅  @nebulr-group/bridge-nestjs installed
-    ✅  AppModule — BridgeModule.forRoot({ guard: { global: true } }), every route needs a signed-in user
-    ✅  .env configured with BRIDGE_APP_ID=abc123

package/dist/prompts/mcp-tools.json

@@ -1,90 +0,0 @@
-{
-  "_comment": [
-    "The names of the Bridge MCP server's tools, and nothing else. The bundled guides are tested against this list: a guide that names a tool not in it fails src/__tests__/guide-decisions.test.ts.",
-    "Source: the `bridgeTools` registry in bridge-api, microservices/account/nebulr-api/mcp/tools/register.ts.",
-    "Generated, never edited by hand: in bridge-api run `bun scripts/generate-mcp-tools-json.ts > <bridge-cli>/bridge-cli/prompts/mcp-tools.json` (in the bridge-api container).",
-    "The count must equal the number of entries in `bridgeTools` (79 at the source below). bridge-api's guide-currency.spec.ts fails when this file and the registry disagree."
-  ],
-  "source": "bridge-api feature/tbp-806-plan-delete 1c622b17",
-  "tools": [
-    "add_plan_feature",
-    "add_redirect_uri",
-    "apply_plan",
-    "archive_plan",
-    "clear_flag_schedule",
-    "connect_stripe",
-    "create_api_token",
-    "create_app",
-    "create_feature_flag",
-    "create_plan",
-    "create_privilege",
-    "create_role",
-    "create_tenant",
-    "create_test_user",
-    "debug_auth_issue",
-    "delete_feature_flag",
-    "delete_plan",
-    "delete_privilege",
-    "delete_role",
-    "delete_tenant",
-    "diagnose_integration",
-    "evaluate_feature_flag",
-    "export_feature_flags",
-    "get_app",
-    "get_auth_config",
-    "get_branding",
-    "get_environment_info",
-    "get_flag",
-    "get_integration_guide",
-    "get_plan",
-    "get_role",
-    "get_server_info",
-    "get_setup_status",
-    "get_started",
-    "get_stripe_status",
-    "get_tenant",
-    "get_user",
-    "import_feature_flags",
-    "invite_user",
-    "list_api_tokens",
-    "list_apps",
-    "list_events",
-    "list_feature_flags",
-    "list_plan_quotas",
-    "list_plans",
-    "list_privileges",
-    "list_redirect_uris",
-    "list_roles",
-    "list_tenants",
-    "list_users",
-    "remove_plan_feature",
-    "remove_plan_price",
-    "remove_plan_quota",
-    "remove_redirect_uri",
-    "remove_user",
-    "revoke_api_token",
-    "scaffold_flags_integration",
-    "set_default_role",
-    "set_flag_schedule",
-    "set_plan_features",
-    "set_plan_price",
-    "set_plan_quota",
-    "set_tenant_plan",
-    "setup_communication",
-    "setup_payments",
-    "setup_sso",
-    "toggle_feature_flag",
-    "update_app",
-    "update_auth_methods",
-    "update_branding",
-    "update_feature_flag",
-    "update_password_policy",
-    "update_plan",
-    "update_privilege",
-    "update_role",
-    "update_tenant",
-    "update_user",
-    "use_app",
-    "verify_login"
-  ]
-}