Quality Console
What the company runs, how it is tested, and the tools to look closer.
Four zones. Static Cockpit QA is the QA cockpit a real company would have. Live experimentation is the playground: the storefront products and the services beside them read, write and delete for real in the dockerised tables, queue and mailbox. DevX holds the developer tools, the tips among them. Utility tools make test files on your disk, audio tracks first. Every tool has its page in Documentation.
Each tool, database, table, bucket and feature carries its label: live when using the stack changes it, static when it is loaded once and only read, mixed when it holds both, mock when nothing is real.
Static Cockpit QA
The QA cockpit of a real company: each tool says whether what it shows is static or changes as the stack is used.- πΊοΈSoftware catalog static
Systems, components, APIs and databases, who owns them, how they are tested.
- π§ͺTest results live
Every CI run uploaded to the results bucket, its details and its trends.
- πJobs live
Every job at a glance, last runs first.
- π₯Gherkin scenarios mixed
The acceptance scenarios by product; click one to run it on the stack.
- π§Scenario design static
Each journey drawn as a graph, the paths its scenarios walk, the gaps.
- π―Leaving SonarQube (sonar-decom) static
A quality gate on new code without a server: the analysers each language has, scoped to the lines a merge request adds.
- πAPI docs static
The contracts of the catalog: Swagger for HTTP APIs, a page for events.
- βΊοΈRecorded examples static
Real partner answers and real events, recorded into contracts/, replayed by the tests (Microcks for HTTP).
- π£Release announcements static
Each system's release announcement as /announce-release drafts it for Slack.
- πͺ£Bucket browser mixed
Folders and files of the Cloud Storage buckets, opened in place.
- πDocumentation static
Every page of docs/: the testing guide, one page per tool and product.
- ποΈDatabases mixed
Every database the console's read-only account can see, row by row.
Live experimentation
Real traffic on the dockerised tables, queue and mailbox: what you do here changes them.Storefront products
Each card opens its product alone on the storefront, in this tab; the storefront links back here.
- ποΈCustomer welcome live
Greet a customer: reads the database, counts the visit in Redis.
π₯ The scenarios that prove it - ποΈCheckout live
Place an order: writes orders, stock, invoices, payments, step by step.
π₯ The scenarios that prove it - ποΈAccount access live
Sign in, sign up, reset: writes the users, emails the QA mailbox.
π₯ The scenarios that prove it
Running beside the console
Services of the stack, to look under the hood. They open in a new tab.
- π¬QA mailbox
Mailpit: every email of the identity service. No login.
- πObservability
Grafana on the traces of the last 15 minutes. No login.
- πMessage broker
RabbitMQ management UI. Login guest / guest.
- πVault
HashiCorp Vault, dev mode. Token root.
- πContract mocks (Prism)
Prism: every OpenAPI contract of contracts/ answered as a mock under /<name>/, requests checked against the contract. One answer per operation, for anyone to try an API. The tests replay recorded answers with Microcks instead (Recorded examples). No login.
DevX
Tools for developers: what an endpoint really touches, test data on demand.- π‘Tips static
GitLab, Git, SQL, Docker, QA and front design, in short examples.
- πretro-footprint live
Which fronts, APIs and tables a test touches: 5 real runs, a pause, 5 more, then its trace in Tempo.
- πVault live
Which credentials the services hold now, for how long: short-lived ones for MySQL and RabbitMQ, a long-lived key for the bank.
- πQuality Console MCP live
Let Claude Code run scenarios, read test runs and measure footprints, with three examples.