service-bridge 2.0.0-alpha.3 → 2.0.0-alpha.6

package/README.md

@@ -41,6 +41,7 @@ You declare what your service handles and what it calls. ServiceBridge does the
 
 - [Install](#install)
 - [AI coding skill](#ai-coding-skill)
+- [CLI](#cli)
 - [Why ServiceBridge](#why-servicebridge)
 - [Use cases](#use-cases)
 - [Quick start](#quick-start)
@@ -110,6 +111,18 @@ Restart the agent so it loads the skill. Source and contents: [`node/skill/`](ht
 
 ---
 
+## CLI
+
+The runtime ships with `sb`, a command-line client for managing services, traces, events, jobs, workflows, alerts and settings. It comes with the runtime image — there is no separate install — so a running runtime already has it at `/usr/local/bin/sb`. Use `docker exec <container> sb …` or the host binary, and pass `-o json` to get machine-readable output for AI agents. Check it with:
+
+```sh
+sb version
+```
+
+Full command reference: **[servicebridge.dev/#docs/cli](https://servicebridge.dev/#docs/cli)**.
+
+---
+
 ## Why ServiceBridge
 
 Microservices rarely fail because of business logic. They fail in the gaps *between* services — the broker that dropped a message, the workflow engine nobody fully understands, the trace that stops at a service boundary, the mesh config that takes a week to debug. Each gap is another system to run, secure and correlate.

package/dist/http/express/index.d.ts

@@ -1,5 +1,5 @@
 import { Express } from 'express';
-import { p as ServiceBridge } from '../../service-bridge-B1sZmWdS.js';
+import { p as ServiceBridge } from '../../service-bridge-DGZXGuhl.js';
 import '@grpc/grpc-js';
 import '@bufbuild/protobuf/wire';