omnigateway 0.5.1 → 0.7.0

package/README.md

@@ -27,6 +27,12 @@ omni start
 - **Filters bulky tool history, optionally.** Built-in RTK filters shorten
   eligible large or repetitive shell and recognizable command output before
   provider dispatch, preserve errors and non-tool-result content, and default off.
+- **Enforces a coding style, optionally.** With `ponytailMode` set, the gateway
+  appends the [ponytail](https://github.com/DietrichGebert/ponytail) ruleset —
+  build the smallest thing that works — to the system prompt of every request,
+  so any client gets it without installing anything. About 1,240 tokens, cached
+  with the prompt it joins; skipped when the client already carries it.
+  Defaults off.
 - **Routes across your accounts.** Define a virtual model like `fast` or
   `smart` with several targets; the gateway ranks them by tier, health,
   remaining quota, cost, latency, and current load.
@@ -70,23 +76,28 @@ graph TD
   store["@omni/store<br/><i>SQLite + field encryption</i>"]
   providers["@omni/providers<br/><i>adapters, wire codecs,<br/>catalog, HTTP client</i>"]
   rtk["@omni/rtk<br/><i>tool-result filters</i>"]
+  ponytail["@omni/ponytail<br/><i>vendored coding ruleset</i>"]
   ratelimit["@omni/ratelimit<br/><i>key limit arithmetic;<br/>no clock, no state</i>"]
   ir["@omni/ir<br/><i>domain model — depends on nothing</i>"]
 
   gateway --> control
   gateway --> rtk
+  gateway --> ponytail
   gateway --> ratelimit
   cli --> control
-  dashboard -. "types + catalog only" .-> providers
+  dashboard -. "types only" .-> ir
   dashboard -. "types only" .-> store
   control --> router
+  control --> ponytail
   control --> ratelimit
   router -. "types + 2 pure helpers,<br/>via /types subpath" .-> store
   router --> providers
   store --> rtk
+  store --> ponytail
   store --> ratelimit
   providers --> ir
   rtk --> ir
+  ponytail --> ir
   store --> ir
 ```
 
@@ -103,9 +114,14 @@ even `@omni/ir`. The rings and the in-flight gauge live in the gateway, because
 state is not the package's job, and that split is what lets sliding-window
 arithmetic be tested without a gateway, a store, or a clock.
 
-The dashboard's edges are dotted because they are type-level only.
-`@omni/providers/catalog` is deliberately kept import-free so model lists can be
-bundled into the browser without dragging in the HTTP client.
+The dashboard's edges are dotted because they are type-level only. It has no edge
+to `@omni/providers` at all: provider names, colours, order and model lists reach
+the console over `GET /api/catalog`, because a provider loaded from
+`<root>/plugins/` exists only at runtime and no build-time import could see one.
+
+`@omni/providers/catalog` and `/descriptors` are still deliberately import-free,
+for a different reason than they used to be: the pure router imports
+`descriptors`, and the leaf property is what lets it.
 
 The router's dotted edge into `@omni/store` is nearly the same story: its
 package-root imports are all `import type`. Two pure arithmetic helpers,
@@ -166,6 +182,9 @@ Connect an account. The CLI prints a URL to open, and waits:
 omni connect anthropic     # or: openai, kimi, kilo, grok
 ```
 
+An installed [plugin](#plugins) that supplies its own provider is connected the
+same way, under its plugin id.
+
 Every provider also takes a plain API key, if that is what you hold rather than
 a subscription:
 
@@ -496,6 +515,7 @@ Everything else lives in the database rather than the environment, so it can be
 changed without a restart: the six routing weights, `maxAttempts`,
 `requestDeadlineMs`, the circuit breaker's `breakerThreshold` and
 `breakerCooldownMs`, `logRetentionDays`, `quotaPollIntervalMs`, `rtkEnabled`,
+`ponytailMode` (`off` | `lite` | `full` | `ultra`),
 and the two body-capture switches. Edit them with `omni settings set` or in the
 console. `quotaPollIntervalMs` is the one exception: the poller reads it once at
 boot, so a change to it takes a restart. Snapshot retention —
@@ -685,7 +705,8 @@ Worth knowing before you deploy it:
 
 ## Plugins
 
-A plugin adds routes, storage, and a screen in the console to one installation,
+A plugin adds routes, storage, a provider, and a screen in the console to one
+installation,
 without being part of OmniGateway. Most installations run none.
 
 ```bash
@@ -723,13 +744,26 @@ and whether the gateway would load it:
 
 ```
 ID       NAME               VERSION  API  SDK     CAPABILITIES                    STATE
-pokemon  Pokémon Companion  1.0.0    1    ^1.0.0  storage,files,net:outbound,…    ok
+pokemon  Pokémon Companion  1.0.0    2    ^1.0.0  storage,files,net:outbound,…    ok
 ```
 
+The API column is the plugin API generation, and it is matched **exactly** — a
+plugin built against an older one is listed with that as its reason rather than
+loaded.
+
 The capabilities a manifest may declare are `storage`, `files`, `net:outbound`,
-`events:request`, `events:limit` and `channels` — the last being namespaced
-topics on the gateway's push socket, which a plugin owns without ever touching a
-connection. Anything a plugin did not declare is absent from what it is handed.
+`events:request`, `events:limit`, `channels` and `provider`. `channels` is
+namespaced topics on the gateway's push socket, which a plugin owns without ever
+touching a connection. `provider` lets a plugin supply a provider of its own —
+the models, the wire format, and optionally the OAuth flow, so
+`omni connect <plugin-id>` works for it exactly as it does for a built-in.
+Anything a plugin did not declare is absent from what it is handed.
+
+`net:outbound` and `provider` each require the manifest to declare `origins`,
+and both are enforced: a plugin's own `fetch` and the requests the gateway makes
+on a provider plugin's behalf are both refused outside them. That is what makes
+`omni plugin verify <id>` worth reading before you install one — where your
+prompts can be sent is in the manifest, not only in the code.
 
 A plugin that would *not* load is listed with the reason rather than hidden,
 because a plugin missing from the console is exactly what you are trying to