ci: make PostgreSQL Foundation contracts non-vacuous and owner-neutral

Verified Foundation false-green

Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f keeps repository quality in the single canonical .github/workflows/foundation-ci.yml, but its PostgreSQL acceptance is still a hand-maintained contracts=(...) array. Newly owned PostgreSQL contracts therefore do not automatically become part of Foundation acceptance.

The current document_records stack is a concrete canary. #107 now owns tests/test_document_record_persistence_postgres.sh, tests/test_document_record_evidence_unique_keys_postgres.sh, and tests/test_document_record_canonical_bytes_postgres.sh, yet protected Foundation does not know those names. A repository can consequently add a PostgreSQL owner contract while Foundation remains GREEN without executing it.

This is the PostgreSQL analogue of the package-discovery problem owned by #258/#259, but it is a distinct acceptance surface. Do not solve it by appending three more #107 filenames to the switchboard.

Canonical acceptance

Keep .github/workflows/foundation-ci.yml the single repository-quality owner and its one-job admission shape. Replace/encapsulate the fixed PostgreSQL filename array with a deterministic, fail-closed, non-vacuous contract-discovery/declaration mechanism that:

discovers every repository-owned PostgreSQL contract intended for Foundation, independent of bounded-context/package name;
rejects malformed ownership metadata, missing scripts, duplicate registrations, unreviewed exclusions, and empty/vacuous discovery;
executes each discovered contract in an isolated PostgreSQL container with the current pinned image/digest and bounded readiness probe;
preserves special follow-up contracts such as schema-hardening only through generic metadata/contract composition, not a growing if contract == ... switchboard;
makes intentional exclusions explicit, reviewed, integrity-bound and traceable rather than silently absent;
keeps contract bytes/registration provenance sealed by the canonical manifest or an equivalent manifest-sealed artifact;
emits enough exact evidence to prove which contracts were discovered and executed on the candidate head;
preserves container cleanup on success/failure and does not leak ports/processes across contracts;
does not add a second Foundation job/matrix or resurrect feature-local workflows.

RED/GREEN acceptance

Add a RED repository test showing a syntactically valid new PostgreSQL contract can exist under tests/ while the current fixed array still reports Foundation success/does not discover it.
Repair Foundation so the same canary is deterministically admitted without naming that bounded context in workflow source.
Add negative cases for malformed registration, missing target, duplicate contract identity, excluded-but-unreviewed contract, and zero discovered PostgreSQL contracts.
Keep ci: preserve declared Python compatibility in canonical Foundation ownership #258/ci: enforce declared Python package compatibility #259 package-neutral Python behavior intact; this successor must ordinary-forward adopt the then-current canonical Foundation owner rather than reimplement it.
Reseal manifest.json from final bytes and reacquire exact-head Foundation/SAST/Security/CodeQL/review evidence before protected integration.

Current adopters

feat(document-records): add governed HR document evidence #98 package evidence: current Foundation GREEN is explicitly not package acceptance.
feat(document-records): persist immutable HR document metadata #107 document persistence: three new PostgreSQL contracts are currently omitted by protected Foundation.
operability(document-records): make durable metadata persistence idempotent under uncertain retry #309 idempotent persistence and feat(document-records): 반환·파기 완료 receipt 권위 계약과 복구 불가능성 evidence #308 lifecycle completion/recovery will add further PostgreSQL contracts and must not require another filename switchboard edit.

Do not weaken coverage/gates, synthesize statuses, restore leaf workflows, create a second quality job, or treat compileall/file presence as execution evidence.

Fresh #107 canary adds one more acceptance invariant for the PostgreSQL Foundation owner. Current document_records contract had migrations on DATABASE_URL but RLS reader probes hardcoded localhost:5432/orgmetra; CodeRabbit correctly identified that a dynamic CI host/port/database could therefore test a different target. #107 ordinary-forward 7ce73aa44f47113b2ecd42d51bb5d38a22c0367d now derives the GRANT target from current_database(), replaces only reader authentication in the configured URI, verifies the same database identity, and uses that endpoint for every RLS probe.

