# WhyBuddy gates its output on evidence and audits its own request latency

> A product rehearsal engine that runs a five stage pipeline and refuses to publish without a fail-closed closure step. Its repository carries generated architecture graphs, a Docker bootstrap with an optional MySQL profile, and a configuration file that documents a reasoning-effort experiment it later withdrew.

**xiaojilele-glitch/WhyBuddy** — A simple and universal product rehearsal engine, speccing anything.

- Repository: https://github.com/xiaojilele-glitch/WhyBuddy
- Website: http://www.sliderule.ai/
- Stars: 369 · Forks: 66
- Language: TypeScript
- License: MIT
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/xiaojilele-glitch-whybuddy

## The North Star rule is that claims do not count, artifacts do

The first thing the README does is state a rule and mark it important. An AI claiming something is done does not count. Only artifacts that pass deterministic gates count.

That single sentence reframes what the tool is for. A system that has to prove its work through gates is not trying to make you believe its summary, and the distinction matters because the summary is exactly where a long-prompt model is most persuasive and least reliable.

The line immediately below narrows the scope of the product itself. There is only one product main line, at `/agent-loop/sliderule`. `/autopilot` is the archived v4 demo, and a separate document named `NORTH_STAR.md` is pointed to as the authority.

So the naming is deliberately unhelpful for anyone arriving from a search result, which is a defensible trade when an old demo would otherwise compete with the live one for attention.

## Five hops, one write each, and a rule about reporting

The pipeline is five hops in a fixed order: `spec`, then `pages`, then `structure`, then `bind`, then `closure`. What makes that more than a pipeline is the constraint attached to it: a hop that did not change a deliverable must not report `ok`.

That is a small rule with large consequences. It means the success signal carries information, because success now implies that something changed rather than that a function returned. A pipeline whose nodes always return success is indistinguishable from one that did nothing.

The comparison the README makes is against an LLM with a long prompt, and the list of six differences is specific about where the work happens. There is a typed control plane in which scope cards, assumption cards and hop intent are answers, and leftover `pages` must not hijack `rehearse` or `refine`. Publish closure is fail-closed: missing evidence is missing, and there is never a fake green light. Python is the authority, with `slide-rule-python` on FastAPI at port 9700 as the live engine and Node thin-proxying two paths to it. And architecture is enforced by compilers rather than hand-drawn maps.

The live path diagram adds the failure branch: closure either closes and yields a browser runtime, or it blocks and routes to park, refine or repair, which loops back to the control plane.

## The graph is compiled from code, and one file warns against hand edits

The architecture documentation is generated, and the README says so in a form that discourages the obvious mistake: authoritative graphs are generated from code, do not hand-edit.

Four graphs are linked, and their sizes are given. The SlideRule Python graph covers 286 modules, broken down as `util` at 125, `core` at 59 and `flow` at 30. The TypeScript graph covers 1919 modules. There is also a whole-repo graph, a comparison graph against another codebase, and a gap review rendered as HTML.

There is a versioning caveat too. The SlideRule documents for versions 5.2 through 6.0 are historical lab notes, not the live map. That is a useful warning, because a repository with six versions of architecture notes in `docs/` is otherwise very easy to cite the wrong one.

The enforcement behind the generation is in two compilers named in the README, `arch_graph.py` and `arch-graph-ts.mjs`, and they are described as failing on three conditions: undeclared edges, new cycles, and a growing function-body import ratchet. That third one is the interesting check, since it converts an architectural regression into a build failure rather than a review comment.

## The preview is a real app with zero backend and zero database

The output is described in a way that sets it apart from diagram generators. The rehearsed model is not diagrams; the browser renders an operable system.

The capability list is concrete about what operable means. You run the app on desktop, tablet or phone. You switch roles. You drive approvals. You edit data in place. You try declared AIGC. You export with evidence.

And the constraint is stated just as firmly: the preview runtime has zero backend and zero database.

