Role-based release confidence tooling

TL;DR

• The team needed release signals that explained more than whether the app compiled.
• I needed checks to model real roles, known gaps, demo paths, and build relationships.
• I added preflight checks, browser tests, narration helpers, expected-failure markers, and build graphs.
• The result was a release process with better visibility into what was covered and what still needed attention.

Quality work is easier to trust when checks are visible and repeatable. A passing build should explain more than whether TypeScript compiled.

Where it started

Basic build checks could miss whether the product still worked for the people and roles that mattered.

What needed to change

Operational tooling adds checks around the paths people rely on: browser tests by role, preflight scripts, generated build graphs, and expected-failure markers for known gaps.

What I built

Automated checks run before release and produce output that can be inspected. Tests can model different user roles, while tooling can call out what is intentionally failing versus unexpectedly broken.

What changed

The team gets better release signals. Problems are easier to discuss because the tooling names what changed and where confidence is missing.

What I would watch

Tooling has to stay close to real workflows. If checks drift away from how people use the product, they create confidence without coverage.