Adapters monitor by default, and detect something without configuration

[cport1]

Both found by installing this SDK on a live site that takes payments and files legal documents. Wiring up @webdecoy/express per the docs and requesting the homepage returned:

{"error":"Forbidden","message":"Access denied by Web Decoy protection"}

An ordinary python-requests user agent got the same.

1. It blocked by default and could not be told not to

protect() returns allowed: false whenever the server-side score clears threatScoreThreshold (default 80). The adapter calls onBlocked, which 403s — and onBlocked never received next, so "record the verdict and serve the request anyway" was not expressible. dryRun on a rule governs that rule, not the score.

mode now defaults to 'monitor' on all three adapters. Set mode: 'enforce' once the recorded hits look right.

The check sits before the rule branches, not after. A rate-limit rule returning 429 is as much of an unasked-for surprise as a 403, so monitor means "changes nothing" rather than "changes nothing except the rules". An earlier draft put it after them and would have shipped the exact bug it exists to fix — caught by re-reading the placement against my own comment.

onBlocked also gains next, so observe-and-continue is expressible even in enforce mode.

Nobody adopts a defence by having it break their site on install. The WordPress plugin needed the 2.3.2 safety release for this exact shape; this is the same mistake in the artifact we hand to developers.

2. With no rules it detected nothing worth recording

The unified score weights honeypot 38%, attack signatures 24%, but user-agent 1% and headers 1% — deliberately, because both are trivially spoofed. A middleware with no rules can only contribute the 1% signals, so it scores ~0 regardless of what it sees.

Measured against production:

source	avg unified	max	scored zero
sdk	0.0	0	9 of 9
sdk_tripwire	52.5	90	0
bot_scanner	45.7	100	0
edge_worker	35.0	100	458

Raising the user-agent weight would be the wrong fix and actively backwards — it would score the clients honest enough to say python-requests and miss every attacker who simply does not. It would also raise threat levels, and threat_level IN ('HIGH','CRITICAL') is the membership condition for the cross-site actor feed — so a presentation problem would push traffic onto a shared, customer-facing surface as a side effect.

So an SDK constructed with no rules now gets tripwires instead of nothing. The built-in paths are secrets and config files — /.env, /.ssh/id_rsa, /wp-config.php — that no application serves, so a request for one is a scanner enumerating rather than a visitor browsing, and a legitimate visitor cannot trip one by accident. rules: [] opts out explicitly.

Nothing in the scorer changed.

Breaking change

mode defaults to 'monitor', so an existing install that relied on automatic blocking will stop blocking until it sets mode: 'enforce'. That is the intended direction — failing open is the safe way to discover this.

Testing

176 tests green across the monorepo, check:edge clean on both edge-targeted packages. New coverage: monitor serves the request and annotates what it would have done, monitor is the default, the annotation does not leak to the browser, an inbound would-block claim is stripped, tripwires are on with no config, ordinary paths are untouched, and rules: [] opts out.

Verified the monitor test actually catches the bug by flipping the default back to enforce and watching it fail.