ci(workforce_validation): admit owner-schema PostgreSQL contract to both Foundation provenance inventories

[seonghobae]

Real hosted RED

Draft #235 exact 72ec2296cbc6b2df94e9c4e7394a8990061d0c88 reached a GitHub-hosted ubuntu-24.04 runner in Foundation run 33974101917, Repository quality job 101327654556. Exact checkout, Python/Node setup, compilation, and runner-image checks passed. npm run validate then failed in tests/dispatcher-inventory.test.mjs with:

Node inventory omitted tests/test_workforce_validation_owner_schema_postgres.sh

The contract was already executable from .github/workflows/foundation-ci.yml and the dispatcher intentionally discovers every root test_*_postgres.sh, but #235 had admitted the new contract to workflow execution without adding it to scripts/foundation-contract-core.mjs::REQUIRED_FILES. The parallel Python tests/validate_repository.py::REQUIRED list also omitted it, and manifest.json is sealed from that Python inventory.

Ordinary repair lineage

• 195ffef5026625d5e1d36b0dbd0175acb4f65108 adds tests/test_workforce_validation_owner_schema_postgres.sh to canonical Node REQUIRED_FILES. Its workflows were cancelled after the ordinary successor advanced the branch, so it is not GREEN evidence.
• c91df2374eaf65bb36a337854cd231c601e93cb7 adds the same contract to Python REQUIRED, preserving the exact dual-inventory assertion instead of exempting the contract. Exact-head CodeRabbit review at this predecessor found the remaining P1: manifest.json still had the stale path set/seals.
• e87d28a32683c6e6f115b3d13645b7d263451795 reseals manifest.json from the exact repaired artifacts. The material entries are:
  • scripts/foundation-contract-core.mjs: SHA-256 5dfc54d40820dfc45962dcc91367c57baf6b011e68efc5f6e8d59e7e82145b2a, 28,182 bytes, 689 lines;
  • tests/validate_repository.py: SHA-256 244627252e7392e4dbed98392c132cb86dc8e5ead839a1129298e8d022fcf8eb, 27,300 bytes, 638 lines;
  • tests/test_workforce_validation_owner_schema_postgres.sh: SHA-256 29f0cd8a7d9040ff86095b68fa2f3d0ed54ea3777e5a816d4a79eb6ceafb9339, 2,949 bytes, 76 lines.

No workflow command, PostgreSQL test body, schema/role/migration, service behavior, coverage threshold, or manifest path-equality gate was weakened.

Successor acceptance — 2026-09-06

CodeRabbit reviewed exact e87d28a32683c6e6f115b3d13645b7d263451795 against protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f and found no blocking defect in the requested #254 scope. It verified the dual canonical inventory admission, exact manifest parity/seals, single existing workflow invocation, and absence of gate weakening or unrelated runtime/schema changes. That remains static causal evidence for the #254 repair rather than current merge approval.

The canonical #235 branch has since advanced ordinarily to exact dd95dd7256f37aab2c4f26aa1fb43e8c867f4e4d through the separate #255 test-only coverage repair. Current Foundation 33986151272 is terminal SUCCESS on that exact successor: repository validation accepts both canonical inventories and the deterministic manifest, owned service suites pass at the required coverage contract, and the isolated Workforce Validation owner-schema PostgreSQL contract executes successfully. SAST 33986151255 is also terminal SUCCESS. No #254 production/workflow/provenance byte was reverted by #255.

Security 33986151270 and CodeQL 33986151302 remain terminal non-passing for shared control-plane reasons already recorded on #235/#255; they are not evidence that the #254 dual-inventory/manifest repair regressed. Submitted #235 reviews remain COMMENTED-only with no qualifying APPROVED review.

The #254 causal repair therefore has hosted successor GREEN, but this issue remains open through normal #235 protected integration or a verified successor carrying the same inventory/manifest/PostgreSQL contract. Do not close on source presence alone, remove the contract from either inventory, weaken exact-set validation, manufacture a leaf security verdict, self-approve, or use routine administrator bypass.