KPI: Verification Pass Rate

Definition: The percentage of times

./verify.sh

passes on the first attempt.

Why This Matters

Every failed verification attempt:

• Wastes time re-running checks
• Indicates preventable issues
• Slows down the feedback loop

A high first-pass rate means fewer wasted cycles and faster development.

Metrics

Primary Metric

First-Pass Success Rate - Percentage of verification runs that pass without prior failures.

Formula:

Pass Rate = (Successful First Attempts) / (Total First Attempts) × 100%

Target Benchmarks

Performance	Pass Rate
Poor	<50%
Acceptable	50-70%
Good	70-90%
Excellent	>90%

Measurement

Manual Tracking

Before each verify run, note:

• Is this the first attempt after changes?
• Did it pass or fail?
• What stage failed (format/lint/type/test/build)?

Automated (Future)

Track via CI metrics when available.

Improvement Strategies

1. Pre-flight Checks

Before running full verification, run quick checks:

# Quick lint check (fastest)
npm run lint:check

# Type check (catches most issues)
npm run typecheck

These catch ~80% of issues in seconds.

2. Incremental Testing

After each code change:

# Run affected tests only
npm run test -- --only-changed

3. IDE Integration

Configure your editor to show:

• Lint errors inline
• Type errors inline
• Format on save

Catch issues before you even run verify.

4. Dependency Validation

Before importing a package:

# Check if it exists and exports what you need
ls packages/<package-name>/src

Don't assume a port exists - verify first.

5. Learn from Failures

Each failure is data:

• What stage failed?
• What was the root cause?
• How could this have been prevented?

Record patterns in typescript-coding skill.

Common Failure Patterns

Stage	Common Causes	Prevention
Format	Forgot to format	Auto-format on save
Lint	Unused imports, missing types	Check lint before commit
Type	Wrong types, missing exports	Run typecheck frequently
Test	Logic errors, missing mocks	Write tests first
Build	Missing exports, circular deps	Check imports carefully

Pre-Verification Checklist

Before running

./verify.sh

:

• Code saved and formatted
• No lint errors in changed files
• Types look correct
• Tests updated for changes
• All imports resolve

Anti-Patterns

• "Verify and pray" - Running verify.sh as your only check
• Ignoring warnings - Warnings often become errors
• Mass changes - Large changes = more failure modes
• Skipping local verify - CI failures are slower to debug