confidence-check

confidence-check, is the ground under this actually known?

Three things get assumed at the start of implementation and are wrong often enough to be worth a minute: that nothing equivalent already exists, that the API is as remembered, and that the bug's cause is understood rather than guessed. Settle them before writing, not after.

Five checks

1. No duplicate exists

   • Search codebase for similar functionality
   • Check if existing code can be extended instead

2. Architecture compliant

   • Uses existing stack and patterns in the project
   • No unnecessary new dependencies
   • Follows project's established conventions

3. Official docs reviewed

   • Library or framework API verified against current version
   • Breaking changes checked if upgrading

4. Working reference found

   • OSS example or proven pattern identified
   • Not relying on untested approach

5. Root cause understood

   • For bugs: clear understanding of WHY it fails
   • For features: clear understanding of requirements

What to do with the answers

Where any check is unsatisfied, say which, and ask. Where all five are satisfied, proceed. That is the whole rule, and it is why no score is kept: a single miss is the whole answer, so a percentage carries nothing the list of unsatisfied checks does not, while looking like a measurement.

A number also invites the wrong move. It can be nudged: one check called "partial" instead of "failed" lifts a total past a threshold, and nothing in the report shows that happened. A named unsatisfied check cannot be nudged; it is either answered or still open.

An unsatisfied check is not a reason to stop. It is a thing to say out loud before writing code, so the person who can settle it gets the chance. Most are settled in one exchange.

Output format

Ready:      <checks satisfied, one line each>
Not ready:  <check>: <what is missing, and what would settle it>
Unknowable here: <check>: <who can answer>

<Proceeding, or Asking first>, because <the one sentence that follows from above>.