Second Chair Release Desk

Agents on GitLab Duo take each change to a public defender's discovery tool from issue to staging, prove it still catches every contradiction, then wait for one human approval.

Comment

Path B (Bring Your Own) · Supervised · all nine DevSecOps stages

Inspiration

Second Chair helps overloaded public defenders review discovery: agents read the arrest report, body cam, dispatch log and evidence receipts, cite exact lines, and deterministic code flags every contradiction (an arrest time that doesn't match the video, cash that shrinks between the scene and the evidence room). Defenders lean on it because they don't have the hours, which makes its mistakes the ones nobody catches.

Before this hackathon it had one developer, no tests, no scanning, no review, and it shipped with vercel --prod from a laptop. A one-line regex change could silently stop it from flagging a contradiction in a police report.

What it does

The release desk runs the whole post-code lifecycle around Second Chair on GitLab, with the maintainer approving only the outcome.

  1. The maintainer files an issue from a template (Missed finding, False finding, Security finding). Its /assign quick action hands it to the second-chair-issue-to-mr flow.
  2. A gatekeeper agent checks who started the session against an allowlist. A planner agent finds the root cause and posts acceptance criteria tied to the eval gate. A fixer agent commits a fictional golden case that reproduces the problem, then the fix and unit tests (it runs them in its runner), and opens a merge request.
  3. The pipeline runs lint and types, unit tests, and the golden-case eval gate: the real reader agents over fictional discovery packets with known contradictions, scored on recall and precision. New cases also run against main, so the report shows "fails on main, passes on this change". GitLab Advanced SAST, secret detection, dependency scanning and a privilege/PII check run alongside.
  4. The desk assigns the second-chair-safety-review flow, which checks the diff against six defense-safety rules (citation guard intact, code derives facts, no legal advice to clients, privileged data stays private, golden cases honest, proof for behavior changes) and returns a verdict. It also starts GitLab's Code Review flow.
  5. The merge gate merges the agent's MR only when every gate is green; a failure gets exactly one automatic repair request. On main, the pipeline builds once into the GitLab Package Registry (checksummed), applies the Vercel configuration as code, deploys staging and smoke-tests it, opens a change record with every gate's evidence, and the second-chair-release-notes flow writes a summary and risk rating for the maintainer.
  6. The maintainer reads that one page and runs deploy-production. The pipeline deploys exactly the package that passed staging, smoke-tests production, publishes a GitLab Release with the agent's notes and an evidence pack (who asked, which agents acted, eval scores, scans, the verdict, checksums, who approved), and reports back on the issue. A scheduled probe runs a real review through production and opens an incident for the second-chair-incident-triage flow if it fails.

The desk ran three real loops: a missed arrest-time contradiction when reports write "0112 hrs" (v1.0.12), a false baggie-count contradiction when a count is written as "twenty-four" (v1.0.26), and three critical Next.js remote code execution advisories found by dependency scanning, fixed with a pnpm upgrade in the agent's runner (v1.0.25; dependency findings 42 to 30, critical 7 to 3).

How we built it

  • GitLab Duo Agent Platform: four custom flows (nine agent components) kept as YAML in .gitlab/duo/flows, synced to the AI Catalog as PRIVATE items by scripts/duo/sync_flows.py, enabled in the project with assign, assign-reviewer and mention triggers and their own service accounts (composite identity). Each flow starts with a gatekeeper and a conditional router. .gitlab/duo/agent-config.yml gives the agents Node 24 and the project's dependencies. GitLab's foundational Code Review flow is started over the REST API.
  • GitLab CI/CD: MR pipelines (verify, secure, review, repair) and main pipelines (package, configure, staging, approve, production, release), scheduled pipelines (monitor), GitLab security templates, JUnit reports, environments, the generic Package Registry, Releases.
  • Orchestration: GitLab starts flows only on human actions, so CI jobs act with a separate, masked token the maintainer delegated for exactly six steps; every agent action is still done by its own service account.
  • The app: Next.js and the Strands Agents SDK (TypeScript) calling Qwen/Qwen3.8-27B on W&B Inference, deployed to Vercel only by the pipeline.

What we added during the Submission Period (on or after Oct 5)

The original project's four commits (Sep 13 2026, https://github.com/chinesepowered/second-chair, MIT) are unchanged at the start of the GitLab history. Everything else was added from Oct 23 2026:

  • the whole release desk: .gitlab-ci.yml, scripts/ci/ and scripts/desk/ (eval gate, privilege check, packaging, deploys, smoke tests, review requests, merge gate, repair, change records, releases and evidence packs, incidents), deploy/vercel-project.json;
  • the agents: four flows, gatekeeper and allowlist, safety rules, agent runner config, catalog sync script, issue templates, AGENTS.md, CODEOWNERS;
  • tests and evals: 56 Vitest unit tests and the golden-case eval gate with six fictional cases;
  • small app changes for testability (packet-aware review, clock and fact parsing split out, retries and timeout, version badge);
  • the deployment: a new Vercel project deployed only by GitLab CI (staging and production);
  • three changes made by the agents themselves (MRs !1, !2, !3; releases v1.0.12, v1.0.25, v1.0.26).

Challenges we ran into

  • GitLab's human-trigger rule means one flow cannot start another; a delegated token in CI does the hand-offs transparently and is limited to six actions, with a one-repair limit so agents can never loop.
  • Vercel's prebuilt Next.js functions reference traced files in node_modules; the package had to carry exactly those files so production deploys only what the registry holds.
  • The project is public, so anyone can mention a flow. The gatekeeper trusts only GitLab's own "started session ... triggered by" system note, and a conditional router keeps every other agent from running.
  • Vercel tokens cannot be scoped to one project, so the pipeline used a short-lived token and the variable was deleted after the final deploy.

Accomplishments that we're proud of

  • Three real issues went from template to production with no human step in between except the approval; two of the six golden cases were written by the agents while fixing real bugs.
  • The eval gate proves both directions that matter to a defender: a missed contradiction (recall) and an invented one (precision), with a baseline run that shows the bug on main.
  • Every release carries a chain of custody a court-adjacent team can audit.

What we learned

  • Deterministic gates around agents (exact-quote guards, checksums, pinned SHAs, verdict lines) make agent work reviewable; the agents are most useful where judgment is needed and least trusted where it is not.
  • A good change record lets the human approve the outcome in a minute instead of re-checking every step.

What's next

  • Swap the remaining critical findings (dev-only vitest dependencies) through the same desk.
  • Merge request approval rules and protected environments when the project moves to a namespace where we are Maintainers.
  • More golden cases from real defender feedback, all fictionalized.

Links

All case data in the app, the golden cases and the video is fictional. AI tools used: Claude Code (coding assistant), the GitLab Duo Agent Platform (the release desk's agents and GitLab's Code Review flow), Qwen3.8-27B on W&B Inference (the app's agents and the eval gate), ElevenLabs (video narration).

Built With

  • elevenlabs
  • gitlab
  • gitlab-advanced-sast
  • gitlab-ai-catalog
  • gitlab-ci/cd
  • gitlab-dependency-scanning
  • gitlab-duo-agent-platform
  • gitlab-environments
  • gitlab-package-registry
  • gitlab-releases
  • gitlab-secret-detection
  • next.js
  • node.js
  • playwright
  • pnpm
  • python
  • qwen3.8-27b
  • react
  • strands-agents-sdk
  • tsx
  • typescript
  • uv
  • vercel
  • vitest
  • w&b-inference
Share this project:

Updates

Submission history