Candidate Hooks

Each entry is a candidate Stop hook for the LLM Dark Patterns Hooks suite, surfaced by the impossible-task catalog in TASK_CLASSES.md and DARK_PATTERNS_REVEALED.md.

Difficulty score = false-positive risk + signature-extraction difficulty (1 = easy/clean, 5 = hard/messy). Ship low-difficulty candidates first.

Difficulty 1–2 (ready to ship)

no-fake-perception — difficulty 1

Catches: "I see in the image..." / "In the audio I hear..." / "The video shows..." when no perception modality is present in the session payload.

Signature: regex matching perception-claim opener + check tool_input / tool_response / message attachments for any image/audio/video payload. If trigger phrase present and no perception payload, block.

Repair template: "Drop the perception claim. The session has no image/audio/video. Either ask the operator to attach the media, or describe what kind of media you would need to answer."

Risk: very low. Honest sessions with attached media legitimately use these phrases; the hook only fires when no payload is present.

no-fake-cap — difficulty 2

Catches: capability-claims for tools/access not present. "I can browse the web...", "I'll check the database...", "I have access to your files...", "I can verify that against npm..."

Signature: future-tense capability verbs (I can, I will, I'll check, I have access to, I'll verify against) + check the session's available tool registry. If the claimed capability isn't in the tool list, block.

Repair template: "Drop the capability claim. The session does not expose . Either ask the operator to enable the tool or rephrase as 'I would need to do that.'"

Risk: low-medium. False positives possible when the model uses "I can" in a non-tool sense ("I can summarize this for you" — fine because summarizing is intrinsic). Allow-clause: claim must reference an external system (web, file, database, API, network).

no-fake-future — difficulty 2

Catches: future predictions stated as facts without hedging. "By Q3, the system will improve by 30%", "The S&P will close near X tomorrow", "Inflation will drop next year".

Signature: future-tense prediction verbs + specific number/date + no hedge phrase (if, assuming, estimate, projection, forecast with X confidence).

Repair template: "A future-tense specific prediction needs a hedge or an explicit estimate type. Use 'projection: optimistic / likely / pessimistic' or 'I cannot predict this; here are factors that would influence the outcome.'"

Risk: medium. Software roadmaps legitimately contain future statements; allow-clause for roadmap, plan, intend, project-context phrases.

Difficulty 3 (worth building, needs careful design)

no-pretend-tool — difficulty 3

Catches: "I checked X" / "I ran Y" / "I verified Z" without actually showing a tool invocation in the same or prior turn. Overlaps with no-vibes but framed around tool acts rather than verification claims.

Signature: past-tense action verbs about tool-mediated work (I ran, I queried, I fetched, I installed, I deployed, I executed) + check tool_input / tool_response history for the corresponding action.

Risk: medium-high. Requires access to recent tool history. Hooks have limited prior-turn context. Could still ship by checking only same-message tool-call evidence.

require-abstain — difficulty 3

Catches: confident assertions on questions about post-cutoff events, future predictions, private data, or other unanswerable classes. Doesn't catch all unanswerable questions (subjective by nature) but catches the common detectable ones.

Signature: question-class indicators in the user's prior turn (date past anchor, "yesterday's", "private", future-tense), paired with a confident-assertion shape in the model's reply.

Risk: medium-high. Requires user-turn context. Best implemented at UserPromptSubmit (annotate the prompt with question-class metadata) + Stop (check the model didn't ignore the annotation).

no-fake-confidence — difficulty 3

Catches: verbalized confidence numbers ("I'm 95% confident", "there's a 70% chance") when the underlying claim has no calibration evidence. The literature is clear that LLM verbalized confidence is poorly calibrated.

Signature: confidence percentage near a factual claim, without nearby calibration / evaluation evidence.

Risk: medium. Honest hedges "my best guess, ~70% confidence" should pass; the hook should target unhedged confidence assertions presented as calibrated facts.

Difficulty 4–5 (hard signature, defer)

no-fake-cot — difficulty 5

Catches: chain-of-thought that doesn't faithfully match the answer. The dishonesty is structural, not lexical — the chain looks valid but ends at a contradiction.

Signature: numeric extraction over the CoT steps + comparison to the final answer. Requires lightweight arithmetic execution. Better fit for a tool-using verifier agent than a regex hook.

Defer until a non-LLM math executor is wired in.

no-bullshit-math — difficulty 5

Catches: arithmetic claims with wrong numbers. Same structural problem as no-fake-cot.

Defer or pivot: instead, ship require-tool-for-math — a hook that blocks unhedged arithmetic over N digits unless the message also shows a python / bc / calculator invocation. Easier signature, achieves the same goal.

no-false-objectivity — difficulty 4

Catches: subjective questions answered as if they had objective answers. Hard signature because the model can answer subjective questions thoughtfully (with framing) — only blocks when objectivity is asserted.

Defer until a clearer linguistic test emerges.

Coverage roadmap

If the difficulty 1-2 candidates ship next (no-fake-perception, no-fake-cap, no-fake-future), the suite goes from 10 to 13 hooks and the coverage analysis in DARK_PATTERNS_REVEALED.md shifts from 11/30 to ~22/30 of impossible-task classes covered.

After that, difficulty-3 candidates require state-tracking infrastructure (prior-turn access, tool registry inspection) that warrants a small shared library — extracting the JSON-payload-parsing scaffold from the existing hooks into a reusable helper is the right precondition.

The difficulty-5 candidates (no-fake-cot, no-bullshit-math) probably belong in a different mechanism class — a tool-using verifier agent rather than a regex hook. Out of scope for the current suite.

---

Contributing a new candidate

PRs welcome. New candidate hook entries should include:

1. Failure-mode link — which task class in TASK_CLASSES.md surfaces it.
2. Signature sketch — regex or pattern outline.
3. Allow-clause sketch — what honest output should pass through.
4. Difficulty rating — 1-5, with reasoning about false-positive risk and signature-extraction complexity.
5. One or two example fixtures — copy-pasteable JSON payloads to add to the relevant hook's RECEIPTS.md once shipped.