#310's generic contract runner should preserve this property: provide one authoritative per-contract DATABASE_URL for migration and all acceptance clients, permit dynamic ports/database names, and fail if an owner contract silently substitutes localhost/default database. Do not solve this by standardizing every contract on orgmetra; the runner must make the actual isolated target explicit and contracts must consume it.

#310 now has an implementation successor: PR #311, stacked on #259, current exact head 15ec7bf142503f0e92a0feb8b13f164cfeb32613. It replaces the fixed PostgreSQL filename array with a registry plus independent discovery, generic companions, per-contract isolated PostgreSQL 16.14 containers, and one authoritative dynamic DATABASE_URL; the PR remains Draft and has no hosted current-head Foundation run because its base is #259 rather than develop.

Fresh source audit found one remaining acceptance defect on that exact head: registry/discovery currently follows symlinks (Path.is_file()/read_bytes()), so a new root path can alias an existing contract and still appear as a distinct integrity-bound owner contract. PR #311 comment 5640281633 records the test-first repair acceptance. Do not mark #310 complete or carry the reported local 16/16 evidence forward until root/companion filesystem indirection is rejected, provenance hashes/manifest are resealed, and the eventual protected-base exact head reacquires required gates and independent approval.

#311 ordinary-forward repaired the symlink-integrity finding on current exact head 2f5a8ed93718acb4b057eae7849a6c69e0cc2807.

Repair lineage: 34e6afe82b9ca34180332e62ea7f02d522adf42e adds root/companion symlink regressions; 3e84679c5bce383e90398987207dc8c9ecfd73b6 rejects symlink components and non-regular/out-of-repository targets in both binding and discovery; e4ba8fa22f4101e9e11400e344d40cbea8f0e748 reseals inline validator/test provenance; 2f5a8ed93718acb4b057eae7849a6c69e0cc2807 reseals manifest.json to the final workflow bytes.

Exact-byte verification at 2f5a8ed...: validator 1470628f8265d2dc39fff1db80379c9395bac416ab6afcc7f4bc78cea49dcf72; tests c41f60972a8f1adf9eb46bf504f074532a97a1fd965b1009e32ddc8bb5d5ca75; workflow 4a30928af750d116bac7260ec0b837136f189a370148103ddcd2d1d193b93ea0 (13,510 bytes / 275 lines); manifest binds that workflow triple exactly. The predecessor local 16/16 result is not transferred, and no hosted exact-head Foundation GREEN is claimed because #311 remains correctly stacked on #259. Fresh CodeRabbit review was requested on the final head; #310 should remain open until #259/#311 reach current protected develop and reacquire required hosted gates plus qualifying independent approval.

Fresh successor audit found one more #310 acceptance gap on #311 exact 2f5a8ed93718acb4b057eae7849a6c69e0cc2807: the inventory is integrity-bound at validation time, but execution is not yet bound to that same immutable snapshot.

Current Foundation obtains the validated root paths, executes each root from the mutable checkout, and only after a root has run re-invokes the live registry CLI to discover that root's companions. The final executed-set comparison checks paths, not executed bytes. Thus a contract can modify a later root/companion or registry binding between initial validation and use; final clean-checkout evidence is too late to prove reviewed bytes were what executed.

Canonical #310 acceptance should therefore include a checked-versus-used invariant: materialize exactly one validated root+companion+SHA-256 execution plan before the first contract runs; retain it in parent execution state; never re-read registry authority after execution begins; verify every script against the captured digest immediately before use and again after the set; and prove with a regression that an intervening mutation is rejected before altered bytes execute. PR #311 comment 5640772647 carries the exact repair acceptance. Keep #310 open until this is repaired, final provenance is resealed, and the eventual protected-base exact head reacquires hosted gates/review.

#311 ordinary-forward repaired the checked-versus-used finding on exact head 758c7a2da720155669f43bd2b79221070e247c67.

