Before a release

Walk the tutorials end to end before releasing the CLI or the framework.

Unit tests check commands one at a time. A reader runs them in sequence: Getting Started, then the tutorials, in a new workspace. That path breaks in ways unit tests do not see, such as an undeclared dependency, a new prompt, a changed message or a step that only fails after the one before it. The docs repository has a test that takes that path.

cd splent_docs
python3 e2e/run.py --cli ../splent_cli --framework ../splent_framework

It creates a new workspace and follows Getting Started and Tutorials 1–7 with the commands, files and expected output taken from the pages themselves. The browser checks run over HTTP. It reports each section as passed, failed or skipped. It exits with 1 if any section failed, and keeps a full log of every section.

Run it on what you are about to release. --cli and --framework take a local clone, which uses its HEAD (commit first), or a ref of the forge repository. With neither, it tests main of the forge.
Include Tutorial 8 when the Claude Code plugin changed. --with-claude runs it, which calls Claude and costs tokens.
Release only on a clean pass. When a section fails, fix the code, or fix the page if the code is right and the docs are out of date. Then run that section again: --keep leaves the environment up, and --root <run dir> --from <section> resumes there (add --from-step to start inside the section).
Update the version lines after the release. The run notes when Getting Started shows older versions than the ones under test.

A full run takes about 12 minutes with Docker’s cache warm, and longer when images must be built. Only one workspace can use the tutorials’ container names at a time, so stop your own my_first_app first. The runner refuses to start otherwise and names what is in the way.

How pages are marked for the test, how output is compared and what the runner never does are described in e2e/README.md in the docs repository.