Feature request: confidence degradation for training-data-driven reasoning

Problem

Claude Code over-relies on training data patterns when debugging, leading to misdiagnosis and cascading failures. When Claude sees a familiar pattern (e.g., "Cloudflare Access challenge" in logs), it immediately maps to the training-data solution ("add Service Token") without verifying the actual cause against real data.

Real-world incident (2026-03-25)

1. CI E2E readiness script failed with 404 errors on static assets
2. Claude saw "Access challenge" in logs and concluded Service Token was needed
3. Actual cause: URL parsing bug (trailing backslash \ in extracted asset URLs)
4. Before the real cause was found, Claude's high-confidence guesses led to:

• Unnecessary Service Token creation
• Creating a Cloudflare Access Application on the production domain
• Production outage (all users blocked by Access)
• Hours of debugging in the wrong direction

1. A different agent (Codex) found the real cause in minutes by actually testing the URLs locally

Root cause analysis

Claude's inference assigns high confidence scores to pattern matches from training data. "Access challenge detected" → "need Service Token" is a strong learned association. This confidence is so high that:

• Claude states it as fact, not hypothesis
• When the user asks "are you sure?", Claude doubles down instead of re-examining
• Claude proposes fixes before verifying the diagnosis
• Even after a fix fails, Claude generates another high-confidence guess instead of going back to raw data

Proposed solution

Implement a mechanism for confidence degradation on training-data-driven reasoning, especially during debugging:

1. Distinguish "known from training" vs "verified from current data" — Internal tagging of whether a conclusion comes from pattern matching (training data) or from actual verification (tool use results in this session)
2. Degrade confidence on unverified conclusions — When a conclusion is training-data-driven and hasn't been verified by tool use, automatically reduce its presentation confidence (e.g., "this might be..." instead of "this is...")
3. Require verification before action — For debugging scenarios, require at least one verification step (curl, log inspection, local reproduction) before proposing a fix
4. Break the "guess → fix → fail → guess again" loop — After a proposed fix fails, force a return to raw data examination instead of generating another high-confidence guess

Why this can't be solved with prompts alone

• System prompts saying "verify first" are overridden by high-confidence pattern matches
• Memory/feedback files are read but don't change the underlying inference behavior
• The user had to ask "are you sure?" multiple times before Claude reconsidered — and even then, Claude generated another guess instead of checking data

Impact

This pattern causes:

• Production incidents from untested fixes
• Wasted debugging time (hours instead of minutes)
• Erosion of user trust
• Cascading failures when each "fix" creates new problems