WhyBuddy (SlideRule): a product rehearsal engine that gates AI output on evidence

The problem SlideRule addresses: direction decisions made before any evidence exists

The README frames the pain in time units. A team spends days writing a PRD, weeks aligning people, and months before it learns whether the direction was right. SlideRule's answer is a rehearsal: enter one sentence, get a full product plan reasoned through multiple loops, decide whether to build, and if the answer is no, walk away without the sunk cost.

The intended user is not a coder looking for autocomplete. The README's own comparison table separates SlideRule from Devin or Cursor-style repo labor and from chatbot or workflow builders like Dify and n8n. The people it targets are the ones who currently own the PRD and the alignment meetings: product leads, founders, and solution architects who need a business structure (data model, RBAC, workflow, pages, AIGC) before anyone writes production code.

The name is the argument. A slide rule is an analog calculator where you align scales and read a number you can defend. SlideRule applies that posture to product decisions: every step visible, every artifact passing deterministic gates, and only then a runnable application. The stated North Star is blunt about the alternative: "An AI claiming something is done does not count. Only artifacts that pass deterministic gates count."

How the V5 rehearsal engine turns one sentence into a five-system model

The pipeline in the README runs from a one-sentence intent through an orchestrator into a capability pool: evidence search, risk analysis, counter-arguments, synthesis, reporting. The output is the five-system model, and that model is what becomes an application.

What distinguishes this from a generation surface is the closure condition. The README says a run ships only when publish closure holds 6/6 evidence. The demo card on the workbench pre-fills a community pet-clinic booking and triage intent and reasons through six skills to that 6/6 closure; the README states the playback was captured from a real end-to-end LLM run rather than hand-written.

The repository layout matches the description. There is a slide-rule-python/ directory, a server/ directory, a client/ directory, a skills/ directory, and an agent-loop/ directory that also hosts the static demo. The docker-compose.yml comments describe the Python service as the place where the V5 five-system rehearsal, the E17 evidence pipeline, and the publish closure all live, listening on port 9700, with session data persisted as JSON files in a volume rather than a database. That is a deliberate architectural choice: the default profile boots without any database at all.

The fail-closed posture shows up in the optional integrations. E2B sandbox tools for code.run and app screenshots are unavailable when E2B_API_KEY is unset, and the .env.example says the tool is then automatically unavailable rather than pretending. Web search falls back to DuckDuckGo and degrades honestly when neither is configured.

Installing SlideRule with Docker Compose and running a first rehearsal

The README points to a zero-install path first: the static workbench and rehearsal surface on GitHub Pages run entirely in the browser with no backend and no key. That is the fastest way to see the shape of a rehearsal. For a live run on your own topics, the compose file is the documented bootstrap.

The compose header gives the sequence. Copy the environment template, fill at least the LLM key and the session secret, then build and start. The default profile boots the app and the Python rehearsal engine; no database is required for the rehearsal main line.

cp .env.example .env
# fill LLM_API_KEY and SESSION_SECRET
docker compose up -d --build
# then open http://localhost:3000/agent-loop/workbench

Inside the container the app listens on 3001 and is published as 3000:3001. The Python service listens on 9700, and the app reaches it through a thin proxy when SLIDERULE_V5_BACKEND=python. Both containers read the host .env.

The .env.example is where the real configuration decisions live. LLM_BASE_URL accepts any OpenAI-compatible provider, and LLM_MODEL defaults to gpt-5.5 in the template. Leaving LLM_API_KEY empty still starts the stack, but the README states rehearsal then falls back to deterministic templates instead of a real LLM run. Two settings deserve attention before you trust output: SLIDERULE_LLM_GENERATE_ENABLED=1 lets the LLM generate five-system meta-models for novel intents, which then pass a structural gate in fail-closed mode, and LLM_UNLIMITED_MODELS is a comma-separated allowlist for models exempted from output-truncation protection.

# .env excerpt
LLM_API_KEY=your_api_key_here
LLM_BASE_URL=https://api.openai.com/v1
LLM_MODEL=gpt-5.5
LLM_WIRE_API=chat_completions
LLM_TIMEOUT_MS=600000
SESSION_SECRET=replace_with_a_64_char_random_hex_secret

If you want the legacy account system (login, email verification codes, projects routes), the compose file provides an opt-in accounts profile that adds MySQL. It is described as lazily connected: without logging in, the stack never touches it.

docker compose --profile accounts up -d

After startup, the workbench is the entry point. You can watch the pre-filled rehearsal, open the finished gallery examples (second-hand instrument consignment, script-murder venue scheduling), run the generated app, switch roles, and drive approvals. Running live rehearsals on new topics requires bringing your own OpenAI-compatible key, which the README says stays in your browser.

Where the evidence-gated approach breaks down

The gate is the product, and that is also the constraint. A 6/6 publish closure means a rehearsal that cannot accumulate six pieces of passing evidence does not close. For exploratory work where the point is to sketch something half-formed, fail-closed behavior is friction rather than safety. The README's own framing acknowledges the trade: this is not an unconstrained vibe UI generator.

