ReleaseLens

Preparing a software change for release involves more than reviewing a diff. Developers, technical leads, and release engineers must determine what changed, what may be affected, which checks to run, what failed, and what evidence supports their conclusions. That information is often spread across Git history, source files, tests, terminal output, and documentation, making the review process fragmented and harder to reproduce. ReleaseLens organizes this work into one evidence-backed workflow. A developer runs the application locally, selects a Git repository and release candidate, and reviews the changed files and diff. The system applies deterministic rules to identify potential impacts, generates a verification plan, runs configured checks, records findings and command output, and produces a Markdown release-verification dossier. When a relationship cannot be established from the available evidence, the system is designed to preserve that uncertainty rather than invent an answer. The controlled demonstration uses a synthetic TypeScript order-management repository. Its discount calculation intentionally conflicts with a contract test: a 10% discount on 100 is expected to produce 90. This makes the change and its failed verification reproducible and inspectable. The check runner uses an explicit command allowlist rather than executing arbitrary commands entered as free-form text. ReleaseLens is designed to make verification evidence easier to assemble and communicate; it does not decide whether a release is safe. It is a local-first prototype: repository analysis requires the API to run on a machine that can access the repository. The hosted Vercel deployment cannot read folders on a user’s computer. No quantified time-saving or accuracy claim is made because a measured comparison has not been completed.