rubberduck-use-case-playground: ten prompts aimed at one small demo app

The local hub answers on 5055 and the container on 8000

The quick start sends you to one address. The container configuration uses another.

The documented path is a clone, a change into `demo-projects`, and then `start-hub.bat` on Windows or `./start-hub.sh` on Linux and macOS, after which you open `http://127.0.0.1:5055/`.

The Dockerfile sets its host and port through environment variables, binds all interfaces, and exposes port 8000:

ENV HUB_HOST=0.0.0.0 \
    HUB_PORT=8000 \
    PYTHONUNBUFFERED=1

EXPOSE 8000

A comment above those lines notes that the launcher reads them and that they are overridable, so the mismatch is a default rather than a hard-coded conflict. It is still a mismatch. Somebody who reads the README, builds the image and then goes looking for the hub on 5055 will find nothing, and the fix is to read the environment variables rather than the readme.

Worth noting the bind address differs too. The local script is described as serving a loopback address, while the container binds every interface, because the comment says it is so the service is reachable inside a container.

Ten use cases land on about four pieces of code

The use-case table lists ten numbered entries, and reading the third column shows how small the target is.

Three of them work on the same search path. The code review entry is a hostile review of the ordering clause where raw SQL sits near search. The planning entry asks for a parameterised version of the customer search. The code generation entry is to implement that safe search along with tests. The version comparison entry then puts raw SQL search next to parameterised search.

Two more work on the same aggregation function. One asks whether the discount flag actually applies, and the quick check asks what the aggregation function returns, with a short answer and evidence.

And two work on the same rename, with the change-impact entry scoped to the blast radius of renaming a configuration table.

So the ten prompts are aimed at roughly four distinct pieces of work inside one demo application. That is a sensible way to teach a workflow, where the same code is revisited from different angles, and it is also a limit on what the exercise can tell you. A tool that finds the planted defects in a small app it was pointed at has not been shown to survive a real codebase, and nothing in the exercise is sized to test that.

The demo app ships deliberate vulnerabilities as the curriculum

The pizzeria demo is described as a restaurant admin interface plus a kitchen API, with the phrase that matters being intentional lab sinks.

The security audit use case names what should surface: SQL injection, cross-site scripting, pickle or exec misuse, insecure direct object references, command injection, server-side template injection and broken access control, with the list left open. The code review use case is specified as a hostile review rather than a friendly one.

This is the standard shape for a scanner evaluation harness, and it is the same shape as a deliberately vulnerable training application. Nothing about it requires the tool to attack anything it was not pointed at, and the repository contains no scanning tool of its own; it contains a target.

The one thing to keep in mind is that a run does execute those sinks. The demo app is served locally with its own database and API, so a misconfigured probe or a careless prompt has somewhere real to land. The health diagram the hub draws, which walks from the virtualenv through dependencies and the database to the API and the UI, is the closest thing to a description of that blast radius.

The Dockerfile is written for the vendor's pentest pipeline

The container file opens with a comment that says more than its filename does.

It describes a deterministic deploy for the demo-projects hub, and then names the consumer: the RubberDuck runtime MCP pentest pipeline, which prefers a Dockerfile over buildpack autodetection.

So the image exists so that the vendor can stand this repository up reproducibly during its own security testing, not primarily so that you can run it. That is a perfectly reasonable reason for the file to exist, and it also explains some of its choices: a slim Python base, dependencies copied in their own layer for caching, and the launcher as the entry point.

It also means the container path is the better-tested one, since it is exercised by a pipeline that runs repeatedly, while the shell scripts you are directed to use on your own machine are the path nobody automates.

Worth noting alongside this: the repository is MIT licensed, carries a licence file and a security-relevant configuration surface, and is maintained under the same organisation as the product whose MCP server it is designed to be pointed at.

Three dependency files for one repository

There are three places that declare what to install, and they are not in agreement about scope.

The project metadata lists a single dependency, Flask at 3.0 or newer, and requires Python 3.10 or newer. The requirements file used by the container also lists Flask, under a comment identifying it as the hub control plane dependency for the launcher script.

The third is inside the demo application. A comment in the requirements file says the pizzeria demo dependencies are installed into their own virtual environment by a setup script during the run, and points at a requirements file in the demo app's package directory.

So one launch creates at least two environments: the hub's, and the demo app's own. The hub diagram that walks from virtualenv through dependencies, database, API and UI is describing that chain rather than a single install.

There is also an unusual detail in the packaging table. The package discovery is pointed at a directory inside the demo project whose name contains both a hyphen and a dot, and the include pattern is a single glob. So what the distribution actually ships is one inner package from the demo app, not the playground.

The previous demo layout was deleted outright

One line in the readme explains why the repository is shaped the way it is.

It says the older stack, consisting of a demo app directory, a labs directory and a lab runner script, was removed so the repository would have one clear path, which is the demo-projects hub.

That is a good reason and a disruptive change. Anything pointing at the old paths, whether a bookmark, a script, a course that referenced them or a pull request against them, breaks without a redirect. The current root confirms the removal: what remains is the GitHub directory, a gitignore, the container file, a guide, the licence, the readme, a setup document, the demo-projects directory, the project metadata and the requirements file.

The same passage is worth reading for a second reason. It tells you the ten use cases and the hub replaced something more granular, which means the labs the old layout provided are now expressed as numbered prompts inside the hub rather than as separate runnable exercises.

For anyone picking this up cold, the readme is the shortest path and the guide and setup documents are where the detail lives.

The homepage is a bare hostname and the language is CSS

Two small metadata details are worth putting next to each other, because both describe the repository from the outside rather than the work inside it.

The declared homepage is a host name with no scheme on it, so it is not a URL that a tool can fetch without guessing the protocol. The documentation links in the readme do carry their schemes, so the guess is easy, but the field itself is incomplete.

The recorded primary language is CSS. For a repository whose own code is Python, that is a statement about where the bulk of the file content sits rather than about what the project is. A demo application with a restaurant admin interface and a kitchen API plausibly accounts for it, since the interface work outweighs a launcher script and a configuration, but it means the language field will mislead anyone filtering repositories by language.

Neither of these affects whether the playground works. They matter for the same reason the port mismatch does: the metadata around this project describes it less accurately than the readme does.

Editorial conclusion

rubberduck-use-case-playground suits someone evaluating a code-analysis product who wants to see it work against code it has never seen, and who is willing to stand up two environments to do it. It is a poor fit if you want to judge the product on anything larger, because the target is a small demo application with known planted defects. Before you run it, settle three things. Expect more setup than the name suggests, since the sixty-second path creates a hub virtualenv and then the demo app creates its own. Watch the port, since the documented local address and the container port are different numbers. And read what you are connecting to, since step five is attaching a vendor MCP server to a machine you work on. The last push was on 2026-09-08.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. RubberDuck-com/rubberduck-use-case-playground on GitHub