Common sense check

Common Sense Check

Prevent two failures:

1. Starting work that does not serve the real goal.
2. Starting correctly, then optimizing a locally plausible but wrong branch.

Use two operating modes: a lightweight mid-work checkpoint, which includes the abstraction-level check, and a full audit for explicit evaluation requests.

Every check ends in one outcome:

• continue - the current branch still serves the goal.
• simplify - the goal is right, but the approach is heavier than necessary.
• reframe - the problem is real, but the work is happening at the wrong level or toward the wrong outcome.
• stop / ask - continuing is not justified, or only the user can resolve a load-bearing uncertainty.

Mid-work checkpoint

Run this check internally without producing a scorecard:

1. Restate the user-visible result being pursued. If it cannot be stated clearly, stop and ask.
2. Separate live evidence from assumptions.
3. Ask whether the current branch directly advances the result.
4. Check for a simpler, cheaper, or more direct action.
5. Choose continue, simplify, reframe, or stop / ask.

Run it when:

• New evidence contradicts or materially complicates the current approach.
• Scope expands beyond the original request.
• Two attempts fail, or a fix works locally but the symptom moves.
• The user says "again", "опять", "в другом месте тоже", or "it should work everywhere".
• One diagnostic cycle or a cluster of related edits completes without a causal explanation.
• A large change, refactor, deletion, publish, deploy, or external message is next.

Surface the result only when it changes the work, exposes serious uncertainty, or produces reframe or stop / ask. State the original goal, triggering evidence, proposed change, and at most one blocking question. If the outcome is continue, keep working without announcing the check.

Abstraction-level check

Treat a repeated symptom as strong evidence that warrants checking for a shared source. After its second appearance, or while writing the second local patch, do not write a third local fix until completing this check.

Build a quick map of what the affected places share, then climb the ladder:

1. Specific component - Is the failure unique to its state or markup?
2. Shared primitive - Do consumers of the same component, utility, service, or hook fail similarly?
3. Runtime or platform boundary - Do lifecycle, Teleport, transitions, global state/classes, routing, WebView, keyboard, network, or environment interactions explain every instance?
4. Architecture - Can the current owner guarantee the required invariant, or must responsibility be extracted or the primitive replaced?

Choose the lowest level that both explains all observed instances and survives one cheap discriminating experiment. Examples: disable a global class, exercise a sibling consumer, bypass one shared hook, or construct a minimal reproduction.

Treat "rewrite it as a new entity" as a level-4 hypothesis, including when proposed by the user or another model. Verify levels 2 and 3 first; fixing the existing shared owner may be enough.

Signals that this check was skipped:

• Each patch repeats similar CSS, lifecycle, watcher, routing, or state workarounds.
• The root-cause explanation remains vague after two fixes.
• A local fix moves the symptom to a neighboring surface.
• The implementation is green locally, but there is still no reason it should work across sibling surfaces.

Full audit

When the user explicitly asks whether an idea, plan, task, feature, purchase, workflow, or decision makes sense, read references/full-audit.md completely and follow it.

Rules

• Judge the current task or branch, not a charitable improved version.
• Prefer live sources of truth: the user's actual request, runtime behavior, logs, data, and real device evidence.
• Be honest without manufacturing objections or failure quotas.
• Locally correct work on the wrong branch is still wrong.
• Do not confuse "the fix compiles" or "the symptom stopped here" with evidence that the real goal is satisfied.