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

package/dist/prompts/decisions/look-and-feel.md

@@ -0,0 +1,62 @@
+# Look and feel — decision guide
+
+How Bridge's pages and emails look to the developer's users: the sign-in pages, the subscription pages, and the emails Bridge sends in the app's name.
+
+> Other decision guides: `bridge guide decision <name>` (MCP: resource `bridge://guides/decisions/<name>`). The customisation levels in full, with every design token: `bridge guide mechanisms`.
+
+## Two places pages can live
+
+- **Hosted:** Bridge serves sign-in on its own address. Styled with the app's **branding** (colours, font, corner radius), which Bridge stores.
+- **In the app:** the same pages render inside the developer's own layout, on their address. Styled with CSS design tokens (`--bridge-*`) in the app's own stylesheet.
+
+Both use the same single route file; one setting switches sign-in into the app (`loginRoute: '/auth/login'` in SvelteKit's `bridgeBootstrap()`). Subscription pages always render in the app.
+
+## Start from what is there
+
+| Read | MCP | CLI |
+|---|---|---|
+| Hosted-page branding | `get_branding` | `bridge branding get` |
+| App name, and the email sender | `get_app` | `bridge app get` |
+
+## Ask the developer
+
+Product questions. Ask, wait, never guess.
+
+1. **Should sign-in look like part of the app, on the app's own address, or is Bridge's hosted page fine?**
+2. **What are the brand colours and font?** Ask for exact values or point at their existing stylesheet; do not pick colours for them.
+3. **What name should users see** on sign-in pages and in emails?
+4. **Which address and sender name should emails come from?** (Invitations, password resets, magic links.)
+5. **Beyond colours, should sign-in pages say anything of their own?** A different heading, a frame around the form, a page they design themselves.
+
+## Decide yourself
+
+Climb only as far as the answers require, and say which level you stopped at.
+
+- **Level 0, nothing:** in-app pages already sit inside the app's layout, so its header and navigation surround them. Reason: often this alone is enough.
+- **Level 1, tokens:** set `--bridge-primary`, `--bridge-border-radius` and friends on `:root`. Reason: tokens are the supported contract; ordinary CSS already wins over Bridge's defaults, so there is never a need for `!important`.
+- **Level 2, frame and heading:** pass the `frame` and `heading` snippets to the sign-in routes component. Reason: it changes every page at once and keeps each page's own sub-steps.
+- **Level 3, take over one page:** create that page's own route file (e.g. `src/routes/auth/login/+page.svelte`); every other page keeps working.
+- **Level 4, headless:** build everything on `getBridgeAuth()`. Only when the developer asks for it.
+- **Never copy Bridge's components into the app to restyle them.** Reason: the copy stops receiving fixes.
+- **When both hosted pages and in-app pages are used, give them the same colours.** Reason: a person moving between them should not notice.
+- **A new sender address must be confirmed.** Bridge emails that address a link; until it is clicked, mail keeps coming from Bridge's default sender. Tell the developer to look for it.
+
+## Do it
+
+| Step | MCP | CLI |
+|---|---|---|
+| Hosted-page colours, font, corners | `update_branding` | `bridge branding update --primary-btn-bg '#1a1a2e' --font-family Inter` |
+| Name users see | `update_app` (`name`) | `bridge app update --name "Acme"` |
+| Email sender | `setup_communication` | `bridge setup communication --from-address no-reply@acme.com --from-name Acme` |
+| In-app pages, tokens, snippets | `get_integration_guide` (topic `branding`, then `auth`) | `bridge guide svelte branding`, `bridge guide mechanisms` |
+
+## Prove it
+
+1. Open the sign-in page and the subscription page in the running app (or the hosted page): colours and font match what the developer gave.
+2. Trigger a password reset for a test user: the email arrives from the agreed sender, in the app's name, and its link opens the app, not a Bridge page.
+
+## Where this connects
+
+- **Login:** hosted or in-app sign-in is the same switch.
+- **Payments:** the subscription and plan-choice pages use the same tokens.
+- **Going live:** a verified sender address before real users arrive.

package/dist/prompts/decisions/payments.md

@@ -0,0 +1,81 @@
+# Payments and plans — decision guide
+
+What customers pay, what each plan includes, and what happens when they reach a limit. A **plan** belongs to a workspace, not to a person. It carries the price, the trial and the limits ("3 projects on Free, 50 on Pro"). Payments run through the developer's own Stripe account.
+
+> Other decision guides: `bridge guide decision <name>` (MCP: resource `bridge://guides/decisions/<name>`). The full model behind limits and upgrade prompts: `bridge guide mechanisms`.
+
+## Start from what is there
+
+| Read | MCP | CLI |
+|---|---|---|
+| Plans with prices and limits | `list_plans` | `bridge plan list` |
+| Every metric the plans already limit, with its kind | `list_plan_quotas` | `bridge plan quota list` |
+| Whether Stripe is connected and its webhook works | `get_stripe_status` | `bridge stripe status` |
+| Whether new customers must pick a plan first (`paymentsAutoRedirect`) | `get_app` | `bridge app get` |
+
+## Ask the developer
+
+Product questions. Ask, wait, never guess. Then show the answer back as tables (plans, prices, limits) and create nothing until the developer confirms them.
+
+1. **Which plans, and what are they called?** Is there a free one?
+2. **What does each paid plan cost, in which currency, and monthly, yearly or both?**
+3. **Is there a free trial, and how many days?**
+4. **What does each plan limit, and how much?** In their words: "2 tickets on Free, 100 on Pro", "10 seats", "1,000 exports a month".
+5. **For each limit: at the limit, block, or keep going and charge per extra unit?** If they charge, how much per unit?
+6. **Which features are only on some plans?** ("Analytics on Pro only.")
+7. **Do they want a welcome page for new customers** where they choose a plan? Offer it; create it only if they say yes.
+
+## Decide yourself
+
+- **Plan keys short and lower-case: `free`, `pro`, `team`.** Reason: the key is permanent and is what code, flag rules and tokens use; the name can change any time.
+- **Monthly and yearly prices of one tier are one plan with two prices,** never `pro-monthly` and `pro-yearly`. Reason: the subscription page then shows one plan with a monthly/yearly switch.
+- **A free plan gets a price of 0.** Reason: a plan with no price cannot be assigned to a workspace.
+- **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. Exports, AI completions and emails are counters (reset each billing period). Tickets, projects and stored files are gauges (never reset). Decide from that sentence and say which you chose.
+- **Seats are the built-in `users` metric, a gauge.** Reason: Bridge counts workspace members itself.
+- **Reuse metric names the app already has** (`list_plan_quotas`) before inventing new ones. Reason: two names for one thing split the count.
+- **Connect Stripe with test keys first; live keys only when going live.** Reason: nobody is charged while you build. Use `setup_payments` / `bridge setup payments`: it stores the keys and switches payments on in one step.
+- **Connect Stripe before adding paid prices.** Reason: each price is created in Stripe as it is saved.
+- **Leave "customers must pick a plan" on** (it is on by default) unless the developer says otherwise. Reason: a new workspace then always has a plan, so every limit and feature check has something to read.
+- **One plan, one call:** `apply_plan` / `bridge plan apply` sets name, trial, prices and limits together. Reason: a plan is never left half set up.
+
+## How a hard limit is enforced, end to end
+
+Tell the developer this plainly; it is where integrations go wrong.
+
+1. **The plan holds the number.** A limit is a quota on the plan: metric, limit, `hard`, and `counter` or `gauge`.
+2. **The backend enforces it, and only the backend.** In NestJS one decorator on the handler that creates the thing: `@RequireQuota('exports')`. Before the handler runs, a workspace at its limit gets `402` with `{ code: 'QUOTA_EXCEEDED', metric, used, limit, fix }` and the handler never runs. After a `2xx` answer, Bridge records one use. Nothing else to wire: no usage call, no counter table. If Bridge cannot answer, the request is refused with `503`, never let through.
+3. **Gauges send the app's own count.** `@RequireQuota('tickets', { current })` on create and `@SyncQuota('tickets', { current })` on delete, where `current` returns the app's count from its own database. There is no decrement.
+4. **Seats need no count at all.** `@RequireQuota('users')` on the invite handler checks the seat limit.
+5. **The frontend only explains the refusal.** With no code at all, the upgrade dialog opens on a `402`, names the limit, and links to the subscription page. A member who cannot manage billing is told to ask the owner. Disabling a button before the click (`<QuotaGate>`) or showing "8 of 10" (`useQuota`) is optional.
+6. **A frontend alone cannot enforce a limit.** Anyone can call the API directly. An app with no backend can report usage from the browser, but that is self-reported: Bridge counts what the client says.
+7. **`metered` never blocks.** Past the included amount it bills per unit through Stripe.
+8. **A plan feature is a hard limit nothing counts.** `analytics` with limit 1 on `pro` makes `@RequireEntitlement('analytics')` and `<Entitled to="analytics">` true on Pro and false elsewhere. Never put `@RequireEntitlement` and `@RequireQuota` on the same name: at the cap the entitlement answers `403` first and the upgrade dialog never opens.
+9. **The plan-choice page** (`/subscription/plan`) appears only when the app has plans and "customers must pick a plan" is on. Turn it off with `update_app` (`paymentsAutoRedirect: false`) / `bridge app update --payments-auto-redirect false`.
+
+Whether a paid feature is a plan feature or a flag with a plan rule is decided in the **feature-control** guide.
+
+## Do it
+
+| Step | MCP | CLI |
+|---|---|---|
+| Connect Stripe (keys from the developer) | `setup_payments` | `bridge setup payments --stripe-key sk_test_… --stripe-public-key pk_test_…` |
+| Set up or reshape one plan in one call | `apply_plan` | `bridge plan apply --spec @plan.json` |
+| Or step by step: create a plan with its first price | `create_plan` | `bridge plan create --key pro --name Pro --amount 29 --interval month` |
+| Add another price | `set_plan_price` | `bridge plan price set pro --amount 290 --interval year` |
+| Add a limit | `set_plan_quota` | `bridge plan quota set pro --metric tickets --limit 100 --policy hard --kind gauge` |
+| Turn off the forced plan choice | `update_app` | `bridge app update --payments-auto-redirect false` |
+| Code for the framework | `get_integration_guide` (topic `billing`) | `bridge guide billing --framework svelte`, `bridge guide billing --framework nestjs` |
+
+## Prove it
+
+1. `list_plans` / `bridge plan list` matches the tables the developer confirmed; a plan with monthly and yearly pricing is one plan.
+2. `get_stripe_status` / `bridge stripe status`: connected, webhook working.
+3. At the limit, send the decorated request with curl: it answers `402 QUOTA_EXCEEDED`. In the app, the upgrade dialog opens and names the limit.
+4. A paid plan opens Stripe Checkout and returns to the subscription page with the new plan.
+
+## Where this connects
+
+- **Feature control:** features that depend on the plan.
+- **Teams:** seats, and the plan belonging to the workspace.
+- **Roles:** who may change the plan.
+- **Going live:** live Stripe keys.

package/dist/prompts/decisions/roles.md

@@ -0,0 +1,72 @@
+# Roles and permissions — decision guide
+
+Who may do what inside a customer's workspace. A **role** (Owner, Admin, Editor…) is a named bundle of **privileges** (`USER_WRITE`, `INVOICE_APPROVE`…). Every signed-in person has one role per workspace, and their token carries its role key and privileges, so the backend can check them on every request.
+
+> Other decision guides: `bridge guide decision <name>` (MCP: resource `bridge://guides/decisions/<name>`). How the pieces work underneath: `bridge guide mechanisms`.
+
+## Which tool answers which question
+
+Three different questions, three different tools. Keep them apart.
+
+| The question | Answered by | Guide |
+|---|---|---|
+| Who, inside a workspace, may do this? | a **role** and its privileges | this one |
+| Is this feature on for them at all? | a **flag** | feature-control |
+| How much do they get (projects, seats, exports)? | the **plan** | payments |
+
+A role never stands in for a plan ("Pro users are Admins") and a plan never stands in for a role.
+
+## Start from what is there
+
+| Read | MCP | CLI |
+|---|---|---|
+| Roles, their privileges, and which is the default | `list_roles` | `bridge role list` |
+| One role in full | `get_role` | — |
+| Privileges that exist | `list_roles` (the `privileges` map) | `bridge privilege list` |
+
+A new app has two roles: **Owner** (`OWNER`, everything, including permanent deletes) and **Admin** (`ADMIN`, manage people, read workspace settings). **Owner is the default role**, which means anyone invited without a role becomes an Owner.
+
+## Ask the developer
+
+Product questions. Ask, wait, never guess.
+
+1. **What kinds of people use one customer's workspace?** For example: the person who pays, people who manage the team, people who do the work, people who only look.
+2. **For each kind, what may they do that others may not?** Ask in the app's own verbs: approve an invoice, delete a project, invite a colleague, change billing.
+3. **Which role should a newly invited person get?** Owner is rarely the right answer.
+4. **Who may manage the subscription and billing?**
+
+## Decide yourself
+
+- **Name privileges after actions, in capitals: `PROJECT_DELETE`, `INVOICE_APPROVE`.** Reason: they read like the existing ones (`USER_READ`, `TENANT_WRITE`) and say exactly what they allow.
+- **Role keys in capitals too: `EDITOR`, `VIEWER`.** Reason: the token carries the key exactly as written, and a flag rule on `user.role` compares it case for case.
+- **In code, check a privilege, not a role name.** Reason: roles get reshaped as the product grows; the privilege on a handler stays true.
+- **Keep Owner as the one role with everything.** Never strip it: it is the only role that can delete, and every workspace needs someone who can.
+- **Make the lowest sensible role the default** by creating it with the default setting on. Reason: a forgotten role on an invitation then gives too little, not too much.
+- **When changing a role's privileges, send the full list.** Reason: the update replaces the list, and anything left out is revoked.
+- **Enforce on the backend; hide buttons in the frontend only as a courtesy.** Reason: anyone can call the API directly.
+
+## Do it
+
+| Step | MCP | CLI |
+|---|---|---|
+| Add a privilege | — | `bridge privilege create --key PROJECT_DELETE --description …` |
+| Create a role | `create_role` | `bridge role create --key EDITOR --name Editor --privileges PROJECT_READ,PROJECT_WRITE` |
+| Create it as the new default | `create_role` (`isDefault: true`) | `bridge role create --key MEMBER --name Member --privileges … --is-default` |
+| Change a role's privileges | `update_role` (full list) | `bridge role update --key EDITOR --privileges …` (full list) |
+| Give a person a role | `update_user` | `bridge user update --email … --role EDITOR --tenant-id …` |
+| Code for the framework | `get_integration_guide` (topic `team`) | `bridge guide nestjs` (backend checks), `bridge guide svelte team` |
+
+On the NestJS backend the check is a decorator on the handler: `@RequirePrivilege('PROJECT_DELETE')`, or `@RequireRole('ADMIN')` when the developer really means a role.
+
+Setting the default on one role clears it from the previous default.
+
+## Prove it
+
+1. `list_roles` / `bridge role list` shows each role with exactly the privileges agreed, and the default where the developer wanted it.
+2. Call a protected backend route as a user whose role lacks the privilege: it must answer 403. Then with one who has it: it must succeed.
+
+## Where this connects
+
+- **Teams:** the role an invited person gets.
+- **Feature control:** a flag can target `user.role`, but "may this person do it" is still a privilege check on the backend.
+- **Payments:** who may change the plan.

package/dist/prompts/decisions/teams.md

@@ -0,0 +1,56 @@
+# Teams and workspaces — decision guide
+
+How customers are grouped in the developer's app. In Bridge every signed-in person belongs to a **workspace** (the API and the CLI call it a tenant). A workspace is one customer: it holds the people, their roles, and the plan the customer pays for.
+
+> Other decision guides: `bridge guide decision <name>` (MCP: resource `bridge://guides/decisions/<name>`). How the pieces work underneath: `bridge guide mechanisms`.
+
+## Start from what is there
+
+| Read | MCP | CLI |
+|---|---|---|
+| Whether people can create their own workspace (`tenantSelfSignup`) | `get_app` | `bridge app get` |
+| Existing workspaces | `list_tenants` | `bridge tenant list` |
+| The people in one workspace | `list_users` | `bridge user list --tenant-id <id>` |
+| Roles an invited person can get | `list_roles` | `bridge role list` |
+
+## Ask the developer
+
+Product questions. Ask, wait, never guess.
+
+1. **Is the app for single people or for teams?** With teams, a customer invites colleagues into a shared workspace. For single people, each person simply has a workspace of their own and never sees the word.
+2. **How does someone get in the first time?** Either they sign up and get a new workspace of their own, or they can only join by invitation from someone already inside.
+3. **When someone is invited, which role should they get?** See the **roles** guide: on a new app the default role is Owner, so an invitee without a role becomes an Owner.
+4. **Does the number of people per workspace depend on the plan?** ("1 user on Free, 10 on Pro.") If yes, that is a seat limit: see the **payments** guide.
+5. **Can one person belong to several workspaces?** Bridge supports it and shows a workspace picker at sign-in; the question is whether the developer wants to offer it in their product.
+
+## Decide yourself
+
+- **Self-signup on for a product people try on their own; off for invitation-only products.** Take it from the answer to question 2 and set `tenantSelfSignup` to match. Reason: with it off, a stranger who signs up has nowhere to land.
+- **Use Bridge's team panel for inviting and managing people** (`TeamManagementPanel` in SvelteKit) rather than a page of your own. Reason: it already handles invitations, role changes and removal against the right permissions.
+- **Seats are the built-in `users` limit.** Reason: Bridge counts workspace members itself, so there is nothing for the app to count or report.
+- **Never create workspaces from the app's own code for sign-ups.** Reason: Bridge creates one at signup when self-signup is on; creating them elsewhere makes duplicates.
+- **Create workspaces by hand only for setup and support** (an existing customer you are migrating, or a demo).
+
+## Do it
+
+| Step | MCP | CLI |
+|---|---|---|
+| Allow or stop self-signup | `update_app` (`tenantSelfSignup`) | `bridge app update --tenant-self-signup true` |
+| Create a workspace by hand | `create_tenant` | `bridge tenant create --name … --owner-email …` |
+| Invite someone into a workspace | `invite_user` | `bridge user invite --email … --role … --tenant-id …` |
+| Change someone's role | `update_user` | `bridge user update --email … --role … --tenant-id …` |
+| Limit seats per plan | `set_plan_quota` (metric `users`, kind `gauge`) | `bridge plan quota set pro --metric users --limit 10 --policy hard --kind gauge` |
+| Code for the framework | `get_integration_guide` (topic `team`) | `bridge guide svelte team` |
+
+Pass a role key on every invitation you make on the developer's behalf; leaving it out gives the app's default role.
+
+## Prove it
+
+1. Create a test user (`create_test_user` / `bridge test-user create`) and sign in (`verify_login` / `bridge test-user verify`): the response names the workspace.
+2. Invite a second address into that workspace and check it appears in `list_users` / `bridge user list` with the role you meant.
+
+## Where this connects
+
+- **Roles:** what each person in a workspace may do.
+- **Payments:** a plan belongs to the workspace, not to a person; seats are a plan limit.
+- **Login:** whether sign-up is open at all.

package/dist/prompts/flags/master.md

@@ -19,7 +19,7 @@ Each plugin repo owns its own framework-specific prompt under `mcp/feature-flags
 
 `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.
+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
 
@@ -63,7 +63,7 @@ Track as you work:
 
 ## Mental model (1-minute version)
 
-A flag in  has:
+A flag has:
 
 | Field | Possible values |
 |---|---|
@@ -75,7 +75,7 @@ A flag in  has:
 
 Branches are first-match-wins; conditions within a branch AND together; `rolloutPct` is rule-level (0-100) and requires `identity` on the eval context.
 
-The SDK call is the same everywhere — `bridge.flag(key, defaultValue)`. The return type is inferred from `defaultValue`, so no casts.
+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
 
@@ -95,7 +95,7 @@ Scan the current directory and its immediate subdirectories for `package.json` f
    - `@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 the unified `useBridge()` is already in place.
+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.
 
@@ -167,8 +167,8 @@ Where `<name>` is one of: `svelte`, `react`, `nextjs`, `angular`, `nestjs`, `exp
 
 **Every per-framework guide covers this contract:**
 
-- **Install** — the right package + version + import path (`/flags` entry point so auth code isn't pulled in unnecessarily)
-- **Bootstrap** — provider / module / factory setup, `appId` + `baseUrl` + `mode` config
+- **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`
@@ -177,14 +177,14 @@ Where `<name>` is one of: `svelte`, `react`, `nextjs`, `angular`, `nestjs`, `exp
 
 **Pass these values from this master to the per-framework prompt:**
 - `appId` — from Step 3
-- `baseUrl` — `https://api.thebridge.dev` (default; only override for self-hosted)
+- `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.
+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
 

package/dist/prompts/integration-success.md

@@ -94,14 +94,13 @@ PLACEHOLDER: what-i-changed
 
     Frontend (my-saas-app):
     ✅  @nebulr-group/bridge-svelte installed
-    ✅  src/routes/+layout.ts wired with bridgeBootstrap()
-    ✅  src/routes/+layout.svelte rendering <BridgeBootstrap>
-    ✅  OAuth callback route at /auth/oauth-callback
+    ✅  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
-    ✅  BridgeModule registered in AppModule
-    ✅  Global JWT guard applied
+    ✅  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

@@ -0,0 +1,77 @@
+{
+  "_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.",
+    "Regenerate from the thebridge-platform root when a tool is added, renamed or removed: grep -hoE \"^ {2,4}name: '[a-z]+(_[a-z]+)+',\" bridge-api/microservices/account/nebulr-api/mcp/tools/*.ts | sed -E \"s/.*'(.*)'.*/\\1/\" | sort -u",
+    "The count must equal the number of entries in `bridgeTools` (66 at the source below). The twin of this check in bridge-api reads the live registry instead of this copy."
+  ],
+  "source": "bridge-api feature/mcp-journey 689899e",
+  "tools": [
+    "add_redirect_uri",
+    "apply_plan",
+    "clear_flag_schedule",
+    "connect_stripe",
+    "create_api_token",
+    "create_app",
+    "create_feature_flag",
+    "create_plan",
+    "create_role",
+    "create_tenant",
+    "create_test_user",
+    "debug_auth_issue",
+    "delete_feature_flag",
+    "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_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_redirect_uris",
+    "list_roles",
+    "list_tenants",
+    "list_users",
+    "remove_plan_price",
+    "remove_plan_quota",
+    "remove_redirect_uri",
+    "remove_user",
+    "revoke_api_token",
+    "scaffold_flags_integration",
+    "set_flag_schedule",
+    "set_plan_price",
+    "set_plan_quota",
+    "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_role",
+    "update_tenant",
+    "update_user",
+    "use_app",
+    "verify_login"
+  ]
+}