Repair lineage: 3c1815e3883f84bde08bcff98405f248f9a2a065 adds the workflow regression; 0a95ed72abada63a516586b40ffd73791bc4a7de captures one validated root+companion+SHA-256 plan before first execution, removes post-start live registry/companion re-resolution, checks every root/companion digest immediately before use, and rechecks the bound set afterward; 758c7a2da720155669f43bd2b79221070e247c67 reseals manifest.json.

Current bound bytes: regression suite 11f256efdfdd951daeb5605e2cfee444eb864f203cf820e9c2bfc360c5691272; Foundation workflow 084fe3897b54c7f69e4c1c11d3cb30246aedf1ceadbe8642c1e9a9f8601fce6 (15,782 bytes / 337 lines), with the manifest entry matching that triple. The digest plan lives in parent-shell state and is not exported to contract subprocesses, so an earlier contract cannot update later expected digests; a changed later root/companion now fails before execution.

No predecessor GREEN is transferred. #311 is still a stacked Draft on #259, so hosted protected-base Foundation/Security/CodeQL/etc. evidence remains to be reacquired after ordinary-forward protected-parent integration. Keep #310 open until those gates and qualifying approval are satisfied.

#311 current owner repair update: exact head is now 818ab0539310f4ca4e6ebeb76323f42ea05640c7 (Draft, mechanically mergeable, still stacked on #259). Fresh audit found a runtime path-identity gap after the earlier checked-versus-used repair: the inventory validator rejected symlink components, but shell pre-use verification only rejected a symlink at the final script path. An earlier contract could replace an ancestor such as tests/ with a symlink and a later same-byte script could still satisfy the captured digest.

Ordinary-forward repair: c8665e7... adds the runtime-component RED contract; eab6cce... revalidates every path component, regular-file status and repository containment immediately before digest/use for roots and companions; 818ab053... reseals manifest.json. Current workflow provenance is SHA-256 af2b54ceaf8e9bf6fb7288dfb31ca43ba81b36ef6edda8e1d8681896b92d1670, 16,829 bytes / 366 lines; regression suite SHA-256 is a3ef84822363878cfe08f3664c1ff33a21acf77e65bc373fb261f8e12f247c85. No hosted exact-head GREEN is claimed because the PR remains stacked and the develop-only Foundation trigger does not materialize here. Keep #310 open until #259 integrates/reconciles and #311 reacquires protected-head gates plus qualifying independent approval.

#311 implementation authority advanced ordinary-forward to 4f4dc87e39e69d84b0024458450976e5e99e3a1a after exact-head review found one remaining checked-versus-used race.

The canonical acceptance is now stronger than immediate pre-use pathname validation: all active PostgreSQL root/companion bytes are revalidated and materialized into a fresh private read-only execution snapshot before any contract begins, and Foundation executes only those snapshot paths. A behavioral regression mutates a later root and companion after snapshot creation and proves the altered repository payloads never execute; source drift before snapshot creation fails closed.

Lineage: RED e0688f720... → snapshot owner implementation bde638ab3... → Foundation execution wiring 5f3d72c7... → manifest reseal 4f4dc87e.... Workflow provenance is SHA-256 5f34a5d117c310c41e03dc97bdab05e5d096845732cecb3bbd4c655dcdf04354, 17,671 bytes / 386 lines. Focused regression suite is locally 22/22 GREEN, but #311 remains Draft/stacked on #259 and has no hosted exact-head Foundation admission yet.

Keep #310 open until #259 is protected truth, #311 ordinary-forward adopts that protected Foundation head, and fresh required gates + qualifying independent approval are obtained.

#311 current implementation authority advanced again to bf15b8bd18204e16bf2e739ff8c7971f8ef12843 after exact-head review proved same-owner snapshot mode bits were insufficient.

The current owner-neutral acceptance now has two separate controls: (1) all reviewed root/companion bytes are frozen before the first contract starts, and (2) contract code executes as distinct non-owner nobody against runner-owned 0444/0555 snapshot/checkout objects. A behavioral regression gives the first contract explicit later-root/companion/snapshot paths and requires chmod/write/rename/remove attempts to fail while the reviewed later payloads still execute.

