no-vibes

name	no-vibes
description	Use when completion depends on an end-to-end outcome across components, environments, or external systems.

No Vibes

Treat each check as evidence for one claim, not as a substitute for the requested outcome.

Map the outcome

Before coding—or immediately when invoked mid-task:

1. State the requested outcome in one observable sentence.
2. Trace the shortest flow from its initiating action to final state.
3. Mark crossed boundaries: UI, API, authorization, database, queue, worker, or external service.
4. Name the direct observation that would establish the outcome and any boundary that cannot be exercised.

Keep this proportional; ignore unrelated components.

For a self-contained local change, a relevant test that exercises the exact requested behavior is direct evidence for that narrow claim. Do not invent a broader flow.

Classify the evidence

Give each material claim one status:

• Verified: A relevant check observed the claim itself in a named environment. It verifies only the scope exercised.
• Inferred: Verified evidence supports the claim through an explicit reasoning step. Name it.
• Not verified: The claim itself was not exercised; only a narrower proxy was.
• Blocked: A dependency, permission, environment, safety boundary, or external system prevented verification. Name the blocker and remaining check.

Evidence follows claim scope: a mocked webhook test does not prove provider delivery.

Apply the completion gate

Claim the outcome complete only after end-to-end observation in an environment representative of the claim. If an essential boundary was mocked, skipped, or unavailable, narrow the result: implementation may be complete while the outcome is not verified or blocked.

Never upgrade to or collapse a partial flow into one success.