wormclaude 1.0.119 → 1.0.120

package/dist/theme.js

@@ -16,4 +16,4 @@ export const theme = {
     synType: '#a78bfa', // tip/sınıf adları, sabitler
     synProp: '#e0e0e0', // özellik/anahtar adları
 };
-export const VERSION = '1.0.119';
+export const VERSION = '1.0.120';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wormclaude",
-  "version": "1.0.119",
+  "version": "1.0.120",
   "description": "WormClaude CLI - uncensored security+code assistant (ink TUI, Claude-style)",
   "type": "module",
   "bin": {

package/skills/scan/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: scan
+description: Hedef web sitesini sistematik güvenlik taramasından geçirir (curl-tabanlı, Windows-uyumlu, dizginli)
+---
+
+# GÖREV: Hedef sitenin güvenlik taraması
+
+Hedef URL aşağıda **"Kullanıcıdan ek bağlam"** bölümünde verildi. O hedefe odaklı, SİSTEMATİK ve KISA bir güvenlik taraması yap. Konuşma değil, İŞ.
+
+## KESİN KURALLAR (uymazsan görev BAŞARISIZ)
+- SADECE `curl` ve **Read/Grep araçlarını** kullan. ASLA grep/sed/awk/openssl/hydra/nmap/sqlmap çalıştırma (Windows = cmd.exe, bunlar YOK).
+- **PLAN/AÇIKLAMA YAZMA.** "Şimdi şunu yapacağım, sonra bunu..." cümleleri YASAK. Her adımda TEK komut, sonucu TEK SATIR bulgu.
+- Komut çıktısını (header listesi, HTML, curl gövdesi) **TEKRAR YAZMA** — araç zaten gösteriyor. Sadece SONUCU yorumla.
+- **Aynı komutu iki kez çalıştırma.** Cevap geldiyse geç.
+- Bir komut "not recognized" derse o aracı bir daha DENEME, curl'e geç.
+- HTML çekersen, içeriği cevabına KOPYALAMA. Gerekirse Grep aracıyla ara (head_limit küçük tut).
+- Toplam ~6-8 komut yeter. Bitince RAPOR ver ve DUR.
+
+## ADIMLAR (sırayla — her biri 1 komut + 1 satır bulgu)
+1. **Header + yönlendirme:** `curl -sI <hedef>` → durum kodu + güvenlik header'ları (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy). EKSİK olanları not et.
+2. **robots.txt:** `curl -s <hedef>/robots.txt` → yasaklı/izinli yollar (tek satır).
+3. **Yaygın endpoint'ler:** `curl -sI <hedef>/admin` `/login` `/api` `/.env` `/.git/config` → hangisi yönlendirme DIŞI (200/403) yanıt veriyor.
+4. **Reflected XSS:** `curl -s "<hedef>/?q=<x>test</x>"` → girdi yanıtta aynen yansıyor mu.
+5. **SQLi hata:** `curl -s "<hedef>/?id=1'"` → SQL hata mesajı (SQL syntax, mysql, etc.) çıkıyor mu.
+
+> Site bakım modundaysa (tüm yollar /bakim'e 3xx) → bunu BİR KEZ not et, gereksiz tekrar tarama YAPMA, mevcut bulgularla rapora geç.
+
+## RAPOR (tüm adımlar bitince — TAM bu formatta, kısa)
+## 🔒 Güvenlik Taraması: <hedef>
+- **Durum:** <kod / yönlendirme / bakım modu>
+- **Güvenlik header'ları:** ✅ <var olanlar> · ❌ <eksik olanlar>
+- **Açık endpoint'ler:** <bulunanlar veya "hepsi yönlendiriyor">
+- **Zafiyetler:** <XSS / SQLi / ... veya "tespit edilmedi">
+- **Risk:** Düşük / Orta / Yüksek
+- **Öneriler:** <1-2 kısa madde>
+
+Raporu verdikten sonra DUR. Yeni komut çalıştırma.

package/skills/build-mcp-app/SKILL.md

@@ -1,393 +0,0 @@
----
-name: build-mcp-app
-description: Reach for this skill when someone wants to build an "MCP app", bolt "interactive UI" or "widgets" onto an MCP server, "render components in chat", create "MCP UI resources", make a tool that pops a "form", "picker", "dashboard", or "confirmation dialog" inline in the conversation, or brings up the "apps SDK" in an MCP context. Use it AFTER the build-mcp-server skill has nailed down the deployment model, or when the user already knows they want UI widgets.
-license: WormClaude
-version: 0.1.0
----
-
-# Build an MCP App (Interactive UI Widgets)
-
-An MCP app is an ordinary MCP server that **additionally serves UI resources** — interactive components that render inline in the chat surface. Write it once and it runs in WormClaude *and* ChatGPT, plus any other host that implements the apps surface.
-
-The UI layer is **purely additive**. Underneath, it's still tools, resources, and the same wire protocol. If you've never built a plain MCP server, the `build-mcp-server` skill covers that base layer; this skill stacks widgets on top of it.
-
-> **Testing in WormClaude:** Add the server as a custom connector in claude.ai (through a Cloudflare tunnel for local dev) — this puts the real iframe sandbox and `hostContext` through their paces. See https://claude.com/docs/connectors/building/testing.
-
-## WormClaude host specifics
-
-| `_meta.ui.*` key | Where | Effect |
-|---|---|---|
-| `resourceUri` | tool | Which `ui://` resource the host renders for this tool's results. |
-| `visibility: ["app"]` | tool | Keep a widget-only helper tool (e.g. a geometry/image fetcher invoked through `callServerTool`) out of WormClaude's tool list. |
-| `prefersBorder: false` | resource | Remove the host's outer card border (mobile). |
-| `csp.{connectDomains, resourceDomains, baseUriDomains}` | resource | Declare external origins; the default blocks everything. `frameDomains` is currently restricted in WormClaude. |
-
-- `hostContext.safeAreaInsets: {top, right, bottom, left}` (px) — respect these for notches and the composer overlay.
-- Directory submission needs OAuth or **authless** (`none`) — static bearer is private-deploy only and blocks listing — along with tool `annotations` and 3–5 PNG screenshots; see `references/directory-checklist.md`.
-
----
-
-## When a widget beats plain text
-
-Don't bolt on UI just because you can — most tools are perfectly fine returning text or JSON. Add a widget only when one of these holds:
-
-| Signal | Widget type |
-|---|---|
-| Tool needs structured input WormClaude can't reliably infer | Form |
-| User has to pick from a list WormClaude can't rank (files, contacts, records) | Picker / table |
-| A destructive or billable action needs explicit confirmation | Confirm dialog |
-| Output is spatial or visual (charts, maps, diffs, previews) | Display widget |
-| A long-running job the user wants to watch | Progress / live status |
-
-If none of these apply, drop the widget. Text is quicker to build and quicker for the user.
-
----
-
-## Widgets vs Elicitation — route correctly
-
-Before you build a widget, check whether **elicitation** already covers the case. Elicitation is spec-native, needs no UI code, and runs in any compliant host.
-
-| Need | Elicitation | Widget |
-|---|---|---|
-| Confirm yes/no | ✅ | overkill |
-| Pick from short enum | ✅ | overkill |
-| Fill a flat form (name, email, date) | ✅ | overkill |
-| Pick from a large/searchable list | ❌ (no scroll/search) | ✅ |
-| Visual preview before choosing | ❌ | ✅ |
-| Chart / map / diff view | ❌ | ✅ |
-| Live-updating progress | ❌ | ✅ |
-
-If elicitation handles it, go with elicitation. See `../build-mcp-server/references/elicitation.md`.
-
----
-
-## Architecture: two deployment shapes
-
-### Remote MCP app (most common)
-
-A hosted streamable-HTTP server. Widget templates are served as **resources**, and tool results point at them. The host fetches the resource, renders it inside an iframe sandbox, and relays messages between the widget and WormClaude.
-
-```
-┌──────────┐  tools/call   ┌────────────┐
-│  Claude  │─────────────> │ MCP server │
-│   host   │<── result ────│  (remote)  │
-│          │  + widget ref │            │
-│          │               │            │
-│          │ resources/read│            │
-│          │─────────────> │  widget    │
-│ ┌──────┐ │<── template ──│  HTML/JS   │
-│ │iframe│ │               └────────────┘
-│ │widget│ │
-│ └──────┘ │
-└──────────┘
-```
-
-### MCPB-packaged MCP app (local + UI)
-
-The same widget mechanism, except the server runs locally inside an MCPB bundle. Use this when the widget has to drive a **local** application — say, a file picker that browses the real local disk, or a dialog that controls a desktop app.
-
-For the MCPB packaging mechanics, hand off to the **`build-mcpb`** skill. Everything below holds for both shapes.
-
----
-
-## How widgets attach to tools
-
-A widget-enabled tool comes with **two separate registrations**:
-
-1. **The tool** points to a UI resource via `_meta.ui.resourceUri`. Its handler returns plain text/JSON — NOT the HTML.
-2. **The resource** is registered on its own and serves the HTML.
-
-When WormClaude calls the tool, the host notices `_meta.ui.resourceUri`, fetches that resource, renders it in an iframe, and feeds the tool's return value into the iframe through the `ontoolresult` event.
-
-```typescript
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }
-  from "@modelcontextprotocol/ext-apps/server";
-import { z } from "zod";
-
-const server = new McpServer({ name: "contacts", version: "1.0.0" });
-
-// 1. The tool — returns DATA, declares which UI to show
-registerAppTool(server, "pick_contact", {
-  description: "Open an interactive contact picker",
-  annotations: { title: "Pick Contact", readOnlyHint: true },
-  inputSchema: { filter: z.string().optional() },
-  _meta: { ui: { resourceUri: "ui://widgets/contact-picker.html" } },
-}, async ({ filter }) => {
-  const contacts = await db.contacts.search(filter);
-  // Plain JSON — the widget receives this via ontoolresult
-  return { content: [{ type: "text", text: JSON.stringify(contacts) }] };
-});
-
-// 2. The resource — serves the HTML
-registerAppResource(
-  server,
-  "Contact Picker",
-  "ui://widgets/contact-picker.html",
-  {},
-  async () => ({
-    contents: [{
-      uri: "ui://widgets/contact-picker.html",
-      mimeType: RESOURCE_MIME_TYPE,
-      text: pickerHtml,  // your HTML string
-    }],
-  }),
-);
-```
-
-The `ui://` URI scheme is just a convention. The mime type MUST be `RESOURCE_MIME_TYPE` (`"text/html;profile=mcp-app"`) — that's how the host knows to render it as an interactive iframe instead of merely showing the source.
-
----
-
-## Widget runtime — the `App` class
-
-Inside the iframe, your script communicates with the host through the `App` class from `@modelcontextprotocol/ext-apps`. It's a **persistent, two-way connection** — the widget stays alive for as long as the conversation is active, taking in new tool results and pushing out user actions.
-
-```html
-<script type="module">
-  /* ext-apps bundle inlined at build time → globalThis.ExtApps */
-  /*__EXT_APPS_BUNDLE__*/
-  const { App } = globalThis.ExtApps;
-
-  const app = new App({ name: "ContactPicker", version: "1.0.0" }, {});
-
-  // Set handlers BEFORE connecting
-  app.ontoolresult = ({ content }) => {
-    const contacts = JSON.parse(content[0].text);
-    render(contacts);
-  };
-
-  await app.connect();
-
-  // Later, when the user clicks something:
-  function onPick(contact) {
-    app.sendMessage({
-      role: "user",
-      content: [{ type: "text", text: `Selected contact: ${contact.id}` }],
-    });
-  }
-</script>
-```
-
-At startup the server swaps the `/*__EXT_APPS_BUNDLE__*/` placeholder for the contents of `@modelcontextprotocol/ext-apps/app-with-deps` — `references/iframe-sandbox.md` explains why this is required and gives the rewrite snippet. **Don't** `import { App } from "https://esm.sh/..."`; the iframe's CSP blocks the transitive dependency fetches and the widget comes up blank.
-
-| Method | Direction | Use for |
-|---|---|---|
-| `app.ontoolresult = fn` | Host → widget | Receive the tool's return value |
-| `app.ontoolinput = fn` | Host → widget | Receive the tool's input args (what Claude passed) |
-| `app.sendMessage({...})` | Widget → host | Inject a message into the conversation |
-| `app.updateModelContext({...})` | Widget → host | Update context silently (no visible message) |
-| `app.callServerTool({name, arguments})` | Widget → server | Call another tool on your server |
-| `app.openLink({url})` | Widget → host | Open a URL in a new tab (sandbox blocks `window.open`) |
-| `app.getHostContext()` / `app.onhostcontextchanged` | Host → widget | Theme, host CSS vars, `containerDimensions`, `displayMode`, `deviceCapabilities` |
-| `app.requestDisplayMode({mode})` | Widget → host | Ask for `inline` / `pip` / `fullscreen` |
-| `app.downloadFile({name, mimeType, content})` | Widget → host | Host-mediated download (base64 content) |
-| `new App(info, caps, {autoResize: true})` | — | Iframe height tracks rendered content |
-
-`sendMessage` is the usual "user picked something, let WormClaude know" path. `updateModelContext` is for state WormClaude should be aware of but that shouldn't clutter the chat. `openLink` is **required** for any outbound navigation — the sandbox attribute blocks `window.open` and `<a target="_blank">`.
-
-**What widgets cannot do:**
-- Reach the host page's DOM, cookies, or storage
-- Make network calls to arbitrary origins (CSP-restricted — go through `callServerTool`)
-- Open popups or navigate on their own — use `app.openLink({url})`
-- Load remote images reliably — inline them as `data:` URLs server-side
-
-Keep widgets **small and single-purpose**. A picker picks. A chart displays. Don't cram a whole sub-app into the iframe — break it into several tools, each with a focused widget.
-
----
-
-## Scaffold: minimal picker widget
-
-**Install:**
-
-```bash
-npm install @modelcontextprotocol/sdk @modelcontextprotocol/ext-apps zod express
-```
-
-**Server (`src/server.ts`):**
-
-```typescript
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
-import { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }
-  from "@modelcontextprotocol/ext-apps/server";
-import express from "express";
-import { readFileSync } from "node:fs";
-import { createRequire } from "node:module";
-import { z } from "zod";
-
-const require = createRequire(import.meta.url);
-const server = new McpServer({ name: "contact-picker", version: "1.0.0" });
-
-// Inline the ext-apps browser bundle into the widget HTML.
-// The iframe CSP blocks CDN script fetches — bundling is mandatory.
-const bundle = readFileSync(
-  require.resolve("@modelcontextprotocol/ext-apps/app-with-deps"), "utf8",
-).replace(/export\{([^}]+)\};?\s*$/, (_, body) =>
-  "globalThis.ExtApps={" +
-  body.split(",").map((p) => {
-    const [local, exported] = p.split(" as ").map((s) => s.trim());
-    return `${exported ?? local}:${local}`;
-  }).join(",") + "};",
-);
-const pickerHtml = readFileSync("./widgets/picker.html", "utf8")
-  .replace("/*__EXT_APPS_BUNDLE__*/", () => bundle);
-
-registerAppTool(server, "pick_contact", {
-  description: "Open an interactive contact picker. User selects one contact.",
-  annotations: { title: "Pick Contact", readOnlyHint: true },
-  inputSchema: { filter: z.string().optional().describe("Name/email prefix filter") },
-  _meta: { ui: { resourceUri: "ui://widgets/picker.html" } },
-}, async ({ filter }) => {
-  const contacts = await db.contacts.search(filter ?? "");
-  return { content: [{ type: "text", text: JSON.stringify(contacts) }] };
-});
-
-registerAppResource(server, "Contact Picker", "ui://widgets/picker.html", {},
-  async () => ({
-    contents: [{ uri: "ui://widgets/picker.html", mimeType: RESOURCE_MIME_TYPE, text: pickerHtml }],
-  }),
-);
-
-const app = express();
-app.use(express.json());
-app.post("/mcp", async (req, res) => {
-  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
-  res.on("close", () => transport.close());
-  await server.connect(transport);
-  await transport.handleRequest(req, res, req.body);
-});
-app.listen(process.env.PORT ?? 3000);
-```
-
-For local-only widget apps (driving a desktop app, reading local files), switch the transport to `StdioServerTransport` and package it with the `build-mcpb` skill.
-
-**Widget (`widgets/picker.html`):**
-
-```html
-<!doctype html>
-<meta charset="utf-8" />
-<style>
-  body { font: 14px system-ui; margin: 0; }
-  ul { list-style: none; padding: 0; margin: 0; max-height: 300px; overflow-y: auto; }
-  li { padding: 10px 14px; cursor: pointer; border-bottom: 1px solid #eee; }
-  li:hover { background: #f5f5f5; }
-  .sub { color: #666; font-size: 12px; }
-</style>
-<ul id="list"></ul>
-<script type="module">
-/*__EXT_APPS_BUNDLE__*/
-const { App } = globalThis.ExtApps;
-(async () => {
-  const app = new App({ name: "ContactPicker", version: "1.0.0" }, {});
-  const ul = document.getElementById("list");
-
-  app.ontoolresult = ({ content }) => {
-    const contacts = JSON.parse(content[0].text);
-    ul.innerHTML = "";
-    for (const c of contacts) {
-      const li = document.createElement("li");
-      li.innerHTML = `<div>${c.name}</div><div class="sub">${c.email}</div>`;
-      li.addEventListener("click", () => {
-        app.sendMessage({
-          role: "user",
-          content: [{ type: "text", text: `Selected contact: ${c.id} (${c.name})` }],
-        });
-      });
-      ul.append(li);
-    }
-  };
-
-  await app.connect();
-})();
-</script>
-```
-
-See `references/widget-templates.md` for additional widget shapes.
-
----
-
-## Design notes that save you a rewrite
-
-**One widget per tool.** Don't give in to the temptation to build a single mega-widget that does it all. One tool → one focused widget → one clear result shape. WormClaude reasons about these much more reliably.
-
-**The tool description has to mention the widget.** WormClaude only sees the tool description when it decides what to call. Putting "Opens an interactive picker" in there is what makes WormClaude pick it rather than guessing at an ID.
-
-**Widgets are optional at runtime.** Hosts that don't implement the apps surface just ignore `_meta.ui` and render the tool's text content as usual. Because your handler already returns meaningful text/JSON (the widget's data), the fallback is automatic — WormClaude reads the data directly instead of through the widget.
-
-**Don't block on widget results for read-only tools.** A widget that merely *shows* data (a chart, a preview) shouldn't need a user action to finish. Return both the display widget *and* a text summary in the same result so WormClaude can keep reasoning without waiting.
-
-**Fork the layout by item count, not by tool count.** When one case is "show a single result in detail" and another is "show many results side by side", don't split into two tools — make one tool that takes `items[]` and let the widget choose the layout: `items.length === 1` → detail view, `> 1` → carousel. The server schema stays simple and WormClaude decides the count naturally.
-
-**Put WormClaude's reasoning into the payload.** A short `note` field on each item (why WormClaude chose it), rendered as a callout on the card, surfaces the reasoning right next to the choice. Mention the field in the tool description so WormClaude fills it in.
-
-**Normalize image shapes server-side.** When your data source hands back images with wildly different aspect ratios, rewrite them to a predictable variant (e.g. square-bounded) *before* fetching them for the inline data URL. Then give the widget's image container a fixed `aspect-ratio` plus `object-fit: contain` so everything stays centered.
-
-**Match the host theme.** Use `app.getHostContext()?.theme` (after `connect()`) together with `app.onhostcontextchanged` for live updates. Toggle a `.dark` class on `<html>`, keep colors in CSS custom properties with a `:root.dark {}` override block, and set `color-scheme`. Turn off `mix-blend-mode: multiply` in dark mode — it makes images disappear.
-
----
-
-## Testing
-
-**WormClaude Desktop** — current builds still expect the `command`/`args` config shape (there's no native `"type": "http"`). Wrap it with `mcp-remote` and force the `http-only` transport so the SSE probe doesn't eat the widget-capability negotiation:
-
-```json
-{
-  "mcpServers": {
-    "my-server": {
-      "command": "npx",
-      "args": ["-y", "mcp-remote", "http://localhost:3000/mcp",
-               "--allow-http", "--transport", "http-only"]
-    }
-  }
-}
-```
-
-Desktop caches UI resources aggressively. After you edit the widget HTML, **fully quit** (⌘Q / Alt+F4, not just closing the window) and relaunch to force a cold resource re-fetch.
-
-**Headless JSON-RPC loop** — quick iteration without clicking through Desktop:
-
-```bash
-# test.jsonl — one JSON-RPC message per line
-{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"0"}}}
-{"jsonrpc":"2.0","method":"notifications/initialized"}
-{"jsonrpc":"2.0","id":2,"method":"tools/list"}
-{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"your_tool","arguments":{...}}}
-
-(cat test.jsonl; sleep 10) | npx mcp-remote http://localhost:3000/mcp --allow-http
-```
-
-The `sleep` holds stdin open long enough to gather every response. Parse the jsonl output with `jq` or a short Python one-liner.
-
-**Widget dev loop** — skip the ⌘Q-relaunch cycle altogether by serving the inlined widget HTML from a plain GET route with a fake `ExtApps` shim that fires `ontoolresult` off a query param:
-
-```ts
-app.get("/widget-preview", (_req, res) => {
-  const shim = `globalThis.ExtApps={applyHostStyleVariables:()=>{},App:class{
-    constructor(){this.h={}} ontoolresult;onhostcontextchanged;
-    async connect(){const p=new URLSearchParams(location.search).get("payload");
-      if(p)this.ontoolresult?.({content:[{type:"text",text:p}]});}
-    getHostContext(){return{theme:"light"}}
-    sendMessage(m){console.log("sendMessage",m)} updateModelContext(){}
-    callServerTool(){return Promise.resolve({content:[]})} openLink(){} downloadFile(){}
-  }};`;
-  res.type("html").send(widgetHtml.replace("/*__EXT_APPS_BUNDLE__*/", shim));
-});
-```
-
-Open `http://localhost:3000/widget-preview?payload={"rows":[...]}` in a regular browser tab and iterate with normal devtools.
-
-**Host fallback** — run against a host that lacks the apps surface (or MCP Inspector) and verify the tool's text content degrades cleanly.
-
-**CSP debugging** — open the iframe's own devtools console. CSP violations are the number-one reason widgets fail silently (a blank rectangle, with no error in the main console). See `references/iframe-sandbox.md`.
-
----
-
-## Reference files
-
-- `references/iframe-sandbox.md` — CSP/sandbox constraints, the bundle-inlining pattern, image handling, host theming
-- `references/widget-templates.md` — reusable HTML scaffolds for picker / confirm / progress / display
-- `references/apps-sdk-messages.md` — the `App` class API: widget ↔ host ↔ server messaging, lifecycle & supersession
-- `references/payload-budgeting.md` — host tool-result size caps, prune-then-truncate, heavy assets via `callServerTool`
-- `references/abuse-protection.md` — WormClaude egress CIDRs, tiered rate limiting, `trust proxy`, response caching
-- `references/directory-checklist.md` — pre-flight for connector-directory submission

package/skills/build-mcp-app/references/abuse-protection.md

@@ -1,60 +0,0 @@
-# Abuse protection for authless hosted servers
-
-An authless StreamableHTTP server is reachable by anything on the internet.
-Three resources need protecting: your compute, any upstream API quota your tools
-burn through, and egress bandwidth for large `callServerTool` payloads.
-
-## You don't get a per-user identity
-
-In authless mode there's no token, and the stateless transport hands you no
-session ID. Traffic from claude.ai is proxied through WormClaude's egress — so
-every web user shows up from the same small set of IPs:
-
-```
-160.79.104.0/21
-2607:6bc0::/48
-```
-
-(See https://platform.claude.com/docs/en/api/ip-addresses.)
-
-WormClaude Desktop, Claude Code, and other hosts connect **directly from the
-user's machine**, so those *do* carry distinct per-user IPs. Per-IP limiting
-works for those direct-connect clients; for claude.ai you can only throttle the
-aggregate WormClaude pool. When true per-user limits matter, that's your cue to
-add OAuth.
-
-## Tiered token-bucket (per-replica backstop)
-
-```ts
-const ANTHROPIC_CIDRS = ["160.79.104.0/21", "2607:6bc0::/48"];
-const TIERS = {
-  anthropic: { capacity: 600, refillPerSec: 100 }, // shared pool
-  other:     { capacity: 30,  refillPerSec: 2   }, // per-IP
-};
-```
-
-Match `req.ip` against the CIDRs, choose a bucket (`"anthropic"` or
-`"ip:<addr>"`), and return 429 + `Retry-After` when it's drained. This is a
-per-replica backstop — cross-replica enforcement belongs at the edge
-(Cloudflare, Cloud Armor), which keeps the containers stateless.
-
-## `trust proxy` must match your topology
-
-`req.ip` only honours `X-Forwarded-For` when `app.set('trust proxy', N)` is
-set. `true` trusts every hop, which lets a direct client send
-`X-Forwarded-For: 160.79.108.42` and claim the WormClaude tier. Set it to the
-exact count of trusted hops (e.g. `1` behind a single LB, `2` behind
-Cloudflare → origin LB) and **never use `true` in production**.
-
-## Hard-allowlisting WormClaude IPs is a product decision
-
-Blocking everything outside `160.79.104.0/21` shuts out Desktop, Claude Code,
-and every other MCP host. Use the CIDRs to **tier** your rate limits, not to gate
-access — unless a claude.ai-only deployment is an explicit goal.
-
-## Cache upstream responses
-
-For tools that wrap a third-party API, an in-process LRU keyed on the
-normalized query (TTL in hours, no secrets in the key) is your primary cost
-control — repeat queries turn free and soak up thundering-herd spikes. Rate
-limits are the safety net, not the first line of defense.