FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository apatureai/bastion;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
in-loop design review over MCP
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
Part of the Apature stack — automated design review for rendered UI. The org profile maps how the pieces compose.
static version
An MCP server that gives a coding agent eyes on the UI it just changed: submit a preview URL, get findings with route, viewport, element ref and a suggested fix, apply them yourself, then ask the server to recheck. It judges and verifies; it never edits code, drives a browser, or opens a pull request — the server is the eyes, the agent is the hands. Everything runs offline with no credentials, and with nothing configured the judgments come from a golden fixture that says so in every payload; one clone and one environment variable swap in a real critique of a real page.
Quickstart
Node 24+ and pnpm 9.15.0 (corepack enable installs pnpm from the packageManager field). No API key, no database, no Docker; pnpm install needs the npm registry once, and after that nothing here opens a connection.
pnpm demo is a real MCP client. It spawns the server as a child process over stdio, completes a handshake, submits a review, reads it back four ways, acts on a finding, rechecks it, and is denied on an unauthorized host — the nine steps shown in the hero above. It ends:
**Success looks like** nine numbered steps, 3 findings, 3 recheck outcomes, and two new files: out/review.json (the agent-facing Critique) and out/panel.html (the self-contained review panel).
> The server still identifies itself on the wire as apature-mcp-review. That name is part of the MCP handshake and any client configuration that already references it, so the repository rename to bastion deliberately left it alone.
If pnpm demo reports Cannot find module, pnpm build has not been run. If step 2 comes back DNS_TARGET_PROHIBITED instead of a job, something changed LOCAL_RESOLVED_ADDRESS in packages/mcp-server/src/local-server.ts to a non-public address, and that rejection is the SSRF guard working.
What you get
pnpm demo reviews https://preview.example.com/pricing and writes two files. out/review.json is the Critique a coding agent reads: a grade, a findings[] array where each entry carries a dimension, severity, route, viewport, element_ref and a suggestion fix string, plus two envelopes an agent must check before trusting any of that — provenance and coverage. out/panel.html is the same review as a self-contained HTML panel: no scripts, no external requests, evidence embedded as data: URIs. The job_* and rev_* ids are freshly generated, so yours differ from the hero's.
With nothing configured the findings are a golden fixture describing a fictional pricing page, not a judgment of the URL you passed — and the payload says so rather than relying on the startup banner, because the consumer is usually an agent that never sees the banner. The full result contract covers grounding, the model-free measurements block, and how every payload an agent reads — the recheck, the panel action, each finding, each content block — carries the same marker.
Provenance: did anything judge this page?
Every Critique carries a provenance object, on every backend including the offline fixture path, so an agent that never sees the terminal can answer "which engine ran" from the payload alone:
The rule an agent codes against: **trust the result only when provenance.model_backed === true and coverage.state is not "nothing".** When model_backed is false — the fixture engine, or verdict run with --model mock/--model canned — the grade is the literal "unjudged", confidence is null, the narrative says no model judged the page instead of describing one, and every finding carries "unjudged": true. When it is true, the engine's grade, narrative and findings pass through untouched and provenance.model names the judge. A remote verdict deployment reports null: a real judgment may be behind it, but this process cannot see how that deployment is configured and does not claim to.
Coverage: what did it actually look at?
provenance answers whether a model judged the page; it does not answer what the model judged, and those come apart. Verdict's triage can conclude a deep review is needed and then name no route to run it on: a model really was called (model_backed truthfully true), yet no page was judged, and a result with no surviving findings grades ship by construction. So every Critique also carries coverage: