Critique v4.1: The Merge Boundary Meets Your Whole Stack

You already had a merge boundary. You did not have a front door.

If you shipped v4, you felt the relief: finally, a single place that remembers who opened the change, what the firewall said, what evidence demanded, and whether merge policy agreed. That story was true. It was also trapped — trapped behind sign-in, behind “open the dashboard,” behind the assumption that the human would come to Critique.

Your agents do not live there. Your issue tracker does not live there. Your on-call channel and your CI system certainly do not live there. They live where work already happens. v4.1 is Critique walking out the door with the passport in hand, not asking everyone to walk in.

Zapier, MCP, and Connections are not the same thing

Before you open Settings, one clarification we should have led with: **Zapier is not MCP**, and neither is the same as pasting a Linear key in Connections.

v4.1’s Connections page is now **Zapier-first**: we would rather you wire the long tail through Zapier than maintain five half-finished OAuth flows. Native Linear and Slack remain for product features that need tight coupling. MCP and REST are for **agents and portals**, not for replacing Zapier.

What “entering the ecosystem” actually means

We use that phrase deliberately. Critique is not trying to become Slack, Linear, or GitHub. It is trying to become the **governance layer** those tools can respect — the place that knows whether this change is allowed to merge, what proof exists, and what production taught you last time.

Entering the ecosystem means three practical things shipped in v4.1:

**Zapier (recommended)** — Wire Slack, Jira, Sentry, Vercel, and the long tail without a dedicated Critique integration for every logo. **Native Connections** — Optional Linear and Slack keys when Chat needs issue search or confirmed Slack posts. **Platform API** — Scripts and internal portals read passports and review runs with scoped `crt_` keys. **Agents API (MCP)** — IDE agents list passports, inspect evidence, and queue reviews — separate from Zapier.

Under the hood it is engineering work — encrypted credentials, scoped keys, JSON-RPC. On the surface it is a promise: **Critique is a participant in your toolchain, not a destination you visit when something goes wrong.**

Connections: Zapier first, native when it matters

The **Connections** page answers “how do I hook Critique up to the rest of my org?” Start with **Zapier** for the tools your company already runs. Use **optional native** Linear and Slack keys only when you want Critique Chat to search issues or post to a channel with a confirmation step. Sentry, Jira, and Vercel are not separate Critique forms anymore — they are expected to arrive through Zapier or Control Board incident webhooks.

When you do connect **Linear** natively, you get a personal API key flow: test, toggle Chat/Review/Remedy/Builder, done. **Slack** accepts a bot token or incoming webhook for `postToSlack` in chat. Everything encrypts with the same `CRITIQUE_SECRETS_ENCRYPTION_KEY` as BYOK.

That matters because context fragmentation is expensive. The fifth time someone pastes a Linear ticket into chat, the product should already know the ticket exists. The third time an incident fires in Sentry, Critique should already be hunting for the passport that matches the deploy — v4 built that link on the backend; v4.1 starts making the **operator setup** feel intentional instead of tribal knowledge.

Your agents deserve the passport, not a screenshot

Coding agents changed the speed of software change. They did not change the need for proof. When Cursor or Claude asks “what is blocking this PR?” the answer should not be a guess from diff comments. It should be the same verdict, risk band, and evidence contract your merge policy already evaluated.

Critique now speaks **MCP** — the open protocol agent hosts use to discover tools. Create an API key, point your MCP client at Critique’s endpoint, and your agent can **list open passports**, **pull a review run**, or **queue a new review** for a commit you specify. You stay in the IDE. Critique stays the system of record at the merge boundary.

We are not asking you to replace your agent. We are asking you to give it read access to governance — the layer comment bots never had.

Platform API: passports for portals, not people clicking around

Many teams already built an internal “release health” view. Before v4.1, wiring Critique into that view meant brittle scraping or manual exports. Now **`GET /api/v1/passports`** and **`GET /api/v1/review-runs/:id`** return the same structures the dashboard uses, authenticated with a scoped **`crt_` key** or your normal session.

That is how Critique shows up in the ecosystem without forcing every engineer to learn a new UI. Your platform team embeds passport status. Your runbook polls review completion. Your security dashboard highlights high-risk open changes. The merge boundary becomes visible where leadership already looks.

The dashboard finally feels like a control room

If you only open Critique to “see the latest PR,” v4.1 will feel different the moment you land on **Overview**. You still get control-room metrics — open passports, firewall blocks, merge blocks, live evidence runs. You also get:

You get a **connection health strip** for GitHub, Linear, Sentry, Jira, and Vercel; a **passport queue preview** on the operating table; a **cross-stack activity timeline** for incidents, gate decisions, merge policy, evidence, and delivery health; and a **Linear workspace** panel when connected — assigned issues beside recent Linear-linked incidents.

This is the product thesis in UI form: **the home screen should answer “what needs my judgment today?”** not “here is a list of installs.”

Chat gets sharper when the stack is connected

With Linear connected, Critique Chat can **search issues and roadmap** in the same thread where you ask about a failing test or a policy exception. The model does not have to pretend your tracker does not exist. It can relate “ENG-442” to the repository you already selected and the passport you are trying to unblock.

That is a small feature name with a large implication: **Critique Chat is an operator console**, not a generic coding assistant. It is allowed to be opinionated because it sits on governance data, not just repository files.

What we are not claiming (yet)

Honesty builds more trust than a roadmap slide. v4.1 does not yet ship a branded Critique Zapier app with one-click OAuth — you compose Zaps with Webhooks by Zapier plus our MCP/REST docs. Not every Remedy or Builder action is on REST yet. Production incidents still arrive through Control Board webhooks, the same as v4.

What shipped is the **spine**: credentials, keys, MCP, read APIs, and a dashboard that admits Critique lives in a larger toolchain. The muscles attach to that spine quickly when the data model is right — and v4’s passport was that model.

Who wins first

The story after v4

v4 answered **what** must be true before merge. v4.1 answers **where** that truth should appear so your organization actually behaves as if merge policy matters. Connections, API keys, and MCP are not side quests — they are how a change-control platform earns a place next to GitHub, not behind it.

If you are already on passports, go connect Linear, mint an API key, and point your agent at Critique once. The next time an agent opens a PR at 2 a.m., you will want the passport waiting in the tools your team already trusts — not locked in a tab they will open tomorrow.