toolfunnel 0.4.0 → 0.6.0

package/docs/KNOWN_BUGS.md

@@ -1,225 +1,99 @@
-# ToolFunnel — 0.4.0 Board (bugs + features)
-
-> Items 1–5: findings from a full source review on **2026-07-03** (v0.3.0, commit `1c5841c`),
-> each ranked, located, explained, and paired with a proposed fix.
-> **All five FIXED 2026-07-06** in commit `6c9821c` (suite 23/23) — the detail sections below are
-> kept as the record of what was wrong and why the fix took the shape it did.
-> Items 6–9: the 0.4.0 feature board (identity, verification passes, packaging).
->
-> **Context for future-me:** the core gate architecture reviewed as *sound* — see
-> "What is already solid" at the bottom before re-auditing. Do not re-review the
-> whole tree; start from this list.
-
----
-
-## The board
-
-| # | Kind | Area | One-liner | Status |
-|---|------|------|-----------|--------|
-| 1 | **High** bug | UI server | Config UI could bind off-loopback with NO auth and NO refusal — unauthenticated LAN RCE surface | **FIXED** `6c9821c` |
-| 2 | Low bug | mcp-client (win) | `winLaunch` cmd.exe metacharacter interpretation — "no injection surface" comment was overstated | **FIXED** `6c9821c` (honest caveat) |
-| 3 | Low bug | aggregator | `_scheduleReconnect` logged `reconnect_slow` every 30s forever instead of once at the transition | **FIXED** `6c9821c` |
-| 4 | Low bug | http-transport | Streaming (chunked) over-cap body didn't get the clean `-32700` — and the "engineered" declared-CL path had the same RST flaw | **FIXED** `6c9821c` (half-close) |
-| 5 | Defensive | auth/resource-server | OIDC discovery followed redirects with no origin-check on the discovered `jwks_uri` | **FIXED** `6c9821c` (origin pin) |
-| 6 | Feature | mcp/server | Configurable server identity — `serverName`/`serverVersion` **and the default `--http`/`--ui` ports** — so a wrapped MCP introduces itself under ITS name and ships its own port defaults. Defaults unchanged. | **DONE** `a734f4b` (toolfunnel.json) |
-| 7 | Verify | protocol/register | Confirm the SCHEMA a hot-promoted register tool advertises is the author's real inputSchema (README promises "your own tools and schemas") | **DONE** `4c219e4` — plumbing was sound; tf_tool_add DROPPED the field (fixed), validated + documented now |
-| 8 | Verify | reload | Confirm `tools.register.json` edits are picked up live — the file-watchers are proven for `mcp/expose.json` + hooks; direct register edits may need a reload path | **DONE** `4c219e4` — was a REAL BUG (startup snapshot); Registry.reload() + tools/ watcher + state list_changed |
-| 9 | Feature | packaging | External config home (`TOOLFUNNEL_HOME` / `--config-dir`) + the full packaging story — see below | **DONE** `108db4e` (home) + `bc88c53` (tf_pack + requires) + `a1fa845` (docs) |
-
----
-
-## 9. The packaging story (the 0.4.0 headline)
-
-**The problem:** an npm/npx install keeps its config *inside the package directory* — an
-`npm update` EATS the user's tools, hooks, and curation. Config must live in a home of its own.
-
-**Four pieces, in dependency order:**
-
-1. **Config home** — `TOOLFUNNEL_HOME` env var / `--config-dir` flag; default stays the repo root
-   for a git clone (unchanged), but an npm-installed gateway defaults to a per-user home. The
-   enabler for everything below.
-2. **Tool-pack** — a pack IS a zipped config home. Docs, not code: the layout already travels
-   (`tools/` + `tools.register.json` + `mcp/expose.json` + `hooks/`).
-3. **npm-wrap** — docs + a worked example, no core code: a third party publishes THEIR package
-   with **`toolfunnel` as a dependency (caret range — DEPEND, NEVER COPY)**, their pack bundled,
-   and a 2-line `bin` that points toolfunnel at the bundled config home → `npx their-mcp`.
-   - Their own runtime deps go in THEIR `package.json` — npm installs the whole tree on npx;
-     script tools resolve `require()` relative to themselves. We add no machinery.
-   - Why depend-not-copy: every install of their MCP is a toolfunnel download; our security
-     fixes reach every wrapped MCP via normal `npm update`; no stale forks. (This batch's UI-bind
-     fix is the worked example of why.)
-4. **requires-preflight** — a `requires` field in the pack manifest (JSON only) checked with
-   `child_process` version probes + a hand-rolled version compare; friendly missing-runtime
-   errors ("this pack needs python ≥3.10").
-
-**★ HARD CONSTRAINT: ToolFunnel itself gains ZERO runtime dependencies from any of this.**
-JSON manifest (no yaml), hand-rolled version compare (no semver), node built-ins only.
-
-**Packs are COMPOSITE** (already true today — `mcp/expose.json` lives in the config home):
-own scripts + upstream MCP references + curation in one pack.
-- Upstreams travel as REFERENCES (npx self-fetches them; pin versions in the pack).
-- Curation travels — ship the 4 chosen tools, not the whole upstream server.
-- **THE GATE TRAVELS** — a shipped pack enforces its policy hooks on the recipient's machine
-  regardless of which MCP client they use. Nobody else can say this sentence.
-- Audit honesty: packs spawn commands. The docs say it plainly — read the `expose.json` of
-  anything you install.
-
----
-
-## 1. [HIGH] UI server binds off-loopback with no auth and no refusal
-
-**Files:** `src/ui/server.js` (`createUiServer().start()`, `isLoopbackHost`), `bin/toolfunnel.js` (`--ui --host`)
-
-**The asymmetry.** `src/mcp/http-transport.js` `start()` refuses to bind a non-loopback host
-unless OAuth is enabled:
-
-> `refusing to bind non-loopback host "<host>" without OAuth enabled — enable auth (and install jose) before exposing the gateway off localhost.`
-
-The **UI server has no equivalent guard.** `createUiServer().start()` binds whatever `host`
-it is handed, and `bin/toolfunnel.js` passes `--ui --host <anything>` straight through to it.
-
-**Why the existing check does not cover it.** `isLoopbackHost()` inside the UI's `onRequest`
-tests only the **`Host` request header**, which is fully attacker-controlled. It defends against
-*browser* DNS-rebinding (the browser sets the Host to the attacker's domain), but does **nothing**
-against a direct, non-browser client that simply sends `Host: localhost` / `Host: 127.0.0.1`.
-
-**Why it matters more than the transport.** The config UI is the one surface that can *spawn
-processes and mutate the security posture*:
-- `POST /api/mcp/add` + `POST /api/mcp/discover` construct an `Aggregator` and **connect the
-  configured upstream — i.e. spawn the configured command** (`aggregator.discover` → `_connectOne`
-  → `clientFactory` → `McpClient.connect`).
-- `POST /api/tools/add` / `/api/tools/update` **write tool scripts** to `tools/scripts/`.
-- `POST /api/tools/hook` / `/api/hooks/*` **toggle the gate hooks.**
-
-So `toolfunnel --ui --host 0.0.0.0` (a plausible "let me reach the config UI from my other
-machine" move) exposes an **unauthenticated, process-spawning, script-writing console to the
-LAN**. The HTTP transport learned this exact lesson; the UI never got the same stitch.
-
-**Fix.** The UI has no auth path at all, so the correct behaviour is a hard refusal, mirroring the
-transport's guard. In `createUiServer().start()`, before `httpServer.listen(...)`:
-
-```js
-if (!isLoopbackHost(host)) {
-  return Promise.reject(new Error(
-    `refusing to bind the config UI to non-loopback host "${host}" — the UI is ` +
-    `unauthenticated and can spawn processes / write scripts. It is loopback-only by design.`
-  ));
-}
-```
-
-(Note: `isLoopbackHost` currently returns `true` for an *empty/missing* value — fine for a Host
-*header*, but for a *bind address* an empty host should not be treated as loopback. Use a stricter
-check on the bind arg, or default-and-validate the bind host explicitly.)
-
-**Test to add:** `createUiServer({ host: '0.0.0.0' }).start()` rejects; `'127.0.0.1'`, `'localhost'`,
-`'::1'` resolve.
-
----
-
-## 2. [LOW] `winLaunch` cmd.exe metacharacter interpretation — comment overstates safety
-
-**File:** `src/mcp/mcp-client.js` (`winLaunch`)
-
-On Windows, a non-`.exe` upstream command is routed through `cmd.exe /c <command> <args…>` with
-`shell:false` (the CVE-2024-27980 `.cmd` workaround). The code comment claims:
-
-> "The args stay DISCRETE (Node escapes each one under shell:false) so nothing is shell-concatenated
-> — no injection surface on this privileged path."
-
-**That guarantee is not quite real.** With `shell:false` and the command being `cmd.exe` (an
-`.exe`), Node applies its *standard argv quoting*, **not** cmd.exe metacharacter (`^`) escaping —
-that special-casing only fires when the *command itself* is the `.cmd`/`.bat`. So a config arg
-containing `& | > < "` can be reinterpreted by cmd.exe.
-
-**Real-world risk: near-zero.** These args come from `expose.json`, authored by the operator — the
-"attacker" would be the person who owns the config. But the comment claims a property the code does
-not provide.
-
-**Fix (pick one):**
-- Downgrade the comment to state the residual cmd.exe-parsing caveat honestly, **or**
-- Defensively quote each arg for cmd.exe, **or**
-- Prefer resolving the real interpreter path (`where npx` → the `node` + `npm-cli.js` shape, as
-  `auth/install.js` already does for npm) and spawn that directly with `shell:false`, avoiding
-  `cmd.exe` entirely.
-
----
-
-## 3. [LOW] `_scheduleReconnect` spams `reconnect_slow` every 30s forever
-
-**File:** `src/mcp/aggregator.js` (`_scheduleReconnect`)
-
-Past `MAX_FAST_ATTEMPTS` (6) the method re-schedules with `Math.min(attempt + 1, MAX_FAST_ATTEMPTS)`
-→ the attempt counter **sticks at 6**. The entry logs `if (attempt === MAX_FAST_ATTEMPTS)`, so a
-permanently-dead-but-enabled upstream emits a `reconnect_slow` log line **every 30 seconds
-indefinitely**, rather than once at the fast→slow transition.
-
-**Fix.** Log the transition only. E.g. only log when entering the slow phase from the fast phase
-(track the previous attempt, or log inside the `attempt + 1` escalation exactly when it crosses
-`MAX_FAST_ATTEMPTS`, not on every subsequent capped re-entry).
-
----
-
-## 4. [LOW] Streaming over-cap body misses the clean `-32700` the declared-CL path produces
-
-**File:** `src/mcp/http-transport.js` (`readBody`, `handleMcpPost`)
-
-The **declared-Content-Length** over-cap path is carefully engineered (`sendJsonAndClose`: announce
-`Connection: close`, flush the `-32700` body, *then* destroy the request in the `res.end` callback)
-so the client receives a clean parse-error before the close.
-
-The **streaming/chunked** over-cap path is not held to the same standard: `readBody` rejects and
-immediately `req.destroy()`s. Because `req` and `res` share the socket, the follow-up
-`sendJson(res, 200, makeError(...))` in `handleMcpPost`'s catch writes to a torn-down socket → the
-client sees `ECONNRESET` instead of the tidy `-32700`.
-
-**Not a crash** — every path here is defensive and the server survives. It is an inconsistency: two
-over-cap paths that should behave identically don't.
-
-**Fix.** Route the streaming over-cap case through the same flush-then-close sequence as
-`sendJsonAndClose` (don't `req.destroy()` before the response body has flushed).
-
----
-
-## 5. [DEFENSIVE] OIDC discovery follows redirects with no origin-check on discovered `jwks_uri`
-
-**File:** `src/auth/resource-server.js` (`resolveJwksUri`, `fetchJson`)
-
-`fetchJson` uses `redirect: 'follow'`, and `resolveJwksUri` accepts whatever `jwks_uri` the issuer's
-discovery document advertises with no check that it shares the issuer's origin. The issuer is
-operator-configured (trusted), and audience binding is still enforced on the verified token, so this
-is standard OIDC behaviour and low-risk — but a defensive origin-pin on the discovered `jwks_uri`
-(and/or `redirect: 'error'` on discovery) would tighten the SSRF-adjacent surface.
-
-**Fix (optional hardening):** assert the discovered `jwks_uri` origin matches the issuer origin, or
-make it opt-out-able. Document the decision either way.
-
----
-
-## What is already solid (do NOT re-audit from scratch)
-
-The review found the **gate architecture sound**. Confirmed on 2026-07-03:
-
-- **`gatedRun` fails CLOSED on every bad-wiring path** — no engine / junk engine return / engine
-  throw all → `blocked:true`, `execute()` never called. The load-bearing invariant ("a PreToolUse
-  deny prevents `execute()` from ever running") is real and centralised in one auditable place
-  (`src/mcp/gated-run.js`).
-- **The engine proxy reads `build.engine` live** (`src/mcp/server.js`), so a hot-reloaded hook gates
-  BOTH the `toolfunnel_run_tool`/lean path AND the curated-direct path — no stale-engine gap.
-- **OAuth validator does the things that matter** (`src/auth/resource-server.js`): pins the algorithm
-  allowlist (blocks alg-confusion + `alg:none`), enforces `audience` (RFC 8707 confused-deputy
-  defence) and `issuer`, requires `exp` present, never reads the token header to choose the alg.
-- **Isolation guard on path-shaped upstream args** (`aggregator.defaultClientFactory` / `isInside` /
-  `looksLikePath`) — a vendored upstream can't point outside the gateway root; the interpreter slot
-  is correctly exempt.
-- **Path-escape defences** in `registry.writeScript` and `defaultRunScript` (basename + in-root
-  assertion), and **atomic temp+rename writes** across registry / tool-state / expose-store / auth
-  config / logger.
-- **The hook matcher is correctly full-anchored** (`^(?:…)$` in `src/core/matcher.js`), so a gate on
-  `read` does NOT leak onto `read_file`; combined with the UI's `escapeRegex` on gate writes, that
-  path is right.
-- **`McpClient` framing was fixed** in v0.3.0 to newline-delimited JSON (was LSP `Content-Length`),
-  with dual-drain read tolerance — proven against `server-everything` / `server-filesystem` + the
-  official SDK client. Zombie-guard tree-kill on close.
-
-The v0.3.0 adversarial pass (backlog task #49) did real work on the OAuth/transport surface. Finding
-#1 above is the one gap that pass did not close (it hardened the *transport*, not the *UI*).
+# Known issues & roadmap
+
+This file tracks the state of the 0.6.0 dual-era work, the deliberately-deferred items, and any
+limitations worth knowing about.
+
+## 0.6.0 - the 2026-07-28 MCP specification
+
+The 2026-07-28 MCP revision is a **breaking** change to the protocol: it removes the `initialize`
+handshake, protocol-level sessions, and the standalone GET/SSE endpoint, and adds new required
+behaviours - per-request protocol metadata, `Mcp-Method` / `Mcp-Name` request headers, a
+`server/discover` endpoint, a `subscriptions/listen` change-notification stream, and
+`resultType` / `ttlMs` / `cacheScope` result fields.
+
+Implemented in 0.6.0 (built against the RC spec; a reconciliation pass against the finalised
+spec lands after 28 July):
+
+- **Dual-era transport** (2024-11-05 + 2026-07-28) - old and new clients both work.
+- `server/discover`, request-header validation, and the `subscriptions/listen` stream.
+- A **dual-era client**: ToolFunnel speaks modern to modern upstream servers (stdio).
+- An **opt-in, per-upstream legacy-protocol shim** (`legacyPin`) - off by default, names the exact
+  version it drops to, warns at startup and on every call, and is enforced (skips the era probe).
+- **Passthrough wrap** (`toolfunnel wrap <upstreamId>`): one command turns the gateway into a
+  transparent, both-era wrapper for one upstream MCP - verbatim identity, tool definitions,
+  results, errors, notifications, and per-URI resource subscriptions (forwarded, and replayed
+  across silent upstream reconnects), with every call still passing the PreToolUse gate.
+- **Elicitation bridging**: a wrapped legacy server's mid-call questions are translated into the
+  modern `input_required` + retry pattern and back - multi-round, single-use tokens, TTL'd -
+  tested end-to-end against real published elicitation servers.
+- **Cancel translation** (stdio): a client's cancel reaches the upstream in the upstream's own
+  request-id space, for forwarded methods and wrapped tool calls alike.
+- **Identity settings + wrap mirroring**: `toolfunnel.json` gains `clientName`/`clientVersion`
+  (the identity upstreams see); under a wrap on stdio the real downstream client's identity is
+  mirrored upstream automatically.
+- **UI**: a Settings tab (identity + ports), a per-upstream legacy-pin toggle, and the wrap
+  security notice surfaced on the UI wrap path (parity with the CLI).
+- **Agent-facing docs**: `toolfunnel_howto` gains `wrap` and `configure` topics, so a plain agent
+  can learn the wrap and the whole no-code config map from inside the protocol.
+- **Method-class timeouts**: tool calls (`tools/call`, `prompts/get`, `resources/read`) wait
+  120 s by default - configurable per upstream via `"timeoutMs"` - and a progress report from
+  the tool re-arms the window, so a slow-but-alive tool never dies to the clock. The 10 s
+  handshake/list window stays fixed as the dead-upstream detector.
+- **Async shell execution**: `shell`-invoke register tools no longer block the event loop
+  (was `spawnSync` since 0.5.0) - concurrent HTTP clients keep being served during a long
+  shell tool.
+- **Config-home visibility**: every start prints the resolved config home to stderr, with a
+  relocation hint when it defaulted to the package root - running from a git clone no longer
+  writes config into the repo silently.
+- **Bounded listen streams**: the HTTP transport caps concurrent `subscriptions/listen`
+  streams (64) and refuses new ones past the cap with a clear error; existing streams are
+  never evicted.
+
+## Deliberately deferred (documented dispositions, target: the 28-July reconciliation pass)
+
+- **Legacy version family**: ToolFunnel currently speaks the oldest legacy dialect (`2024-11-05`)
+  to legacy upstreams and clamps a wrapped handshake to what the upstream negotiated. A client and
+  upstream that both speak a newer legacy revision (e.g. `2025-06-18`) are negotiated down.
+  Fidelity of the *fields* is unaffected (verified against real servers - nothing version-gated is
+  dropped), but the advertised version string is older than either end requires. DECIDED
+  (2026-07-17): best-version negotiation in BOTH directions - newest each peer speaks, modern
+  first, legacy fallback. Lands with the reconciliation pass, sequenced after the elicitation
+  bridge (a newer legacy offer invites server-initiated requests the client must handle first).
+- **Modern-upstream subscriptions**: the client does not yet open a `subscriptions/listen` stream
+  to modern upstreams, so their change-notifications are not received; the listen ack honestly
+  refuses `resourceSubscriptions` when no legacy subscribe-capable upstream is in scope.
+- **Elicitation bridge scope**: a wrapped upstream's mid-call `elicitation/create` bridges to
+  modern clients as MRTR (`input_required` + retry - built and wire-tested). A LEGACY client
+  gets an automatic decline instead (relaying backwards requests to legacy clients is future
+  work), and `sampling/createMessage` / `roots/list` from upstreams are answered -32601 for now.
+  An elicitation can only be bound to a call when exactly ONE wrapped call is in flight for that
+  upstream (always true on stdio); ambiguous concurrent HTTP calls decline rather than guess.
+- Header validation reports `-32020` where `-32022` would be more specific in one path.
+- Two-store wrap state read (expose.json + tools.state.json) has a benign TOCTOU window.
+- A meta-less `server/discover` is answered rather than refused (permissive-by-design).
+- The wrap's identity-mirror reconnect re-runs the full era negotiation - worst case ~3 s extra
+  on the first handshake against an upstream that ignores `server/discover`. Reusing the
+  already-known era on reconnect is a deferred optimisation.
+- HTTP cancel translation: the sessionless modern era gives a POST no connection identity, so a
+  client `notifications/cancelled` over HTTP is dropped rather than risk cancelling another
+  client's call. stdio (one client per pipe) translates and forwards cancels for both forwarded
+  methods and wrapped tools/call; the remaining best-effort windows are sub-millisecond (a cancel
+  racing the instant a forward is issued) plus the PreToolUse gate-evaluation phase of a tool
+  call (registered at upstream-issue time, post-gate).
+- `io.modelcontextprotocol/logLevel` (the modern per-request log level) is stripped with the rest
+  of the protocol `_meta` keys on wrapped forwards and not re-injected for modern upstreams -
+  part of the modern-upstream work above.
+- Discover on a DISABLED upstream works (inspect its tools before enabling - an explicit
+  allowance on the discover path only; the disabled upstream never reaches the tool surface).
+
+## Current limitations
+
+- The OAuth 2.1 resource-server and Streamable-HTTP support are recent and less battle-tested than
+  the core - test your setup before relying on them in a networked deployment.
+- No Prometheus / OpenTelemetry metrics - a toggleable JSONL audit log and in-memory `/health`
+  call counters only.
+- One gateway instance per process: the bridge/cancel state is process-global, so embedding two
+  gateway instances in one Node process is not a supported configuration (running two processes
+  is fine, and is the normal deployment).
+
+Found a bug, or want to help with the 0.6.0 work? Issues and PRs are welcome.

package/docs/design.md

@@ -0,0 +1,70 @@
+# Design decisions
+
+Short notes on the decisions that shape ToolFunnel, so you can judge the reasoning without
+reading the source. Each one is also documented at the place in the code where it bites.
+
+## 1. Zero runtime dependencies
+
+ToolFunnel sits in a privileged position: it executes tools and enforces policy. Every
+transitive dependency in that position is something you have to trust or audit. So the gateway
+uses Node built-ins only; "dependencies" in package.json is empty and stays empty. The one
+exception is deliberate and opt-in: OAuth token validation uses jose, installed only when you
+run `toolfunnel install-oauth`, version-pinned, because hand-rolled JWT crypto is how security
+holes are born. Dev tooling for the test suite (jose, the MCP SDK for interop tests) never
+ships.
+
+## 2. No SDK
+
+The gateway hand-rolls JSON-RPC over stdio and HTTP rather than building on the official MCP
+SDK. Two reasons. First, the zero-dependency stance above. Second, ToolFunnel has to speak two
+protocol eras at once, on both sides, which the SDK does not do; owning the wire layer is what
+makes the dual-era serving and the wrap possible at all.
+
+## 3. The gate fails closed
+
+Every server-side execution path goes through one function, gatedRun, and that function treats
+every failure as a deny: a hook that blocks, a hook engine that crashes, a malformed engine
+result, all of them mean the tool does not run. Denies carry a flag distinguishing operator
+policy ("your hook said no") from wiring failure ("the gate itself broke"), so a broken gate
+can never be mistaken for an approving one. The invariant has its own test.
+
+## 4. The isolation boundary
+
+Upstream server definitions can name any executable but their path-shaped arguments must stay
+inside the config home. The command is the interpreter you chose; the args are what it can
+reach, so the args are what the guard checks. Wrapping suspends the guard for the wrapped
+server only, because a wrap is an explicit statement that this one server is your entire
+surface, and it warns you when that happens.
+
+## 5. Two eras, served per request
+
+The 2026-07-28 revision removes the handshake that defines the older protocol, so "which era"
+is a property of each request, and that is how the gateway treats it: era detection per
+request, no mode switch, no configuration. Legacy answers stay byte-identical to what a
+pre-0.6.0 client saw; the gateway's own modern decoration only ever appears on modern
+requests. (A wrapped modern upstream's results are relayed verbatim, whatever era the
+caller speaks - stripping a server's own fields would be data loss and a wrapper tell.)
+
+## 6. Config lives in one folder
+
+Everything mutable (tools, upstreams, hooks, identity, logs) lives in the config home,
+relocatable with `--config-dir` or `TOOLFUNNEL_HOME`, seeded once, never overwritten by
+updates. One folder to back up, one folder to package, one folder to hand a colleague. The
+gateway prints the resolved home at every start so there is never any doubt about where state
+lives.
+
+## 7. Single operator by design
+
+Each ToolFunnel instance serves one operator. That is a decision, not an oversight: one
+instance per user gives process isolation, crash containment, per-user wrap state, and a
+security boundary you can reason about in one sentence. Multi-user deployment composes *in
+front of* the gateway rather than inside it - an authenticating proxy at the OAuth boundary
+(ToolFunnel is already an OAuth 2.1 resource server) routing each authenticated user to their
+own instance, with the per-request `_meta` lane carrying user context through to upstreams
+that want it. Nothing in the core couples the operator to a token subject, so that door stays
+open without the core ever growing user-shaped complexity.
+
+A Team edition built on this pattern - per-user identity, audit trails, quotas, per-user
+policy - is on the roadmap if there is interest. If your team wants that sooner, or you need a
+bespoke gateway built on ToolFunnel for your own requirements, open an issue on this
+repository titled `enquiry` - tailored builds are available.