quality-baseline

Quality baseline

Build an evidence ledger, not a generic score. A missing checked-in control is a gap in visible repository evidence, not proof that no organization-level control exists.

1. Freeze repository identity

Record repository path, remote identity, HEAD, branch, working-tree state, stack, package manager, instruction files, CI workflows, and exact verification commands. Preserve unrelated changes.

Complete when: another reader can reproduce the inspected state and commands.

2. Map critical paths and controls

Trace the user-visible and operational paths whose failure would matter. For each path, map:

• functional contracts and external specifications;
• test layers and whether they exercise the real boundary;
• latency, throughput, memory, or size observability;
• timeout, retry, cancellation, cleanup, recovery, and overload behavior;
• dependency, secret, trust-boundary, and release controls;
• supported runtimes, operating systems, renderers, or protocol surfaces.

Use history, churn, and change coupling only as prioritization evidence. A large or frequently edited file is not a defect by itself.

Complete when: every critical path has an evidence-backed control map or an explicit verification gap.

3. Prove or reject findings

For every candidate gap, capture:

• exact evidence and affected contract;
• plausible failure and impact;
• confidence and important unknowns;
• smallest useful verification;
• fix effort and regression risk.

Reject code-smell findings that do not connect to a failure, change-safety cost, measurable bottleneck, or violated repository rule. Reject optimization claims without a workload and measurable symptom. Reject "add tests" without naming what the test must detect.

Complete when: every retained finding has a verification story and every investigated rejection has a reason.

4. Rank pilot work

Rank by impact, evidence strength, verification cost, fix risk, and reversibility. Prefer one bounded pilot whose result can be measured. Route: