ci: preserve declared Python compatibility in canonical Foundation ownership

[seonghobae]

Problem

Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f consolidated repository-owned package quality into canonical .github/workflows/foundation-ci.yml, whose primary Python runtime is CPython 3.14 on ubuntu-24.04. Product packages can declare a wider supported runtime contract that must not disappear when historical package-local workflows are retired.

PR #40 is the concrete adopter: packages/interview-plan/pyproject.toml declares requires-python = ">=3.12" and its historical workflow exercised 3.12/3.13/3.14. #42 independently showed that a shared dispatcher must not become a package-name switchboard.

Implementation review has repaired five distinct failure modes in Draft PR #259:

• metadata/parser errors must fail closed rather than become unsupported-package skips;
• PEP 440 must be evaluated against the actual executed interpreter patch, not fabricated major.minor.0;
• every discovered owned package must retain both src/ and tests/ or fail closed;
• compatibility must not add a matrix/second Foundation job and recreate Actions admission pressure;
• the reviewed compatibility dependency file must be integrity-bound as complete bytes, not only contain individually hashed requirement lines.

Historical head f529086c... produced the real queue-shape RED in Foundation 34050838082: its 3.12/3.13 compatibility jobs succeeded while Repository quality failed the canonical one-job runner contract. Head 79e8757515673144b68687517360cf493e93ccb8 then produced Foundation SUCCESS in 34053906336 with sequential 3.12/3.13 execution inside the single quality job. Current exact head f1f152b0838e11cba1cf583706eb0983d56af373 additionally binds the complete compatibility requirements file by reviewed SHA-256 before installation; Foundation 34057542130 is terminal SUCCESS on that unchanged head.

Canonical acceptance

• keep .github/workflows/foundation-ci.yml as the sole repository-quality owner with exactly one Foundation job on ubuntu-24.04;
• preserve primary 3.14 package/service/PostgreSQL acceptance;
• execute package-neutral 3.12 and 3.13 compatibility sequentially inside that same job;
• use actual interpreter patch PEP 440 selection, fail-closed metadata/layout handling, hash-locked binary-only tooling, complete-file provenance binding, and non-vacuous execution;
• preserve each selected package's exact 100% statement/branch coverage contract;
• keep retired package-local workflows absent and avoid package-name switchboards;
• reseal manifest.json from final Foundation workflow bytes;
• require fresh exact-head Foundation/security/code-scanning/review evidence before protected integration.

Active implementation

Draft PR #259 is the canonical implementation. Current exact head is f1f152b0838e11cba1cf583706eb0983d56af373, direct base develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, open · Draft · mergeable. The manifest-sealed Foundation workflow is SHA-256 27fd3f2a69181e6a31b49ab2a3d394bfc8dca2b8ef5e9ce39324273f7962773d, 11,708 bytes, 251 lines.

Current exact-head evidence:

• Foundation 34057542130: terminal SUCCESS;
• SAST 34057542122: terminal SUCCESS;
• Security 34057542151: terminal FAILURE only at the fail-closed Dependency Review availability probe after exact-head verification; Scorecard, OSV, and Trivy succeeded while the pinned Dependency Review action was skipped because support could not be established. Central owner is ContextualWisdomLab/.github#810; no Orgmetra-local substitute is valid;
• CodeQL 34057542155: terminal FAILURE after language detection and both current-head Python/Actions dispatch requests succeed, then both compatibility jobs fail at Release runner or enforce current-head CodeQL verdict. Fresh central #1925 evidence corrects its original wording: the handler does acquire a runner and exchanges the app token; it then fails when the array-valued client_payload.matrix is evaluated into a scalar step env: value, so the native scan job is skipped. This is a step-evaluation/dispatch-handler defect, not a workflow-compile failure. .github#1927 separately owns the later dispatch-identity authorization decision;
• fresh review enumeration remains without a qualifying submitted approval. Live ruleset 18156473 requires one approval while naming no reviewer/code-owner/last-push authority; .github#772 owns the solo-maintainer governance repair. Self/model approval and routine administrator bypass remain invalid.

These central failures are non-passing acceptance, but they are not a reason to mutate the unchanged #259 source, manufacture a verdict, or weaken exact-head gates.

Dependency order

After normal protected integration, #40 and #42 must non-force adopt the protected generic Foundation owner rather than restore package-local workflow ownership. #260 remains the separate Python 3.11 service-boundary compatibility successor. #261 is a later installed-wheel successor: fresh People-owner review proved that source-tree PYTHONPATH acceptance can mask stale internal package pins, so installed-artifact acceptance must be added from protected #259/#64 truth rather than widening this mutable Foundation PR.

No force-push/destructive rebase, compatibility-range reduction, invalid-metadata skip, incomplete-package skip, fabricated runtime patch, matrix/second-job expansion, source-tree packaging claim, predecessor-GREEN transfer, administrator bypass, or gate/provenance weakening.