That combination is the interesting design decision. A generated system that runs entirely client-side can be demonstrated to someone without standing up infrastructure, which is what makes the static demo meaningful. It also means whatever the rehearsal concluded about persistence and permissions exists in the preview as interface behaviour rather than as a working backend, so the distinction between demonstrated and implemented is worth keeping in mind.

The schema behind it is named as a five-system JSON covering pages, RBAC, workflow, data and AIGC.

## Five service hops, and only some of them wait for a human

The table walking through a single rehearsal is the most concrete documentation in the project, because it names who is responsible at each step.

Step one is intent, one sentence in the composer, entered by the client. Step two is park, where the control plane parks a scope card, and the responsible component is `rehearsal_control`. Step three is confirm, where the text Start rehearsal maps to `forcedTool=rehearse`.

Step four is the first pass, running `spec` through to `bind` in one go under the spec-first pipeline. Step five is assumptions, where the model's silent forks become a card that has to be confirmed to continue, and the component named is `spec.assumptions`.

Step six is closure, producing evidence for the six skills or parking, handled by publish closure. Step seven is run or refine, which is either the browser runtime or `refine` and `repair` before the next hop, handled by the live runtime together with the control plane.

So human involvement is concentrated at steps two, three and five. Steps four and six run unattended, which is consistent with the fail-closed design: the unattended parts produce artifacts, and the gated parts are where judgement enters.

## MySQL exists only for a legacy account system and connects lazily

The quick start is two commands. Clone and configure:

```bash
git clone https://github.com/2686521696/WhyBuddy.git && cd WhyBuddy
cp .env.example .env
```

Fill at least `LLM_API_KEY`, which accepts any OpenAI compatible provider, and the session secret. Without an LLM key the stack still boots, but rehearsals fall back to deterministic templates, so you will see the plumbing rather than a real model run. Then start it:

```bash
docker compose up -d --build
```

and open the sliderule path on port 3000.

One detail in the clone line is worth knowing before you are puzzled by it. The URL there names a different account from the repository you are reading, so the command as written points somewhere other than this project. Change it if the clone fails; it is not a sign the instructions are otherwise unreliable.

The compose file then carries a long comment explaining what is and is not in the default bootstrap, and the omissions are as informative as the inclusions.

The default profile boots two things: the app, which is the server plus bundled frontend on port 3000 published from a container that internally listens on 3001, and the Python engine on port 9700. The comment is explicit that the main rehearsal line does not need a database at all, and that session data persists in a JSON file store on a named volume rather than in a database.

MySQL sits behind an optional profile called accounts, and the stated reason is that only the legacy account system uses it, covering login, email verification codes and the projects route. It connects lazily, so a run that never logs in never touches it. It also does not expose a port to the host.

Three more things are deliberately absent: a Docker-in-Docker executor, because nesting is messy and has to be opted into separately; Redis, which is off unless `REDIS_ENABLED=true`; and Feishu integration, which defaults to mock mode.

That is an unusually honest compose file, and the pattern it describes is what lets the quick start be one command.

## A configuration comment records a speed optimisation that was tried and withdrawn

The environment template carries the most unusual writing in the repository, a comment block documenting a reasoning-effort experiment in detail, including a measurement table.

The claim is that reasoning effort is the largest speed knob on a reasoning model, more effective than changing model or tuning the prompt. Supporting numbers are given for three settings, and the reasoning token medians differ by an order of magnitude between the lowest and highest. The explanation is that wall clock tracks completion tokens at a measured rate, and that 85 to 90 percent of completion is thinking the user never sees, so elapsed time is decided by how much the model thinks rather than by prompt size or cache hits.

Then the part worth reading. A note explains why the lowest setting was not chosen, and that the decision to take it was made and then withdrawn on the same day. The recorded failure is specific: at the lowest setting the design stage returned a validation failure and the model could not assemble a valid deep node tree, with mechanical repair attempts not rescuing it.

There is also a warning that single-run variance is large, so a conclusion about which setting is faster has to be drawn from multiple samples and a median. A commented note records that the project nearly got this wrong.

The eventual resolution was a global middle setting, with the reasoning made explicit that this bet on no other path needing thought, and that the saved time was not worth the gamble.