Lineage for this repair: RED c5e057e6... → causal Foundation boundary bc6fb261... → manifest reseal bf15b8bd.... Current workflow provenance is SHA-256 e01f3c370b6a87ed95f66901704a4e2a83d8740a3d9efd67c15fa77a5c08352d, 18,246 bytes / 401 lines; regression suite SHA-256 de98d839891fc7d396ccc4275b2d69821a8a682ec9153cb5f191b026cbbdc31d.

Keep #310 open: #311 is still Draft/stacked on #259, current head has no hosted Foundation workflow run, and protected integration + fresh required gates/qualifying approval remain prerequisites.

#311 successor authority advanced to exact 778ab5d1ea40a47cfe0153971407e33ccadbef18 (base remains #259 f1f152b0838e11cba1cf583706eb0983d56af373, Draft/mergeable).

A fresh execution audit found that runner-owned immutable snapshot bytes plus shared nobody execution still allowed a root/companion to return while leaving a background process alive with the same DATABASE_URL/PGPASSWORD. That violates this issue's requirement that processes not leak across contracts and cannot be safely remediated with pkill -u nobody because the UID is shared.

Ordinary-forward repair:

75f8fce33... / 7260f24fb...: RED workflow contract for a dedicated ephemeral execution principal and per-root/per-companion process quiescence.
f519343d4...: Foundation now creates orgmetra_pg_contract as a temporary system/no-home/nologin user, runs every snapshot only through one guarded helper, checks pgrep -u after shell return, logs/kills leaks and fails closed, then removes the identity in cleanup.
778ab5d1...: manifest reseal. Current workflow provenance is cd08ded606c578332aaaecb2ceedb656e59911364cb86a6cd03fddbefdc92549, 20,100 bytes / 441 lines; the new quiescence regression is SHA-256 dba93f27e9f629abb4680d9e4e6be60dbf4a854d5537432b233387ba83293637 and is separately provenance-bound in Foundation.

The defect was behaviorally reproduced outside the static contract: a dedicated non-owner shell returned success while a background sleep PID remained under the same UID, after which the quiescence cleanup detected/killed it. Do not close #310 yet: #311 is still stacked on #259 and current exact head has no protected-base hosted Foundation admission or qualifying independent approval.

Successor authority update: #311 is now 6ed76309d8ca1f06e6223284fa9e406dbdf510f4 on #259 f1f152b0838e11cba1cf583706eb0983d56af373.

Current-head review of predecessor 778ab5d1... found a deterministic provenance-step RED: the older snapshot-binding regression still asserted shared-nobody commands after the workflow had moved to the dedicated ephemeral orgmetra_pg_contract principal. This was a stale test contract, not a reason to weaken the new process-isolation boundary.

Ordinary-forward repair: 37c177fa... aligns the regression with the dedicated principal and explicitly rejects sudo -n -u nobody; 9faa8f2b... binds the repaired regression SHA-256 9c90ed386248961640aeeddabfefb9c98d96bf3c550474ffb50ec2705775c92b; 6ed76309... reseals the Foundation manifest. Final workflow SHA-256 is 572f7427cdf8d91344aa979289e7bbfde82066f861f7dabcee88465a9282e890, 20,100 bytes / 441 lines.

#310 remains open: #311 is still stacked on #259 and has no protected-base hosted Foundation admission or transferable predecessor approval.

Successor authority advanced again: #311 exact head is now b40bc6e8e97834f1edee00eca338848071e5ad26 on #259 f1f152b0838e11cba1cf583706eb0983d56af373.

After repairing the stale shared-nobody regression, a fresh execution-boundary audit found a distinct residual isolation gap: process quiescence did not clear filesystem client state because every root/companion used HOME=/tmp under the same dedicated UID. A completed contract could leave conventional .psqlrc/cache/config/state residue for a later executable without leaving any live process.