Several capabilities are opt-in and degrade rather than substitute. Without E2B_API_KEY, code execution and real app screenshots are unavailable; the frontend falls back to placeholder cards, and the .env.example is explicit that this is an honest fallback, not a silent success. Real screenshots additionally need SLIDERULE_PUBLIC_APP_URL set to a publicly reachable address of the deployed app, because the E2B sandbox is a separate cloud machine that cannot reach the host's localhost. Without RAG_VECTOR_ENABLED=true and an embeddings endpoint, semantic vector retrieval is off and retrieval falls back to whatever the configured search path provides.

Operational scope has edges too. The compose file states that Lobster Executor is not included because Docker-in-Docker is messy, Redis is off by default behind REDIS_ENABLED=true, and Feishu integration runs in mock mode by default. The README labels the project status as Early Testing, and no releases were retrieved for the repository. The last push was on 2026-08-14. Anyone expecting a stable, versioned release train should treat that as a gap to plan around.

There is also a naming wrinkle worth knowing before you search for help. The repository is xiaojilele-glitch/WhyBuddy and keeps the project's original name, while the product is called SlideRule. The README states this directly. Documentation, issues and forum threads may use either name.

SlideRule versus code agents and workflow builders

The README positions SlideRule against two adjacent categories, and the differences are structural rather than cosmetic.

A code agent such as Devin or Cursor works on a repository: it reads files, edits them, and runs tests. Its unit of output is a diff. SlideRule's unit of output is a gated application model with a data model, RBAC, workflow, pages and AIGC layers, plus an evidence trail. It does not labor in your existing codebase; it rehearses a product before one exists. If your task is refactoring a service or fixing a failing test, SlideRule is the wrong instrument, and the README says so in its own is/is-not table.

A workflow builder like Dify or n8n gives you a graph you wire by hand: nodes, edges, prompts, integrations. You are the author and the runtime executes your design. SlideRule inverts that. You supply one sentence; the orchestrator selects from a capability pool and the artifact has to pass gates you did not write. The trade is control for verification. A builder gives you exact, reproducible topology and no opinion about whether the result is good. SlideRule gives you a business-structure generator with a publish bar, at the cost of accepting its gate definitions as the arbiter of done.

A generation surface like v0 or Lovable produces UI quickly. The README cites those as the closest mental model for the generation surface specifically, but pairs them with Power Platform-like business structure and Manus-like long deliberation, ending in a gated app model rather than a git repo. That combination, not any single piece, is the claim.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-08-14. No releases were retrieved, so there is no published version to pin against. The package.json declares version 1.0.0 and the project status badge says Early Testing. In practice that means upgrades arrive as commits on main rather than as tagged releases, and you should expect to read CHANGELOG.md and the commit history before pulling.

The build has real moving parts. The Dockerfile is a two-stage build: pnpm install with --frozen-lockfile and --ignore-scripts, then pnpm run build, which runs vite build and an esbuild bundle of server/index.ts into dist. The runtime stage is node:22-alpine with NODE_ENV=production and PORT=3001. Both stages support an optional enterprise root certificate by placing PEM files in docker/certs/, which matters if your LLM gateway sits behind a MITM proxy. There is both a package-lock.json and a pnpm-lock.yaml in the repository root; the Dockerfile uses pnpm via corepack, pinned by the packageManager field in package.json.

The test surface is broad enough to affect upgrade cost. The package.json test script chains four suites: client tests via vitest, server tests via a script, executor tests via a separate vitest config, and script tests via node --test. There is also a typecheck script that runs tsc --noEmit and a lint script that runs prettier --check against a specific file list. Running these before and after an upgrade is the cheapest way to catch a breaking change.

The licence is MIT, declared in package.json and shown as a badge in the README, with a LICENSE file at the repository root. MIT is permissive: it allows commercial use and modification with attribution and no warranty. That is a statement about the licence text, not legal advice, and the usual caveat applies about the optional third-party services the project integrates with. E2B, SerpAPI-compatible search endpoints, and your LLM provider each carry their own terms, and the repository's SECURITY.md is the place to check before filing anything sensitive.

Editorial conclusion

Adopt SlideRule if you want a visible, evidence-gated rehearsal before committing engineering time, and if a self-hosted Docker stack with your own OpenAI-compatible key is acceptable. Do not adopt it as a code agent for repo labor or as a no-key production service: the README describes it as an early-testing rehearsal instrument, not a one-click app factory. Verify first that your LLM gateway supports the chat_completions wire API with a 600000 ms timeout, that SLIDERULE_LLM_GENERATE_ENABLED=1 produces five-system models that pass the structural gate on your topics, and that the Python service on port 9700 is reachable from the app container with matching SLIDE_RULE_INTERNAL_KEY values.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. xiaojilele-glitch/WhyBuddy on GitHub