## The build embeds a CSP value that a missing environment variable silently broke

The production Dockerfile carries a comment that reads like a post mortem, and it is about a build-time value.

The workbench content security policy sets `frame-src` at compile time. The config reads the allowed preview origin from an environment variable, computes which origins may embed a frame, and injects the result into the document head as a meta tag.

Then the recorded incident, dated 16 September 2026. In an image built by CI the policy came out as `frame-src 'self'`, because the variable had never been present in the build environment. The failure mode is called out specifically because it is misleading: the consequence was not a 502. The gateway connected and the preview address was correct, but the browser blocked the iframe according to the policy, which presents as the preview simply not opening, and is considerably harder to diagnose than a 502.

Three consequences are recorded. Changing the value requires rebuilding the image and restarting the container is not enough. It is a public domain rather than a credential, and a gateway key must never enter the frontend build. And when it is left empty the policy falls back to `frame-src 'self'`, which is the older behaviour of permitting same-origin frames only.

That last fallback is the one to notice: the failure mode of a missing build variable is a policy that is narrower than intended rather than an error.

## Conclusion

Use WhyBuddy if you want to interrogate a product idea before building it, and if being told that a stage produced nothing is a more useful answer than being handed a plausible plan. The gates are the point: a hop that did not change a deliverable must not report success, and the publish closure is fail-closed. Do not expect a turnkey product generator, since the project explicitly frames itself as a rehearsal instrument rather than a one-click app factory, and it states that the model claims being done do not count unless artifacts pass deterministic gates. Four things to check first. That you fill at least `LLM_API_KEY` and `SLIDERULE_AUTH_SECRET`, since without a key the stack still boots but rehearsals fall back to deterministic templates. Which service line you are on, because `/agent-loop/sliderule` is the only product main line and `/autopilot` is an archived v4 demo. What the optional MySQL profile is for, since it exists only for the legacy account system and connects lazily. And whether you can work in the browser first, because the static demo needs no backend and no key at all. Licence is MIT, there are no GitHub releases, and the last push to main is dated 22 September 2026.

## FAQ

### What is xiaojilele-glitch/WhyBuddy?

It is a product rehearsal engine. You type one sentence and it rehearses a gated product plan through five hops, spec, pages, structure, bind and closure, and then lets you run the result. The browser preview renders an operable application with zero backend and zero database.

### How do I run WhyBuddy without installing anything?

The static demo runs in the browser with no backend and no key. The rehearsal surface is at the /agent-loop/sliderule path and a workbench view is beside it. You can watch a captured end to end rehearsal, open finished examples and run the generated app, or bring your own OpenAI compatible key, which stays in the browser.

### What does the publish closure step do in WhyBuddy?

It is fail-closed. Missing evidence counts as missing rather than as a pass, and the pipeline never reports a fake green light. A hop that did not change a deliverable must not report ok, so a successful closure implies artifacts were produced and passed deterministic gates.

### How do I start the WhyBuddy stack locally?

Clone the repository, copy .env.example to .env and fill at least LLM_API_KEY for any OpenAI compatible provider plus the session secret, then run docker compose up -d --build and open the sliderule path on port 3000. Without an LLM key the stack still boots but rehearsals fall back to deterministic templates.

### Why does WhyBuddy ship both a sliderule path and an autopilot path?

Only one product main line exists. SlideRule at /agent-loop/sliderule is the live line, while /autopilot is the archived v4 demo kept for reference. The repository points to a NORTH_STAR.md document as the authority on which line is live.

## Sources

- [Issues](https://github.com/xiaojilele-glitch/WhyBuddy/issues)
- [License: MIT](https://github.com/xiaojilele-glitch/WhyBuddy/blob/main/LICENSE)
- [Project website](http://www.sliderule.ai/)
- [README](https://github.com/xiaojilele-glitch/WhyBuddy/blob/main/README.md)
- [xiaojilele-glitch/WhyBuddy on GitHub](https://github.com/xiaojilele-glitch/WhyBuddy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xiaojilele-glitch-whybuddy