k11 Release Gate — MCP server & CI gate

One release decision from all your QA evidence, under a policy you can read, with an audit trail.

Teams already have the evidence: UI test runs, API checks, security scans, JUnit files. What they lack is a consistent answer to "can we ship?". Today that answer is a person reading five dashboards under deadline pressure. k11 Release Gate reads the evidence, applies a written policy and returns one verdict, with every reason and the file it came from:

Deterministic. The same evidence and the same policy always give the same verdict. There's no LLM in the decision, so it holds up in an audit. Every evidence file is recorded with its SHA-256, timestamp and age, alongside the policy's own hash and the git commit.

What it reads

The kind of evidence is recognised from the file's content:

Which checks does this change need?

k11-release-gate-mcp plan --base origin/main

The gate compares the branch with --base and maps the changed files to evidence kinds using the policy's triggers (sensible defaults included): an openapi.yaml change needs contract and API evidence, .tsx/.css/templates need UI evidence, prompts/** needs an LLM red-team. evaluate --base origin/main then requires exactly those kinds, so a CSS-only change isn't held up by a red-team, and an API change can't ship without a contract check. The plan is saved in the decision record, so "why was this check required?" always has an answer.

triggers:                     # override the defaults per kind
  llm: ["src/assistant/**", "prompts/**"]
  contract: ["api/openapi.yaml"]

Missing evidence is never treated as a pass. Required kinds that are missing block by default, and optional kinds without evidence are listed as not tested.

See it decide

demo/ contains two release candidates whose evidence comes from real runs of the five K11 tools against their own demos.

rc1 → 🔴 Block, with 7 blockers, each traced to its source:

• 1 UI test failed for reasons other than locators (ui.real_failures): page title changed
• 2 broken locators still unresolved (ui.unresolved_locators): "Edit profile" needs review; cart-btn heal reverted
• API change breaks billing-svc, checkout-web, notification-svc (contract.breaks_critical_consumer): billing-svc is critical, owner @team-billing
• 2 API flows failed (api.flow_failed): "Order total is quantity times price", negative tests for POST /orders
• 2 server errors (5xx) in API tests (api.server_error): wrong type / missing items[0].qty
• 6 critical and 13 high-severity LLM findings (llm.critical, llm.high): unverified refund, other customers' records, indirect prompt injection, …

Needs a person: the contract check escalated (3 consumers break). Conditions: approve the healed view-orders locator; confirm the consumer list for 3 unused breaking changes.

rc2 (after the fixes) → 🟠 Needs a person's sign-off:

Sign-off needed from @qa-lead, @ai-safety-lead before release.

• Needs a person: 1 LLM probe inconclusive (llm.inconclusive)
• Condition: 1 locator healed and verified: approve the heal pull request

Everything passes, but one security probe couldn't be decided automatically, so the policy asks a named person to look. It doesn't let it through silently and doesn't block the release outright.

QA_MCP_ROOT=demo/rc1 k11-release-gate-mcp evaluate --label rc1
QA_MCP_ROOT=demo/rc2 k11-release-gate-mcp evaluate --label rc2

The policy: .qa-mcp/release-policy.yaml

name: Order platform release policy
evidence:                                   # where each tool writes its report (globs inside the project)
  api_tests: [".qa-mcp/api-test-report/api-test-report.json"]
  junit: ["test-results/**/*.xml"]
required: [api_tests, contract, ui_heal, llm]
max_age_hours: 24                           # older evidence → evidence.stale
critical_consumers: [critical, high]        # their breakage blocks
approvers: ["@qa-lead", "@ai-safety-lead"]  # named on a needs_human verdict
rules:                                      # override any rule: block | needs_human | conditional | info | off
  llm.medium: needs_human
  ui.healed: info

k11-release-gate-mcp init writes a commented starter policy; k11-release-gate-mcp rules lists every rule.

Rules

Tools

The Claude Code plugin adds /release-check, which collects the evidence, tells you which tool produces anything missing, evaluates and explains, without ever softening the verdict.

In CI

k11-release-gate-mcp evaluate --label v2.4.0 --base origin/main

It writes release-decision.md (the PR comment) and release-decision.json (the audit record), sets GitHub Actions outputs (verdict, blockers, needs_human, conditions, report) and exits non-zero according to --fail-on block | needs-human | conditions | never. See docs/release-gate.yml.

Install

/plugin marketplace add K11-Software-Solutions/k11techlab-release-gate-mcp
/plugin install release-gate@k11-release-gate

Or the MCP server only: claude mcp add release-gate -- uvx k11-release-gate-mcp, or pip install k11-release-gate-mcp for CI.

Background

This puts into practice the risk-proportionate human-in-the-loop idea from the K11 research on autonomous CI/CD quality assurance (IJECS, 2026): automate the clear cases and send the uncertain ones to a named person, with the evidence attached. It's an independent implementation and doesn't depend on the research code.

Development

python -m venv .venv && .venv/Scripts/pip install -e ".[dev]"   # bin/pip on macOS/Linux
pytest   # real evidence from all five tools, policy, determinism, diff-aware planning, CLI, MCP (15)

Roadmap

• A GitHub Check with per-rule annotations
• Signed decision records (Sigstore) for regulated releases
• Approvals recorded against the decision (who signed off a needs_human verdict, and when)
• The Release Readiness Agent: a Claude Code plugin that runs the checks plan_checks asks for through the K11 servers and asks this gate for the verdict

Built by K11 Software Solutions. Part of the K11 Tech Lab agentic QA series. MIT licensed.