36a6967c... adds the fail-closed runtime-workspace regression; c0021ae7... creates a runner-owned non-writable runtime parent and a fresh user-owned child per root/companion, binds HOME/TMPDIR/XDG cache/config/state to it, removes it after quiescence, and retains trap cleanup; b40bc6e8... reseals the manifest. Process/runtime regression SHA-256 is abd48ed1ceea5da8fe1890962dc2ad90a82f88f16306352ffa9105a2f23684a2; final workflow SHA-256 is dcf607453543007e5651b5228a0df1b81e042fc7d9e470c8dfc3c400bbc76d69, 20,978 bytes / 460 lines.

#310 remains open because #311 is still stacked and has no protected-base hosted admission or transferable predecessor approval.

Successor authority update: #311 is now exact daaf7954b0f3ad3e98b5d8dce96e96d824b530b6 on #259 f1f152b0838e11cba1cf583706eb0983d56af373.

CodeRabbit's exact b40bc6e8... review identified the remaining runtime-state escape: XDG_DATA_HOME and XDG_RUNTIME_DIR were inherited rather than bound to the fresh per-executable workspace. 770419e4... adds the RED regression, 6a30f41b... binds both paths under contract_runtime and updates the regression provenance hash, and daaf7954... reseals the manifest. Current process/runtime regression SHA-256 is 8d53ced7aa23df2a9896aad3cfe312852f40e5016df95f0478418a8b8bc522e5; Foundation workflow SHA-256 is 24e7e26e12c5fe901c0088558ebee10ae6b34cbb4e08dd5c2ddfc6bd123e5619, 21,102 bytes / 462 lines.

#310 remains open: #311 is still stacked and has no protected-base hosted admission or transferable predecessor approval.

#312 owner canary is now exact head 45a0296f9ad513b3f73dfce24a09d26d629b447a. When #310/#311 is ordinary-forward reconciled with the #107 descendant stack, owner-neutral PostgreSQL Foundation discovery must admit both tests/test_document_record_idempotency_postgres.sh and tests/test_document_record_idempotency_isolation_postgres.sh without filename-specific switchboard logic or copying the tests prematurely onto #311.

The first contract exercises real concurrent replay, changed-semantic conflict, FORCE RLS, append-only receipts, connection cleanup, and timezone-stable identity across UTC/Asia-Seoul callers. The second enters a real REPEATABLE READ transaction and requires the owner to fail closed before command validation because replay visibility is only specified for Read Committed. Hosted GREEN remains intentionally unclaimed until the canonical Foundation path executes both contracts on the reconciled exact head.

Fresh Foundation owner audit advanced the implementation successor #311 to exact 101145be960b0b314748f4795acffdd180ebb441 on #259 f1f152b0838e11cba1cf583706eb0983d56af373.

The new finding was an execution-boundary leak that remained after process quiescence and per-executable HOME/TMPDIR/XDG isolation: sudo -u "$contract_user" env ... still inherited the parent runner/job environment. A contract could therefore observe ambient PGOPTIONS, PGSERVICE, PYTHONPATH, proxy/config variables, or future job-level configuration outside the reviewed PostgreSQL contract boundary.

Ordinary-forward RED → repair:

7a844c153dcc58940f6ea7a0fb57c3f01d7d9c0e: regression requires a scrubbed execution environment, explicit tool PATH, and rejects the inherited-env invocation.
d32a46be84dc323c2fbca33cfee606c6cde0d7b3: Foundation contract execution now starts with env -i, then explicitly supplies PATH, the authoritative DATABASE_URL/PGPASSWORD, and the disposable HOME/TMPDIR/XDG variables only.
101145be960b0b314748f4795acffdd180ebb441: manifest resealed to the final workflow bytes.

Current provenance: process/runtime/environment regression 6814ecb6a6cf983aad935c8a022ed05cb19759ca502d6fc24c6e47e0a7ef720d; Foundation workflow 55cbbb3cbbab6759a14db8457b3dd380bf48f5830bd8cafb95ae5dcb6c20942c, 21,134 bytes / 463 lines. daaf7954... → 101145b... is 3 commits ahead / 0 behind and changes only the workflow, its isolation regression, and manifest.

