AfterMerge

Inspiration

Writing the code is the easy part now. The stretch after a merge request lands is where small teams lose days: proving the change is safe, getting it onto staging, checking the product still behaves, telling the people who operate it, and only then shipping. For a field-service software team, a bad release breaks technician certs, closeout photos, payroll timestamps, and EPA 608 refrigerant logs. We wanted an agent that owns that stretch and makes real decisions instead of rubber-stamping green checks.

What it does

AfterMerge is an agentic post-merge DevSecOps console for Northline Mechanical, a fictional field-service company, and its product FieldClear (dispatch, closeout, timeclock, and EPA 608 compliance for mechanical contractors). When a merge request lands, the agent runs seven stages:

• SAST (Semgrep with a GitLab SAST-style ruleset): waive, file a follow-up, or hold.
• Dependencies (Gemnasium and npm audit): reachability decides hold versus waiver.
• Staging deploy: GitLab environment deploy plus a health check.
• Smoke tests (Playwright): one retry on a 429 from a portal mock.
• Release notes: drafted for field ops, including every waiver.
• Human approval: required at medium or high risk; low risk may auto-promote.
• Promote: production only after the gate; critical findings never get here.

On the live merge, the agent waives a token-prefix log only after checking the production log level, files a follow-up, and refuses to auto-promote. It waives a high dependency advisory only after a call-path check. It retries one flaky smoke test. Medium risk stops at a person. A critical, reachable advisory on an older run never leaves the dependency stage. The board already shows promoted, waiting, and held runs so the policy is visible before you press Simulate merge.

How we built it

Next.js App Router, TypeScript, Tailwind CSS, and shadcn/ui, hosted on Vercel. The agent's stage pipeline and risk policy run in the browser, and the repo includes a GitLab webhook mapping and a sample .gitlab-ci.yml (docs/architecture.md, docs/gitlab-ci.example.yml) showing how merge-request events drive the same stages. A /demo route plays a narrated three-minute walkthrough with one human click at the approval gate.

Challenges we ran into

Making the agent's judgment legible. A green pipeline is easy to show; showing why a finding was waived, followed up, or held, and why that changes whether production is allowed, took most of the design work. We also kept the demo fully simulated (no GitLab token, no paid API, DEMO- ids instead of real CVEs) so judges can run it anywhere.

Accomplishments that we're proud of

A complete, end-to-end post-merge workflow that covers seven lifecycle stages with a clear risk policy: auto-promote, human gate, or hold. Every waiver lands in the release notes, so operators see exactly what shipped and why.

What we learned

The value of a post-merge agent is in the decisions between stages, not the stages themselves: reachability checks, log-level checks, bounded retries, and knowing when to stop and ask a person.

What's next for AfterMerge

Wire the webhook mapping to a live GitLab project on Duo Agent Platform, add monitoring and incident-response stages using GitLab Observability (OpenTelemetry traces, metrics, and logs), and roll back automatically when post-promote health checks regress.

Built With

• gitlab-ci
• next.js
• playwright
• react
• semgrep
• shadcn-ui
• tailwindcss
• typescript
• vercel