ai-slop: check whether any shipped rule appears under Wikipedia's "Ineffective indicators"

[kyle-sexton]

Graduated from the contract slice of #3031 (docs/topics/ai-slop-unslop-integration/PLAN.md), pruned before merge per the topic-docs convention.

What

plugins/ai-slop/skills/audit/reference/catalog.md records two sections of its source page as a known fetch gap: "Comment-specific indicators" and "Ineffective indicators". The second one is the load-bearing half.

"Ineffective indicators" lists signals that page's own editors consider unreliable for detection. Our catalog cites that page as its source. If a rule we ship appears in that section, we are shipping a rule our own cited source classifies as ineffective — which is a guardrail question, not a completeness one.

The two candidates, both by our own records:

• rule-em-dash — zero-tolerance by design, and measured at 34,999 matching lines on this repo alone.
• rule-rule-of-three — the catalog's own calibration record calls it "highest false-positive risk in the roster".

Why it is not already answered

A /discovery:research pass attempted it and was blocked: every Wikimedia host is denied at the research environment's egress gateway (a network policy, not a tool-permission setting). Routing through a third-party read-proxy was deliberately declined as circumventing the denial rather than researching around it. Seven hosts and routes were checked and recorded.

What closes this

One fetch from a session with Wikimedia egress:

1. Fetch the current revision of Wikipedia:Signs of AI writing; record its revision id and date.
2. Read the "Ineffective indicators" section. Report whether any of detect.sh's 15 shipped rules appears there.
3. If one does: that is a rule-disposition decision, not a doc edit — bring it back as such.
4. If none does: record the section as checked in the catalog's upstream-drift record and close the fetch gap for that half.

The "Comment-specific indicators" half is lower value — its scope is Wikipedia talk-page comments, and secondary evidence suggests it duplicates rule-verbose-edit-summaries and rule-canned-policy-assurance, which the catalog already carries. Worth doing in the same visit, not worth its own.

Our pin is revision 1369699198 (2026-08-16), and the page was measured at 50+ edits/week, so expect meaningful drift.

[kyle-sexton]

Attempted 2026-08-21 — blocked by network policy, mechanism now proven rather than assumed

Three independent paths, all denied:

Path	Result
curl https://en.wikipedia.org/...	CONNECT tunnel failed, response 403
WebFetch tool	EGRESS_BLOCKED: Access to en.wikipedia.org is blocked by the network egress proxy
Agent-proxy status	selective: false, and a logged connect_rejected — "gateway answered 403 to CONNECT (policy denial or upstream failure)" — for an unrelated non-allowlisted host

So this is a gateway allowlist policy, not a tool permission, a transient failure, or something a retry or a different client fixes. It needs a session whose network policy reaches en.wikipedia.org. Routing around it through a mirror or read-proxy is deliberately not done — that defeats the policy rather than researching around it.

What did come back, and why it sharpens this issue

WebSearch is reachable and surfaced something that bears directly on a shipped rule. Secondary reporting on the page states that the em-dash sign "is most useful when taken in combination with other indicators, not by itself", and that some vendors now suppress em dashes in newer models (GPT-5.1 named).

If that phrasing is on the pinned revision, it is in tension with how rule-em-dash ships: zero-tolerance, the strongest tier in the crosswalk, firing per occurrence with no corroboration required. That is exactly the shape this issue was filed to check.

I am not acting on it. It is a search snippet, not the revision-pinned source, and this catalog's attribution is pinned to revision 1369699198 for CC BY-SA compliance. Retiering a shipped rule on unverifiable secondary reporting would be the precise failure the calibration record exists to prevent.

The question, sharpened to one fetch

A session with egress should read the pinned revision and answer:

1. Does an "Ineffective indicators" section exist on revision 1369699198, and does any shipped rule slug appear in it? (reference/catalog.md records this and "Comment-specific indicators" as a "Known fetch gap" — both exceeded the fetch window at catalog time.)
2. Does the em-dash entry carry the "in combination with other indicators, not by itself" qualifier? If so, rule-em-dash's zero-tolerance tier and the crosswalk row that argues it both need revisiting — the rule may be correct but its tier overclaims what the source supports.
3. Is the page's own guidance that no single indicator is dispositive reflected anywhere in the crosswalk, which currently tiers each rule independently?

Item 2 is new information from this attempt and is the highest-value part of this issue now.

Sources consulted (secondary, unverified against the pinned revision): FlowingData, Beutler Ink, MakeUseOf.

---

Generated by Claude Code

[kyle-sexton]

Claiming for the Ineffective-indicators recheck (isolated worktree /tmp/wt-3032, branch cursor/3032-ineffective-indicators-cfcf).

Wikimedia egress succeeded this session. Fetching the catalog-cited page and comparing the 15 shipped script rules against Ineffective indicators.