Repository navigation
ci: replace source-tree PYTHONPATH acceptance with installed-wheel contracts #261
Description
Finding
Canonical Foundation currently executes owned package/service tests by putting repository src directories on PYTHONPATH. That proves source-tree behavior but does not prove the published Python packaging contract. Fresh inspection has now exposed two concrete classes of defect hidden by that arrangement.
First, services/people-api/pyproject.toml declared orgmetra-hris-kernel==0.1.0 while the canonical owned packages/hris-kernel/pyproject.toml version is 0.4.0. Source-tree import injection bypassed dependency resolution, so exact-head Foundation could remain GREEN despite the stale internal pin. Canonical People owner #64 carries the test-first version-pin repair.
Second, both HTTP services advertise Python >=3.11 on protected truth while their mandatory owned HRIS-kernel and Keyverse adapter distributions both require Python >=3.12. The same source-tree execution therefore also hides an impossible interpreter/dependency-closure contract. #64 now carries the People-side >=3.12 repair and a focused runtime-floor regression; #260 has been corrected to own repository-level service runtime metadata/compatibility reconciliation rather than preserving an unsupported Python 3.11 claim.
Required owner order
Do not copy mutable #259 or #64 source. #259/#258 first establish the canonical package-neutral declared-Python Foundation owner on protected develop; #64 then integrates the People metadata corrections through its normal owner path. #260 reconciles the remaining service runtime metadata, including Job Analysis, from protected owner truth. This installed-artifact successor must consume those protected contracts rather than preserving stale source-tree assumptions.
Acceptance
- Remove repository-owned package/service test reliance on manual
PYTHONPATHas packaging acceptance evidence. - Build each owned Python distribution from the exact checked-out source using a reviewed, hash-locked build toolchain; build isolation/dependency acquisition must not fetch unreviewed mutable artifacts.
- Compute and record each produced wheel SHA-256 before installation; install/test the exact built wheel, not the source tree or an editable install.
- Resolve Orgmetra-internal service dependencies against the exact owned distribution versions declared in their pyprojects; a stale/missing/duplicate internal pin must fail before service tests.
- Validate that each service's declared Python runtime is compatible with the complete mandatory owned dependency closure; do not claim a lower interpreter solely because service metadata advertises it.
- Keep package/service discovery owner-neutral rather than a package-name switchboard where practical.
- Preserve truthful declared Python compatibility acceptance from ci: preserve declared Python compatibility in canonical Foundation ownership #258/ci: enforce declared Python package compatibility #259 and ci: reconcile service Python runtime metadata and executable compatibility #260. A lower runtime floor is acceptable only when the full installed dependency closure has executable evidence at that runtime.
- Preserve exact 100% statement/branch coverage for owned production code. Coverage must measure the installed artifact and must not silently fall back to
srcthrough cwd/import precedence. - Keep one canonical Foundation quality job on
ubuntu-24.04; do not reintroduce package-local workflows or matrix/job admission pressure. - Prove wheel contents do not accidentally include tests, repository-only files, secrets, or sibling package source, and that package-data such as
py.typedis present where declared. - Add executable regressions for stale internal dependency versions, incompatible dependency runtime floors, source-tree import leakage, wheel digest binding, and clean environment installation.
- Reseal deterministic provenance/manifest inputs from final bytes and acquire fresh exact-head Foundation/SAST/Security/CodeQL/review evidence before protected integration.
No cross-service SQL, mutable sibling source copy, editable install, unpinned build backend download, PYTHONPATH workaround, coverage exclusion, no-op retrigger, force-push, destructive rebase, self-approval, routine administrator bypass, or gate weakening is an acceptable substitute.
Activity
seonghobae commentedon Sep 18, 2026
Service-local #409 reconciliation found one more installed-wheel false-GREEN on canonical Workforce Validation owner #235. Predecessor
885e3a98282283635e1f5a4d06f79a6d52c48dcahash-bound both built wheels and installed them directly, but did not inspect built.dist-info/METADATA. A service wheel that silently omitted mandatoryRequires-Dist: orgmetra-keyverse-adapter==0.1.0could therefore still pass because Keyverse was independently present in the lock andpip checkhad no declared missing dependency to report.Ordinary-forward repair:
c92855b583cfad3aac51a1d21b793203d7372f6a— source-first synthetic-wheel regression proving the detachment is not rejected by predecessor acceptance; no hosted RED claimed.88c8743b47b76ab8b0e233e3a73836617188da2d— parses the exact built wheel's single.dist-info/METADATA, bindsName/Version/Requires-Pythonto reviewed project metadata, and requires exactly one unconditional exact KeyverseRequires-Distbefore accepting the wheel hash lock.This advances only the Workforce Validation slice. #261 remains open for repository-wide installed-wheel migration and owner-neutral coverage.
seonghobae commentedon Sep 18, 2026
Workforce Validation service-local evidence on #235 advanced again without claiming repository-wide completion. Fresh artifact review found that an outer wheel SHA-256 plus built METADATA validation still did not prove the wheel's own installation
RECORDwas truthful. A wheel could be byte-bound as an archive while carrying a false/incomplete per-member hash/size ledger.Ordinary-forward lineage:
fb92e3b52f40b4a1ef8c26c3a833480960246252: source-first regression constructs internally recorded synthetic wheels, corrupts one member digest, and requires fail-closed verification. Predecessor acceptance did not inspectRECORD; no hosted RED is claimed for this intermediate SHA.396d8ae80cdca9b601eedd7a4ec134767e1ea7cb: adds strictRECORDintegrity checking: one canonical record, no duplicate archive/ledger paths, exact archive-member coverage, canonical relative paths, sha256 and byte-size equality for every non-self member, empty hash/size for theRECORDself-entry.5d6433a7fab230b5af2913a0fd4c869f5a804ac4: applies the same contract to the actual Keyverse and Workforce Validation wheels built from the checkout.This suggests repository-level #261 acceptance should include internal wheel
RECORDintegrity in addition to outer artifact digest, METADATA/dependency closure, installed-artifact coverage and source-tree leakage checks. #235 remains Draft; exact-head hosted gates and independent approval are still required.seonghobae commentedon Sep 18, 2026
Workforce Validation service-local installed-wheel evidence exposed one more path-identity gap on #235. The first RECORD validator compared raw ZIP/RECORD names, so raw-distinct entries such as
alias/__init__.pyand./alias/__init__.pycould both be internally hash-correct while normalizing to one install path.Ordinary-forward lineage:
ee8ea428950f6f38685246b1367575df3ffc4a57: source-first regression requires that normalized-path alias wheel to fail closed; no hosted RED is claimed for the intermediate SHA.7c69e03ba356bc8b7f68b278c5978b5f4de49775: canonicalizes every archive and RECORD member path, requires raw spelling to equal canonical relative POSIX form, and rejects normalization aliases/collisions before coverage/hash acceptance. The real built-wheel test reuses the same validator.Repository-level #261 acceptance should therefore treat canonical installed path identity as part of wheel integrity, not just raw-name uniqueness, outer digest, METADATA, and RECORD hashes. #235 remains Draft and this does not claim repository-wide completion.
seonghobae commentedon Sep 18, 2026
Workforce Validation service-local evidence on #235 found and repaired a causal-path gap in installed-wheel integrity. Current-head review of predecessor
7c69e03ba356bc8b7f68b278c5978b5f4de49775correctly noted that a separate test validating real-wheelRECORDfiles did not prove the exact helper that emits the SHA-256 install lock rejects a false ledger.Ordinary-forward lineage:
468bb9afeb79506ded577fcd3c30014c7c0890d5: source-first integration RED requires_locked_wheel_requirements(...)itself to reject a wheel with a false RECORD member digest; predecessor code could not do so. No hosted RED is claimed for this intermediate SHA.860fbcb2e7a91d3ad0bee5b8a23b59060cb41977: canonical member-path/RECORD verification moves into the exact lock helper and runs before_sha256(wheel_path).cc0254197dafd4b72428bed6699341d278fba66c: the synthetic invalid-RECORD regression now exercises that lock helper rather than a parallel validator.ef41ebe2607410c7d945c061e86820d61d9e21d8: the real built-wheel test also reuses the same validator.Repository-wide #261 acceptance should therefore require internal ledger/path validation on the same causal path that emits the artifact digest/install lock. A parallel integrity test is useful regression evidence but is not by itself proof that an invalid artifact cannot enter installation. This remains service-local Draft evidence and does not claim #261 completion.
seonghobae commentedon Sep 18, 2026
Service-local #409 evidence on canonical Workforce Validation owner #235 found another installed-artifact false-GREEN relevant to this repository owner. Exact head
6565f6160c4f60458b4ff0b916ab3e79d67b04d4now requires the complete builtRequires-Distmultiset to equal reviewed[project].dependencies, not merely the presence of one mandatory internal dependency. Source-firstafa0d25c3a3925241e5abd3e48994f58644e626ademonstrates that an added marker-disabled dependency could otherwise evade offline install/pip check;6565f616...binds canonical name, extras, specifier, marker and URL and also enforces Keyverse's current empty runtime-dependency set. This is service-local evidence only and does not claim #261 repository-wide completion.seonghobae commentedon Sep 18, 2026
Correction to the prior Workforce Validation service-local handoff:
6565f616...was not a complete final model because it compared builtRequires-Distonly with base[project].dependencies. Keyverse legitimately owns[project.optional-dependencies].test, which compliant wheel metadata represents asProvides-Extra: testplus extra-gatedRequires-Dist. Source-first0d084772ffd0a2bdddce6db10fe656f95ecd8dbccaptures that false-negative; current service-local head508c6ea1d8998356448e90839a91ddc266907c7dexpands reviewed base+optional dependencies into core-metadata semantics, binds canonical name/extras/specifier/marker/direct URL for every built dependency, and requires normalizedProvides-Extrato match reviewed optional groups. The unreviewed marker-disabled dependency regression fromafa0d25c...remains covered. #261 remains open; this does not claim repository-wide completion.seonghobae commentedon Sep 18, 2026
Service-local follow-up: exact-head review of
508c6ea1d8998356448e90839a91ddc266907c7dfound one P1 test-contract gap in the new optional-dependency ledger check. Production semantics were otherwise accepted in static inspection, butProvides-Extrahad only a valid fixture. Current #235 headf76e337dbdb2f3fef3b537cc90745e5e7f0f201fadds direct hash-lock-path rejection coverage for missingProvides-Extra: test, a different normalized extra name, and duplicateProvides-Extra: test, while retaining the compliant Keyverse optional-dependency case. This remains service-local evidence; #261 stays open.