Finding
Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f still creates the canonical validity_study registry in public, while ARCHITECTURE.md and TRD.md assign that registry to the workforce_validation bounded context and require service-owned schemas/database roles. Parent #235 establishes the governed application boundary and owner-schema bootstrap but intentionally leaves application relations untouched.
FR-007 therefore still lacks its complete durable owner path: ValidityStudyReadPort needs a PostgreSQL adapter against a service-owned relation without introducing copied truth or cross-service application SQL.
Required repair owned by #248
Dependency-first child #248 must preserve the existing relation object with forward ALTER TABLE ... SET SCHEMA, retain inbound FK linkage/forced tenant RLS/bitemporal governance, keep workforce_validation_role as NOLOGIN schema/migration owner, add a distinct NOBYPASSRLS read runtime role, and provide a schema-qualified read-only PostgreSQL adapter that binds tenant context transaction-locally. The adapter must snapshot/revalidate UUID target authority before executable connection behavior, structurally bind its validated connection capability, consume that exact tuple-stored callable without subclass-overridable property lookup, use bounded fetch, and fail closed on malformed/duplicate/foreign results.
#251 additionally requires normalized validity_study_case_record governance to remain executable after the schema move. The pre-existing trigger function embedded public.validity_study; the forward owner migration replaces that function in place so only the registry relation target changes while signature, trigger attachment and non-study governance remain intact. #250/#252 preserve the connection-dependency checked-versus-used invariant.
No compatibility copy/view, second mutable registry, cross-service application SQL, protected global migration-history rewrite, mutable owner source copy, force-push, destructive rebase, gate weakening or administrator bypass is valid.
Current dependency state — 2026-09-06
#248's own exact head remains d54d44d795444df572efbb301a667d74ac574d58 on recorded parent snapshot 656a0c41c06bc517b2cf7c554e35a6fb4f8c4f4b. GitHub's mechanical mergeability has changed during parent recomputation and is not acceptance evidence either way. The durable finding is the stale mutable-parent base.
Parent #235 has advanced ordinary-only to exact dd95dd7256f37aab2c4f26aa1fb43e8c867f4e4d. Its earlier exact e87d28a32683c6e6f115b3d13645b7d263451795 actually ran Foundation 33981328157, Repository quality 101346954404. #254 provenance validation passed, then Workforce Validation executed 25/25 passing tests but failed its own gate at 99.04% because the fail-closed _detach_policy(...) branch rejecting a non-exact string inside permitted_fields remained uncovered. Issue #255 preserves that real hosted RED.
Parent successor dd95dd725... is the minimum test-only repair: it changes only test_policy_runtime_integrity.py, making the hostile string subtype hashable with ordinary str.__hash__ so it can inhabit a frozenset and proving the Workforce boundary rejects that subtype in permitted_fields before caller-defined comparison behavior or persistence. Production authorization logic, SQL, migrations, workflow, provenance inventories, manifest, PostgreSQL contract and the 100% threshold are unchanged.
Fresh current-head acceptance now exists for that parent successor. Foundation 33986151272 is terminal SUCCESS, including exact repository validation, owned service coverage and isolated PostgreSQL contracts; SAST 33986151255 is terminal SUCCESS. Security 33986151270 is terminal FAILURE only at the shared Dependency Review support probe after exact-head verification, while CodeQL 33986151302 is terminal FAILURE only after both compatibility jobs successfully request current-head central dispatch and then fail at Release runner or enforce current-head CodeQL verdict. Those shared control-plane failures are non-passing parent acceptance, not a child source defect or permission to restack against mutable source. Submitted parent reviews remain COMMENTED-only with no qualifying APPROVED review.
Acceptance and integration order
#235 must complete the remaining authoritative shared Security/CodeQL control-plane path plus qualifying review and integrate normally to protected develop first. Then #248 non-force adopts that protected truth and retargets to develop, preserving parent #249 exact repository-capability identity, #253 Protocol-placeholder rejection, #254 provenance sealing, #255 exact policy-field regression, and all valid child migration/adapter/#250/#251/#252 delta.
The restacked child must then reacquire exact-head 100% owned statement/branch coverage, isolated PostgreSQL adoption GREEN, terminal required security workflows, independent review and normal protected-branch integration. #247/#250/#251/#252 stay open until that is complete. Source implementation, mutable-parent Foundation success, static review or temporary mergeability is not a close condition.
Finding
Protected
develop@eb9757f8649aaad026a9865508d9aad50c1a7a4fstill creates the canonicalvalidity_studyregistry inpublic, whileARCHITECTURE.mdandTRD.mdassign that registry to theworkforce_validationbounded context and require service-owned schemas/database roles. Parent #235 establishes the governed application boundary and owner-schema bootstrap but intentionally leaves application relations untouched.FR-007 therefore still lacks its complete durable owner path:
ValidityStudyReadPortneeds a PostgreSQL adapter against a service-owned relation without introducing copied truth or cross-service application SQL.Required repair owned by #248
Dependency-first child #248 must preserve the existing relation object with forward
ALTER TABLE ... SET SCHEMA, retain inbound FK linkage/forced tenant RLS/bitemporal governance, keepworkforce_validation_roleas NOLOGIN schema/migration owner, add a distinct NOBYPASSRLS read runtime role, and provide a schema-qualified read-only PostgreSQL adapter that binds tenant context transaction-locally. The adapter must snapshot/revalidate UUID target authority before executable connection behavior, structurally bind its validated connection capability, consume that exact tuple-stored callable without subclass-overridable property lookup, use bounded fetch, and fail closed on malformed/duplicate/foreign results.#251 additionally requires normalized
validity_study_case_recordgovernance to remain executable after the schema move. The pre-existing trigger function embeddedpublic.validity_study; the forward owner migration replaces that function in place so only the registry relation target changes while signature, trigger attachment and non-study governance remain intact. #250/#252 preserve the connection-dependency checked-versus-used invariant.No compatibility copy/view, second mutable registry, cross-service application SQL, protected global migration-history rewrite, mutable owner source copy, force-push, destructive rebase, gate weakening or administrator bypass is valid.
Current dependency state — 2026-09-06
#248's own exact head remains
d54d44d795444df572efbb301a667d74ac574d58on recorded parent snapshot656a0c41c06bc517b2cf7c554e35a6fb4f8c4f4b. GitHub's mechanical mergeability has changed during parent recomputation and is not acceptance evidence either way. The durable finding is the stale mutable-parent base.Parent #235 has advanced ordinary-only to exact
dd95dd7256f37aab2c4f26aa1fb43e8c867f4e4d. Its earlier exacte87d28a32683c6e6f115b3d13645b7d263451795actually ran Foundation33981328157, Repository quality101346954404. #254 provenance validation passed, then Workforce Validation executed 25/25 passing tests but failed its own gate at 99.04% because the fail-closed_detach_policy(...)branch rejecting a non-exact string insidepermitted_fieldsremained uncovered. Issue #255 preserves that real hosted RED.Parent successor
dd95dd725...is the minimum test-only repair: it changes onlytest_policy_runtime_integrity.py, making the hostile string subtype hashable with ordinarystr.__hash__so it can inhabit a frozenset and proving the Workforce boundary rejects that subtype inpermitted_fieldsbefore caller-defined comparison behavior or persistence. Production authorization logic, SQL, migrations, workflow, provenance inventories, manifest, PostgreSQL contract and the 100% threshold are unchanged.Fresh current-head acceptance now exists for that parent successor. Foundation
33986151272is terminal SUCCESS, including exact repository validation, owned service coverage and isolated PostgreSQL contracts; SAST33986151255is terminal SUCCESS. Security33986151270is terminal FAILURE only at the shared Dependency Review support probe after exact-head verification, while CodeQL33986151302is terminal FAILURE only after both compatibility jobs successfully request current-head central dispatch and then fail atRelease runner or enforce current-head CodeQL verdict. Those shared control-plane failures are non-passing parent acceptance, not a child source defect or permission to restack against mutable source. Submitted parent reviews remain COMMENTED-only with no qualifyingAPPROVEDreview.Acceptance and integration order
#235 must complete the remaining authoritative shared Security/CodeQL control-plane path plus qualifying review and integrate normally to protected
developfirst. Then #248 non-force adopts that protected truth and retargets todevelop, preserving parent #249 exact repository-capability identity, #253 Protocol-placeholder rejection, #254 provenance sealing, #255 exact policy-field regression, and all valid child migration/adapter/#250/#251/#252 delta.The restacked child must then reacquire exact-head 100% owned statement/branch coverage, isolated PostgreSQL adoption GREEN, terminal required security workflows, independent review and normal protected-branch integration. #247/#250/#251/#252 stay open until that is complete. Source implementation, mutable-parent Foundation success, static review or temporary mergeability is not a close condition.