Skip to content

ci: enforce declared Python package compatibility - #259

Draft
seonghobae wants to merge 17 commits into
developfrom
fix/foundation-declared-python-compatibility
Draft

ci: enforce declared Python package compatibility#259
seonghobae wants to merge 17 commits into
developfrom
fix/foundation-declared-python-compatibility

Conversation

@seonghobae

@seonghobae seonghobae commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Finding

Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f consolidated repository-owned quality into Foundation CI, while merged Python packages already declare support below the primary CPython 3.14 runtime. Structured Interview Plan #40 is the concrete adopter: it declares requires-python = ">=3.12" and historically exercised 3.12/3.13/3.14. Deleting its retired package-local workflow without replacement evidence would weaken the declared runtime contract.

Earlier heads repaired four distinct defects: metadata/parser failure being reclassified as an unsupported-package skip; patch-sensitive PEP 440 evaluation against fabricated major.minor.0; owned packages escaping acceptance when src/ or tests/ disappeared; and a second compatibility matrix job that violated the protected one-job Foundation admission contract. Exact head f529086c... produced the real queue-shape RED in Foundation run 34050838082.

Exact head 79e8757515673144b68687517360cf493e93ccb8 then produced Foundation GREEN in run 34053906336: the single Repository quality job passed exact checkout, runner-image proof, Foundation validation, dependency hygiene, primary package/service/PostgreSQL contracts, Python 3.12 compatibility, Python 3.13 compatibility, and clean-checkout proof.

That GREEN exposed one remaining provenance finding on review: .github/requirements/foundation-compatibility-test.txt was hash-locked per dependency but its complete file bytes were not bound by the canonical manifest inventory. A reviewed compatibility dependency set could therefore change without changing the manifest unless a tracked artifact bound it.

Current repair

Current successor f1f152b0838e11cba1cf583706eb0983d56af373 keeps the same one-job compatibility behavior and adds a fail-closed provenance check before compatibility installation:

  • .github/workflows/foundation-ci.yml remains exactly one quality job on ubuntu-24.04;
  • primary CPython 3.14 package/service/PostgreSQL contracts run first;
  • before switching runtimes, Foundation verifies the complete compatibility requirements file against reviewed SHA-256 cebb36181e8ac995a36d73a02a45094a204ff5adb3cbcdc0c9eccff309ac6aab;
  • CPython 3.12 and 3.13 then execute sequentially in the same job;
  • package discovery remains package-neutral; exact executed interpreter patches drive PEP 440 selection; malformed metadata and incomplete owned package layouts fail closed; compatibility evidence is non-vacuous and keeps each package's 100% statement/branch contract;
  • the compatibility file remains installed with --require-hashes --no-deps --only-binary=:all:;
  • the manifest-sealed workflow now transitively integrity-binds the compatibility input instead of relying on an untracked mutable dependency file;
  • retired package-local workflows remain retired.

The final Foundation workflow is resealed in manifest.json as SHA-256 27fd3f2a69181e6a31b49ab2a3d394bfc8dca2b8ef5e9ce39324273f7962773d, 11,708 bytes, 251 lines. A manual manifest transcription error on an unrelated migration digest in intermediate commit 581e1a3f... was immediately detected by exact diff review and corrected in normal fast-forward successor dd89898a...; comparison against 79e875... after correction shows only the intended Foundation workflow and its manifest entry changed. No migration source was modified.

Traceability is synchronized at the current head and records the successful 34053906336 predecessor evidence plus the provenance repair rationale.

Exact-current-head authority — 2026-09-12

  • exact head: f1f152b0838e11cba1cf583706eb0983d56af373;
  • protected base: develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f;
  • state: open · Draft · mechanically mergeable;
  • Foundation 34057542130: terminal SUCCESS;
  • SAST 34057542122: terminal SUCCESS;
  • Security 34057542151: terminal FAILURE only in dependency-review. Exact-head checkout/verification succeeded; sibling scanners completed, but central owner .github#810 still records the fail-closed public non-fork dependency-comparison availability/configuration incident. This is incomplete authoritative security evidence, not an Orgmetra source vulnerability and not permission for a local substitute or gate weakening;
  • CodeQL 34057542155: terminal FAILURE on this exact immutable head. Historical compatibility consumers failed at current-head verdict enforcement before their downstream dispatch path could complete. The central authority has advanced: protected .github/main is now fb17ef556f94f673234aa557254ae52779e9a7b0; canonical producer/consumer successor .github#2040 is exact 85522306949bada2b5939608dc911f6374125f1b, 150 ahead / 0 behind, open · Draft · mergeable after ordinary reconciliation; and its protected-handler bootstrap prerequisite .github#2106 is exact 24bb6591ab7df23558cb793b4af60c567ff9da97, 24 ahead / 0 behind the same protected main, open · Draft · mergeable. #2106 current-head Runtime Quality/SAST/Python Security/Security are GREEN while CodeQL remains terminal non-passing with both language dispatches successful and verdict pending; independent approval is absent. This is still a central bootstrap/settlement cycle, not an Orgmetra leaf finding. Therefore no ci: enforce declared Python package compatibility #259 rerun, synthetic verdict, no-op churn, or product-repository workflow copy is justified until the central protected-handler prerequisite and canonical successor integrate normally and current-head evidence converges;
  • predecessor evidence remains historical RCA only and is not transferred;
  • fresh review state remains without a qualifying independent APPROVED review. Live organization ruleset 18156473 still requires one approving review while naming no reviewer/code-owner/last-push authority. .github#772 owns that solo-maintainer governance deadlock; self/model approval and routine administrator bypass remain forbidden.

