You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PostgresValidityStudyReadPort stores its accepted connection_factory in tuple-backed storage, but predecessor read_validity_study(...) invoked it through self.connection_factory(). A subclass could override that property (or dynamic attribute resolution) and substitute a different executable connection capability after construction, defeating the structural-binding guarantee introduced by #250.
This is a checked-versus-used dependency boundary: the constructor validated/stored one callable, while the executable read could resolve another callable later.
Test-first repair
ceb72ff997fdf54640a146c8569b0ee225312507: focused regression creates a PostgresValidityStudyReadPort subclass whose connection_factory property returns a replacement callable. The inherited read must still call only the original constructor-accepted factory.
d54d44d795444df572efbb301a667d74ac574d58: production reads the executable dependency directly from base tuple storage with tuple.__getitem__(self, 0) and invokes that local callable. The public property uses the same direct tuple read.
CodeRabbit independently reviewed exact d54d44d795444df572efbb301a667d74ac574d58 and reported no defect in the requested #252 scope. It confirmed the test-first predecessor, direct tuple-storage selection, UUID snapshot ordering, read-only transaction, tenant-local set_config, schema-qualified parameterized owner SQL, bounded fetch, row reconstruction and absence of unrelated parent-owned changes. This is static evidence only; it did not execute tests/PostgreSQL/coverage and is not a qualifying approval or hosted GREEN.
Finding
PostgresValidityStudyReadPortstores its acceptedconnection_factoryin tuple-backed storage, but predecessorread_validity_study(...)invoked it throughself.connection_factory(). A subclass could override that property (or dynamic attribute resolution) and substitute a different executable connection capability after construction, defeating the structural-binding guarantee introduced by #250.This is a checked-versus-used dependency boundary: the constructor validated/stored one callable, while the executable read could resolve another callable later.
Test-first repair
ceb72ff997fdf54640a146c8569b0ee225312507: focused regression creates aPostgresValidityStudyReadPortsubclass whoseconnection_factoryproperty returns a replacement callable. The inherited read must still call only the original constructor-accepted factory.d54d44d795444df572efbb301a667d74ac574d58: production reads the executable dependency directly from base tuple storage withtuple.__getitem__(self, 0)and invokes that local callable. The public property uses the same direct tuple read.b210b6bd201a9b62949da33bc4a9feb92ec6a095is two ordinary commits ahead / zero behind and changes only the PostgreSQL adapter plus the focused regression.CodeRabbit independently reviewed exact
d54d44d795444df572efbb301a667d74ac574d58and reported no defect in the requested #252 scope. It confirmed the test-first predecessor, direct tuple-storage selection, UUID snapshot ordering, read-only transaction, tenant-localset_config, schema-qualified parameterized owner SQL, bounded fetch, row reconstruction and absence of unrelated parent-owned changes. This is static evidence only; it did not execute tests/PostgreSQL/coverage and is not a qualifying approval or hosted GREEN.Acceptance still open
develop, preserve fix(workforce-validation): bind PostgreSQL connection capability from tuple storage #252, and reacquire fresh exact-head Foundation/PostgreSQL/security/review evidence.Keep #252 open until that protected integration. Source repair or static review alone is not a close condition.