HOW WE ENSURE QUALITY
From the first code change to the next release. We use a shared foundation, automated checks and several layers of testing to make quality and security part of development itself.
01 / THE COMPLETE FLOW
02 / WHAT WE CHECK
Repo Blueprint brings together repository structure, document metadata and instructions for people and agents. Formatting, types, coding rules and architectural boundaries are checked automatically.
Unit tests check logic, API and integration tests check how components work together, and UI tests check the interface. Smoke tests check that services start and respond. E2E tests follow the user’s journey through the entire product.
Dependencies are checked for known vulnerabilities. Secrets in Git history, Dockerfile rules and risky deployment configuration have dedicated checks in CI.
Built container images are sent to Zot and scanned there with Trivy. The CVE gate reads results for the image digest, the identity of that exact build. Release checks review the images listed in the release evidence.
03 / THE TEST PIPELINE
Unit tests, API and integration tests, UI tests, smoke tests and E2E tests answer different questions. UI and E2E can use the same browser tools while testing different scopes.
Does the individual function work correctly?
Logic & edge casesDo the components work together?
API, database & servicesDo views, forms and interactions work?
Interface & browsersDoes the built stack start and respond?
Health & key endpointsDoes the flow work from start to finish?
Complete user journeysFast feedback: unit and API tests in the project’s local checks and CI.
Real interactions: integration tests during verification and CI, plus Compose smoke tests during verification.
Browser flows: UI/E2E in the project’s verification pipeline and scheduled runs. Blueprint’s nightly stage includes E2E; Ticketeer’s verification also runs UI tests in a Playwright container.
04 / WHEN A CHECK FINDS SOMETHING
A gate produces a verifiable result. A blocking finding stops the check until it is fixed or covered by a documented exception with an expiry date.
Default threshold for the container CVE gate.
By default, the container CVE gate blocks HIGH and CRITICAL findings without a valid accepted exception. Each project’s policy determines which findings block progress.
Accepted container risks receive a review date. OSV exceptions require a reason and an expiry date no more than 90 days ahead. When time runs out, the risk must be reviewed again.
Vulnerability information changes. Recurring reviews of dependencies and released images can bring a previously approved build back for remediation.
05 / CHECKS THAT FOLLOW THE WORK
edit · turn-end · pre-commit · pre-push
Fast feedback on changes, coding rules, types, tests and secrets. Checks accompany both agent work and the Git workflow.
verify · ci
Broader verification with tests, builds, code quality and security scanning. The shared CI environment can run locally or on a CI runner.
build · release
CVE checks for container images, followed by checks of release evidence, agent instructions and project governance.
nightly
Recurring E2E tests, dependency reviews and CVE checks of released images, according to each project’s scheduled configuration.
An approved result applies to the revision, images and evidence that were checked. Each project’s test and release evidence shows what has actually been verified.
THE FOUNDATION BEHIND THE FLOW
Versioned rules, agent instructions and a shared gate runner make the approach reusable across projects and technology stacks.