Scope boundary

The HTTP services declare Python 3.11 support. This PR does not claim that service-runtime compatibility; #260 remains the separate successor after #258/#259 is normally integrated.

Owner dependencies and acceptance

Keep Draft until the unchanged exact head has terminal authoritative central Security/CodeQL evidence and the then-live protected review governance is structurally satisfiable. Do not self-approve, use routine administrator bypass, manufacture a status, weaken a gate, create a no-op retrigger, or copy central workflow source into Orgmetra.

After protected integration, #40 and #42 can non-force adopt the canonical Foundation capability without restoring package-local workflow ownership.

Move declared Python package compatibility into canonical Foundation ownership. Keep CPython 3.14 as the primary quality lane, add exact-head CPython 3.12/3.13 package compatibility on ubuntu-24.04, discover package contracts from pyproject metadata without package-name switchboards, retain package-owned 100% statement/branch coverage, and bind the compatibility test toolchain with reviewed hashes.

Implements the source repair for #258 without closing it before protected integration.
@coderabbitai

coderabbitai Bot commented Sep 6, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Distinguish a valid unsupported requires-python constraint from parser or metadata failure. Missing, blank, malformed, or invalid specifier metadata now fails the compatibility job instead of being converted into a package skip. Add executable Foundation hygiene coverage, update traceability, and reseal the exact Foundation workflow bytes.

Copy link
Copy Markdown
Contributor Author

Fresh central owner correction for the current CodeQL RCA: .github#1925 should no longer be summarized as a workflow compile/template-validation failure before execution. Direct run evidence shows validate-dispatch receives a runner, setup succeeds, and the OpenCode app-token exchange succeeds. The failure occurs when client_payload.matrix (an array) is evaluated into a scalar step-level env: value in Bind workflow inputs to live org PR metadata; the native CodeQL scan job is then skipped. The likely toJSON(...) repair and real redispatch verification remain central-owner work. #258 has been updated with this narrower mechanism. No #259 source change/no-op retrigger is justified by this correction.

Copy link
Copy Markdown
Contributor Author

Fresh adopter canary from #98 after ordinary protected-parent reconciliation: #98 exact ec39bfa9bcb73b2b7730a0a6115b2e484d78acb2 adds packages/document-record-evidence, targets develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, and its Foundation run 34625702215 reached Run owned unit and service contracts once SUCCESS. The protected workflow’s explicit pytest list does not include packages/document-record-evidence, so that step is a concrete false-green for a newly owned package: exact checkout/compile/foundation validation can pass while the package’s own 100% statement/branch contract is never executed. This is direct current-head acceptance evidence for #259’s package-neutral discovery requirement. Do not repair #98 by restoring its retired feature-local workflow; keep #98 Draft until the canonical Foundation successor is protected truth and the package is actually discovered/executed on a fresh exact head.

Copy link
Copy Markdown
Contributor Author

Fresh central CodeQL owner-path correction for current dependency metadata: the #259 body still references .github#2040@d7bb95f6..., but live #2040 has ordinary-forward reconciled to protected .github/main@cb0872c9a20d5584703dffacca65c096fc034c6c and now has exact head 3b2de64c2c4c95c56d2f5099a480a0825304d038, open · Draft · mergeable while the reconciled head reacquires hosted/security/review evidence.

This changes no Orgmetra source and does not transfer central predecessor GREEN. #259 remains exact f1f152b0838e11cba1cf583706eb0983d56af373, Draft, with its historical exact-head Foundation/SAST evidence and unresolved central Security/CodeQL plus independent-approval prerequisites. Do not rerun/no-op-churn #259 merely because #2040 moved; wait for normal protected central integration and then reacquire whatever exact-head evidence the live policy requires.

Copy link
Copy Markdown
Contributor Author

Fresh central-owner authority update: protected ContextualWisdomLab/.github/main has advanced from cb0872c9... to 691fb78932eff5fbe52db69077848134b0b4e053. Canonical CodeQL successor #2040 is currently exact be25a767aa2e0d5cb79d6988853011bae16d4be3, open · Draft · GitHub reports non-mergeable. Fresh compare against protected main@691fb789... is 147 ahead / 8 behind with merge base still cb0872c9...; therefore the earlier #259 body statement that #2040 was reconciled 145 ahead / 0 behind onto protected main is now stale. This is a central-owner reconciliation finding, not justification for an Orgmetra no-op rerun, copied workflow, synthetic verdict, force update, or gate weakening. Keep #259 Draft until the central successor ordinary-forward adopts the new protected main and reacquires current-head evidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant