#1524 tried to publish by adding
`data/servers/io.decisionrules/server.json`. The detector ran fine and
logged:
```
Non-publish file changed: data/servers/io.decisionrules/server.json
PR #1524 match=false
```
The path list only knew `servers/**` at the repo root and exactly
`data/seed.json`. Putting the file under `data/servers/` is a natural
guess given `data/seed.json` exists, and it fell straight through.
Adds `data/servers/**` plus root-level `server.json` / `servers.json`.
`find` confirms nothing legitimate lives at any of those paths today.
The list stays explicit rather than becoming a broad `**/server.json`
glob. The classifier only flags a PR when *every* changed file matches,
which makes widening asymmetric: too narrow silently misses spam, too
broad auto-closes a legitimate single-file PR.
Both copies of the list (stage 1 and stage 2) are updated identically,
with a comment on each pointing at the other.
## Testing
`actionlint` clean. macOS ships bash 3.2, so I extracted the literal `if
[[ ... ]]` condition from each workflow file and ran it under bash 5 in
Docker — testing the shipped text rather than a retyped copy. Both
copies are byte-identical and agree:
```
MATCH data/servers/io.decisionrules/server.json # PR 1524
MATCH servers/com.aradia/x.json # PR 1549
MATCH data/seed.json
MATCH server.json
MATCH servers.json
keep internal/api/handler.go
keep internal/servers/service.go
keep data/servers.md
keep docs/README.md
```
Also dry-ran the full classifier against all 35 currently-open PRs from
untrusted authors: **0 would be closed**. No legitimate open PR is
affected.
## Known remaining gap (deliberately not fixed here)
The detector does not run at all for authors new to GitHub. This repo's
Actions approval policy is `first_time_contributors_new_to_github`, so
their fork PRs sit in `action_required` until a maintainer approves the
run. That is why #1549 was never flagged.
I'm leaving that alone for now because the numbers don't justify the
fix. Since the automation landed on 2026-07-09 it has had **71 detect
runs: 70 ran, 1 was gated**. It has correctly closed 3 publish attempts
(SAGE, Diagram Generation API, Kairos Signal) and missed 2 — one to the
path bug this PR fixes, one to the gate. So the gate costs roughly one
missed PR every six weeks, and those get closed manually within a day.
The only ways around it are `pull_request_target` (runs untrusted PRs in
a privileged context — one future `actions/checkout` from being a
privilege-escalation hole) or a scheduled sweep (works, but trades the
two-stage design for cron semantics and a ~15 min delay). Neither seems
worth it at that rate. Happy to open a follow-up if you'd rather close
the gap.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary
We keep getting PRs (e.g. #1385, #1368, #1367, #1363, #1354) that try to
"publish" an MCP server by adding files under `servers/` or editing
`data/seed.json`. That isn't how publishing works — servers are
published with the `mcp-publisher` CLI against the live registry API.
This adds automation that detects those PRs, comments with a pointer to
the publishing quickstart, labels them `invalid`, and closes them.
## How it works (two stages, no `pull_request_target`)
`pull_request_target` is intentionally avoided. Instead:
- **Stage 1 — `detect-invalid-publish-prs.yml`** runs on `pull_request`
(opened/reopened) with a **read-only** token. It only reads the changed
file paths and, if the PR *exclusively* touches `servers/**` and/or
`data/seed.json` (and the author isn't a MEMBER/OWNER/COLLABORATOR),
records just the PR number as a short-lived artifact. It can't comment
or close anything.
- **Stage 2 — `close-invalid-publish-prs.yml`** runs via `workflow_run`
in the trusted base-repo context (write token). It picks up the flagged
PR number, **independently re-validates** the PR from the API (still
open, external author, files still match, not already labeled), then
comments, labels `invalid`, and closes.
### Trust boundary
The only thing crossing from the untrusted stage to the privileged stage
is the **PR number**, sanitized to digits only. Stage 2 never trusts
stage 1's verdict — it re-derives every decision. Neither stage ever
checks out or runs PR code.
### Safety against false positives
- Fires only when a PR touches *exclusively* `servers/**` and/or
`data/seed.json` — a real code PR that also happens to touch seed data
is left alone.
- Skips `MEMBER`/`OWNER`/`COLLABORATOR` authors, so maintainers editing
dev seed data aren't auto-closed.
- Idempotent: skips PRs already labeled `invalid` (e.g. if a maintainer
reopens one).
## Notes
- Like any `pull_request`/`workflow_run` automation, this only takes
effect **once merged to `main`** — it is not retroactive and won't run
on this PR. The currently-open offending PRs should be closed manually.
- Pinned action SHAs match the repo's existing convention
(`upload-artifact` reuses the SHA already in `ci.yml`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Radoslav Dimitrov