…#121)

Narrow sanitize companion to form-prefill-annotate (PR1). On checkout
URLs, clear `value` on `<input type="hidden">` whose `name` matches a
curated affiliate / UTM / promo / coupon allowlist (utm_*, aff_*, ref_*,
referral_*, promo*, coupon*, discount_code, source_id, campaign_*,
partner_*, click_id, gclid, fbclid, msclkid). Annotation is the wrong
tool for hidden inputs — the value is submitted regardless of any chip
and never reaches the agent's snapshot, so clearing is the only useful
action.

FP control:
  - Hard denylist takes precedence (CSRF / nonce / signature / hmac /
    secret / session / state / cart_id / order_id / token / antiforgery
    / verification / authenticity, etc.). Substring-and-whole-name
    match so `_csrf`, `csrf-token`, `apple_pay_signature`, and `_token`
    are all preserved. Failure mode for these is a silently-rejected
    submit — strictly worse than the original dark pattern.
  - URL gate via isCheckoutUrl.
  - Form-scoped: the input must live inside an enclosing `<form>` (or
    reference one via the `form` attribute). Free-floating hidden
    inputs are JS-only carriers we leave alone.
  - Per-host kill-switch (empty at launch) for known loyalty / Apple
    Pay / 1-Click flows where saved attribution is the user intent.
  - Set-once: stamping CLEARED_ATTR prevents a re-clear fight loop with
    pages that repopulate the value after our scan.

Value is cleared via the prototype's native setter so React/Vue value
trackers see the change. No input/change event dispatch — hidden inputs
don't expect them and firing one risks tripping totals-recalculation
that re-fetches attribution from the same source.

Ships default-on. Tests cover the curated allowlist, denylist
precedence, form-scope requirement, lazy-loaded subtrees, URL gate,
form-attribute association, already-empty short-circuit, and the no-
double-clear guarantee. Property tests assert allowlist/denylist
disjointness, denylist precedence across composed names, URL-gate
invariance, and idempotency across a mix of allowed and preserved
inputs.

Docs updated under Dark patterns → Preselection alongside form-prefill-
annotate; demo Checkout page grows hidden affiliate / UTM / promo
metadata plus a csrf_token so both halves of the rule are exercised.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

When the watcher delivers a single `<input type="hidden">` appended
directly to an existing form, that input is itself the root passed to
`onSubtrees`. `querySelectorAll` only walks descendants, so the input
was never caught. Extract the per-element scrub into a `tryClearInput`
helper and invoke it once for the root before the descendant loop —
same root+descendants pattern as `attribute-injection-sanitize` and
`confirmshame-sanitize`.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Drop `promo` / `promotion` / `coupon` / `discount` shapes from the
affiliate allowlist. Hidden promo-code inputs commonly carry a
legitimate user-acquired discount (email promo link, sticky session
promo, "apply coupon" UI that writes to a hidden field at submit
time); clearing them would silently strip the user's discount with no
visible recourse. Attribution (UTM, gclid, affiliate refs) has the
opposite asymmetry — clearing it is invisible to the user and only
costs the marketing trail.

Tests:
- Move promo/coupon/discount names from positive to negative
  isAffiliateName cases.
- New shouldClearName preservation suite (it.each over the seven
  promo/coupon/discount shapes).
- New rule-level it.each that asserts a hidden promo input survives
  alongside a cleared utm_source.
- New property test: no PROMO_NAMES match the allowlist or get
  cleared, and a hidden promo input at checkout keeps its value.

Rule label tightened to "Scrub Hidden Affiliate Metadata" (no longer
"… / Promo Metadata"); demo Checkout.tsx comment + docs/rules.md
section updated to reflect the preservation rationale.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

DENY_TOKENS header comment cited `token` as a substring entry and
`coupon_token`/`aff_token` as denylist examples — both are stale post
round-2 (token is whole-name-only; coupon was removed from the
allowlist). Rewrote the rationale to a hypothetical that the substring
denylist actually catches (`affiliate_nonce`).

Renamed `never clears a denylisted name that happens to overlap the
allowlist` — `state` isn't in the allowlist regex, so there's no overlap
to resolve; the test is really demonstrating DENY_WHOLE_NAMES coverage.

Added `verify` to the property test's SECURITY_TOKENS sample so the
denylist-precedence property exercises another substring-deny token.

— Claude Code, on behalf of @twschiller

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>