Durable acceptance invariant: process identity, process quiescence, and fresh filesystem homes are insufficient if an executable still inherits ambient CI environment. Canonical Foundation acceptance should begin each untrusted/owner contract from an empty environment (or equivalent explicit allowlist) and pass only the reviewed endpoint/auth/tool/runtime variables required for that executable.

#310 remains open. Hosted protected-base Foundation GREEN is not claimed because #311 remains correctly stacked on #259; no predecessor result or approval is transferred.

Fresh #311 audit found a remaining checked-versus-used gap that belongs to this Foundation owner lane. Exact #311 head 101145be960b0b314748f4795acffdd180ebb441 snapshots/hashes each root/companion shell and runs that reviewed copy under a non-owner identity, but the scripts still consume transitive repository files from the live checkout. For example, registered tests/test_job_analysis_snapshot_postgres.sh immediately executes database/migrations/0001...0013 by relative path. Those migration bytes are not part of the execution snapshot binding. A prior repository step can therefore change a migration or other transitive input after root-script provenance validation and before PostgreSQL execution; final cleanliness can detect drift later but cannot prove the database was built from the reviewed transitive bytes.

Acceptance successor should bind the whole executable dependency surface, not only root/companion shell bytes. Prefer an owner-neutral immutable candidate tree/workspace (or equivalent transitive manifest) created from the exact candidate and execute contracts with cwd inside that immutable boundary. Do not solve this with filename-specific migration lists. Keep the current #311 stack/Draft intact; this is a repair finding, not a close reason.

#311 current successor update: the transitive checked-versus-used gap is now repaired ordinary-forward at exact 6a78bfa208462d03d583b1c035452a32d056a506. RED 7466a3a... proved that root/companion byte snapshots were insufficient while contracts could still resolve database/migrations/* and other repository-relative inputs from the live checkout. Causal fix 087dd013... executes from a read-only git archive of the exact candidate commit, rejects symlinks in that tree, re-verifies registered executable digests there, temporarily denies the contract principal traversal of the live checkout, and preserves existing env -i, disposable runtime state, and process-quiescence controls. 6a78bfa... reseals the Foundation workflow as SHA-256 1ed982603e2ccd4c2b18be37449954d0f610fe1396be9245040b2457a2bd46a7, 24,173 bytes / 527 lines. Local 5/5 boundary regressions plus bash -n are GREEN; hosted protected-base Foundation is still absent because #311 remains correctly stacked on #259, so no hosted-GREEN/approval transfer is claimed.

#311 implementation authority advanced by ordinary-forward RED→repair→reseal to exact head a97afd2354a181c3dad03557001aa1379c318a42. Fresh review of predecessor 5f3196ee... verified two remaining runtime-authority gaps after exact-tree isolation: inherited executable-search authority via PATH="$PATH", and an XDG_RUNTIME_DIR path that did not exist at contract start. 3c15d40... makes both executable regressions; 2dc8b4d... creates the runtime directory as orgmetra_pg_contract with mode 0700 and pins the scrubbed contract PATH to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; a97afd2... reseals manifest provenance. Local deterministic evidence: five runtime/exact-tree regression tests PASS and extracted PostgreSQL step passes bash -n. Hosted PostgreSQL GREEN remains pending normal #259→#311 reconciliation; no predecessor runtime evidence is transferred.

Fresh exact-head audit of #311 found a current acceptance-evidence RED after the exact-tree repair. #311@a97afd2354a181c3dad03557001aa1379c318a42 contains tests/test_foundation_postgres_contracts.py blob ad3fa733d4767047c41674a6c5274cf0253c761e, whose corrected exact-tree regression SHA-256 is 7b96082acb24f5a49cb6015be620b7ef675a6fda7943eb1c73816db8d832c3d3. The test now requires execution_script="$candidate_snapshot_dir/$script" / exec bash "$2" and rejects obsolete bash "$snapshot_script" execution.

