dev-loop

Map the blocking critical path, classify each step by the evidence it produces, then remove or parallelize no-evidence work and move non-blocking validation off the PR path. Verify that any skipped work has an explicit escalation or scheduled fallback so coverage is preserved, not silently dropped.

Derive the affected scope from the dependency graph rather than filename heuristics, and pair selection with a safe escalation path for high-risk changes like shared libraries, schemas, or toolchains. Validate both a positive affected case and a negative unaffected case before trusting the selection logic.

Cache keys may be too broad, causing misses, or transfer and storage costs may exceed the recomputation avoided. Check that keys include toolchain, lockfile, and true source inputs while excluding timestamps and absolute paths, and verify hit, miss, and invalidation paths explicitly.

A blocking gate must state the failure it prevents, the distinct evidence it adds, why it must run pre-merge, and why it cannot be scoped to affected changes. Long release, compliance, or platform-matrix work should move to asynchronous or scheduled validation unless change risk requires it.

Do not use it as the primary workflow for production runtime performance issues like API latency, database query tuning, memory leaks, or frontend rendering unless those issues directly slow the development feedback loop. It targets developer and CI feedback, not production performance engineering.