omnigateway 0.5.1 → 0.6.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,
@@ -496,6 +512,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 +702,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