Current .github/workflows/foundation-ci.yml still pins ORGMETRA_POSTGRES_TEST_SHA256=9c90ed386248961640aeeddabfefb9c98d96bf3c550474ffb50ec2705775c92b, so the current head is deterministically RED at provenance preflight before that regression can execute. The workflow/manifest pair is internally sealed to workflow SHA-256 a38c4c6828d7110c2921e7d7f90952dde92b4984e74731ad42bbddcebb3d9199 (24,325 bytes / 528 lines), but that seal contains the stale child-test digest and is therefore not GREEN evidence.

Canonical repair: do not revert the regression to its obsolete assertion. Ordinary-forward update the workflow expected inventory-regression SHA to 7b96082a..., execute the deterministic provenance/regression boundary, then reseal manifest.json from the resulting workflow bytes. Any intervening branch delta must be adopted before resealing. Until then #311 must remain Draft and must not claim local or hosted GREEN.

#311 authority advanced again after fresh exact-head review found a real provenance-preflight RED. At a97afd2..., tests/test_foundation_postgres_contracts.py had legitimately advanced to SHA-256 7b96082acb24f5a49cb6015be620b7ef675a6fda7943eb1c73816db8d832c3d3, while the workflow still expected predecessor 9c90ed...; Foundation would therefore fail before running that regression. Ordinary-forward repair: 31c95f3d9d99edd4cc8bc748c4b2888b064b322a refreshes only the expected child-test digest without reverting the exact-tree assertion, and dbc2fcf70ba6a6883381e8526cd62c6e19ce159c reseals manifest.json. Final workflow SHA-256 is 025a9a0588f68720640bf46a754f62444ff44c8ef48b69a79fd4fbd391083be2, 24,325 bytes / 528 lines. Hosted PostgreSQL GREEN remains pending normal #259→#311 reconciliation.

Superseding the earlier RED handoff: #311 ordinary-forward adopted the corrected inventory regression and completed the provenance repair. Current exact authority is #311@dbc2fcf70ba6a6883381e8526cd62c6e19ce159c on #259 f1f152b0838e11cba1cf583706eb0983d56af373, open/Draft/mechanically mergeable. 31c95f3d9d99edd4cc8bc748c4b2888b064b322a updates ORGMETRA_POSTGRES_TEST_SHA256 to exact current test SHA-256 7b96082acb24f5a49cb6015be620b7ef675a6fda7943eb1c73816db8d832c3d3; dbc2fcf70ba6a6883381e8526cd62c6e19ce159c reseals the final workflow as SHA-256 025a9a0588f68720640bf46a754f62444ff44c8ef48b69a79fd4fbd391083be2, 24,325 bytes / 528 lines. The corrected exact-tree regression was retained rather than reverted.

This closes the stale child-test-digest finding. Hosted/protected-base GREEN is still not claimed because #311 remains stacked on #259 and has zero PR-triggered workflow runs on dbc2fcf...; current Devin/CodeRabbit success statuses are review signals, not PostgreSQL runtime admission or an independent approval.

#311 advanced to exact head 4e441993....

The remaining false-owner path is repaired test-first: migrations and PostgreSQL root contracts are no longer duplicated in Python/Node filename arrays; the canonical registry plus immutable exact-candidate tree owns discovery/provenance, and the local validation entry point now invokes that registry. Fresh exact-tree evidence is Node 56/56 and PostgreSQL registry/process 28 run, OK (1 environment-dependent skip).

A diagnostic combination with #446 now fails for the actionable reason—15 unregistered product-composition PostgreSQL roots—rather than the stale Node inventory omitted migration 0018 switchboard error. #310 remains open because #311 is Draft/stacked on #259 and protected-base hosted admission plus independent approval remain outstanding.

Navigation Menu

Repository navigation

ci: make PostgreSQL Foundation contracts non-vacuous and owner-neutral #310

Verified Foundation false-green

Canonical acceptance

RED/GREEN acceptance

Current adopters

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ci: make PostgreSQL Foundation contracts non-vacuous and owner-neutral #310

Description

Verified Foundation false-green

Canonical acceptance

RED/GREEN acceptance

Current adopters

Activity

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 12, 2026

seonghobae commented on Sep 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions