PEP 668 fixes should keep pip check as a second-stage conflict detector

When this applies: a digest-pinned Python base image is externally managed, while an application image must install a separately locked runtime environment into that interpreter. Use the explicit package-manager override only at the controlled mutation sites, keep the externally-managed marker intact, and retain an unsuppressed pip check after installation. Passing the PEP 668 gate does not prove dependency consistency: the next failure can come from an unrelated tool already present in the base image.

A proportionate remedy is to remove only a base package that is proven to be development-only, has no reverse dependencies, and is not used by startup/runtime behavior, then repeat the exact lock install and pip check. Do not mask pip check, weaken the application lock, or broadly purge base packages. Limit: if the conflicting base package is runtime or system machinery, this technique does not apply; select a compatible base or isolate the application environment instead.

Evidence/example — 2026-09-11: In a local no-cache production-image verification, adding the explicit PEP 668 override allowed a hash-locked, offline wheel install to proceed; the retained pip check then exposed a version conflictlk conflict from an inherited developer CLI. Read-only inspection found no reverse dependencies or startup use. Removing that one CLI before the locked install produced “No broken requirements found,” and the exact image build plus full affected tests passed. Source provenance: current task’s local Docker build logs, image metadata inspection, package metadata, and repository test results. No registry or deployment claim is included.