🛰️ Release Sentinel

Is this build safe to ship? Release Sentinel is an agentic release-readiness copilot. It aggregates the signals an engineering team checks by hand before every production release — CI builds (TeamCity), static-analysis quality gates (SonarQube), monitoring and incidents (Datadog), open blockers (Jira), deployment history (Octopus Deploy), and the diff itself (GitHub) — and has GPT-5.6 reason across them to produce a go / no-go verdict with cited evidence, a risk score, a rollback plan, and a "who to ask" list.

Built for OpenAI Build Week — Developer Tools track.

Why

Release sign-off in enterprise teams is a swivel-chair job: someone opens six dashboards, cross-references a quality-gate failure with a muted test with an incident from last week, and makes a judgment call. The dangerous risks are the correlations — a reworked subsystem plus muted tests covering that exact subsystem plus a recent production incident in the same area. No single dashboard shows that. An LLM reasoning over all the signals at once does.

Quick start

Zero dependencies — just Node 20+.

node server.js
# → http://localhost:3000

• Without an API key, a deterministic rules engine produces the verdict, so the demo runs end-to-end offline.
• With GPT-5.6 (the intended engine):

set OPENAI_API_KEY=sk-...        # PowerShell: $env:OPENAI_API_KEY="sk-..."
node server.js

Optionally set OPENAI_MODEL (defaults to gpt-5.6) and PORT (defaults to 3000).

Two-scenario demo script

Use the two extremes for a quick product walkthrough:

1. Select payments-api v2.14.0 (#4812). Point out that TeamCity is green in isolation, then trace the settlement-engine correlation across the muted tests, failed SonarQube gate, staging regressions, open Blocker, SEV-2, migration, and prior rollback. Click Assess release: the expected verdict is ⛔ NO GO.
2. Select payments-api v2.13.2 (#4788). Show the small incident-fix diff, regression coverage, green gate, baseline monitors, and closed tickets. Click Assess release: the expected verdict is ✓ GO.

The third fixture is useful for showing that the copilot is not binary: select payments-api v2.14.1 (#4846) to get ▲ GO WITH CAUTION for a modest coverage gap, unrelated muted legacy test, staging latency warning, and DB index.

Included scenarios

Three release candidates ship as fixtures (in mock/), modeled on a realistic payments service:

Candidate	Story	Expected verdict
payments-api v2.14.0	Settlement engine rework: failed quality gate (new SQL-injection finding, 54% coverage), 2 muted tests covering the reworked code, staging error-rate/latency regressions, an open Blocker ticket, a DB migration, and a related SEV-2 two weeks ago	NO GO
payments-api v2.13.2	Small, well-tested incident fix: green gates, no muted tests, monitors at baseline	GO
payments-api v2.14.1	Beneficiary-validation cache change: coverage below target, one unrelated muted legacy test, a staging latency warning, and a DB index migration	GO WITH CAUTION

Pick a candidate, review the raw signal cards, hit Assess release, and read the verdict brief.

Architecture

public/index.html    dashboard (vanilla HTML/JS, light + dark)
server.js            zero-dependency Node HTTP server + API
lib/reasoner.js      GPT-5.6 reasoning engine + deterministic fallback
mock/*.json          per-release aggregated signals (one file per candidate)
test/*.test.js        deterministic verdict and output-shape checks
package.json          Node 20+ module metadata and convenience scripts

• GET /api/releases — list release candidates
• GET /api/signals/:id — aggregated signals for one candidate
• POST /api/assess/:id — run the reasoning engine, returns the verdict brief

Swapping mocks for real integrations: each mock/*.json file has one top-level key per source (github, teamcity, sonarqube, datadog, jira, octopus), matching what each vendor's REST API returns after a thin mapping. In production these would be fetched live from each vendor's REST API (or via an MCP gateway); the reasoner is already source-agnostic — it just receives the aggregated JSON.

The vendor-shaped mappings are deliberately thin: GitHub compare data supplies diff counts, hotspots, and commit authors; TeamCity contributes build state and muted tests; SonarQube contributes quality-gate conditions; Datadog contributes monitor and incident summaries; Jira contributes fixVersion issues; and Octopus contributes deployment history and available runbooks. Authentication and vendor pagination belong in integration adapters, while the reasoner continues to accept the same aggregate shape.

Where Codex accelerated the workflow

In this authoring session, Codex:

1. Added the mid-risk release fixture and calibrated the deterministic fallback so the three fixtures reliably produce all three verdict bands.
2. Tightened the GPT-5.6 JSON contract validation and strengthened correlation logic between changed subsystems and recent incidents.
3. Added zero-dependency Node tests for verdicts, score bands, blocker ordering, rollback-runbook references, and the shared response shape.
4. Refined the vanilla dashboard with explicit light/dark modes, accessible icon-and-text statuses, an accessible risk meter, escaped vendor data, and visible network-error handling.
5. Started the real server and exercised each fixture through the rendered UI, confirming the expected verdicts before handoff.

Judging notes

• Codex utilization: see above; the repo history shows the Codex-driven commits.
• Real-world problem: this is a daily pain point in regulated/enterprise software delivery; the fixtures are modeled on a real FX-payments release flow.
• UX: one screen, one question, one answer — with the evidence trail attached.